Integraciones de AppExchange
Ejecutar tu ERP en Salesforce tiene una ventaja acumulativa: el resto de tu stack probablemente ya se conecta a Salesforce. CRM, procesadores de pago, herramientas de gastos, firma electrónica, gestión documental: las integraciones de AppExchange conviven en el mismo org que tu contabilidad, y "integrar con REDA Financials AI" normalmente se reduce a mapeos de registros ordinarios.
Los encajes naturales
| Categoría | Forma de la integración |
|---|---|
| CRM (¡nativo!) | Los mismos registros de Cuenta SON tus clientes y proveedores — de oportunidad a factura es un Flujo, no un archivo de interfaz. La razón original por la que la contabilidad nativa de Salesforce gana. |
| Procesadores de pago | Las apps de procesadores que escriben registros de pago → mapean las liquidaciones a Recibos de caja (la aplicación automática hace el emparejamiento); los lotes de pagos se concilian como cualquier línea bancaria. |
| Gestión de gastos | Informes de gastos aprobados → Facturas de compra de tipo gasto vía Flujo o API — nacen liquidadas, correctamente contabilizadas. |
| Feeds bancarios / facturación electrónica | Contratos de extensión de primera clase en lugar de integraciones genéricas. |
| Firma electrónica / herramientas documentales | Archivos y enlaces en los mismos registros — un contrato de arrendamiento firmado junto a la plantilla de factura recurrente que autoriza. |
Cómo evaluar cualquier app frente a tu contabilidad — las cuatro preguntas
- ¿Dónde entra el dinero al libro mayor? Toda integración que "crea datos financieros" debe terminar en documentos de REDA (facturas, recibos, asientos) contabilizados a través del motor normal — nunca escrituras directas a las transacciones contables.
- ¿Quién es el usuario de la integración y qué conjunto de permisos tiene? Los conjuntos de permisos empaquetados rigen las escrituras por API exactamente igual que las escrituras desde la interfaz — una app que contabiliza documentos de CxP necesita el conjunto de CxP, y obtiene sus resguardos.
- ¿Qué ocurre si falla? Las validaciones de contabilización rechazan datos incorrectos con mensajes claros — la app debe mostrarlos, no ocultarlos.
- ¿Respeta los bloqueos? La inmutabilidad de los documentos contabilizados, los períodos cerrados, la protección de registros conciliados — una app bien comportada trata un rechazo como una respuesta.
Lo que encontrará tu revisión de seguridad
Cuando el equipo de seguridad audita el org antes de aprobar una nueva app junto a REDA Financials AI, esta es la huella completa de salida del paquete — lo bastante pequeña para memorizarla:
| Elemento | Qué incluye | Para qué es |
|---|---|---|
Sitio remoto OCR_API | Ver Remote Site Settings en tu org | Endpoint del servicio de IA de REDA para las funciones de REDA Financials AI (OCR, conciliación bancaria) — no relacionado con el producto REDA AI independiente |
Sitio remoto Open_Exchange_Rates | Ver Remote Site Settings en tu org | API de Open Exchange Rates para la sincronización diaria automática de tipos de cambio en DatedConversionRate, mediante un servicio interno del paquete |
| Named credentials | Ninguno | — |
| Connected apps | Ninguno | — |
| Webhooks entrantes / endpoints REST personalizados | Ninguno | — |
Todo lo demás que se comunica con tu org — los callbacks de la app de pagos, el OAuth del middleware — pertenece a esas apps y a la configuración propia de tu org, gobernada por tus políticas. Esa separación es lo que hace la revisión manejable: la superficie propia de REDA nunca crece porque hayas instalado algo junto a ella.
Aprovisionar el usuario de integración
| La app hace… | Otorga este conjunto de permisos empaquetado |
|---|---|
| Crea y contabiliza documentos de clientes (facturación, cobros) | Accounts Receivable v2 |
| Crea y contabiliza documentos de proveedores (facturas, pagos) | Accounts Payable v2 |
| Lee datos financieros para reportes/BI | Read Only v2 |
| Interfaces a nivel de asiento (nómina, consolidación) | Accounting Controller v2 |
| Administra la configuración de forma programática | Accounting Admin v2 — con moderación, y solo cuando sea realmente necesario |
Usa los conjuntos v2. Desde la versión 1.610 son los que hay que asignar, y los únicos que pueden asignarse a un usuario con licencia Salesforce Platform; los conjuntos v1 sin sufijo están obsoletos. Agrega un asiento de licencia REDA para cualquier usuario que escriba documentos contables — la verificación de licencia se aplica a las escrituras por API exactamente igual que a los humanos. Una app, un usuario, un conjunto de permisos: los inicios de sesión de "integración" compartidos entre apps hacen que toda pregunta de auditoría quede sin respuesta.
Errores comunes que evitar
| Error | Por qué perjudica | Haz esto en su lugar |
|---|---|---|
| Dejar que una app escriba "registros financieros" solo en sus propios objetos | El dinero existe en la app pero no en tu contabilidad — el libro mayor queda ciego a él | Exige que la integración termine en documentos de REDA contabilizados; los registros de la app pueden vincularse a ellos |
| Otorgar al usuario de integración Accounting Admin "por seguridad" | Cada falla de la app ahora tiene un radio de impacto a nivel de configuración | El conjunto empaquetado más acotado que cumpla la función; escala solo con evidencia |
| Omitir el mapeo de Referencia | No hay clave de idempotencia, ni rastro de conciliación de vuelta al sistema de origen | Mapea el identificador de transacción de la app al campo Referencia en cada documento que crea |
| Asumir que la app "maneja la contabilidad" porque contabiliza con éxito | Contabilizar demuestra la validez de los datos, no la política contable — mapeos de cuentas contables incorrectos se contabilizan sin problema | Haz que el contralor revise el mapeo de documentos de la app (cuentas contables, entidades, impuestos) antes de la puesta en producción, y luego haga verificaciones puntuales mensuales |
Qué sigue
- API REST para datos contables — la mecánica que hay debajo de la mayoría de las apps.
- Paquetes de extensión — los contratos hechos a propósito.
- Descripción general de la API — el mapa completo, en una sola página.
Preguntas frecuentes
La interfaz de asiento clásica: el sistema de nómina exporta el resumen, un job programado (o la carga de CSV del formulario de asiento contable, para la versión manual) crea el asiento mensual. Las plantillas recurrentes se encargan del patrón de devengo fijo entre corridas.
La respuesta duradera es la arquitectura: cualquier cosa que escriba borradores limpios a través de la API se integra bien. Para conocer las apps de socios y extensiones de proveedores vigentes, consulta con REDA: los ecosistemas cambian más rápido que los manuales.
Ambos funcionan: el middleware habla las mismas API REST/Bulk. Elige según el modelo operativo de tu equipo; el patrón del lado de REDA (borrador → contabilizar → eventos) es idéntico en ambos casos.
Los triggers y las validaciones del paquete se ejecutan en cada escritura sin importar quién escriba: otra app no puede desactivarlos, y no hay ninguna bandera de omisión que pueda encontrar. Lo que sí puede colisionar es la lógica de negocio: dos sistemas creando recibos para los mismos pagos, por ejemplo. Eso es una cuestión de diseño de integración, no un riesgo de la plataforma.
Son el caso especial con contratos de primera clase: en lugar de un mapeo genérico de registros, los proveedores implementan refin.BankFeedProvider o refin.EInvoiceProvider y se registran en un registro de configuración. Consulta Paquetes de extensión — evaluar esas apps empieza por el contrato, no por las cuatro preguntas anteriores.
¿Te resultó útil?