odoo/enterprise#77206

Created by Misc, Joren Van Onder (jov)
Merged at e8a16a108aba27c76e9a98cd4a8d50f0ac3bcc67

Statuses:

Linked pull requests
label
odoo-dev:18.0-l10n-br-edi-pos-task-3564171-jov
head
e6f79bf5782bf08b9720f08811664b02a51d5b15
merged
8 months ago by Accounting, Antoine Dupuis (andu)
odoo/odoo odoo/enterprise
18.0 #193834 #77206
saas-18.1 #201790 #81469
saas-18.2 #202616 #81796
saas-18.3
saas-18.4
19.0
master #203199 #82039

[ADD] l10n_br_edi_pos: Brazilian EDI in the POS with Avatax

This module implements issueing NFC-e receipts through the POS. The process is conceptually similar to what we do for invoices. First taxes are calculated, and then we e-invoice.

The calculated taxes will never change the order total. NFC-e mandates taxes to always be included in the price so we don't need any additional RPC call before payment.

One way of achieving this was through l10n_br_edi, forcing every pos.order to be invoiced and then following the implemented flows on account.move. We decided against it because:

  • It leads to a large amount of mostly unnecessary invoices,
  • It's conceptually strange to the user, NFC-e "invoices" resemble POS receipts more than they do invoices,
  • The flow in the POS is simpler, we handle tax calculation and EDI in one atomic step.

We therefore chose to re-implement EDI for pos.order. The downside of this approach is that we temporarily need to copy some code from l10n_br_edi. In master this code can be consolidated in a common mixin.

The integration tries to never block POS sales. You're allowed to retry EDI later. When EDI fails, the POS user is informed and we fall back to the standard receipt (marked as a "receipt without fiscal value").

For refunds we still go through account.move, as NFC-e doesn't support refunds (must be NF-e, which is what we already support for account.move).

task-3564171