

Una nota de débito es el documento con el que el vendedor aumenta el importe de una operación que ya había facturado.
Existe por el mismo motivo que su opuesta: en contabilidad un comprobante emitido no se modifica, se corrige con otro comprobante.
Reemitir la factura con un importe mayor rompería la correlatividad de la serie y borraría el rastro de lo que se había acordado primero.
Por eso la nota de débito convive con la factura original y la referencia de forma expresa.
Si la factura sigue impaga, la nota de débito eleva lo que el cliente adeuda.
Si ya fue cobrada, genera una deuda nueva por la diferencia.
Cuando el concepto está alcanzado por impuestos, el ajuste arrastra también el impuesto correspondiente, porque modifica la base imponible.
Las dos son comprobantes de ajuste y se distinguen únicamente por la dirección del movimiento.
La nota de débito sube el importe adeudado y la nota de crédito lo baja.
Un mismo hecho puede necesitar las dos, por ejemplo cuando se anula una factura equivocada con una nota de crédito y se emite después la correcta.
El documento también viaja en sentido contrario.
Un proveedor puede emitir una nota de débito contra la empresa por los mismos conceptos, y entonces lo que aumenta es una cuenta por pagar.
Conviene revisarla con el mismo criterio que una factura de compra, porque incrementa una deuda propia.
Los requisitos formales exactos son normativa de cada país y conviene consultarlos antes de diseñar el comprobante.
Aun así hay un núcleo de datos que se repite en todas las jurisdicciones.
La regla práctica es la misma que rige para la nota de crédito: el comprobante tiene que poder cruzarse con la factura que ajusta.
Una nota de débito que llega sin aviso previo suele terminar en una discusión con el cliente.
Los conceptos que la justifican, sobre todo los intereses por mora, conviene dejarlos escritos en las condiciones de venta antes de que ocurran.
El ERP parte del mismo principio que hace necesaria una nota de débito: un comprobante emitido no se altera.
El número de cada Factura lo asigna la Plataforma con un contador automático, así que nadie lo escribe ni lo edita a mano.
Corregir en más una operación cerrada consiste entonces en registrar el hecho nuevo, sin volver sobre el documento anterior.
La Configuración de la empresa define de antemano qué Cuenta contable recibe cada tipo de ajuste.
Tenerlo resuelto ahí evita que la imputación quede librada al criterio de quien carga el comprobante.
La misma Configuración guarda tres campos de días llamados Primer Aviso, Segundo Aviso y Tercer Aviso.
Cada uno define a cuántos días del vencimiento corresponde reclamar, de modo que la cobranza sigue una escala pareja para todos los clientes.
Esa escala es lo que le da sustento a un débito por intereses: cuando llega, el cliente ya fue avisado tres veces.
La Factura lleva una Fecha vencimiento y un campo Estado con los valores Borrador, Emitida y Pagada.
Cruzar esos dos datos devuelve, en una Vista de lista, exactamente qué comprobantes están vencidos y sin cobrar.
El Total de cada uno y los días transcurridos desde el vencimiento son la base sobre la que se calcula el interés a debitar.
La Configuración guarda además la Fecha de Cierre contable de la empresa.
Ese dato separa el período ya cerrado del período abierto, y por lo tanto define hasta dónde se puede seguir ajustando.
Un débito que corresponde a un período cerrado se resuelve dentro del ejercicio corriente.
El objeto Record History guarda, para cada modificación, el registro alcanzado, el campo tocado, su valor anterior y su valor nuevo.
Guarda también el usuario que hizo el cambio y la fecha y hora exactas.
Es la contracara técnica de la idea que sostiene todo comprobante de ajuste: nada se modifica en silencio.
Una Factura vence el día 10 de un mes y el cliente la termina pagando treinta días más tarde.
Los tres avisos configurados ya se dispararon sobre esa Fecha vencimiento, así que el reclamo quedó documentado antes del ajuste.
El interés se calcula sobre el Total de esa Factura por los días transcurridos, y se imputa a la Cuenta de Intereses por mora a Clientes definida en la Configuración.
La Factura original queda intacta, y el ajuste vive como un hecho nuevo y rastreable.
En la dirección del ajuste.
La nota de débito aumenta lo que el cliente adeuda y la nota de crédito lo reduce.
No conviene, y el motivo es contable antes que legal: un comprobante emitido no se modifica, se ajusta con otro comprobante.
Reemitir rompe la correlatividad de la serie y borra el rastro de lo que se había acordado en primer lugar.
Las formalidades exactas las fija cada país, pero en la práctica el aviso previo es lo que evita el reclamo.
Los conceptos que la justifican, en especial los intereses por mora, conviene dejarlos escritos en las condiciones de venta antes de que ocurran.
Sí, y en ese caso lo que aumenta es una cuenta por pagar en lugar de una cuenta por cobrar.
Conviene revisarla con el mismo criterio que una factura de compra, porque incrementa una deuda propia.
El circuito de ventas se apoya en EGAFutura__Invoice__c (Factura) y EGAFutura__Sales_Order__c (Venta).
El campo Name de la Factura, etiquetado Número de Factura, es un Auto Number, de modo que no admite escritura desde la API.
Todas viven en EGAFutura__Configuration__c y son búsquedas hacia EGAFutura__Cuenta_contable__c.
EGAFutura__Primer_Aviso_dias__c, EGAFutura__Segundo_Aviso_dias__c y EGAFutura__Tercer_Aviso_dias__c son campos Number(2, 0) del mismo objeto de configuración.
El límite del ajuste lo marca EGAFutura__Fecha_Cierre_contable__c, un campo Date.
Las series de comprobantes se administran desde EGAFutura__Number_sequence__c, que mantiene secuencias separadas por tipo de operación.
EGAFutura__RecordHistory__c registra EGAFutura__ParentObject__c, EGAFutura__ParentId__c, EGAFutura__FieldLabel__c, EGAFutura__OldValue__c, EGAFutura__NewValue__c, EGAFutura__User__c y EGAFutura__EventDateTime__c.