Write-back: tu sistema manda

aiuda no acumula verdad propia. Si una factura vino de Odoo y el dueño confirma el pago en aiuda, ese pago debe quedar registrado en Odoo; si vino de Shopify, en el pedido de Shopify. La consola es una capa de acción, no un silo nuevo.

Cómo funciona

core/aiuda_core/engine/writeback.py implementa el patrón outbox transaccional:

1. Cuando ocurre el evento (pago confirmado a mano, o detectado contra banco/Stripe), queue_payment_writeback() encola una entrada en la misma transacción que lo origina. Si la transacción falla, no hay entrada huérfana.
2. Un job del worker (process_outbox) procesa las pendientes con el conector del sistema destino: en Odoo deja constancia en el chatter de la factura (add_invoice_note), en Shopify una nota en el pedido (mark_note).
3. Reintentos con límite (5): si el sistema destino no responde, la entrada guarda el error y reintenta en la siguiente corrida; al agotar intentos queda en failed, trazable.
4. Si el conector no está configurado, la entrada espera sin fallar y sin consumir intentos.

from aiuda_core.engine.writeback import queue_payment_writeback, process_outbox

queue_payment_writeback(session, tenant, invoice)   # al confirmar el pago
process_outbox(session, tenant, odoo_client=odoo)   # en el worker

Qué sistemas reciben write-back

Sistema	Acción	Mecanismo
Odoo	Constancia en el chatter de la factura	XML-RPC message_post
Shopify	Nota en el pedido	PUT del campo note
Excel / CSV	No aplica: un archivo no es un sistema vivo	—

La lista crece con cada conector de escritura. Las misiones CUA de escritura entran por este mismo outbox, con la misma trazabilidad.

Por qué importa

Es la garantía de salida del proyecto: si un negocio deja aiuda, su información sigue íntegra en sus propios sistemas, incluidas las gestiones hechas durante el servicio.