O que precisa estar pronto antes de configurar SAP ACR no SAP?

Na minha rotina de serviços, o acesso só de leitura para quem concilia já criou um gargalo, porque ninguém consegue corrigir o cadastro quando o erro aparece. Então, como já disse, a correção precisa de um responsável com permissão de escrita e registro da mudança. Discordo do Lucas nesse ponto: leitura para conciliar é bom, mas o ajuste precisa passar por um fluxo de aprovação, não por proibição total. Sem esse caminho, o cadastro volta a ser mexido às escondidas.

Se a equipe tiver disciplina para editar só no sistema, o modelo da Lívia funciona bem. Lívia, complemento o seu ponto: o relatório de conferência deve sair do próprio sistema, nunca digitado à mão, senão volta a ser um segundo registro. Bem, o óbvio: quem concilia precisa de acesso só de leitura ao cadastro, para não voltar a editar por fora.

A planilha não deveria ser o registro aprovado, e discordo da Débora nesse ponto. Agora, já adianto: quando a planilha manda, alguém sempre edita o sistema por fora e ninguém sabe qual versão é a certa. Na siderurgia, isso virou auditoria com conjuntos de números diferentes, e foi caro corrigir. Prefiro que o sistema seja o registro e a planilha seja só relatório de conferência.

Eu faria diferente. Bem, pelo que testei, quando o volume de unidades é pequeno, vale montar a correspondência direto no sistema, com a planilha só como controle. Quando há muitas unidades e vários ERPs de origem, a planilha pode virar o registro oficial, mas precisa de dono. Na nossa operação de energia, a equipe usou a planilha como registro aprovado e o sistema apenas espelhou. Esse caminho custa mais tempo no começo, mas evita discussão de versão no fechamento.

Daniela, a planilha funciona até a primeira carga, depois vira gargalo. Eu complemento com um ponto que ninguém tocou: o código antigo costuma trazer espaço à direita e zero à esquerda, e o log mostra a diferença como se fosse outra unidade. Já vi isso num log de erro com cara de problema grave, e era só espaço. Meu palpite, viu, é normalizar tudo antes do mapeamento, senão o ACR rejeita por motivo bobo.

Concordo em parte com o Vinícius, o mapeamento antes da configuração é o caminho. Discordo quando ele sugere resolver o código antigo na carga, porque isso empurra o problema para o fechamento. Bem, por experiência, no varejo a gente só limpou o cadastro depois que o log mostrou tipos diferentes de unidade com o mesmo nome. Então sugiro um corte: primeiro a tabela de correspondência aprovada, depois a carga.

E o cadastro? Paula, você falou do log, mas na nossa distribuidora o ERP antigo guarda a unidade com outro código, e isso já travou a carga de teste. Agora, um palpite: pelo que vi, o ACR depende do mapeamento, então o mapeamento de códigos precisa vir antes da configuração. Como você faria esse mapeamento quando o código antigo não bate com o novo?

Na minha rotina de consultoria na mineração, o caso mais comum é o cadastro de unidade que existe no papel e não no sistema. Complemento a Vanessa com isso: o log de erro da configuração costuma apontar essa lacuna antes de qualquer outra. A verdade é que, pois é, a gente perde tempo procurando o problema no ACR quando a origem está no cadastro. Por isso eu checaria essa base primeiro, antes de qualquer teste de configuração.

Quando a estrutura organizacional e os cadastros fiscais estão fechados, o ACR pode ser configurado sem retrabalho. Que eu saiba, o ponto que mais atrasa é definir quem aprova cada cadastro, porque ninguém quer assinar o que não entende. Antes de abrir o projeto, eu deixaria pronto o plano de contas, a lista de centros de custo e a matriz de responsabilidades. Quando isso estiver certo, a configuração vira execução. Se algo faltar, o consultor para e pede de novo, e o cronograma escorrega.