VL_CREDITOACUM - Valor padrão de limite de crédito acumulado por pessoa

Tela: MFA001 - Parâmetros de Faturamento Localização: Parâmetros → Faturamento → Opção 2 (pagFatOp2 em UMFA001.dfm:3656, GroupBox4 = 'Parâmetros Comum a Notas Fiscais / Pedido') → campo Crédito Acumulado (label Label41 em UMFA001.dfm:3728-3742, posicionado em Left=9, Top=158). Tabela: PARMFATUR.VL_CREDITOACUM Tipo: Numérico monetário em R$ — DOM_NUMERIC15_2 no DDL (docs/schema/tables/PARMFATUR.sql:126); TFMTBCDField com Precision=18, Size=2 e DisplayFormat='#,0.00' no client (UdmMFA001.dfm:1301-1307). TDBEdit edtVL_CREDITOACUM em UMFA001.dfm:4244-4260 (sem máscara, TabOrder=12). Valor padrão: NULL — o AfterInsert de tabPARMFATUR em UdmMFA001.pas:434-605 não atribui default para este campo (o bloco de inicialização termina em UdmMFA001.pas:605 sem tocar em VL_CREDITOACUM). Em base recém-criada o parâmetro nasce vazio. Validação (MFA001): não há OnValidate em tabPARMFATURVL_CREDITOACUM (confirmado em UdmMFA001.pas:167 — só existe a declaração do field, sem handler). Qualquer valor numérico até 15 dígitos com 2 decimais é aceito (inclusive 0 e negativos, pois DOM_NUMERIC15_2 não impõe check de positividade). A única tela que impõe >= 0 é a TFA063 (tabCREDITOVL_CREDITOACUMValidate em UdmTFA063.pas:110-113).

O que o parâmetro faz

PARMFATUR.VL_CREDITOACUM é o template/default do limite de crédito acumulado (em R$) — o valor máximo da soma das duplicatas pendentes de um cliente — que o sistema copia para o cadastro de crédito (CREDITO) de cada pessoa na primeira vez em que ela é criada.

A regra de bloqueio em tempo real (no fechamento do pedido/NF/OS) não consulta PARMFATUR.VL_CREDITOACUM — ela consulta CREDITO.VL_CREDITOACUM (por cliente) via VIEW_CREDITOPESSOA. O parâmetro da MFA001 atua apenas como semente nos seguintes pontos:

TRGAI_PESSOA (trigger AFTER INSERT em PESSOA): ao criar uma pessoa nova, o trigger lê PARMFATUR.VL_CREDITOACUM da empresa logada e insere o valor em CREDITO.VL_CREDITOACUM (Scripts/TRGAI_PESSOA.sql:16-47). Se TP_LIMITECREDITO = 'S' (global), replica para todas as empresas com parâmetro global; caso contrário, insere só na empresa corrente.
CREDITOPERIODICO_AI0 e CREDITOPERIODICOGRUPO_AI0 (triggers em CREDITOPERIODICO / CREDITOPERIODICOGRUPO): quando a TFA002 (Análise de Crédito) cadastra um registro de período com DT_REGISTRO = '01.01.2000 00:00:00' e o limite é Global, os triggers propagam o valor para as demais empresas, lendo PARMFATUR.VL_CREDITOACUM (Scripts/CREDITOPERIODICO_AI0.sql:17-40, Scripts/CREDITOPERIODICOGRUPO_AI0.sql:17-40).

Diferença crucial em relação a VL_CREDITO:

VL_CREDITO = teto do valor de um único documento (um pedido/NF isolado).
VL_CREDITOACUM = teto da soma de duplicatas em aberto (saldo pendente acumulado do cliente).

O campo é avaliado em VERIFICA_CREDITO / VALIDA_MODELOBLOQUEIOVLLIMITE apenas quando PESSOA.ST_BLOQUEIO estiver em ('T','A','O','B','F','G') — modos que habilitam o controle por valor acumulado.

Telas impactadas

Módulo	Código	Papel
Parâmetros de Faturamento	MFA001	Produtora — cadastra/edita o valor no campo `edtVL_CREDITOACUM` (`UMFA001.dfm:4244-4260`), Opção 2
Análise de Crédito	TFA002	Produtora / editora de `CREDITO.VL_CREDITOACUM` e `CREDITOPERIODICO.VL_CREDITOACUM` — tela principal de manutenção do valor por cliente; monta INSERTs/UPDATEs em `CREDITO` com `VL_CREDITOACUM` (`UTFA002.pas:721-728, 791-798, 902-917, 945-960`)
Crédito Periódico	TFA063	Produtora — edita `CREDITO.VL_CREDITOACUM` com filtro por faixa (`VL_ACUMULADOINI..VL_ACUMULADOFIM`) e validação `>= 0` (`UdmTFA063.pas:110-113, 156`; `UTFA063.pas:287-322`)
Crédito do Cliente	CFC004	Consumidora / editora — exibe/edita `CREDITO.VL_CREDITOACUM` por cliente; o valor inicial veio do `TRGAI_PESSOA` que copiou de `PARMFATUR.VL_CREDITOACUM` (`UdmCFC004.dfm:785-788, 870, 883`; `UdmCFC004.pas:48`)
Análise de Crédito (Sinônimo/Alternativa)	TFA044	Possui label `lblVL_CREDITOACUM` (`UTFA044.dfm:200`)
Tela de Relacionamento de Pedido	MPD034	Exibe o limite acumulado do cliente (`UMPD034.dfm:2522-2531` — `edtVL_CREDITOACUM`) e calcula disponível acumulado = `CR.VL_CREDITOACUM - (VL_DUPAVENC + VL_DUPVENC)` (`UdmMPD034.dfm:1094-1099`)
Cotação de Peça	MCO008	Sobrescreve o campo virtual `VL_CREDITOACUM` com `VL_ACUMULADOMEN` de LIMITECREDITO do cliente (`UdmMCO008.pas:282-295`)
Cadastro de Pessoa	TPO001	Gatilho — o `INSERT INTO PESSOA` dispara `TRGAI_PESSOA`, que aplica `PARMFATUR.VL_CREDITOACUM` como default no novo registro de `CREDITO`
Relatório Análise de Crédito	TFA001	Relatório — lista `C.VL_CREDITOACUM` por cliente (`URelTFA001.pas:1386, 1399`)
Relatório Movimento de Contas	RFC022	Relatório — lista `C.VL_CREDITOACUM` junto com parcelas em aberto (`URFC022.pas:2754`)
Relatório de Inadimplência Analítico	RFC030	Relatório que consome `VIEW_RFC030ANALITICO.O_VL_CREDITOACUM` (`UdmRFC030.dfm:187, 210, 275-277`; `UdmRFC030.pas:45`)

Consumidores finais de CREDITO.VL_CREDITOACUM (não de PARMFATUR.VL_CREDITOACUM, mas que dependem do valor semeado por este parâmetro):

Módulo	Código	Papel
Manutenção de Pedido	MPD034, MPD043	Chamam `VERIFICA_CREDITO`/`VERIFICA_BLOQUEIO`, que lêem `CREDITO.VL_CREDITOACUM`
Manutenção de NF	MNF012, MNF026	Idem — bloqueio no faturamento
Fechamento de Faturamento	MFC027, MFI012, MFI015	Idem — bloqueio/desbloqueio
APIs mobile	`LimiteCreditoDAO.java`, `ClienteDAO.java`, `ClienteDataDAO.java`, `EmpresaDAO.java`, `ParametrosDAO.java`, `PessoaSQL.java`	Expõem `CREDITO.VL_CREDITOACUM` e `PARMFATUR.VL_CREDITOACUM` aos apps Android (PedidoMobile, VulcanoColeta, Apollo) e ao ERP Web

Procedures impactadas

Procedure / Trigger	Uso de `PARMFATUR.VL_CREDITOACUM`
`TRGAI_PESSOA`	Principal produtor de `CREDITO.VL_CREDITOACUM` — ao criar pessoa, copia `PARMFATUR.VL_CREDITOACUM` para `CREDITO.VL_CREDITOACUM` de uma ou várias empresas, conforme `TP_LIMITECREDITO` (`Scripts/TRGAI_PESSOA.sql:10, 18, 22, 36-47`)
`CREDITOPERIODICO_AI0`	Trigger `AFTER INSERT` de `CREDITOPERIODICO` — lê `PARMFATUR.VL_CREDITOACUM` e propaga período global entre empresas com `TP_LIMITECREDITO = 'S'` (`Scripts/CREDITOPERIODICO_AI0.sql:10, 17-21, 38-40`)
`CREDITOPERIODICOGRUPO_AI0`	Mesma lógica para grupo de empresas (`Scripts/CREDITOPERIODICOGRUPO_AI0.sql:10, 17-21, 38-40`)
`VERIFICA_CREDITO`	Consome `CREDITO.VL_CREDITOACUM` (não PARMFATUR) no bloqueio em tempo de faturamento; modo `V_ST_BLOQUEIO in ('T','A','O')` com `I_VL_CREDITOACUM IS NOT NULL` — soma `VL_TOTAL` (duplicatas vencidas + a vencer + documento atual) e compara com o limite (`Scripts/VERIFICA_CREDITO.sql:14, 27-31, 60-65`)
`VERIFICA_BLOQUEIO`	Consome `VIEW_CREDITOPESSOA.VL_CREDITOACUM`, invoca `VALIDA_MODELOBLOQUEIOVLLIMITE` passando o limite como `I_VL_CREDITOACUM` (`Scripts/VERIFICA_BLOQUEIO.sql:37, 700-704, 747-752, 757-762, 830`)
`VALIDA_MODELOBLOQUEIOVLLIMITE`	Compara `I_VL_TOTAL` (saldo pendente + documento) com `I_VL_CREDITOACUM`; modo `I_ST_BLOQUEIO in ('T','A','O','B','F','G')`; combina com `PARMUSUARIO.VL_LIMITECREDACUMULADO` quando `TP_MODELOBLOQUEIO = 'L'` (Alçada). Monta mensagem "Ultrapassou o Limite de Crédito Acumulado" (`Scripts/VALIDA_MODELOBLOQUEIOVLLIMITE.sql:108-166`)
`VIEW_CREDITOPESSOA`	Projeta `CREDITO.VL_CREDITOACUM` por empresa ou global conforme `TP_LIMITECREDITO`, incluindo via `CREDITOGRUPO` quando o cliente tem pai de grupo (`Scripts/VIEW_CREDITOPESSOA.sql:10, 70-74, 186-192, 202-206, 268-274`)
`VIEW_RFC030ANALITICO`	Exporta `C.VL_CREDITOACUM` no relatório analítico de inadimplência (`Scripts/VIEW_RFC030ANALITICO.sql:25, 388, 407, 414`)
`VIEW_CREDITO_ESTABIL`	Integração com ESTABIL — retorna `VL_CREDITOACUM` do `CREDITO` para sincronização (`Scripts/VIEW_CREDITO_ESTABIL.sql:61`)
`EXPORTACAO_SOVIS` / `EXPORTACAO_ALLABOR`	Exportações em arquivo-texto do saldo do cliente, incluem `COALESCE(C.VL_CREDITOACUM,0)` no registro (`Scripts/EXPORTACAO_SOVIS.sql:49, 237, 259`; `Scripts/EXPORTACAO_ALLABOR.sql:48, 186, 204-206`)
`GERA_CREDITO`	Corpo comentado — rotina inativa (`Scripts/GERA_CREDITO.sql:21, 32, 36`)

Campos envolvidos

Campo	Tabela	Papel
`VL_CREDITOACUM`	`PARMFATUR`	Este parâmetro — default/template da empresa em R$
`VL_CREDITOACUM`	`CREDITO`	Limite acumulado por cliente em R$ — é o que efetivamente trava o faturamento em `VERIFICA_CREDITO`/`VERIFICA_BLOQUEIO`/`VALIDA_MODELOBLOQUEIOVLLIMITE`. Nasce do `PARMFATUR.VL_CREDITOACUM` via `TRGAI_PESSOA` (`docs/schema/tables/CREDITO.sql:5`)
`VL_CREDITOACUM`	`CREDITOGRUPO`	Mesmo papel, para grupos de pessoas (pai financeiro) (`docs/schema/tables/CREDITOGRUPO.sql:5`)
`VL_CREDITOACUM`	`CREDITOPERIODICO` / `CREDITOPERIODICOGRUPO`	Histórico de limites acumulados por período (TFA002/TFA063) (`docs/schema/tables/CREDITOPERIODICO.sql:7`, `docs/schema/tables/CREDITOPERIODICOGRUPO.sql:7`)
`VL_CREDITO`	`PARMFATUR` / `CREDITO`	Parâmetro irmão — limite do documento isolado; avaliado por `ST_BLOQUEIO in ('C','A','O','Q','B','F','G')`
`NR_DIASATRASO`	`PARMFATUR` / `CREDITO`	Parâmetro irmão — tolerância em dias, default para `CREDITO.NR_DIASATRASO`
`TP_LIMITECREDITO`	`PARMFATUR`	`'S'` = limite global (replica `VL_CREDITOACUM` entre empresas); `'N'`/demais = por empresa
`TP_MODELOBLOQUEIO`	`PARMFATUR`	`'N'` = Normal, `'L'` = Alçada, `'A'` = Sem modelo; define se `VL_CREDITOACUM` é combinado com alçada do usuário em `VALIDA_MODELOBLOQUEIOVLLIMITE`
`ST_BLOQUEIO`	`PESSOA`	Modo de bloqueio do cliente — o valor acumulado só é avaliado em `('T','A','O','B','F','G')` (`Scripts/VALIDA_MODELOBLOQUEIOVLLIMITE.sql:108`) ou `('T','A','O')` (`Scripts/VERIFICA_CREDITO.sql:60`)
`VL_DUPVENC` + `VL_DUPAVENC`	`CREDITO` / `VIEW_CREDITOPESSOA`	Soma das duplicatas vencidas e a vencer — comparada com `VL_CREDITOACUM` para decidir o bloqueio
`VL_LIMITECREDACUMULADO`	`PARMUSUARIO`	Teto adicional por usuário (alçada) — comparado com `I_VL_TOTAL` quando `TP_MODELOBLOQUEIO = 'L'` (`VALIDA_MODELOBLOQUEIOVLLIMITE.sql:140-151`)

Comportamento / Regra de aplicação

Valor = NULL (padrão / empresa recém-criada)

Aspecto	Comportamento
Preenchimento em MFA001	Campo nasce vazio no `AfterInsert` (`UdmMFA001.pas:434-605`)
Efeito em `TRGAI_PESSOA`	Ao criar nova pessoa, o `INSERT INTO CREDITO (..., VL_CREDITOACUM ...)` grava `NULL` em `CREDITO.VL_CREDITOACUM` (`Scripts/TRGAI_PESSOA.sql:34-47`)
Efeito em `VERIFICA_CREDITO` (`Scripts/VERIFICA_CREDITO.sql:60`)	A condição `if (V_ST_BLOQUEIO in ('T','A','O')) and (I_VL_CREDITOACUM is not null)` cai para false → o bloco de bloqueio por acumulado é totalmente pulado
Efeito em `VALIDA_MODELOBLOQUEIOVLLIMITE` (`Scripts/VALIDA_MODELOBLOQUEIOVLLIMITE.sql:108`)	`I_VL_CREDITOACUM IS NOT NULL` → false → bloqueio por limite acumulado é ignorado
Consequência prática	Nenhum cliente herda limite acumulado. A regra de bloqueio por acumulado fica desligada sistemicamente até que o usuário preencha o parâmetro e rode a rotina que atualiza `CREDITO` (TFA002) ou cadastre pessoa nova

Resultado esperado: NULL equivale a "não bloquear ninguém por limite acumulado". O cliente só poderá ser bloqueado por outros modos ('C'/'Q' — crédito por documento, 'D' — dias de atraso), se estiverem configurados.

Valor = 0

Aspecto	Comportamento
Cadastro em MFA001	Aceito (sem `OnValidate` na MFA001 — só a TFA063 recusa negativo)
Em `TRGAI_PESSOA`	`CREDITO.VL_CREDITOACUM = 0,00` para toda pessoa nova
Em `VERIFICA_CREDITO` linha 60-65	`I_VL_CREDITOACUM is not null` é `true` → entra no bloco; `I_VL_TOTAL = coalesce(I_VL_TOTAL,0) + coalesce(V_VL_DOCUMENTO,0)`; `if I_VL_TOTAL > 0` compara `(saldo + documento) > 0`
Consequência prática	Qualquer duplicata pendente + qualquer pedido > R$ 0,00 dispara o bloqueio (mesmo que o cliente não tenha saldo pendente, se lançar um pedido `> 0` o sistema bloqueia). É o modo "nenhum crédito acumulado"
Mensagem (`VERIFICA_CREDITO.sql:63-65`)	`"Ultrapassou o Limite de Crédito Acumulado da Pessoa. Valor Total Pendente.: <saldo+doc>. Valor do Limite Acumulado.: 0,00"`

Resultado esperado: bloqueio imediato em qualquer venda a prazo, mesmo para cliente com contas em dia. Diferente de NULL: NULL desliga a regra; 0 a torna proibitiva.

Valor > 0 (ex.: 20.000,00)

Aspecto	Comportamento
Cadastro em MFA001	Aceito — `TDBEdit` com `DisplayFormat='#,0.00'` exibe `20.000,00`
Em `TRGAI_PESSOA`	`CREDITO.VL_CREDITOACUM = 20000,00` para toda pessoa nova
Em `VERIFICA_CREDITO`	Compara `(saldo_pendente + valor_pedido) > VL_CREDITOACUM`. Só bloqueia quando a soma de duplicatas em aberto somada ao documento atual ultrapassa R$ 20.000,00
Consequência prática	Cliente pode ter até R$ 20.000,00 de débito acumulado aberto (vencido + a vencer + documento atual). Acima disso, o sistema bloqueia ou exige liberação por alçada

Simulação passo a passo

Pré-requisitos do cenário:

PARMFATUR.VL_CREDITOACUM = 20.000,00 (definido em MFA001, Opção 2).
PARMFATUR.VL_CREDITO = 5.000,00 (parâmetro irmão — teto por documento).
PARMFATUR.TP_LIMITECREDITO = 'N' (limite por empresa).
PARMFATUR.TP_MODELOBLOQUEIO = 'N' (modelo normal).
Cliente novo "Maria" cadastrado em TPO001 com PESSOA.ST_BLOQUEIO = 'T' (bloqueia por valor acumulado).

Cadastro da pessoa (TPO001 → commit INSERT INTO PESSOA):
- Trigger TRGAI_PESSOA dispara.
- Lê PARMFATUR.VL_CREDITO = 5000,00 e PARMFATUR.VL_CREDITOACUM = 20000,00 (Scripts/TRGAI_PESSOA.sql:17-22).
- Como TP_LIMITECREDITO <> 'S', insere em CREDITO apenas da empresa logada: CREDITO.VL_CREDITO = 5000,00, CREDITO.VL_CREDITOACUM = 20000,00 (Scripts/TRGAI_PESSOA.sql:43-47).
Primeiro pedido para Maria: R$ 4.000,00 (MPD034):
- VERIFICA_BLOQUEIO → VIEW_CREDITOPESSOA retorna VL_CREDITOACUM = 20000, VL_TOTAL = 0 (sem duplicatas).
- I_VL_TOTAL = 0 + 4000 = 4000.
- 4000 > 20000 → false → não bloqueia por acumulado.
- (O VL_CREDITO = 5000 > 4000 também passa.)
Pedido é faturado e vira duplicata (CONTAS) — VL_DUPAVENC = 4.000,00. VIEW_CREDITOPESSOA passa a retornar VL_TOTAL = 4000.
Segundo pedido para Maria: R$ 10.000,00 (desmembrado em 3 parcelas):
- I_VL_TOTAL = 4000 + 10000 = 14000.
- 14000 > 20000 → false → não bloqueia por acumulado.
- MAS VL_CREDITO = 5000 e 10000 > 5000 → bloqueia por VL_CREDITO (se ST_BLOQUEIO também tiver 'C') — aqui, com ST_BLOQUEIO='T' apenas, o teto por documento não é avaliado e o pedido passa.
Terceiro pedido para Maria: R$ 8.000,00 (saldo pendente atual = 4000 + 10000 = 14000):
- I_VL_TOTAL = 14000 + 8000 = 22000.
- 22000 > 20000 → true → V_DS_BLOQUEIO = 'Ultrapassou o Limite de Crédito Acumulado da Pessoa. Valor Total Pendente.: 22000,00. Valor do Limite Acumulado.: 20000,00'.
- MPD034/MNF012/MFC027 exibem a mensagem e bloqueiam/exigem liberação por alçada.
Financeiro aumenta individualmente CREDITO.VL_CREDITOACUM = 30.000,00 para Maria via CFC004:
- A próxima chamada VERIFICA_BLOQUEIO(..., documento 8000) compara 22000 > 30000 → false → libera.
- O parâmetro PARMFATUR.VL_CREDITOACUM = 20000 não é reconsultado — a decisão é 100% do valor por cliente.
Gestor altera PARMFATUR.VL_CREDITOACUM para R$ 50.000,00 no MFA001:
- Nada muda para Maria — seu CREDITO.VL_CREDITOACUM continua 30000,00.
- Apenas clientes cadastrados após essa alteração herdarão CREDITO.VL_CREDITOACUM = 50000,00.

Resultado esperado: o parâmetro define a carga inicial do limite acumulado em R$ que cada cliente herda ao ser cadastrado. Ajustes individuais em CFC004/TFA002 sobrescrevem o default sem afetar o parâmetro, e ajustes posteriores no parâmetro não retroagem para clientes já existentes.

Interação com VL_CREDITO / TP_LIMITECREDITO

Aspecto	`PARMFATUR.VL_CREDITOACUM` (MFA001)	`CREDITO.VL_CREDITOACUM` (por cliente)
Escopo	Empresa (`CD_EMPRESA`)	Empresa + Pessoa (`CD_EMPRESA, CD_PESSOA`)
Quem preenche	Usuário em MFA001	`TRGAI_PESSOA` (default = PARMFATUR), ou CFC004/TFA002/TFA063 (override manual)
Quem lê no bloqueio	Ninguém lê em tempo de pedido/NF	`VERIFICA_CREDITO` (`Scripts/VERIFICA_CREDITO.sql:27-65`), `VERIFICA_BLOQUEIO` → `VALIDA_MODELOBLOQUEIOVLLIMITE`
Atualização retroativa	Não — mudar MFA001 depois de cadastrado o cliente não altera os `CREDITO.VL_CREDITOACUM` já existentes	Sim — cada alteração em CFC004/TFA002/TFA063 altera imediatamente o comportamento da validação

Diferença entre VL_CREDITO e VL_CREDITOACUM

Parâmetro	O que limita	Modo `ST_BLOQUEIO` que avalia	Comparação no backend
`VL_CREDITO`	Valor de um único documento (pedido/NF)	`('C','A','O','Q','B','F','G')` em `VALIDA_MODELOBLOQUEIOVLLIMITE`; `('C','A','O','Q')` em `VERIFICA_CREDITO`	`V_VL_DOCUMENTO > I_VL_CREDITO`
`VL_CREDITOACUM`	Soma de duplicatas em aberto + documento atual	`('T','A','O','B','F','G')` em `VALIDA_MODELOBLOQUEIOVLLIMITE`; `('T','A','O')` em `VERIFICA_CREDITO`	`I_VL_TOTAL > I_VL_CREDITOACUM` onde `I_VL_TOTAL = saldo_pendente + V_VL_DOCUMENTO`

Um cliente pode ter os dois ativos simultaneamente: VL_CREDITO = 5000 (cada pedido até 5k) e VL_CREDITOACUM = 20000 (máximo 20k em aberto). ST_BLOQUEIO = 'A' habilita ambos os modos; 'B', 'F', 'G' habilitam ambos em VALIDA_MODELOBLOQUEIOVLLIMITE, mas VERIFICA_CREDITO tem conjuntos menores.

Com TP_LIMITECREDITO

TP_LIMITECREDITO = 'S' (Global): no TRGAI_PESSOA, o valor de PARMFATUR.VL_CREDITOACUM da empresa logada é replicado em CREDITO.VL_CREDITOACUM de todas as empresas que também tenham TP_LIMITECREDITO = 'S' (Scripts/TRGAI_PESSOA.sql:25-40). Idem para os triggers CREDITOPERIODICO_AI0/CREDITOPERIODICOGRUPO_AI0 quando a TFA002 cria um período padrão.
TP_LIMITECREDITO = 'N' (por Empresa, default): TRGAI_PESSOA grava o CREDITO.VL_CREDITOACUM apenas para a empresa corrente (Scripts/TRGAI_PESSOA.sql:42-47). Clientes terão limites acumulados independentes por empresa.

Com ST_BLOQUEIO da pessoa

A regra de limite acumulado só é ativada quando PESSOA.ST_BLOQUEIO contém o modo correspondente:

Em VERIFICA_CREDITO: ('T','A','O')
Em VALIDA_MODELOBLOQUEIOVLLIMITE: ('T','A','O','B','F','G')

Se a pessoa tiver outro modo (ex.: 'C' = só crédito do documento, 'D' = só dias de atraso, 'N' = nenhum), o VL_CREDITOACUM do CREDITO é ignorado mesmo que preenchido.

Com TP_MODELOBLOQUEIO

'N' (Normal): bloqueia direto quando I_VL_TOTAL > I_VL_CREDITOACUM (VALIDA_MODELOBLOQUEIOVLLIMITE.sql:111-120).
'L' (Alçada/Liberação): se o usuário logado tem PARMUSUARIO.VL_LIMITECREDACUMULADO configurado, o bloqueio só se converte em alçada se o valor também ultrapassar esse teto adicional (VALIDA_MODELOBLOQUEIOVLLIMITE.sql:122-165). Caso contrário, cai no comportamento Normal.
'A' (Sem modelo): modelo desligado — nem Normal, nem Alçada.

:::warning Parâmetro MFA001 não é suficiente sozinho Preencher PARMFATUR.VL_CREDITOACUM não habilita o bloqueio por acumulado para os clientes que já existiam antes. É necessário: (a) rodar TFA002/TFA063/CFC004 para preencher CREDITO.VL_CREDITOACUM de cada cliente, ou (b) confiar que apenas clientes cadastrados depois da parametrização terão o valor correto (via TRGAI_PESSOA). :::

:::info Acumulado soma duplicatas + documento corrente O cálculo de I_VL_TOTAL em VERIFICA_CREDITO.sql:61 é coalesce(I_VL_TOTAL,0) + coalesce(V_VL_DOCUMENTO,0), onde I_VL_TOTAL vem de VL_DUPVENC + VL_DUPAVENC em VIEW_CREDITOPESSOA. Ou seja, o documento que está sendo lançado conta para o limite — um cliente com saldo zero pode bater o teto logo no primeiro pedido se VL_CREDITOACUM = 0. :::

Referências no Código Fonte

Delphi — MFA001 (cadastro do parâmetro)

Arquivo	Linhas	Papel
`source/MFA001/UMFA001.dfm`	3728-3742	`TLabel Label41` com `Caption = 'Cr'#233'dito Acumulado'` (Crédito Acumulado), `FocusControl = edtVL_CREDITOACUM`, dentro de `pagFatOp2` (Opção 2)
`source/MFA001/UMFA001.dfm`	4244-4260	`TDBEdit edtVL_CREDITOACUM` com `DataField = 'VL_CREDITOACUM'`, `DataSource = dmMFA001.dsPARMFATUR`, `TabOrder = 12`
`source/MFA001/UMFA001.pas`	261	Declaração `edtVL_CREDITOACUM: TDBEdit`
`source/MFA001/UdmMFA001.pas`	167	Declaração `tabPARMFATURVL_CREDITOACUM: TFMTBCDField` (sem `OnValidate`)
`source/MFA001/UdmMFA001.dfm`	1301-1307	Field definition — `DisplayFormat = '#,0.00'`, `Precision = 18`, `Size = 2`, sem `DefaultExpression`, sem `OnValidate`
`source/MFA001/UdmMFA001.dfm`	2393, 2557, 2777	Inclusão de `VL_CREDITOACUM` em SELECT/INSERT/UPDATE da tabela `PARMFATUR`
`source/MFA001/UdmMFA001.pas`	434-605	Bloco `tabPARMFATURAfterInsert` termina sem atribuir valor a `VL_CREDITOACUM` — nasce `NULL`

Delphi — TFA002 (produtor/editor por cliente)

Arquivo	Linhas	Papel
`source/TFA002/UTFA002.pas`	38, 48, 109	Declarações `lblVL_CREDITOACUM`, `edtVL_CREDITOACUM`, `edtVL_CREDITOACUMGRUPO`
`source/TFA002/UTFA002.pas`	304	Consulta `C.VL_CREDITO, C.VL_CREDITOACUM, C.NR_DIASATRASO` de `CREDITO`
`source/TFA002/UTFA002.pas`	721-728, 791-798	INSERT INTO CREDITO/CREDITOGRUPO com `VL_CREDITOACUM = Nulo(..., 'F')` (NUMBERIC)
`source/TFA002/UTFA002.pas`	902-917, 945-960	Rotina DepsSmart — INSERT OR UPDATE de `CREDITO` com `VL_CREDITOACUM = ...` (`SeSenao` decide entre preservar valor anterior ou aplicar novo)
`source/TFA002/UTFA002.pas`	1904, 1907	Copia `cdsDepsSmartVL_SOLICITADOREQ`/`VL_SUGERIDOREQ` para `tabPERIODOVL_CREDITOACUM` ao gerar novo período
`source/TFA002/UTFA002.pas`	2121-2123	Calcula `VL_DISPONIVELAUX = VL_CREDITOACUM - vlTotal` (saldo livre no acumulado)
`source/TFA002/UdmTFA002.dfm`	55, 106-110, 207-218, 234	Fields e SQLs (`tabCREDITO`) com `VL_CREDITOACUM`
`source/TFA002/UdmTFA002.dfm`	367, 409-414, 467-483, 503, 715, 769-773, 864-867	Campos `tabPERIODOVL_CREDITOACUM` e `tabCREDITOGRUPOVL_CREDITOACUM` (CREDITOPERIODICO e CREDITOGRUPO) com `OnValidate`

Delphi — TFA063 (Crédito Periódico — com validação >= 0)

Arquivo	Linhas	Papel
`source/TFA063/UdmTFA063.pas`	27, 61, 110-113	`tabCREDITOVL_CREDITOACUM` com `OnValidate` que rejeita `< 0`
`source/TFA063/UdmTFA063.pas`	156	UPDATE de `CREDITO` com `VL_CREDITOACUM = Nulo(...)`
`source/TFA063/UTFA063.pas`	287-289, 322	Filtro por faixa `VL_ACUMULADOINI..VL_ACUMULADOFIM` e SELECT de `C.VL_CREDITOACUM`
`source/TFA063/UdmTFA063.dfm`	67, 108-111, 185-202, 216	Fields e SQLs
`source/TFA063/UTFA063.dfm`	890	`FieldName = 'VL_CREDITOACUM'` na grid de edição

Delphi — CFC004 (cadastro por cliente)

Arquivo	Linhas	Papel
`source/CFC004/UdmCFC004.dfm`	741, 785-788, 870, 883	Field `tabCREDITOVL_CREDITOACUM` com `Origin = 'CREDITO.VL_CREDITOACUM'`, UPDATE inclui `VL_CREDITOACUM = :VL_CREDITOACUM`
`source/CFC004/UdmCFC004.pas`	48	Declaração do field — edita o valor por cliente, sobrescrevendo o default herdado de PARMFATUR

Delphi — MPD034 (consumidor em pedido)

Arquivo	Linhas	Papel
`source/MPD034/UMPD034.dfm`	2522-2531	`TDBEdit edtVL_CREDITOACUM` (somente leitura na tela de pedido)
`source/MPD034/UdmMPD034.dfm`	1094-1099, 1204-1206	SELECT em `CLIENTE` calcula `VL_DISPONIVELACUMULADO = COALESCE(CR.VL_CREDITOACUM, 0) - (VL_DUPAVENC + VL_DUPVENC)`
`source/MPD034/UdmMPD034.pas`	146	`tabCLIENTEVL_CREDITOACUM: TFMTBCDField`
`source/MPD034/UMPD034.pas`	141	Declaração `edtVL_CREDITOACUM: TDBEdit`

Delphi — Outros consumidores

Arquivo	Linhas	Papel
`source/MCO008/UdmMCO008.pas`	176, 282-295	Sobrescreve `VL_CREDITOACUM` virtual com `LIMITECREDITO.VL_ACUMULADOMEN` (cotação de peças)
`source/MCO008/UdmMCO008.dfm`	54, 161-163, 511	Campo virtual `CAST(NULL AS DOM_NUMERIC15_2) VL_CREDITOACUM`
`source/TFA001/URelTFA001.pas`	1386, 1399	Relatório Análise de Crédito — exibe `C.VL_CREDITOACUM`
`source/RFC022/URFC022.pas`	2754	Relatório Movimento de Contas — exibe `C.VL_CREDITOACUM`
`source/RFC030/UdmRFC030.dfm`	187, 210, 275-277	Relatório de Inadimplência Analítico — consome `VIEW_RFC030ANALITICO.O_VL_CREDITOACUM`
`source/RFC030/UdmRFC030.pas`	45	`tabRELATORIOO_VL_CREDITOACUM: TFMTBCDField`
`source/TFA044/UTFA044.pas`	42; `UTFA044.dfm:200`	Label `lblVL_CREDITOACUM`
`source/JunsoftImportacao/PersistenciaDAO/PersistenciaDao.pas`	—	Rotina de importação persiste `CREDITO.VL_CREDITOACUM` vindo do ERP origem

Java — APIs (expõem o valor para apps e ERP Web)

Arquivo	Linhas	Papel
`source/Server/PedidoMobile/ERPPedidoRestAS/.../EmpresaDAO.java`	22, 90-91	`SELECT PM.VL_CREDITOACUM FROM PARMFATUR PM` — expõe o parâmetro aos apps
`source/Server/PedidoMobile/ERPPedidoRestAS/.../LimiteCreditoDAO.java`	22, 37, 50, 221-222	`SELECT CP.VL_CREDITOACUM FROM VIEW_CREDITOPESSOA CP` — expõe limite acumulado por pessoa (mobile)
`source/Server/VulcanoColeta/.../ParametrosDAO.java`	27, 117-118	`SELECT PF.VL_CREDITOACUM FROM PARMFATUR PF` — expõe parâmetro aos apps Vulcano
`source/Server/VulcanoColeta/.../ClienteDAO.java`	47, 486-487	`SELECT CP.VL_CREDITOACUM FROM VIEW_CREDITOPESSOA`
`source/Server/VulcanoColeta/.../ClienteDataDAO.java`	41	Idem
`source/Server/JunsoftApollo/.../LimiteCreditoDAO.java`	22	`UPDATE OR INSERT INTO CREDITO (..., VL_CREDITOACUM, ...)` — persiste via API Apollo
`source/Server/JunsoftWebAPI/.../PessoaSQL.java`	109	`COALESCE(CR.VL_CREDITOACUM,0) - (VL_DUPAVENC+VL_DUPVENC) VL_CREDITODISPONIVEL` — calcula disponível acumulado no ERP Web

DDL

docs/schema/tables/PARMFATUR.sql:126 — VL_CREDITOACUM DOM_NUMERIC15_2, (permite NULL, sem default SQL)
docs/schema/tables/CREDITO.sql:5 — VL_CREDITOACUM DOM_NUMERIC15_2, (campo populado por TRGAI_PESSOA a partir de PARMFATUR)
docs/schema/tables/CREDITOGRUPO.sql:5 — VL_CREDITOACUM DOM_NUMERIC15_2,
docs/schema/tables/CREDITOPERIODICO.sql:7 — VL_CREDITOACUM DOM_NUMERIC15_2,
docs/schema/tables/CREDITOPERIODICOGRUPO.sql:7 — VL_CREDITOACUM DOM_NUMERIC15_2,

SQL — Triggers/Procedures

Arquivo	Linhas	Papel
`Scripts/TRGAI_PESSOA.sql`	10, 17-22, 34-47	Principal consumidor — copia `PARMFATUR.VL_CREDITOACUM` para `CREDITO.VL_CREDITOACUM` no cadastro de nova pessoa, respeitando `TP_LIMITECREDITO` (global vs. por empresa)
`Scripts/CREDITOPERIODICO_AI0.sql`	10, 17-21, 38-40	Trigger `AFTER INSERT` de `CREDITOPERIODICO` — lê/replica `VL_CREDITOACUM` entre empresas globais
`Scripts/CREDITOPERIODICOGRUPO_AI0.sql`	10, 17-21, 38-40	Idem para grupo de empresas
`Scripts/VERIFICA_CREDITO.sql`	14, 27-31, 60-65	Consome `CREDITO.VL_CREDITOACUM` para bloqueio; modo `ST_BLOQUEIO in ('T','A','O')`; soma saldo + documento e compara
`Scripts/VERIFICA_BLOQUEIO.sql`	37, 700-704, 747-752, 757-762, 830	Consome `VIEW_CREDITOPESSOA.VL_CREDITOACUM` (incluindo via `CREDITOPERIODICO[GRUPO]`) e invoca `VALIDA_MODELOBLOQUEIOVLLIMITE`
`Scripts/VALIDA_MODELOBLOQUEIOVLLIMITE.sql`	108-166	Compara `I_VL_TOTAL > I_VL_CREDITOACUM`; aplica alçada `PARMUSUARIO.VL_LIMITECREDACUMULADO` quando `TP_MODELOBLOQUEIO = 'L'`; mensagem "Ultrapassou o Limite de Crédito Acumulado"
`Scripts/VIEW_CREDITOPESSOA.sql`	10, 70-74, 186-192, 202-206, 268-274	Projeta `CREDITO.VL_CREDITOACUM` por empresa ou global conforme `TP_LIMITECREDITO`, incluindo fallback para `CREDITOGRUPO`
`Scripts/VIEW_RFC030ANALITICO.sql`	25, 388, 407, 414	View do relatório de inadimplência analítico, expõe `O_VL_CREDITOACUM`
`Scripts/VIEW_CREDITO_ESTABIL.sql`	61	Integração ESTABIL → ERP — retorna `VL_CREDITOACUM` do `CREDITO`
`Scripts/EXPORTACAO_SOVIS.sql`	49, 237, 259, 265, 526, 544, 546, 552	Exportação de arquivo SALDOCLIENTE.TXT — concatena `COALESCE(C.VL_CREDITOACUM,0)` no registro
`Scripts/EXPORTACAO_ALLABOR.sql`	48, 186, 204-206, 211	Idem, exportação para ALLABOR
`Scripts/GERA_PEDIDOCOTACAOPECA.sql`	—	Referencia `VL_CREDITOACUM` em contexto de cotação
`Scripts/GERA_CREDITO.sql`	21, 32, 36	Corpo comentado — rotina inativa

O que o parâmetro faz​

Telas impactadas​

Procedures impactadas​

Campos envolvidos​

Comportamento / Regra de aplicação​

Valor = NULL (padrão / empresa recém-criada)​

Valor = 0​

Valor > 0 (ex.: 20.000,00)​

Simulação passo a passo​

Interação com VL_CREDITO / TP_LIMITECREDITO​

Diferença entre VL_CREDITO e VL_CREDITOACUM​

Com TP_LIMITECREDITO​

Com ST_BLOQUEIO da pessoa​

Com TP_MODELOBLOQUEIO​

Referências no Código Fonte​

Delphi — MFA001 (cadastro do parâmetro)​

Delphi — TFA002 (produtor/editor por cliente)​

Delphi — TFA063 (Crédito Periódico — com validação >= 0)​

Delphi — CFC004 (cadastro por cliente)​

Delphi — MPD034 (consumidor em pedido)​

Delphi — Outros consumidores​

Java — APIs (expõem o valor para apps e ERP Web)​

DDL​

SQL — Triggers/Procedures​