Una remesa agrupa facturas pendientes de cobro o de pago sobre una cuenta bancaria de la empresa. Sphere genera el archivo XML que acepta el banco y, cuando el banco lo procesa, convierte cada línea en un cobro o un pago que salda la factura y deja su movimiento de tesorería.
El tipo de la remesa decide de dónde salen las facturas, qué datos bancarios del tercero hacen falta y qué documento se crea al liquidar.
Tres acciones mueven la remesa por sus estados. Cada acción sólo está habilitada en los estados que se muestran; el resto del tiempo el botón aparece deshabilitado.
| Estado | Proponer líneas | Descargar SEPA | Liquidar remesa |
|---|---|---|---|
| Draft | Sí | Sí | No |
| FileGenerated | No | Sí | Sí |
| Sent | No | Sí | Sí |
| Settled | No | No | No |
| Canceled | No | No | No |
Es una secuencia real: no se puede liquidar sin haber descargado el archivo, y no se puede descargar sin líneas válidas.
Al crearla, Sphere rellena el número con la marca de tiempo (REM-20260909-153012), la fecha de hoy, el vencimiento a dos días, el tipo Adeudo directo y el estado Borrador. Lo único que el usuario tiene que elegir es la cuenta bancaria de la empresa y, si corresponde, cambiar el tipo a Transferencia.
El vencimiento de la remesa es la fecha que va al banco como fecha de cobro o de ejecución solicitada.
Sphere busca facturas con saldo pendiente mayor que cero y vencimiento igual o anterior a la fecha límite, y añade una línea por cada una con importe = saldo pendiente. Descarta las que ya están en la remesa y las de terceros sin datos bancarios completos, sin avisar línea por línea. Si no queda ninguna, la acción falla con un mensaje.
Las líneas también se pueden cargar a mano en la ficha, o desde la API pasando la lista de facturas al crear la remesa. La API no aplica el filtro de vencimiento ni el de datos bancarios: toma las facturas que le mandan.
Primero valida la remesa completa: cuenta de la empresa con IBAN, identificador de acreedor si es adeudo, al menos una línea, y para cada línea que la factura tenga tercero y que el tercero tenga mandato o cuenta con IBAN. Cualquier falta corta la acción con un mensaje que nombra al cliente o proveedor.
Después genera el XML, lo guarda dentro de la remesa y pasa el estado a Enviada. En la versión web el navegador descarga el archivo como SEPA_DD_<número>.xml o SEPA_CT_<número>.xml. Ese archivo es el que se sube a la banca electrónica.
Se puede volver a descargar mientras no esté liquidada: regenera el XML y lo pisa.
Vuelve a validar y luego resuelve el método de pago: busca uno activo del tipo que corresponde a la dirección y asociado a la cuenta de la remesa; si no hay, toma cualquiera activo de ese tipo; si tampoco, corta con error de configuración.
Por cada línea con factura e importe positivo crea, en una sola transacción:
La línea queda enlazada a su instrumento y la remesa pasa a Liquidada. Liquidar dos veces no es posible: la acción se deshabilita y la API responde que ya está liquidada.
Una remesa de adeudo con dos facturas, después de liquidar. La de transferencia es simétrica: Orden de Pago en lugar de Recibo, y el instrumento cuelga de la orden.
Un adeudo con una línea, reducido a lo que importa. Cada valor sale de un campo de Sphere; la columna de la derecha dice de cuál.
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.008.001.02"> <CstmrDrctDbitInitn> <GrpHdr> <MsgId>REM-20260909-153012</MsgId> <NbOfTxs>1</NbOfTxs> <CtrlSum>1210.00</CtrlSum> <InitgPty><Nm>EL FARO SL</Nm></InitgPty> </GrpHdr> <PmtInf> <PmtMtd>DD</PmtMtd> <PmtTpInf> <LclInstrm><Cd>CORE</Cd></LclInstrm> <SeqTp>RCUR</SeqTp> </PmtTpInf> <ReqdColltnDt>2026-09-11</ReqdColltnDt> <CdtrAcct><Id><IBAN>ES9121000418450200051332</IBAN></Id></CdtrAcct> <CdtrSchmeId>… <Id>ES23000B12345678</Id> …</CdtrSchmeId> <DrctDbitTxInf> <PmtId><EndToEndId>LINE-412</EndToEndId></PmtId> <InstdAmt>1210.00</InstdAmt> <MndtRltdInf> <MndtId>MND-2025-0042</MndtId> <DtOfSgntr>2025-03-01</DtOfSgntr> </MndtRltdInf> <Dbtr><Nm>HOTEL PLAYA GOLF SA</Nm></Dbtr> <DbtrAcct><Id><IBAN>ES7100300001…</IBAN></Id></DbtrAcct> <RmtInf><Ustrd>Factura 0001-00000018</Ustrd></RmtInf> </DrctDbitTxInf> </PmtInf> </CstmrDrctDbitInitn> </Document>
ReqdExctnDt.| Pieza | Ubicación | Qué hace |
|---|---|---|
| Modelo | Core/Sphere.Module/Model/Treasury/ | Remesa, sus líneas, el mandato del cliente y los parámetros de la propuesta. |
| Lógica compartida | RemittanceViewController.cs | Las tres acciones, la validación, la resolución del método de pago y la liquidación. Común a Blazor y Win. |
| Blazor | RemittanceBlazorViewController.cs | Se engancha a «Descargar SEPA» y hace que el navegador baje el XML guardado. |
| Win | RemittanceWinViewController.cs | Lo mismo con diálogo de guardar archivo. |
| Archivo del banco | SepaXmlService.cs | Construye el pain.008 y el pain.001 a partir de la remesa. |
| Movimiento de tesorería | TreasuryHelper.cs | Crea el movimiento sobre la cuenta bancaria del método de pago, para cualquier cobro o pago de Sphere. |
| API REST | RemittanceController.cs | Replica el circuito completo para clientes externos y Flutter. |
| Llamada | Ruta | Efecto |
|---|---|---|
| GET | /api/remittance | Lista con tipo, estado, cuenta, total y cantidad de líneas. |
| GET | /api/remittance/{id} | Ficha con líneas, factura, saldo pendiente y tercero. |
| POST | /api/remittance | Crea la remesa con cuenta, tipo, vencimiento y lista de facturas. Cada línea toma el saldo pendiente. |
| GET | /api/remittance/{id}/download-sepa | Valida, genera el XML, lo guarda, pasa a Enviada y devuelve el archivo. |
| POST | /api/remittance/{id}/reconcile | Liquida: crea cobros o pagos, aplicaciones y movimientos, y pasa a Liquidada. |
Comportamientos verificados en el código actual que un usuario o un desarrollador puede no esperar.
Descargar el archivo lleva la remesa de Borrador directamente a Enviada. Nada distingue «generé el XML» de «lo subí al banco». Si se quiere ese matiz, hay que asignar el estado intermedio en la descarga y dejar Enviada para una acción aparte.
El documento, el instrumento y la aplicación llevan la fecha del día en que se pulsa Liquidar. Si el banco procesó la remesa días antes, la fecha contable no coincide con la del extracto.
La línea copia el saldo pendiente del momento. Si la factura se cobra parcialmente por otra vía antes de liquidar, la aplicación se hace igual por el importe de la línea. La validación no vuelve a comparar contra el saldo.
Si conviven en la misma remesa un mandato CORE y uno B2B, o un FRST con varios RCUR, el archivo lleva los del primero para todas las líneas. Para remesas mixtas conviene separarlas por esquema y secuencia.
Validación, resolución del método de pago y liquidación viven dos veces, línea por línea idénticas. Un cambio en una tiene que replicarse en la otra hasta que se extraigan a un servicio.
Los dos tipos de método de pago que usa la liquidación se materializan como documento bancario. En el adeudo queda depositado en la cuenta de la remesa; en la transferencia queda como documento propio. Es lo que muestra la cartera de tesorería.
El tenant de demo hostelera trae 35 remesas. Las de referencia son HOR-PAIN001-202607 (pagos a proveedores) y HOR-PAIN008-202607 (adeudos a clientes), ambas con su XML guardado.