Que perfis de TI e fiscal devem revisar juntos o fluxo MM, SD e FI do GUEPARDO Tax?

Se a dúvida for repetida, desculpem, mas discordo de pensar só em perfis. E aí, vale registrar: o que quebra a integração costuma ser extensão própria que ninguém sabe que existe. Inclua na revisão um inventário das extensões Z em torno do fiscal, com dono e o que cada uma assume do produto.

Regra de decisão das notas de projeto: parametrização antes de desenvolvimento, e ponto de extensão previsto antes de alterar objeto padrão. Sem isso a revisão aprova o desenho e a atualização seguinte quebra.

Quero saber uma coisa antes de responder: a revisão é de regra ou de integração? Aqui na empresa separamos assim, em lista:

1. Dono fiscal da regra, para validar o imposto.
2. Key user de MM, de SD e de FI, cada um do seu processo.
3. ABAP e Basis, para enhancements e transportes.
4. Contabilidade, para conciliar com o razão.

O documento que resulta é um desenho de ponta a ponta, do documento de origem à guia e ao lançamento, com dono de cada passo. Por referência, o teste integrado fica com o cliente, com apoio da consultoria.

O que temos aqui: desenhar por documento real. Então, um adendo: peça um caso de cada fluxo e siga o documento. Na documentação do e-Invoicing, os processos de compra sugeridos no inbound são NF-e (pedido, MIGO, MIRO), NFS-e (pedido, MIRO) e CT-e (pedido da NF-e, MIRO). Esses caminhos dão o esqueleto do lado de MM. Do lado de SD e FI, o desenho precisa do mesmo tipo de caminho, e o produto, segundo a NTT, lê FI, CO, MM e SD direto da base SAP.