Sap drc ksef poland

Thiago Barbosa, bem, o fato é que guardar cada XML rejeitado é bom, mas eu discordo de transformar isso em regra geral. Em agro, a gente migrou de outro ERP e o histórico antigo nem tinha o mesmo formato, então a comparação gera ruído. Antes de montar o acervo, precisamos de um modelo de referência limpo e de um critério para saber se a rejeição veio do cadastro ou do envio. Sem isso, o acervo só guarda erros diferentes.

O risco que já vi é a equipe corrigir o XML sem registrar a versão do modelo, e o lote seguinte volta a falhar sem ninguém entender por quê. Complemento o ponto do Eduardo Oliveira sobre a trilha: sem o histórico de geração, a auditoria não consegue provar qual mudança resolveu. Eu sei que, saindo um pouco do tema, muita gente só pensa na urgência e esquece dos registros. Na minha mineração, a regra simples foi guardar cada XML rejeitado com o horário e o retorno, para comparar depois. Assim a falha vira padrão e não susto.

Concordo em parte com você, Daniela Nunes, a tabela ajuda muito, mas, olha, antes de mais nada, eu discordo de tratar a rejeição como erro de cadastro só porque o item é novo. Na minha siderurgia, o formato da nota pede uma informação que o DRC não traz, então sobra o campo vazio. Você conseguiu fechar isso com alguma customização ou ficou só no mapeamento?

Veja, aqui na empresa, uma dúvida curta: por que confiar no modelo validado se ele pode ter sido criado com o mesmo mapeamento que está quebrado? Eu discordo de Daniela Nunes nesse ponto, e veja, aqui na minha área, já vimos modelo antigo passar no teste e falhar em produção, porque o ambiente da Polônia pode exigir campos que a versão antiga não preenche. Antes de comparar com um modelo, eu checaria a geração do XML, do início ao envio, e só depois o retorno. Se a trilha não mostra quem gerou cada campo, o diagnóstico fica preso ao log genérico.

Na minha rotina de fechamento no automotivo, a gente só descobre o erro de item quando o lote já foi enviado, Daniela Nunes. Aqui o retorno chega depois do envio e isso atrasa tudo. O segredo é, viu, separar o cadastro de unidade do cadastro de imposto antes de qualquer teste. Você disse para comparar com o modelo validado: qual ferramenta vocês usam para gerar esse modelo a partir do DRC?

O erro de cabeçalho quase sempre está no mapeamento dos dados mestres, não no envio, então comece pelo cadastro do emitente e do destinatário no DRC. Seja como for, eu não validaria o XML só no portal, porque um teste de qualidade pode aceitar campos que a produção rejeita. Monte uma tabela de campos obrigatórios com o formato da Polônia, compare nota a nota com o XML gerado pelo SAP e registre cada rejeição com o código devolvido. Quando o log for genérico, o caminho mais rápido é reproduzir com uma nota simples, sem impostos, e acrescentar os campos um a um.