Campos reservados: log de inclusão e alteração, bloqueio e imagem

Um campo comum você desenha: tipo, tamanho, título, validação. Um campo reservado já vem desenhado: o nome é reservado pelo sistema e a definição chega pronta. Por isso o B1_MSBLQL do cadastro de produtos e o A1_MSBLQL do cadastro de clientes têm o mesmo tipo, tamanho, inicializador e validação.

Como o dicionário padrão define cada um

No cadastro de produtos (SB1), os quatro estão assim:

Para ver quais tabelas do seu ambiente têm esses campos:

SELECT X3_ARQUIVO, X3_CAMPO, X3_TIPO, X3_TAMANHO, X3_TITULO,
       X3_VISUAL, X3_BROWSE, X3_CONTEXT, X3_NIVEL, X3_CBOX, X3_RELACAO
  FROM SX3010
 WHERE (X3_CAMPO LIKE '%USERLGI' OR X3_CAMPO LIKE '%USERLGA'
     OR X3_CAMPO LIKE '%USERGI'  OR X3_CAMPO LIKE '%USERGA'
     OR X3_CAMPO LIKE '%MSBLQL'  OR X3_CAMPO LIKE '%BITMAP')
   AND D_E_L_E_T_ = ' '
 ORDER BY X3_ARQUIVO, X3_CAMPO

O sufixo 010 é o da empresa; no seu ambiente pode ser outro.

USERLGI ou USERGI: o limite de dez caracteres

Nome de campo no Protheus tem no máximo dez caracteres. Em tabela de alias iniciado por S, o prefixo do campo tem duas letras (B1_, A1_), e B1_USERLGI cabe. Em tabela de alias com três letras, o prefixo já ocupa quatro posições com o sublinhado, e CT2_USERLGI teria onze. Por isso o dicionário padrão usa a forma curta nessas tabelas: CT2_USERGI, CT2_USERGA, ACY_USERGI, com o mesmo tipo (C) e tamanho (17) da forma longa.

A tabela customizada da série, a ZA1, tem alias de três letras. Os campos reservados dela ficam assim:

MSBLQL e BITMAP têm seis letras e cabem nos dois formatos.

Guardam quem fez e quando: o usuário e a data da inclusão (_USERLGI ou _USERGI) e da última alteração (_USERLGA ou _USERGA). São campos reais — existem na tabela física. No SB1 e no SA1, o dicionário padrão os deixa só para visualização (X3_VISUAL = V) e fora do browse; isso não é regra de todas as tabelas — na CT2, por exemplo, o log está com X3_VISUAL = A. Confira na SQL acima como estão na tabela que interessa.

O conteúdo não é texto legível. Um SELECT direto na coluna devolve caracteres codificados, não um nome e uma data. Para ler, a TOTVS documenta a função FWLeUserlg: o primeiro parâmetro é o campo; o segundo, o tipo — 1 devolve o nome do usuário, 2 devolve a data.

// Com a ZA1 posicionada no registro que interessa
Local cUsuInc := FWLeUserlg("ZA1->ZA1_USERGI", 1)   // quem incluiu
Local cDatInc := FWLeUserlg("ZA1->ZA1_USERGI", 2)   // quando incluiu
Local cUsuAlt := FWLeUserlg("ZA1->ZA1_USERGA", 1)   // quem alterou por último

Log de alteração guarda só a última alteração. Para histórico campo a campo, o assunto é outro: Log de registros.

Um campo de um caractere, em combo: 1 bloqueia, 2 libera. O inicializador "2" faz todo registro novo nascer liberado. No padrão, a descrição do combo varia conforme a tabela: 1=Sim;2=Não no SB1 (título “Blq. de Tela”), 1=Inativo;2=Ativo no SA1 (título “Status”) — o valor gravado é o mesmo.

O que a documentação da TOTVS diz sobre o comportamento:

• O campo existe para informar visualmente que o registro foi bloqueado. Como isso aparece na tela depende da rotina.
• Como é campo reservado, cada módulo decide o que tratar. No Faturamento, o bloqueio impede escolher o registro em lançamentos novos — por exemplo, um cliente, vendedor, transportadora ou produto bloqueado num pedido de venda novo. O que já foi gerado para aquele registro continua valendo e pode ser manipulado normalmente — um pedido que já tem o cliente pode ser faturado.
• A validação acontece em tela, pela validação do campo que aponta para o cadastro (X3_VALID com ExistCpo()). Rotinas de processamento que usam o cadastro não fazem essa validação.
• Só são tratadas tabelas de cadastro que sejam tabelas pai — não tabelas filhas nem de movimento.
• Bloquear produto tem efeito além da venda. A mesma página do Faturamento avisa que o B1_MSBLQL impede a seleção do produto em pedidos novos, mas impede também o processamento da Ordem de Produção, para quem usa. Antes de bloquear um produto para parar de vendê-lo, confira se ele ainda é produzido.

Existe também o _MSBLQD, de bloqueio por data. A documentação registra que alguns módulos (Estoque/Custos, Compras) não tratam o _MSBLQD; confira no seu módulo antes de contar com ele.

Na ZA1, o ZA1_MSBLQL serve para tirar de uso um motorista desligado sem apagar o histórico dele. Não conte com a validação de existência para barrar o bloqueado no pedido: a ExistCpo confere se o código existe na tabela, e motorista bloqueado continua existindo. A documentação dela não diz que olha o _MSBLQL, e há rotinas do padrão que testam o bloqueio numa condição à parte, depois da ExistCpo. Se a empresa quiser recusar motorista bloqueado no C5_XMOTOR, a validação do campo precisa ler o ZA1_MSBLQL, por exemplo:

Vazio() .Or. (ExistCpo("ZA1", M->C5_XMOTOR, 1) .And. ;
    Posicione("ZA1", 1, xFilial("ZA1") + M->C5_XMOTOR, "ZA1_MSBLQL") <> "1")

Para listar os registros bloqueados:

SELECT B1_COD, B1_DESC, B1_MSBLQL
  FROM SB1010
 WHERE B1_MSBLQL = '1'
   AND D_E_L_E_T_ = ' '

Imagem (BITMAP)

O campo de imagem é um caractere curto, com tamanho que varia por tabela no dicionário padrão; no B1_BITMAP são 20 posições. Vinte caracteres não guardam uma foto: guardam uma referência a ela. Como as imagens entram no Protheus está em Repositório de imagens.

No SB1, o campo fica na pasta 5 (Atendimento) e fora do browse — é o tipo de informação que se vê abrindo o registro, não na lista.

Os outros campos da ZA1, os comuns, estão em Os cinco tipos de campo do Protheus.