 edited description
Because somtimes the values change after converting and rounding several times by several functions the paid amount will not always reduce the payment value to zero. Thats why the paid_in_fullmethod won't return true and our external payment provieders did not close with a success email after a successful payment.
My proposal is to create a field in the settings where the shop owner can define a tolerance value (eg 0.10) the zerobalance can differ from
setting:
ORDER_VALUE_TOLERANCE = config_register( DecimalValue(PAYMENT_GROUP, 'ORDER_VALUE_TOLERANCE', description= _('Order value tolerance'), help_text=_('Enter a decimal value which will be used as tolerance around the order value (eg 0.10 so the paid amount can differ  or + 0.10 of the order total).'), default='0.00' ) )
Before:
def _paid_in_full(self): """True if total has been paid""" return self.balance == Decimal('0.00') paid_in_full = property(fget=_paid_in_full)
After:
def _paid_in_full(self): """True if total has been paid""" config = config_get_group('PAYMENT') try: tolerance = config.ORDER_VALUE_TOLERANCE.value except: tolerance = '0' return self.balance >= Decimal('%s'%tolerance) and \ self.balance =< Decimal(tolerance) paid_in_full = property(fget=_paid_in_full)
Comments (5)

reporter 
reporter  edited description

I can't think of a reason why the order total should not be nicely rounded at all times. Couldn't we just change
Order.force_recalculate_total
to round the order total? Maybe parametrize the rounding so user can choose to round up or down or whatevs? Would we also have to round the total tax and total discount values to make sure that all the order's components add up exactly to the total?I had rounding problems when implementing PayPal Pro stuff as it requires rounded amounts for each line item and for the order total. In my case, all the insignificant digits in the total where caused solely by the tax procesor.

I've come across what appears to be a rounding issue as well. It seems to be whenever tax is involved. In the order admin the order total was one cent less than the balance forward. My solution was to edit my payment calculation in my custom Authorize DPM to
"%0.2f" % (math.ceil(float(total)*100)/100)
. The actual total as 9.2125 and the balance forward was 9.22. 
reporter Thanks. I will have a look at it. Meanwhile we created a custom branch with proposed feature above because our system must be able to define a cent tolerance. I think we can close this one.
 Log in to comment