`_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>
Migrated from the 17.0 branch (4fbf328). APIs that no longer exist in 18.0:
* `order.selected_paymentline` -> `order.get_selected_paymentline()`
* `ErrorPopup` + `env.services.popup` -> `AlertDialog` + `env.services.dialog`
* `/** @odoo-module */`, implicit in `.esm.js` since 17.0
The rounding itself needed a different approach: `get_rounding_applied()` now
reads `taxTotals.order_rounding`, only computed over payments that are already
`is_done()`. The CashDro line is still `waiting` when the amount is requested,
so a literal port would always have added 0. `getDefaultAmountDueToPayIn()` is
the 18.0 equivalent: it applies `getRoundedRemaining()` honouring both
`cash_rounding` and `only_round_cash_method`, and is what core itself uses for
the default amount of a payment line.
Only `_cashdro_payment_url()` is patched now, instead of duplicating the whole
`cashdro_send_payment_request()`, so the request flow, the acknowledge, the
polling and the error handling stay in the base module. With no cash rounding
configured the patch delegates to `super` and changes nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
