feat(sales): Core Flow para Sales Document con Coverage #60

Closed
opened 2026-05-07 04:23:25 +00:00 by leandro · 0 comments
Owner

Objetivo

Implementar el flujo base de Core para documentos comerciales de venta, asegurando que todo Sales Document persista Details y Coverage de forma obligatoria.

Contexto funcional

La Story #57 dejó preparado el contrato de Domain para Sales Document: entidades, DTOs, enums/constants y contratos conceptuales de Coverage.

Esta story continúa el módulo Sales y agrega la primera implementación operativa de Core/Data para crear y consultar documentos comerciales internos, sin avanzar todavía sobre API, UI ni homologación ARCA.

El modelo funcional mantiene la separación:

SalesDocument
 ├── Details   → lo facturado
 └── Coverage  → lo cubierto

Coverage queda como fuente de verdad para determinar qué presupuesto/caso quedó cubierto, incluso cuando el escenario sea simple:

1 documento → 1 cliente → 1 presupuesto/caso

Alcance

Incluye:

  • Crear contrato de Core ISalesDocumentService.
  • Crear implementación SalesDocumentService.
  • Crear contrato de repositorio IPhSSalesDocumentRepository.
  • Crear implementación PhSSalesDocumentRepository.
  • Implementar persistencia de ESalesDocument hacia PhSSalesDocument mediante EntityMapper.
  • Implementar lectura DTO de Sales Document con Details, Coverage y FiscalDocument opcional.
  • Implementar búsqueda paginada básica por cliente, cliente facturado, quote, tipo, estado y fecha.
  • Validar creación mínima del documento comercial.
  • Persistir siempre Coverage.

Archivos agregados:

Core/Interfaces/ISalesDocumentService.cs
Core/Services/SalesDocumentService.cs
Models/Interfaces/IPhSSalesDocumentRepository.cs
Models/Repositories/PhSSalesDocumentRepository.cs

Fuera de alcance

No incluye:

  • Endpoints API.
  • UI Blazor.
  • Generación de PDF.
  • Exportación Excel.
  • Numeración interna definitiva por PhS_FormSeries.
  • Emisión fiscal real.
  • Integración ARCA/AFIP.
  • Reintentos fiscales.
  • Reconciliación fiscal.
  • Modificación manual de modelos EF scaffold.

Criterios de aceptación

✔ Existe un servicio Core SalesDocumentService con contrato propio.
✔ Existe repositorio PhSSalesDocumentRepository.
✔ La creación valida Customer, BillToCustomer, Currency, Details, Coverage y totales.
✔ Coverage es obligatorio y siempre se persiste.
✔ Details representa lo facturado.
✔ Coverage representa lo cubierto.
quote_id se mantiene como referencia opcional, no como dependencia del flujo.
✔ El patch no modifica modelos EF generados por scaffold.
✔ El patch aplica correctamente con git apply --check.
✔ No se agregan endpoints ni cambios de UI.

Decisiones de diseño

  • SalesDocument.Status se inicializa como Draft porque esta story no emite ni homologa fiscalmente.
  • Los totales del documento se calculan desde Details para evitar confiar en importes de encabezado enviados desde capas superiores.
  • Coverage no se deriva automáticamente de quote_id; se exige explícitamente en el request.
  • quote_id continúa siendo opcional para ventas manuales, escritorio, cápita o escenarios futuros.
  • La persistencia usa EntityMapper, manteniendo el patrón existente del repositorio de Delivery Note.
  • La consulta detallada devuelve Details y Coverage juntos, pero mantiene semánticas separadas.
  • El documento fiscal se lee como opcional para quedar preparado para múltiples intentos/estados fiscales futuros, sin implementar ARCA en esta story.

Entregable esperado

Entregables generados:

phroncare-story-59-sales-document-core-coverage.md
phroncare-story-59-sales-document-core-coverage.patch

Branch sugerido:

feature/leandro/59-sales-document-core-coverage

Commit sugerido:

feat(core): add sales document core flow with coverage

closes #59

Checklist de pruebas

git apply --check phroncare-story-59-sales-document-core-coverage.patch
git apply phroncare-story-59-sales-document-core-coverage.patch
dotnet build phronCare.sln

Nota: en el entorno de generación del patch se validó git apply --check. El build debe correrse localmente porque el entorno no tiene instalado el SDK dotnet.

## Objetivo Implementar el flujo base de Core para documentos comerciales de venta, asegurando que todo Sales Document persista Details y Coverage de forma obligatoria. ## Contexto funcional La Story #57 dejó preparado el contrato de Domain para Sales Document: entidades, DTOs, enums/constants y contratos conceptuales de Coverage. Esta story continúa el módulo Sales y agrega la primera implementación operativa de Core/Data para crear y consultar documentos comerciales internos, sin avanzar todavía sobre API, UI ni homologación ARCA. El modelo funcional mantiene la separación: ```text SalesDocument ├── Details → lo facturado └── Coverage → lo cubierto ``` Coverage queda como fuente de verdad para determinar qué presupuesto/caso quedó cubierto, incluso cuando el escenario sea simple: ```text 1 documento → 1 cliente → 1 presupuesto/caso ``` ## Alcance Incluye: - Crear contrato de Core `ISalesDocumentService`. - Crear implementación `SalesDocumentService`. - Crear contrato de repositorio `IPhSSalesDocumentRepository`. - Crear implementación `PhSSalesDocumentRepository`. - Implementar persistencia de `ESalesDocument` hacia `PhSSalesDocument` mediante `EntityMapper`. - Implementar lectura DTO de Sales Document con Details, Coverage y FiscalDocument opcional. - Implementar búsqueda paginada básica por cliente, cliente facturado, quote, tipo, estado y fecha. - Validar creación mínima del documento comercial. - Persistir siempre Coverage. Archivos agregados: ```text Core/Interfaces/ISalesDocumentService.cs Core/Services/SalesDocumentService.cs Models/Interfaces/IPhSSalesDocumentRepository.cs Models/Repositories/PhSSalesDocumentRepository.cs ``` ## Fuera de alcance No incluye: - Endpoints API. - UI Blazor. - Generación de PDF. - Exportación Excel. - Numeración interna definitiva por `PhS_FormSeries`. - Emisión fiscal real. - Integración ARCA/AFIP. - Reintentos fiscales. - Reconciliación fiscal. - Modificación manual de modelos EF scaffold. ## Criterios de aceptación ✔ Existe un servicio Core `SalesDocumentService` con contrato propio. ✔ Existe repositorio `PhSSalesDocumentRepository`. ✔ La creación valida Customer, BillToCustomer, Currency, Details, Coverage y totales. ✔ Coverage es obligatorio y siempre se persiste. ✔ Details representa lo facturado. ✔ Coverage representa lo cubierto. ✔ `quote_id` se mantiene como referencia opcional, no como dependencia del flujo. ✔ El patch no modifica modelos EF generados por scaffold. ✔ El patch aplica correctamente con `git apply --check`. ✔ No se agregan endpoints ni cambios de UI. ## Decisiones de diseño - `SalesDocument.Status` se inicializa como `Draft` porque esta story no emite ni homologa fiscalmente. - Los totales del documento se calculan desde Details para evitar confiar en importes de encabezado enviados desde capas superiores. - Coverage no se deriva automáticamente de `quote_id`; se exige explícitamente en el request. - `quote_id` continúa siendo opcional para ventas manuales, escritorio, cápita o escenarios futuros. - La persistencia usa `EntityMapper`, manteniendo el patrón existente del repositorio de Delivery Note. - La consulta detallada devuelve Details y Coverage juntos, pero mantiene semánticas separadas. - El documento fiscal se lee como opcional para quedar preparado para múltiples intentos/estados fiscales futuros, sin implementar ARCA en esta story. ## Entregable esperado Entregables generados: ```text phroncare-story-59-sales-document-core-coverage.md phroncare-story-59-sales-document-core-coverage.patch ``` Branch sugerido: ```text feature/leandro/59-sales-document-core-coverage ``` Commit sugerido: ```text feat(core): add sales document core flow with coverage closes #59 ``` ## Checklist de pruebas ```bash git apply --check phroncare-story-59-sales-document-core-coverage.patch git apply phroncare-story-59-sales-document-core-coverage.patch dotnet build phronCare.sln ``` Nota: en el entorno de generación del patch se validó `git apply --check`. El build debe correrse localmente porque el entorno no tiene instalado el SDK `dotnet`.
leandro added this to the Sales (Ventas, Facturación y Remitos) milestone 2026-05-07 04:23:25 +00:00
leandro added the
STORY
label 2026-05-07 04:23:25 +00:00
leandro self-assigned this 2026-05-07 04:23:25 +00:00
leandro added this to the phronCare: Tablero DEV project 2026-05-07 04:23:25 +00:00
leandro changed title from Core Flow para Sales Document con Coverage to feat(sales): Core Flow para Sales Document con Coverage 2026-05-07 04:23:49 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leandro/phronCare#60
No description provided.