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

feat(sales): exponer API de lectura para Delivery Note #21

New Issue
Closed
opened 2026-03-19 13:44:52 +00:00 by leandro · 0 comments
leandro commented 2026-03-19 13:44:52 +00:00
Owner
Copy Link

Objetivo

Habilitar la capa API del módulo Delivery Note para consulta de remitos en modo solo lectura, reutilizando la lógica ya implementada en Core y Repository.

Contexto funcional

El módulo Delivery Note ya cuenta con soporte de lectura en las capas inferiores del sistema:

  • Repositorio: IPhSDeliveryNoteRepository / PhSDeliveryNoteRepository
  • Core: IDeliveryNoteDom / DeliveryNoteService

Actualmente Delivery Note no posee endpoints API propios.
Esta story busca abrir un contrato HTTP mínimo y atómico para lectura, manteniendo consistencia con los módulos existentes como Quotes y Expeditions.

La intención es habilitar consumo externo e interno del módulo sin incorporar todavía UI, generación de documentos, paginación ni lógica adicional de negocio.

Alcance

Esta story incluye únicamente:

  • creación del controller API del módulo Delivery Note
  • definición de endpoints GET mínimos:
    • obtener por id
    • obtener por deliveryNoteNumber
    • obtener por quoteId
  • consumo de IDeliveryNoteDom desde la capa API
  • definición del contrato de respuesta para lectura
  • manejo básico de respuestas HTTP (200, 404, y validaciones mínimas si correspondiera)

Capas involucradas:

  • API
  • eventualmente DTO de lectura si no existiera uno reutilizable

Fuera de alcance

Queda explícitamente fuera de esta story:

  • UI Blazor
  • PDF o impresión
  • creación, edición o eliminación de Delivery Note
  • paginación
  • filtros complejos o búsquedas múltiples
  • numeración
  • lógica de negocio adicional
  • integración avanzada con Quote
  • cambios en modelos EF generados por scaffold
  • refactor de repositorios o servicios ya implementados

Criterios de aceptación

  • Existe un DeliveryNoteController en la capa API
  • Se exponen tres endpoints GET:
    • por id
    • por deliveryNoteNumber
    • por quoteId
  • Los endpoints reutilizan IDeliveryNoteDom / DeliveryNoteService
  • Si el registro existe, la API devuelve 200 OK
  • Si el registro no existe, la API devuelve 404 Not Found
  • No se modifican modelos EF generados por scaffold
  • Se respeta la arquitectura Data → Domain → Core → API
  • El proyecto compila sin errores
  • La story no introduce lógica de escritura ni comportamiento extra

Decisiones de diseño

  • El controller se llamará DeliveryNoteController
  • La ruta base propuesta será /api/DeliveryNote, manteniendo consistencia con el estilo nominal del resto de los controladores del sistema
  • Para evitar ambigüedad entre identificadores numéricos y string, las rutas no basadas en PK usarán prefijos explícitos:
    • /by-number/{deliveryNoteNumber}
    • /by-quote/{quoteId}
  • Se prioriza exponer un DTO de lectura en lugar de devolver EDeliveryNote directamente, para desacoplar el contrato HTTP del modelo de dominio y evitar romper clientes ante cambios internos futuros
  • La story se mantiene deliberadamente pequeña y de solo lectura

Entregable esperado

Archivos esperables a crear o modificar:

  • API/Controllers/DeliveryNoteController.cs
  • archivo DTO de lectura, si se define uno nuevo
  • ajustes mínimos de DI o mapping, solo si fueran necesarios

Próxima Story sugerida (opcional)

feat(sales): agregar búsqueda/listado simple de Delivery Note en API o preparar consumo desde UI Blazor

## Objetivo Habilitar la capa API del módulo Delivery Note para consulta de remitos en modo solo lectura, reutilizando la lógica ya implementada en Core y Repository. ## Contexto funcional El módulo Delivery Note ya cuenta con soporte de lectura en las capas inferiores del sistema: - Repositorio: `IPhSDeliveryNoteRepository` / `PhSDeliveryNoteRepository` - Core: `IDeliveryNoteDom` / `DeliveryNoteService` Actualmente Delivery Note no posee endpoints API propios. Esta story busca abrir un contrato HTTP mínimo y atómico para lectura, manteniendo consistencia con los módulos existentes como Quotes y Expeditions. La intención es habilitar consumo externo e interno del módulo sin incorporar todavía UI, generación de documentos, paginación ni lógica adicional de negocio. ## Alcance Esta story incluye únicamente: - creación del controller API del módulo Delivery Note - definición de endpoints GET mínimos: - obtener por `id` - obtener por `deliveryNoteNumber` - obtener por `quoteId` - consumo de `IDeliveryNoteDom` desde la capa API - definición del contrato de respuesta para lectura - manejo básico de respuestas HTTP (`200`, `404`, y validaciones mínimas si correspondiera) Capas involucradas: - API - eventualmente DTO de lectura si no existiera uno reutilizable ## Fuera de alcance Queda explícitamente fuera de esta story: - UI Blazor - PDF o impresión - creación, edición o eliminación de Delivery Note - paginación - filtros complejos o búsquedas múltiples - numeración - lógica de negocio adicional - integración avanzada con Quote - cambios en modelos EF generados por scaffold - refactor de repositorios o servicios ya implementados ## Criterios de aceptación - Existe un `DeliveryNoteController` en la capa API - Se exponen tres endpoints GET: - por `id` - por `deliveryNoteNumber` - por `quoteId` - Los endpoints reutilizan `IDeliveryNoteDom` / `DeliveryNoteService` - Si el registro existe, la API devuelve `200 OK` - Si el registro no existe, la API devuelve `404 Not Found` - No se modifican modelos EF generados por scaffold - Se respeta la arquitectura Data → Domain → Core → API - El proyecto compila sin errores - La story no introduce lógica de escritura ni comportamiento extra ## Decisiones de diseño - El controller se llamará `DeliveryNoteController` - La ruta base propuesta será `/api/DeliveryNote`, manteniendo consistencia con el estilo nominal del resto de los controladores del sistema - Para evitar ambigüedad entre identificadores numéricos y string, las rutas no basadas en PK usarán prefijos explícitos: - `/by-number/{deliveryNoteNumber}` - `/by-quote/{quoteId}` - Se prioriza exponer un DTO de lectura en lugar de devolver `EDeliveryNote` directamente, para desacoplar el contrato HTTP del modelo de dominio y evitar romper clientes ante cambios internos futuros - La story se mantiene deliberadamente pequeña y de solo lectura ## Entregable esperado Archivos esperables a crear o modificar: - `API/Controllers/DeliveryNoteController.cs` - archivo DTO de lectura, si se define uno nuevo - ajustes mínimos de DI o mapping, solo si fueran necesarios ## Próxima Story sugerida (opcional) feat(sales): agregar búsqueda/listado simple de Delivery Note en API o preparar consumo desde UI Blazor
leandro added the
STORY
 label 2026-03-19 13:45:09 +00:00
leandro added this to the Sales (Ventas, Facturación y Remitos) milestone 2026-03-19 13:45:13 +00:00
leandro added this to the phronCare: Tablero DEV project 2026-03-19 13:45:18 +00:00
leandro self-assigned this 2026-03-19 13:45:21 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:40 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:42 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:45 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:47 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:49 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:51 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:52 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-24 20:24:05 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-24 20:24:07 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-25 13:27:46 +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#21
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?