Search options (Page 11 of 11)

If you are prepaying freight, it is really an asset account, it is not an expense or cogs at the time you purchase the freight, because the customer transaction has not yet taken place.

I go back to my first suggestion: make a Shipping and Handling a G/L Asset account instead of a Revenue account.    A sales order with shipping will credit this account and purchasing freight will debit this account.  You won't have any revenue or expense in this scenario.

In the more usual scenario, the customer pays for freight up front, generating revenue.   Later, the carrier bills the sender, generating an expense.

cogs is another issue entirely, used for freight in when you are purchasing items to resell.

Perhaps setup prepayments to the freight consolidator as an Asset account (Prepaid Shipping), then change your FA G/L setup Shipping Charged Account to Prepaid Shipping, so that when you enter the FA invoice, the Shipping field uses the Prepaid Shipping account.

If you have multiple shippers with different g/l accounts, you would have to create Service items (e.g. Fedex, UPS, Prepaid USPS, etc) rather than using the provided Shipping field.

If you are offering free shipping, then you would not put any shipping on the sales order, but use a separate JE each time you ship a sales order.   As far as I can tell, there is no way for FA to tie the two together (ie. offer free shipping on the FA sales order and expense it elsewhere).

One idea, but I haven't tried it out yet.

https://github.com/apmuthu/frontac24/pull/7 allows service costs to be wrapped into purchased item costs on a single P/O or direct invoice and offers three methods for the calculation.

Thus, using the example offered, each computer is $100 and 10 computers are ordered.   A Freight service item for $100 is added to the P/O, and using the Quantity method, the price of the computer is automatically recalculated to $110 and the service item is zeroed.

While this does not directly address the issue of wrapping in P/Os from multiple vendors, such as DHL, it may be possible to do this by leaving the P/O open until the DHL bill arrives:

1.  When the DHL bill comes in, add the freight to the original P/O, which is then incorporated into the item pricing as described above.

2.  Because now this overstates the amount payable to the vendor of the original P/O, when the P/O is invoiced, the Freight account must be added as a G/L item to the invoice using the negative amount of the DHL payment.

3.  The amount invoiced should now be correct for the original vendor.

4.  DHL is paid in the usual manner against the G/L Freight account.

5.  The net Freight expense is zero, because the negative amount on the invoice offsets the positive amount of the DHL payment.

Result: the cost of the DHL freight is captured in the item price and will be reflected in COGS when the item is sold.

The disadvantage of this approach is that the P/O had to remain open to wait for the DHL freight billing, which delays deliveries, and therefore may not be acceptable.

I wrote the pull request to operate on the P/O, but perhaps it would preferable for it to operate when the invoice is created, which should work because item prices are not firmed up in FA until then.  That would allow the delivery to go forward before the DHL freight bill was received.

Or you could modify your FA installation with this pull request:
https://github.com/FrontAccountingERP/FA/pull/26

Good point.  That function is "Cancel Order", which happens to appear on the edit screen.

But why would anyone actually want to change any of the Sales Order Items or Order Delivery Details on the sales order after it was invoiced?

If you want to use the cash basis accounting method with FA, all you need to do is change the "Accounts Receivables" account group from an Asset to an Income account.   The Profit and Loss and Balance Sheet reports and tools will then report on the cash basis.  Its really that simple.

This should suffice for most simple businesses.  If you offer customer financing or prepayment, it gets a little more complex, because you may want to split interest from sales because of reporting requirements, and have to deal with negative A/R.   For example, customer A prepays $100 without an order and customer B makes a $100 order but hasn't paid yet.   Is your income -100, zero or $100 using cash basis accounting?  Good question on an accountant exam.

Caveat: this technique is broken if you use dimensions until FA is updated with a pull request I made.

If you use Accounts Payable, you would have to change it from a Liability to an Expense account (I haven't tested this).

Note: you can change the account group of "Accounts Receivable" back and forth with no harm done if you want to switch between cash to accrual basis.

Just restating what apmuthu said, follow the instructions by  trafficpest to import the customers.

I wrote some scripts that can aid in a Quickbooks / FA migration: https://gist.github.com/braathwaate/250e13959d437f616b6936025ecd9f56.  They are not turnkey and would require coding skill to get working on another migration.

If all you want is the customer list, you could use the qbimport.sh script that uses facebook/webdriver and selenium to remote control the FA customer entry page.   The advantage of doing an import this way is that you don't need to know anything about the FA database structure.  Its also fun to watch the import.

I did not import the invoices, so each customer started out with zero balance.   Payments after the migration were double entered in Quickbooks and FA (until the customer in both accounting systems reached the same outstanding balance; i.e. all payments from Quickbooks era invoices were received).   Payments from invoices from the Quickbooks era were entered in FA journal entry.

The 0-169 entries as you describe appear to be correct, so missing entries in gl_trans must not be the problem.

I was assuming that the error is coming from the call:

     add_journal(ST_JOURNAL, $curEntryId[ST_JOURNAL], ...

in import_transactions.   $curEntryId[ST_JOURNAL] is supposed to be 1 past the last transaction.   It should not be 169 if the last journal transaction is 2187.  You could instrument the code (add the line display_notification(...)) to try to determine why it is not  2187.   Instrument this call and in last_transno().

You could also use mysql to see if the following queries all return the same number:

select max(type_no) from gl_trans where type=0;
select max(trans_no) from journal where type=0;
SELECT counter, type, type_no, amount FROM gl_trans ORDER BY counter DESC LIMIT 1;

For initial testing, try creating a file with just one transaction.   Then examine the bottom of the green page.   If it says "xx would have been successful if imported. Uncheck Trial check before importing" then there is some problem with unclicking the trial check.  If it says "xx have been imported", then the item should have been imported, and the next step is to try to find it.   You should notice it on Trial Balance.  Look at the G/L for the account that was imported.  If you can't find it, then post the data line you tried to import.