Como homologar a emissão do SAP DRC e a apuração do GUEPARDO Tax no mesmo ciclo de testes?

Só pra alinhar, né, discordo um pouco do ciclo único. Quando um cenário falha no fim da cadeia, fica difícil saber se foi a emissão ou a apuração.

Prefiro ciclo único com pontos de parada: depois da nota, depois da carga na apuração, depois do arquivo. Em cada parada, quem fecha o ponto registra a evidência antes do próximo começar. O material que temos também não afirma como o produto recebe os dados do SAP DRC, então esse ponto de carga é o que mais merece olho.

Como bem lembrou a Carolina, ó, o ponto de carga merece atenção. E tem mais uma coisa que o ciclo de teste não pega sozinho: a regressão contra período já fechado.

Segundo as notas de projeto, o primeiro fechamento real é o teste que conta e a regressão compara com evidência de períodos fechados. Escolha um mês já entregue, rode a massa dele e compare os totais com o que foi declarado. Quem valida é o cliente, não a consultoria.

Use uma massa de documentos compartilhada e um cenário que atravessa os dois lados. Veja, a prova é o documento chegar ao arquivo final com o mesmo valor com que saiu da nota.

Segundo as notas de projeto que usamos, os testes se dividem em técnico, integrado, regressão, contábil, homologação do cliente e primeiro fechamento. O ciclo conjunto é o integrado. Monte 10 cenários, cada um com nota, apuração e linha da obrigação, e um dono para cada cenário.

Agora, em todo caso, aqui a gente fez de outro jeito: dois ciclos curtos com um ponto de encontro. Primeiro a emissão fecha o lote de notas e congela a lista. Depois o fiscal apura exatamente aquela lista.

O ponto de encontro é uma planilha com a contagem e o valor total por tipo de documento nos dois lados. Se a diferença for zero, segue. Se não, o cenário volta com o nome do dono. Evita o ciclo único virar fila de culpa.