PAC Purchase Order Number (DGI <dNroPed>)¶

Date: 2026-06-27

Problem / motivation¶

The DGI factura electrónica supports a "Pedido Comercial global" group whose purchaseOrder field (DGI <dNroPed>) records the purchase/commercial order number for the document. Cifras was not sending it. When an invoice originates from an order, that order's number is the natural purchase order to report.

In scope¶

Model the Alanube global group on the PAC invoice payload with a single purchaseOrder field.
On the create-from-invoice PAC path, populate it with the linked order's number when the invoice has one; omit the group entirely otherwise.

Out of scope¶

The acceptances and delivery members of the Alanube global group — only purchaseOrder is sent.
A manually editable purchase order field on the invoice. The value is derived from the order.

Data model changes¶

None. The purchase order is derived from the linked order at PAC-submission time; no new column or migration.

What's being implemented¶

PAC model: new PedidoComercialGlobal (just purchaseOrder, 1–50 chars) and the optional PacInvoice.commercial_order field serialized as global in pac_general_model.py.
PAC factory: optional purchase_order parameter that builds the global group only when present in pac_invoice_factory.py.
PAC service: derive the order number from invoice.order_id and pass it to the factory in invoice_pac_service.py.
Tests: test_commercial_order.py.

PAC payload¶

When the invoice has an order, the payload gains:

"global": { "purchaseOrder": "<order_number>" }

When the invoice has no order, the global key is omitted.

Frontend contract¶

None. This is server-derived from the existing order ⇄ invoice relationship and is reflected only in the PAC document/payload.

What shipped¶

Everything in scope above. task all is green and the PAC unit tests pass.

Future additions¶

Surface acceptances (Números de Aceptación) if/when the business needs to report acceptance numbers. Deferred: not currently used.