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 Nota de Débito (V)

Introduccion

Nota de Débito (V) es una entidad del módulo Ventas, ubicada en la categoría Notas de Venta. Representa el documento de nota de débito de venta y su circuito operativo, incluyendo emisión, entrega al cliente, cálculo de percepciones y registración/ajustes contables asociados.

No se encontró evidencia suficiente para describir:

• El objetivo contable/fiscal exacto de la NDV (por ejemplo, si siempre ajusta una factura previa, si puede ser a cuenta , etc.).
• El orden obligatorio de transición entre estados y qué evento dispara cada cambio de estado (manual/automático).
• Restricciones de edición por estado (campos bloqueados/desbloqueados).

Estados detectados en el circuito (8): Proyectada, Emitida, Entregada, Calculando Percepciones, Copiando Nota, Regenerando asiento, Reimputando, Anulada.

Relaciones funcionales relevantes detectadas (no exhaustivo): Cliente, Tipo de factura, Punto de venta, Factura, Asiento, Moneda, Condición de venta, Producto/Servicio, Liquidación de impuestos, Provincia, Centro de Costo, y entidades de detalle/impuestos/percepciones.

Mapa de estados (vision funcional)

Estado	Tipo	Objetivo funcional	Editable por usuario
Proyectada	Operativo	Ejecutar un evento al Proyectada asociado al documento.	No se encontró evidencia suficiente.
Emitida	Operativo	Generar movimientos asociados a la emisión de la nota.	No se encontró evidencia suficiente.
Entregada	Operativo	Enviar el link de la nota al contacto (entrega al cliente).	No se encontró evidencia suficiente.
Calculando Percepciones	Operativo	Crear percepción IIBB (cálculo/alta de percepciones).	No se encontró evidencia suficiente.
Copiando Nota	Operativo	Copiar la Nota de Débito (copia ND).	No se encontró evidencia suficiente.
Regenerando asiento	Operativo	Regenerar el asiento contable asociado.	No se encontró evidencia suficiente.
Reimputando	Operativo	Reimputar la Nota de Débito (ajuste de imputaciones).	No se encontró evidencia suficiente.
Anulada	Operativo	Anular asiento (asociado a la anulación del documento).	No se encontró evidencia suficiente.

Nota: no hay evidencia que indique cuáles estados son iniciales/finales, ni el flujo exacto (secuencia) entre ellos.

Que completa el sistema automaticamente

Acciones automáticas/operativas detectadas por estado:

• Proyectada: Evento al Proyectada .
• Emitida: Movimientos asociados a la emisión de la nota .
• Entregada: Envía el link de la nota al contacto .
• Calculando Percepciones: Crea Percepción IIBB .
• Copiando Nota: Copia ND .
• Regenerando asiento: Regenerar asiento .
• Reimputando: Reimputar ND .
• Anulada: Anular asiento .

No se encontró evidencia suficiente sobre:

• Si estas acciones se disparan automáticamente al entrar al estado, o mediante una acción del usuario.
• Si generan registros en entidades específicas (por ejemplo, Percepción Realizada, Movimiento Contable) y con qué criterios.

Reglas funcionales clave

• Cliente obligatorio: el campo Cliente (CLIE_ID_CLIE) es mandatorio para registrar la Nota de Débito (V).
• Vinculación contable: existe relación con Asiento (ASIE_ID_ASIE) y se observan acciones específicas de regeneración/anulación de asiento, lo que sugiere dependencia del documento con su registración contable.
• Cálculo de percepciones: existe un estado/acción explícita para crear Percepción IIBB, lo que indica que el documento puede gatillar percepciones (al menos IIBB) bajo ciertas condiciones.

No se encontró evidencia suficiente para documentar reglas como:

• Validaciones de numeración (correlatividad por punto de venta / tipo).
• Reglas de cálculo de importes (neto/IVA/total) y su origen (detalle, impuestos, moneda).
• Reglas de anulación (si requiere motivo, si revierte percepciones/movimientos, si impacta factura asociada).
• Reglas de reimputación (qué se reimputa y contra qué entidades/documentos).

Campos funcionales mas consultados

Campo	Significado funcional
CLIE_ID_CLIE (Cliente)	Cliente al que se emite la Nota de Débito (V). Mandatorio.
TIFA_ID_TIFA (Tipo)	Tipo de comprobante / tipo de factura asociado a la ND.
PUVE_ID_PUVE (Punto de venta)	Punto de venta desde el cual se emite la nota.
NUMERO (Nro)	Número del comprobante.
FECHA_EMISION (Fecha de emisión)	Fecha de emisión del documento.
NETO (Neto)	Importe neto del documento (sin impuestos).
IVA (IVA)	Importe de IVA del documento.
TOTAL (Total)	Importe total del documento (neto + impuestos).
PENDIENTE_CANCELACIO (Pendiente de Cancelación)	Saldo pendiente de cancelación del documento.

Preguntas frecuentes (FAQ)

1. ¿Para qué se usa la Nota de Débito (V) en el módulo Ventas?

• • Para gestionar un documento de Nota de Débito de venta, con estados operativos y acciones asociadas (emisión, entrega, percepciones, asiento contable).
  • No se encontró evidencia suficiente para detallar los escenarios de negocio exactos (p. ej., ajuste de factura, cargos adicionales, intereses, etc.).

2. ¿Qué datos necesito sí o sí para crear/registrar una Nota de Débito (V)?

• • Cliente es obligatorio.
  • El resto de campos (Tipo, Punto de venta, Número, Fecha de emisión, importes) aparecen como relevantes de cabecera, pero no se encontró evidencia suficiente para afirmar obligatoriedad o validaciones.

3. ¿Qué sucede cuando la nota pasa a Emitida ?

• • Se ejecutan movimientos asociados a la emisión de la nota .
  • No se encontró evidencia suficiente sobre qué movimientos se generan exactamente (contables, fiscales, stock, cuenta corriente, etc.).

4. ¿Cómo se gestiona la entrega al cliente?

• • En el estado Entregada el sistema envía el link de la nota al contacto .
  • No se encontró evidencia suficiente sobre el canal (email/portal) ni qué contacto utiliza (del cliente, del documento, etc.).

5. ¿Cuándo se calculan o crean percepciones (IIBB)?

• • En el estado Calculando Percepciones el sistema crea Percepción IIBB .
  • No se encontró evidencia suficiente sobre condiciones de aplicación (jurisdicción/provincia, padrón, alícuotas, mínimos, etc.).

6. ¿Qué implica Regenerando asiento y Anulada respecto a contabilidad?

• • Regenerando asiento: ejecuta Regenerar asiento asociado.
  • Anulada: ejecuta Anular asiento .
  • No se encontró evidencia suficiente sobre si impacta otros registros (movimientos contables, liquidaciones de impuestos, percepciones realizadas).

Integraciones funcionales relevantes

Entidades/procesos relacionados detectados (por relaciones e integraciones declaradas):

• Cliente
• Tipo de factura (TIPODEFACTURA)
• Punto de venta (PUNTO_VENTA)
• Factura (campos relacionados: FACT_ID_FACT, FACT_ID_FAC2)
• Condición de venta
• Moneda
• Asiento (y, por integración, Movimiento Contable)
• Detalle ND venta / NDV DET FX (detalle asociado)
• Producto/Servicio
• Impuesto
• Liquidación de impuestos
• Percepción Realizada y Concepto Percepción
• Concepto facturación
• Centro de costos
• Provincia
• Centro de Costo
• Empresa

No se encontró evidencia suficiente para describir:

• Qué integración es obligatoria vs. opcional.
• Puntos de sincronización (al emitir, al entregar, al anular, etc.) y su impacto exacto en cada entidad relacionada.

---

Regla fiscal IVA Digital (validada en codigo)

• La inclusion de Notas de Debito en la Liquidacion de IVA se define en el proceso de liquidacion de impuestos.
• Para Nota de Debito de venta, la condicion efectiva es que el tipo de comprobante tenga CODIGO_AFIP_ND informado y distinto de 0.
• El proceso de CITI Ventas (IVA Digital) no recalcula esta regla: toma comprobantes ya asociados por LIQI_ID_LIQI.

Implicancia operativa:

• Un tipo documental no fiscal (por ejemplo, "Presupuesto") no deberia tener codigo ARCA/AFIP de ND distinto de 0 si no corresponde reportarlo.
• Si quedo asociado a una liquidacion, aparecera en CITI Ventas aunque luego se cambie el tipo o la configuracion.