Protheus: módulos e funcionalidades

Protheus: módulos e funcionalidades

Você precisa mapear quais módulos do Protheus suportam um processo crítico — por exemplo, desde a requisição de compra até a baixa financeira e escrituração contábil — e não sabe quais rotinas, tabelas e parâmetros são envolvidos? Em operações reais isso gera dúvidas estratégicas: onde parametrizar bloqueios, como garantir o controle de saldos em estoque, quais tabelas confirmar em uma integração ou auditoria, e quais rotinas chamar para automatizar etapas como geração de títulos ou fechamento de mês.

Visão geral dos módulos e como eles se conectam

O Protheus organiza funcionalidades por módulos funcionais (ex.: Compras, Faturamento, Estoque, Financeiro, Contabilidade, Gestão de Pessoas/Folha). Cada módulo inclui rotinas de atualização (manutenção e gravação), tabelas de negócio e pontos de entrada que permitem customizações e integrações. Em cenários transacionais as fronteiras mais críticas são:

• Compras → Geração de pedidos e controle de atendimento (módulo Compras).
• Estoque → Recebimento, controle de saldos e fechamento (módulo Estoque/Logística).
• Faturamento → Emissão de pedidos de venda e integração para gerar títulos (módulo Faturamento).
• Financeiro → Contas a pagar e a receber, baixa bancária e CNAB (módulo Financeiro).
• Contabilidade / TAF → Consolidação das informações fiscais e geração de arquivos magnéticos.
• Folha → Geração de provisões e integração de títulos para o financeiro.

Cada trajeto transacional percorre tabelas-chave que servem como “contratos” entre módulos; entender essas tabelas e os pontos de gravação reduz risco em integrações e reconciliações.

Módulo de Compras: rotinas, tabelas e pontos de controle

No fluxo de compras há rotinas específicas para solicitação, cotação, pedido e recebimento. Exemplos de rotinas de manutenção de pedido e solicitação são MATA110 (Solicitação de Compras) e MATA120 / MATA121 (Pedido de Compras). Essas rotinas interagem com tabelas de cabeçalho e itens e com cadastros mestres.

• Tabelas relevantes: SC1 (Solicitações de Compra), SC7 (Itens do Pedido de Compra), SC8 (Cotações), SA2 (Fornecedores), SB1 (Produtos), SA5 (amarração produto-fornecedor), SE4 (Condições de pagamento).
• Pontos de entrada (hooks): existem pontos como MT110VLD e MT120OK que permitem validações e ajustes na gravação, além de pontos que manipulam saldo e aprovação — úteis para personalizar regras de negócio sem alterar a rotina base.
• Parâmetros (exemplos): nomes como MV_RESTINC, MV_RESTPED, MV_RESTNFE, MV_ARRPEDC aparecem em contextos de restrição e arredondamento. Atenção: parâmetros com prefixo MV_* devem ser tratados como exemplos de customização e precisam de validação em cada ambiente antes de alteração.

Boas práticas no módulo de Compras: ativar validações críticas via pontos de entrada em vez de alterar código-fonte; documentar as regras de aprovação e acompanhar as atualizações de tabelas que são usadas para origem automática de pedidos (ex.: cotações).

Módulo de Faturamento/Vendas: rotinas, tabelas e integração com estoque

O ciclo de vendas é coordenado por rotinas centrais como MATA410 (Pedido de Venda). O faturamento depende de tabelas de pedido e itens e consulta cadastros de clientes, preços e saldos por armazém.

• Tabelas envolvidas: SC5 (cabecalho do pedido), SC6 (itens do pedido), SA1 (clientes), SB1 (produtos), DA0/DA1 (tabelas de preços), SB2 (saldos por armazém), SE4 (condições de pagamento), SA3 (vendedores).
• Pontos de controle: validações e triggers como MT410INC, MT410TOK e MTA410I permitem interceptar inclusão, alteração e gravação do pedido, por exemplo para chamar regras de crédito, bloqueio ou integração com e‑commerce/EDI.
• Parâmetros de operação: parâmetros que governam reservas e avaliação de saldo (alguns exibidos em contexto de faturamento) devem ser avaliados para comportamento de reserva e liberação de estoque.

Recomendação técnica: isolar regras de política comercial no nível de configuração (tabelas de preço, condições de pagamento) e usar pontos de entrada para regras operacionais que dependam de processos externos (credit scoring, WMS).

Módulo de Estoque e Logística: controle de saldos, custeio e fechamento

Controle de estoque no Protheus envolve movimentações de entrada/saída e procedimentos de fechamento que atualizam saldos iniciais e bloqueiam lançamentos retroativos. Rotinas associadas ao fluxo de movimentos usam tabelas de notas e saldos.

• Tabelas principais: SD1 (notas de entrada), SD2 (notas de saída), SD3 (movimentações internas) e SB9 (saldos iniciais / virada de saldos). Para inventário, a tabela SB7 é citada no contexto de importação e processamento de inventário.
• Parâmetros de controle: MV_ULMES (data do último fechamento de estoque) é frequentemente consultado antes de permitir movimentações em datas anteriores; MV_CUSMED aparece como exemplo de seleção de método de custeio (médio, FIFO, último preço, etc.). Observe que parâmetros com prefixo MV_* devem ser tratados como exemplos de customização e validados localmente.
• Processos de fechamento: rotinas e procedimentos como recálculo de custo de entrada, refaz saldo, recálculo de custo médio e a rotina de “Virada dos Saldos” atualizam SB9 e o parâmetro de fechamento. Esses processos são críticos para bloqueio de lançamentos retroativos e para consistência entre quantidade e valor.

Operacionalmente: implemente rotinas de conferência (kardex, relatórios por dia) antes da virada; mantenha logs de processamento do recálculo e do refaz de saldos para auditoria. Em integrações WMS, avalie parametrizações que influenciam gravação por endereço/lote.

Financeiro (Contas a Pagar e Receber): tabelas, integração e configuração

O módulo Financeiro centraliza títulos, baixas e integração bancária. Rotinas como FINA050 (Contas a Pagar) e FINA040 (Contas a Receber) são os pontos de entrada operacionais para manutenção de títulos.

• Tabelas: SE2 (títulos a pagar), SE1 (títulos a receber), SE5 (movimentação bancária), SE4 (condições de pagamento), SED (naturezas financeiras), SA6 (bancos).
• Pontos de extensão: existem pontos como FA050GRV e FA040GRV para interceptar gravações e adaptar integração com ERPs externos ou automações (por exemplo, geração de borderôs, CNAB ou baixa automática).
• Integração com Folha e Compras: existe a rotina de integração que transforma movimentos de folha (processos de geração de títulos no módulo de Gestão de Pessoal) em registros a serem importados pelo financeiro; o fluxo normalmente passa por uma tabela de manutenção no módulo de folha antes de persistir em SE2/SE1.

Governança: manter regras de natureza financeira (SED) bem parametrizadas evita erros de impostos e retenções; adote validações por ponto de entrada para evitar divergências no momento da geração automática de títulos por nota fiscal de entrada/saída.

Contabilidade e obrigações fiscais (TAF / TAFST / ECF): integrações e processos

A camada de escrituração envolve captura de lançamentos contábeis e entrega de arquivos magnéticos. O fluxo operacional pode incluir geração por uma “Central de Escrituração” e processos de integração entre o sistema contábil e o componente de obrigações.

• Objetos citados: tabelas de integração TAFST1 e TAFST2 são utilizadas no fluxo de passagem de dados para o motor de obrigações. Processos de reconfiguração e wizard de setup recriam índices e preparam as tabelas para integração.
• Operações frequentes: execução de processos “0” e “2” (do fluxo de integração) que copiam dados entre TAFST1 → TAFST2 e processam informações para o repositório do TAF. Rotinas de compatibilizador e atualizações de dicionário (por exemplo UPDDISTR) são usadas para acomodar mudanças de layout.
• Parâmetros de deploy e wizard: MV_VAUTCON e MV_TAFWIZ são exemplos de parâmetros relacionados ao carregamento de tabelas autocontidas e ao wizard do TAF; observe que parâmetros com prefixo MV_* devem ser revisados como customizações antes de alterações.

Do ponto de vista técnico, garanta backups de RPO e dicionário antes de executar atualizações do TAF; ao recriar índices ou dropar tabelas temporárias, documente o processo e valide com ambiente controle para evitar perda de dados.

Gestão de Pessoas / Folha: fechamento, reabertura e integração

A Folha possui procedimentos próprios de fechamento que movem movimentos mensais para acumulados anuais e geram tabelas auxiliares de backup. Entender as tabelas envolvidas é crítico para reaberturas controladas e para a integração com o financeiro.

• Tabelas envolvidas: SRC990 (movimentos mensais), SRD990 (acumulados anuais) e cópias mensais como RC + empresa + ano + mês (ex.: RC991411) — utilizadas para recuperação em processo de reabertura. Para 13º, tabelas equivalentes SRI / RI são usadas.
• Processo de fechamento: o fechamento move dados de SRC990 para SRD990, cria a tabela RC com o backup do mês, limpa SRC990 e atualiza o parâmetro MV_FOLMES para o próximo período. Alterações no parâmetro MV_FOLMES (ex.: reabrir o mês) devem ser acompanhadas de procedimentos de restauração controlada.
• Integração com financeiro: existe um fluxo de definição/geração/manutenção que prepara títulos no módulo de folha e depois chama a rotina de integração para incluir os registros no contas a pagar (SE2). Esse processo usualmente tem uma rotina de “Manutenção” que serve como staging antes da inclusão definitiva.

Recomendação operacional: nunca reabra períodos sem backup completo; documente a sequência de restauração (restaurar SRD990, reimportar RC…, ajustar MV_FOLMES) e alinhe processo com a contabilidade para recalculos de provisões, se aplicável.

Configuração, parâmetros e diferenciação entre padrão e customização

Na administração do ambiente é comum lidar com parâmetros que alteram operações padrão. Alguns nomes aparecem com prefixo MV_ — ao considerar mudanças neles, tenha em mente que, conforme prática de projeto, parâmetros MV_* podem ser utilizados como pontos de customização entre instalações.

• Exemplos de parâmetros citados: MV_ULMES (data do último fechamento de estoque), MV_CUSMED (método de custeio), MV_ESTNEG (permite saldo negativo), MV_PZRESER (prazo de validade da reserva de estoque). Tratar esses itens como customizações exige validação de impacto em todos os módulos que leem esses parâmetros.
• Outros artefatos de customização: rotinas utilitárias com prefixo U_ (por exemplo U_UPDSIGAFIS) foram mencionadas em contextos de compatibilizadores/importação. Essas rotinas, por convensão, costumam ser pacotes complementares e exigem revisão antes de serem executadas em produção.
• Princípio de implementação: prefira parametrização e pontos de entrada (hooks) em vez de alterações diretas em fontes padrões; quando customizar, registre nome, objetivo e dependências para facilitar upgrade e suporte.

Padrões de integração e automação entre módulos

Integrações internas (ex.: Compras → Estoque → Financeiro → Contabilidade) seguem um padrão de staging: gerar registros em tabelas transacionais, processar regras de negócio e gravar em tabelas mestres ou de destino. Pontos-chave para projetos de integração:

• Use tabelas de staging e rotinas de manutenção (ex.: rotina de Manutenção do módulo de Folha) para validar dados antes da inclusão final;
• Intercepte gravações via pontos de entrada (por exemplo MT*/FA* / MTA*), evitando mudanças em fontes padrões;
• Execute compatibilizadores e atualize dicionário (UPDDISTR) em ambiente de homologação antes de produção; mantenha logs das execuções;
• Em integrações fiscais, reproduza os processos de Wizard/TAFLOAD e valide índices das tabelas TAFST1/TAFST2 para evitar erros de leitura/ordenação.

Boas práticas operacionais e de governança

Para reduzir problemas operacionais e garantir auditabilidade, recomenda-se:

• Documentar fluxos end-to-end, mapeando rotinas, tabelas e pontos de entrada envolvidos em cada processo crítico;
• Ter procedimentos de backup e rollback antes de aplicar patches ou executar compatibilizadores que alterem dicionário ou índices;
• Conservar ambientes de homologação idênticos a produção para testar atualizações de fontes e parametrizações, incluindo simulações de fechamento (estoque, folha, contábil);
• Controlar customizações U_/MV_/Z* em repositório e registrar dependências — isso facilita atualizações e redução de regressões;
• Automatizar geração de relatórios de conferência (kardex por dia, posição de estoque, relatórios de conferência de inventário, logs de geração de títulos) para supervisão mensal.

Exemplo de fluxo integrado (conceitual) e pontos de validação

Fluxo típico: requisição (MATA110) → pedido de compra (MATA120/MATA121) → recebimento (SD1) → atualização de saldo (SB9/SB2) → geração de título a pagar (finite process via FINA050 / SE2) → contabilização pela rotina de folha/conta ou via integração para TAF (TAFST1/TAFST2).

Pontos de validação em cada etapa:

• No pedido: confirmar itens em SC7, fornecedor em SA2 e vínculo produto-fornecedor em SA5;
• No recebimento: verificar atualização de saldo em SB9 e regras de custo (MV_CUSMED, custo médio/refaz custo entrada);
• No financeiro: conferir natureza (SED), condições de pagamento (SE4) e títulos resultantes em SE2/SE1 antes da baixa;
• Na contabilização: validar planos de contas e executar processos de integração para criação de registros em TAFST1, garantindo índices e integridade para exportação.

Checklist de auditoria técnica antes de alterações

Antes de qualquer mudança que afete processos transacionais, execute:

• Backup de RPO, dados e dicionário;
• Testes end-to-end em ambiente de homologação (incluindo geração e conferência de relatórios finais);
• Validação de índices e execução de compatibilizadores (por exemplo UPDDISTR) quando dicionário for alterado;
• Verificação de dependências em pontos de entrada e rotinas U_* ou Z* que possam ser invocadas;
• Plano de rollback documentado com responsáveis e janelas de execução.

Dominar o mapa de módulos, rotinas e tabelas do Protheus — MATA110/120/121 para compras, MATA410 para pedidos de venda, SD*/SB* para estoque, SE*/SE4/SED para financeiro, SRC/SRD para folha e TAFST1/TAFST2 para obrigações — é condição necessária para projetos de implantação, integração e auditoria. A combinação de configuração correta, uso de pontos de entrada para customizações e procedimentos robustos de validação reduz riscos de inconsistência entre módulos e garante maior previsibilidade nas operações diárias e nos fechamentos mensais.