Tomas, no. Tax rounding is not used and is not important for Satchmo. It is better at some point of view to round the sum than to round every item. Order total is rounded up (or should be rounded) to two decimal places by trunc_decimal as well as balance which is used for paid_in_full test. It's on the edge but it works each other.
I remember some reports related to rounding or probably related to it, but nobody provided more details last year and I think it is unconfirmed. e.g. the problem disappeared in http://groups.google.com/group/satchmo-users/browse_thread/thread/f89a14175caf54da/ after my questions. If it is in your code try to use that rounding for order total. If you think the problem is with some builtin payment processor, please write which and verify it by logging. (I personally can not test any payment processor. I can only read the source and probably understand it after some effort. So I would not be easy suitable for payment modules because I need more feedback.) On 25 lis, 16:31, Tomas Neme <[email protected]> wrote: > I'm having a little issue with taxes with the digits below the 2nd > decimal. The order says it's for 79.690538, and a payment gets > captured for 79.69, so satchmo says the order is not paid in full. > > I understand that each tax should be rounded but I wonder where's the > right place to do that? I'm looking at the area tax module and I don't > see anything specific for this > > Thanks > Tomas > > -- > "The whole of Japan is pure invention. There is no such country, there > are no such people" --Oscar Wilde > > |_|0|_| > |_|_|0| > |0|0|0| > > (\__/) > (='.'=)This is Bunny. Copy and paste bunny > (")_(") to help him gain world domination. -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
