Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Scenario:
You have an order where the value of products + shipping is 100.05 USD and you are using the currency format with "Number of decimal places" 0.
The client is displayed the price for total order 100 USD with no decimals so he will pay only 100 USD instead of 100.05 USD. Of course when you enter the payment in the payments tab of order you will enter 100 USD because this is the correct amount that the client payed for the order.
Now if you have a rule that "Check the order ballance" for "Balance is equal to 0 USD" it will fail because the order balance is in fact 0.05 USD which is greater than 0.01. So if you have, like me, a rule that should change the order status to anything (for example "Completed" or "Payment Received") on payment receive and the payment balance is 0 it will fail.
This can be fixed by making $balance in "function uc_payment_condition_order_balance" from uc_payments module use uc_currency_format for checking the balance.
Or maybe the output of uc_payment_balance() should be outputted trough uc_currency_format()?
I'm waiting for your suggestions in order to make a patch...
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 1817696-uc_payment-balance-property.patch | 866 bytes | longwave |
Comments
Comment #1
longwaveuc_payment_balance() should not automatically use uc_currency_format(), that should be up to the caller, so to fix this I suggest changing the condition only.
Out of interest why do you have decimal places set to 0, but then use prices like 0.05?
Comment #2
SilviuChingaru CreditAttribution: SilviuChingaru commentedMy shipping rates are as following:
17.89 per first kg
0.72 per additional kg
I cannot put prices for shipping like 18 for firs kg an 1 per additional kg because our average weight for order is near 10 kg so the shipping price will be 27 instead of 24. Not to talk about orders at 80 kg... There is also no option to round the shipping quotes.
Also think about coupons of percent discount where calculation can be with decimals and so on...
Comment #3
longwaveActually, when you explain it like that, I am not sure this is really a bug, and we perhaps should not change the code; instead you should change your conditions. For your case, shouldn't you change your rules so you "check the order balance" is less than 0.50 USD?
Comment #4
SilviuChingaru CreditAttribution: SilviuChingaru commentedAnd what if is smaller than 0 with 0.13 like -0.13? There is no logic to calculate order with a number of decimals and check against it with other number of decimals. Am I right?
Comment #5
longwaveThat is still less than 0.50 USD, and if you are checking for full payment, -0.13 is still a valid balance for that?
Comment #6
SilviuChingaru CreditAttribution: SilviuChingaru commentedHmm I think you are right but I still think this is workaround and there is no logic to check against same values with different formatting, right?
Comment #7
TR CreditAttribution: TR commentedI don't consider this a bug at all. By hiding the decimal portion of the price, you are effectively trying to set up your site so that all prices are rounded. That is not a core Ubercart capability, nor do we currently intend to put that capability into core. A contributed module should be able to add that ability, and it would be the responsibility of the contributed module to properly handle the rounding EVERYWHERE, including shipping and taxes. The "number of decimal places" setting is not intended for rounding - it's sole purpose is to define the number of decimal places used by a currency. Since your currency supports units of 0.01, it's not correct to set the number of decimal places to 0. It should be 2. If you are simply trying to theme the price display to suppress the .00, the proper way to do that is by overriding theme_uc_price().
Comment #8
SilviuChingaru CreditAttribution: SilviuChingaru commented@TR:
And why not put it in the core? Then why don't you take decimal places option out of the uc_store module and we will implement it as a theme hook. I don't understand what is the role of that function anymore?
Yes my store display prices rounded and my clients pays rounded but I want to have a report of costs EXACTLY with decimals so I can't round costs from stock update module, right? Or even shipping quotes for each courier because I need to know exactly how much I paid that courier in order to claim a discount and so on. I'm using Ubercart for rounding and is all ok except the mentioned bug so maybe it wasn't programmed with this purpose but is also useful like this so where is the problem?
There is no hook to allow alteration of uc_currency_format output so how to use a custom module (anyway I don't see the logic to use a custom hook if the core could and should be fixed to work according to administrator settings). By the way I use the standard shipping module why doesn't it store the shipping in the correct currency format??? This mean I need to use a custom shipping module? Maybe this module should be also removed from core if is useless in all configurations and is useful in only few/one configurations.
@longwave:
The only options for "Check the order balance" are:
- Balance is less than 0
- Balance is less than or equal to 0
- Balance is equal to 0
- Balance is greather than 0
so how can I set an order of witch balance is 0.14 as completed??? Maybe should be an option Balance is less/greater than custom value also... but I think the function should use store settings for comparing values.
Comment #9
longwaveHm, I was sure that the balance condition could already do that, but I guess not!
At the very least though this is a feature request; as already stated Ubercart was not designed to be used like this, I am glad it is (mostly) working out for you when configured this way, and perhaps we can work towards better rounding capability in core, but it is certainly not a bug.
Comment #10
SilviuChingaru CreditAttribution: SilviuChingaru commentedAnd how could we work towards on this? I'll make the patch but how could we implement this?
I think the structure should be more like default rules value check, so will be like this:
Check if order balance is
OPERATOR: greater than, greater or equal, equal, less, less or equal
VALUE custom input and maybe a default
Is this structure ok?
Comment #11
longwaveThis patch adds an order:payment-balance property that can be used with the "data comparison" condition, allowing any operator and value to be tested.
Comment #12
longwaveCommitted #11.
Comment #13
SilviuChingaru CreditAttribution: SilviuChingaru commentedNice solution. I'll test it and report back...
Comment #14.0
(not verified) CreditAttribution: commented...