Closed jonerikceberio closed 2 weeks ago
Este caso parece complejo. Entiendo lo que comentas, y siendo así, seria conveniente hacer la mejora en el POS. Si haces alguna propuesta de mejora y necesitas ayuda para hacer pruebas y review estoy disponible 🙂
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.
El módulo l10n_es_ticketbai_pos hace un método hermano del build_tbai_invoice (build_tbai_simplified_invoice) para usar los datos de última factura enviada del config de la TPV en vez de los datos de la compañía.
Pero si el proceso de envío (común), da error, se llama al mark_chain_as_error para deshacer todo el proceso. Y éste no está heredado en l10n_es_ticketbai_pos, por lo que va a escribir como última factura enviada en la compañía la última factura de la TPV. Sin comprobarlo, entiendo que esto destroza el encadenamiento porque hemos metido las simplificadas en las ordinarias.
Tal y como lo veo yo: heredar mark_chain_as_error en el l10n_es_ticketbai_pos, comprobar si es simplificada (tiene pos_order_id), y si es así hacer lo mismo que el método original pero escribiendo en el config de TPV. Si no, llamar a super