Order::_paid_in_full should not compare to exactly Decimal(0)

Issue #1475 new
Dag Königrör
created an issue

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_full-method 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 zero-balance 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)

  1. marconius

    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.

  2. Nathaniel Pardington

    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.

  3. Dag Königrör 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.

  4. Log in to comment