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

Sales Document Backoffice UI Foundation #66

New Issue
Closed
opened 2026-06-03 18:15:32 +00:00 by leandro · 0 comments
leandro commented 2026-06-03 18:15:32 +00:00
Owner
Copy Link

Objetivo

Implementar la primera UI administrativa oficial para el módulo Sales Documents en el Backoffice Blazor, consumiendo los endpoints API ya publicados por Story #64.

El objetivo es cerrar la capa:

UI (Blazor)

sobre el flujo ya existente:

Data → Domain → Core → API

Contexto funcional

El proyecto PhronCare ya cuenta con el módulo Sales Document consolidado a nivel backend:

  • persistencia PhSSalesDocument, PhSSalesDocumentDetail, PhSSalesDocumentCoverage
  • entidades Domain ESalesDocument, ESalesDocumentDetail, ESalesDocumentCoverage
  • DTOs de create, summary y detail
  • enums de SalesDocumentType, SalesDocumentStatus, SalesDocumentOriginType y SalesDocumentCoverageType
  • repositorios y mappings Domain ↔ EF
  • SalesDocumentService funcional
  • endpoints API oficiales:
    • GET /api/SalesDocument/search
    • GET /api/SalesDocument/{id}
    • POST /api/SalesDocument
  • Swagger funcional

Las Stories #56, #58, #59, #61, #63 y #64 ya fueron aplicadas y mergeadas.

Esta story agrega la primera experiencia administrativa mínima para operar Sales Documents desde el Backoffice existente, manteniendo el enfoque incremental antes de avanzar hacia facturación fiscal.

Alcance

Esta story incluye exclusivamente cambios en la capa UI Blazor.

Navegación

  • Agregar entrada en el menú lateral existente dentro del grupo Ventas.
  • Nombre visible: Sales Documents.
  • Ruta principal: /salesdocuments.

Cliente UI/API

  • Crear servicio UI tipado para consumir la API existente:
    • ISalesDocumentService
    • SalesDocumentService
    • SalesDocumentSearchParams
  • Registrar el servicio en Program.cs siguiendo el patrón actual de DI del Backoffice.

Browse/List

  • Crear página /salesdocuments.
  • Consumir GET /api/SalesDocument/search.
  • Mostrar listado con tabla Bootstrap consistente con Quotes/DeliveryNotes.
  • Incluir loading, lista vacía y manejo básico de errores vía IToastService.
  • Incluir paginación simple reutilizando el patrón manual existente.
  • Mostrar columnas principales:
    • documento
    • fecha
    • cliente
    • cliente de facturación
    • presupuesto
    • document type
    • status
    • moneda
    • total
    • acción de detalle

Detail readonly

  • Crear página /salesdocuments/{id:int}.
  • Consumir GET /api/SalesDocument/{id}.
  • Mostrar cabecera readonly:
    • número interno / id
    • fecha
    • estado
    • document type
    • origen agregado desde líneas
    • total
  • Mostrar datos relacionados:
    • cliente
    • cliente de facturación
    • quote id
    • coverage
    • observaciones
  • Mostrar líneas de detalle:
    • línea
    • origin type
    • descripción
    • cantidad
    • precio unitario
    • neto
    • impuesto
    • total

Create mínimo

  • Crear página /salesdocuments/create.
  • Consumir POST /api/SalesDocument.
  • Permitir carga mínima de:
    • fecha
    • document type
    • moneda
    • cotización
    • cliente
    • cliente de facturación
    • quote id para coverage
    • coverage type
    • coverage percentage
    • período
    • observaciones
    • detalles básicos
  • Permitir agregar/remover detalles.
  • Calcular importes básicos en UI solo para construir el payload requerido por la API, sin incorporar reglas de negocio avanzadas.
  • Al crear correctamente, navegar al detalle readonly del documento creado.

Enums

  • Usar enums existentes del proyecto:
    • SalesDocumentType
    • SalesDocumentStatus
    • SalesDocumentOriginType
    • SalesDocumentCoverageType
  • Evitar ints mágicos en la UI.
  • Mostrar labels legibles sin cambiar la serialización ni los contratos API.

Archivos incluidos en el patch

  • phronCare.UIBlazor/Layout/NavMenu.razor
  • phronCare.UIBlazor/Program.cs
  • phronCare.UIBlazor/Services/Sales/SalesDocuments/ISalesDocumentService.cs
  • phronCare.UIBlazor/Services/Sales/SalesDocuments/SalesDocumentService.cs
  • phronCare.UIBlazor/Services/Sales/SalesDocuments/SalesDocumentSearchParams.cs
  • phronCare.UIBlazor/Pages/Sales/SalesDocuments/SalesDocuments.razor
  • phronCare.UIBlazor/Pages/Sales/SalesDocuments/SalesDocumentDetail.razor
  • phronCare.UIBlazor/Pages/Sales/SalesDocuments/SalesDocumentCreate.razor

Fuera de alcance

Esta story no incluye:

  • cambios en Data / Models scaffolded
  • cambios en Domain
  • cambios en Core
  • cambios en API
  • edición de Sales Documents
  • eliminación/anulación
  • workflows fiscales
  • AFIP/ARCA
  • CAE
  • autorización fiscal
  • impresión PDF
  • exportación Excel
  • auditoría avanzada
  • permisos/roles complejos
  • AutoMapper
  • refactorización masiva
  • dashboards
  • filtros avanzados
  • búsqueda compleja
  • componentes genéricos nuevos
  • virtualización avanzada

Criterios de aceptación

✔ El menú lateral muestra acceso a Sales Documents dentro de Ventas.

✔ La ruta /salesdocuments carga el browse/list.

✔ El browse consume GET /api/SalesDocument/search.

✔ El browse muestra loading, lista vacía, tabla y paginación básica.

✔ La acción de detalle navega a /salesdocuments/{id}.

✔ El detalle consume GET /api/SalesDocument/{id}.

✔ El detalle muestra cabecera, coverage y líneas readonly.

✔ La ruta /salesdocuments/create permite crear un documento mínimo.

✔ El create consume POST /api/SalesDocument.

✔ Al crear correctamente, la UI navega al detalle del documento creado.

✔ Los enums se manejan usando tipos existentes, no ints mágicos.

✔ No se modifica ningún modelo EF generado por scaffold.

✔ No se rompen contratos API existentes.

✔ El patch aplica limpio con:

git apply --check story66.patch

Decisiones de diseño

  • La story se limita a la capa UI porque API/Core/Data ya están disponibles.
  • Se crea un service UI específico para Sales Documents, siguiendo el patrón de QuoteService y DeliveryNoteService.
  • Se mantiene el uso de HttpClient scoped global configurado en Program.cs.
  • Se usa tabla Bootstrap simple, consistente con pantallas existentes.
  • No se introduce grid nuevo ni componente genérico adicional.
  • El create es deliberadamente mínimo y manual.
  • La UI no implementa reglas fiscales ni workflows avanzados.
  • El QuoteId se solicita en create porque el Core actual exige Coverage y el DTO de coverage requiere QuoteId.
  • Origin type se expone en cada línea; para orígenes no manuales se permiten OriginId y QuoteDetailId para respetar validaciones actuales del Core.

Entregable esperado

Story

Archivo:

story66-sales-document-backoffice-ui.md

Patch

Archivo:

story66.patch

Validado con:

git apply --check story66.patch

Branch sugerido

feature/sales/66-sales-document-backoffice-ui

Commit sugerido

feat(ui): add sales document backoffice foundation close #66
## Objetivo Implementar la primera UI administrativa oficial para el módulo **Sales Documents** en el Backoffice Blazor, consumiendo los endpoints API ya publicados por Story #64. El objetivo es cerrar la capa: ```text UI (Blazor) ``` sobre el flujo ya existente: ```text Data → Domain → Core → API ``` --- ## Contexto funcional El proyecto PhronCare ya cuenta con el módulo **Sales Document** consolidado a nivel backend: - persistencia `PhSSalesDocument`, `PhSSalesDocumentDetail`, `PhSSalesDocumentCoverage` - entidades Domain `ESalesDocument`, `ESalesDocumentDetail`, `ESalesDocumentCoverage` - DTOs de create, summary y detail - enums de `SalesDocumentType`, `SalesDocumentStatus`, `SalesDocumentOriginType` y `SalesDocumentCoverageType` - repositorios y mappings Domain ↔ EF - `SalesDocumentService` funcional - endpoints API oficiales: - `GET /api/SalesDocument/search` - `GET /api/SalesDocument/{id}` - `POST /api/SalesDocument` - Swagger funcional Las Stories #56, #58, #59, #61, #63 y #64 ya fueron aplicadas y mergeadas. Esta story agrega la primera experiencia administrativa mínima para operar Sales Documents desde el Backoffice existente, manteniendo el enfoque incremental antes de avanzar hacia facturación fiscal. --- ## Alcance Esta story incluye exclusivamente cambios en la capa **UI Blazor**. ### Navegación - Agregar entrada en el menú lateral existente dentro del grupo **Ventas**. - Nombre visible: `Sales Documents`. - Ruta principal: `/salesdocuments`. ### Cliente UI/API - Crear servicio UI tipado para consumir la API existente: - `ISalesDocumentService` - `SalesDocumentService` - `SalesDocumentSearchParams` - Registrar el servicio en `Program.cs` siguiendo el patrón actual de DI del Backoffice. ### Browse/List - Crear página `/salesdocuments`. - Consumir `GET /api/SalesDocument/search`. - Mostrar listado con tabla Bootstrap consistente con Quotes/DeliveryNotes. - Incluir loading, lista vacía y manejo básico de errores vía `IToastService`. - Incluir paginación simple reutilizando el patrón manual existente. - Mostrar columnas principales: - documento - fecha - cliente - cliente de facturación - presupuesto - document type - status - moneda - total - acción de detalle ### Detail readonly - Crear página `/salesdocuments/{id:int}`. - Consumir `GET /api/SalesDocument/{id}`. - Mostrar cabecera readonly: - número interno / id - fecha - estado - document type - origen agregado desde líneas - total - Mostrar datos relacionados: - cliente - cliente de facturación - quote id - coverage - observaciones - Mostrar líneas de detalle: - línea - origin type - descripción - cantidad - precio unitario - neto - impuesto - total ### Create mínimo - Crear página `/salesdocuments/create`. - Consumir `POST /api/SalesDocument`. - Permitir carga mínima de: - fecha - document type - moneda - cotización - cliente - cliente de facturación - quote id para coverage - coverage type - coverage percentage - período - observaciones - detalles básicos - Permitir agregar/remover detalles. - Calcular importes básicos en UI solo para construir el payload requerido por la API, sin incorporar reglas de negocio avanzadas. - Al crear correctamente, navegar al detalle readonly del documento creado. ### Enums - Usar enums existentes del proyecto: - `SalesDocumentType` - `SalesDocumentStatus` - `SalesDocumentOriginType` - `SalesDocumentCoverageType` - Evitar ints mágicos en la UI. - Mostrar labels legibles sin cambiar la serialización ni los contratos API. ### Archivos incluidos en el patch - `phronCare.UIBlazor/Layout/NavMenu.razor` - `phronCare.UIBlazor/Program.cs` - `phronCare.UIBlazor/Services/Sales/SalesDocuments/ISalesDocumentService.cs` - `phronCare.UIBlazor/Services/Sales/SalesDocuments/SalesDocumentService.cs` - `phronCare.UIBlazor/Services/Sales/SalesDocuments/SalesDocumentSearchParams.cs` - `phronCare.UIBlazor/Pages/Sales/SalesDocuments/SalesDocuments.razor` - `phronCare.UIBlazor/Pages/Sales/SalesDocuments/SalesDocumentDetail.razor` - `phronCare.UIBlazor/Pages/Sales/SalesDocuments/SalesDocumentCreate.razor` --- ## Fuera de alcance Esta story no incluye: - cambios en Data / Models scaffolded - cambios en Domain - cambios en Core - cambios en API - edición de Sales Documents - eliminación/anulación - workflows fiscales - AFIP/ARCA - CAE - autorización fiscal - impresión PDF - exportación Excel - auditoría avanzada - permisos/roles complejos - AutoMapper - refactorización masiva - dashboards - filtros avanzados - búsqueda compleja - componentes genéricos nuevos - virtualización avanzada --- ## Criterios de aceptación ✔ El menú lateral muestra acceso a `Sales Documents` dentro de Ventas. ✔ La ruta `/salesdocuments` carga el browse/list. ✔ El browse consume `GET /api/SalesDocument/search`. ✔ El browse muestra loading, lista vacía, tabla y paginación básica. ✔ La acción de detalle navega a `/salesdocuments/{id}`. ✔ El detalle consume `GET /api/SalesDocument/{id}`. ✔ El detalle muestra cabecera, coverage y líneas readonly. ✔ La ruta `/salesdocuments/create` permite crear un documento mínimo. ✔ El create consume `POST /api/SalesDocument`. ✔ Al crear correctamente, la UI navega al detalle del documento creado. ✔ Los enums se manejan usando tipos existentes, no ints mágicos. ✔ No se modifica ningún modelo EF generado por scaffold. ✔ No se rompen contratos API existentes. ✔ El patch aplica limpio con: ```bash git apply --check story66.patch ``` --- ## Decisiones de diseño - La story se limita a la capa UI porque API/Core/Data ya están disponibles. - Se crea un service UI específico para Sales Documents, siguiendo el patrón de `QuoteService` y `DeliveryNoteService`. - Se mantiene el uso de `HttpClient` scoped global configurado en `Program.cs`. - Se usa tabla Bootstrap simple, consistente con pantallas existentes. - No se introduce grid nuevo ni componente genérico adicional. - El create es deliberadamente mínimo y manual. - La UI no implementa reglas fiscales ni workflows avanzados. - El `QuoteId` se solicita en create porque el Core actual exige `Coverage` y el DTO de coverage requiere `QuoteId`. - Origin type se expone en cada línea; para orígenes no manuales se permiten `OriginId` y `QuoteDetailId` para respetar validaciones actuales del Core. --- ## Entregable esperado ### Story Archivo: ```text story66-sales-document-backoffice-ui.md ``` ### Patch Archivo: ```text story66.patch ``` Validado con: ```bash git apply --check story66.patch ``` ### Branch sugerido ```text feature/sales/66-sales-document-backoffice-ui ``` ### Commit sugerido ```text feat(ui): add sales document backoffice foundation close #66 ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
STORY
bug
infra
refactor
tech-debt
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leandro/phronCare#66
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?