Colunas de PDF configuráveis pelo administrador
Toda organização acaba querendo mais uma coisa em seus documentos — a forma de pagamento nos recibos, um código de projeto nas linhas da fatura, o número do cheque nos comprovantes de pagamento. Na REDA Financials isso não é um redesenho de modelo; é um administrador arrastando um campo para uma lista. Os layouts de PDF leem esse conteúdo extra a partir de conjuntos de campos — listas de campos configuráveis pelo administrador — chamados de Modelo de PDF em cada objeto de documento.
Acesso necessário. Editar conjuntos de campos é uma capacidade de administrador do Salesforce (a permissão "Personalizar aplicativo"), não um dos conjuntos de permissões da REDA Financials. Os usuários do dia a dia simplesmente veem as colunas resultantes nos PDFs gerados.
O que aparece onde
| Conjunto de campos em… | Renderiza como… |
|---|---|
| O cabeçalho do documento (Fatura de venda, Recebimento, Desembolso, Ordem de compra) | Linhas extras de rótulo/valor no cartão de detalhes do documento, após as linhas padrão de número/data/referência |
| As linhas (linhas da Fatura de venda, linhas da Ordem de compra) | Uma pequena faixa de detalhes abaixo de cada linha — pares "Rótulo: valor" abaixo da descrição, mantendo a tabela principal limpa |
De fábrica, os recibos já exibem Applied to Invoices, Bank Account, Unapplied Cash, Forma de pagamento e Tipo dessa forma, e os comprovantes de pagamento exibem Bank Account, Applied Amount, Unapplied Amount, Forma de pagamento e Número do cheque — esses valores padrão são apenas entradas do conjunto de campos que você pode estender ou reduzir.
Cada objeto de documento tem sua própria lista, então o mapa completo fica assim:
| Documento | A lista do cabeçalho vem com… | Lista da linha |
|---|---|---|
| Fatura de venda | Vazia — adicione o que suas faturas precisam | Vem com Tax Base; adicione os seus (códigos de projeto, centros de custo…) |
| Recebimento | Applied to Invoices, Bank Account, Unapplied Cash, Forma de pagamento, Tipo | — (recebimentos não têm linhas) |
| Desembolso | Bank Account, Applied Amount, Unapplied Amount, Forma de pagamento, Número do cheque | — (comprovantes não têm linhas) |
| Ordem de compra | Vazia | Disponível, vem vazia |
Um exemplo prático, com recibos como o caso clássico: a Meridian quer que seus recibos de aluguel indiquem em qual banco o dinheiro caiu. Não há nada a fazer: Bank Account já vem na lista de campos Modelo de PDF do Recebimento, então o cartão de detalhes de cada recibo já traz uma linha "Conta bancária: First National Bank - Operating" — o nome da conta, não um código. Essa mesma lista é onde eles acrescentariam um campo realmente novo: abrem, arrastam e pronto. Tempo total decorrido: cerca de dois minutos, sem release, sem indisponibilidade.
Adicionando um campo (administrador, ~2 minutos)
Abra os conjuntos de campos do objeto
Configuração → Gerenciador de Objetos → o objeto de documento (por exemplo, Recebimento) → Conjuntos de Campos → Modelo de PDF.
Arraste o campo para dentro do conjunto
Qualquer campo do objeto se qualifica — padrão, empacotado ou seus próprios campos personalizados. A ordem no conjunto é a ordem no papel.
Regenere e confira
Sem deployment, sem código — a próxima geração já usa o campo. Confira um documento; pronto.
Como os valores são impressos
- Campos de referência (lookup) imprimem nomes — um campo Conta bancária mostra "First National Bank - Operating", nunca um ID.
- Os formatos seguem o local (locale) do documento — datas, números (duas casas decimais para valores monetários), sinais de porcentagem e Sim/Não para caixas de seleção. O próprio local se resolve de forma sensata: o do modelo quando definido, senão o do cliente, senão o seu.
- Valores vazios desaparecem — um campo em branco não imprime nada, então dados esparsos nunca geram linhas de rótulos vazios.
- Os extratos têm sua própria lista — colunas adicionadas ao conjunto de campos do Livro Razão da Conta aparecem tanto no livro razão em tela quanto no Extrato de Conta exportado, entre Referência e as colunas de valor.
Erros comuns a evitar
| Erro | Por que isso prejudica | Faça isto em vez disso |
|---|---|---|
| Adicionar o campo à lista errada | Cabeçalho em vez de linha, ou o objeto de documento errado por completo — o campo não é impresso em lugar nenhum e a alteração parece quebrada | Cada objeto de documento tem sua própria lista Modelo de PDF; abra o objeto de onde vem o papel e escolha cabeçalho ou linha deliberadamente |
| Testar em um registro em que o campo está em branco | Campos em branco são ignorados por design, então uma configuração perfeitamente correta parece uma falha | Regenere um documento em que o campo com certeza tenha um valor |
| Expor campos internos no papel entregue ao cliente | A lista vale para toda a organização, por tipo de documento — uma margem ou código interno adicionado "para uma entidade" é impresso para todas as entidades, para todos os clientes | Inclua apenas campos relevantes para o leitor; análises internas pertencem aos relatórios, não às faturas |
| Esperar que colunas do extrato venham das listas dos documentos | O extrato lê uma lista diferente — a do Livro Razão da Conta — então mudanças nas listas dos documentos nunca chegam até ele | Adicione as colunas do extrato ao conjunto de campos do Livro Razão da Conta; elas aparecerão em tela e no PDF exportado |
| Resolver um desejo de layout com mais campos | Dez linhas extras por linha afogam o documento que o leitor realmente precisa interpretar | Três extras bem escolhidos; mude o modelo para orientação Paisagem quando um documento realmente precisar de mais largura |
O que vem a seguir
- Configuração de Modelo de PDF — o estilo em torno dos seus campos.
- Detalhes de Pagamento em PDFs — instruções permanentes vs. dados do registro.
- Tipos de documentos suportados — o layout base de cada documento.
Perguntas frequentes
Os conjuntos de campos são por tipo de documento em toda a organização — as faturas de todas as entidades compartilham a mesma lista. A apresentação específica por entidade (cores, seções, texto) fica nos modelos; listas de campos específicas por entidade não são uma combinação suportada.
Dois motivos habituais: o campo está vazio no documento testado (campos em branco são ignorados por design) ou ele foi adicionado ao conjunto errado (cabeçalho em vez de linha, ou o objeto errado). Teste com um registro em que o campo com certeza tenha um valor.
O layout exibe os extras de linha como uma faixa de detalhes abaixo de cada linha — isso mantém a tabela principal legível independentemente da quantidade de extras. Se um valor for importante o suficiente para ser uma coluna, geralmente ele pertence à descrição que sua equipe escreve na linha.
Não — é uma operação de arrastar e soltar feita pelo administrador na Configuração, e a próxima geração já usa o novo campo. É esse o objetivo do design: o conteúdo dos documentos evolui na velocidade da configuração, não na velocidade de um release.
Os que têm linhas: faturas de venda (incluindo notas de crédito) e ordens de compra. Recebimentos e comprovantes de pagamento são documentos de valor único — todos os seus extras vão no cartão de detalhes do cabeçalho.
Não — os arquivos já gerados são históricos. A próxima geração (ou uma regeneração manual, que cria uma nova versão do mesmo arquivo) é que passa a incluir o novo campo.
Isso foi útil?