Sales Document Refinement — Invoice Candidate from Delivery Notes #68

New Issue

leandro · 2026-06-04T16:16:52Z

leandro commented

2026-06-04 16:16:52 +00:00

Objetivo

Refinar el flujo de creación de Sales Document para que el documento comercial facturable se genere desde Delivery Notes emitidos, permitiendo agrupar uno o varios remitos de un mismo cliente fiscal y conservando precios aprobados y snapshot clínico/comercial.

Contexto funcional

PhronCare ya contiene persistencia, Domain contracts, DTOs, Core flow, repositories, mappings Domain ↔ EF, endpoints API oficiales y Backoffice UI funcional para Sales Documents.

La operación real validada para ortopedias y financiadores queda consolidada como:

Quote aprobado
        ↓
Delivery Note emitido
        ↓
Sales Document facturable
        ↓
Sales Fiscal Document futuro
        ↓
ARCA / AFIP futuro

Sales Document no representa todavía un comprobante fiscal. Representa un documento comercial preparado para facturación futura.

Coverage se define funcionalmente como la entidad financiadora/pagadora responsable: Obra Social, Prepaga, ART, Particular, Convenio o Cápita. Coverage no es paciente, hospital ni médico.

Alcance

Esta story incluye:

Crear Sales Document desde Delivery Notes emitidos.
Permitir asociación 1 Sales Document → N Delivery Notes.
Validar que todos los Delivery Notes seleccionados pertenezcan al mismo cliente fiscal.
Reutilizar PhSDeliveryNote.SalesinvoiceId para marcar remitos asociados al Sales Document creado.
Copiar líneas desde los detalles del remito.
Copiar precios aprobados desde el QuoteDetail relacionado.
Mantener snapshot comercial por línea mediante OriginSnapshotJson.
Mantener snapshot agrupado de operaciones en ExtraInfoJson del Sales Document.
Agregar endpoint para buscar candidatos de remitos emitidos pendientes de facturación.
Agregar endpoint para crear Sales Document desde remitos.
Reemplazar la pantalla create manual de Backoffice por un flujo simple de selección de remitos.

Capas involucradas:

Domain → Core → Models/Repositories → API → UI Blazor

No se requieren cambios SQL porque se reutiliza el campo existente SalesinvoiceId en Delivery Notes.

Fuera de alcance

No forma parte de esta story:

Integración AFIP / ARCA.
WSAA.
CAE / CAEA.
QR fiscal.
Numeración fiscal definitiva.
Punto de venta.
Letra fiscal A/B/C.
Tipo de comprobante fiscal definitivo.
Notas de crédito fiscales.
Percepciones.
Impuestos fiscales avanzados.
Autorización electrónica.
PDF fiscal.
Modificación manual de modelos EF scaffolded.
Cambios de base de datos.

Criterios de aceptación

✔ Sales Document se crea desde Delivery Notes emitidos.

✔ Se permite agrupar múltiples Delivery Notes.

✔ Se valida cliente fiscal único en Core, API y UI.

✔ Se impide facturar remitos ya asociados a un Sales Document.

✔ Se copian líneas del remito correctamente.

✔ Se conservan precios aprobados desde QuoteDetail.

✔ Se conserva snapshot comercial por línea.

✔ Se conserva snapshot agrupado de operaciones.

✔ No se modifica ningún modelo EF scaffolded.

✔ No se rompe el flujo existente de Delivery Notes.

✔ No se rompe el endpoint create anterior de Sales Document.

✔ El patch aplica limpio con:

git apply --check story68.patch

Decisiones de diseño

Sales Document como documento comercial

Sales Document queda definido como documento comercial facturable, previo a cualquier emisión fiscal. No se introducen conceptos fiscales definitivos todavía.

Cliente fiscal

Para esta story se usa DeliveryNote.CustomerId como cliente fiscal/facturable efectivo. Es la opción conservadora compatible con el modelo actual porque Delivery Note no posee todavía un BillToCustomerId separado.

Agrupación de remitos

Se permite agrupar varios Delivery Notes en un único Sales Document solo si todos comparten el mismo CustomerId.

Asociación con remitos

Se reutiliza PhSDeliveryNote.SalesinvoiceId para asociar los remitos al Sales Document creado. No se crea una tabla intermedia en esta story.

Precios aprobados

Los importes se toman desde QuoteDetail.Approvedunitprice y QuoteDetail.Approvedamount. Si falta Approvedamount, se calcula conservadoramente desde precio aprobado/unitario y cantidad del remito. No se recalculan precios comerciales ni se actualizan automáticamente.

Snapshot clínico/comercial

Cada línea conserva snapshot de origen con remito, presupuesto, cliente y ExtraInfoJson del remito. El encabezado conserva un snapshot agrupado con la lista de operaciones asociadas. En facturación agrupada no se fuerza una única cabecera clínica.

Impacto futuro fiscal documentado

Una futura Story Fiscal Foundation deberá introducir formalmente:

Punto de Venta
Tipo Comprobante
Letra Fiscal
Número Fiscal
Fecha Fiscal
CAE

Estos datos deberán pertenecer al documento fiscal futuro, no al Sales Document comercial base.

Entregable esperado

Archivos creados:

Domain/Dtos/Sales/SalesDocumentCreateFromDeliveryNotesRequest.cs
Domain/Dtos/Sales/SalesDocumentDeliveryNoteCandidateDto.cs
Domain/Dtos/Sales/SalesDocumentDeliveryNoteOperationSnapshotDto.cs

Archivos modificados:

Core/Interfaces/ISalesDocumentDom.cs
Core/Services/SalesDocumentService.cs
Domain/Dtos/Sales/DeliveryNoteItemDto.cs
Models/Interfaces/IPhSSalesDocumentRepository.cs
Models/Repositories/PhSDeliveryNoteRepository.cs
Models/Repositories/PhSSalesDocumentRepository.cs
phronCare.API/Controllers/Sales/SalesDocumentController.cs
phronCare.UIBlazor/Pages/Sales/SalesDocuments/SalesDocumentCreate.razor
phronCare.UIBlazor/Services/Sales/SalesDocuments/ISalesDocumentService.cs
phronCare.UIBlazor/Services/Sales/SalesDocuments/SalesDocumentService.cs

Branch sugerido:

feature/sales/68-sales-document-refinement

Commit sugerido:

feat(sales): refine sales document creation from delivery notes close #68

## Objetivo Refinar el flujo de creación de Sales Document para que el documento comercial facturable se genere desde Delivery Notes emitidos, permitiendo agrupar uno o varios remitos de un mismo cliente fiscal y conservando precios aprobados y snapshot clínico/comercial. --- ## Contexto funcional PhronCare ya contiene persistencia, Domain contracts, DTOs, Core flow, repositories, mappings Domain ↔ EF, endpoints API oficiales y Backoffice UI funcional para Sales Documents. La operación real validada para ortopedias y financiadores queda consolidada como: ```text Quote aprobado ↓ Delivery Note emitido ↓ Sales Document facturable ↓ Sales Fiscal Document futuro ↓ ARCA / AFIP futuro ``` Sales Document no representa todavía un comprobante fiscal. Representa un documento comercial preparado para facturación futura. Coverage se define funcionalmente como la entidad financiadora/pagadora responsable: Obra Social, Prepaga, ART, Particular, Convenio o Cápita. Coverage no es paciente, hospital ni médico. --- ## Alcance Esta story incluye: - Crear Sales Document desde Delivery Notes emitidos. - Permitir asociación 1 Sales Document → N Delivery Notes. - Validar que todos los Delivery Notes seleccionados pertenezcan al mismo cliente fiscal. - Reutilizar `PhSDeliveryNote.SalesinvoiceId` para marcar remitos asociados al Sales Document creado. - Copiar líneas desde los detalles del remito. - Copiar precios aprobados desde el QuoteDetail relacionado. - Mantener snapshot comercial por línea mediante `OriginSnapshotJson`. - Mantener snapshot agrupado de operaciones en `ExtraInfoJson` del Sales Document. - Agregar endpoint para buscar candidatos de remitos emitidos pendientes de facturación. - Agregar endpoint para crear Sales Document desde remitos. - Reemplazar la pantalla create manual de Backoffice por un flujo simple de selección de remitos. Capas involucradas: ```text Domain → Core → Models/Repositories → API → UI Blazor ``` No se requieren cambios SQL porque se reutiliza el campo existente `SalesinvoiceId` en Delivery Notes. --- ## Fuera de alcance No forma parte de esta story: - Integración AFIP / ARCA. - WSAA. - CAE / CAEA. - QR fiscal. - Numeración fiscal definitiva. - Punto de venta. - Letra fiscal A/B/C. - Tipo de comprobante fiscal definitivo. - Notas de crédito fiscales. - Percepciones. - Impuestos fiscales avanzados. - Autorización electrónica. - PDF fiscal. - Modificación manual de modelos EF scaffolded. - Cambios de base de datos. --- ## Criterios de aceptación ✔ Sales Document se crea desde Delivery Notes emitidos. ✔ Se permite agrupar múltiples Delivery Notes. ✔ Se valida cliente fiscal único en Core, API y UI. ✔ Se impide facturar remitos ya asociados a un Sales Document. ✔ Se copian líneas del remito correctamente. ✔ Se conservan precios aprobados desde QuoteDetail. ✔ Se conserva snapshot comercial por línea. ✔ Se conserva snapshot agrupado de operaciones. ✔ No se modifica ningún modelo EF scaffolded. ✔ No se rompe el flujo existente de Delivery Notes. ✔ No se rompe el endpoint create anterior de Sales Document. ✔ El patch aplica limpio con: ```bash git apply --check story68.patch ``` --- ## Decisiones de diseño ### Sales Document como documento comercial Sales Document queda definido como documento comercial facturable, previo a cualquier emisión fiscal. No se introducen conceptos fiscales definitivos todavía. ### Cliente fiscal Para esta story se usa `DeliveryNote.CustomerId` como cliente fiscal/facturable efectivo. Es la opción conservadora compatible con el modelo actual porque Delivery Note no posee todavía un `BillToCustomerId` separado. ### Agrupación de remitos Se permite agrupar varios Delivery Notes en un único Sales Document solo si todos comparten el mismo `CustomerId`. ### Asociación con remitos Se reutiliza `PhSDeliveryNote.SalesinvoiceId` para asociar los remitos al Sales Document creado. No se crea una tabla intermedia en esta story. ### Precios aprobados Los importes se toman desde `QuoteDetail.Approvedunitprice` y `QuoteDetail.Approvedamount`. Si falta `Approvedamount`, se calcula conservadoramente desde precio aprobado/unitario y cantidad del remito. No se recalculan precios comerciales ni se actualizan automáticamente. ### Snapshot clínico/comercial Cada línea conserva snapshot de origen con remito, presupuesto, cliente y `ExtraInfoJson` del remito. El encabezado conserva un snapshot agrupado con la lista de operaciones asociadas. En facturación agrupada no se fuerza una única cabecera clínica. ### Impacto futuro fiscal documentado Una futura Story Fiscal Foundation deberá introducir formalmente: ```text Punto de Venta Tipo Comprobante Letra Fiscal Número Fiscal Fecha Fiscal CAE ``` Estos datos deberán pertenecer al documento fiscal futuro, no al Sales Document comercial base. --- ## Entregable esperado Archivos creados: ```text Domain/Dtos/Sales/SalesDocumentCreateFromDeliveryNotesRequest.cs Domain/Dtos/Sales/SalesDocumentDeliveryNoteCandidateDto.cs Domain/Dtos/Sales/SalesDocumentDeliveryNoteOperationSnapshotDto.cs ``` Archivos modificados: ```text Core/Interfaces/ISalesDocumentDom.cs Core/Services/SalesDocumentService.cs Domain/Dtos/Sales/DeliveryNoteItemDto.cs Models/Interfaces/IPhSSalesDocumentRepository.cs Models/Repositories/PhSDeliveryNoteRepository.cs Models/Repositories/PhSSalesDocumentRepository.cs phronCare.API/Controllers/Sales/SalesDocumentController.cs phronCare.UIBlazor/Pages/Sales/SalesDocuments/SalesDocumentCreate.razor phronCare.UIBlazor/Services/Sales/SalesDocuments/ISalesDocumentService.cs phronCare.UIBlazor/Services/Sales/SalesDocuments/SalesDocumentService.cs ``` Branch sugerido: ```text feature/sales/68-sales-document-refinement ``` Commit sugerido: ```text feat(sales): refine sales document creation from delivery notes close #68 ```

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: leandro/phronCare#68