Protheus 12.1.2610 no Faturamento e Compras: o que muda na emissão, na alçada e na cotação

O que muda em uma tabela

A tabela reúne o que a TOTVS publicou para o SIGAFAT e o SIGACOM nas novidades de Backoffice da 12.1.2610. A última coluna mostra o que decide se a mudança entra no seu ambiente.

O que já existia antes da 2610

Quem está numa release anterior atualizada pode já ter parte dessas funções, porque a TOTVS as entregou por expedição contínua. Na 2610 elas passam a fazer parte do pacote da release, e algumas telas mudam por causa do Smart X.

Por isso o primeiro passo é saber o que já está ligado no ambiente de produção. Uma empresa que já fatura com data de entrega e alçada vai testar a 2610 de um jeito; outra, que nunca aplicou esses pacotes, vai receber tudo de uma vez.

Data prevista de entrega divide a nota

A NT 2025.002 tornou obrigatória a tag dPrevEntrega no cabeçalho da NF-e. No Protheus, a data nasce no item do pedido (C6_ENTREG), passa para a liberação (C9_DATENT) e, no faturamento, vai para o cabeçalho da nota (F2_DTENTR). Como a data é do documento inteiro, ela entra na regra de aglutinação: itens do mesmo pedido com datas diferentes geram notas diferentes.

• Data inicial: o C6_ENTREG nasce com a data base do sistema. Sem revisão, o pedido digitado hoje carrega a data de hoje como entrega.
• Facilitador: a data no cabeçalho do pedido (C5_FECENT) replica para todos os itens, que continuam editáveis.
• Frete: a data não é gravada quando o tipo de frete é FOB, por conta do destinatário, sem frete ou em branco.
• Depois da emissão: o evento 112150 permite ao emitente atualizar a data prevista quando ela muda.
• Parâmetro: MV_LDTENTR liga ou desliga o tratamento.

A SEFAZ rejeita a nota quando a data passa de três meses da saída (1154), é anterior à saída (1155), aparece em finalidade diferente de normal ou devolução (1156) ou é informada com frete FOB, transporte próprio do destinatário ou sem transporte (1157). A NFC-e com a tag é rejeitada (1153).

A TOTVS não colocou trava padrão nos valores informados. Para proteger a operação, a própria documentação indica o ponto de entrada MT46DTEN, a validação dos campos ou do pergunte MT460A28.

Faturamento por Schedule

A função FatSchNFPV roda pelo Schedule e gera os documentos de saída de todos os pedidos já liberados, de acordo com a periodicidade, a empresa, a filial e a série configuradas. Os parâmetros do agendamento são os mesmos do pergunte MT460A.

• Série: o parâmetro MV_SERSCHD precisa ter a série do documento de saída. Sem ele, os pedidos não são faturados.
• Agendamento: no menu de agendamentos do Scheduler, nova rotina FatSchNFPV, data inicial e periodicidade do job.
• Liberação: o job só fatura o que já passou por crédito e estoque. Regras de bloqueio continuam valendo.

Para quem fatura alto volume em lote, a função tira a dependência de alguém disparar o MATA460A. Para quem tem conferência manual antes da emissão, o agendamento precisa respeitar esse fluxo, ou a nota sai antes da hora.

Alçada no pedido de venda

O controle de alçadas do Faturamento restringe a manutenção, a análise e a aprovação do pedido de venda a quem tem permissão. Ele usa a mesma estrutura de Compras: aprovadores (MATA095), perfis de aprovação (COMA210) e grupo de aprovação (MATA114), com a liberação feita na MATA094.

A aprovação é sempre pelo total do pedido, nunca por item, e não considera as entidades contábeis do grupo. Com MV_TALCFAT em 2, pedido sem desconto entra liberado. Na 2610, com o Smart X, as legendas de pedido em aprovação e rejeitado mudam de cor. Quem tem relatório, painel ou integração que lê a legenda ou o status do pedido precisa conferir.

Ente governamental e notas de débito

Para vendas ao poder público, o cliente é marcado no campo AI0_ENTGOV (União, Estado, Distrito Federal, Município, Consórcio Público ou Comitê Gestor do IBS) e o pedido informa o tipo de operação em C5_GOVOPER: fornecimento com pagamento posterior, recebimento após o fornecimento, fornecimento com pagamento já realizado ou recebimento com fornecimento posterior. As duas notas, a do fornecimento e a do recebimento, levam o grupo gTribCompraGov, e a alíquota redutora vem do Configurador de Tributos. O pedido de venda tem um facilitador em Outras Ações que gera o pedido espelho a partir da nota de fornecimento.

As notas de débito (finNFe igual a 6) formalizam ajustes de IBS e CBS que aumentam o imposto, na ótica do emitente. A rotina MATA600 entra no menu padrão do Faturamento na 2610; nas releases anteriores, é preciso incluir no menu. As notas de crédito (finNFe igual a 5) são geradas só por Compras. A TOTVS publicou patches para os pontos de entrada legados que são usados em comum na gravação e na exclusão. A contabilização dos novos tributos está em contabilização de IBS e CBS no Protheus.

Cotação multifilial e workflow

No Novo Fluxo de Compras, o parâmetro MV_NFCMFIL igual a .T. faz as telas de solicitação e de cotação mostrarem os registros de todas as filiais que o usuário pode acessar, não só da filial logada. O comportamento padrão continua sendo só a filial corrente. Uma mesma cotação não mistura solicitações de filiais diferentes.

• Descrição do produto: com o multifilial ligado, a TOTVS orienta usar MV_NFCDESC igual a 3, para usar a descrição da solicitação. Sem isso, o nome do produto aparece em branco ou errado quando o código não é o mesmo nas filiais.
• Acesso: o que cada comprador enxerga passa a depender das filiais liberadas no cadastro dele.
• Melhorias de tela: data estimada na cotação, campos customizados da SC8 no gerenciador de colunas, filtros por comprador e status, e desempate por menor valor sem impostos quando os prazos empatam.

O workflow customizável (NFCA030) monta o e-mail que vai ao fornecedor com campos escolhidos da SC8 e da DHU, define quais o fornecedor pode editar e quais são obrigatórios. Só é permitido um template, guardado nas tabelas DKK e DKL, e o HTML gerado fica na pasta workflow do protheus_data.

Cadastro de clientes e produtos

O cadastro de clientes pessoa física (CRMA980) passa a ter um formulário único com a seção de endereços complementares. A tabela SA1 continua com um registro por loja, então integrações e relatórios que leem a SA1 seguem vendo vários registros para o mesmo CPF. A mudança é na tela e na integridade dos dados gerais.

Também entram a categorização e a caracterização de produtos numa única interface e a codificação automática de produtos pela árvore de categorias. Quem já tem regra própria de código de produto, por gatilho ou ponto de entrada, precisa decidir qual das duas vale antes de habilitar a padronização.

O que procurar nas customizações

• Aglutinação: pontos de entrada e rotinas próprias que assumem uma nota por pedido, no MATA410 e no MATA460A.
• Data de entrega: uso atual do C6_ENTREG e do C5_FECENT, e qualquer validação própria; avaliar o MT46DTEN.
• Integrações: EDI, transportadora, WMS e portal do cliente que leem a SF2 ou esperam um documento por pedido.
• Status do pedido: relatórios e painéis que leem C5_CONAPRO, a legenda ou o bloqueio do pedido.
• Compras: workflow de cotação customizado, filtros por filial e uso de MV_NFCDESC.
• Cadastros: regras próprias de código de produto e rotinas que tratam cliente pessoa física duplicado.

Roteiro de homologação

Como a TOTVS bloqueia a volta para a release anterior depois da atualização, o teste usa uma cópia da base com pedidos reais.

O panorama da release está em Protheus 12.1.2610: o que muda. As mudanças no estoque estão em 12.1.2610 no Estoque e Custos, e as da contabilidade em 12.1.2610 na Contabilidade e no Ativo.

Em resumo