feat (sales): Normalización de OriginType con Enum en Sales Document #62

New Issue

leandro · 2026-05-08T02:54:32Z

leandro commented

2026-05-08 02:54:32 +00:00

Objetivo

Normalizar el manejo de OriginType en Sales Document usando un enum de negocio y persistencia semántica, eliminando ints mágicos en el flujo Core/Domain.

Contexto funcional

La Story #60 dejó aplicado el flujo Core de Sales Document con persistencia de Coverage, DTOs Create/Summary/Detail, repositories, mappings Domain ↔ EF y validaciones mínimas.

Durante la revisión se detectó que OriginType todavía estaba modelado como int en el request de detalle y luego se persistía con x.OriginType.ToString(). Ese comportamiento guardaba valores como "1", "2" o "3", en lugar de códigos de negocio legibles y auditables como "QUOTE", "DELIVERY_NOTE", "CAPITA", "MANUAL" o "ADJUSTMENT".

Esta story pertenece al módulo Sales y prepara el modelo para trazabilidad, auditoría, cobertura mixta y futura homologación ARCA, sin implementar todavía emisión fiscal.

Alcance

Incluye:

Revisar el enum existente SalesDocumentOriginType.
Extender el enum con DeliveryNote para contemplar origen por remito de venta.
Cambiar SalesDocumentCreateDetailRequest.OriginType de int a SalesDocumentOriginType.
Agregar una extensión de conversión explícita a códigos persistibles.
Persistir OriginType como código semántico, no como número.
Agregar validaciones mínimas de detalle en Core:
- número de línea válido,
- OriginType válido,
- descripción obligatoria,
- cantidad mayor a cero,
- consistencia básica entre OriginType, OriginId y QuoteDetailId.
Resolver OriginId / QuoteDetailId para líneas originadas en presupuesto cuando uno de los dos venga informado.
Actualizar comentario Domain de ESalesDocumentDetail.OriginType para documentar los códigos esperados.

Archivos modificados o creados:

Domain/Constants/SalesDocumentOriginType.cs
Domain/Constants/SalesDocumentOriginTypeExtensions.cs
Domain/Dtos/Sales/SalesDocumentCreateDetailRequest.cs
Domain/Entities/ESalesDocumentDetail.cs
Core/Services/SalesDocumentService.cs

Fuera de alcance

No incluye:

cambios en modelos EF generados por scaffold,
cambios SQL,
endpoints API nuevos,
UI Blazor,
emisión fiscal,
integración AFIP/ARCA,
asociaciones fiscales automáticas,
cambio de contratos de Coverage fuera de lo necesario para trazabilidad del detalle.

Criterios de aceptación

✔ OriginType deja de ser int crudo en SalesDocumentCreateDetailRequest.
✔ El Core valida que OriginType sea un valor definido del enum.
✔ El Core persiste códigos semánticos como QUOTE, DELIVERY_NOTE, CAPITA, MANUAL o ADJUSTMENT.
✔ No se persisten valores como "1", "2" o "3".
✔ No se modifican modelos EF generados por scaffold.
✔ No se modifica la estructura SQL.
✔ El patch aplica correctamente con git apply --check.
✔ El cambio queda acotado a Domain/Core, manteniendo la arquitectura Data → Domain → Core → API → UI.

Decisiones de diseño

Se conserva el enum existente SalesDocumentOriginType para respetar convenciones actuales del repo.
Se agregan códigos de persistencia mediante SalesDocumentOriginTypeExtensions.ToStorageCode() en lugar de usar ToString() directamente.
Se conserva el valor numérico existente de los miembros ya definidos para reducir riesgo de incompatibilidad con código interno que pudiera enviar valores numéricos.
Se agrega DeliveryNote como origen posible para preparar el flujo futuro de facturación desde remitos.
OriginType representa de dónde viene la línea.
OriginId representa cuál es el registro origen.
QuoteDetailId mantiene trazabilidad granular cuando la línea viene de un detalle de presupuesto.
Coverage sigue siendo la fuente de verdad para saber qué presupuestos/casos quedan cubiertos por el documento comercial.
Details guarda la línea comercial facturable y su origen para auditoría, reintentos fiscales y relaciones futuras entre documentos.
Esta normalización deja el modelo preparado para futura homologación ARCA sin acoplar todavía comprobantes fiscales.

Entregable esperado

Story en formato .md descargable.
Patch .patch descargable.
Patch validado con:

git apply --check story-62-normalize-sales-document-origin-type.patch

Resultado de validación:

CHECK_OK

Build local no ejecutado en este entorno porque no está disponible el SDK dotnet en el contenedor de análisis.

Branch sugerido

feature/leandro/62-normalize-sales-document-origin-type

Commit sugerido

feat(core): normalize sales document origin types

closes #62

## Objetivo Normalizar el manejo de `OriginType` en Sales Document usando un enum de negocio y persistencia semántica, eliminando ints mágicos en el flujo Core/Domain. --- ## Contexto funcional La Story #60 dejó aplicado el flujo Core de Sales Document con persistencia de Coverage, DTOs Create/Summary/Detail, repositories, mappings Domain ↔ EF y validaciones mínimas. Durante la revisión se detectó que `OriginType` todavía estaba modelado como `int` en el request de detalle y luego se persistía con `x.OriginType.ToString()`. Ese comportamiento guardaba valores como `"1"`, `"2"` o `"3"`, en lugar de códigos de negocio legibles y auditables como `"QUOTE"`, `"DELIVERY_NOTE"`, `"CAPITA"`, `"MANUAL"` o `"ADJUSTMENT"`. Esta story pertenece al módulo Sales y prepara el modelo para trazabilidad, auditoría, cobertura mixta y futura homologación ARCA, sin implementar todavía emisión fiscal. --- ## Alcance Incluye: - Revisar el enum existente `SalesDocumentOriginType`. - Extender el enum con `DeliveryNote` para contemplar origen por remito de venta. - Cambiar `SalesDocumentCreateDetailRequest.OriginType` de `int` a `SalesDocumentOriginType`. - Agregar una extensión de conversión explícita a códigos persistibles. - Persistir `OriginType` como código semántico, no como número. - Agregar validaciones mínimas de detalle en Core: - número de línea válido, - `OriginType` válido, - descripción obligatoria, - cantidad mayor a cero, - consistencia básica entre `OriginType`, `OriginId` y `QuoteDetailId`. - Resolver `OriginId` / `QuoteDetailId` para líneas originadas en presupuesto cuando uno de los dos venga informado. - Actualizar comentario Domain de `ESalesDocumentDetail.OriginType` para documentar los códigos esperados. Archivos modificados o creados: - `Domain/Constants/SalesDocumentOriginType.cs` - `Domain/Constants/SalesDocumentOriginTypeExtensions.cs` - `Domain/Dtos/Sales/SalesDocumentCreateDetailRequest.cs` - `Domain/Entities/ESalesDocumentDetail.cs` - `Core/Services/SalesDocumentService.cs` --- ## Fuera de alcance No incluye: - cambios en modelos EF generados por scaffold, - cambios SQL, - endpoints API nuevos, - UI Blazor, - emisión fiscal, - integración AFIP/ARCA, - asociaciones fiscales automáticas, - cambio de contratos de Coverage fuera de lo necesario para trazabilidad del detalle. --- ## Criterios de aceptación ✔ `OriginType` deja de ser `int` crudo en `SalesDocumentCreateDetailRequest`. ✔ El Core valida que `OriginType` sea un valor definido del enum. ✔ El Core persiste códigos semánticos como `QUOTE`, `DELIVERY_NOTE`, `CAPITA`, `MANUAL` o `ADJUSTMENT`. ✔ No se persisten valores como `"1"`, `"2"` o `"3"`. ✔ No se modifican modelos EF generados por scaffold. ✔ No se modifica la estructura SQL. ✔ El patch aplica correctamente con `git apply --check`. ✔ El cambio queda acotado a Domain/Core, manteniendo la arquitectura Data → Domain → Core → API → UI. --- ## Decisiones de diseño - Se conserva el enum existente `SalesDocumentOriginType` para respetar convenciones actuales del repo. - Se agregan códigos de persistencia mediante `SalesDocumentOriginTypeExtensions.ToStorageCode()` en lugar de usar `ToString()` directamente. - Se conserva el valor numérico existente de los miembros ya definidos para reducir riesgo de incompatibilidad con código interno que pudiera enviar valores numéricos. - Se agrega `DeliveryNote` como origen posible para preparar el flujo futuro de facturación desde remitos. - `OriginType` representa de dónde viene la línea. - `OriginId` representa cuál es el registro origen. - `QuoteDetailId` mantiene trazabilidad granular cuando la línea viene de un detalle de presupuesto. - Coverage sigue siendo la fuente de verdad para saber qué presupuestos/casos quedan cubiertos por el documento comercial. - Details guarda la línea comercial facturable y su origen para auditoría, reintentos fiscales y relaciones futuras entre documentos. - Esta normalización deja el modelo preparado para futura homologación ARCA sin acoplar todavía comprobantes fiscales. --- ## Entregable esperado - Story en formato `.md` descargable. - Patch `.patch` descargable. - Patch validado con: ```bash git apply --check story-62-normalize-sales-document-origin-type.patch ``` Resultado de validación: ```text CHECK_OK ``` Build local no ejecutado en este entorno porque no está disponible el SDK `dotnet` en el contenedor de análisis. --- ## Branch sugerido ```text feature/leandro/62-normalize-sales-document-origin-type ``` --- ## Commit sugerido ```text feat(core): normalize sales document origin types closes #62 ```

leandro referenced this issue from a commit

2026-05-08 03:15:16 +00:00

feat(core): normalize sales document origin types

leandro referenced a pull request that will close this issue

2026-05-08 03:15:50 +00:00

feat(core): normalize sales document origin types #63

leandro closed this issue

2026-05-08 03:16:03 +00:00

leandro added the

STORY

label 2026-05-08 03:16:26 +00:00

leandro added this to the Sales (Ventas, Facturación y Remitos) milestone 2026-05-08 03:16:31 +00:00