Descripción general de la API
Esta sección está escrita para administradores y desarrolladores de integraciones: el único rincón de esta base de conocimientos donde tienen cabida los nombres de clases de Apex.
REDA Financials es nativo de Salesforce hasta la médula: cada documento es un objeto personalizado, cada contabilización es un cambio de estado impulsado por un trigger, y por lo tanto cada API estándar de Salesforce funciona sobre tus datos contables desde el primer momento. Sobre esa superficie de plataforma, el paquete expone un conjunto pequeño y deliberado de contratos estables. Esta descripción general mapea todo el panorama de integración.
Las cuatro capas de integración
| Capa | Qué es | Artículo |
|---|---|---|
| APIs estándar de Salesforce | REST, Bulk y (si el org lo habilita) streaming contra los objetos refin__: CRUD, consultas, cargas masivas. La capa de uso más frecuente. | REST · Bulk · Streaming |
| La API global de Apex | Cinco clases globales estables (a continuación) para cálculo de impuestos, generación de PDF, recepción de correo y contratos de extensión de proveedores. | Apex Development |
| Puntos de enganche declarativos | Una acción de Flujo empaquetada ("Generate PDF Document") más el patrón de que contabilizar = una actualización del campo de estado que cualquier Flujo puede realizar. | Flows Integration |
| Extensibilidad sin código | Field sets que extienden formularios, dimensiones del libro mayor y PDFs sin tocar código. | Extensibilidad de FieldSets |
Todo lo que se incluye — y todo lo que deliberadamente no
La planificación de integraciones empieza con un inventario honesto. Aquí está la superficie empaquetada completa — y, tan útil como lo anterior, las cosas que podrías buscar y que no están, porque la plataforma estándar ya las provee:
| Superficie | Qué se incluye | Dónde se cubre |
|---|---|---|
| Clases globales de Apex | Cinco: refin.GlobalTaxService, refin.PDFGeneratorAPI, refin.BankFeedProvider, refin.EInvoiceProvider, refin.OCREmailHandler | Apex Development · Paquetes de extensión |
| Acciones invocables de Flujo | Exactamente una: Generate PDF Document (categoría "REDA Financials") | Flows Integration |
| Objetos y campos personalizados | Cada documento, línea y registro del libro mayor es un objeto personalizado refin__ corriente — CRUD y consultas completas a través de las APIs estándar | REST · Bulk |
| Field sets | 43 field sets empaquetados en los objetos transaccionales, agrupados en tres familias (Interface, Posting_Mapping, PDF_Template) — editables por el administrador, sin código | Extensibilidad de FieldSets |
| Endpoints REST personalizados | Ninguno — no se incluye ninguna clase @RestResource; los endpoints estándar de sObject, consulta y composite son la superficie REST | REST API |
| Eventos de plataforma / CDC | Ninguno empaquetado; Change Data Capture sobre los objetos refin__ es una capacidad estándar del org que tu administrador puede habilitar | Streaming |
| Named credentials / connected apps | Ninguno se incluye — las integraciones se autentican a través de la connected app y el flujo OAuth propios de tu org, bajo tus propias políticas | — |
| Llamadas salientes (callouts) | Exactamente dos: el servicio de IA de REDA para las funciones de IA (incluido con la licencia de REDA Financials AI) y Open Exchange Rates para la sincronización diaria del tipo de cambio | Funciones de IA · Sincronización de FX |
La superficie global de Apex — la lista completa
Trece tipos globales constituyen el contrato estable de Apex del paquete. Cinco son los puntos de entrada del día a día:
refin.GlobalTaxService— calcula impuesto indirecto y retención de impuestos de forma programática, sin DML, con resultados totalmente resueltos contra el libro mayor.refin.PDFGeneratorAPI— genera el PDF de un documento desde Apex o Flujo.refin.BankFeedProvider— el contrato abstracto que implementan los paquetes de extensión de feed bancario.refin.EInvoiceProvider— el contrato abstracto que implementan los proveedores de facturación electrónica.refin.OCREmailHandler— el manejador de correo entrante detrás de correo a factura; apunta un Email Service hacia él.
Los ocho restantes existen para los paquetes de extensión: los contratos de facturación electrónica y los tipos que intercambian, más dos puntos de entrada que llamas directamente:
refin.EInvoiceQueueProvider,refin.EInvoiceDocumentProvider,refin.EInvoiceProvisioner— interfaces globales añadidas junto aEInvoiceProvider, porque una clase abstracta global ya publicada no puede ganar métodos sin romper los paquetes que ya la extienden.refin.EInvoiceDocument,refin.EInvoiceEvent,refin.EInvoiceProvisionResult— los tipos de transferencia de datos que esos contratos reciben y devuelven.refin.EInvoiceStatusPollSchedulable— programa el sondeo de estado de facturación electrónica con tu propio cron en lugar de la tarjeta de la Consola de administración.refin.EInvoiceTrailCreator— crea un rastro de factura electrónica para facturas de venta contabilizadas; también se expone como acción de Flow.
Todo lo demás en el paquete es public — interno, invisible entre namespaces, y sujeto a cambios. Si una clase no está en esta lista, no construyas nada que dependa de ella.
Los servicios internos no son API — aunque puedas verlos
Al leer los debug logs y los conjuntos de permisos, te encontrarás con clases de servicio internas detrás de acciones cotidianas — contabilización, renderizado de PDF, importación de estados de cuenta bancarios, llamadas de IA y de FX, carga inicial de contenido fiscal. Son public, no global — el Apex del suscriptor y de las extensiones no puede llamarlas a través del límite del namespace, y su forma interna puede cambiar en cualquier versión, así que nada de lo que construyas debería referenciarlas por nombre:
| Qué ocurre internamente | La ruta admitida en su lugar |
|---|---|
| El motor de contabilización detrás de cada transición de Borrador a Contabilizado | Actualiza refin__Status__c a "Posted" — el trigger ejecuta el motor por ti |
| El motor detrás de la acción de Actualización masiva de estados en la vista de lista, que nunca omite las validaciones estándar de contabilización | La acción de la vista de lista, o tus propias actualizaciones masivas de estado mediante las APIs |
| Los internos del renderizado de PDF | refin.PDFGeneratorAPI.generateOne o la acción de Flujo |
| Los internos de la importación de estados de cuenta bancarios | El contrato BankFeedProvider y las escrituras mediante la API estándar |
| Las dos rutas de llamadas salientes (IA, tipos de cambio) | Opéralas desde la Consola de administración; no son superficies invocables |
| La carga inicial del contenido fiscal por país detrás del Asistente de configuración de impuestos | Ejecuta el asistente desde la interfaz |
refin.PDFGeneratorAPI y refin.EInvoiceTrailCreator, las dos que respaldan acciones de Flujo empaquetadas. refin.GlobalTaxService, refin.BankFeedProvider, refin.OCREmailHandler y los tipos de contrato de facturación electrónica no los otorga ningún conjunto de permisos empaquetado; otorga esos tú mismo donde tu contexto de Flujo o Apex lo requiera.
Versionado y seguridad ante actualizaciones
Las clases de API del paquete están compiladas en la versión 65.0 de la API de Salesforce — refin.GlobalTaxService se declara a sí misma como "@since API v65.0". La regla de los paquetes gestionados (managed packages) es la columna vertebral de tu planificación:
- Lo global es para siempre: una vez publicadas, las clases, métodos y variables miembro globales no pueden ser eliminados ni cambiar de firma por parte del publicador. Los trece tipos anteriores, las acciones de Flujo que exponen, y cada objeto y campo
refin__publicado son tu superficie estable. - Lo público es privado, en la práctica: las clases internas pueden renombrarse, remodelarse o eliminarse en cualquier versión — y como son invisibles entre namespaces, nada de lo que publiques puede romperse por depender de ellas, porque nada de lo que publiques puede depender de ellas.
- El comportamiento viaja a través de los triggers: los 52 triggers empaquetados se ejecutan sobre el DML de la API de forma idéntica en todas las actualizaciones — no hay bandera de omisión que se pueda perder, ni un modo especial que volver a probar.
Una integración típica, en trazo grueso
El sistema de administración de propiedades de Meridian Properties Group factura a los inquilinos; REDA lleva la contabilidad. La integración nocturna se autentica a través de la connected app propia de Meridian como un usuario de integración que posee Cuentas por cobrar, inserta cada factura como un refin__Sales_Invoice__c en borrador junto con sus líneas, y luego actualiza cada una a Contabilizada en una segunda llamada. Los números de documento se asignan desde las secuencias de la entidad al insertar, los valores predeterminados de la entidad se completan, y la contabilización ejecuta el motor completo — impuestos, tipos de cambio, validaciones de período. Cuando un registro falla (un período cerrado, por ejemplo), el mensaje de error que devuelve la API es la misma frase que leería un usuario en pantalla, lo que hace que las conversaciones de soporte sean breves. Código personalizado total dentro de REDA: ninguno.
El único principio que hace fácil la integración
La API y la interfaz son la misma máquina. Inserta una factura en borrador vía REST y recibe su número de documento, sus valores predeterminados de entidad y sus validaciones exactamente igual que si se hubiera escrito a mano. Actualiza su estado a Contabilizada y se ejecuta el motor de contabilización completo — impuestos, retenciones, tipos de cambio, cada validación. No existe una puerta trasera para integraciones, lo que significa que no hay nada especial que aprender: lo que puede hacer un usuario, puede hacerlo un usuario de API, bajo las mismas reglas y los mismos conjuntos de permisos.
Qué sigue
- API REST para datos contables — la integración del primer día.
- Desarrollo en Apex sobre REDA — las clases globales en detalle.
- Paquetes de extensión — los contratos de proveedor.
Preguntas frecuentes
Sí — eso es justamente lo que significa "global" en un managed package: las firmas globales publicadas no pueden eliminarse ni cambiarse. Esa garantía es precisamente por qué la superficie se mantiene pequeña.
El mismo conjunto de permisos empaquetado que tendría una persona haciendo ese trabajo (una integración de cuentas por pagar contabiliza facturas → Cuentas por pagar). Los triggers hacen cumplir las mismas reglas tanto para escrituras de API como de interfaz; no hay que inventar un perfil de integración aparte.
Configuración → Object Manager — cada objeto de REDA está ahí bajo el prefijo refin__ (por ejemplo, refin__Sales_Invoice__c, refin__Status__c). Las llamadas describe estándar también funcionan, por supuesto.
No — es public, así que la propia plataforma lo hace invisible para tu namespace. La ruta admitida (e igualmente segura para operaciones masivas) es la actualización del campo de estado: el trigger invoca el motor con cobertura completa de validaciones.
Se incluyen exactamente dos destinos de llamadas salientes: el servicio de IA de REDA (las funciones de IA, incluidas con la licencia de REDA Financials AI) y Open Exchange Rates (sincronización diaria de tipo de cambio, orgs multimoneda). Sin webhooks, sin otros endpoints — cualquier otra cosa que veas en una revisión de seguridad no es de REDA.
¿Te resultó útil?