Sap drc golden tax

O risco que eu já vi foi o relatório diário virar uma lista que ninguém abre, veja, na real, isso acontece em qualquer equipe com muita rotina. Discordo da Raquel na parte de só usar tela simples para equipes pequenas, porque o problema aparece justamente quando o time cresce e ninguém sabe quem olhou. Na siderurgia, a gente resolveu com um responsável por turno e um fechamento com assinatura, o que é mais chato, mas funciona. Prefiro esse controle formal a confiar na memória de alguém.

Concordo em parte com a Úrsula, o relatório diário é bom para a rotina. Discordo quando o volume é baixo, porque uma tela simples com dono resolve sem nenhuma regra extra. Só pra alinhar, eu usaria o alerta apenas para os tipos de retorno que travam o faturamento, e o relatório para o resto. Esse caminho vale quando o time de e-commerce tem muitos pedidos e pouca gente para olhar. Para equipes pequenas, a tela com responsável e data costuma bastar.

Dúvida curta: o alerta automático não vira mais ruído do que ajuda? E aí, o teste é quanto tempo leva para alguém ver a mensagem. Discordo da Sandra no ponto do alerta a cada silêncio, porque no processo de vocês o retorno demora e isso geraria aviso o tempo todo. Prefiro um relatório diário com os pedidos sem resposta, revisado por um responsável, do que um alarme que todo mundo ignora. Assim a equipe decide o que escalar, sem perder tempo com falso positivo.

Na minha rotina de controladoria, o caso concreto é o pedido que volta sem status final e fica parado por dias. Então, a título de exemplo, criamos uma tela de acompanhamento com data de entrada e responsável, e a Débora tem razão em exigir dono. Eu complementaria com um alerta automático para quando o retorno não chegar, porque o silêncio é o pior sinal. Assim o time vê o problema antes do fechamento e não depois.

O resultado que importa é o pedido sair da fila, e não em qual tela ele aparece. Discordo do Paulo Teixeira nesse ponto, porque tratar tudo como evento pode esconder o erro. E aí, batendo o olho, a fila cresce e ninguém sabe quem é o dono da decisão. Na mineração em que trabalhei, a regra era ter um responsável por status, com prazo curto para resposta e rastreio do que foi decidido. Quem trata o retorno precisa de um dono, não só de um mapeamento.

Trate o retorno como evento separado. Não é erro de documento, é uma resposta que pede decisão, e isso muda quem precisa agir. No meu projeto, pois é, a gente criou uma fila de status com a ação esperada para cada resposta, e o pedido só volta a ser processado depois da decisão. Antes de reenviar, eu conferiria se o status recebido já foi mapeado no SAP, porque o reenvio sem mapeamento só repete o problema. A regra de tratamento de erro ficou no próprio processo de emissão, com um registro de log que mostra o que foi recebido. Isso dá trabalho no começo, mas evita pedido parado sem dono.