TIP: You can type at any time to perform a new search.
Romania - Point of Sale Refunds
l10n_ro_pos_refund · OCA/l10n-romania
- Repository
- OCA/l10n-romania · module folder · Try on Runboat
- Module version
- 1.4.0
- Category
- Localization
- Folder size
- 0.07 MB
- License
- AGPL-3
- Application
- No
- Auto-installable
- No
- Website
- https://github.com/OCA/l10n-romania
- Last tracking update
- 2026-09-25 17:32:05
- Authors
- Odoo Community Association (OCA), NextERP Romania
- Maintainers
- Odoo Community Association (OCA), NextERP Romania
- Committers
- Mihai Fekete, OCA-git-bot, oca-ci
- Odoo dependencies
- Python dependencies
- num2words>=0.5.8
- System dependencies
- None
- Required by
- None
- Description
In Romania a fiscal receipt cannot be reversed by printing a negative one: the refund has to go out as a credit note ("factura storno"), and the cash given back over the counter has to be covered by a payment disposal ("dispozitie de plata") the customer signs for. This module makes both of them happen on their own. Refunding a receipt in the Point of Sale creates a regular refund order, and as soon as it is paid: - the credit note is issued on the invoice journal of the Point of Sale -- invoicing a refund is not optional any more. The cashier is asked for the customer as soon as the refund is created, and the payment screen says why it cannot be validated without one; - the cash returned is registered as its own cash statement line, linked to the session and settling the credit note directly. That line is the payment disposal, and it comes out of the printer at the till right behind the credit note, for the customer to sign. A refund either produces a real credit note or does not happen at all. Where core would attach a proforma and carry on -- an e-Factura that will not build over a partner missing its county, say -- the refund is refused instead, with the reason, because a proforma reverses nothing. An e-Factura that builds but cannot reach the SPV is a different matter: the credit note is real, the refund goes through, and the upload is retried from the back office. The cash leaves the till once: the POS payment behind a payment disposal is kept out of the session's cash flow and out of its closing entry, because the statement line already carries it.
Code Analysis ⓘ
Views touched (1)
| XML ID | Name | Model | Type | Status |
|---|---|---|---|---|
view_pos_pos_form_l10n_ro_refund |
pos.order.form.l10n.ro.refund | pos.order | form | Inherits point_of_sale.view_pos_pos_form |
HTTP endpoints (0)
No HTTP endpoints found for this module.
Models touched (4)
New fields (1)
-
l10n_ro_payment_disposal_idMany2one → account.bank.statement.linecopy=Falsehelp='Cash statement line paying the customer back for this refund. It is the payment disposal handed over at the till.'readonly=Truestring='Romania - Payment Disposal' args: 'account.bank.statement.line'
-
action_l10n_ro_print_payment_disposal(self) -
l10n_ro_get_payment_disposal_report(self)Report action for the payment disposal, or False when there is none. Called from the Point of Sale, which prints it right after the credit note so the customer signs for the cash before leaving the till.
New fields (1)
-
l10n_ro_payment_disposal_idMany2one → account.bank.statement.linecopy=Falsehelp='Cash statement line that paid this refund out of the till.'readonly=Truestring='Romania - Payment Disposal' args: 'account.bank.statement.line'
No public methods.
New fields (0)
No new fields.
Public methods (1)-
get_closing_control_data(self)
New fields (0)
No new fields.
Public methods (0)No public methods.