Search options

Itronics - thanks for your help.  It's seems that what you are explaining is exactly what I've done.

I am in the US, where each state has it's own tax rate.  So I set up 3 Tax Groups, call them Group A, Group B, and Group C (one for each state our customers are in), and one for Tax Exempt customers.  Each of the 3 taxed groups only has one rate....the rate that applies to their state.  So Group A is set up for Tax A at 6%, Group B is set up for Tax B at 6.5%, and Group C is set up for Tax C at 7%.

The customer in question is not tax exempt, therefore I selected the appropriate tax group (Group C) in the customer branches setup.  Their state is at a 7% tax rate.

This is a "Direct Delivery" entry, but it seems to work the same if I try a Sales Order entry.  The order has only one item at $263, and a quantity of 4.  So the line item total shows $1,052.00, the sub-total shows $1,052.00, Shipping is $0.  All good so far.

Then the tax line shows the tax group and $68.882 for the tax.....which is NOT 1052 x .07.  It should be $73.64.  The Amount Total line still shows $1,052....which I understand (from reading the many posts on this topic) could be showing the total "value" of the goods in the order....which would exclude tax.

The real problem is that once delivered and invoiced, the invoice shows $1,052 on the TOTAL INVOICE line...so nowhere does the customer know the actual total to pay.....  which should be 1052 + 73.64 = $1,125.54

Thanks again for your help....believe me, I have tried figuring this out myself, but tax in this application is a fairly complex chain of included files and called methods on objects that are bounced around quite a bit in the code.

FYI....I wrote an extension module for this, which I called 'Pricing Bands'.  I had to modify the purchase order entry a bit to auto-pull the price based on the entered quantity (using AJAX).  If you are interested in this add-on, just let me know.

The way software I've used works, you specify a transaction type in the message, and then the data definition for each type must be adhered to.  XML is probably the best fit for this, but it could be just a formatted text document.

Here are some ideas that this negotiating feature could import:

- Consumption: if there's an MES system on the production floor that control the building process, and you just want to tell FA that you've built qty X of part Y.  I have written this add-on, which fires a page periodically that summarizes the production for the day (from the MES tables), and adds a simple work order to FA for this amount.  I am mainly doing just straight inserts into FA tables.  The trickiest part of this was getting around the session and security that is part of the normal application.

- Sales orders: this is for EDI interaction.  I wrote an add-on application for FA that wakes up every 30 minutes, connects to any number of FTP servers, pulls in any 850 purchase order documents, parses them into sales orders, inserts a sales order for each PO received, creates an 855 PO acknowledgement document, and sends it back via FTP.  Again, doing straight table inserts, but would be nice if there was a native FA mechanism to handle this from 'inside' the software.  The app I wrote is in c#, which I can provide source for, if you're interested.

- Shipments: if you are shipping items with a handheld device, or some other application that handles pallet serialization, truck cubing, robotic loading, etc.

- Receipts: again, if you are using a handheld to receive incoming material via scanning.

- Adjustments: if you do inventory cycle counting using a handheld device, you could directly apply the reconciliation to FA inventory levels.