Sap drc for uae

O resultado que importa é este: a filial só passou no teste quando o pedido já saía com o tipo de documento certo. Fábio Rodrigues, completo o que você disse sobre a integração: que eu saiba, pois é, o intermediário é quem ajusta o formato, e foi isso que nos salvou. Sem essa etapa, a validação inicial parece correta e só falha no envio.

Se a equipe espera o intermediário resolver tudo, bem, a conta é cara. Discordo da Talita Silva nesse ponto, porque ajustar o formato no meio do caminho esconde erro de cadastro e de imposto que aparece depois, na auditoria. Prefiro validar o dado mestre antes, mesmo que o teste demore mais. Assim o intermediário fica para o que ele faz de fato, que é transporte, e não correção de dados.

O risco que já vi é a equipe corrigir o cadastro e esquecer que a filial tem tratamento de imposto próprio. Discordo do João Ribeiro em começar pelos clientes: no meu projeto gastamos boa parte do tempo porque o erro era de código de imposto, e o cadastro estava bom. Bem, a saída é olhar o log de erros antes de mexer nos dados mestres e pedir a tela de rejeição do envio. Assim a gente não corrige o que não estava quebrado.

Roberta Gomes, eu completo pelo lado do desenvolvimento. Lá onde trabalho, pois é, a dor maior aparece na formatação do arquivo, que só se descobre quando o ambiente de testes recusa o envio. Vale pedir para a equipe de integração validar o formato antes de cadastrar tudo. Assim o log que você falou mostra a causa certa cedo, e não depois do fechamento.

Concordo que imposto dá trabalho, mas o começo é o cadastro de clientes, Renato, e não o código de imposto. No nosso caso, o que travou foi o cadastro sem os campos que o reporte pede. Agora, até onde sei, a correção não vem do pacote padrão: é completar os dados mestres antes de ligar o envio. Eu começaria pela lista de clientes da filial e só depois pelos códigos.