Expose Sales Document Application API Endpoints #64

New Issue

leandro · 2026-06-03T11:48:03Z

leandro commented

2026-06-03 11:48:03 +00:00

Objetivo

Exponer oficialmente el módulo Sales Document desde la capa API de PhronCare, permitiendo crear, consultar detalle y listar documentos comerciales internos de venta mediante endpoints consumibles desde Swagger y futuras pantallas UI.

Contexto funcional

El módulo Sales Document ya cuenta con persistencia, contratos Domain, DTOs, enums, Coverage, repositories, mappings Domain ↔ EF y flujo Core funcional.

Las stories previas dejaron implementada la base de datos y el flujo de aplicación, pero todavía faltaba cerrar la capa:

API

Esta story publica el Core existente sin incorporar UI, workflow fiscal, impresión ni exportación.

Alcance

Incluye los siguientes cambios:

Crear SalesDocumentController en la estructura real de controllers de ventas.
Exponer POST /api/SalesDocument para crear un Sales Document usando SalesDocumentCreateRequest.
Exponer GET /api/SalesDocument/{id} para obtener el detalle completo usando SalesDocumentDto.
Exponer GET /api/SalesDocument/search para browse paginado usando PagedResult<SalesDocumentSummaryDto>.
Agregar búsqueda mínima en ISalesDocumentDom y IPhSSalesDocumentRepository.
Implementar búsqueda paginada en PhSSalesDocumentRepository con filtros simples compatibles con patrones existentes.
Registrar DI de ISalesDocumentDom, SalesDocumentService, IPhSSalesDocumentRepository y PhSSalesDocumentRepository en Program.cs.
Mantener DTOs públicos existentes sin refactorización masiva.
Mantener OriginType compatible con storage legacy: enum en request create, string storage code en persisted detail DTO.

Endpoints incorporados:

POST /api/SalesDocument
GET  /api/SalesDocument/{id}
GET  /api/SalesDocument/search

Filtros mínimos del browse:

customerId
customerText
quoteId
documentType
status
issueDateFrom
issueDateTo
page
pageSize

Fuera de alcance

No incluye:

UI Blazor.
Grillas o pantallas.
Edición.
Delete/cancelación.
Impresión.
Exportación Excel.
Validaciones complejas adicionales.
Workflow fiscal ARCA/AFIP.
Autenticación o roles.
AutoMapper.
Refactorización masiva de DTOs/enums.
Cambios SQL o scaffold.
Modificaciones manuales sobre modelos EF generados.

Criterios de aceptación

✔ El controller compila dentro de la estructura API existente.
✔ Swagger expone SalesDocumentController sin conflictos de schemas nuevos.
✔ POST /api/SalesDocument consume SalesDocumentCreateRequest y devuelve el documento creado.
✔ GET /api/SalesDocument/{id} devuelve cabecera, details y coverage.
✔ GET /api/SalesDocument/search devuelve PagedResult<SalesDocumentSummaryDto>.
✔ El browse aplica orden descendente por fecha de emisión e ID.
✔ DI queda registrado sin duplicar registros previos.
✔ No se modifican modelos EF generados por scaffold.
✔ Se preserva compatibilidad de OriginType con storage legacy.
✔ No se incorporan dependencias nuevas.
✔ No se rompe el flujo Core existente.

Decisiones de diseño

Se siguió el patrón existente de controllers de ventas: [Route("api/[controller]")], [ApiController], ActionResult<T>, try/catch y mensajes con MethodBase.
El endpoint create devuelve CreatedAtAction con SalesDocumentDto completo para facilitar consumo desde Swagger/UI.
El browse se implementó como GET search, alineado con QuoteController y DeliveryNoteController.
La paginación reutiliza PagedResult<T> ya existente.
Los filtros se mantuvieron mínimos para evitar inventar un contrato complejo antes de la UI.
La normalización de enums se mantuvo incremental: no se cambió el contrato público de DTOs ya existentes salvo el uso vigente de SalesDocumentOriginType en create detail.
No se modificaron modelos scaffolded ni configuración EF generada.

Entregable esperado

Archivos creados o modificados:

phronCare.API/Controllers/Sales/SalesDocumentController.cs
phronCare.API/Program.cs
Core/Interfaces/ISalesDocumentDom.cs
Core/Services/SalesDocumentService.cs
Models/Interfaces/IPhSSalesDocumentRepository.cs
Models/Repositories/PhSSalesDocumentRepository.cs
docs/stories/story-64-sales-document-api-endpoints.md

Patch esperado:

story64.patch

Branch sugerido:

feature/sales/64-sales-document-api-endpoints

Commit sugerido:

feat(api): expose sales document application endpoints close #64

## Objetivo Exponer oficialmente el módulo **Sales Document** desde la capa API de PhronCare, permitiendo crear, consultar detalle y listar documentos comerciales internos de venta mediante endpoints consumibles desde Swagger y futuras pantallas UI. ## Contexto funcional El módulo Sales Document ya cuenta con persistencia, contratos Domain, DTOs, enums, Coverage, repositories, mappings Domain ↔ EF y flujo Core funcional. Las stories previas dejaron implementada la base de datos y el flujo de aplicación, pero todavía faltaba cerrar la capa: ```text API ``` Esta story publica el Core existente sin incorporar UI, workflow fiscal, impresión ni exportación. ## Alcance Incluye los siguientes cambios: - Crear `SalesDocumentController` en la estructura real de controllers de ventas. - Exponer `POST /api/SalesDocument` para crear un Sales Document usando `SalesDocumentCreateRequest`. - Exponer `GET /api/SalesDocument/{id}` para obtener el detalle completo usando `SalesDocumentDto`. - Exponer `GET /api/SalesDocument/search` para browse paginado usando `PagedResult<SalesDocumentSummaryDto>`. - Agregar búsqueda mínima en `ISalesDocumentDom` y `IPhSSalesDocumentRepository`. - Implementar búsqueda paginada en `PhSSalesDocumentRepository` con filtros simples compatibles con patrones existentes. - Registrar DI de `ISalesDocumentDom`, `SalesDocumentService`, `IPhSSalesDocumentRepository` y `PhSSalesDocumentRepository` en `Program.cs`. - Mantener DTOs públicos existentes sin refactorización masiva. - Mantener `OriginType` compatible con storage legacy: enum en request create, string storage code en persisted detail DTO. Endpoints incorporados: ```http POST /api/SalesDocument GET /api/SalesDocument/{id} GET /api/SalesDocument/search ``` Filtros mínimos del browse: - `customerId` - `customerText` - `quoteId` - `documentType` - `status` - `issueDateFrom` - `issueDateTo` - `page` - `pageSize` ## Fuera de alcance No incluye: - UI Blazor. - Grillas o pantallas. - Edición. - Delete/cancelación. - Impresión. - Exportación Excel. - Validaciones complejas adicionales. - Workflow fiscal ARCA/AFIP. - Autenticación o roles. - AutoMapper. - Refactorización masiva de DTOs/enums. - Cambios SQL o scaffold. - Modificaciones manuales sobre modelos EF generados. ## Criterios de aceptación ✔ El controller compila dentro de la estructura API existente. ✔ Swagger expone `SalesDocumentController` sin conflictos de schemas nuevos. ✔ `POST /api/SalesDocument` consume `SalesDocumentCreateRequest` y devuelve el documento creado. ✔ `GET /api/SalesDocument/{id}` devuelve cabecera, details y coverage. ✔ `GET /api/SalesDocument/search` devuelve `PagedResult<SalesDocumentSummaryDto>`. ✔ El browse aplica orden descendente por fecha de emisión e ID. ✔ DI queda registrado sin duplicar registros previos. ✔ No se modifican modelos EF generados por scaffold. ✔ Se preserva compatibilidad de `OriginType` con storage legacy. ✔ No se incorporan dependencias nuevas. ✔ No se rompe el flujo Core existente. ## Decisiones de diseño - Se siguió el patrón existente de controllers de ventas: `[Route("api/[controller]")]`, `[ApiController]`, `ActionResult<T>`, `try/catch` y mensajes con `MethodBase`. - El endpoint create devuelve `CreatedAtAction` con `SalesDocumentDto` completo para facilitar consumo desde Swagger/UI. - El browse se implementó como `GET search`, alineado con `QuoteController` y `DeliveryNoteController`. - La paginación reutiliza `PagedResult<T>` ya existente. - Los filtros se mantuvieron mínimos para evitar inventar un contrato complejo antes de la UI. - La normalización de enums se mantuvo incremental: no se cambió el contrato público de DTOs ya existentes salvo el uso vigente de `SalesDocumentOriginType` en create detail. - No se modificaron modelos scaffolded ni configuración EF generada. ## Entregable esperado Archivos creados o modificados: ```text phronCare.API/Controllers/Sales/SalesDocumentController.cs phronCare.API/Program.cs Core/Interfaces/ISalesDocumentDom.cs Core/Services/SalesDocumentService.cs Models/Interfaces/IPhSSalesDocumentRepository.cs Models/Repositories/PhSSalesDocumentRepository.cs docs/stories/story-64-sales-document-api-endpoints.md ``` Patch esperado: ```text story64.patch ``` Branch sugerido: ```text feature/sales/64-sales-document-api-endpoints ``` Commit sugerido: ```text feat(api): expose sales document application endpoints close #64 ```

leandro referenced this issue from a commit

2026-06-03 12:01:09 +00:00

feat(api): expose sales document application endpoints

leandro referenced a pull request that will close this issue

2026-06-03 13:37:39 +00:00

feat(api): expose sales document application endpoints #65

leandro closed this issue

2026-06-03 13:39:36 +00:00

leandro referenced this issue

2026-06-03 18:15:32 +00:00

Sales Document Backoffice UI Foundation #66

Sign in to join this conversation.