M410STTS como identificar a operação do pedido de venda

O nome M410STTS sugere um evento de mudança de status. Antes de construir uma integração em cima dele, vale olhar a informação que o padrão realmente transmite: os pontos encontrados no MATA410 passam números que identificam operações. Isso é diferente de receber uma descrição completa da mudança realizada no pedido.

O primeiro dado útil está no quarto argumento

Na inclusão, o fonte contém esta chamada:

ExecBlock("M410STTS", .F., .F.,{3})	// 3- Identificar a operação da inclusão

O array {3} é o conteúdo enviado ao ponto de entrada nessa chamada. A leitura de PARAMIXB[1], depois das verificações de existência, tipo e tamanho, permite reconhecer esse caminho. Não presuma que há um segundo elemento com o pedido anterior ou um terceiro com os itens modificados: eles não aparecem no argumento examinado.

A chamada vive dentro de A410Inclui(), depois do trecho que executa MT410INC. É uma observação do fluxo do MATA410. A ordem precisa ser conferida de novo a cada atualização de release, porque o comportamento do padrão muda entre versões.

A última linha merece atenção: ela vem de uma função com um papel diferente das demais. A410ProcDv() é a rotina de interface do pedido de vendas com o fluxo de devolução. O cabeçalho dela documenta dois modos — baseado em nota fiscal de entrada ou cópia de um pedido de venda normal —, e o ExecBlock("M410STTS",…,{7}) dispara nos dois, sem distinção: não há guarda de lFornece ao redor da chamada.

A coluna do ExecTemplate também importa — é ela que explica o aviso abaixo: inclusão e cópia disparam só o ExecBlock, alteração e exclusão disparam os dois mecanismos em sequência, e devolução, de novo, só o ExecBlock. A tabela reúne ocorrências localizadas nesses caminhos do MATA410, não uma promessa de que qualquer rotina que mexa em pedido executará todos esses eventos. Um processo automático, um módulo integrado e uma tela interativa podem percorrer caminhos diferentes.

Nas chamadas acima, o retorno de ExecBlock não participa de uma condição nem é atribuído a uma variável. Assim, devolver .F. do M410STTS não faz essas chamadas desfazerem a operação.

Na alteração, dentro de A410Altera(), a ordem no fonte é: a gravação fecha o Begin/End Transaction primeiro, o MT410ALT dispara depois disso, e o M410STTS só executa depois do MT410ALT — com o pedido já gravado e a transação fechada. Isso ajuda a explicar por que uma regra que precisa impedir a alteração deve ser procurada no ponto de validação apropriado — o MT410TOK ou o MTA410. Não estenda essa posição transacional automaticamente aos outros caminhos sem ler o contexto de cada um.

Uma necessidade de negócio como “não permitir alterar o pedido depois da aprovação” exige que o bloqueio aconteça antes da confirmação definitiva. Já “registrar que a operação passou por determinado caminho” tem outra natureza. Definir isso antes de escolher o PE evita uma customização que executa corretamente e resolve o problema errado.

Operação não é diferença entre versões

Receber o código 4 informa qual caminho foi acionado. Não informa quais campos mudaram, o valor antigo, a intenção do usuário nem se a mudança interessa à sua integração.

Imagine que um sistema externo precisa ser avisado somente quando a condição de pagamento mudar. O código da operação é um filtro inicial, mas ainda falta comparar um estado anterior confiável com o estado relevante após o processamento. Essa comparação precisa de desenho próprio. Uma leitura feita tarde demais pode encontrar apenas o valor novo.

Também não é prudente assumir que todas as áreas de trabalho estão posicionadas da mesma forma na inclusão e na exclusão. Antes de acessar um alias ou variável privada, documente o que foi observado naquele caminho e proteja os acessos que podem não existir. É o mesmo cuidado que PARAMIXB exige.

Comece com instrumentação temporária que registre somente a identificação do teste e o código recebido. Execute uma operação de cada vez sobre pedidos de demonstração. Anote se o usuário confirmou ou cancelou, qual tela iniciou o processo e quantas chamadas ocorreram.

Depois acrescente a identificação do pedido somente quando o posicionamento necessário tiver sido confirmado. Isso evita que o próprio log que deveria ajudar no diagnóstico provoque erro por tentar ler uma área indisponível.

Se houver comunicação externa

Uma chamada ao PE não garante que uma API externa receberá a mensagem. Falhas de rede, repetição de operações e reprocessamentos precisam ser tratados no desenho da integração. Defina uma identificação do evento e como reconhecer duplicatas; não use apenas o código da operação como identificador único.

Uma fila pode ajudar a desacoplar o processamento, mas sua gravação, transação e retomada também precisam ser projetadas. “Colocar em fila” não resolve sozinho a consistência entre a operação de origem e o envio posterior.

O uso mais sólido do M410STTS começa com uma frase precisa: “quero observar esta operação, neste caminho, com estes dados comprovadamente disponíveis”. A partir daí, a escolha entre log, auditoria e integração fica muito mais clara.

Para o mecanismo geral, veja Ponto de entrada no Protheus: como o padrão te chama.