Error 10015 AFIP about django-afip HOT 8 OPEN

Debería. Pero por lo que me decís, parecería que el AFIP dió el okay.

Podés ver el objecto ReceiptValidation de ese comprobante? Tiene un CAE?

from django-afip.

Perdon no estoy pudiendo replicar el error debido a un error de afip 502 Transaccion activa. Segun estuve investigando es un error interno de afip.
Fuente
Al registrar una receipt nueva me salta lo siguiente:
(1062, "Duplicate entry '1-4-163' for key 'afip_receipt_point_of_sales_id_receip_6a7c4af7_uniq'")

from django-afip.

Perdon no estoy pudiendo replicar el error debido a un error de afip 502 Transaccion activa. Segun estuve investigando es un error interno de afip.

No puedo ayudarte mucho ahí; es algo que tendrán que solucionar ellos.

Al registrar una receipt nueva me salta lo siguiente:
(1062, "Duplicate entry '1-4-163' for key 'afip_receipt_point_of_sales_id_receip_6a7c4af7_uniq'")

Rarísimo. Parecería que el número de comprobante que le estás poniendo ya está en uso en la base local.

Estás asignando el número de comprobante vos? No deberías, al validar se le asigna el siguiente en sequencia.

Generaste capaz otro compobante al que le asignaste número a mano, o te quedó alguna transacción a medias? (esto sería claro si tenés algun no-validado que sí tiene número).

from django-afip.

Para aclarar un poco más (y esto debería documentarlo bien), como los comprobantes tienen que validarse con número sequenciales, validate setea el número al siguiente según el afip (último+1).

Por ese motivo, no se espera que vos le asignes número a los comprobantes.

Por el error, daría la impresión de que tenés un comprobante con un número seteado pero que no fue validado.

from django-afip.

Sinceramente no se que paso, ahora ya puedo registrar receipts y validarlas. El error era lo que decias, al parecer el validate tiraba error desde afip y por ende las proximas receipts tenian el mismo numero que la anterior la no poder validarla.
Otra cosa que me hace dudar es que no entiendo por que el validate le asigno el primer numero si la validacion dio error desde AFIP. Incluso con un transaction.atomic() no hace el rollback.
Creo que para evitar esto en un futuro deberia separar la instancia de registro de la receipt de la validacion.

Para aclarar un poco más (y esto debería documentarlo bien), como los comprobantes tienen que validarse con número sequenciales, validate setea el número al siguiente según el afip (último+1).

Estaria bueno para entender un poco mas el funcionamiento y comprender los errores que puedan surgir.
Muchas gracias Hugo.

from django-afip.

Sinceramente no se que paso, ahora ya puedo registrar receipts y validarlas. El error era lo que decias, al parecer el validate tiraba error desde afip y por ende las proximas receipts tenian el mismo numero que la anterior la no poder validarla.

Esto puede pasar si estás ejecutando la validación fuera de una transacción.

En mi código siempre lo llamo dentro de un transaction.atomic, pero estoy pensando que el método validate() podría encargarse de la transacción por sí mismo.

Otra cosa que me hace dudar es que no entiendo por que el validate le asigno el primer numero si la validacion dio error desde AFIP

El número debe asignarse antes de mandarlo al AFIP.

Creo que para evitar esto en un futuro deberia separar la instancia de registro de la receipt de la validacion.

Separar asignación de número y validación puede traer muchos problemas, dado que impicaría que en el instante entre los dos pasos, tenés datos inválidos en la base, y puede generar el error que estás viendo. Creo que la solución correcta es, de nuevo, que validate se encargue de hacer todo transaccional.

from django-afip.

Action points en base a esto:

• Aclarar en la documentación esto que hablamos.
• Make validate una transacción.

from django-afip.

Hugo vuelvo sobre este problema que ahora vuelve a ocurrir por algun motivo.
No logro detectar el por que de la falla pero tengo un panorama mas claro del sistema y tengo mas evidencias para ver si podemos solucionarlo. Ademas me gustaria saber como salir de esto para seguir facturando ya que el problema esta en produccion.

Esta claro que el problema es por que el sistema quiere asociarle un numero de factura que ya esta en el sistema, en este caso el numero de factura 719.
Revisando las Receipts encuentro que efectivamente el numero existe en la base de datos pero sin ningun ReceiptValidation asociado, tampoco hay ReceiptValidationObservations asociados a esa factura.

Puede ser que esto se deba a un problema de fechas? Nosotros permitimos generar una Receipt (sin asignarle numero de factura) y llamar a validate dias posteriores a la generacion de la factura.

Como podemos salir de este problema? Que ocurre si seteo manualmente a null el numero de factura que esta generando conflicto?

from django-afip.