No genera asiento contable cuando la factura ya tiene número asignado
lukio opened this issue · 8 comments
En algunos casos, la factura pasa de estado contabilizada a borrador, si utilizamos un módulo extra (account_invoice_posted2draft de nantic).
Al querer contabilizarla nuevamente, no genera el asiento. Esta corrección esta involucrada con el issue #125
Copio de #125:
Para verificar si la factura en estado contabilizada ya esta en AFIP, se evalua el campo del CAE (pyafipws_cae), y eso es lo que se tiene en cuenta. Dentro del metodo post_wsfe se generan los asientos y se confirman si la factura fue aprobada. Como esta factura no se vuelve a enviar a la AFIP, esa parte del código no se ejecuta y no se genera el asiento.
Estoy creyendo que lo correcto sería empezar a utilizar la posibilidad de reprocesar facturas ya numeradas. De esa manera, se comprueba que el numero de la factura que quedo en borrador (aunque tuviera cae) se puede reprocesar (comprobar que numero y datos de la factura corresponden) y guardarnos los datos del cae y transaccion correspodiente.
Ver: http://www.sistemasagiles.com.ar/trac/wiki/ManualPyAfipWs#ReprocesoAutom%C3%A1tico
Si no evaluamos que la factura ya tenga pyafipws_cae, pero la factura sí contiene el número que afip se le aasigna, y viene con error 10016 "(10016) El número o fecha del comprobante no se corresponde con el próximo a autorizar. Consultar metodo FECompUltimoAutorizado." y en vez de propagar el error, se puede reprocesar en ese momento.
Implica que cuando termina el proceso de batch y hubo un error en cuestión, deberiamos evaluar y reprocesar? Actualmente blanqueamos el valor del campo number e invoice_date para poder enviar el lote nuevamente.
En el metodo CAESolicitar (cuando se emite una factura y no en lote) pyafipws en vez de devolvernos un error con codigo , puede reprocesar la factura y consultar automáticamente por dicho comprobante devolviendonos el cae correspondiente. (Esto si se le ha pasado el parametro Reprocesar = S)
Esto implica que la numeracion de las facturas se hagan no se deberian antes de enviar a la AFIP y que
Esto nos abre la puerta a que los usuarios dejen de tener que utilizar el asistente de recuperación de factura manual.
Tengo un problema que cuando genero una factura de proveedor a partir de líneas de factura, no me genera los asientos contables al contabilizar la factura.
Saludos!
Tengo un problema que cuando genero una factura de proveedor a partir de líneas de factura, no me genera los asientos contables al contabilizar la factura.
Hola @andres53016, ese problema fue reportado y corregido en los tickets #135 y #134
abrazo!
linkeamos a modulo de recover_invoice_ar. Es un caso típico en el que al recuperar una factura, primero le guardamos el número de comprobante (para que tryton no le asgine uno) y luego la contabilizamos.
Evaluando:
- si el comprobante tiene número y cae, entonces puede ser que (o bien se uso el modulo de posted2draft o se esta queriendo recuperar una factura que no se guardo en tryton (recover_invoice_ar.).
La postura sería que cuando tiene ambos datos, (lo más probable es que no tenga guardado la fecha), entonces se debe consultar a la afip con dichos datos (punto de venta, tipo comprobante, y numero de comprobante), corroborar que los datos sean los mismos (montos, fechas, etc) y si esta todo bien, pasarla a contabilizado. Si es asi, entonces no debemos pasar por el codigo del post_wsfe (batch) y tener un nuevo metodo que sea consultar_y_recuperar_invoice.
Hice los cambios y corri el test de recover_invoice_ar.
El test pasó. El test de recover_invoice_ar contabiliza una factura, duplica y luego recupera en la factura duplicada la primera.
El test de account_invoice_ar que chequea este error debería de ser parecido, ya que por ahora estamos hardoceando los datos y como usamos el atributo Reprocesar de pyafipws, verifica si hay diferencias entre la factura que consultamos de afip y la que estamos recuperando. Si va todo bien, la contabiliza, sino, la deja como esta.