Integrações do AppExchange
Rodar seu ERP no Salesforce traz uma vantagem cumulativa: o resto do seu ecossistema provavelmente já se conecta ao Salesforce. CRM, processadores de pagamento, ferramentas de despesas, assinatura eletrônica, gestão de documentos — as integrações do AppExchange chegam à mesma organização em que estão os seus livros contábeis, e "integrar com a REDA Financials" costuma se reduzir a mapeamentos de registros comuns.
Os encaixes naturais
| Categoria | Formato da integração |
|---|---|
| CRM (nativo!) | Os mesmos registros de Conta SÃO seus clientes e fornecedores — de oportunidade a fatura é um Fluxo, não um arquivo de interface. A razão original pela qual finanças no Salesforce vence. |
| Processadores de pagamento | Aplicativos de processadora que gravam registros de pagamento → mapeiam liquidações para Recebimentos (a aplicação automática faz a correspondência); lotes de repasse são conciliados como qualquer linha bancária. |
| Gestão de despesas | Relatórios de despesas aprovados → Faturas de compra do tipo despesa via Fluxo ou API — já nascem liquidadas e corretamente contabilizadas. |
| Feeds bancários / nota fiscal eletrônica | Contratos de extensão de primeira classe em vez de integrações genéricas. |
| Assinatura eletrônica / ferramentas de documentos | Arquivos e links nos mesmos registros — um contrato de locação assinado ao lado do modelo de fatura recorrente que ele autoriza. |
Avaliando qualquer aplicativo em relação aos seus livros contábeis — as quatro perguntas
- Onde o dinheiro entra no livro razão? Toda integração que "cria dados financeiros" deve terminar em documentos REDA (faturas, recebimentos, lançamentos contábeis) contabilizados pelo motor normal — nunca gravações diretas em transações contábeis.
- Quem é o usuário de integração e qual conjunto ele possui? Os conjuntos de permissões empacotados regem gravações via API exatamente como gravações via interface — um aplicativo que contabiliza documentos de contas a pagar precisa do conjunto de Contas a Pagar, e recebe as proteções desse conjunto.
- O que acontece em caso de falha? Os controles de contabilização recusam dados incorretos com mensagens claras — o aplicativo deve exibi-las, não engoli-las.
- Ele respeita os bloqueios? Imutabilidade de documentos contabilizados, períodos fechados, proteção de registros conciliados — um aplicativo bem-comportado trata uma recusa como uma resposta.
O que sua revisão de segurança vai encontrar
Quando a equipe de segurança audita a organização antes de aprovar um novo aplicativo ao lado da REDA Financials, esta é a superfície de saída completa do pacote — pequena o suficiente para memorizar:
| Item | O que é entregue | Para que serve |
|---|---|---|
Site remoto OCR_API | Veja Remote Site Settings na sua organização | Endpoint do serviço de IA da REDA para os recursos da REDA Financials AI (OCR, Conciliação Bancária) — sem relação com o produto separado REDA AI |
Site remoto Open_Exchange_Rates | Veja Remote Site Settings na sua organização | API Open Exchange Rates para sincronização diária automatizada de taxas de câmbio em DatedConversionRate, via um serviço interno do pacote |
| Credenciais nomeadas | Nenhuma | — |
| Aplicativos conectados | Nenhum | — |
| Webhooks de entrada / endpoints REST personalizados | Nenhum | — |
Tudo o mais que se comunica com sua organização — os callbacks do aplicativo de pagamento, o OAuth do middleware — pertence a esses aplicativos e à configuração da sua própria organização, governada pelas suas políticas. Essa separação é o que torna a revisão tratável: a própria superfície da REDA nunca cresce só porque você instalou algo ao lado dela.
Provisionando o usuário de integração
| O aplicativo faz… | Conceda este conjunto de permissões empacotado |
|---|---|
| Cria e contabiliza documentos de clientes (faturamento, recebimentos) | Accounts Receivable v2 |
| Cria e contabiliza documentos de fornecedores (contas, pagamentos) | Accounts Payable v2 |
| Lê dados financeiros para relatórios/BI | Read Only v2 |
| Interfaces em nível de lançamento contábil (folha de pagamento, consolidação) | Accounting Controller v2 |
| Administra a configuração programaticamente | Accounting Admin v2 — com moderação, e só quando genuinamente necessário |
Use os conjuntos v2. A partir da versão 1.610 são eles que devem ser atribuídos, e os únicos que podem ser atribuídos a um usuário com licença Salesforce Platform; os conjuntos v1 sem sufixo estão obsoletos. Adicione uma licença REDA para qualquer usuário que grave documentos contábeis — a verificação de licença se aplica a gravações via API exatamente como a humanos. Um aplicativo, um usuário, um conjunto: logins de "integração" compartilhados entre aplicativos tornam toda pergunta de auditoria impossível de responder.
Erros comuns a evitar
| Erro | Por que isso prejudica | Faça isto em vez disso |
|---|---|---|
| Deixar um aplicativo gravar "registros financeiros" apenas em seus próprios objetos | O dinheiro existe no aplicativo, mas não nos seus livros contábeis — o livro razão fica cego para ele | Exija que a integração termine em documentos REDA contabilizados; os registros do aplicativo podem se vincular a eles |
| Conceder Accounting Admin ao usuário de integração "por segurança" | Toda falha do aplicativo agora tem um raio de impacto no nível de configuração | Use o conjunto empacotado mais restrito que cumpra a tarefa; escale apenas com evidências |
| Pular o mapeamento de Reference | Sem chave de idempotência, sem trilha de conciliação de volta ao sistema de origem | Mapeie o identificador da transação do aplicativo no campo Reference de cada documento que ele cria |
| Presumir que o aplicativo "cuida da contabilidade" porque contabiliza com sucesso | A contabilização comprova a validade dos dados, não a política contábil — mapeamentos de conta contábil errados são contabilizados normalmente | Peça ao controller para revisar o mapeamento de documentos do aplicativo (contas contábeis, entidades, impostos) antes da entrada em produção e depois fazer verificações pontuais mensais |
O que vem a seguir
- REST API para dados contábeis — a mecânica por trás da maioria dos aplicativos.
- Pacotes de extensão — os contratos construídos para esse propósito.
- Visão geral da API — o mapa completo, em uma página.
Perguntas frequentes
A interface clássica de lançamento contábil: o sistema de folha de pagamento exporta o resumo, um job agendado (ou o upload de CSV do formulário de lançamento contábil, na versão manual) cria o lançamento mensal. Modelos recorrentes tratam do padrão fixo de provisionamento entre execuções.
A resposta durável é a arquitetura: qualquer coisa que grave rascunhos limpos pela API se integra bem. Para os aplicativos parceiros e extensões de provedores atuais, consulte a REDA — os ecossistemas mudam mais rápido do que os manuais.
Ambos funcionam — o middleware fala as mesmas APIs REST/Bulk. Escolha de acordo com o modelo operacional da sua equipe; o padrão do lado da REDA (rascunho → contabilização → eventos) é idêntico de qualquer forma.
Os triggers e as validações do pacote rodam em toda gravação, independentemente de quem grava — outro aplicativo não consegue desligá-los, e não há flag de bypass para ele encontrar. O que pode colidir é a lógica de negócio: dois sistemas criando recebimentos para os mesmos pagamentos, por exemplo. Isso é uma questão de design de integração, não um risco de plataforma.
São o caso especial com contratos de primeira classe: em vez de mapeamento genérico de registros, os provedores implementam refin.BankFeedProvider ou refin.EInvoiceProvider e se registram em um registro de configuração. Veja Pacotes de extensão — avaliar esses aplicativos começa pelo contrato, não pelas quatro perguntas acima.
Isso foi útil?