Revisar o Registro de lançamentos

O Registro de lançamentos é um console no nível do tenant, fora de qualquer projeto específico, no qual finanças e contabilidade revisam lançamentos de ERP em todos os projetos e conexões que têm permissão para ver. Enquanto o Histórico de lançamentos de ERP se limita a um projeto ao qual você já tem acesso, o Registro de lançamentos é a visão entre projetos criada para quem revisa e precisa ver lançamentos de vários projetos e conexões em um só lugar.

O Registro de lançamentos foi criado primeiro para revisão. Duas ações em lote, limpar lançamentos simulados e tentar novamente os que falharam, além de um botão Tentar novamente por linha no painel de detalhes, o estorno e o estorno de uma execução intercompanhia inteira de uma só vez, permitem agir diretamente na grade e no painel de detalhes. O Assistente de IA ajuda a encontrar e entender lançamentos mais rápido, e Tendências, Linhagem, Totais de controle, Fechamentos e Exportar permitem analisar, voltar à origem, selar um período e extrair dados. A colaboração permite que uma equipe comente, aprove e monitore um lançamento em conjunto, sem nunca colocar valores monetários em uma notificação.

O console é um único espaço de trabalho acoplado, não um conjunto de janelas flutuantes. Uma barra de navegação à esquerda abre cada tela (lançamentos, simulados, exceções, aprovações, delegações, consolidação, tendências, totais de controle, linhagem, exportações e alertas e assistente de IA) como um painel no mesmo lugar; assim, trocar de tela substitui o que está no centro do espaço de trabalho em vez de empilhar outra janela sobre a anterior. Ao abrir um lançamento, os detalhes deslizam a partir da direita sem ocultar a lista em que você estava trabalhando.

Um único espaço de trabalho acoplado: a barra abre uma tela no centro, no mesmo lugar, e os detalhes de um lançamento abrem em um painel à direita sem ocultar a lista.

Quem pode abrir

Abrir o Registro de lançamentos exige um de quatro escopos de realm do Keycloak: erp.register.view, .operate, .approve e .admin. São concessões independentes, não uma escada progressiva: ter .admin não concede, por si só, o que .operate concede, e toda ação que altera dados ou envia dados para fora verifica explicitamente seu próprio escopo (ou escopos) necessário, em vez de inferi-lo de um nível mais alto.

Escopo	Concede
`erp.register.view`	Abrir o registro e revisar lançamentos: fila de exceções, grade, visões consolidadas, Tendências, Linhagem e Assistente de IA. Nada disso aplica, exporta ou notifica coisa alguma.
`erp.register.operate`	A base de tudo o que altera o estado ou sai do console: ações em lote, iniciar um estorno, solicitar aprovação para um estorno, abrir a caixa de entrada de aprovações e decidir uma solicitação sobre a qual você tem autoridade, ver ou devolver uma delegação, exportar ou agendar uma entrega, assinar o resumo do Assistente de IA e publicar um comentário, uma aprovação final ou um monitoramento. As ações protegidas por `.approve` e `.admin` são exigidas além de `.operate`, nunca no lugar dele; veja abaixo.
`erp.register.approve`	Autoridade de aprovação sobre um estorno igual ou acima do limite de segregação de funções do tenant, seja por ter este escopo diretamente ou por meio de uma delegação ativa de alguém que o tenha, e resolução de uma tentativa de estorno travada (`released` ou `confirmed`). Conceder a outra pessoa uma delegação dessa autoridade também exige que você mesmo tenha `.approve`; usar, ver ou revogar uma delegação não exige. Tudo isso em conjunto com `.operate`.
`erp.register.admin`	A exportação para auditoria e o perfil de leitura em data de referência (valores monetários e identidade do autor sem máscara) e a definição da política de retenção do tenant, cada um em conjunto com `.operate`. Também permite excluir ou disparar o agendamento de outro membro.

A regra de visibilidade

Ter um escopo erp.register.* abre o console, mas não torna nenhum lançamento visível por si só. Um lançamento só fica visível no registro se você também tiver uma concessão pessoal de conexão na conexão desse lançamento e, quando o lançamento pertencer a um projeto, acesso a esse projeto. Um lançamento que não está vinculado a um projeto é controlado apenas pela concessão da conexão.

Esta é uma concessão separada do escopo do registro acima, e ambas são necessárias:

Concessão de conexão. Você precisa ser proprietário explícito da conexão, ser citado individualmente ou ser membro de um grupo de segurança citado nela, as mesmas concessões que o Modelo de segurança de uma conexão controla. Uma conexão definida como All Workspace Members não concede visibilidade no registro. Essa configuração torna a conexão utilizável por todos; ela não é uma concessão pessoal, de grupo ou de propriedade, e o registro exige especificamente uma delas.
Acesso ao projeto, para qualquer lançamento que pertença a um projeto, o mesmo acesso exigido pelo seu outro trabalho no projeto.

Um membro que tem erp.register.view, mas nenhuma concessão de conexão, vê um registro corretamente vazio, e o console informa isso em vez de parecer quebrado. Uma concessão de conexão ou de projeto que seja revogada entra em vigor no seu próximo carregamento de página; não há visibilidade obsoleta para limpar.

O que você vê por função

O console é adaptável à função: uma entrada da barra ou um botão de ação para o qual você não tem o escopo fica oculto, e não apenas esmaecido, de modo que o espaço de trabalho mostra somente o que você realmente pode fazer. Isso espelha o que o servidor aplica, em vez de substituí-lo:

Você tem	Você vê
`erp.register.view`	As telas de revisão: fila de exceções, grade, consolidação, tendências, linhagem, totais de controle e assistente de IA.
`erp.register.operate`	Adiciona os botões de ação: tentar novamente, estornar e limpar lançamentos simulados.
`erp.register.approve`	Adiciona a caixa de entrada de aprovações, as decisões de aprovação e a delegação.
`erp.register.admin`	Adiciona as configurações de retenção e a exportação para auditoria sem máscara.

Ocultar um controle é apenas apresentação, uma conveniência para que não lhe ofereçam algo que seria recusado. O servidor continua sendo a autoridade: toda ação que altera dados ou envia dados para fora verifica novamente seu próprio escopo necessário, além das suas concessões de conexão e de projeto, no momento em que você a executa. Nada é permitido só porque o cliente mostrou um botão, e nada é realmente bloqueado apenas porque o cliente ocultou um.

A fila de exceções

Ao abrir o registro, você chega à Fila de exceções, e não à grade: os lançamentos com maior probabilidade de exigir sua atenção, agrupados em quatro categorias e exibidos em ordem de prioridade:

Em dúvida: o lançamento foi enviado e nada confirma ainda o que aconteceu com ele.
Não confirmado: enviado e já passou do prazo em que deveria ter sido confirmado.
Pendente: um lançamento assíncrono que já passou do prazo em que deveria ter sido resolvido.
Falhou: rejeitado pelo ERP.

Cada categoria aparece como um bloco de contagem acima da fila, mostrando seu total em tempo real, de modo que o volume de trabalho fica visível antes de você abrir qualquer item. Selecionar um bloco filtra a fila para essa categoria, enquanto os outros blocos continuam mostrando seus próprios totais; assim, alternar para Falhou nunca faz a contagem de Em dúvida parecer vazia.

“Envelhecido” é medido pelos temporizadores da própria plataforma, e não por um limite inventado, de modo que um lançamento cai em uma categoria exatamente quando a própria plataforma o consideraria atrasado. Dentro de cada categoria, os lançamentos mais antigos vêm primeiro.

Lançamentos simulados nunca aparecem na fila nem em suas contagens; a fila informa quantos foram excluídos, para que uma contagem baixa nunca seja confundida com “nada para revisar” quando as simulações são o motivo. Filtrar por uma categoria reduz as linhas exibidas, mas não altera o que as contagens das outras categorias informam; assim, alternar para Falhou nunca faz Em dúvida parecer vazia.

A mesma regra de visibilidade da grade se aplica aqui: você só vê exceções em lançamentos vinculados a uma conexão na qual você tem concessão pessoal, em um projeto ao qual você tem acesso.

Estornos ainda pendentes

A lista de exceções pela API, GET /erp/register/exceptions, também informa uma quinta categoria, reversal_outstanding: um lançamento registrado cujo estorno foi enviado mas nunca concluído, seja porque o ERP não deu resposta, seja porque a tentativa foi interrompida durante o envio. Ela tem sua própria contagem ao lado das outras quatro, vai para o topo junto com Em dúvida, e cada linha nomeia a tentativa de estorno e seu estado. Esse lançamento permanece na lista até ser resolvido, conforme descrito em Estorno; ele não sai da lista por conta própria com o passar do tempo.

Integridade das conexões

Um banner acima da Fila de exceções e das visões consolidadas (abaixo) responde a uma pergunta que nenhuma delas responde sozinha: alguma das suas conexões está fora do ar? Para cada conexão na qual você tem concessão pessoal, e somente essas, ele mostra o último lançamento bem-sucedido e se a conexão está apresentando erros no momento. Uma conexão com concessão e ainda sem lançamentos informa isso, em vez de ser omitida da lista, e se a própria verificação de integridade não puder ser concluída, o banner também informa isso, em vez de relatar silenciosamente que está tudo certo.

Formatação de valores monetários

Todo valor que o registro mostra (grade, consolidação, totais de controle, painel de detalhes, fila de exceções, caixa de entrada de aprovações, Assistente de IA e a caixa de diálogo de estorno) é exibido como uma cifra contábil: separadores de milhar, negativos entre parênteses e numerais tabulares (de largura fixa), para que uma coluna de valores se alinhe na vírgula decimal. As casas decimais seguem a própria moeda, e não um padrão fixo de duas: o JPY não mostra nenhuma, o KWD mostra três.

Subtotais nunca são somados entre moedas. Um grupo ou lote com mais de uma moeda é dividido em uma linha por moeda, cada uma identificada com a própria moeda, tanto nas visões consolidadas quanto nos Totais de controle; nenhuma taxa de câmbio é presumida em nenhum lugar da plataforma.
O arredondamento para exibição nunca oculta uma diferença real. Quando o arredondamento para as casas decimais habituais da moeda eliminaria um dígito diferente de zero, o painel de detalhes mostra o valor exato capturado ao lado do arredondado. As cifras de Totais de controle nunca são arredondadas, pelo mesmo motivo: uma diferença verificada em relação a uma tolerância permanece com precisão total, de modo que uma diferença real fora da tolerância, como 0.004, não possa aparecer como 0.00 ao lado de um veredito de “Desbalanceado”.

A grade do registro

Mude para a grade para ver todos os lançamentos, e não apenas as exceções: ela lista lançamentos de todos os projetos e conexões que você pode ver, uma linha por lançamento. Uma barra de escopo percorre o topo da grade, onde você restringe o que está vendo:

Projeto
Ambiente
Conexão
Tipo de ERP
Entidade
Data de lançamento
Estado
Modo de lançamento

Para criar seu próprio filtro de tipo de ERP, GET /erp/register/erp-types retorna todos os tipos de ERP dos lançamentos que você pode ver, em ordem.

A barra de escopo usa seletores: você escolhe um projeto, uma conexão ou uma entidade pelo nome, em uma lista limitada ao que você tem permissão para ver, em vez de digitar um identificador. Estado é uma seleção múltipla, para que você possa acompanhar vários estados ao mesmo tempo.

Modo de lançamento é um seletor de três botões sempre visível, para que você veja de relance o que os números incluem. Ao vivo mostra somente os lançamentos que chegaram ao ERP, Simulado mostra somente os lançamentos de execuções no modo Simular e Todos (o padrão) mostra ambos. A coluna Modo de lançamento da grade mostra o tipo de cada linha. As telas Reconciliar e Consolidação têm seu próprio seletor de Modo de lançamento com as mesmas opções, com Ao vivo como padrão. Quando o modo não é Ao vivo, uma observação ao lado dos totais monetários informa que eles incluem lançamentos simulados que nunca chegaram ao ERP ou, em Simulado, que nenhum chegou ao ERP. O que você definiu permanece visível na tela enquanto trabalha, de modo que você nunca fica adivinhando o que a grade está mostrando.

Ações em lote

Na grade, selecione mais de um lançamento e aja sobre todos juntos. Selecione lançamentos marcando suas linhas ou escolhendo selecionar tudo o que corresponde ao filtro atual, o que alcança todos os lançamentos que o filtro encontra em todas as páginas, e não apenas os já carregados.

Duas ações são oferecidas:

Limpar lançamentos simulados: uma exclusão lógica para lançamentos simulados que você não precisa mais manter.
Tentar novamente lançamentos com falha: reenviar lançamentos que o ERP rejeitou ou que nunca foram enviados.

A prévia de impacto

Antes de qualquer das ações ser executada, o PlaidCloud mostra uma prévia de impacto: quantos lançamentos são afetados, o valor monetário envolvido (detalhado por moeda; os valores nunca são misturados entre moedas, e um valor não capturado aparece em branco, nunca como 0.00) e a quais conexões e entidades pertencem os lançamentos afetados. Qualquer item da sua seleção em que a ação não possa atuar é destacado separadamente, de modo que “24 dos seus 30 lançamentos selecionados não farão nada” fica visível antes de você confirmar, e não é descoberto depois.

Digitar para confirmar

Acima de um limite, o botão Aplicar permanece desativado até que você digite o valor afetado exatamente como ele aparece.

A nova tentativa só atua sobre o que você marcou

Limpar lançamentos simulados pode ser executado sobre qualquer tipo de seleção: linhas marcadas ou tudo o que corresponde ao seu filtro. Tentar novamente como ação em lote não pode: ela só atua sobre lançamentos que você marcou individualmente. Uma seleção ampla por filtro não tem uma lista fixa de lançamentos à qual restringir a nova tentativa; por isso, a nova tentativa pede que você cole os lançamentos de volta e se recusa a prosseguir, a menos que o que você colar seja exatamente o que a prévia mostrou: os mesmos lançamentos, sem duplicatas e com a mesma contagem. Essa vinculação é o que mantém a confirmação honesta: o lote que você confirmou é o lote que será enviado.

O que pode ser tentado novamente

Somente um lançamento que o ERP rejeitou, ou que nunca foi enviado, pode ser tentado novamente. Um que ainda esteja em andamento, em dúvida ou já registrado não pode ser tentado novamente a partir daqui.

Quando o ERP da conexão oferece suporte, o PlaidCloud consulta diretamente o ERP antes de tentar novamente: se o ERP já mantém o documento como registrado, a nova tentativa é recusada e o estorno é sugerido no lugar. Se o ERP não puder responder a essa verificação, a nova tentativa é recusada em vez de arriscada; ele nunca adivinha. Algumas conexões não oferecem suporte a essa verificação; para elas, a nova tentativa se baseia na própria rejeição registrada do lançamento.

Tentar novamente exige erp.register.operate e sua própria concessão pessoal na conexão desse lançamento, a mesma concessão de conexão que A regra de visibilidade exige para ver o lançamento.

Tentar novamente a partir do painel de detalhes

O painel de detalhes de um lançamento também traz seu próprio botão Tentar novamente, ao lado dos controles de monitoramento: a mesma nova tentativa, uma linha por vez, alcançada sem passar pela grade. Não é um clique único: ao abri-lo, aparecem a mesma prévia de impacto e, acima do limite, o mesmo desafio de digitar para confirmar que a ação em lote usa; existe exatamente um caminho de nova tentativa, acessado de dois lugares. O botão aparece em todas as linhas para um membro que tem erp.register.operate; o painel nunca presume que uma linha pode ser tentada novamente antes de oferecer o botão, de modo que uma linha que se revele inelegível (já registrada, em andamento ou já mantida pelo ERP) é recusada pela prévia com o motivo do próprio servidor, e não ocultada silenciosamente.

Limpar lançamentos simulados

Limpar é uma exclusão lógica: o PlaidCloud registra quem limpou e quando, e exige um motivo antes que Aplicar seja ativado. Ele remove os lançamentos do armazenamento de prévia de simulação e do diário de simulação do próprio razão; nunca toca em um lançamento real, e não há como apontá-lo para um.

A visão de lançamentos simulados

Lançamentos simulados abre como um painel a partir da barra, listando o que está no armazenamento de simulação, em vez de obrigar você a procurar linhas simuladas na grade principal. Filtre por conexão, projeto, ambiente ou ID de execução de simulação.

Incluir limpos vem desativado por padrão, de acordo com o padrão do próprio servidor: uma linha limpa é o registro de auditoria de uma limpeza e é mantida por pouco tempo por esse motivo, de modo que a visão abre mostrando o que ainda está ativo no armazenamento, e não o seu próprio histórico.
Limpar a partir daqui continua passando pela mesma prévia de impacto da ação em lote na grade, nunca uma limpeza com um clique, restrita ao que os filtros da visão correspondem no momento.
A linha de resumo da visão também informa o mesmo valor simulated_excluded que a Fila de exceções mostra: quantos lançamentos simulados do razão de lançamentos, uma tabela separada do armazenamento de simulação, são mantidos fora da fila porque uma linha simulada nunca chegou ao ERP e, portanto, nunca é uma exceção.

Assistente de IA

O Assistente de IA abre uma caixa de pesquisa, uma fileira de cartões proativos e um painel de orientação por linha. Todo valor nele é calculado pelo próprio registro, sobre as suas concessões em tempo real; o modelo, quando há um configurado, apenas explica ou redige, e nunca inventa um número ou um predicado.

Pergunte em linguagem simples

Digite uma frase, como “lançamentos em dúvida da conexão EMEA na semana passada”, e ela é interpretada no vocabulário de filtros do próprio registro por uma tabela fixa, e não por uma chamada a um modelo: uma interpretação só pode restringir as linhas que a grade já mostraria a você, nunca alcançar uma linha para a qual você não tem concessão. O único papel do modelo é explicar a interpretação em uma frase: ele nomeia o campo que correspondeu e quantas das suas linhas o filtro resultante encontra.

Cartões proativos

Sete cartões resumem o que vale a pena examinar, cada um com uma contagem em tempo real e linhas de exemplo restritas às suas próprias concessões: pendentes para o fechamento, quase duplicatas, a diferença de saldo zero entre empresas, alterados desde o último fechamento, confirmados no ERP, envelhecimento e responsáveis e já estornados. Uma breve frase narrativa fica ao lado dos valores quando uma conexão de LLM está configurada para o seu espaço de trabalho; quando não há nenhuma, o cartão ainda é exibido por completo e informa por que a narrativa está ausente. Um valor não capturado em um cartão fica sempre em branco, nunca 0.00, a mesma regra que as visões consolidadas seguem.

Orientação por linha

Escolha um lançamento e receba dois tipos de orientação, dependendo do estado dele:

Um rascunho de estorno, para qualquer lançamento: como seria estorná-lo, se o driver da conexão oferece suporte a isso, o total de controle com o qual ele precisaria conciliar e uma verificação de período. É apenas um rascunho; nada aqui estorna coisa alguma.
Direcionamento de falha, para um lançamento rejeitado ou em dúvida: por que falhou, se deve tentar novamente ou corrigir primeiro os dados de origem, qual campo corrigir e o risco de duplicidade ao tentar novamente. A mensagem de erro do próprio ERP é texto livre, então ela é classificada em uma causa no servidor em vez de ser mostrada diretamente a você, a mesma regra que mantém texto livre fora do restante do registro.

O resumo diário

Um resumo mostra, sob demanda, uma prévia dos cartões acima restritos a um subconjunto relevante para o fechamento (pendentes para o fechamento, envelhecimento e responsáveis, quase duplicatas, a diferença de saldo zero entre empresas e confirmados no ERP) como seriam se fossem enviados a você hoje. Uma chave alterna a assinatura e o cancelamento dela; a assinatura armazena apenas o seu ID de membro, de modo que uma concessão que você perca depois simplesmente remove essas linhas do seu próximo resumo, em vez de vazar uma visão obsoleta.

Estorno

Estornar um lançamento, ou seja, criar no ERP um novo documento oposto, está disponível no controle Estornar do painel de detalhes e, para automação, diretamente pela API.

A elegibilidade depende do estado do próprio lançamento (somente um lançamento registrado com um ID de documento do ERP confirmado pode ser estornado), do driver da conexão (Business Central, Oracle Fusion e Acumatica não oferecem nenhum estorno programático e informam isso quando você tenta) e de já haver ou não uma tentativa de estorno pendente nele. O painel verifica a elegibilidade novamente tanto quando você abre Estornar quanto imediatamente antes de você enviar, de modo que uma linha que ficou obsoleta nesse intervalo (outro estorno já pendente, por exemplo) mostra a recusa do próprio driver, em suas próprias palavras, em vez de disparar uma solicitação fadada ao fracasso.
Estornar exige erp.register.operate e fica protegido por um desafio de digitar para confirmar: você digita novamente o ID do documento do ERP do próprio lançamento, verificado apenas no navegador e nunca enviado, antes que Estornar seja desbloqueado, o mesmo padrão de alcance de impacto que as ações em lote usam, um aviso de segurança e não uma etapa de aprovação.
Estornar pode, opcionalmente, redirecionar o novo lançamento para um período de destino diferente do lançamento original, o que é respeitado em adaptadores cujo ERP aceita um período de lançamento explícito e recusado com um erro claro naqueles que não conseguem direcioná-lo. Um redirecionamento ainda pode cair em um período diferente do solicitado: alguns adaptadores só descobrem se o respeitaram depois do envio, então o painel informa um período de destino final somente depois que a tentativa for efetivamente concluída como estornada, nunca antes, e recorre à mensagem do próprio servidor em todos os outros resultados. Um bloqueio rígido no banco de dados impede que uma segunda tentativa de estorno seja enviada enquanto houver uma pendente, mesmo diante de uma falha de processo no meio do envio; uma rejeição do ERP libera esse bloqueio automaticamente, já que nada foi criado.
Um estorno por vez, onde quer que comece. Um estorno enviado a partir do Registro de lançamentos e um enviado por um fluxo de trabalho ou pela API de estorno no nível do projeto compartilham o mesmo bloqueio, e cada um lê o lançamento novamente depois de obtê-lo, de modo que um lançamento nunca é estornado duas vezes, nem por uma nova execução nem por duas solicitações simultâneas.
Uma resposta desconhecida é retida, não adivinhada. Quando o ERP expira o tempo limite, retorna um erro de servidor ou responde de uma forma que o PlaidCloud não reconhece, o estorno é registrado como in_doubt em vez de rejeitado, e o bloqueio permanece. Um documento de estorno só conta como o estorno quando espelha o original: mesma entidade e moeda, data não anterior, com débito e crédito de cada linha trocados; qualquer outra coisa permanece em dúvida para você verificar.
Um estorno deixado como pending ou in_doubt, com resultado desconhecido, permanece assim até ser resolvido. Para o Workday e o Dynamics 365 Finance & Operations, o PlaidCloud consulta um estorno in_doubt no ERP na próxima vez que um estorno desse lançamento for tentado e o resolve com base no que encontrar. Um estorno pending nessas conexões, e qualquer estorno não resolvido em todas as outras conexões, é limpo com os controles de resolução do painel, protegidos por erp.register.approve além de .operate: uma pessoa verifica diretamente o ERP e registra o que encontrou, Liberar (nada foi criado lá, então o razão fica intacto e o lançamento volta a poder ser estornado) ou Marcar como estornado (existe um documento de estorno, com seu ID), que é a única forma de esse bloqueio ser liberado. Marcar um estorno como confirmed é permanente; não há como desfazer pelo produto.

Segregação de funções

Um estorno igual ou acima do limite configurado no seu tenant exige aprovação antes de prosseguir, e a aprovação é algo que um aprovador faz, não um nome que o autor do envio informa na solicitação.

Quem faz ≠ quem verifica. O membro que envia o estorno não pode ser também o aprovador dele, nem seu próprio autorizador de emergência.
Medido pela magnitude. O limite compara o tamanho do estorno independentemente do sinal: estornar um crédito é medido da mesma forma que estornar um débito.
Estornos recentes contam para o limite. Uma janela móvel totaliza os estornos do próprio autor do envio na mesma conexão, de modo que um estorno grande não possa ser dividido em vários menores para ficar abaixo do limite. Os valores são somados pela magnitude, não compensados: um estorno negativo e um positivo não se anulam.
Falha de forma segura. Se um estorno anterior na janela não puder ser verificado (um valor ou moeda não capturado, por exemplo), o estorno exige aprovação em vez de pular a verificação.
O aprovador precisa ser qualificado. Ele precisa de erp.register.approve, ou de uma delegação ativa de quem o tenha, e de sua própria concessão na conexão que está sendo estornada. Se menos de dois membros tiverem ambos, os estornos iguais ou acima do limite são recusados em vez de liberados.
Emergência (break-glass) continua sendo o único caminho em que o autor do envio nomeia diretamente quem autorizou uma exceção: uma emergência genuína, decidida por um autorizador independente da cadeia operacional, que tenha erp.register.admin mas não .operate nem .approve, além de sua própria concessão na conexão, e toda exceção é registrada permanentemente na trilha de auditoria.
Uma recusa não diz por quê. Seja porque a solicitação não tem aprovador qualificado, foi decidida pela pessoa errada ou nunca foi aberta, o estorno é recusado com a mesma mensagem, deliberadamente, para que uma recusa não possa ser usada para mapear quem tem qual função ou concessão. O motivo real está na trilha de auditoria, não no erro.
O estorno de uma execução precisa de uma aprovação por item, não uma para a execução. Estornar de uma só vez uma execução intercompanhia inteira não recebe uma única aprovação no nível da execução: cada item precisa da sua própria, porque uma aprovação está vinculada a um lançamento, uma conexão e um aprovador que tenha uma concessão ali, e não há um único nome ao qual vincular todos os itens de uma execução.
Os estornos passam pelo registro. Enquanto a segregação de funções estiver ativada, um estorno solicitado pela API de estorno de ERP no nível do projeto, o caminho que um projeto, uma função definida pelo usuário ou uma conta de serviço usa, é recusado antes que qualquer coisa chegue ao ERP, com uma mensagem para estornar a partir do Registro de lançamentos. Um lançamento para o qual o registro não tem detalhes de captura também não pode ser estornado ali e deve ser corrigido no ERP. Os lançamentos não são afetados, e Business Central, Oracle Fusion e Acumatica continuam dando seu próprio motivo, o de que não oferecem suporte a estorno.

A ativação da segregação de funções e a definição do seu limite são configuradas para o seu tenant pelo PlaidCloud; ainda não há uma chave no console para isso.

A caixa de entrada de aprovações

Quando o limite exige, Solicitar aprovação, oferecido ao lado de Estornar no painel de detalhes, encaminha o estorno a todos os aprovadores que tenham uma concessão pessoal ativa nessa conexão. Não há ninguém específico a quem endereçá-lo; a concessão da conexão é o roteamento. Os aprovadores trabalham a fila em Aprovações na barra: uma caixa de entrada com solicitações aguardando a decisão deles e uma segunda fila mostrando as solicitações que eles mesmos enviaram. Cada linha traz o valor, a entidade e o período do lançamento e há quanto tempo está aguardando, de modo que decidir nunca significa sair da fila para ir procurar algo antes. Aprovar ou Rejeitar exige um motivo, registrado com a decisão.

Uma aprovação está vinculada exatamente àquilo para o qual foi concedida (o lançamento, sua conexão, o motivo declarado e o período de destino) e não pode ser reutilizada para um estorno diferente, um motivo diferente ou um período de destino alterado; uma solicitação alterada precisa de uma nova aprovação. Somente uma solicitação pode estar aberta em um lançamento por vez, e uma aprovação é consumida no momento em que é resgatada. Uma breve retenção segue cada aprovação, durante a qual o aprovador ou o autor do envio ainda pode cancelá-la; depois que a retenção passa, o estorno já pode ser um documento no ERP, e nada desfaz isso. Tudo é verificado novamente no momento em que o estorno é efetivamente aplicado (a função do aprovador, o acesso de ambas as partes à conexão e o mínimo de dois aprovadores do tenant), de modo que uma aprovação concedida antes não sobrevive à perda de acesso do aprovador nesse intervalo.

Delegação

Um aprovador pode delegar sua autoridade de aprovação a outro membro por uma janela limitada, no painel Delegações da barra, o que é útil quando um aprovador estará indisponível e os estornos ainda precisam ser decididos. Conceder uma delegação exige erp.register.approve; usar uma, ver as suas próprias e devolver uma exigem apenas .operate, já que o delegado típico nem sequer tem a função de aprovador; esse é o objetivo de delegar a ele.

A autodelegação é recusada, assim como um par recíproco (delegar a alguém que já delegou a você) ou qualquer cadeia mais longa; nenhuma delas é aceita, para que dois membros não possam fazer discretamente com que as decisões um do outro valham como cobertura para ambos, direta ou por meio de um intermediário. A regra de quem faz ≠ quem verifica continua valendo em uma delegação: um delegado não pode aprovar uma solicitação da pessoa que delegou a ele, nem uma solicitação própria, de nenhuma das duas formas. Toda decisão que um delegado toma é registrada na trilha de auditoria como tomada sob a autoridade do aprovador que delegou, e não como se o delegado tivesse a função de forma plena.

Escalonamento

Uma aprovação que fica tempo demais sem decisão gera um alerta, para que não envelheça silenciosamente em uma fila que ninguém está vigiando. Cada destinatário é informado apenas sobre as solicitações que ele próprio poderia decidir (um e-mail de escalonamento para um colega nunca cita uma solicitação encaminhada para as concessões de outra pessoa), e o alerta não traz valor nem texto livre, a mesma minimização que o restante das notificações do registro segue.

Execuções intercompanhia

Uma execução intercompanhia é o grupo de lançamentos, seus itens, feitos em conjunto para um fechamento, identificado pelo dia de fechamento e pela sequência carimbados neles na ocasião, nunca pela execução de fluxo de trabalho que os produziu. (O ID dessa execução de fluxo de trabalho continua separadamente no histórico do próprio razão e pode durar mais que o carimbo de fechamento de um lançamento, portanto não é uma forma segura de identificar uma execução.) Liste as execuções, abra uma para ver seus itens conciliados e pareados e estorne a execução inteira como uma única ação governada.

Acessível apenas pela API por enquanto (GET /erp/register/runs, GET /erp/register/runs/{run_day}/{sequence} e POST /erp/register/runs/{run_day}/{sequence}/reverse); ainda não há uma tela no console.

Saldo zero e pareamento

Ao abrir uma execução, seus itens são conciliados de duas formas, ambas restritas às conexões nas quais você tem concessão pessoal, a mesma regra de visibilidade de todo o restante do registro, de modo que uma execução que abrange conexões que você só vê parcialmente é informada como parcialmente visível, e não como desbalanceada.

Saldo zero, por moeda: um veredito balanceado, desbalanceado ou indeterminado, com as entidades por trás de cada saldo detalhadas. Uma moeda só é conciliada se todos os itens nela foram capturados; um item não capturado torna a moeda inteira indeterminada, nunca um saldo calculado apenas sobre o que por acaso foi medido.
O pareamento associa cada item a pagar ao item a receber correspondente por meio de uma chave de pareamento que o fluxo de trabalho de lançamento carimba em ambos antes de qualquer um ser enviado. Um par correspondente tem saldo zero em uma moeda; tudo o mais traz um motivo nomeado: nenhum item da contraparte visível para você, um valor não capturado, um saldo que realmente não é zero ou entre moedas, que é informado e nunca conciliado, já que não existe taxa de câmbio em lugar nenhum da plataforma.

Uma execução com mais de 200 itens é grande demais para ser conciliada ou pareada em uma única resposta: ambos retornam indeterminado em vez de serem calculados sobre uma fatia truncada da execução, de modo que uma execução grande nunca informa um saldo falso, nem uma contraparte ausente falsa, causados apenas pelo próprio tamanho.

Estornar uma execução

Estorne todos os itens de uma execução em uma única ação, por meio de POST /erp/register/runs/{run_day}/{sequence}/reverse.

A elegibilidade é verificada para cada item de antemão. Tudo o que pode ser conhecido com antecedência (estado, suporte do adaptador, uma tentativa pendente, sua própria concessão de conexão) recusa a execução inteira antes que uma única solicitação chegue a um ERP.
O que não pode ser conhecido de antemão é informado depois, por item. O estado ativo do ERP e da autorização pode mudar durante a execução; assim, uma execução pode terminar parcialmente estornada mesmo que nada parecesse errado na verificação prévia. Nada é compensado automaticamente: registrar mais documentos para desfazer uma falha parcial é uma gravação mais arriscada do que a que falhou. Uma execução parcial é corrigida item a item, da mesma forma que um estorno individual.
Executar novamente o estorno de uma execução é como se conclui um parcial. Os itens que uma tentativa anterior já estornou são deixados de lado em vez de recusados, de modo que tentar de novo estorna apenas o que realmente ainda resta.
A segregação de funções se aplica por item, não ao total da execução. Quando a política de segregação de funções do seu tenant está em vigor, cada item precisa da sua própria aprovação antes que a execução despache qualquer coisa, em qualquer valor, não apenas acima do limite. Isso é deliberadamente conservador: o requisito de um item só pode ser definido no momento em que ele é despachado (uma janela móvel contra fracionamento que conta os próprios itens da execução à medida que são estornados e uma releitura ativa do ERP que pode falhar); portanto, exigir todas as aprovações de antemão é o que impede que uma execução estorne metade dos seus itens antes de descobrir, no meio do caminho, que o restante também precisa de aprovação.
As ações em lote cobrem a execução inteira em uma chamada. POST /erp/register/runs/{run_day}/{sequence}/approval-requests abre uma solicitação de aprovação para cada item em que quem envia pode agir, e POST .../approval-decisions decide cada item para o qual um aprovador está qualificado, uma chamada para cada em vez de uma solicitação e uma decisão por item (20 chamadas para uma execução rotineira de 10 itens). O modelo de segurança subjacente não muda: cada item ainda recebe sua própria aprovação, vinculada àquele lançamento, à sua conexão, ao motivo e ao período de destino, e o aprovador ainda precisa de seu próprio acesso à conexão de cada item; um item que ele não pode autorizar simplesmente permanece pendente para alguém que possa, nunca incluído à força. Um chamador sem nenhuma autoridade de aprovação é recusado de imediato, sem descobrir quais itens têm solicitações abertas. Os resultados voltam por item, de modo que uma execução parcialmente autorizável informa exatamente quais itens foram decididos e quais permaneceram pendentes, e por quê.
A emergência (break-glass) não está disponível para o estorno de uma execução. É uma exceção de duas pessoas para um lançamento, e aplicar a autorização de uma testemunha a uma execução inteira a multiplicaria pelo número de itens da execução. Use a emergência por item, em POST /entries/{ledger_id}/reverse.
Execuções com mais de 200 itens não podem ser estornadas como uma única ação. Estorne-as em partes, a partir da lista de lançamentos.

Tendências

Tendências mostra a taxa de falhas e a latência, agrupadas por conexão ou tipo de ERP, além da distribuição dos códigos de motivo de estorno; todos os valores, incluindo todos os denominadores, são calculados sobre as suas próprias concessões em tempo real. Uma conexão sem nada em estado terminal na janela mostra um travessão na taxa de falhas, nunca 0%, já que um zero perfeito colocaria uma conexão que ninguém usa no topo de uma lista de integridade. A latência é uma amostra limitada dos lançamentos terminais mais recentes, identificada como amostra e não apresentada como se cobrisse a janela inteira. Os motivos de estorno aparecem somente como seus códigos estruturados; o motivo em texto livre digitado por uma pessoa nunca é agrupado nem exibido aqui.

Linhagem

Linhagem leva de um lançamento de volta à execução do fluxo de trabalho que o produziu e, para fora, ao documento no próprio ERP. Procure por ID de execução ou pelo ID do razão de um lançamento; pesquisar por ID do razão resolve a execução primeiro por meio das suas próprias concessões, de modo que um lançamento em uma conexão que você não pode ver não resolve nada, em vez de expor de qual execução ele veio. Quando o PlaidCloud consegue verificar o formato da URL do documento do ERP para aquele adaptador, a linhagem inclui um link direto para o documento; quando não consegue, ou o lançamento nunca foi confirmado, ela informa qual desses é o motivo em vez de adivinhar um link. A chave de negócio do ERP continua sem aparecer aqui: a chave de linhagem é o run_id do fluxo de trabalho, e o ponteiro do ERP é confirmation_id, igual a todos os outros lugares do registro.

Fechamentos

Solicitar um fechamento sela um período, para uma ou mais conexões e entidades, em um instantâneo imutável de um ponto no tempo: tudo o que o registro sabia sobre esses lançamentos naquele momento, mantido mesmo que as linhas ativas sejam depois tentadas novamente, estornadas ou limpas. Ele se destina a um período contábil bloqueado em que você precisa de um registro defensável e inalterável, e não do que a grade ativa mostra hoje. Solicitar ou ler um fechamento só é possível pela API por enquanto; ainda não há uma tela no console para solicitar ou navegar por um.

Solicitar um fechamento (erp.register.operate) é uma ação administrativa em todo o tenant, não uma ação pessoal: as conexões e entidades que você nomeia são exatamente as seladas, independentemente das suas próprias concessões de conexão. Fechar novamente um período já fechado nunca é destrutivo: sempre produz uma nova revisão, numerada separadamente, em vez de sobrescrever a última.

Os fechamentos se materializam sozinhos. Solicitar um fechamento não o sela imediatamente: um job em segundo plano varre automaticamente todos os fechamentos pendentes, em um agendamento diário, e grava seu instantâneo Iceberg sem nenhuma outra ação sua. Se uma varredura não puder ser concluída para um determinado fechamento (uma interrupção do warehouse, por exemplo), esse fechamento é marcado como falho em vez de ficar travado, e é retomado e tentado novamente automaticamente na varredura do dia seguinte; nunca é ignorado silenciosamente. Um fechamento excepcionalmente grande (abrangendo mais de aproximadamente 500.000 lançamentos) é o único caso que não se resolve sozinho dessa forma: a varredura se recusa a selá-lo em uma única passagem, e é preciso a ajuda do PlaidCloud para fechá-lo em lotes menores. Esse é um caso extremo raro para a maioria dos períodos de relatório.

Depois que um fechamento é materializado, lê-lo de volta aplica as regras habituais do registro, reavaliadas ao vivo a cada leitura em vez de incorporadas ao instantâneo no momento do selo: você só vê linhas de conexões e projetos nos quais tem concessão no momento. Diferentemente da grade ativa, que mostra valores monetários e a identidade do autor a qualquer visualizador que consiga ver a linha, os valores de um fechamento ficam mascarados, a menos que você tenha erp.register.admin, a mesma regra que Exportar aplica. Um fechamento também informa sua própria contagem de chegadas tardias: lançamentos enviados ou alterados depois da marca-d’água máxima do fechamento e, portanto, nunca capturados no selo, visível apenas ao solicitar um novo fechamento para o mesmo período, já que nada reabre um antigo.

Exportar

Exportações e alertas é onde o registro sai do console como um arquivo ou uma notificação, e a única superfície em que os controles do PlaidCloud deixam de se aplicar no momento em que os bytes saem. Produzir uma exportação ou agendar uma entrega exige erp.register.operate; abrir o registro para consultá-lo não exige.

Baixar agora

Exporte o registro que você está vendo no momento como um CSV compatível com Excel ou como JSON, gerado na hora com base nas suas próprias concessões em tempo real. Dois perfis de mascaramento se aplicam, dependendo da sua função:

erp.register.operate recebe o perfil padrão, mascarado: valores monetários e identidade do autor são omitidos.
erp.register.admin recebe o perfil de auditor, o único que traz valores monetários e identidade do autor sem máscara.

Toda exportação segue as mesmas regras do restante do registro: natural_key nunca aparece, os campos de texto livre (comentários, valores de dimensões e de worktags) são excluídos por completo, e não apenas higienizados, e um valor não capturado fica em branco, distinguido de um mascarado, para que um campo em branco nunca seja lido como “nada foi lançado” quando na verdade significa “sua função não vê isto”.

Agendar uma entrega

Crie um agendamento: um filtro, uma periodicidade, um formato e uma lista de destinatários por membro, ou uma conexão do Slack para uma notificação sem nenhum conteúdo de linha. Dois tipos são oferecidos:

Exportação: uma entrega recorrente em CSV ou JSON do registro filtrado.
Alerta: uma notificação disparada por uma de três condições: um lançamento real com falha, uma autorização envelhecida ou um estorno de lançamento. Veja uma prévia do que um gatilho corresponderia atualmente para você antes de assiná-lo.

O arquivo de cada destinatário é construído a partir das concessões ativas dele, no momento do envio, e não das do proprietário do agendamento: dois destinatários do mesmo agendamento podem receber dois arquivos diferentes, e um destinatário que, entretanto, perdeu a função de exportação, perdeu todas as concessões de conexão, foi desativado ou não tem endereço cadastrado é ignorado individualmente com um motivo declarado, em vez de ser descartado silenciosamente. Somente o proprietário do agendamento ou alguém com erp.register.admin pode excluir ou disparar o agendamento de outra pessoa.

Retenção

Configure por quanto tempo o registro mantém três tipos de histórico: detalhes de payload capturados, lançamentos simulados e a trilha de auditoria, cada um como uma contagem de dias, em todo o tenant, exigindo erp.register.admin. Todo campo é gravado em toda chamada; um campo omitido limpa esse horizonte em vez de deixá-lo inalterado, e um tenant não configurado mantém tudo (todo horizonte é lido como nulo, não como um padrão oculto).

A varredura de retenção que atua sobre essa política agora é executada automaticamente, uma vez por dia, em todo o tenant, o mesmo mecanismo de jobs periódicos que também aciona as exportações e alertas agendados, envelhece lançamentos atrasados para a fila de exceções e expira lançamentos simulados antigos.

Visões consolidadas

Consolidação abre como um painel a partir da barra. Agrupe o registro por execução, período ou conexão para ver subtotais e uma consolidação de status em vez de linhas individuais; o agrupamento é um controle segmentado no topo do painel, de modo que você alterna entre Por execução, Por período e Por conexão no mesmo lugar, sem reabrir nada.

Valor monetário em branco continua em branco. Um lançamento sem valor capturado (todo lançamento do SAP, um lançamento já nascido em estado terminal ou um escrito antes de este recurso existir) não contribui com nada para um subtotal e nunca é mostrado como 0.00. Cada grupo informa em palavras se todos os lançamentos nele foram capturados, se alguns não foram ou se nenhum foi.
As moedas nunca são misturadas em um único total. O PlaidCloud não faz nenhuma conversão cambial, então um grupo que abrange mais de uma moeda recebe uma linha por moeda, em vez de um único valor combinado; veja Formatação de valores monetários.
Uma lista de grupos limitada ainda totaliza corretamente. Se um agrupamento produz mais grupos do que a visão exibe, a linha de totais ainda cobre todos os grupos, não apenas os exibidos, e informa isso.

O banner de Integridade das conexões também aparece nesta visão.

Totais de controle

Totais de controle abre como um painel a partir da barra, sobre as mesmas conexões e entidades às quais A regra de visibilidade já restringe você. Ele agrupa lançamentos em lotes e informa, para cada um, um veredito de três estados, Balanceado, Desbalanceado ou Indeterminado, com o motivo declarado pelo próprio servidor, nunca uma palavra solta.

Indeterminado é uma resposta real, não uma aprovação branda. Um lote só é Balanceado quando todas as linhas nele foram medidas e seus grupos conferem. Uma janela vazia, um valor não capturado, um adaptador que dispara e esquece ou uma leitura interrompida antes de todo o lote ser lido retornam Indeterminado, com o motivo explicitado, nunca um verde por padrão.
O valor monetário é em branco, nunca zero. Os totais de origem e registrados de um grupo, e sua diferença, ficam em branco sempre que o valor não foi capturado ou confirmado, a mesma regra que as visões consolidadas seguem, porque um 0.00 fabricado subestimaria um lote não medido enquanto parece um valor autorizado.
Os grupos são por moeda e entidade e nunca são somados entre si. O PlaidCloud não faz nenhuma conversão cambial, então um lote que abrange mais de uma moeda ou entidade lista os totais de cada grupo lado a lado em vez de misturá-los; veja Formatação de valores monetários para saber como esses valores são exibidos.
As linhas anteriores à captura recebem seu próprio grupo (no batch id). Um lançamento escrito antes de a captura de lote existir não pode ser reagrupado em um lote que nunca o continha, portanto é mostrado como sua própria linha, em vez de ser incorporado ou descartado.

A mesma leitura também cobre duas perguntas relacionadas: a prontidão para fechamento de período, por entidade e período, que degrada para Indeterminado, e não para um falso Bloqueado, para um grupo para o qual a plataforma ainda não tem números, como uma linha anterior à captura em um fechamento de transição; e a divergência de confirmação, informada por documento e não por grupo, porque dois documentos que divergem em direções opostas dentro do mesmo grupo de moeda/entidade podem conferir no total e esconder ambos.

O painel de detalhes

O painel de detalhes fica acoplado à direita do espaço de trabalho, de modo que a lista permanece visível enquanto você lê um lançamento. Abra-o pelo ícone de lupa de uma linha, pressionando Enter na linha selecionada ou com um clique duplo na linha. Ele é organizado em guias:

Guia	Mostra
Diário	As linhas de débito e crédito do lançamento, lidas como um contador as leria. Veja A guia Diário.
Solicitação/Resposta	A solicitação enviada e a resposta do ERP, filtradas para minimização de dados (veja abaixo).
Erros	Qualquer erro retornado pelo ERP ou pela etapa de lançamento.
Linha do tempo	Os estados do lançamento em ordem, do envio até o estado atual.
Relacionados	O lançamento original e seu estorno, vinculados entre si, quando existe um.
Auditoria	Um registro somente leitura da atividade neste lançamento. Escasso por enquanto; veja A guia Auditoria abaixo.
Comentários	Comentários encadeados neste lançamento, com @menção por ID de membro. Veja Colaboração.
Aprovação final	O status de revisão atual do lançamento (Revisado, Limpo ou Requer acompanhamento) com seu histórico completo. Veja Colaboração.

A guia Diário

A guia Diário lê um lançamento como um contador o leria: suas linhas de débito e crédito por conta, em vez do payload bruto da solicitação.

Somente as colunas que cada ERP realmente captura. A guia mostra os campos que um determinado sistema envia e nenhum outro: um lançamento do Acumatica mostra sua subconta, enquanto um sistema que nunca envia uma não mostra nenhuma coluna de subconta vazia; você não precisa percorrer colunas que nunca conterão nada.
Dimensões e worktags ficam abaixo de cada linha. O detalhe analítico de uma linha (suas dimensões ou os worktags do Workday) aparece sob a linha à qual pertence, e não espremido em colunas extras no topo.
Um fechamento de soma por moeda com verificação exata de saldo. Cada moeda totaliza por conta própria; a verificação nunca mistura moedas e nunca arredonda para zero um lançamento desbalanceado, de modo que um desequilíbrio genuíno aparece como o valor que é, em vez de desaparecer em um 0.00.
Um adaptador que não captura detalhe de linha diz isso. Quando um driver, como o SAP local, não registra nenhum detalhamento por linha, a guia declara isso claramente em vez de mostrar uma grade vazia que você poderia interpretar como “sem linhas”.

Triagem pelo teclado

Na Fila de exceções, as teclas de seta para cima e para baixo percorrem de um lançamento ao próximo com o painel de detalhes acompanhando a seleção, de modo que você pode fazer toda uma passagem de triagem pelo teclado, lendo os detalhes de cada lançamento em sequência sem recorrer ao mouse.

A grade principal mantém deliberadamente a seleção com o mouse, Enter e o clique duplo: a seleção de várias linhas é o que aciona as ações em lote, como tentar novamente e limpar lançamentos simulados; portanto, ali as setas movem a seleção em vez de varrer o painel por todas as linhas.

Colaboração

Trabalhe um lançamento com sua equipe sem sair do registro: comente com @menção, registre uma aprovação final ou monitore uma conexão ou uma execução para acompanhar sua atividade futura.

Os Comentários são notas encadeadas em texto simples sobre um lançamento, na guia Comentários dele. Faça uma @menção a um colega pelo ID de membro e ele é notificado, se puder ver o lançamento no momento; essa verificação é refeita no momento do envio, nunca presumida a partir de quem foi mencionado.
A Aprovação final registra um de três estados (Revisado, Limpo ou Requer acompanhamento), com uma observação opcional, e mantém o histórico completo de quem definiu o quê e quando. É um registro, não um bloqueio: atualmente nada bloqueia um lançamento ou um estorno com base no estado da aprovação final.
Monitorar uma conexão ou uma execução, dois controles separados, para ser notificado da atividade em qualquer uma delas daqui em diante.

Publicar um comentário, uma aprovação final ou um monitoramento exige erp.register.view e .operate; lê-los de volta exige apenas .view.

Minimização de dados

O registro foi criado para mostrar o que um revisor precisa para confirmar que um lançamento ocorreu, sem expor os dados sensíveis que uma etapa de lançamento manipulou para realizá-lo.

Os payloads de solicitação e resposta têm lista de permissão por adaptador. Um campo só aparece se foi explicitamente classificado como seguro para manter. Números de contas bancárias, números de roteamento, IBANs, números de identificação fiscal e outros identificadores pessoais são removidos antes que você veja o payload.
A chave de negócio do ERP é omitida por completo. Ela pode incorporar o nome de um fornecedor ou outro token de referência, por isso nunca chega ao registro, inclusive ao Assistente de IA: a mesma lista de permissão que decide o que você vê decide o que um prompt de modelo pode ver, e um valor de chave natural em qualquer lugar desse payload é recusado de imediato, em vez de enviado. Identifique uma linha pelo ID do razão e use o confirmation_id como o ponteiro do próprio ERP para o documento, o mesmo campo que o Histórico de lançamentos de ERP chama de confirmation_id.
Os campos de texto livre passam por limpeza de padrões na leitura e são excluídos por completo, e não apenas higienizados, do resumo, de qualquer prompt de modelo de IA e de qualquer exportação. A limpeza de padrões detecta um formato como um IBAN ou um número de identificação fiscal; ela não consegue detectar o nome de um fornecedor digitado em um memorando, e é por isso que tudo o que sai do console como arquivo descarta esses campos por completo, em vez de depender apenas da limpeza.

A guia Auditoria

A guia Auditoria é somente de exibição. Seu detalhe é intencionalmente escasso nesta versão, porque o vocabulário de auditoria subjacente ainda não foi classificado; espere que ela seja preenchida à medida que esse trabalho avançar, sem mudar a forma como você lê o restante do painel.

Tudo o mais nesta página (a fila de exceções, a integridade das conexões, as visões consolidadas, as ações em lote, a nova tentativa por linha, o estorno, os totais de controle, o Assistente de IA, as tendências, a linhagem, os fechamentos, a colaboração e a exportação) funciona hoje.