Sap edocument xml generation

Na minha rotina de farma, o caso mais comum é o xml sair certo e mesmo assim faltar uma referência ao documento de origem. Helena, complementando o que você disse sobre reprocessar, bem, na real, o reprocessamento só funciona se o documento de origem estiver fechado com a mesma chave. Eu checo isso antes de qualquer reenvio. Se a chave não bate, reprocessar só repete o erro. Deixaria no checklist uma linha para confirmar a chave de referência, o status e a data de geração, nessa ordem, antes de disparar a rotina.

Confirmar o xml campo a campo antes do envio é o que segura o fechamento. André Martins, complementando sua ideia, agora, o bom é que, na distribuidora em que atuei, a gente gerava um relatório de checagem no mesmo dia e comparava com o documento salvo. Com isso, a diferença aparecia antes da escrituração. Esse relatório também serve para o contador que não conhece o xml, porque mostra o valor do documento e o valor do arquivo lado a lado.

Quando a equipe não tem tempo para mexer no customizing, a saída que adotamos foi outra. Se o xml já foi gerado e está quebrado, a gente não corrige o arquivo à mão: reprocessa o documento pela transação de envio, depois de alinhar o cadastro. Na prática, e aí, digamos assim, o caminho manual fica para exceção, com a chefia ciente. Esse caminho vale quando o volume é baixo; quando o volume cresce, o ajuste de modelo compensa mais. Em mineração, com key user de pouca experiência, o reprocessamento foi o que mais evitou erro.

Discordo, com todo respeito. Eu não trataria o log como prova final, porque a sacada é que o xml pode sair bem formado e ainda assim trazer conteúdo errado, já que a validação de regra é outra etapa. Na minha experiência com energia, aprendemos a conferir o xml contra o leiaute e depois contra os campos do documento, com print de tela ao lado. Só assim a gente sabe se o edocument está certo para quem recebe. Mexer no customizing sem esse teste só desloca o problema.

O risco que já vi foi exatamente esse, e com pressa de fechamento ele vira problema grande. Matheus, complementando o que você falou, eu acrescentaria a checagem da data de emissão contra o período aberto: o edocument gera, o xml sai, mas a nota fica travada no status e o print de tela mostra só a mensagem genérica. Quando isso acontece, e aí, o problema é que a equipe olha o xml certo e não percebe que o envio nunca aconteceu. Por isso eu acompanharia o status e o protocolo de retorno junto com o arquivo, não só o conteúdo.

Concordo em parte: o xml só sai completo quando o edocument passa pela validação antes da geração. No meu caso, bem, pelo meu histórico, o erro quase nunca está no modelo, e sim na ordem dos passos. Em migrações de outro ERP para SAP eu vi três casos que se repetem: o parceiro sem dados de endereço, o status do documento que não foi liberado e o mapeamento de campos customizados que não chegou ao leiaute. Eu começaria pelo log da geração, porque ele mostra em qual etapa o xml parou. Só depois mexeria no customizing.