Rever o registo de lançamentos

O Registo de lançamentos é uma consola ao nível do tenant, fora de qualquer projeto individual, onde as equipas de finanças e contabilidade revêem lançamentos de ERP em todos os projetos e ligações que lhes é permitido ver. Enquanto o Histórico de lançamentos do ERP está limitado a um projeto a que já tem acesso, o Registo de lançamentos é a vista entre projetos pensada para um revisor que precisa de ver num só local os lançamentos de muitos projetos e ligações.

O Registo de lançamentos foi concebido primeiro para revisão. Duas ações em massa — limpar lançamentos simulados e voltar a tentar os que falharam —, um botão Tentar novamente individual na gaveta de detalhes, o estorno e o estorno de uma execução intragrupo inteira de uma só vez permitem agir diretamente a partir da grelha e da gaveta de detalhes; a Assistência de IA ajuda a encontrar e compreender lançamentos mais depressa; e as Tendências, a Linhagem, os Totais de controlo, os Fechos e a Exportação permitem analisar, recuar até à origem, selar um período e extrair dados. A Colaboração permite a uma equipa comentar, aprovar e vigiar um lançamento em conjunto, sem nunca colocar valores monetários numa notificação.

A consola é uma área de trabalho única e ancorada, não um conjunto de janelas flutuantes. Uma barra de navegação à esquerda abre cada ecrã — lançamentos, simulados, exceções, aprovações, delegações, resumo, tendências, totais de controlo, linhagem, exportações e alertas e assistência de IA — como um painel no local, pelo que mudar de ecrã substitui o conteúdo do centro da área de trabalho em vez de empilhar outra janela sobre a anterior. Ao abrir um lançamento, o respetivo detalhe desliza a partir da direita sem ocultar a lista em que estava a trabalhar.

Uma única área de trabalho ancorada — a barra abre um ecrã no centro, no local, e o detalhe de um lançamento abre numa gaveta à direita sem ocultar a lista.

Quem pode abri-lo

Abrir o Registo de lançamentos requer um de quatro âmbitos do realm Keycloak — erp.register.view, .operate, .approve e .admin. São permissões independentes, não uma escada progressiva: possuir .admin não concede, só por si, o que .operate concede, e cada ação que altera o estado ou que faz sair dados da consola verifica explicitamente o seu próprio âmbito, ou âmbitos, em vez de os deduzir de um nível superior.

Âmbito	Concede
`erp.register.view`	Abrir o registo e rever lançamentos — a fila de exceções, a grelha, as vistas de resumo, as Tendências, a Linhagem e a Assistência de IA. Nada disto aplica, exporta ou notifica seja o que for.
`erp.register.operate`	A base de tudo o que altera o estado ou sai da consola: ações em massa, iniciar um estorno, pedir aprovação para um estorno, abrir a caixa de entrada de aprovações e decidir um pedido sobre o qual tenha autoridade, ver ou devolver uma delegação, exportar ou agendar uma entrega, subscrever o resumo diário da Assistência de IA e publicar um comentário, uma aprovação ou uma vigilância. As ações protegidas por `.approve` e `.admin` são verificadas em complemento de `.operate`, nunca em sua substituição — veja abaixo.
`erp.register.approve`	Autoridade de aprovação sobre um estorno igual ou superior ao limite de segregação de funções do tenant — quer por possuir este âmbito diretamente, quer através de uma delegação ativa de alguém que o possua — e resolução de uma tentativa de estorno bloqueada (`released` ou `confirmed`). Conceder a outra pessoa uma delegação dessa autoridade também exige que possua `.approve`; usar, ver ou revogar uma delegação não exige. Tudo isto em conjunto com `.operate`.
`erp.register.admin`	A exportação de auditor e o perfil de leitura à data (valores monetários e identidade do autor sem máscara) e a definição da política de retenção do tenant — cada uma em conjunto com `.operate`. Permite também eliminar ou disparar o agendamento de outro membro.

Quatro grupos de segurança incorporados agrupam estes âmbitos de forma cumulativa, por conveniência — Leitor do registo de lançamentos (.view), Operador (acrescenta .operate), Aprovador (acrescenta .approve) e Administrador (os quatro) — mas a matriz de Grupos de segurança permite atribuir qualquer combinação de forma independente, uma vez que os âmbitos não se implicam mutuamente. .approve e .admin não têm significado por si sós: todas as ações que protegem exigem também .operate, pelo que um grupo destinado a resolver estornos ou a retirar a máscara de exportações tem de ter .operate concedido explicitamente a par destes, e não assumido a partir do nível superior. Atribua o nível — ou a combinação — que corresponde ao que um membro deve fazer, e não apenas .view a todos.

A regra de visibilidade

Possuir um âmbito erp.register.* abre a consola, mas não torna visível, por si só, nenhum lançamento. Um lançamento só é visível no registo se também possuir uma permissão pessoal de ligação na ligação desse lançamento e — quando o lançamento pertence a um projeto — acesso a esse projeto. Um lançamento que não está associado a um projeto é controlado apenas pela permissão de ligação.

Esta é uma permissão distinta do âmbito do registo acima, e ambas são necessárias:

Permissão de ligação. Tem de ser proprietário explícito da ligação, ou estar nomeado individualmente, ou ser membro de um grupo de segurança nomeado nela — as mesmas permissões que o Modelo de segurança de uma ligação controla. Uma ligação definida como All Workspace Members não concede visibilidade no registo. Essa definição torna a ligação utilizável por todos; não é uma permissão pessoal, de grupo nem de propriedade, e o registo exige especificamente uma delas.
Acesso ao projeto, para qualquer lançamento que pertença a um projeto — o mesmo acesso que o seu restante trabalho no projeto exige.

Um membro que possua erp.register.view mas nenhuma permissão de ligação vê um registo corretamente vazio, e a consola informa-o disso em vez de parecer avariada. Uma permissão de ligação ou de projeto que seja revogada produz efeito no carregamento de página seguinte — não há visibilidade obsoleta para limpar.

O que vê consoante a função

A consola é adaptada à função: uma entrada da barra ou um botão de ação para o qual não tem o âmbito necessário fica oculto, e não apenas esbatido, pelo que a área de trabalho mostra apenas o que pode realmente fazer. Isto reflete o que o servidor impõe, sem o substituir:

Se possui	Vê
`erp.register.view`	Os ecrãs de revisão — fila de exceções, grelha, resumo, tendências, linhagem, totais de controlo e assistência de IA.
`erp.register.operate`	Acrescenta os botões de ação: tentar novamente, estornar e limpar lançamentos simulados.
`erp.register.approve`	Acrescenta a caixa de entrada de aprovações, as decisões de aprovação e a delegação.
`erp.register.admin`	Acrescenta as definições de retenção e a exportação de auditor sem máscara.

Ocultar um controlo é apenas apresentação — uma conveniência para que não lhe seja oferecido algo que seria recusado. O servidor continua a ser a autoridade: cada ação que altera o estado ou faz sair dados volta a verificar o seu próprio âmbito necessário, bem como as suas permissões de ligação e de projeto, no momento em que a executa. Nada é permitido só porque o cliente mostrou um botão, e nada fica realmente bloqueado só porque o cliente ocultou um.

A fila de exceções

Ao abrir o registo, aterra na Fila de exceções, e não na grelha — os lançamentos com maior probabilidade de exigirem a sua atenção, agrupados em quatro categorias e apresentados por ordem de prioridade:

Em dúvida — o lançamento foi submetido e nada confirma ainda o que lhe aconteceu.
Não confirmado — submetido e já passado o prazo em que deveria ter sido confirmado.
Pendente — um lançamento assíncrono, já passado o prazo em que deveria ter sido resolvido.
Falhou — rejeitado pelo ERP.

Cada categoria surge como um mosaico de contagem acima da fila, com o respetivo total em tempo real, para que o volume de trabalho seja visível antes de abrir seja o que for. Ao selecionar um mosaico, a fila é filtrada para essa categoria, enquanto os outros mosaicos continuam a mostrar os seus próprios totais — por isso, mudar para Falhou nunca faz com que a contagem de Em dúvida pareça vazia.

«Em atraso» é medido com base nos temporizadores da própria plataforma, e não num limite inventado, pelo que um lançamento cai numa categoria exatamente quando a própria plataforma o consideraria em atraso. Dentro de cada categoria, os lançamentos mais antigos aparecem primeiro.

Os lançamentos simulados nunca aparecem na fila nem nas respetivas contagens — a fila indica quantos foram excluídos, para que uma contagem baixa nunca seja confundida com «nada a rever» quando a causa são simulações. Filtrar por uma categoria reduz as linhas apresentadas; não altera o que as contagens das outras categorias indicam, pelo que mudar para Falhou nunca faz com que Em dúvida pareça vazia.

Aplica-se aqui a mesma regra de visibilidade da grelha: só vê exceções em lançamentos associados a uma ligação para a qual tenha uma permissão pessoal, num projeto a que tenha acesso.

Estornos ainda pendentes

A lista de exceções através da API, GET /erp/register/exceptions, comunica também uma quinta categoria, reversal_outstanding: um lançamento registado cujo estorno foi enviado mas nunca foi liquidado — o ERP não deu resposta, ou a tentativa foi interrompida a meio do envio. Tem a sua própria contagem a par das outras quatro, ordena-se no topo juntamente com Em dúvida, e cada linha identifica a tentativa de estorno e o respetivo estado. Um lançamento assim permanece na lista até ser resolvido, tal como descrito em Estorno; não deixa de aparecer por si só com o passar do tempo.

Estado das ligações

Uma faixa acima da Fila de exceções e das vistas de resumo (abaixo) responde a uma pergunta que nenhuma delas responde sozinha: alguma das suas ligações está em baixo? Para cada ligação para a qual tenha uma permissão pessoal — e apenas essas — mostra o último lançamento bem-sucedido e se essa ligação está atualmente a dar erros. Uma ligação com permissão mas ainda sem lançamentos di-lo em vez de ser omitida da lista, e se a própria verificação de estado não puder ser concluída, a faixa também o indica em vez de comunicar discretamente que está tudo bem.

Formatação de valores monetários

Todos os montantes que o registo mostra — grelha, resumo, totais de controlo, gaveta de detalhes, fila de exceções, caixa de entrada de aprovações, Assistência de IA e caixa de diálogo de estorno — são apresentados como valores contabilísticos: separadores de milhares, negativos entre parênteses e algarismos tabulares (de largura fixa), para que uma coluna de montantes fique alinhada na vírgula decimal. As casas decimais seguem a própria moeda e não um valor fixo de duas — o JPY não mostra nenhuma, o KWD mostra três.

Os subtotais nunca são somados entre moedas. Um grupo ou lote com mais do que uma moeda divide-se numa linha por moeda, cada uma identificada com a sua própria moeda, tanto nas vistas de resumo como nos Totais de controlo — a plataforma não assume qualquer taxa de câmbio em lado nenhum.
O arredondamento para apresentação nunca esconde uma diferença real. Quando o arredondamento para as casas decimais habituais da moeda eliminaria um dígito diferente de zero, a gaveta de detalhes mostra o valor exato capturado a par do arredondado. Os valores dos Totais de controlo nunca são arredondados, pelo mesmo motivo: uma diferença verificada face a uma tolerância mantém a precisão total, pelo que uma diferença real fora da tolerância, como 0.004, não pode ser apresentada como 0.00 ao lado de um veredicto de «Desequilibrado».

A grelha do registo

Mude para a grelha para ver todos os lançamentos e não apenas as exceções — lista os lançamentos de todos os projetos e ligações que pode ver, uma linha por lançamento. Uma barra de âmbito percorre o topo da grelha, onde restringe o que está a observar:

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

Para construir um filtro próprio por tipo de ERP, GET /erp/register/erp-types devolve, ordenados, todos os tipos de ERP presentes nos lançamentos que pode ver.

A barra de âmbito usa seletores: escolhe um projeto, uma ligação ou uma entidade pelo nome, a partir de uma lista limitada ao que lhe é permitido ver, em vez de escrever um identificador. O Estado é de seleção múltipla, pelo que pode acompanhar vários estados em simultâneo.

O Modo de lançamento é um comutador de três botões sempre visível, para que perceba de relance o que os números incluem. Real mostra apenas os lançamentos que chegaram ao ERP, Simulado mostra apenas os lançamentos de execuções em modo de simulação e Todos (o predefinido) mostra ambos. A coluna Modo de lançamento da grelha indica de que tipo é cada linha. Os ecrãs Reconciliar e Resumo têm o seu próprio seletor de Modo de lançamento com as mesmas opções, com Real como predefinição. Quando o modo não é Real, uma nota junto dos totais monetários indica que estes incluem lançamentos simulados que nunca chegaram ao ERP ou, em Simulado, que nenhum chegou ao ERP. O que tiver definido permanece visível no ecrã enquanto trabalha, para que nunca tenha de adivinhar o que a grelha está a mostrar.

Ações em massa

A partir da grelha, selecione mais do que um lançamento e aja sobre todos em conjunto. Selecione lançamentos assinalando as respetivas linhas, ou escolhendo selecionar tudo o que corresponde ao filtro atual — o que abrange todos os lançamentos que o filtro encontra em todas as páginas, e não apenas os já carregados.

São oferecidas duas ações:

Limpar lançamentos simulados — uma eliminação lógica para lançamentos simulados que já não precisa de manter.
Tentar novamente os lançamentos falhados — reenviar lançamentos que o ERP rejeitou ou que nunca chegaram a ser enviados.

A pré-visualização do impacto

Antes de qualquer das ações ser executada, o PlaidCloud mostra uma pré-visualização do impacto: quantos lançamentos são afetados, o dinheiro envolvido (discriminado por moeda — os montantes nunca são misturados entre moedas, e um montante não capturado aparece em branco, nunca como 0.00) e a que ligações e entidades pertencem os lançamentos afetados. Tudo o que, na sua seleção, a ação não pode tocar é indicado em separado, pelo que «24 dos 30 lançamentos selecionados não terão efeito» é visível antes de confirmar, e não descoberto depois.

Confirmação por escrita

Acima de um limite, o botão Aplicar permanece desativado até escrever o montante afetado de forma exatamente igual.

A nova tentativa só atua sobre o que assinalou

Limpar lançamentos simulados pode atuar sobre qualquer tipo de seleção — linhas assinaladas ou tudo o que corresponde ao filtro. Tentar novamente como ação em massa não pode: só atua sobre lançamentos que assinalou individualmente. Uma seleção ao nível do filtro não tem uma lista fixa de lançamentos a que limitar a nova tentativa, pelo que esta pede que volte a colar os lançamentos e recusa prosseguir a menos que o que colar seja exatamente o que a pré-visualização mostrou — os mesmos lançamentos, sem duplicados e com a mesma contagem. É essa associação que mantém a confirmação honesta: o lote que confirmou é o lote que é enviado.

O que pode ser tentado novamente

Só um lançamento que o ERP rejeitou, ou que nunca foi enviado, pode ser tentado novamente. Um lançamento ainda em curso, em dúvida ou já registado não pode ser tentado novamente a partir daqui.

Quando o ERP da ligação o suporta, o PlaidCloud consulta diretamente o ERP antes de tentar novamente: se o ERP já tiver o documento como registado, a nova tentativa é recusada e é sugerido o estorno. Se o ERP não conseguir responder a essa verificação, a nova tentativa é recusada em vez de arriscada — nunca adivinha. Algumas ligações não suportam de todo esta verificação; para essas, a nova tentativa baseia-se na rejeição registada do próprio lançamento.

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

Tentar novamente a partir da gaveta de detalhes

A gaveta de detalhes de um lançamento tem também o seu próprio botão Tentar novamente, junto aos controlos de vigilância — a mesma nova tentativa, uma linha de cada vez, alcançada sem passar pela grelha. Não é um clique único: ao abri-lo, apresenta a mesma pré-visualização do impacto e, acima do limite, o mesmo desafio de confirmação por escrita que a ação em massa usa — existe exatamente um caminho de nova tentativa, com entrada em dois locais. O botão aparece em todas as linhas para um membro com erp.register.operate; a gaveta nunca decide antecipadamente que uma linha pode ser tentada novamente antes de a oferecer, pelo que uma linha que se revele inelegível — já registada, em curso ou que o ERP já tem — é recusada pela pré-visualização com o motivo do próprio servidor, e não ocultada em silêncio.

Limpar lançamentos simulados

Limpar é uma eliminação lógica: o PlaidCloud regista quem limpou e quando, e exige um motivo antes de o botão Aplicar ser ativado. Remove os lançamentos do armazenamento de pré-visualização de simulação e do diário de simulação do próprio razão — nunca toca num lançamento real, e não há forma de o apontar a um.

A vista de lançamentos simulados

Os Lançamentos simulados abrem como um painel a partir da barra, listando o que existe no armazenamento de simulação, em vez de o obrigar a encontrar linhas simuladas na grelha principal. Filtre por ligação, projeto, ambiente ou id de execução de simulação.

Incluir limpos está desativado por predefinição, em linha com a predefinição do próprio servidor: uma linha limpa é o registo de auditoria de uma limpeza e é mantida durante pouco tempo por esse motivo, pelo que a vista abre sobre o que ainda está ativo no armazenamento e não sobre o seu próprio histórico.
Limpar a partir daqui continua a passar pela mesma pré-visualização do impacto da ação em massa na grelha — nunca uma limpeza com um só clique — limitada ao que os filtros da vista correspondem naquele momento.
A linha de resumo da vista comunica também o mesmo valor simulated_excluded que a Fila de exceções mostra — quantos lançamentos simulados do registo de lançamentos, uma tabela distinta do armazenamento de simulação, são mantidos fora da fila porque uma linha simulada nunca chegou ao ERP e, por isso, nunca é uma exceção.

Assistência de IA

A Assistência abre uma caixa de pesquisa, uma fila de cartões proativos e um painel de aconselhamento por linha — todos os valores apresentados são calculados pelo próprio registo, com base nas suas permissões em tempo real; o modelo, quando há um configurado, apenas explica ou redige, e nunca inventa um número nem um predicado.

Pergunte por palavras suas

Escreva uma frase — «lançamentos em dúvida da ligação EMEA na semana passada» — e esta é convertida no vocabulário de filtros do próprio registo por uma tabela fixa, e não por uma chamada a um modelo: uma conversão só pode restringir as linhas que a grelha já lhe mostraria, nunca alcançar uma linha para a qual não tenha permissão. O único papel do modelo é explicar a conversão numa frase: indica o campo que correspondeu e quantas das suas linhas o filtro resultante encontra.

Cartões proativos

Sete cartões resumem o que merece atenção, cada um com uma contagem em tempo real e linhas de exemplo limitadas às suas próprias permissões: pendente de fecho, quase duplicados, a diferença de saldo zero intragrupo, alterado face ao último fecho, confirmado no ERP, antiguidade e responsáveis e já revertido. Uma breve frase narrativa surge junto dos valores quando existe uma ligação LLM configurada para a sua área de trabalho; quando não existe, o cartão continua a ser apresentado por completo e indica porque falta a narrativa. Um montante não capturado num cartão aparece sempre em branco, nunca como 0.00 — a mesma regra que as vistas de resumo seguem.

Aconselhamento por linha

Escolha um lançamento e obtenha dois tipos de aconselhamento, consoante o seu estado:

Um rascunho de estorno, para qualquer lançamento — o aspeto que teria estorná-lo: se o controlador da ligação o suporta sequer, o total de controlo com que teria de fechar e uma verificação do período. É apenas um rascunho; nada aqui estorna seja o que for.
Orientação sobre a falha, para um lançamento rejeitado ou em dúvida — porque falhou, se deve tentar novamente ou corrigir primeiro os dados de origem, que campo corrigir e o risco de duplicação de carregar em tentar novamente. A mensagem de erro do próprio ERP é texto livre, pelo que é classificada numa causa no servidor em vez de lhe ser mostrada diretamente — a mesma regra que mantém o texto livre fora do resto do registo.

O resumo diário

Um resumo pré-visualiza, a pedido, os cartões acima limitados a um subconjunto relevante para o fecho — pendente de fecho, antiguidade e responsáveis, quase duplicados, diferença de saldo zero intragrupo e confirmado no ERP — tal como seriam apresentados se lhe fossem enviados hoje. Um interruptor subscreve-o ou cancela a subscrição; a subscrição não armazena mais do que o seu id de membro, pelo que uma permissão que perca depois simplesmente faz com que essas linhas deixem de constar do seu resumo seguinte, em vez de expor uma vista desatualizada.

Estorno

Estornar um lançamento — criar no ERP um novo documento de sinal oposto — está disponível a partir do controlo Estornar da gaveta de detalhes e, para automação, diretamente pela API.

A elegibilidade depende do estado do próprio lançamento (só um lançamento registado com um id de documento do ERP confirmado pode ser estornado), do controlador da ligação (o Business Central, o Oracle Fusion e o Acumatica não suportam qualquer estorno programático, e di-lo quando tenta) e de já haver ou não uma tentativa de estorno pendente sobre ele. A gaveta volta a verificar a elegibilidade tanto quando abre Estornar como imediatamente antes de submeter, pelo que uma linha que entretanto ficou desatualizada — por exemplo, outro estorno já pendente — mostra a recusa do próprio controlador, nas suas palavras, em vez de disparar um pedido condenado ao fracasso.
Estornar exige erp.register.operate e fica protegido por um desafio de confirmação por escrita: volta a escrever o id de documento do ERP do próprio lançamento, verificado apenas no navegador e nunca enviado, antes de Estornar ser desbloqueado — o mesmo padrão de alcance do impacto que as ações em massa usam, um aviso de segurança e não um passo de aprovação.
O estorno pode, opcionalmente, redirecionar o novo lançamento para um período de destino diferente do do lançamento original — respeitado nos adaptadores cujo ERP aceita um período de lançamento explícito, e recusado com um erro claro nos que não conseguem apontá-lo. Um redirecionamento pode, mesmo assim, cair num período diferente do pedido: alguns adaptadores só ficam a saber se o respeitaram depois do envio, pelo que a gaveta indica um período de destino apenas quando a tentativa já ficou efetivamente liquidada como estornada — nunca antes — e remete para a mensagem do próprio servidor em todos os outros resultados. Um bloqueio rígido na base de dados impede que uma segunda tentativa de estorno seja alguma vez enviada enquanto outra estiver pendente, mesmo após a falha de um processo a meio do envio; uma rejeição do ERP liberta esse bloqueio automaticamente, uma vez que nada foi criado.
Um estorno de cada vez, seja onde for que comece. Um estorno enviado a partir do Registo de lançamentos e outro enviado por um fluxo de trabalho ou pela API de estorno ao nível do projeto partilham o mesmo bloqueio, e cada um volta a ler o lançamento depois de o obter, pelo que um lançamento nunca é estornado duas vezes — nem por uma nova execução, nem por dois pedidos em simultâneo.
Uma resposta desconhecida é retida, não adivinhada. Quando o ERP esgota o tempo limite, devolve um erro de servidor ou responde de uma forma que o PlaidCloud não reconhece, o estorno é registado como in_doubt em vez de rejeitado, e o bloqueio permanece retido. Um documento de estorno só conta como o estorno quando espelha o original — mesma entidade e moeda, data não anterior, o débito e o crédito de todas as linhas trocados; qualquer outra coisa permanece em dúvida até a verificar.
Um estorno que fique pending ou in_doubt — com resultado desconhecido — permanece assim até ser liquidado. Para o Workday e o Dynamics 365 Finance & Operations, o PlaidCloud procura no ERP um estorno in_doubt na próxima vez que se tentar estornar esse lançamento, e liquida-o com base no que encontrar. Um estorno pending nessas ligações, e qualquer estorno por liquidar em todas as outras ligações, é resolvido com os controlos de resolução da gaveta, protegidos por erp.register.approve além de .operate: uma pessoa verifica diretamente o ERP e regista o que encontrou — Libertar (nada foi criado lá, pelo que o razão fica intacto e o lançamento volta a poder ser estornado) ou Marcar como estornado (existe um documento de estorno, com o respetivo id) — que é a única forma de esse bloqueio ser libertado. Marcar um estorno como confirmed é permanente; não há forma de o anular através do produto.

Segregação de funções

Um estorno igual ou superior ao limite configurado para o seu tenant exige aprovação antes de prosseguir — e a aprovação é algo que um aprovador faz, não um nome que quem submete indica no pedido.

Autor≠aprovador. O membro que submete o estorno não pode ser também o seu aprovador, nem o seu próprio autorizador de break-glass.
Medido pela magnitude. O limite compara a dimensão do estorno independentemente do sinal — estornar um crédito é medido da mesma forma que estornar um débito.
Os estornos recentes contam para o limite. Uma janela móvel totaliza os estornos do próprio submissor na mesma ligação, pelo que um estorno elevado não pode ser dividido em vários mais pequenos para ficar abaixo do limite. Os montantes são somados pela magnitude, não compensados — um estorno negativo e um positivo não se anulam mutuamente.
Falha de forma segura. Se um estorno anterior na janela não puder ser verificado — por exemplo, um montante ou uma moeda não capturados —, o estorno exige aprovação em vez de saltar a verificação.
O aprovador tem de estar qualificado. Precisa de erp.register.approve — ou de uma delegação ativa de alguém que o possua — e da sua própria permissão na ligação a estornar. Se menos de dois membros possuírem ambos, os estornos iguais ou superiores ao limite são recusados em vez de deixados passar.
O break-glass continua a ser o único caminho em que quem submete indica diretamente quem autorizou uma exceção: uma emergência genuína, decidida por um autorizador independente da cadeia operacional — que possua erp.register.admin mas não .operate nem .approve, mais a sua própria permissão na ligação — e cada exceção fica registada de forma permanente na pista de auditoria.
Uma recusa não explica o motivo. Quer um pedido não tenha aprovador qualificado, tenha sido decidido pela pessoa errada ou nunca tenha sido aberto, o estorno é recusado com a mesma mensagem — deliberadamente, para que uma recusa não possa ser usada para mapear quem tem que função ou permissão. O motivo real consta da pista de auditoria, não do erro.
O estorno de uma execução precisa de uma aprovação por parcela, não uma para a execução. Estornar de uma só vez uma execução intragrupo inteira não obtém uma única aprovação ao nível da execução — cada parcela precisa da sua, porque uma aprovação está associada a um lançamento, a uma ligação e a um aprovador com permissão nela, e não há um nome único a que associar todas as parcelas de uma execução.
Os estornos passam pelo registo. Enquanto a segregação de funções estiver ativa, um estorno pedido através da API de estorno de ERP ao nível do projeto — o caminho usado por um projeto, uma função definida pelo utilizador ou uma conta de serviço — é recusado antes de chegar ao ERP, com uma mensagem a indicar que deve estornar a partir do Registo de lançamentos. Um lançamento para o qual o registo não tem detalhe de captura também não pode ser estornado aí, e tem de ser corrigido no ERP. Os lançamentos não são afetados, e o Business Central, o Oracle Fusion e o Acumatica continuam a dar o seu próprio motivo — o de que não suportam estorno.

A ativação da segregação de funções e a definição do respetivo limite são configuradas para o seu tenant pelo PlaidCloud — ainda não existe um interruptor na consola.

A caixa de entrada de aprovações

Quando o limite o exige, Pedir aprovação — oferecido a par de Estornar na gaveta de detalhes — encaminha o estorno para todos os aprovadores que tenham uma permissão pessoal ativa nessa ligação. Não há ninguém a quem o endereçar; a permissão de ligação é o encaminhamento. Os aprovadores trabalham a fila em Aprovações, na barra: uma caixa de entrada com os pedidos à espera da sua decisão e uma segunda fila com os pedidos que eles próprios submeteram. Cada linha traz o montante, a entidade e o período do lançamento, e há quanto tempo aguarda, pelo que decidir nunca implica sair da fila para ir consultar algo primeiro. Aprovar ou Rejeitar requer um motivo, registado com a decisão.

Uma aprovação está associada exatamente àquilo para que foi concedida — o lançamento, a sua ligação, o motivo indicado e o período de destino — e não pode ser reutilizada para outro estorno, outro motivo ou um período de destino alterado; um pedido alterado precisa de uma nova aprovação. Só pode haver um pedido aberto num lançamento de cada vez, e uma aprovação é consumida no momento em que é utilizada. Após cada aprovação segue-se uma breve retenção, durante a qual o aprovador ou quem submeteu ainda pode cancelá-la — passada a retenção, o estorno pode já ser um documento no ERP, e nada o desfaz. Tudo é verificado novamente no momento em que o estorno é efetivamente aplicado — a função do aprovador, o acesso de ambas as partes à ligação e o mínimo de dois aprovadores do tenant — pelo que uma aprovação concedida anteriormente não sobrevive à perda de acesso do aprovador entretanto.

Delegação

Um aprovador pode delegar a sua autoridade de aprovação noutro membro durante um período limitado, a partir do painel Delegações na barra — útil quando um aprovador vai estar indisponível e os estornos continuam a precisar de decisão. Conceder uma delegação exige erp.register.approve; usar uma, ver as suas e devolver uma só exigem .operate, uma vez que o delegado típico não possui de todo a função de aprovador — é essa a razão de delegar nele.

A autodelegação é recusada, tal como um par recíproco (delegar em alguém que já delegou em si) ou qualquer cadeia mais longa — nenhuma destas é respeitada, para que dois membros não possam fazer discretamente com que as decisões um do outro contem como cobertura de ambos, diretamente ou através de um intermediário. Autor≠aprovador continua a aplicar-se através de uma delegação: um delegado não pode aprovar um pedido da pessoa que nele delegou, nem pode aprovar um pedido seu em nenhuma das situações. Cada decisão tomada por um delegado fica registada na pista de auditoria como tomada sob a autoridade do aprovador delegante, e não como se o delegado possuísse a função por direito próprio.

Escalonamento

Uma aprovação que fique demasiado tempo sem decisão gera um alerta, para que não envelheça em silêncio numa fila que ninguém vigia. Cada destinatário é informado apenas dos pedidos que ele próprio poderia decidir — o e-mail de escalonamento enviado a um colega nunca nomeia um pedido encaminhado para as permissões de outra pessoa — e o alerta não traz montante nem texto livre, a mesma minimização que as restantes notificações do registo seguem.

Execuções intragrupo

Uma execução intragrupo é o conjunto de lançamentos — as suas parcelas — efetuados em conjunto para um fecho, identificado pelo dia de fecho e sequência nelas carimbados na altura, e nunca pela execução do fluxo de trabalho que as produziu. (Esse id de execução do fluxo de trabalho vive separadamente no histórico do próprio razão e pode sobreviver ao carimbo de fecho de um lançamento, pelo que não é uma forma segura de identificar uma execução.) Pode listar execuções, abrir uma para ver as suas parcelas conciliadas e emparelhadas, e estornar a execução inteira como uma única ação governada.

Acessível apenas pela API por agora — GET /erp/register/runs, GET /erp/register/runs/{run_day}/{sequence} e POST /erp/register/runs/{run_day}/{sequence}/reverse — ainda não existe um ecrã na consola.

Saldo zero e emparelhamento

Ao abrir uma execução, as suas parcelas são conciliadas de duas formas, ambas limitadas às ligações para as quais tem permissão pessoal — a mesma regra de visibilidade que vigora em todo o registo, pelo que uma execução que abranja ligações que só vê em parte é comunicada como parcialmente visível e não como desequilibrada.

Saldo zero, por moeda: um veredicto equilibrado, desequilibrado ou indeterminado, com as entidades por trás de cada saldo discriminadas. Uma moeda não fica conciliada a menos que todas as parcelas nela tenham sido capturadas — uma parcela não capturada torna toda a moeda indeterminada, nunca um saldo calculado apenas sobre aquilo que por acaso foi medido.
O emparelhamento faz corresponder cada parcela a pagar à sua contrapartida a receber através de uma chave de emparelhamento que o fluxo de trabalho de lançamento carimba em ambas antes de qualquer uma ser submetida. Um par correspondente tem saldo zero numa moeda; tudo o resto traz um motivo identificado — nenhuma parcela de contraparte visível para si, um montante não capturado, um saldo que genuinamente não é zero ou moeda cruzada, que é comunicada e nunca conciliada, uma vez que não existe taxa de câmbio em lado nenhum da plataforma.

Uma execução com mais de 200 parcelas é demasiado grande para ser conciliada ou emparelhada numa única resposta: ambas devolvem indeterminado em vez de serem calculadas sobre uma fatia truncada da execução, pelo que uma execução grande nunca comunica um falso equilíbrio, ou uma falsa contraparte em falta, causado apenas pela sua dimensão.

Estornar uma execução

Estorne todas as parcelas de uma execução numa só ação, a partir de POST /erp/register/runs/{run_day}/{sequence}/reverse.

A elegibilidade é verificada para todas as parcelas à partida. Tudo o que é possível saber antecipadamente — estado, suporte do adaptador, uma tentativa pendente, a sua própria permissão de ligação — recusa a execução inteira antes de um único pedido chegar a um ERP.
O que não pode ser sabido à partida é comunicado depois, por parcela. O estado em tempo real do ERP e da autorização pode mudar a meio da execução, pelo que uma execução pode terminar parcialmente estornada mesmo que nada parecesse errado na verificação prévia. Nada é compensado automaticamente — lançar mais documentos para desfazer uma falha parcial é uma escrita mais arriscada do que aquela que falhou. Uma execução parcial é corrigida parcela a parcela, da mesma forma que um estorno individual.
Voltar a executar o estorno de uma execução é a forma de concluir um parcial. As parcelas que uma tentativa anterior já estornou são postas de parte em vez de recusadas, pelo que tentar de novo só estorna o que realmente ainda falta.
A segregação de funções aplica-se por parcela, não ao total da execução. Quando a política de SoD do seu tenant está imposta, cada parcela precisa da sua própria aprovação antes de a execução enviar o que quer que seja — seja qual for o montante, e não apenas acima do limite. Isto é deliberadamente conservador: o requisito de uma parcela só pode ser resolvido no momento em que é enviada — uma janela móvel antifracionamento que conta as próprias parcelas da execução à medida que são estornadas, e uma leitura de confirmação em tempo real no ERP que pode falhar — pelo que exigir todas as aprovações à partida é o que impede uma execução de estornar metade das parcelas antes de descobrir a meio que as restantes também precisam de aprovação.
As ações em massa cobrem a execução inteira numa só chamada. POST /erp/register/runs/{run_day}/{sequence}/approval-requests abre um pedido de aprovação para cada parcela sobre a qual quem submete pode agir, e POST .../approval-decisions decide todas as parcelas para as quais um aprovador está qualificado — uma chamada para cada, em vez de um pedido e uma decisão por parcela (20 chamadas para uma execução de rotina de 10 parcelas). O modelo de segurança subjacente não muda: cada parcela continua a ter a sua própria aprovação, associada a esse lançamento, à sua ligação, ao motivo e ao período de destino, e o aprovador continua a precisar do seu próprio acesso à ligação de cada parcela — uma parcela que não pode autorizar simplesmente permanece pendente para alguém que possa, nunca é arrastada. Quem não tenha qualquer autoridade de aprovação é recusado de imediato, sem saber que parcelas têm pedidos abertos. Os resultados regressam por parcela, pelo que uma execução parcialmente autorizável comunica exatamente que parcelas foram decididas e quais ficaram pendentes, e porquê.
O break-glass não está disponível para o estorno de uma execução. É uma exceção de duas pessoas sobre um só lançamento, e aplicar a autorização de uma testemunha a uma execução inteira multiplicá-la-ia pelo número de parcelas. Use o break-glass por parcela em POST /entries/{ledger_id}/reverse.
As execuções com mais de 200 parcelas não podem ser estornadas numa só ação. Estorne-as por partes a partir da lista de lançamentos.

Tendências

As Tendências mostram a taxa de falhas e a latência, agrupadas por ligação ou tipo de ERP, mais a distribuição dos códigos de motivo de estorno — todos os valores, incluindo todos os denominadores, calculados com base nas suas permissões em tempo real. Uma ligação sem nada em estado terminal na janela mostra um travessão na taxa de falhas, nunca 0%, uma vez que um zero perfeito colocaria no topo de uma lista de saúde uma ligação que ninguém usa. A latência é uma amostra limitada sobre os lançamentos terminais mais recentes, identificada como amostra e não apresentada como se cobrisse toda a janela. Os motivos de estorno surgem apenas como os seus códigos estruturados — o motivo em texto livre que alguém escreveu nunca é agrupado nem mostrado aqui.

Linhagem

A Linhagem recua de um lançamento até à execução do fluxo de trabalho que o produziu, e avança até ao documento no próprio ERP. Pesquise por id de execução ou pelo id de razão de um lançamento — perguntar por id de razão resolve a execução primeiro através das suas próprias permissões, pelo que um lançamento numa ligação que não pode ver não resolve nada em vez de expor de que execução provém. Quando o PlaidCloud consegue verificar o formato do URL de documento do ERP para esse adaptador, a linhagem inclui uma ligação direta ao documento; quando não consegue, ou o lançamento nunca foi confirmado, indica qual desses é o motivo em vez de adivinhar uma ligação. A chave de negócio do ERP continua a nunca aparecer aqui — a chave de linhagem é o run_id do fluxo de trabalho, e o ponteiro para o ERP é confirmation_id, tal como em todo o resto do registo.

Fechos

Pedir um fecho serve para selar um período — para uma ou mais ligações e entidades — num instantâneo imutável, num ponto no tempo: tudo o que o registo sabia sobre esses lançamentos nesse momento, mantido mesmo que as linhas em tempo real sejam depois tentadas novamente, estornadas ou limpas. Destina-se a um período contabilístico bloqueado em que precisa de um registo defensável e inalterável, e não do que a grelha em tempo real mostra hoje. Pedir ou ler um fecho só é possível através da API por agora; ainda não existe um ecrã na consola para pedir ou consultar um.

Pedir um fecho (erp.register.operate) é uma ação administrativa ao nível do tenant, não pessoal — as ligações e entidades que indica são exatamente as que são seladas, independentemente das suas próprias permissões de ligação. Voltar a fechar um período já fechado nunca é destrutivo: produz sempre uma nova revisão, numerada em separado, em vez de substituir a última.

Os fechos materializam-se por si. Pedir um fecho não o sela de imediato — uma tarefa em segundo plano percorre automaticamente todos os fechos pendentes, num agendamento diário, e escreve o respetivo instantâneo Iceberg sem qualquer ação adicional da sua parte. Se uma passagem não conseguir concluir um determinado fecho (uma falha do armazém de dados, por exemplo), esse fecho é marcado como falhado em vez de ficar bloqueado, e é retomado e tentado novamente automaticamente na passagem do dia seguinte — nunca é ignorado em silêncio. Um fecho invulgarmente grande (que abranja mais de cerca de 500 000 lançamentos) é o único caso que não se resolve assim por si: a passagem recusa selá-lo de uma só vez, e é necessária a ajuda do PlaidCloud para o fechar em lotes mais pequenos. É um caso extremo raro na maioria dos períodos de relato.

Depois de um fecho ser materializado, lê-lo de novo aplica as regras habituais do registo, resolvidas novamente em tempo real a cada leitura e não fixadas no instantâneo no momento da selagem: só vê as linhas de ligações e projetos para os quais tem atualmente permissão. Ao contrário da grelha em tempo real, que mostra valores monetários e a identidade do autor a qualquer pessoa que consiga ver a linha, os valores de um fecho ficam mascarados a menos que possua erp.register.admin — a mesma regra que a Exportação aplica. Um fecho comunica também a sua própria contagem de chegadas tardias: lançamentos submetidos ou alterados depois do limite máximo do fecho, e portanto nunca capturados na selagem — visíveis apenas pedindo um novo fecho para o mesmo período, uma vez que nada reabre um fecho antigo.

Exportação

As Exportações e alertas são o local onde o registo sai da consola sob a forma de um ficheiro ou de uma notificação — e a única superfície em que os controlos 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 registo para o consultar não exige.

Transferir agora

Exporte o registo que está a ver como um CSV compatível com o Excel ou como JSON, construído de novo com as suas permissões em tempo real. Aplicam-se dois perfis de máscara consoante a sua função:

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

Todas as exportações seguem as mesmas regras que o resto do registo: 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 depurados, e um montante não capturado fica em branco — distinguido de um mascarado, para que um espaço em branco nunca seja lido como «nada foi lançado» quando na realidade significa «a sua função não vê isto».

Agendar uma entrega

Crie um agendamento — um filtro, uma cadência, um formato e uma lista de destinatários por membro, ou uma ligação Slack para uma notificação sem qualquer conteúdo de linha. São oferecidos dois tipos:

Exportação — uma entrega recorrente em CSV ou JSON do registo filtrado.
Alerta — uma notificação desencadeada por uma de três condições: um lançamento real falhado, uma autorização em envelhecimento ou o estorno de um lançamento. Pré-visualize o que um desencadeador corresponderia atualmente para si antes de o subscrever.

O ficheiro de cada destinatário é construído a partir das suas próprias permissões em tempo real no momento do envio, e não das do proprietário do agendamento — dois destinatários do mesmo agendamento podem receber dois ficheiros diferentes, e um destinatário que entretanto perdeu a função de exportação, perdeu todas as permissões de ligação, foi desativado ou não tem endereço registado é ignorado individualmente, com um motivo indicado, em vez de ser descartado em silêncio. Apenas o proprietário do agendamento ou um erp.register.admin pode eliminar ou disparar o agendamento de outra pessoa.

Retenção

Configure durante quanto tempo o registo mantém três tipos de histórico: o detalhe do conteúdo capturado, os lançamentos simulados e a pista de auditoria — cada um como um número de dias, ao nível do tenant, exigindo erp.register.admin. Todos os campos são escritos em cada chamada; um campo omitido limpa esse horizonte em vez de o deixar inalterado, e um tenant não configurado mantém tudo (todos os horizontes surgem como nulos, sem uma predefinição oculta).

A passagem de retenção que atua sobre esta política corre agora automaticamente, uma vez por dia, ao nível do tenant — o mesmo mecanismo de tarefas periódicas que também aciona os alertas e exportações agendados, faz passar os lançamentos em atraso para a fila de exceções e faz expirar os lançamentos simulados antigos.

Vistas de resumo

O Resumo abre como um painel a partir da barra. Agrupe o registo por execução, período ou ligação para ver subtotais e um resumo de estados em vez de linhas individuais — o agrupamento é um controlo segmentado no topo do painel, pelo que alterna entre Por execução, Por período e Por ligação no local, em vez de reabrir o que quer que seja.

Um valor em branco continua em branco. Um lançamento sem montante capturado — todos os lançamentos SAP, um lançamento nascido em estado terminal ou um escrito antes de esta funcionalidade existir — não contribui com nada para um subtotal e nunca é mostrado como 0.00. Cada grupo indica por palavras se todos os lançamentos nele foram capturados, se alguns não foram ou se nenhum foi.
As moedas nunca são misturadas num só total. O PlaidCloud não faz qualquer conversão cambial, pelo que um grupo que abranja mais do que uma moeda tem uma linha por moeda em vez de um único valor misturado — veja Formatação de valores monetários.
Uma lista de grupos limitada continua a totalizar corretamente. Se um agrupamento produzir mais grupos do que a vista apresenta, a linha de totais continua a abranger todos os grupos, e não apenas os apresentados, e di-lo.

A faixa de Estado das ligações aparece também nesta vista.

Totais de controlo

Os Totais de controlo abrem como um painel a partir da barra, sobre as mesmas ligações e entidades a que A regra de visibilidade já o limita. Agrupa os lançamentos em lotes e indica, para cada um, um veredicto de três estados — Equilibrado, Desequilibrado ou Indeterminado — com o motivo declarado pelo próprio servidor, nunca uma palavra isolada.

Indeterminado é uma resposta real, não uma aprovação branda. Um lote só é Equilibrado quando todas as linhas nele foram medidas e os seus grupos coincidem. Uma janela vazia, um montante não capturado, um adaptador que dispara e esquece, ou uma leitura interrompida antes de todo o lote ser lido resultam todos em Indeterminado, com o motivo explicado — nunca um verde por omissão.
O dinheiro fica em branco, nunca a zero. Os totais de origem e de lançamento de um grupo, e a sua diferença, ficam em branco sempre que o montante não foi capturado ou confirmado — a mesma regra que as vistas de resumo 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 somados entre si. O PlaidCloud não faz qualquer conversão cambial, pelo que um lote que abranja mais do que uma moeda ou entidade lista os totais de cada grupo lado a lado em vez de os misturar — veja Formatação de valores monetários para saber como esses valores são apresentados.
As linhas anteriores à captura têm o seu próprio balde (no batch id). Um lançamento escrito antes de a captura de lotes existir não pode ser reagrupado num lote que nunca o continha, pelo que é mostrado como uma linha própria, e não integrado nem descartado.

A mesma leitura abrange também duas questões relacionadas: a preparação para o fecho do período, por entidade e período, que degrada para Indeterminado — e não para um falso Bloqueado — num balde para o qual a plataforma ainda não tem números, como uma linha anterior à captura num fecho de transição; e o desvio de confirmação, comunicado por documento e não por grupo, porque dois documentos que derivam em sentidos opostos dentro do mesmo grupo de moeda/entidade podem coincidir no total e esconder ambos.

A gaveta de detalhes

A gaveta de detalhes ancora-se à direita da área de trabalho, para que a lista continue visível enquanto lê um lançamento. Abra-a a partir do ícone de lupa de uma linha, premindo Enter na linha selecionada ou fazendo duplo clique na linha. Está organizada em separadores:

Separador	Mostra
Diário	As linhas de débito e de crédito do lançamento, lidas como um contabilista as leria. Veja O separador Diário.
Pedido/Resposta	O pedido enviado e a resposta do ERP, filtrados para minimização de dados (veja abaixo).
Erros	Qualquer erro que o ERP ou o passo de lançamento devolveu.
Cronologia	Os estados do lançamento por ordem, desde a submissão até ao estado atual.
Relacionados	O lançamento original e o seu estorno, ligados entre si, quando existe um.
Auditoria	Um registo só de leitura da atividade neste lançamento. Escasso por agora — veja O separador Auditoria abaixo.
Comentários	Comentários encadeados neste lançamento, com @menção por id de membro. Veja Colaboração.
Aprovação	O estado de revisão atual do lançamento — Revisto, Limpo ou Requer acompanhamento — com o seu histórico completo. Veja Colaboração.

O separador Diário

O separador Diário lê um lançamento da forma como um contabilista o faria — as suas linhas de débito e de crédito por conta, em vez do conteúdo bruto do pedido.

Apenas as colunas que cada ERP realmente captura. O separador mostra os campos que um dado sistema envia e nenhuns outros: um lançamento Acumatica mostra a sua subconta, enquanto um sistema que nunca envia uma não mostra qualquer coluna de subconta vazia — não tem de passar por colunas que nunca terão conteúdo.
As dimensões e as worktags ficam por baixo de cada linha. O detalhe analítico de uma linha — as suas dimensões, ou as suas worktags do Workday — aparece sob a linha a que pertence, e não comprimido em colunas adicionais no topo.
Um apuramento por moeda com uma verificação exata de equilíbrio. Cada moeda é apurada por si; a verificação nunca mistura moedas e nunca arredonda para zero um lançamento desequilibrado, pelo que um desequilíbrio genuíno é mostrado como o valor que é e não desaparece num 0.00.
Um adaptador que não captura detalhe de linhas di-lo. Quando um controlador — como o SAP on-prem — não regista qualquer discriminação por linha, o separador di-lo claramente em vez de mostrar uma grelha vazia que pode ser lida como «sem linhas».

Triagem por teclado

Na Fila de exceções, as teclas de seta para cima e para baixo percorrem um lançamento após o outro com a gaveta de detalhes a acompanhar a seleção — para que possa fazer toda uma passagem de triagem pelo teclado, lendo o detalhe de cada lançamento à vez sem recorrer ao rato.

A grelha principal mantém deliberadamente a seleção com o rato, Enter e o duplo clique: a sua seleção de várias linhas é o que aciona as ações em massa, como tentar novamente e limpar lançamentos simulados, pelo que as teclas de seta aí movem a seleção em vez de fazerem a gaveta percorrer todas as linhas.

Colaboração

Trabalhe um lançamento com a sua equipa sem sair do registo: comente-o com @menção, registe uma aprovação ou vigie uma ligação ou uma execução para acompanhar a sua atividade futura.

Os Comentários são notas encadeadas, em texto simples, sobre um lançamento, a partir do respetivo separador Comentários. Faça @menção de um colega por id de membro e este é notificado — se conseguir ver o lançamento nesse momento; essa verificação é refeita no momento do envio, nunca assumida a partir de quem foi mencionado.
A Aprovação regista um de três estados — Revisto, Limpo ou Requer acompanhamento — com uma nota opcional, e mantém o histórico completo de quem definiu o quê e quando. É um registo, não uma barreira: atualmente nada bloqueia um lançamento ou um estorno com base no seu estado de aprovação.
Vigiar uma ligação ou uma execução — dois interruptores separados — para ser notificado da atividade em qualquer uma delas daqui em diante.

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

Minimização de dados

O registo foi concebido para mostrar o que um revisor precisa para confirmar que um lançamento ocorreu, sem expor os dados sensíveis que um passo de lançamento tratou para o concretizar.

Os conteúdos de pedido e de resposta estão numa lista de permissões por adaptador. Um campo só aparece se tiver sido explicitamente classificado como seguro para guardar. Números de contas bancárias, números de encaminhamento, IBAN, números de identificação fiscal e outros identificadores pessoais são removidos antes de alguma vez ver o conteúdo.
A chave de negócio do ERP é totalmente retida. Pode incorporar o nome de um fornecedor ou outro código de referência, pelo que nunca chega ao registo — incluindo a Assistência de IA: a mesma lista de permissões que decide o que vê decide o que um pedido a um modelo pode ver, e um valor de chave natural em qualquer ponto desse conteúdo é recusado de imediato em vez de enviado. Identifique uma linha pelo seu id de razão e use o confirmation_id como ponteiro do próprio ERP para o documento — o mesmo campo que o Histórico de lançamentos do ERP designa confirmation_id.
Os campos de texto livre são depurados por padrões na leitura, e excluídos por completo — e não apenas depurados — do resumo, de qualquer pedido a um modelo de IA e de qualquer exportação. A depuração por padrões apanha formatos como um IBAN ou um número fiscal; não consegue apanhar o nome de um fornecedor escrito numa nota, que é a razão pela qual tudo o que sai da consola como ficheiro descarta esses campos por completo em vez de confiar apenas na depuração.

O separador Auditoria

O separador Auditoria é apenas de apresentação. O seu detalhe é intencionalmente escasso nesta versão, porque o vocabulário de auditoria subjacente ainda não foi classificado — conte com ele a preencher-se à medida que esse trabalho avança, e não com uma alteração da forma como lê o resto da gaveta.

Tudo o resto nesta página — a fila de exceções, o estado das ligações, as vistas de resumo, as ações em massa, a nova tentativa individual, o estorno, os totais de controlo, a Assistência de IA, as tendências, a linhagem, os fechos, a colaboração e a exportação — funciona hoje.