Paquetes de extensión

Algunas integraciones son productos en sí mismos — feeds bancarios con credenciales de proveedor, facturación electrónica frente a APIs gubernamentales. REDA Financials estructura estas integraciones como paquetes de extensión: el núcleo define un contrato abstracto global, la extensión lo implementa y un registro de configuración conecta ambos. Hoy se distribuyen dos contratos base, más tres interfaces de capacidad opcionales que un proveedor implementa solo si las necesita.

Cómo funciona el patrón

Ambos contratos siguen la misma arquitectura, y los dos encabezados de clase lo describen con las mismas palabras: "The core package resolves the provider at runtime via: Type.forName(setup.Provider_Class__c).newInstance()". Ningún contrato codifica un proveedor de forma fija. Hay cuatro piezas móviles, cada una con un dueño claro:

refin.BankFeedProvider — extractos bancarios automatizados

• El contrato: tres métodos que aporta una implementación — connect (el flujo de vinculación del proveedor), sync (recuperar transacciones desde el cursor y entregar líneas de extracto), disconnect (revocar el acceso). Los resultados se devuelven en una forma estándar (éxito, transacciones importadas, cursor actualizado, saldo, error).
• La conexión: un registro de Configuración de feed bancario por cada cuenta conectada — nombre del proveedor, entorno (Sandbox/Producción), el nombre de la clase implementadora, cursor y estado de sincronización (Active / Paused / Error / Disconnected), última sincronización. Las configuraciones viven en la página de registro de la cuenta bancaria.
• Las credenciales permanecen en la extensión — el núcleo nunca ve los tokens del proveedor; la extensión gestiona su autenticación de principio a fin.
• El resultado: los extractos llegan como extractos bancarios comunes (con el origen de importación marcado en consecuencia) y fluyen hacia el mismo emparejamiento y conciliación que tendría un CSV — automatización aguas arriba, flujo de trabajo conocido aguas abajo.

El contrato del feed bancario, método por método

Cada método recibe el registro de configuración como contexto. La documentación de la clase describe el modelo: "Each method receives the Bank_Feed_Setup__c record as the primary context — the provider reads the linked bank account and its own credentials to execute sync logic."

global abstract BankFeedResult sync(refin__Bank_Feed_Setup__c setup);

global abstract BankFeedResult connect(
    refin__Bank_Feed_Setup__c setup,
    Map<String, String> params
);

global abstract void disconnect(refin__Bank_Feed_Setup__c setup);

BankFeedResult es una clase interna global — cada miembro es @AuraEnabled global, y el constructor establece por defecto success en false y transactionsImported en 0, de modo que una implementación debe ganarse un éxito:

refin__Bank_Feed_Setup__c — referencia de campos

Un esqueleto de implementación

Así es la forma de un proveedor — el equipo de Meridian esbozando uno contra la API directa de su banco estadounidense. Solo las piezas del contrato son reales; los comentarios marcan dónde va tu lógica de proveedor:

global class MeridianBankFeedProvider extends refin.BankFeedProvider {

    global override refin.BankFeedProvider.BankFeedResult connect(
            refin__Bank_Feed_Setup__c setup, Map<String, String> params) {
        refin.BankFeedProvider.BankFeedResult result =
            new refin.BankFeedProvider.BankFeedResult();
        // Intercambia los parámetros de conexión (p. ej. public_token) con el
        // proveedor. Guarda las credenciales en TU paquete — nunca en objetos del núcleo.
        result.success = true;
        return result;
    }

    global override refin.BankFeedProvider.BankFeedResult sync(
            refin__Bank_Feed_Setup__c setup) {
        refin.BankFeedProvider.BankFeedResult result =
            new refin.BankFeedProvider.BankFeedResult();
        // 1. Recupera las transacciones desde setup.refin__Sync_Cursor__c
        // 2. Entrégalas como líneas de extracto bancario
        // 3. Devuelve el nuevo cursor para que pueda persistirse
        result.transactionsImported = 42;
        result.updatedCursor = 'cursor-after-this-batch';
        result.success = true;
        return result;
    }

    global override void disconnect(refin__Bank_Feed_Setup__c setup) {
        // Revoca tokens y webhooks del lado del proveedor; el núcleo
        // establece Sync_Status en Disconnected después de que esto se complete.
    }
}

refin.EInvoiceProvider — facturación electrónica estatutaria

• El contrato: submit (construir la carga útil de la jurisdicción a partir del documento y llamar a la autoridad), checkStatus (consultar autoridades asíncronas), cancel (aplican reglas específicas de la jurisdicción — la propia nota del contrato cita la ventana de 24 horas de Brasil y la aceptación del receptor en México).
• La conexión: una Configuración de facturación electrónica por entidad/país — proveedor, entorno, clase implementadora, qué tipos de documento participan y una opción Auto Submit On Post; cada intento de envío se registra como un Historial de facturación electrónica en el documento (estado, UUID y número fiscal, cargas útiles, respuesta, cantidad de reintentos) — el rastro de auditoría de cumplimiento que exigen los reguladores.
• Nota de disponibilidad: los historiales y las listas relacionadas son visibles en toda la aplicación (ya has visto Historiales de facturación electrónica en las páginas de facturas); el envío en vivo requiere la extensión de proveedor de tu jurisdicción — confirma con REDA qué está disponible para tu país.

El contrato de facturación electrónica, método por método

Los tres métodos devuelven un EInvoiceResult — miembros: success, status, fiscalUUID, fiscalNumber, responseCode, responseMessage, xmlPayload, responsePayload, errorMessage.

Los objetos de facturación electrónica — referencia de campos

El registro refin__E_Invoice_Trail__c es la fila de auditoría por envío: búsquedas a la configuración y a la factura de origen, Document_Type__c, Status__c, Fiscal_UUID__c, Fiscal_Number__c, XML_Payload__c, los campos de respuesta (Response_Code__c/Message__c/Payload__c/Date__c), Submitted_Date__c, Retry_Count__c y Provider_Document_Id__c — la cadena de evidencia que esperan los reguladores, una fila por intento. Status__c tiene ocho valores: Draft, Ready to Send, Queued, Submitted, Accepted, Rejected, Cancelled, Error.

Interfaces de capacidad opcionales — cómo crece un contrato congelado

refin.EInvoiceProvider se publicó como clase abstracta global en una versión Managed-Released, lo que significa que nunca se le puede añadir un método. En lugar de congelar el marco con ella, REDA añade el comportamiento nuevo como interfaces globales independientes, algo que Salesforce sí permite. Un proveedor extiende EInvoiceProvider y implementa las interfaces de capacidad que admite; el núcleo detecta el soporte con instanceof y simplemente omite la capacidad para los proveedores que no la implementan.

Los tres tipos de datos que intercambian

• refin.EInvoiceEvent: un hito en la vida de un documento ante la autoridad. El núcleo lo correlaciona con un rastro mediante erpDocumentId, un valor que tu proveedor estampa en el sobre saliente y que la autoridad devuelve. status se normaliza a Accepted, Rejected, Cancelled o InProgress: el núcleo basa los reintentos y los estados terminales en ese campo, nunca en el responseCode crudo. También lleva notificationId, processType (Outbound / Inbound), responseMessage, fiscalUUID, fiscalNumber, una lista opcional documents, payload y eventDate.
• refin.EInvoiceDocument: un artefacto, con title, fileExtension ('xml' o 'pdf'), base64Body y documentKind ('Legal', 'LegalResponse' o 'Representation'). El núcleo lo decodifica y lo adjunta al rastro y a la factura de origen como archivos de Salesforce, para que los usuarios vean los artefactos conformes en el registro con el que ya trabajan.
• refin.EInvoiceProvisionResult: success (que por defecto es false), externalId (el identificador del lado del proveedor) y message.

documentKind, processType y status son todos String y no enumeraciones, deliberadamente, para que el conjunto permitido pueda crecer sin romper una firma global congelada. No hagas un switch exhaustivo sobre ellos: gestiona los valores que conoces y deja pasar el resto.

Errores comunes que evitar

Para equipos que construyen una extensión

• Implementa la clase abstracta en el namespace de tu paquete; registra el nombre de clase completo en el registro de configuración.
• Gestiona tus propias credenciales (credenciales con nombre en tu paquete), tu mapeo de API, tu semántica de errores — devuelve resultados honestos; el núcleo los expone en Sync Status y en los historiales.
• Construye solo contra el contrato — la superficie global documentada es la estable (las reglas).

Qué sigue

1. Importación de extractos bancarios — el flujo donde aterrizan los feeds.
2. Integraciones de AppExchange — el panorama más amplio del ecosistema.
3. Desarrollo en Apex sobre REDA — las reglas de la superficie global.

Preguntas frecuentes