CriptoMart/addons-cm
3
0
Fork 0
Code Issues Pull requests Wiki Activity Actions
addons-cm/pos_payment_method_cashdro_rounding/README_DEV.md
GitHub Copilot 57bf688169
[REF] pos_payment_method_cashdro_rounding: hook the amount, not the url builder 
`_cashdro_payment_url()` is shared by the payment and the reversal paths, so
patching it applied the rounding to the reversals too: giving back a paid
order sent the drawer the *order* remaining, rounded, instead of the amount
of the line, and reversing an order already covered by other payments sent 0.

It also collided with the modules that fix that same method, leaving the
outcome to the asset load order.

Both go away by hooking `_cashdro_amount()`, the extension point
`pos_payment_method_cashdro_flow_fix` provides, which is only reached on a
payment. `shouldRound`/`getDefaultAmountDueToPayIn` came with the 18.0 tax
totals rework, so fall back instead of breaking the payment with a TypeError
the operator would read as one more connection error.

Adds the README_DEV.md the repo conventions ask for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 17:43:38 +02:00

2.4 KiB
Raw Blame History

pos_payment_method_cashdro_rounding

Sends the CashDro the amount the customer is really expected to pay — the due amount with the PoS cash rounding applied — instead of the plain due amount the OCA module asks for.

Why

A CashDro can only give change with the coins it holds. When the PoS is configured with a cash rounding (pos.config.cash_rounding, typically to 0.05 so that 1 and 2 cent coins are not needed), asking the drawer for the unrounded due leaves it trying to return change it does not have.

Core already computes that amount: PosOrder.getDefaultAmountDueToPayIn() is what a payment line defaults to when it is created. We simply reuse it, so the drawer is asked for exactly what the payment screen shows.

shouldRound() decides whether the rounding applies at all — it takes only_round_cash_method into account, and the CashDro method is a cash one, so in practice it is always true when a cash rounding is configured.

How

One single patch on PaymentCashdro.prototype._cashdro_amount(), the hook pos_payment_method_cashdro_flow_fix extracted for this. Everything else of the OCA payment flow (request, acknowledge, polling, error handling) is untouched.

Two things this deliberately does not do:

  • It does not touch the reversals. There the amount to send is the one of the line being given back, not the remaining of the order, and it is already the rounded figure that was collected. Rounding it a second time against the order total would ask the drawer to collect the total all over again.
  • It does not touch _cashdro_payment_url(), which is what it patched until 18.0.1.1.0. That method is shared by the payment and the reversal paths, which is exactly how the reversal bug above got in, and it collides with the fix modules that also patch it — the outcome then depending on the asset load order.

Dependencies

Needs pos_payment_method_cashdro_flow_fix for the _cashdro_amount() hook, and through it pos_payment_method_cashdro_fix: without them the OCA module does not work on 18.0 at all, so there is nothing to round.

Testing

There are no automated tests — the flow needs a CashDro answering on the network. To check it by hand, configure a cash rounding of 0.05 on the PoS, take an order to a total that is not a multiple of 0.05 (e.g. 17.43) and confirm the drawer asks for 17.45. See the USAGE of pos_payment_method_cashdro_flow_fix for how to read a failure.