REDA Financials Monsoon 2026 · v1.610 2 Aug 2026

REDA Financials AI — Monsoon 2026 (v1.610)

Esta versão acrescenta o faturamento eletrônico: a REDA Financials já consegue transmitir uma fatura de venda para a autoridade fiscal de um país como parte da contabilização e registrar a resposta da autoridade na própria fatura. Ela também reconstrói os conjuntos de permissões empacotados para que possam ser atribuídos a usuários com licença Salesforce Platform, corrige os pacotes de retenção na fonte de dezessete países e resolve uma falha de contabilização que ocorria quando um dos seus próprios campos de dimensão era uma fórmula.

Três passos manuais, ou a versão não faz nada. A atualização instala os componentes novos, mas não os mostra a ninguém — e há um valor novo que ela simplesmente não instala. Percorra O que a atualização não faz por você antes de anunciar o recurso aos usuários. O faturamento eletrônico não funciona enquanto o valor Pronto para enviar da lista de seleção não existir na sua organização.

O número da versão mudou de formato — você não retrocedeu. A Financials agora usa um número secundário de três dígitos: 1.610 significa onda 6, versão de recurso 1, patch 0. Ela vem depois da 1.6.0. O próximo patch será 1.611 e a próxima versão de recurso, 1.620.

Como obter esta versão

Atualize o pacote REDA Financials na sua organização do mesmo modo que instala qualquer pacote gerenciado. Para confirmar que você a tem, abra Configuração → Pacotes instalados e verifique se a coluna Número da versão ao lado de REDA Financials mostra 1.610 ou superior. Tudo o que está descrito aqui se refere a essa versão; se a coluna ainda mostrar 1.6 ou inferior, a atualização não foi concluída e nenhum destes passos encontrará os componentes a que se refere.

O que a atualização não faz por você

A atualização de um pacote gerenciado do Salesforce é deliberadamente conservadora: ela não sobrescreve a configuração que você alterou. Isso protege a sua organização, mas significa que há três coisas que um administrador precisa fazer à mão em cada organização que é atualizada. Se faltar qualquer uma delas, o recurso fica invisível ou quebrado.

O que a atualização pula	Por quê	O que acontece se você pular também
Colocar os campos novos nos seus layouts de página	Uma atualização nunca acrescenta um campo a um layout que você tenha personalizado, e quase toda organização em produção personalizou os seus. Só os layouts padrão do pacote, intocados, recebem os campos automaticamente.	Os campos existem e guardam dados, mas ninguém consegue vê-los no registro.
*Conceder a segurança em nível de campo nos seus* conjuntos de permissões**	Os campos novos são concedidos nos cinco conjuntos de permissões empacotados `_v2`. Isso só alcança os usuários que tenham esses conjuntos atribuídos. Se a sua organização usa os próprios conjuntos de permissões ou perfis — a maioria usa —, nada foi concedido a eles.	Os usuários não veem nada, não importa o que diga o layout de página. «Está nos conjuntos de permissões» não é o mesmo que «os seus usuários têm acesso».
*Acrescentar o valor novo Pronto para enviar* à lista de seleção**	Uma atualização acrescenta campos novos, mas nunca acrescenta um valor novo a uma lista de seleção que a sua organização já tem. O campo Status em Histórico de fatura eletrônica já existia antes desta versão, então o valor novo não chega. Só recebe esse valor a organização que instalar do zero na 1.610.	O faturamento eletrônico falha por completo — veja abaixo. Este não é um detalhe estético.

Todos os campos novos desta versão

Estes são os campos que a atualização instala. Cada um precisa ser colocado nos layouts que os seus usuários realmente abrem e, se você não usa os conjuntos de permissões empacotados, precisa receber a segurança em nível de campo.

Objeto	Campo	Tipo	Acesso	Seção do layout
Fatura de venda	Status de fatura eletrônica	Lista de seleção	Somente leitura para todos: quem define é o sistema	Faturamento eletrônico
Fatura de venda	UUID de fatura eletrônica	Texto	Somente leitura para todos: quem emite é a autoridade	Faturamento eletrônico
Fatura de venda	Ignorar fatura eletrônica	Caixa de seleção	Editável — Accounting Admin, Accounts Receivable	Faturamento eletrônico
Histórico de fatura eletrônica	ID do documento do provedor	Texto	Somente leitura para todos	Detalhes do histórico

Também chegam dois objetos novos com as suas guias: Configuração de fatura eletrônica (a configuração por entidade) e Histórico de fatura eletrônica (o registro de auditoria). Se você usa os seus próprios conjuntos de permissões, conceda as permissões de objeto e a visibilidade de guia para ambos.

Os nomes dos conjuntos de permissões aparecem em inglês. O pacote traduz os rótulos de campo e os valores das listas de seleção, mas não os nomes dos conjuntos de permissões. Procure por eles exatamente assim: Accounting Admin, Accounting Controller, Accounts Payable, Accounts Receivable e Read Only, cada um com o sufixo _v2.

O que um administrador precisa fazer, em cada organização

Coloque os campos nos seus layouts de página. Vá em Configuração → Gerenciador de objetos → Fatura de venda → Layouts de página, abra cada layout que os seus usuários realmente usam e arraste Status de fatura eletrônica, UUID de fatura eletrônica e Ignorar fatura eletrônica para uma seção Faturamento eletrônico — crie a seção se o seu layout não tiver nenhuma — e clique em Salvar. Repita em Histórico de fatura eletrônica para ID do documento do provedor. Faça isso em todos os layouts e todos os tipos de registro em uso: um campo colocado em um layout continua invisível nos demais.
Conceda a segurança em nível de campo se você não usa os conjuntos de permissões empacotados. Configuração → Gerenciador de objetos → o objeto → Campos e relacionamentos → o campo → Definir segurança em nível de campo → marque Visível para cada um dos seus perfis ou conjuntos de permissões. Deixe Somente leitura marcado em Status de fatura eletrônica, UUID de fatura eletrônica e ID do documento do provedor. Desmarque apenas em Ignorar fatura eletrônica, e só para quem deve poder excluir uma fatura da transmissão.
Conceda o acesso ao objeto e a visibilidade de guia de Configuração de fatura eletrônica e Histórico de fatura eletrônica aos seus próprios conjuntos de permissões, se você não usa os nossos.
Acrescente o valor Pronto para enviar à lista de seleção Status de Histórico de fatura eletrônica. Toda organização que atualizar para a 1.610 precisa fazer isso: veja a seção seguinte para os passos exatos e para entender por que ela é a mais importante.
Acrescente Ignorar fatura eletrônica ao conjunto de campos Interface de Fatura de venda. Fatura de venda usa um formulário de entrada próprio, então um campo colocado no layout de página é exibido mas não pode ser preenchido. Vá em Configuração → Gerenciador de objetos → Fatura de venda → Conjuntos de campos → Interface e acrescente o campo ali também. Ele vem disponível mas não selecionado, porque a maioria das organizações nunca transmite faturas eletronicamente.
Defina quem pode liberar os documentos retidos, se você transmite manualmente. Os cinco conjuntos de permissões empacotados concedem somente leitura sobre Histórico de fatura eletrônica, e isso é deliberado: ele é a evidência de auditoria que o sistema escreve. Liberar um documento retido e tentar de novo um que deu erro exigem editar o registro, então, de fábrica, só um administrador do sistema consegue fazer qualquer uma das duas coisas. Para delegar: Configuração → Conjuntos de permissões → Novo → Configurações de objeto → Históricos de fatura eletrônica → marque Editar e atribua-o às pessoas responsáveis por essa fila.

O valor Pronto para enviar — o passo que quebra o recurso

Toda organização que atualizar precisa fazer isso. Não é um «verifique se você é afetado». O campo Status em Histórico de fatura eletrônica é uma lista de seleção restrita, o que significa que a plataforma rejeita qualquer valor que não esteja definido nela. Enquanto você não acrescentar Pronto para enviar, um Histórico não consegue entrar nesse status: em uma entidade configurada para enviar automaticamente na contabilização, a criação do Histórico falha por completo em vez de degradar em silêncio, e ninguém consegue liberar um Histórico retido à mão.

Abra Configuração → Gerenciador de objetos → Histórico de fatura eletrônica → Campos e relacionamentos → Status.
Nos valores da lista de seleção, escolha Novo, digite Pronto para enviar — com exatamente essa grafia e essas maiúsculas — e clique em Salvar. O aplicativo escreve uma cadeia literal, então um quase acerto como «Pronto Para Enviar» continua falhando mesmo parecendo correto à vista.
Escolha Reordenar e mova o valor novo para logo abaixo de Rascunho, para que a lista seja lida na ordem que o processo realmente segue.
Confirme que o campo agora oferece os oito valores: Rascunho, Pronto para enviar, Na fila, Enviado, Aceito, Rejeitado, Erro, Cancelado. Se ele listar apenas sete, este passo não foi feito e o envio automático vai falhar.

Novidades

Enviar faturas eletronicamente para uma autoridade fiscal

Os países que exigem faturamento eletrônico requerem que cada fatura de venda seja transmitida à autoridade fiscal e volte com um identificador fiscal oficial antes de ser legalmente válida. A REDA Financials já faz isso como parte da contabilização, então ninguém precisa redigitar faturas em um portal do governo.

Você configura a Configuração de fatura eletrônica uma vez por entidade: qual país, quais tipos de documento entram no escopo e se o envio acontece automaticamente na contabilização ou espera que uma pessoa o libere. Quando uma fatura é contabilizada, um registro de Histórico de fatura eletrônica é criado para ela: um Histórico por fatura, que guarda toda a conversa com a autoridade — o que foi enviado, o que voltou, o identificador fiscal e cada nova tentativa. A própria fatura ganha um Status de fatura eletrônica e um UUID de fatura eletrônica, para que o usuário veja a situação sem sair da fatura.

Um Histórico percorre uma sequência definida: Rascunho (criado, aguardando liberação) → Pronto para enviar → Na fila → Enviado → Aceito ou Rejeitado, com Erro para o que não pôde ser entregue e Cancelado para um documento retirado. Como muitas autoridades respondem de forma assíncrona — minutos ou horas depois, não na mesma requisição —, uma verificação agendada leva os documentos enviados ao seu status final.

Uma fatura enviada não pode ser descontabilizada nem alterada. Isso é uma exigência legal, não uma restrição da REDA: a autoridade já tem o documento. Corrija-a emitindo uma nota de crédito.

Duas coisas são tratadas de forma explícita. A criação do Histórico é executada depois que a fatura é confirmada, então um problema para alcançar a autoridade nunca pode estornar nem bloquear a própria contabilização. E uma caixa de seleção Ignorar fatura eletrônica na fatura de venda exclui aquela fatura por completo.

Conectar-se à autoridade de um país específico exige um pacote de extensão; o aplicativo principal entrega a estrutura e o registro de auditoria. Guias completos: Visão geral do faturamento eletrônico, Configuração de fatura eletrônica, Histórico de fatura eletrônica, Faturar eletronicamente uma fatura de venda e Extensões de faturamento eletrônico.

Verificação de status de fatura eletrônica — um novo cartão em Operações

As autoridades fiscais respondem no seu próprio ritmo. A Verificação de status de fatura eletrônica pergunta à autoridade, uma vez por dia no horário que você escolher, o que aconteceu com todas as faturas ainda paradas em Enviado, e move cada uma para Aceito ou Rejeitado. Ela aparece como o décimo segundo cartão em Console de administração → Operações, ao lado dos demais trabalhos agendados, com os mesmos controles de Agendar / Reagendar / Desagendar / Executar agora e uma contagem ao vivo de quantos documentos estão aguardando e quantos estão com erro.

Agendá-la é um passo obrigatório de configuração, não uma otimização. Um trabalho agendado não pode ser incluído em um pacote gerenciado: cada organização precisa criar o seu. Se ninguém agendar, as faturas ficam em Enviado indefinidamente e ninguém é avisado do motivo. Vá em Console de administração → Operações → Verificação de status de fatura eletrônica, escolha um horário e clique em Agendar.

Executar agora faz a verificação imediatamente, sem esperar a próxima execução. Ela faz uma chamada por documento enviado, então trate-a como uma ação deliberada e não como um botão de atualizar. As organizações que não transmitem faturas eletronicamente veem uma nota curta de «ainda não existe uma configuração ativa» no cartão e podem ignorá-lo. Guias completos: Verificação de status de fatura eletrônica e a guia Operações.

Correções

Conjuntos de permissões reconstruídos para poder atribuí-los a usuários Platform

Os cinco conjuntos de permissões empacotados estavam vinculados a uma licença de usuário Salesforce. Qualquer organização cujos usuários de contabilidade tivessem uma licença Salesforce Platform — a maioria — simplesmente não conseguia atribuí-los, e a mensagem de erro não explicava o motivo. A licença de um conjunto de permissões não pode ser alterada depois de criado, então a única solução foi entregar substitutos.

Agora há cinco conjuntos de permissões novos, idênticos em conteúdo e sem restrição de licença: Accounting Admin, Accounting Controller, Accounts Payable, Accounts Receivable e Read Only, cada um com o sufixo _v2.

Este é um passo de migração obrigatório. Atribua primeiro o conjunto _v2 a cada usuário e só depois remova o antigo: essa ordem evita que alguém fique sem acesso no meio da mudança. Ambos concedem o mesmo acesso; o que muda é apenas o vínculo com a licença. Os cinco originais continuam instalados e funcionando para usuários com licença Salesforce completa; eles não podem ser excluídos de um pacote publicado, então trate-os como obsoletos e pare de atribuí-los.

Guias completos: Conjuntos de permissões, Atribuição de licenças, Configuração pós-instalação, Checklist de entrada em operação e Segregação de funções.

Pacotes de retenção na fonte corrigidos em 17 países

Os pacotes de impostos por país usados pelo assistente de inicialização traziam alíquotas de retenção cujo escopo de «aplica-se a» não correspondia aos valores que o campo aceita. Essas alíquotas eram ignoradas em silêncio, então um país inicializado ficava sem regras de retenção que deveria ter.

Dezessete pacotes foram corrigidos: Argentina, China, Colômbia, Equador, França, Gana, Hong Kong, Indonésia, Quênia, Paquistão, Filipinas, Sri Lanka, Tanzânia, Uganda, Uruguai, Venezuela e Vietnã. Quando uma única regra misturava escopos que o modelo mantém separados — residente e não residente, empresa e pessoa física —, a regra foi dividida em duas em vez de ampliada, de modo que cada alíquota agora declara exatamente a quem se aplica. Além disso, cinco alíquotas latino-americanas de retenção de IVA foram reexpressas como percentual do valor líquido, que é como elas são efetivamente apuradas.

Se você inicializou algum desses dezessete países em uma versão anterior, execute o assistente de inicialização novamente para aquele país e recupere as regras que antes eram ignoradas. A inicialização só acrescenta o que está faltando: ela não sobrescreve as regras que você editou.

Guias completos: Assistente de inicialização de impostos, Regras de impostos e Inscrição fiscal da entidade.

Campos de dimensão personalizados com fórmula não quebram mais a contabilização

A REDA copia os seus próprios campos de dimensão de um documento de origem para os lançamentos contábeis que ela cria, para que as suas dimensões de relatório acompanhem o dinheiro. Se um desses campos fosse uma fórmula ou um resumo de totalização no objeto de destino, a cópia tentava gravar um valor em um campo que não pode ser gravado e a operação inteira falhava — o que aparecia sobretudo ao cancelar um recebimento.

A cópia agora verifica se o campo de destino pode mesmo ser gravado e o ignora se não puder. Os campos de fórmula e de resumo de totalização continuam calculando os próprios valores, exatamente como devem. Não há nada a configurar: a configuração existente continua funcionando, inclusive os conjuntos de campos que misturam campos graváveis e calculados. Guias completos: Dimensões de contabilização, Extensibilidade de conjuntos de campos e Cancelar um recebimento.

Melhorias

As atualizações de status em massa agora respeitam o compartilhamento e as permissões de campo

Esta é uma mudança de comportamento deliberada e você pode notá-la. Antes, as atualizações de status em massa eram executadas com acesso elevado, então um usuário podia alterar registros que não teria permissão de abrir ou editar um a um. Agora elas são executadas com o compartilhamento de registros e as permissões de campo daquele usuário.

Quem atualiza registros que realmente pode editar não vai notar diferença alguma. Um usuário que vá além do seu acesso agora recebe uma falha clara por registro, no mesmo painel de resultados que já informa o sucesso parcial: o restante do lote continua sendo processado. Se alguém relatar linhas que falham e antes funcionavam, a solução é conceder o acesso que essa pessoa deveria ter tido, e não contornar o problema. Guias completos: Visão geral das atualizações em massa, Objetos compatíveis e Atualizações de status em massa.

Ativar uma chave de licença agora exige Personalizar aplicativo

Inserir uma chave de licença de assinatura grava metadados de configuração na organização, então isso agora exige a permissão Personalizar aplicativo — a permissão de que essa mudança realmente precisa. Antes, qualquer usuário que conseguisse chegar à tela de assinatura podia ativar uma chave.

Não há nada a configurar, desde que quem ativa as licenças seja um administrador do sistema, porque essa pessoa já tem a permissão. Se a ativação de licenças for delegada a alguém que não é administrador, conceda a essa pessoa Personalizar aplicativo ou peça a um administrador que ative a chave. Guias completos: Assinatura e licenciamento e Arquitetura de licenças.

Como verificar se a atualização funcionou de verdade

Teste como um usuário comum, nunca como administrador. Os administradores veem os campos independentemente da segurança em nível de campo, então testar com o seu próprio usuário não prova absolutamente nada.

Verificação	Como	O que você deve ver
A versão instalada	Configuração → Pacotes instalados	REDA Financials na 1.610 ou superior.
Os campos estão visíveis para usuários reais	Abra uma fatura de venda contabilizada como um usuário comum de Accounts Receivable	Que ele vê Status de fatura eletrônica e consegue marcar Ignorar fatura eletrônica.
O valor da lista de seleção existe	Abra qualquer Histórico de fatura eletrônica e olhe o campo Status	Os oito valores, incluindo Pronto para enviar. Sete significa que o passo 4 foi pulado.
A verificação está agendada	Console de administração → Operações → Verificação de status de fatura eletrônica	O cartão mostra Agendado, com um próximo horário de execução.
Os conjuntos novos podem ser atribuídos	Atribua um conjunto de permissões `_v2` a um usuário com licença Platform	A atribuição é salva sem erro de licença.

Perguntas frequentes

O número secundário agora tem três dígitos: 1.610 é onda 6, versão de recurso 1, patch 0. Ela ordena acima da 1.6.0 e vem depois dela. O próximo patch é 1.611 e a próxima versão de recurso, 1.620.

Porque a atualização de um pacote gerenciado nunca acrescenta um valor novo a uma lista de seleção que a sua organização já tem: só recebe esse valor uma instalação nova na 1.610 ou posterior. Isso vale mesmo que os campos novos do mesmo objeto tenham chegado na mesma atualização. Acrescente Pronto para enviar à mão; veja os passos acima.

Não. Os campos novos são concedidos apenas nos conjuntos empacotados _v2. Se os seus usuários estão nos seus próprios conjuntos de permissões ou perfis, você precisa conceder a segurança em nível de campo, ou eles não verão nada, não importa o que diga o layout de página.

Fatura de venda usa um formulário de entrada próprio, então o layout exibe o valor mas não consegue capturá-lo. Acrescente o campo também ao conjunto de campos Interface de Fatura de venda: Configuração → Gerenciador de objetos → Fatura de venda → Conjuntos de campos → Interface.

Os cinco conjuntos de permissões empacotados concedem somente leitura sobre Histórico de fatura eletrônica, porque ele é a evidência de auditoria que o sistema escreve. Liberar um documento retido ou tentar de novo um que deu erro exige editar o registro, então, de fábrica, só um administrador do sistema consegue. Crie um conjunto de permissões pequeno que conceda Editar sobre Históricos de fatura eletrônica e atribua-o a quem cuida dessa fila.

Não: a autoridade fiscal já tem o documento, então essa é uma restrição legal e não da REDA. Emita uma nota de crédito para corrigi-la.