Impedir o faturamento de cliente bloqueado no Protheus é um controle importante para empresas que querem reduzir riscos financeiros e evitar que pedidos já liberados sejam faturados depois que a situação do cliente mudou.
Imagine uma situação bastante comum: o comercial cria um pedido de venda para um cliente que, naquele momento, está com sua situação regular. O pedido segue normalmente pelo processo e fica disponível para faturamento.
Algumas semanas depois, porém, esse mesmo cliente começa a apresentar inadimplência ou algum outro risco identificado pelo financeiro. A equipe então realiza o bloqueio do cliente no Protheus.
O problema é que já existe um pedido de venda liberado.
Se nenhum novo controle for realizado antes do faturamento, um usuário pode acabar processando esse pedido sem perceber que o cliente foi bloqueado posteriormente.
Neste artigo, vamos mostrar uma alternativa para criar essa proteção no ERP Protheus, utilizando os pontos de entrada M410PVNF e M460MARK.
Por que validar novamente o cliente antes do faturamento?
O ponto principal desse cenário está no intervalo entre a criação do pedido e seu faturamento.
Vamos imaginar que um pedido seja criado hoje. O cliente está regular, o comercial realiza a venda e o pedido segue pelo fluxo normalmente.
Depois de 30 ou 40 dias, antes que esse pedido seja efetivamente faturado, o cliente passa a apresentar problemas financeiros. A equipe responsável identifica a situação e realiza seu bloqueio através do cadastro de clientes.
No exemplo deste artigo, estamos considerando o campo:
A1_MSBLQL
Esse campo está relacionado ao cadastro do cliente na tabela SA1 e será utilizado pelas validações apresentadas para identificar se o cliente está bloqueado.
A questão é que o pedido já existia antes dessa alteração.
Por isso, uma maneira de aumentar a segurança do processo é fazer com que o Protheus consulte novamente a situação atual do cliente antes de permitir determinadas etapas do faturamento.
Em vez de confiar apenas na condição existente quando o pedido foi criado ou liberado, passamos a ter uma validação mais próxima da operação que realmente representa o risco: o faturamento.
Como bloquear o faturamento de cliente bloqueado no Protheus
Para tratar o cenário apresentado, podemos trabalhar com duas validações.
A primeira utiliza o ponto de entrada M410PVNF. O objetivo é verificar a situação do cliente quando o usuário tentar seguir com o faturamento através das ações disponíveis no pedido de venda.
A segunda utiliza o M460MARK, criando outra proteção durante a marcação dos registros na preparação do documento de saída.
Com essas duas validações, conseguimos cobrir diferentes caminhos utilizados pelo usuário durante o processo.
Vamos começar pelo M410PVNF.
Utilizando o ponto de entrada M410PVNF
A primeira trava pode ser criada através do ponto de entrada M410PVNF.
A lógica é relativamente simples: antes de permitir que o processo continue, verificamos novamente se o cliente relacionado ao pedido está bloqueado.
Para isso, o código consulta o campo A1_MSBLQL do cadastro do cliente.
Caso seja identificado o bloqueio, o faturamento não continua e uma mensagem é apresentada ao usuário.
O código utilizado é:
User Function M410PVNF()
Local lContinua := .T.
Local aArea := GetArea()
Local aAreaSA1 := SA1->(GetArea())
Local cBlqCli := ""
//Busca se o cliente ta bloqueado
cBlqCli := Posicione("SA1",1, xFilial("SA1") + SC5->C5_CLIENTE + SC5->C5_LOJACLI, "A1_MSBLQL")
//Se cliente estiver bloqueado, barra o faturamento.
If cBlqCli == "1"
lContinua := .F.
ExibeHelp("Help", "Faturamento não permitido! Cliente Bloqueado!", "Verifique o cadastro do Cliente!")
EndIf
RestArea(aAreaSA1)
RestArea(aArea)
Return lContinua
Como funciona a validação do M410PVNF?
O código começa considerando que o processo poderá continuar normalmente:
Local lContinua := .T.
Em seguida, utiliza os dados do pedido de venda para localizar o respectivo cliente no cadastro SA1.
A consulta acontece através do Posicione, utilizando o código e a loja presentes no pedido:
SC5->C5_CLIENTE
e:
SC5->C5_LOJACLI
O retorno esperado está no campo A1_MSBLQL.
Quando o conteúdo encontrado é "1", a rotina entende que o cliente está bloqueado e altera o retorno:
lContinua := .F.
Nesse momento, também é exibida uma mensagem informando ao usuário:
Faturamento não permitido! Cliente Bloqueado!
Com isso, mesmo que o pedido tenha sido criado anteriormente, existe uma nova verificação da situação do cliente antes da continuidade do processo.
É uma proteção simples, mas que pode evitar um problema importante: faturar para um cliente cuja situação financeira mudou depois da criação do pedido.
Por que apenas uma trava pode não ser suficiente?
Quando trabalhamos com processos do TOTVS Protheus, é importante lembrar que uma mesma operação pode ser realizada através de diferentes rotinas e caminhos.
Por isso, proteger apenas um ponto específico nem sempre significa proteger todo o processo.
No cenário deste artigo, também precisamos considerar a preparação do documento de saída.
É justamente aqui que entra a segunda validação.
Bloqueando o cliente na preparação do documento de saída
Para complementar o controle, podemos utilizar o ponto de entrada M460MARK.
Nesse caso, a ideia é impedir que pedidos relacionados a clientes bloqueados sejam marcados para continuidade do processo na preparação do documento de saída.
O código é:
#INCLUDE 'TOTVS.CH'
#INCLUDE 'TOPCONN.CH'
User Function M460MARK()
Local aArea := GetArea()
Local aAreaC9 := SC9->(GetArea())
Local aAreaC5 := SC5->(GetArea())
Local lRet := .T.
Local cMarca := ParamIXB[1]
Local lInverte := ParamIXB[2]
Local cQuery := ""
Local cMsgBlq := ""
Pergunte("MT461A", .F.)
//Criando a consulta
cQuery += " SELECT " + CRLF
cQuery += " DISTINCT "
cQuery += " C9_CLIENTE, " + CRLF
cQuery += " C9_LOJA, A1_NOME " + CRLF
cQuery += " FROM "+RetSQLName("SC9")+" SC9 " + CRLF
cQuery += " INNER JOIN "+RetSQLName("SC5")+" SC5 ON (" + CRLF
cQuery += " SC5.D_E_L_E_T_='' " + CRLF
cQuery += " AND C5_FILIAL = C9_FILIAL " + CRLF
cQuery += " AND C5_NUM = C9_PEDIDO " + CRLF
cQuery += " ) " + CRLF
cQuery += " INNER JOIN "+RetSQLName("SA1")+" SA1 ON (" + CRLF
cQuery += " SA1.D_E_L_E_T_='' " + CRLF
cQuery += " AND A1_COD = C9_CLIENTE " + CRLF
cQuery += " AND A1_LOJA = C9_LOJA " + CRLF
cQuery += " AND A1_MSBLQL = '1' " + CRLF // 1 = Bloqueado.
cQuery += " ) " + CRLF
cQuery += " WHERE SC9.D_E_L_E_T_ = ' ' " + CRLF
cQuery += " AND C9_FILIAL='"+FWxFilial("SC9")+"' " + CRLF
cQuery += " AND C9_OK"+Iif(lInverte, "<>", "=")+ "'"+cMarca+"' " + CRLF
cQuery += " AND C9_CLIENTE >= '" + MV_PAR07 + "' AND C9_CLIENTE <= '" + MV_PAR08 + "' " + CRLF
cQuery += " AND C9_LOJA >= '" + MV_PAR09 + "' AND C9_LOJA <= '" + MV_PAR10 + "' " + CRLF
cQuery += " AND C9_DATALIB >= '" + dToS(MV_PAR11) + "' AND C9_DATALIB <= '" + dToS(MV_PAR12) + "' " + CRLF
cQuery += " AND C9_PEDIDO >= '" + MV_PAR05 + "' AND C9_PEDIDO <= '" + MV_PAR06 + "' " + CRLF
cQuery += " AND C9_BLEST = '' AND C9_BLCRED = ''" + CRLF
//Executando a Cláusula
TCQuery cQuery NEW ALIAS QRY_SC9
cMsgBlq := "Cliente(s) Bloqueado(s): " + CRLF + CRLF
While !QRY_SC9->(Eof())
lRet := .F.
cMsgBlq += AllTrim(QRY_SC9->C9_CLIENTE) + '-' + QRY_SC9->C9_LOJA + ": " + AllTrim(QRY_SC9->A1_NOME) + CRLF
QRY_SC9->(dbSkip())
EndDo
QRY_SC9->(DbCloseArea())
If !lRet
ExibeHelp("Help", cMsgBlq, "Verifique o cadastro dos clientes!")
Endif
RestArea(aAreaC5)
RestArea(aAreaC9)
RestArea(aArea)
//Restaurando a pergunta do botão Prep.Doc.
Pergunte("MT460A", .F.)
Return lRet
Entendendo o ponto de entrada M460MARK
Essa segunda implementação possui uma lógica um pouco mais completa.
A consulta relaciona informações das tabelas SC9, SC5 e SA1.
A SC9 é utilizada no contexto das liberações dos pedidos. A SC5 entra na consulta para relacionar os respectivos pedidos de venda, enquanto a SA1 permite verificar a situação atual do cadastro do cliente.
Um dos principais filtros utilizados pela consulta é:
A1_MSBLQL = '1'
Assim, somente clientes identificados como bloqueados entram nessa validação.
A consulta também considera informações utilizadas durante o processo, incluindo filial, cliente, loja, período de liberação e intervalo de pedidos.
Quando algum registro correspondente a um cliente bloqueado é encontrado, o retorno da função passa para .F..
Além de interromper a continuidade do processo, o código monta uma mensagem apresentando os clientes bloqueados identificados.
Isso torna o controle mais amigável para quem está utilizando o ERP, já que o usuário não recebe apenas um bloqueio genérico: ele consegue identificar quais clientes precisam ser verificados.
M410PVNF e M460MARK: por que utilizar os dois?
A combinação dos pontos de entrada M410PVNF e M460MARK cria uma proteção mais abrangente para o processo apresentado.
O primeiro atua na tentativa de faturamento através das ações relacionadas ao pedido de venda.
O segundo atua durante a marcação na preparação do documento de saída.
Na prática, estamos criando duas barreiras para uma mesma regra de negócio:
se o cliente está bloqueado, o faturamento não deve prosseguir.
Essa abordagem reduz a dependência da atenção do usuário.
Sem a validação, alguém precisaria perceber manualmente que o cliente teve sua situação alterada depois que o pedido foi criado.
Com a regra implementada, o próprio Protheus passa a impedir a continuidade do processo nos cenários tratados.
Como essa customização pode reduzir riscos no faturamento
O benefício mais evidente é evitar o faturamento indevido para clientes bloqueados.
Mas existe outro ponto importante.
Processos empresariais não são estáticos.
Entre o momento em que um pedido é criado e o momento em que ele é faturado, muita coisa pode mudar: situação financeira, limite de crédito, negociação comercial e até mesmo regras internas da empresa.
Por isso, algumas informações precisam ser validadas novamente nos momentos mais críticos do processo.
Nesse cenário, estamos utilizando a situação atual do cadastro para decidir se o faturamento poderá ou não continuar.
Isso ajuda a aproximar o comportamento do ERP da realidade operacional da empresa e diminui a necessidade de controles paralelos.
Cuidados antes de implementar os pontos de entrada
Antes de utilizar os códigos em ambiente de produção, é importante avaliar o cenário específico da empresa.
O Protheus permite inúmeras customizações e uma empresa pode possuir outras regras utilizando os mesmos processos ou até os mesmos pontos de entrada.
Por isso, a implementação deve passar por testes em ambiente de homologação.
É interessante validar cenários como clientes ativos, clientes bloqueados, pedidos já liberados, diferentes intervalos utilizados na preparação de documentos e demais situações existentes na operação.
Também é necessário considerar outras customizações que possam interferir no faturamento.
O objetivo não é simplesmente criar uma trava, mas garantir que ela respeite as regras comerciais e financeiras existentes na empresa.
Customizações no Protheus devem acompanhar as regras do negócio
Esse exemplo mostra bem como uma customização relativamente pequena pode ajudar a resolver um problema operacional importante.
O comercial continua trabalhando normalmente, o financeiro continua realizando seus controles e o ERP passa a atuar como uma camada adicional de segurança entre essas duas áreas.
Quando o cliente muda de situação, essa informação passa a ser considerada novamente antes do faturamento.
Esse conceito pode ser aplicado em vários outros processos do Protheus.
Existem situações em que determinadas validações precisam acontecer novamente antes da emissão de documentos, movimentações de estoque, liberações financeiras ou outras operações críticas.
O mais importante é entender onde está o risco e em qual momento do processo a regra deve ser aplicada.
Como evitar o faturamento de clientes bloqueados no Protheus?
Para o cenário apresentado, a solução utiliza dois pontos de entrada complementares.
O M410PVNF verifica a situação do cliente antes da continuidade do faturamento relacionado ao pedido de venda.
Já o M460MARK adiciona uma segunda validação durante a preparação do documento de saída.
Com isso, pedidos criados anteriormente não ficam dependentes apenas da situação que o cliente possuía no momento da venda.
A situação atual do cadastro passa a fazer parte da decisão.
É uma solução que pode ajudar empresas que utilizam o ERP TOTVS Protheus a fortalecer seus controles de crédito e faturamento e reduzir a possibilidade de operações realizadas por engano.
Sua empresa possui processos no Protheus que ainda dependem de conferência manual?
Muitas empresas utilizam o Protheus há anos e acabam acumulando processos que dependem de planilhas, conferências manuais ou conhecimento específico de determinados usuários.
O problema aparece quando essas regras começam a impactar produtividade, segurança ou escalabilidade da operação.
Na Geeker Company, trabalhamos com consultoria, desenvolvimento, integrações e customizações no TOTVS Protheus, buscando transformar essas necessidades em processos mais seguros e automatizados dentro do ERP.
Se existe alguma regra no seu processo comercial, financeiro ou de faturamento que ainda depende de conferência manual, fale com a equipe da Geeker. Podemos avaliar como levar esse controle para dentro do Protheus.
FAQ — Faturamento de clientes bloqueados no Protheus
É possível impedir o faturamento de um cliente bloqueado no Protheus?
No cenário apresentado neste artigo, sim. Foram utilizados pontos de entrada para verificar a situação atual do cliente e impedir a continuidade do processo quando o cadastro estiver bloqueado.
Qual campo identifica o bloqueio do cliente neste exemplo?
O código utiliza o campo A1_MSBLQL, presente no cadastro de clientes da tabela SA1.
Para que serve o M410PVNF neste exemplo?
O ponto de entrada M410PVNF é utilizado para verificar se o cliente está bloqueado antes de permitir a continuidade do faturamento pelo fluxo tratado no código.
O que o M460MARK faz?
No exemplo apresentado, o M460MARK verifica clientes durante a marcação dos registros na preparação do documento de saída. Caso sejam encontrados clientes bloqueados, o processo é interrompido.
Preciso utilizar os dois pontos de entrada?
Os dois códigos apresentados atuam em momentos diferentes do processo. A proposta de utilizar ambos é aumentar a cobertura da regra e evitar que outro caminho operacional permita o faturamento.
Posso utilizar esses códigos diretamente no ambiente de produção?
É recomendável primeiro validar a implementação em ambiente de homologação e verificar as regras e customizações existentes na empresa antes de levar qualquer alteração para produção.
