Maqueta — aquí se ve la estructura, no los datos
Puedes llenar el formulario para ver cómo se siente, pero nada se guarda: no hay base de datos ni endpoint detrás. Al enviar, se explica qué haría el módulo de verdad.
Datos del gasto
los campos con * serían obligatoriosQué pasa al enviar
cuando el módulo sea real- El formulario hace POST a /api/gastos, un route handler del propio módulo.
- El handler resuelve persona, cliente y tienda contra los maestros de Core por RPC y guarda uuid.
- Si un código no existe, no se inventa: se manda a la cola de curaduría con core_solicitar_alta.
- Se escribe la fila en la base del módulo y el comprobante en su Storage.
- El gasto queda enviado y aparece en Total de gastos, esperando autorización.
La regla que no se rompe
El navegador nunca habla con la base ni con Supabase directo. La única puerta a datos son los route handlers de este módulo — ahí viven las llaves y ahí se valida quién es quien pide. Es la regla de arquitectura de la plataforma, no una preferencia de estilo.
navegador → route handlerhandler → basenavegador → base ✕
Lo que aquí NO va
Facturas, cuentas por cobrar, tesorería y el cotejo contable son de evolveos-finanzas. Aquí vive la comprobación: el gasto, su evidencia y su autorización. El gasto comprobado se le entrega a finanzas por contrato o por espejo — el CFDI no se duplica en dos módulos.