Extensibilidade por FieldSets
O mecanismo de extensão mais poderoso da REDA Financials não exige código e sobrevive a cada atualização: os conjuntos de campos (field sets). Adicione seu campo personalizado ao conjunto certo e ele aparece nos formulários de entrada, viaja até o livro razão, filtra os relatórios e é impresso nos PDFs — as telas e os motores do pacote leem os conjuntos em tempo de execução. Mais de quarenta conjuntos são distribuídos nos objetos transacionais, em três famílias.
As três famílias
| Família | Onde aparece | Uso clássico |
|---|---|---|
| Interface | Colunas/campos adicionais nos formulários de entrada empacotados (linhas de fatura, linhas de lançamento, formulários de recebimento…) | As dimensões da sua indústria — a Meridian adicionou Property__c às linhas de fatura; ele aparece na grade do formulário como se tivesse nascido ali (e o mesmo conjunto de linha até estende as linhas de modelos recorrentes) |
| Posting_Mapping | Leva os valores de dimensão dos documentos para as Transações contábeis — e daí para os filtros de relatório, os drill-downs e as aplicações com correspondência por dimensão | O mesmo Property__c fluindo até o livro razão para que a demonstração de resultado possa ser gerada por propriedade |
| Modelo de PDF | Linhas de cabeçalho / detalhes de linha adicionais nos documentos gerados (detalhes) | Forma de pagamento nos recibos, códigos de projeto nas faturas |
Além do conjunto Account Ledger em Transação contábil — colunas adicionais para os livros razão de terceiros e extratos.
A razão pela qual isso funciona: os conjuntos de campos em objetos gerenciados são deliberadamente deixados editáveis pelo administrador na plataforma. Suas edições de membros são metadados da organização — o pacote lê o que quer que os conjuntos contenham em tempo de execução, e é por isso que este é o principal mecanismo de extensibilidade sem código e por que ele sobrevive intacto a cada atualização.
A receita completa (uma nova dimensão em ~15 minutos)
Crie o campo onde ele é preenchido — e onde ele chega
O campo personalizado na linha do documento (por exemplo, Property na Linha de fatura de venda) e um campo com o mesmo nome de API em Transação contábil. Nomes de API correspondentes são o contrato que permite que os valores fluam.
Adicione a Interface (entrada) e a Posting_Mapping (fluxo)
Gerenciador de objetos → Conjuntos de campos → arraste o campo para dentro. O formulário o exibe imediatamente; as contabilizações passam a carregá-lo; a seção Dimensões do painel de relatórios e os drill-downs o reconhecem automaticamente.
Opcionalmente: imprima, filtre por ele, faça correspondência por ele
Conjunto PDF Template → ele é impresso. Aparece entre os filtros de dimensão dos relatórios. E os recursos que reconhecem dimensões (correspondência de aplicações, fechamento de ano com escopo por dimensão) o tratam como o centro de custo nativo.
Nas próprias palavras do pacote
Os conjuntos de campos se documentam sozinhos — suas descrições empacotadas são a intenção de design, ao pé da letra. O conjunto Interface da Linha de fatura de venda diz: "Add client-specific accounting dimensions here (e.g. Property__c, Cost_Centre__c, Sub_Property__c)" — essas são apenas as ilustrações que vêm de fábrica; os mesmos espaços aceitam qualquer dimensão que a sua indústria acompanhe (centros de custo, projetos, departamentos, fundos), que é exatamente como uma empresa como a Meridian os usa para propriedades. Quarenta e três conjuntos de campos são distribuídos nos objetos transacionais; o padrão se repete por objeto, de modo que o formulário, o fluxo de contabilização e o PDF de cada tipo de documento são extensíveis de forma independente.
Dois contratos estão por trás dos conjuntos — um nas descrições empacotadas, outro no próprio motor — e vale a pena declará-los claramente:
- A correspondência de nomes é o encanamento. O fluxo de contabilização mapeia por nome de API — assim como a correspondência de aplicações: quando aplicações com correspondência por dimensão estão em jogo, o motor exige que "os nomes de API coincidam entre os dois FieldSets de Posting_Mapping" nos documentos que estão sendo correspondidos. Um campo, um nome, em todo lugar.
- As colunas padrão ficam de fora. Os conjuntos Interface são apenas para as suas adições; as colunas empacotadas já são renderizadas pelos formulários, e adicioná-las novamente duplica a coluna.
A dimensão Property da Meridian, em toda parte de uma só vez
Um único campo personalizado — Property__c — adicionado seguindo a receita acima, e aqui está tudo em que ele agora aparece sem mais um minuto de configuração:
| Superfície | O que a Meridian vê |
|---|---|
| Formulário de fatura de venda | Uma coluna Property na grade de linhas, preenchida por linha de aluguel |
| Modelos recorrentes | A mesma coluna nas linhas do modelo — o conjunto Interface da linha estende ambos, então o modelo de aluguel mensal também carrega a propriedade |
| O livro razão | A Transação contábil de cada linha contabilizada carrega o valor da propriedade (Posting_Mapping) |
| Relatórios | Property aparece entre os filtros de dimensão — demonstração de resultado por prédio, incluindo drill-down |
| PDFs gerados | A propriedade é impressa nas faturas dos locatários (conjunto PDF Template) |
| Extração por IA | O catálogo de campos do OCR o inclui — contas de fornecedores enviadas podem ter a propriedade preenchida pela IA quando o documento a indica |
Erros comuns a evitar
| Erro | Por que prejudica | Faça isto em vez disso |
|---|---|---|
| Nomes de API diferentes no campo do documento e em seu gêmeo em Transação contábil | O mapeamento é feito por nome — os valores param silenciosamente no documento e nunca chegam ao livro razão | Crie os dois campos com nomes de API idênticos antes de mexer nos conjuntos |
| Adicionar a Interface, mas não a Posting_Mapping | Os usuários preenchem fielmente um campo que nunca chega aos relatórios — descoberto no fechamento do mês | Pense em pares: entrada (Interface) e fluxo (Posting_Mapping) juntos |
| Adicionar novamente colunas padrão a um conjunto Interface | Colunas duplicadas na grade confundem o formulário | Os conjuntos Interface carregam apenas os seus campos |
| Renomear um campo de dimensão depois de meses de contabilizações | As linhas antigas do livro razão mantêm o campo antigo; os relatórios dividem uma dimensão em duas | Escolha nomes com o mesmo cuidado que contas contábeis; renomear é um projeto de migração de dados, não uma edição |
| Pular a conversa sobre campo obrigatório | Os conjuntos de campos tornam os campos disponíveis, não obrigatórios — dimensões opcionais acabam 60% preenchidas | Combine a alteração do conjunto de campos com validação ou processo de equipe que torne a dimensão confiável |
O que vem a seguir
- Colunas de PDF Guiadas por FieldSet — a família de impressão em profundidade.
- Dimensões de contabilização — a teoria contábil das dimensões.
- Lightning Web Components — quando os conjuntos de campos não são suficientes.
Perguntas frequentes
Os formulários empacotados são interfaces personalizadas (grades, assistentes), não layouts padrão — os conjuntos de campos são a forma como um pacote gerenciado permite estender as telas que lhe pertencem. Mesma ideia, superfícies mais ricas: formulários, motores, relatórios e PDFs leem todos eles.
Sim — suas edições de membros são metadados da organização, preservados entre versões do pacote. É exatamente por isso que este é o caminho de extensão recomendado.
Tecnicamente é generoso; na prática, cada dimensão é um campo que os usuários precisam preencher e que os relatórios precisam segmentar. Duas ou três dimensões bem governadas superam oito parcialmente preenchidas — é uma decisão de política contábil mais do que técnica.
Sem código, sem implantação: é apontar e clicar no Gerenciador de objetos, com efeito imediato. Mesmo assim, governe-a como uma mudança de configuração: primeiro em sandbox, porque um formulário em produção ganha uma coluna no momento em que você salva.
Interface — os mesmos conjuntos que estendem os campos do formulário de Fatura de compra são lidos quando a IA constrói seu catálogo de campos, de modo que estender o formulário ensina automaticamente o extrator sobre o novo campo. Uma única definição, todos os consumidores.
Sim. Qualquer campo personalizado que você adicionou e que não faça parte do conjunto de campos Posting Mapping permanece editável em qualquer estado — rascunho, contabilizado, cancelado, até mesmo estornado. A REDA bloqueia apenas seus próprios campos, os campos padrão e qualquer campo que você tenha transformado em dimensão de contabilização (esses são gravados no livro razão quando o registro é contabilizado, por isso ficam congelados junto com ele). Sinalizadores simples, observações e chaves de integração podem ser alterados a qualquer momento. Uma precisão: “seus” significa campos do namespace da sua própria organização. Um campo personalizado vindo de outro pacote gerenciado instalado tem namespace, então a proteção o trata como governado e não como livre.
Isso foi útil?