Ubercart

+1

It's really critical for accounting that the actual amounts received for each order are stored with the order. I haven't checked the tables, but other things that are vital for accounting are the actual ship date and the actual receipt date for the payment(s) - not just the order date! This is true whether you use cash or accrual accounting. Even if there is no Ubercart accounting module and accounting is supported just by export to QuickBooks etc., it is absolutely essential that the needed information is stored! Also, a field for actual shipping amount paid by the business to ship the order and the actual date shipped, because these will be needed for accounting too when shipping (not just shipping quotes) is fully integrated. (maybe this is added by the shipping module)

Generally, every cent (or should that be uc_currency_format('cent')? ) that is received or paid via Ubercart needs to be recorded with its associated transaction.

Gord, I agree...this could lead to some rather large problems when dealing with adding, removing, or altering taxes in any way. Any adjustments to state or local taxes, or even something like the tax free holidays that some states offer could require you to make these changes.

I'd rather see these values stored per order during the checkout process as opposed to being date based rules. The date based rules would still leave you with the problem of needing to re-calculate each time and would leave more room for inconsistencies between what was actually paid and what is later reported.

Would there be large problems trying to tie taxes in with line items?

Why doesn't the tax amount for an order get stored in the uc_order_line_items table with a type of 'tax' and the title of the tax method used?

I think it's due to the line items API having to differentiate between calculated line items (like a tax which has to be calculated each time in case a country, zone, product type, etc. changes) and a stored line item like a shipping fee. I'm open to discussion on how to improve the line item API, but basically we're looking at either leaving it like it is or making sure sales people remember to recalculate taxes when they make a change to an order.

Can't there be a trigger to recalculate the tax when a change to an order is made?

I was thinking the same thing as I was typing it. Similarly, it could check the order status before recalculating the tax and not do it if the order status is in the completed state.

That would be ideal, then it would be a simple group by statement and sum to calculate taxes.
Keep in mind though that it would be quite useful to store what the tax was at the time of calculation.
Eg: Order is placed when the tax was 6%, the next day the store owner processes it after adding/removing an item from the order. The new tax rate of 7% would apply even though the customer ordered before then.

It is an edge case issue, being able to manually set the tax after calculation would be a potential work around...

Gord.

I've made it so that the amount of tax that is charged to an order is recorded in the order log. Any changes that affect the tax amount will be reflected there as well, so everything should be traceable now.

Thank you for recording the taxes in the order log. Unfortunately, the numbers are being inserted into an HTML unordered list, which makes them difficult to retrieve and work with. Also, the numbers are being saved with uc_currency_format() already applied.

I'm looking for an easy way to print out the order sub-total, along with each tax and line item amount that was applied. As it currently stands, I would have to run the order log through a regular expression to strip out the HTML and currency formatting, in order to get the raw numbers.

Perhaps the applied tax and line item amounts could be saved in the order's "data" field? Or, maybe some new fields could be added to the uc_orders table, such as "order_sub_total", "order_applied_taxes" and "order_applied_line_items"?

Has anyone addressed this issue in Ubercart 2? I haven't had time to explore it.

Thanks!

I've posted a patch at http://drupal.org/node/475810 that addresses this issue.