Como testar fiscal no RISE e GROW with SAP antes de ir para produção?

O risco que eu já vi foi o time testar tudo junto e não conseguir isolar qual mudança quebrou o quê. Então, e aí, a verdade é que a gente passou a fazer teste empresa a empresa, ligando uma empresa por vez no ambiente novo e deixando as outras no legado. Funciona bem quando o grupo tem empresas independentes na apuração, porque o erro fica contido. Não vale quando as empresas dividem processos de intercompany, porque o teste de uma depende da outra e o isolamento não existe. Nesse caso eu voltaria para o mapa de cenários.

Tatiana, discordo com respeito de um ponto. O teste empresa a empresa parece isolar, mas o cadastro de parceiros e as tabelas de condição fiscal costumam ser compartilhados entre os códigos de empresa. Então, pelo que testei num cenário parecido, uma mudança de regra feita para uma empresa acaba valendo para as outras no mesmo momento, e o isolamento que você descreveu não acontece. Eu separaria o teste pela configuração compartilhada antes de ligar qualquer empresa, senão a contenção fica só no papel e a equipe aprende tarde.

Uma dúvida curta: vocês comparam o resultado com o sistema antigo ou só com o relatório do próprio contador? Aqui a gente adotou uma execução paralela, rodando a apuração no ambiente novo e no legado para o mesmo período, e conferindo a diferença por documento. Olhando o número, pois é, a diferença aparece logo no primeiro lote, e é mais barato corrigir ali do que depois do fechamento. Esse caminho vale quando o sistema antigo ainda existe e os dados estão limpos. Quando não existe mais legado, ou quando a operação mudou muito, eu prefiro o roteiro de cenários da resposta anterior, porque a comparação não tem com o que comparar.

Na nossa rotina de siderurgia, a gente testa fiscal no RISE com um cenário de fechamento completo, e não com notas soltas. Pelo meu histórico, ó, o que salvou o último trimestre foi montar um mapa com cada tipo de operação que a empresa roda de verdade, como remessa, devolução e transferência, e validar isso no sistema de teste antes do fechamento. Quando o roteiro é só um exemplo de nota, o problema aparece na semana do fechamento, que é a pior hora possível. Então a primeira coisa é mapear as operações reais, depois separar o que é configuração do que é customização, e só então validar a apuração com o contador olhando o resultado.