leandro/phronCare
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

feat(sales): Domain Contracts para Sales Document con Coverage #57

New Issue
Closed
opened 2026-04-30 20:48:24 +00:00 by leandro · 0 comments
leandro commented 2026-04-30 20:48:24 +00:00
Owner
Copy Link

Objetivo

Definir los contratos de la capa Domain para el nuevo módulo de documentos comerciales de venta, incorporando explícitamente el concepto de Coverage como fuente de verdad de lo cubierto por cada documento.

La story debe preparar el terreno para las próximas capas sin implementar todavía repositorios, servicios Core, endpoints API, UI ni homologación ARCA.

Contexto funcional

El proyecto PhronCare usa arquitectura estricta:

Data → Domain → Core → API → UI (Blazor)

La Story #55 (Data) dejó creadas y scaffolded las tablas base del módulo de facturación comercial interna:

PhS_SalesDocuments
PhS_SalesDocumentDetails
PhS_SalesFiscalDocuments
PhS_SalesFiscalDocumentAssociations
PhS_SalesDocumentCoverage

Decisiones funcionales ya tomadas:

SalesDocumentDetails = lo facturado
SalesDocumentCoverage = lo cubierto
quote_id = referencia, no lógica principal

Esto permite representar correctamente:

  • facturación 1 a 1;
  • facturación por cápita;
  • facturación mixta entre obra social y particular;
  • facturación parcial, por ejemplo 60/40;
  • trazabilidad entre documento comercial, líneas facturadas y presupuestos/casos cubiertos.

El repositorio actual ya contiene patrones similares en Domain:

  • entidades Domain con prefijo E, por ejemplo EDeliveryNote, EQuoteHeader, EQuoteDetail;
  • DTOs por módulo bajo Domain/Dtos, con Domain/Dtos/Sales para ventas;
  • enums bajo Domain/Constants;
  • separación entre modelos EF generados en Models/Models y contratos Domain propios.

Esta story existe para crear los contratos limpios de Domain antes de avanzar con Core/Data/API/UI.

Alcance

Crear los contratos Domain necesarios para Sales Document.

1. Entities

Crear entidades Domain en Domain/Entities:

ESalesDocument
ESalesDocumentDetail
ESalesFiscalDocument
ESalesFiscalDocumentAssociation
ESalesDocumentCoverage

Lineamientos:

  • usar prefijo E, consistente con el resto de Domain;
  • reflejar los campos relevantes de las tablas scaffolded sin depender directamente de los modelos EF;
  • mantener nombres compatibles con el mapping actual por convención siempre que sea posible;
  • incluir colecciones de navegación Domain donde aporten claridad contractual;
  • no incorporar lógica de negocio pesada dentro de las entidades.

Relación esperada:

ESalesDocument
 ├── PhSSalesDocumentDetails / Details
 ├── PhSSalesDocumentCoverages / Coverage
 └── PhSSalesFiscalDocument / FiscalDocument

La implementación concreta del nombre de las colecciones debe priorizar compatibilidad con los patrones actuales de EntityMapper y las entidades existentes.

2. Enums

Crear enums en Domain/Constants usando tipo base int:

SalesDocumentType
SalesDocumentStatus
SalesFiscalDocumentStatus
SalesDocumentOriginType
SalesDocumentCoverageType

Valores sugeridos iniciales:

SalesDocumentType

Invoice = 1
DebitNote = 2
CreditNote = 3
CreditInvoice = 4
CreditDebitNote = 5
CreditCreditNote = 6

SalesDocumentStatus

Draft = 1
Validated = 2
Issued = 3
Cancelled = 4

SalesFiscalDocumentStatus

None = 0
Pending = 1
Authorized = 2
Rejected = 3
Error = 4
PendingReconciliation = 5

SalesDocumentOriginType

Manual = 1
QuoteDetail = 2
Adjustment = 3
Capita = 4

Nota: aunque PhS_SalesDocumentDetails.OriginType está scaffolded como string, el contrato Domain debe definir el enum int como referencia semántica interna. En la próxima story se deberá decidir si Core/Data persiste el nombre, el valor o realiza conversión explícita.

SalesDocumentCoverageType

Direct = 1
Capita = 2
Adjustment = 3
Partial = 4

3. DTOs

Crear DTOs en Domain/Dtos/Sales.

Create

SalesDocumentCreateRequest
SalesDocumentCreateDetailRequest
SalesDocumentCreateCoverageRequest
SalesDocumentCreateResponse

Debe permitir crear un documento con:

  • cabecera comercial;
  • detalles facturados;
  • coverage obligatorio;
  • datos fiscales previstos, pero sin ejecutar ARCA.

Detail / lectura completa

SalesDocumentDto
SalesDocumentDetailDto
SalesDocumentCoverageDto
SalesFiscalDocumentDto
SalesFiscalDocumentAssociationDto

Debe representar el documento completo para lectura interna/API futura.

Summary

SalesDocumentSummaryDto

Debe servir para listados, búsquedas y grillas sin cargar todo el detalle.

Fiscal

Los DTOs fiscales deben quedar separados conceptualmente del documento comercial:

SalesFiscalDocumentDto
SalesFiscalDocumentAssociationDto

La separación es obligatoria porque el documento comercial interno puede existir sin estar autorizado fiscalmente.

Coverage

SalesDocumentCoverageDto y SalesDocumentCreateCoverageRequest deben ser contratos explícitos, no un dato derivado implícito desde QuoteId.

Campos mínimos esperados:

Id
SalesDocumentId
SalesDocumentDetailId?
QuoteId
QuoteDetailId?
CoverageType
CoveragePercentage?
CoverageAmount?
PeriodFrom?
PeriodTo?
Notes?

Fuera de alcance

Esta story NO incluye:

  • modificar modelos EF generados por scaffold en Models/Models;
  • modificar PhronCareOperationsHubContext;
  • crear o modificar tablas SQL;
  • ejecutar scaffold;
  • implementar repositorios Data;
  • implementar servicios Core;
  • implementar validaciones de negocio completas;
  • implementar endpoints API;
  • implementar pantallas Blazor;
  • generar PDFs, Excel o documentos fiscales;
  • integrar ARCA/AFIP;
  • consumir WSAA/wsfev1;
  • asignar CAE;
  • resolver numeración fiscal real;
  • reconciliación post-timeout;
  • idempotencia fiscal.

Criterios de aceptación

✔ El proyecto Domain compila sin errores.
✔ No se modifica ningún modelo EF generado por scaffold.
✔ Las entidades Domain usan prefijo E.
✔ Los enums quedan en Domain/Constants.
✔ Los enums solicitados usan tipo base int.
✔ Los DTOs quedan agrupados en Domain/Dtos/Sales.
✔ Coverage queda modelado como contrato explícito.
✔ Coverage no depende de quote_id como lógica principal.
✔ El diseño permite facturación 1 a 1 usando Coverage.
✔ El diseño permite cápita usando Coverage.
✔ El diseño permite facturación parcial, por ejemplo 60/40.
✔ El documento comercial queda separado del documento fiscal.
✔ La capa Domain queda preparada para una futura integración ARCA sin implementarla todavía.
✔ El patch futuro debe poder validarse con git apply --check antes de aplicarse.

Decisiones de diseño

1. Coverage es obligatorio conceptualmente

Toda creación futura de Sales Document debe incluir coverage, incluso en facturación directa 1 a 1.

Motivo:

SalesDocumentCoverage es la fuente real para determinar qué presupuesto/caso quedó cubierto.

QuoteId en cabecera puede existir como referencia útil, pero no debe ser usado como fuente de verdad para determinar cobertura o pendiente de facturación.

2. Separación entre lo facturado y lo cubierto

El contrato debe dejar clara la separación:

SalesDocumentDetails = líneas valorizadas que aparecen en el documento
SalesDocumentCoverage = presupuestos/casos cubiertos por esas líneas

Esto evita forzar una relación 1 a 1 entre línea facturada y presupuesto.

Ejemplos soportados:

  • una factura directa puede tener una línea y una coverage 100%;
  • una factura por cápita puede tener una línea agregada mensual y muchas coverages;
  • una factura mixta puede cubrir parcialmente un presupuesto con obra social y dejar otra parte para particular;
  • un documento puede cubrir 60% de un caso y otro documento cubrir el 40% restante.

3. Documento comercial separado del documento fiscal

ESalesDocument representa el documento comercial interno.

ESalesFiscalDocument representa el estado fiscal asociado, preparado para ARCA/AFIP.

Motivo:

  • PhronCare puede emitir, validar o anular documentos internos;
  • ARCA puede autorizar, rechazar o dejar pendiente reconciliación;
  • ambos ciclos de vida no deben mezclarse.

4. Preparación ARCA sin implementación

La story puede incluir contratos con campos fiscales previstos:

FiscalVoucherType
FiscalVoucherLetter
PointOfSale
VoucherType
VoucherNumber
CAE
CAEExpirationDate
RequestFingerprint
ArcaRequestPayloadJson
ArcaResponsePayloadJson
ErrorsJson
EventsJson
ObservationsJson
ReconciledAfterTimeout

Pero no debe implementar:

  • WSAA;
  • FECAESolicitar;
  • CAE;
  • idempotencia real;
  • reconciliación real.

5. Enums int alineados con DB

Los enums nuevos deben usar int para quedar alineados con columnas int ya scaffolded.

Excepción a revisar en próxima story:

PhS_SalesDocumentDetails.OriginType = string

Para esta story se define SalesDocumentOriginType : int como contrato semántico. La conversión concreta queda para Core/Data.

6. No sobreingeniería

Domain debe contener contratos, no resolver todavía reglas complejas de emisión, cálculo fiscal o validación de coverage.

La validación fuerte debe quedar para Core en stories posteriores.

Diseño propuesto de relaciones

SalesDocument
 ├── Details
 │    └── representan lo facturado / valorizado
 │
 ├── Coverage
 │    └── representa lo cubierto / fuente de verdad funcional
 │
 └── FiscalDocument
      └── representa estado y trazabilidad fiscal futura

Relación conceptual recomendada:

ESalesDocument
 ├── ICollection<ESalesDocumentDetail>
 ├── ICollection<ESalesDocumentCoverage>
 └── ESalesFiscalDocument?

ESalesDocumentCoverage debe poder apuntar opcionalmente a una línea:

SalesDocumentDetailId?

Motivo:

  • en facturación directa puede apuntar a la línea concreta;
  • en cápita puede apuntar a una línea agregada;
  • en escenarios complejos puede existir cobertura trazable sin forzar granularidad por ítem.

Entregable esperado

Archivos a crear o modificar en una futura implementación:

Domain/Entities/ESalesDocument.cs
Domain/Entities/ESalesDocumentDetail.cs
Domain/Entities/ESalesFiscalDocument.cs
Domain/Entities/ESalesFiscalDocumentAssociation.cs
Domain/Entities/ESalesDocumentCoverage.cs

Domain/Constants/SalesDocumentType.cs
Domain/Constants/SalesDocumentStatus.cs
Domain/Constants/SalesFiscalDocumentStatus.cs
Domain/Constants/SalesDocumentOriginType.cs
Domain/Constants/SalesDocumentCoverageType.cs

Domain/Dtos/Sales/SalesDocumentCreateRequest.cs
Domain/Dtos/Sales/SalesDocumentCreateDetailRequest.cs
Domain/Dtos/Sales/SalesDocumentCreateCoverageRequest.cs
Domain/Dtos/Sales/SalesDocumentCreateResponse.cs
Domain/Dtos/Sales/SalesDocumentDto.cs
Domain/Dtos/Sales/SalesDocumentDetailDto.cs
Domain/Dtos/Sales/SalesDocumentSummaryDto.cs
Domain/Dtos/Sales/SalesDocumentCoverageDto.cs
Domain/Dtos/Sales/SalesFiscalDocumentDto.cs
Domain/Dtos/Sales/SalesFiscalDocumentAssociationDto.cs

No se esperan cambios en:

Models/Models/*
Models/Models/PhronCareOperationsHubContext.cs
Core/*
phronCare.API/*
phronCare.UIBlazor/*
Database/*

Plan de implementación de abajo hacia arriba

1. Data / Models

No modificar.

Validar solamente que las clases scaffolded existen:

PhSSalesDocument
PhSSalesDocumentDetail
PhSSalesFiscalDocument
PhSSalesFiscalDocumentAssociation
PhSSalesDocumentCoverage

2. Domain / Constants

Crear enums int para tipos y estados comerciales/fiscales.

3. Domain / Entities

Crear entidades E* reflejando los contratos de cabecera, detalle, fiscal, asociaciones fiscales y coverage.

4. Domain / DTOs

Crear DTOs de create, lectura completa, summary, fiscal y coverage bajo Domain/Dtos/Sales.

5. Core

Fuera de alcance en esta story.

La próxima story debería definir interfaces y servicios Core para crear/listar/consultar Sales Documents usando coverage obligatorio.

6. API

Fuera de alcance.

7. UI

Fuera de alcance.

Branch sugerido

feature/leandro/57-sales-document-domain-contracts-coverage

Commit sugerido

feat(domain): add sales document domain contracts with coverage

closes #57

Checklist técnico previo al patch

Antes de generar el patch de implementación:

1. Confirmar que el ZIP fuente es la última versión del repo.
2. Confirmar que no hay cambios pendientes no relacionados.
3. Crear archivos nuevos solamente en Domain/Entities, Domain/Constants y Domain/Dtos/Sales.
4. No tocar Models/Models ni PhronCareOperationsHubContext.
5. Ejecutar dotnet build.
6. Generar patch.
7. Validar con git apply --check.
## Objetivo Definir los contratos de la capa **Domain** para el nuevo módulo de documentos comerciales de venta, incorporando explícitamente el concepto de **Coverage** como fuente de verdad de lo cubierto por cada documento. La story debe preparar el terreno para las próximas capas sin implementar todavía repositorios, servicios Core, endpoints API, UI ni homologación ARCA. --- ## Contexto funcional El proyecto **PhronCare** usa arquitectura estricta: ```text Data → Domain → Core → API → UI (Blazor) ``` La **Story #55 (Data)** dejó creadas y scaffolded las tablas base del módulo de facturación comercial interna: ```text PhS_SalesDocuments PhS_SalesDocumentDetails PhS_SalesFiscalDocuments PhS_SalesFiscalDocumentAssociations PhS_SalesDocumentCoverage ``` Decisiones funcionales ya tomadas: ```text SalesDocumentDetails = lo facturado SalesDocumentCoverage = lo cubierto quote_id = referencia, no lógica principal ``` Esto permite representar correctamente: - facturación 1 a 1; - facturación por cápita; - facturación mixta entre obra social y particular; - facturación parcial, por ejemplo 60/40; - trazabilidad entre documento comercial, líneas facturadas y presupuestos/casos cubiertos. El repositorio actual ya contiene patrones similares en `Domain`: - entidades Domain con prefijo `E`, por ejemplo `EDeliveryNote`, `EQuoteHeader`, `EQuoteDetail`; - DTOs por módulo bajo `Domain/Dtos`, con `Domain/Dtos/Sales` para ventas; - enums bajo `Domain/Constants`; - separación entre modelos EF generados en `Models/Models` y contratos Domain propios. Esta story existe para crear los contratos limpios de Domain antes de avanzar con Core/Data/API/UI. --- ## Alcance Crear los contratos Domain necesarios para Sales Document. ### 1. Entities Crear entidades Domain en `Domain/Entities`: ```text ESalesDocument ESalesDocumentDetail ESalesFiscalDocument ESalesFiscalDocumentAssociation ESalesDocumentCoverage ``` Lineamientos: - usar prefijo `E`, consistente con el resto de Domain; - reflejar los campos relevantes de las tablas scaffolded sin depender directamente de los modelos EF; - mantener nombres compatibles con el mapping actual por convención siempre que sea posible; - incluir colecciones de navegación Domain donde aporten claridad contractual; - no incorporar lógica de negocio pesada dentro de las entidades. Relación esperada: ```text ESalesDocument ├── PhSSalesDocumentDetails / Details ├── PhSSalesDocumentCoverages / Coverage └── PhSSalesFiscalDocument / FiscalDocument ``` La implementación concreta del nombre de las colecciones debe priorizar compatibilidad con los patrones actuales de `EntityMapper` y las entidades existentes. ### 2. Enums Crear enums en `Domain/Constants` usando tipo base `int`: ```text SalesDocumentType SalesDocumentStatus SalesFiscalDocumentStatus SalesDocumentOriginType SalesDocumentCoverageType ``` Valores sugeridos iniciales: #### SalesDocumentType ```text Invoice = 1 DebitNote = 2 CreditNote = 3 CreditInvoice = 4 CreditDebitNote = 5 CreditCreditNote = 6 ``` #### SalesDocumentStatus ```text Draft = 1 Validated = 2 Issued = 3 Cancelled = 4 ``` #### SalesFiscalDocumentStatus ```text None = 0 Pending = 1 Authorized = 2 Rejected = 3 Error = 4 PendingReconciliation = 5 ``` #### SalesDocumentOriginType ```text Manual = 1 QuoteDetail = 2 Adjustment = 3 Capita = 4 ``` Nota: aunque `PhS_SalesDocumentDetails.OriginType` está scaffolded como `string`, el contrato Domain debe definir el enum `int` como referencia semántica interna. En la próxima story se deberá decidir si Core/Data persiste el nombre, el valor o realiza conversión explícita. #### SalesDocumentCoverageType ```text Direct = 1 Capita = 2 Adjustment = 3 Partial = 4 ``` ### 3. DTOs Crear DTOs en `Domain/Dtos/Sales`. #### Create ```text SalesDocumentCreateRequest SalesDocumentCreateDetailRequest SalesDocumentCreateCoverageRequest SalesDocumentCreateResponse ``` Debe permitir crear un documento con: - cabecera comercial; - detalles facturados; - coverage obligatorio; - datos fiscales previstos, pero sin ejecutar ARCA. #### Detail / lectura completa ```text SalesDocumentDto SalesDocumentDetailDto SalesDocumentCoverageDto SalesFiscalDocumentDto SalesFiscalDocumentAssociationDto ``` Debe representar el documento completo para lectura interna/API futura. #### Summary ```text SalesDocumentSummaryDto ``` Debe servir para listados, búsquedas y grillas sin cargar todo el detalle. #### Fiscal Los DTOs fiscales deben quedar separados conceptualmente del documento comercial: ```text SalesFiscalDocumentDto SalesFiscalDocumentAssociationDto ``` La separación es obligatoria porque el documento comercial interno puede existir sin estar autorizado fiscalmente. #### Coverage `SalesDocumentCoverageDto` y `SalesDocumentCreateCoverageRequest` deben ser contratos explícitos, no un dato derivado implícito desde `QuoteId`. Campos mínimos esperados: ```text Id SalesDocumentId SalesDocumentDetailId? QuoteId QuoteDetailId? CoverageType CoveragePercentage? CoverageAmount? PeriodFrom? PeriodTo? Notes? ``` --- ## Fuera de alcance Esta story NO incluye: - modificar modelos EF generados por scaffold en `Models/Models`; - modificar `PhronCareOperationsHubContext`; - crear o modificar tablas SQL; - ejecutar scaffold; - implementar repositorios Data; - implementar servicios Core; - implementar validaciones de negocio completas; - implementar endpoints API; - implementar pantallas Blazor; - generar PDFs, Excel o documentos fiscales; - integrar ARCA/AFIP; - consumir WSAA/wsfev1; - asignar CAE; - resolver numeración fiscal real; - reconciliación post-timeout; - idempotencia fiscal. --- ## Criterios de aceptación ✔ El proyecto `Domain` compila sin errores. ✔ No se modifica ningún modelo EF generado por scaffold. ✔ Las entidades Domain usan prefijo `E`. ✔ Los enums quedan en `Domain/Constants`. ✔ Los enums solicitados usan tipo base `int`. ✔ Los DTOs quedan agrupados en `Domain/Dtos/Sales`. ✔ `Coverage` queda modelado como contrato explícito. ✔ `Coverage` no depende de `quote_id` como lógica principal. ✔ El diseño permite facturación 1 a 1 usando Coverage. ✔ El diseño permite cápita usando Coverage. ✔ El diseño permite facturación parcial, por ejemplo 60/40. ✔ El documento comercial queda separado del documento fiscal. ✔ La capa Domain queda preparada para una futura integración ARCA sin implementarla todavía. ✔ El patch futuro debe poder validarse con `git apply --check` antes de aplicarse. --- ## Decisiones de diseño ### 1. Coverage es obligatorio conceptualmente Toda creación futura de Sales Document debe incluir coverage, incluso en facturación directa 1 a 1. Motivo: ```text SalesDocumentCoverage es la fuente real para determinar qué presupuesto/caso quedó cubierto. ``` `QuoteId` en cabecera puede existir como referencia útil, pero no debe ser usado como fuente de verdad para determinar cobertura o pendiente de facturación. ### 2. Separación entre lo facturado y lo cubierto El contrato debe dejar clara la separación: ```text SalesDocumentDetails = líneas valorizadas que aparecen en el documento SalesDocumentCoverage = presupuestos/casos cubiertos por esas líneas ``` Esto evita forzar una relación 1 a 1 entre línea facturada y presupuesto. Ejemplos soportados: - una factura directa puede tener una línea y una coverage 100%; - una factura por cápita puede tener una línea agregada mensual y muchas coverages; - una factura mixta puede cubrir parcialmente un presupuesto con obra social y dejar otra parte para particular; - un documento puede cubrir 60% de un caso y otro documento cubrir el 40% restante. ### 3. Documento comercial separado del documento fiscal `ESalesDocument` representa el documento comercial interno. `ESalesFiscalDocument` representa el estado fiscal asociado, preparado para ARCA/AFIP. Motivo: - PhronCare puede emitir, validar o anular documentos internos; - ARCA puede autorizar, rechazar o dejar pendiente reconciliación; - ambos ciclos de vida no deben mezclarse. ### 4. Preparación ARCA sin implementación La story puede incluir contratos con campos fiscales previstos: ```text FiscalVoucherType FiscalVoucherLetter PointOfSale VoucherType VoucherNumber CAE CAEExpirationDate RequestFingerprint ArcaRequestPayloadJson ArcaResponsePayloadJson ErrorsJson EventsJson ObservationsJson ReconciledAfterTimeout ``` Pero no debe implementar: - WSAA; - FECAESolicitar; - CAE; - idempotencia real; - reconciliación real. ### 5. Enums int alineados con DB Los enums nuevos deben usar `int` para quedar alineados con columnas `int` ya scaffolded. Excepción a revisar en próxima story: ```text PhS_SalesDocumentDetails.OriginType = string ``` Para esta story se define `SalesDocumentOriginType : int` como contrato semántico. La conversión concreta queda para Core/Data. ### 6. No sobreingeniería Domain debe contener contratos, no resolver todavía reglas complejas de emisión, cálculo fiscal o validación de coverage. La validación fuerte debe quedar para Core en stories posteriores. --- ## Diseño propuesto de relaciones ```text SalesDocument ├── Details │ └── representan lo facturado / valorizado │ ├── Coverage │ └── representa lo cubierto / fuente de verdad funcional │ └── FiscalDocument └── representa estado y trazabilidad fiscal futura ``` Relación conceptual recomendada: ```text ESalesDocument ├── ICollection<ESalesDocumentDetail> ├── ICollection<ESalesDocumentCoverage> └── ESalesFiscalDocument? ``` `ESalesDocumentCoverage` debe poder apuntar opcionalmente a una línea: ```text SalesDocumentDetailId? ``` Motivo: - en facturación directa puede apuntar a la línea concreta; - en cápita puede apuntar a una línea agregada; - en escenarios complejos puede existir cobertura trazable sin forzar granularidad por ítem. --- ## Entregable esperado Archivos a crear o modificar en una futura implementación: ```text Domain/Entities/ESalesDocument.cs Domain/Entities/ESalesDocumentDetail.cs Domain/Entities/ESalesFiscalDocument.cs Domain/Entities/ESalesFiscalDocumentAssociation.cs Domain/Entities/ESalesDocumentCoverage.cs Domain/Constants/SalesDocumentType.cs Domain/Constants/SalesDocumentStatus.cs Domain/Constants/SalesFiscalDocumentStatus.cs Domain/Constants/SalesDocumentOriginType.cs Domain/Constants/SalesDocumentCoverageType.cs Domain/Dtos/Sales/SalesDocumentCreateRequest.cs Domain/Dtos/Sales/SalesDocumentCreateDetailRequest.cs Domain/Dtos/Sales/SalesDocumentCreateCoverageRequest.cs Domain/Dtos/Sales/SalesDocumentCreateResponse.cs Domain/Dtos/Sales/SalesDocumentDto.cs Domain/Dtos/Sales/SalesDocumentDetailDto.cs Domain/Dtos/Sales/SalesDocumentSummaryDto.cs Domain/Dtos/Sales/SalesDocumentCoverageDto.cs Domain/Dtos/Sales/SalesFiscalDocumentDto.cs Domain/Dtos/Sales/SalesFiscalDocumentAssociationDto.cs ``` No se esperan cambios en: ```text Models/Models/* Models/Models/PhronCareOperationsHubContext.cs Core/* phronCare.API/* phronCare.UIBlazor/* Database/* ``` --- ## Plan de implementación de abajo hacia arriba ### 1. Data / Models No modificar. Validar solamente que las clases scaffolded existen: ```text PhSSalesDocument PhSSalesDocumentDetail PhSSalesFiscalDocument PhSSalesFiscalDocumentAssociation PhSSalesDocumentCoverage ``` ### 2. Domain / Constants Crear enums `int` para tipos y estados comerciales/fiscales. ### 3. Domain / Entities Crear entidades `E*` reflejando los contratos de cabecera, detalle, fiscal, asociaciones fiscales y coverage. ### 4. Domain / DTOs Crear DTOs de create, lectura completa, summary, fiscal y coverage bajo `Domain/Dtos/Sales`. ### 5. Core Fuera de alcance en esta story. La próxima story debería definir interfaces y servicios Core para crear/listar/consultar Sales Documents usando coverage obligatorio. ### 6. API Fuera de alcance. ### 7. UI Fuera de alcance. --- ## Branch sugerido ```text feature/leandro/57-sales-document-domain-contracts-coverage ``` --- ## Commit sugerido ```text feat(domain): add sales document domain contracts with coverage closes #57 ``` --- ## Checklist técnico previo al patch Antes de generar el patch de implementación: ```text 1. Confirmar que el ZIP fuente es la última versión del repo. 2. Confirmar que no hay cambios pendientes no relacionados. 3. Crear archivos nuevos solamente en Domain/Entities, Domain/Constants y Domain/Dtos/Sales. 4. No tocar Models/Models ni PhronCareOperationsHubContext. 5. Ejecutar dotnet build. 6. Generar patch. 7. Validar con git apply --check. ```
leandro added the
STORY
 label 2026-04-30 20:48:32 +00:00
leandro added this to the Sales (Ventas, Facturación y Remitos) milestone 2026-04-30 20:48:37 +00:00
leandro added this to the phronCare: Tablero DEV project 2026-04-30 20:48:40 +00:00
leandro self-assigned this 2026-04-30 20:48:45 +00:00
leandro changed title from feat(sales): Sales Document Domain Contracts to feat(sales): Domain Contracts para Sales Document con Coverage 2026-05-03 14:53:18 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
STORY
bug
infra
refactor
tech-debt
No Label
STORY
Milestone
No items
No Milestone Sales (Ventas, Facturación y Remitos)
Projects
Clear projects
No project phronCare: Tablero DEV
Assignees
Clear assignees
No Assignees leandro
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leandro/phronCare#57
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?