Dos compañías.
Un recorrido claro.

Gestión → origen comercial + emisor/receptor + proveedor/destino versionado + ofertas cliente/CN + solicitudes y decisiones + obligaciones + ajustes + aplicaciones + eventos monetarios + evidencias + actividad.

Cada evento lleva compañía propietaria, entidad financiera, cuenta, moneda nativa, cantidad, fecha real, versión aceptada, autor, ejecutor cuando difiera y clave de idempotencia. Una transferencia enlaza envío y recepciones; una conversión enlaza dos cantidades reales y sus comisiones. Una aplicación distribuye un evento entre una o varias gestiones sin exceder su cantidad disponible.

• Encargo: borrador → enviado → información pendiente / viable / no viable / cancelado.
• Comercial: cotizado → presentado → aceptado / vencido / sustituido. Cliente y China conservan decisiones propias.
• Financiación: por autorizar / autorizada / parcial / fondos asignados / anticipo por recuperar.
• Envío: pendiente / enviado / recibido parcial / recibido / diferencia por resolver.
• Ejecución: por convertir / conversión parcial / fondos CNY / pago parcial / pagado.
• Control: por sincronizar / registrado / por conciliar / conciliado. Cierre operativo, obligaciones liquidadas y cierre contable son hitos distintos.

El resumen visual deriva el próximo pendiente de estos estados. Un único estado «completado» no reemplaza todos los registros.

1. Saldo por cuenta, entidad y moneda = apertura + entradas − salidas. Una vista consolidada identifica fecha y tasa; no suma monedas directamente.
2. Cobro, captura, feed bancario y conciliación afectan una sola vez el dinero real. Respuesta perdida y reintento devuelven el mismo resultado.
3. USD→USDT y USDT→CNY guardan cantidades reales independientes. La tasa ejecutada tiene unidades; las comisiones conservan monto, moneda y responsable.
4. Enviar no confirma recibir. Cantidad esperada = recepciones aplicadas + deducciones documentadas + pendiente de ese tramo.
5. Facturar, aprobar, reservar o asignar fondos no produce efectivo. Una autorización de anticipo no crea dinero disponible.
6. El saldo del cliente, la obligación entre empresas y el pendiente del proveedor se explican por separado. Las aplicaciones no consumen más de lo disponible.
7. Las dos tarifas conservan su base y versión. Un cambio de configuración no modifica acuerdos aceptados ni tasas ejecutadas.
8. Una conciliación valida entidad, cuenta, moneda, dirección e importe; no basta que sumen lo mismo.
9. Todo remanente se clasifica por dueño y propósito. Los decimales, la precisión USDT y el residuo de redondeo quedan definidos y reproducibles.
10. Un cambio de compañía no reasigna documentos ni capturas. Usuario sin compañía o permiso explícito no puede ejecutar comandos financieros.

1. Identidad y dinero. Mapear entidades/cuentas, extender permisos y crear la raíz de gestión. Implementar comandos idempotentes, aplicaciones y captura/observación como un solo hecho. Validar todos los saldos antes de construir automatismos.

2. Admin y relevo a China. Envío del encargo, bandeja persistente, ofertas independientes, vigencia, aceptación, ajustes, autorización y anticipos. El doble clic en enviar genera un único pendiente en China.

3. Caja y conciliación. USD/USDT en VE, recepciones, conversiones parciales, pagos, remanentes y exportación. El mismo caso debe cuadrar por operación y por cada cuenta nativa.

4. Piloto y AI. Corte y conciliación del histórico, piloto con ambas compañías, luego canales AI con la misma identidad y autorización. Integrar Alcancía por período sin mezclar presupuesto con fondos de clientes.

Aceptación mínima: ejecutar el ejemplo 113,12 USD → 106 USDT → 700 CNY; luego USDT preexistente, anticipo VE, anticipo CN, fondos insuficientes, dos recepciones, comisión de red, conversión parcial, pago parcial, ajuste positivo/negativo, cancelación y devolución. Verificar banco antes/después de captura, reintento tras respuesta perdida, identidad/moneda ajena rechazada, cambio de compañía con borrador pendiente y exportación sin duplicados. Resolver saldo inicial y capturas históricas sin vínculo antes del corte.

Estos son criterios de implementación. La publicación del diseño no acredita que esas pruebas de Mogos ya hayan pasado.

• Identidad real: determinar qué entidad presta el servicio de China/Hong Kong y quién es titular de cada cuenta y wallet. La moneda no determina la entidad. HKD requiere soporte explícito si entra en alcance.
• Documentación por emisor: validar proforma, factura del servicio, fondos administrados y documento correctivo. No asignar ingreso o tratamiento fiscal automáticamente al total recibido.
• Políticas operativas: perfiles, límites de anticipos, responsable de recuperarlos, segundo aprobador cuando aplique, condiciones de evidencia y regularización.
• Condiciones comerciales: tarifas/base por operación, fuente y vigencia de tasas, momento de fijación, gastos bancarios/red y quién los asume. El ajuste mantiene ambos porcentajes pactados.
• Oficina: período mensual de Alcancía, manejo del saldo no usado y reposición. Cada gasto conserva su origen y autorización presupuestaria.

La financiación flexible y el mecanismo de ajustes están decididos. Los valores concretos se configuran; los hechos jurídicos y la titularidad de cuentas se confirman con sus responsables.

Revisión de código sobre la referencia local origin/development · 6ea5d0281c565a5ab11d43c459d8c7697b82c808 del 7 de septiembre de 2026. No acredita el estado remoto actual ni el estado de los datos en producción.

Se identificaron rutas que crean Ingreso sin MoneyMovement, reintentos de Caja sin clave estable, clasificación bancaria que puede duplicar capturas, entidad por defecto al convertir ServiceQuote a Quotation y swap con diferencias atribuidas a US_LLC. El alcance anterior exige cerrar esas rutas, integrar la valoración real USD/USDT y validar las asignaciones de conciliación.

El informe interno con referencias de código y el contrato de proyecto acompañan esta entrega. Se reutiliza el repositorio de Mogos; no se crea una app financiera ni un saldo paralelo.

Fuera de alcance: ejecución bancaria automática, trading, un nuevo ERP contable, tratamiento tributario inventado por el producto y habilitación automática de permisos a empleados.