Como escrever um chamado de Protheus que não volta por falta de informação

“O Protheus não funciona” descreve a frustração de quem está parado, mas ainda não permite investigar. A pessoa que recebe o chamado precisa descobrir qual atividade falhou, em qual tela, com quais dados e qual resultado era esperado.

Você não precisa saber programar para escrever um chamado melhor. Precisa reconstruir o caminho que levou ao problema e mostrar o impacto no trabalho. Com isso, a primeira resposta do suporte pode avançar para a análise em vez de pedir as informações que faltaram.

Comece pelo trabalho que ficou parado

Explique o objetivo em uma frase: incluir um pedido, classificar uma pré-nota, emitir um relatório ou registrar um recebimento. O nome da rotina ajuda se você o conhece, mas o processo em linguagem comum já dá uma direção. Se algum termo não for familiar, o glossário do Protheus para quem não é da TI resolve boa parte do vocabulário.

Depois descreva o impacto. “A emissão do relatório de conferência não termina” é diferente de “nenhum pedido pode ser faturado”. Diga quantas pessoas ou documentos foram afetados e se existe alguma forma temporária de continuar o trabalho.

Evite marcar tudo como urgente sem explicar o motivo. Uma data de fechamento ou uma operação interrompida ajuda a equipe a avaliar a prioridade com mais precisão.

O suporte precisa comparar duas coisas: o que deveria acontecer e o que aconteceu. Se você só informa “deu erro”, parte importante dessa comparação fica implícita.

Quando houver uma mensagem, copie o texto completo ou envie uma captura legível. Uma palavra omitida pode diferenciar falta de cadastro, validação de negócio e erro técnico.

Descreva poucos passos, na ordem

Escreva o caminho que uma segunda pessoa poderia seguir para chegar ao mesmo ponto. Não é necessário documentar o dia inteiro. Comece na abertura da rotina e termine na ação que reproduz o problema.

Uma sequência curta pode ser: acessar o módulo, abrir a rotina, localizar o documento, escolher a operação e confirmar. Se um campo precisa de um valor específico para a falha aparecer, inclua esse detalhe pelo canal autorizado.

Se não conseguir reproduzir, diga isso. Informe a última ocorrência e as condições conhecidas. “Aconteceu uma vez” e “acontece em toda tentativa” orientam investigações diferentes.

Ambiente e horário mudam a investigação

Informe se estava em produção ou homologação, a empresa e filial selecionadas e o horário aproximado. Se uma data-base diferente foi usada, registre-a também.

Esses dados ajudam a localizar o contexto. Um pedido que existe em produção pode não estar numa cópia de homologação. O resultado de um relatório também pode mudar conforme período e perguntas de emissão.

Uma boa captura mostra a rotina, o estado da operação e a mensagem relevante. Se houver dados que não são necessários à investigação, oculte-os antes de compartilhar por um canal mais amplo. Preserve as informações essenciais no canal autorizado para o atendimento.

Para divergência de relatório, envie também os filtros usados. Dois totais diferentes sem suas datas e recortes não permitem concluir que existe erro — a orientação oficial da TOTVS para análise de estoque reforça justamente a comparação entre fontes com critérios equivalentes.

Uma gravação curta pode ajudar quando o problema depende da sequência de cliques. Ela precisa começar antes da ação que falha e terminar mostrando o resultado. Vídeos longos, sem objetivo indicado, aumentam o esforço de localizar a evidência.

Um modelo que pode ser copiado

Título: [rotina/processo] — [problema observado]

O que eu estava tentando fazer:

Resultado esperado:

O que aconteceu e mensagem exibida:

Passos para reproduzir:
1.
2.
3.

Ambiente, empresa e filial:
Data-base e horário aproximado:
Documento de exemplo, pelo canal autorizado:

Frequência: sempre / algumas vezes / uma ocorrência
Quem ou o que foi afetado:
Prazo ou impacto operacional:

Evidências anexadas e filtros utilizados:
O que já foi tentado e qual foi o resultado:

Não deixe o preenchimento virar uma barreira para comunicar um incidente. Se algo essencial estiver indisponível, informe a ausência e envie o que já sabe. O modelo organiza a investigação; não exige que o usuário resolva o problema antes de abrir o chamado.

Um exemplo de título e descrição

Título: “Documento de entrada — confirmação interrompida na classificação de pré-nota”.

Descrição: “Em homologação, filial de demonstração, abri a rotina de documento de entrada e selecionei a pré-nota TESTE-001. Ao confirmar, apareceu a mensagem da captura e a operação não foi concluída. Repeti uma vez com o mesmo resultado. Outro documento de demonstração concluiu normalmente. Preciso terminar a validação do treinamento; produção não foi testada.”

Esse texto não inventa uma causa. Ele informa um contraste útil, delimita o alcance observado e permite decidir o próximo teste. Também evita apresentar um problema de homologação como se toda a empresa estivesse parada. Se o assunto for recebimento, vale conferir antes a diferença entre pré-nota e documento de entrada — boa parte dos chamados dessa área nasce dessa confusão.

O que costuma atrasar a primeira resposta

Misturar vários problemas no mesmo chamado dificulta separar causas e soluções. Quando os sintomas forem independentes, descreva-os separadamente. Se parecem relacionados, explique por quê e mantenha uma sequência de evidências para cada um.

Também registre as tentativas feitas. Uma alteração de parâmetro, reinstalação ou repetição do processamento pode mudar o cenário. Sem esse histórico, a investigação pode partir de uma condição que já não existe.

Ao receber uma correção, repita o cenário original e compare com o resultado esperado. Responder “agora abriu” pode ser insuficiente se o problema era concluir e conferir o documento. O chamado fica mais forte quando a validação final responde à mesma pergunta que iniciou o atendimento.