Relatório de negócio: componentes do documento

Histórico de versões

• 2.33.0

  O relatório agora mostra os componentes de um documento: cada parte de uma lista que não é linha de item — como a pressão sistólica e a diastólica de uma medição, cada dose de uma prescrição ou cada diagnóstico — vira uma linha própria, na nova entidade "Componente do documento" do construtor de relatórios e num card do relatório de negócio, por tipo de mensagem. Antes esses valores eram só sinalizados e não apareciam. O valor não entra nos totais, e dado de saúde sai mascarado. Documento, item e parceiro não mudam.

  10/5/2026 · updated

• 2.32.0

  O relatório de negócio passa a mostrar o imposto total também quando o documento não traz o total (MOA+176): ele é a soma exata de todos os grupos de imposto do documento (um por alíquota) e aparece com a marca "derivado". Antes, um documento com imposto só por grupo ficava com o imposto total vazio. O total declarado continua sempre vencendo, e quem já tinha o total (declarado ou somado das linhas) vê o mesmo número.

  10/5/2026 · updated

• 2.31.0

  Total do imposto e imposto de uma linha de imposto ficam como dois conceitos, cada um com a sua definição: o total de impostos da mensagem (EDIFACT MOA+176, IDoc E1EDS01 005, SAP TotalTaxAmount) e o imposto de uma alíquota do resumo (MOA+124, E1EDK04). Um documento com duas alíquotas tem dois valores de grupo e um total, e o relatório de negócio nunca toma um grupo como total. O conceito obsoleto que apontava para o imposto do grupo deixa de se descrever como "total". Nenhum mapeamento publicado muda e a saída do Sugerir é a mesma.

  10/5/2026 · updated

• 2.30.0

  Na entrada de arquivos EDIFACT, o grupo que se repete no resumo da mensagem (o imposto do resumo da fatura, depois dos totais, e o desconto/encargo do resumo) passa a ser lido no mesmo caminho que o catálogo e a saída usam (TAX_2, ALC_2), em vez de se misturar ao do cabeçalho. O Sugerir passa a ler o imposto do documento no resumo, uma linha por alíquota, e a linha sem imposto próprio herda o do documento. Mapeamentos já publicados não mudam: quem lia o imposto do resumo junto com o do cabeçalho continua lendo assim, e o documento enviado ao SAP é o mesmo.

  10/5/2026 · updated

• 2.29.0

  O aprendizado da base de conhecimento pelos mapeamentos salvos volta a contar o aceite de uma regra que vai para um segmento qualificado (como o NAD do comprador ou o RFF do número do IVA): o significado de cada qualificador vem do dicionário de qualificadores, não do campo genérico do segmento. A medição semanal desse aprendizado passa a dizer por que um aceite não contou (repetido no mesmo mapeamento ou significado ambíguo), e há um relatório antes × depois da mudança de regra de 26/09/2026. Nenhum mapeamento muda o arquivo que gera.

  10/4/2026 · updated

• 2.28.0

  Na fatura EDIFACT (INVOIC), o imposto do documento no resumo agora sai separado por alíquota: quando os itens da fatura têm códigos de imposto ou alíquotas diferentes, o Sugerir gera um grupo de imposto do resumo (TAX+7 com MOA+124) para cada um, com a soma do imposto dos itens daquele código. A alíquota sai no grupo quando a origem a informa por item, e o tipo do imposto sai quando há de-para do código cadastrado; sem nenhum dos dois, os grupos não teriam como se distinguir e sai um grupo só com a soma. Se algum item vier sem o código ou a alíquota que separa os grupos, o resumo não sai e a mensagem traz o aviso. Faturas com uma alíquota só saem iguais a antes, exceto quando o item informa a alíquota ou o código tem de-para do cliente: aí o grupo único passa a levar a alíquota ou o tipo do imposto. Mapeamentos já publicados não mudam.

  10/4/2026 · updated

• 2.27.0

  Na fatura EDIFACT (INVOIC), o Sugerir passa a colocar o imposto do documento no lugar que a norma reserva para ele: o grupo de imposto do resumo, depois dos totais (TAX+7 com o MOA+124), com a soma do imposto das linhas. Antes não havia lugar para ele no arquivo: o catálogo dava o mesmo caminho ao imposto do cabeçalho e ao do resumo. Agora toda mensagem que repete um grupo no cabeçalho e no resumo tem o do resumo com caminho próprio no catálogo (TAX_2, ALC_2), e o arquivo o escreve na posição certa. Mapeamentos já publicados não mudam: o arquivo que eles geram é o mesmo.

  10/4/2026 · updated

• 2.26.0

  O texto do ajuste sai no EDIFACT de saída dentro do grupo do ajuste: o motivo do ajuste (código da lista UNCL 4465, vindo da origem pelo de-para) abre o AJT e o texto vai no FTX logo abaixo, com o qualificador de motivo. Sem o motivo na origem o texto não sai, e uma mensagem sem o motivo sai sem o ajuste, com aviso, em vez de parar.

  10/4/2026 · updated

• 2.25.0

  A lista de código de um campo OData (unidade do SAP ou código ISO da unidade) passa a vir da anotação do próprio $metadata do serviço, não do nome do campo. Campos de unidade com qualquer nome são reconhecidos; o nome só decide o que o $metadata não anota (código ISO da unidade no OData V2 e tipo de documento). Os mappings já publicados não mudam.

  10/4/2026 · updated

• 2.24.0

  A base de conhecimento foi revisada nos campos em que o aprendizado automático tinha aprovado um segundo significado sem conferência (26/09): data de fatura no aviso de expedição, total de controle no contador de linhas, tipo da condição de preço como código do imposto, data do pedido no lugar da data da referência, entre outros. Nos segmentos qualificados do EDI (referências, datas, valores), quem decide o significado de cada ocorrência é o qualificador. Os arquivos gerados não mudam.

  9/26/2026 · updated

• 2.23.0

  A base de conhecimento só aprende com um mapeamento salvo quando a regra confirma o significado dos dois lados: o campo de origem e o campo de destino precisam ter o mesmo conceito. Nos outros casos o save fica só registrado no histórico. E quando dois campos do SAP carregam o mesmo conceito, o preço calculado usa o de maior confiança.

  9/26/2026 · updated

• 2.22.0

  O valor da linha (MOA+203) e o preço líquido (PRI+AAA) da fatura voltam a sair do valor líquido do SAP, não do bruto. E a base de conhecimento não aprende mais sozinha um significado de campo que ninguém confirmou: quando um campo tem mais de um significado possível, salvar um mapeamento que o usa fica só registrado, sem aprovar nenhum deles.

  9/26/2026 · updated

• 2.21.0

  A base de conhecimento reconhece, na leitura de um pedido X12 850 do parceiro, a data do pedido de compra (DTM*004) e o número do contrato (REF*CT). São códigos só de leitura: o 850 gerado a partir de um pedido SAP não muda.

  9/26/2026 · updated

• 2.19.0

  A chave da condição de pagamento do SAP (por exemplo 0004) passa a ir como texto, que qualquer parceiro aceita: no EDIFACT em FTX+AAB (texto das condições de pagamento), no X12 no ITD12 e no IDoc no ZTERM. Antes ia num campo de código (PAT+1+0004::91), válido pela spec, mas reprovado pelos validadores de parceiros, que exigem a lista oficial de códigos. A condição de pagamento (PAT+1) só sai quando há o número de dias. As notas do documento e da linha saem com o qualificador de texto geral (FTX+AAI), que a spec exige.

  9/26/2026 · updated

• 2.20.0

  Nova altura na base de conhecimento: o componente, para as listas que repetem valores diferentes dentro de um documento sem ser linha (as partes de uma observação, as instruções de dosagem, os motivos e diagnósticos). A trava das anotações e o relatório passam a reconhecê-la, e a geração do FHIR passa a levar os componentes da observação, a faixa de referência e a frequência de cada dosagem. O valor, o código, a unidade e a data de uma observação, laudo, pedido ou prescrição vão para o documento. O aviso de pagamento (REMADV) ganha uma linha por documento pago, com as linhas desse documento como sub-linhas, e os textos de ajuste do cabeçalho e da linha (ORDRSP, INVOIC, REMADV) têm conceito próprio.

  9/26/2026 · updated

• 2.18.0

  A unidade faz parte da quantidade em todos os formatos: pedido, fatura e aviso de remessa saem com a unidade convertida pela base de conhecimento. A base pode declarar uma data reserva para outra (a real, senão a planejada). As anotações novas herdam a versão da mensagem.

  9/26/2026 · updated

• 2.17.1

  Na fatura EDIFACT, o pagador sai como pagador (NAD+PR) e não mais como recebedor do pagamento (NAD+PE); o recebedor só sai quando a origem o traz. O faturado (NAD+IV) é o da lista de parceiros da fatura; o pagador só o substitui quando a fatura não traz faturado. No X12 e no IDoc nada muda.

  9/26/2026 · updated

• 2.17.0

  A agência da lista de códigos (por exemplo "lista do vendedor", 91 no EDIFACT) passa a sair só para o código cujo conceito declara quem o atribui — a chave da condição de pagamento do SAP é do vendedor — e não para qualquer valor que caia naquela posição. A validação só aceita código fora da lista oficial quando a agência informada existe; com a agência GS1 a lista oficial continua valendo, somada à extensão EANCOM.

  9/26/2026 · updated

• 2.16.1

  O aviso de remessa (DESADV) gerado da remessa de saída do SAP passa a sair completo: data de despacho, data de entrega prevista e data do documento, o material de cada linha e a quantidade despachada dentro da linha, além do comprador, do recebedor da mercadoria e do transportador quando a remessa o tem. O recebedor sai uma vez só (NAD+ST). A data de faturamento da remessa deixou de ocupar a data do documento.

  9/26/2026 · updated

• 2.16.0

  A condição de pagamento da fatura sai com o significado certo. A chave da condição do SAP (por exemplo 0004) vai no EDIFACT como código do vendedor (PAT+1+0004::91), e não mais no campo do número de dias, onde reprovava na validação. O número de dias até o vencimento virou um conceito próprio, usado no EDIFACT (PAT, C112), no X12 (ITD07) e no IDoc (E1EDK18 com o qualificador 003); quando a origem não tem os dias, o campo não sai. No IDoc a chave vai no E1EDK01.ZTERM.

  9/26/2026 · updated

• 2.13.3

  O total do imposto da fatura do SAP passa a ter o significado certo em todos os formatos: é o total de todos os impostos do documento, e não o imposto de uma alíquota. No EDIFACT ele sai no MOA+176 do resumo (antes saía como MOA+124 solto, que o EANCOM não aceita no grupo de totais) e no IDoc no segmento de totais E1EDS01 com o qualificador 005. Os relatórios também passam a ler cada total do E1EDS01 pelo qualificador: número de itens, valor líquido, total do imposto e valor faturado. O imposto por alíquota separado no resumo do EDIFACT fica para uma próxima versão.

  9/26/2026 · updated

• 2.13.2

  O pagador da fatura do SAP (PayerParty) passa a ser reconhecido como pagador, e não como o destinatário da fatura. Quando a fatura traz os parceiros, o faturado sai do parceiro RE — antes o pagador tomava o lugar dele. Quando a fatura só tem o cabeçalho (sem a lista de parceiros), o faturado continua saindo com o pagador, por uma regra declarada na base de conhecimento, e agora o pagador também sai no papel dele: no X12 no N1*PR e no IDoc no E1EDKA1 RG; no EDIFACT EANCOM o pagador não sai por padrão (o NAD+PR não está na lista do perfil).

  9/26/2026 · updated

• 2.15.0

  Novos conceitos para o valor de um recurso de saúde FHIR que não tem linhas: o que foi observado, o resultado, a unidade e a data de uma observação ou laudo, o serviço pedido e a data dele, o tipo de serviço do atendimento. Antes esses valores usavam conceitos de linha e não apareciam no relatório. Novo conceito para o texto do ajuste de uma linha (grupo AJT dentro da linha do ORDRSP e do REMADV). As trocas entraram na fila da curadoria automática como proposta.

  9/26/2026 · updated

• 2.14.0

  A base de conhecimento passa a dizer quando uma mensagem não tem linha de item por natureza: cadastros (parceiro de negócio, produto), recursos FHIR únicos (paciente, observação, atendimento…) e o aviso de aplicação APERAK. A revisão das anotações para de pedir o número da linha nessas mensagens e mostra o motivo; o relatório de negócio não fatia as listas delas como se fossem itens. Novo conceito para o texto de um ajuste do documento (FTX do grupo AJT). As propostas de identidade da linha do DESADV e do REMADV, do texto do ajuste e da descrição comum do cabeçalho do ORDRSP entraram na fila da curadoria automática.

  9/26/2026 · updated

• 2.13.1

  Correção: a segunda linha da descrição do item no EDIFACT (IMD, 2ª ocorrência da descrição) passa a ter o próprio conceito (descrição do item — linha 2). Antes as duas linhas tinham o mesmo conceito: o relatório mostrava só uma delas e o gerador de mapeamento escolhia a linha pela ordem da lista. O arquivo gerado hoje não muda.

  9/26/2026 · updated

• 2.13.0

  A base de conhecimento ganhou lugar para cinco dados que a curadoria automática não conseguia decidir: as linhas 2 a 5 do nome do parceiro (cada linha vai para a mesma linha no destino, sem juntar nem cortar), o transportador (id e nome, do segmento de transporte — no DESADV também como parceiro NAD+CA), o nome ligado à situação de uma instrução, o titular da conta bancária (duas linhas) e a descrição comum a todas as linhas dada no cabeçalho da fatura/pedido (fica no documento; não é copiada para cada linha). As anotações voltam para a fila da curadoria, que decide com as checagens de sempre. Nenhum arquivo entregue muda.

  9/26/2026 · updated

• 2.12.0

  Conversão pedido → fatura e pedidos em aberto, dentro da Inteligência de Negócio, agora é medida real pela camada semântica — não mais um texto dizendo que depende da conciliação. A fatura cita o pedido (reference.order, o RFF+ON do EDIFACT / QUALF 001 do IDoc / PurchaseOrderByCustomer da OData); casando essa referência com o número do próprio pedido (order.number, com purchase_order.number e o número do documento como reforço), o bloco mostra quantos pedidos converteram, quantos ficaram em aberto, a taxa de conversão e uma lista dos pedidos em aberto (cliente por pseudônimo, valor e dias parado), sempre dentro da janela do período escolhido. Sem pedido no período o bloco some; com pedido e nenhuma fatura, todos os pedidos contam como em aberto.

  9/25/2026 · updated

• 2.11.0

  Dicionário de papéis curado: um nome de papel por função de negócio. O faturado é invoicee em todo formato (o N1*BT do X12 deixa de ser bill_to), o fornecedor é supplier (o NAD+SU do INVOIC deixa de ser seller, e o N1*VN do X12 deixa de ser vendor; o vendedor fica só no NAD+SE), e o recebedor aparece como delivery no relatório também quando o formato o chama de ship-to (X12 N1*ST, NAD+ST do DESADV) — o conceito ship-to continua separado no mapeamento. O pagador (RG no SAP) ganha papel próprio, payer: o relatório de negócio deixa de mostrar "Sem papel declarado" para ele, o IDoc passa a levar o E1EDKA1 RG e o X12 o N1*PR quando a origem tem pagador; no EDIFACT EANCOM o pagador não sai por padrão (o NAD+PR não está na lista do perfil). Os qualificadores que já saíam nos arquivos não mudam.

  9/25/2026 · updated

• 2.10.1

  Correção: a anotação automática da base de conhecimento não apaga mais o histórico da anotação. Quando uma nova passada da anotação reescrevia uma anotação que já existia, o histórico de revisão (reaberturas e desbloqueios feitos por pessoas, eventos de mapeamento, marcação de antiga pela rotina), a contagem de mapeamentos que aceitaram ou recusaram a sugestão e o consenso entre empresas eram perdidos. Agora a gravação acrescenta ao que já existe, mantendo as 50 entradas mais recentes do histórico. A justificativa da IA aparece no histórico como nota, não como aprovação.

  9/25/2026 · updated

• 2.10.0

  Curadoria automática com origem própria e trava manual na base de conhecimento (#69). A regra: decisão manual de pessoa sempre vence a automática, e a automática vence o que a IA e as rotinas sugerem. Uma anotação decidida pela rotina de curadoria do Lefia passa a ter a origem "Curadoria automática" (auto_curated), com as fontes consultadas (especificação, link, teste em ferramenta, teste automatizado, dado medido) e a confiança registradas no histórico e na trilha de auditoria — antes, essas decisões ficavam com a origem da sugestão da IA, e virar "verificada por pessoa" seria proveniência falsa. A curadoria automática não entra como gabarito da avaliação de IA. Quando uma pessoa aprova, rejeita ou troca o conceito, o campo fica travado para automação: nenhuma rotina, sugestão de IA, feedback de mapping ou refresh muda o conceito, o status ou a origem dele depois; a trava é garantida no banco. Na curadoria (/admin/catalog-semantics), o selo "Curadoria automática", o botão para confirmar a decisão automática como sua (vira decisão manual) e, nas travadas, o selo "travada" e "Liberar para automação", registrado na trilha. As curadorias feitas pelo agente em 25/09/2026 foram migradas para a origem nova, com o histórico preservado.

  9/25/2026 · updated

• 2.9.0

  Relatório do lado destino: total do cabeçalho pelo qualificador (#34). No EDIFACT o total das linhas (MOA+79), o total do pedido (MOA+86) e o imposto (MOA+124) moram no mesmo campo; cada um agora entra no seu conceito pelo qualificador da própria ocorrência, na linha ou no cabeçalho, pelas mesmas necessidades que o compilador usa. Qualificador desconhecido não vira outro total: fica de fora e é contado.

  9/25/2026 · updated

• 2.8.0

  Decisões humanas sobre a base de conhecimento na trilha de auditoria (#78). Aprovar, rejeitar e trocar o conceito de uma anotação do catálogo, e confirmar o aviso da trava da linha, passam a gravar um evento imutável em audit_events (quem decidiu, quando, o campo, o conceito e o status antes e depois, o motivo), pelo mesmo ponto único do resto da trilha — com o catálogo de ações e a redação de PII da metadata. A confirmação da trava da linha é um evento próprio e avisa os outros owners. Antes, a decisão ficava só no histórico dentro da anotação, que guarda as 50 entradas mais recentes e mistura decisão de pessoa com feedback de mapping e rotinas; esse histórico segue como resumo. Na curadoria (/admin/catalog-semantics), cada linha ganhou o botão de histórico: as decisões registradas na trilha, paginadas, e abaixo o que só existe no resumo (decisões anteriores à trilha, rotinas, feedback de mapping). O histórico antigo não é copiado para a trilha — a trilha não se reescreve.

  9/25/2026 · updated

• 2.7.0

  R3b: Inteligência de negócio pela camada semântica; pipeline antigo de negócio aposentado (PR #1147, release #1158).

  9/25/2026 · updated

• 2.6.0

  Relatórios, análise de negócio: projetor v2 pela KB — conceito obsoleto segue o substituto (linhagem), linha pela identidade aprovada da coleção (não pela posição do array mais externo), anotação aprovada vence a pendente; medida "líquido dos itens". Reprocessar a materialização por empresa após o deploy.

  9/25/2026 · updated

• 2.5.0

  Camada semântica de relatórios, as CDS views do Lefia: entidades, campos e associações declarativos sobre o catálogo existente, format-agnostic nos 8 formatos. Em cima dela: relatórios técnico e de negócio, conciliação origem x destino e construtor com IA que emite definição validada, nunca SQL. Materialização do conteúdo: payload sai do caminho de leitura, 5.176 KB para 0 e 3 a 4 vezes mais rápido. Itens #514, #515, #516, #517, #518, #588.

  9/19/2026 · updated

• 2.3.0

  IMD item description vem do ITEM: BillingDocumentItemText (V2+V4) → item.description approved 0.9 (alinha Billing ao padrão *ItemText de SalesOrder/PurchaseOrder/Delivery/Product); rejeitada anotação de pricing (PriceElementDescription). Migration 20260609_0200.

  6/9/2026 · updated

• 2.4.0

  Payment terms FORA do grupo PAT inteiro (C110/C112/DTM/MOA/PCD/PAT01) nos 4 formatos EDIFACT — 4277 é codificado 1-7 (drafts, não prazo) e o C112 tem 2475 obrigatório próprio. PAT emite só PAT+1 (válido). Decomposição NT30→C112 = frente futura. Migrations 20260609_0300+0400.

  6/9/2026 · updated

• 2.2.0

  Curadoria: party.name → C08001 (componente obrigatório do C080) em 8 msgs EDIFACT + SalesOrder over-broad concepts (LIN01/NAD/RFF, 3 conflitos falsos→0) + rejeita org-codes como party identifier.

  6/8/2026 · updated

• 2.1.0

  Quality check (Bruno 31/05): 2 problemas reais consertados. (1) 32 concept_key órfãos em message_qualifier_needs — o vocab do layer qualifier é granular (party.payer≠party.invoicee), o dicionário era grosso; adicionei 25 concepts granulares canônicos (qualifier EDIFACT como synonym) em vez de remapear/colapsar. Restaura match-por-conceito de amounts/dates/refs. (2) 127 duplicatas em catalog_field_semantics deduplicadas (mantém approved>reviewed>confiança>recente, 3778→3651). Resultado: órfãos 32→0, dups 125→0, concepts 73→98. Business-minimum INVOIC limpou (clinical.* ruído sumiu → 12/15 faltantes legítimos).

  5/31/2026 · updated