4.3 KiB
4.3 KiB
Proforma Series Contract
Objetivo
Normalizar el contrato publico de proformas para separar definitivamente la serie propia de la proforma de la serie futura de la factura emitida.
Semantica correcta
En proformas:
document_series_ididentifica la serie documental propia de la proformaproforma_numberguarda el numero propio de la proformaproforma_referenceguarda la referencia visible de la proforma, por ejemploPF-0139proforma_series_codees el codigo funcional que se usa solo en create para elegir una serie dedocument_type = proformatarget_invoice_series_codeidentifica la serie futura que se usara al emitir unaissued_invoice, por ejemploF26
target_invoice_series_code nunca debe apuntar implicitamente a la serie documental de proforma. Un valor como PF solo seria valido si existiera tambien una serie activa PF de document_type = issued_invoice, lo cual no debe asumirse.
Reglas funcionales
Crear proforma
- se pide fecha
- se pide cliente
proforma_series_codees opcional; si falta, se usa la serie default activa dedocument_type = proformatarget_invoice_series_codees opcional; si falta, se persisteNULL- la creacion de proforma genera una cabecera valida aunque no existan lineas
itemspuede omitirse o enviarse como[]- si no hay lineas valoradas, la response debe devolver
items = [],taxes = []y totales a0 tax_regime_codeen create representa configuracion fiscal inicial, no impuestos ya aplicados- la UI obtiene ambas listas desde
GET /document-series, filtrando pordocument_type
Editar draft
- se permiten cambios comerciales
- se permite cambiar
target_invoice_series_code - se permite cambiar
tax_config - no se permite cambiar
proforma_series_code,document_series_id,proforma_numberniproforma_reference - la UI hidrata la configuracion fiscal desde
tax_config, no desdetaxes
Editar approved
- la edicion queda restringida
- solo se permite ajustar
target_invoice_series_codeantes de emitir
Editar issued
- no se permite edicion funcional
Contrato actual
Requests
- create acepta
proforma_series_code - create acepta
target_invoice_series_code - create puede aceptar
tax_config - update acepta
target_invoice_series_code - update puede aceptar
tax_config - el flujo nuevo ya no necesita
series
Responses
- el backend emite
target_invoice_series_codecomo nombre preferente seriespuede mantenerse solo como alias legacy/deprecated de salida mientras existan consumidores antiguostaxesrepresenta impuestos calculados a partir de lineas valoradastax_configrepresenta la configuracion fiscal persistida de cabeceratotalsrepresenta importes calculados a partir de lineas valoradas- create no debe inventar filas fiscales sobre base
0
Regla de emision
- si
target_invoice_series_codetiene valor, la emision usa eseseriesCodeparadocument_type = issued_invoice - si
target_invoice_series_codeesNULL,document-seriesresuelve la serie default activa deissued_invoice - la UI nunca debe consumir numeracion directa desde
POST /document-series/assign-next - los impuestos y totales reales se recalculan cuando la proforma ya tiene lineas en update
Regla de borrado y numeracion
- borrar una proforma draft no libera ni reutiliza
proforma_reference - el siguiente alta consume el siguiente numero disponible de
document-series - no se decrementa
document_series.next_number - las proformas
rejectedno se borran; quedan para una futura operacion de archivado
Validacion defensiva
Si el request informa target_invoice_series_code:
- debe corresponder a una serie activa de
document_type = issued_invoice - no se permite volver a persistir series de
document_type = proformacomo target de factura
Si el request informa proforma_series_code:
- debe corresponder a una serie activa de
document_type = proforma - solo se usa para numerar la proforma en create
- despues queda congelado en
document_series_id,proforma_numberyproforma_reference
Retirada futura de series
seriesera ambiguo porque mezclaba dos conceptos distintos- el contrato correcto usa
proforma_series_codeytarget_invoice_series_code seriesdebe retirarse por completo cuando ya no queden consumidores legacy de responses