Referencia generada desde el metamodelo

Este borrador describe evidencia técnica del ERP. Las frases que indican evidencia insuficiente no deben interpretarse como reglas confirmadas.

Manual funcional de Cancelaciones de Carga Resumida

Introduccion

Cancelaciones de Carga Resumida es una entidad ubicada en la raíz del módulo Ventas. Su propósito funcional específico no se encuentra descripto con evidencia suficiente en la información disponible; por lo tanto, este documento actúa como borrador operativo inicial para ser completado/validado por un responsable funcional.

Relaciones (según evidencia estructurada):

• Vincula con Carga resumida de Recibos V2 mediante el campo CRDR_ID_CRDR (FK a CARGA_RESU_DE_RECIBO).
• Vincula con Pedido mediante el campo PEDI_ID_PEDI (FK a PEDIDO).
• Vincula con Punto de venta mediante el campo PUVE_ID_PUVE (FK a PUNTO_VENTA).
• Vincula con Tipo de factura mediante el campo TIFA_ID_TIFA (FK a TIPODEFACTURA).

Mapa de estados (vision funcional)

No se encontró evidencia suficiente de un flujo de estados asociado a la entidad (no hay estados detectados).

Estado	Tipo	Objetivo funcional	Editable por usuario
No identificado (sin estados relevados)	No definido	No se encontró evidencia suficiente para describir el circuito/flujo	No se encontró evidencia suficiente

Que completa el sistema automaticamente

No se detectaron acciones automáticas asociadas a la entidad (por ejemplo: cálculos, asignaciones por evento, numeraciones, auditorías específicas de esta entidad).

• No se encontró evidencia suficiente de automatismos.

Reglas funcionales clave

1. Relación con Carga Resumida de Recibos

   • Existe una dependencia por FK CRDR_ID_CRDR hacia CARGA_RESU_DE_RECIBO.
   • No se encontró evidencia suficiente sobre qué validaciones se aplican al cancelar una carga (por ejemplo: si debe existir, si debe estar en un estado particular, si se revierte contabilización, etc.).

2. Relación con Pedido

   • Existe una relación por FK PEDI_ID_PEDI hacia PEDIDO.
   • No se encontró evidencia suficiente para afirmar si la cancelación impacta (o no) en el estado del pedido, su facturación o su imputación.

3. Relación con Punto de Venta y Tipo de Factura

   • Relaciones por FK PUVE_ID_PUVE (PUNTO_VENTA) y TIFA_ID_TIFA (TIPODEFACTURA).
   • No se encontró evidencia suficiente sobre reglas como obligatoriedad, consistencia entre punto de venta/tipo de factura, o restricciones por configuración fiscal.

4. Campos clave / criterios de unicidad

   • No se encontró evidencia suficiente de campos clave, criterios de búsqueda principales, ni restricciones (por ejemplo: unicidad por CRDR+Pedido, etc.).

Campos funcionales mas consultados

No se cuenta con un listado de campos propio de la entidad. Con la evidencia disponible, solo se pueden documentar los campos de relación (FK) como los más relevantes a nivel funcional.

Campo	Significado funcional
CRDR_ID_CRDR	Referencia a la Carga resumida de Recibos V2 asociada a la cancelación (FK a CARGA_RESU_DE_RECIBO).
PEDI_ID_PEDI	Referencia al Pedido asociado (FK a PEDIDO).
PUVE_ID_PUVE	Referencia al Punto de venta asociado (FK a PUNTO_VENTA).
TIFA_ID_TIFA	Referencia al Tipo de factura asociado (FK a TIPODEFACTURA).

Preguntas frecuentes (FAQ)

1. ¿Para qué se usa Cancelaciones de Carga Resumida en Ventas?

• • No se encontró evidencia suficiente para describir el objetivo funcional exacto.
  • Con la evidencia disponible, se sabe que la entidad registra/relaciona una cancelación con una Carga resumida de Recibos, y opcionalmente/relacionadamente con Pedido, Punto de venta y Tipo de factura.

2. ¿Qué estados tiene el registro de cancelación?

• • No se encontró evidencia suficiente: no hay estados detectados en la fuente provista.
  • Se recomienda validar si la entidad maneja estados (p. ej. Pendiente , Confirmada , Anulada ) o si es un registro plano sin workflow.

3. ¿El sistema completa datos automáticamente al crear una cancelación?

• • No se detectaron acciones automáticas asociadas.
  • No se encontró evidencia suficiente para confirmar numeraciones automáticas, fechas por defecto, usuario creador, etc.

4. ¿Qué validaciones deberían revisarse antes de habilitar el uso productivo?

• • Consistencia de FK: que existan CARGA_RESU_DE_RECIBO, PEDIDO, PUNTO_VENTA, TIPODEFACTURA referenciados.
  • Definición funcional pendiente: qué significa cancelar en este contexto y qué impacto tiene en los documentos vinculados (no hay evidencia suficiente).

5. ¿Qué entidades/procesos están directamente vinculados?

• • Carga resumida de Recibos V2 (CARGA_RESU_DE_RECIBO) mediante CRDR_ID_CRDR.
  • Pedido (PEDIDO) mediante PEDI_ID_PEDI.
  • Punto de venta (PUNTO_VENTA) mediante PUVE_ID_PUVE.
  • Tipo de factura (TIPODEFACTURA) mediante TIFA_ID_TIFA.

Integraciones funcionales relevantes

• Carga resumida de Recibos V2 (relación directa por FK CRDR_ID_CRDR).
• Pedido (relación directa por FK PEDI_ID_PEDI).
• Punto de venta (relación directa por FK PUVE_ID_PUVE).
• Tipo de factura (relación directa por FK TIFA_ID_TIFA).