Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

...

Produto:

Protheus

Versões:

A partir da 11.8

Ocorrência:

Explicativo sobre as condições de pagamentos no faturamento disponíveis no produto Protheus

Ambiente:

Todos

Índice

Índice
exclude.*ndice


Conceito

As condições de pagamento existem para estipular regras comerciais e prazos no momento da finalização da compra, seja ela um recebimento de empresas (compras) ou entrega (vendas). É possível vincular em casos da entrada de produtos (compra) pagamentos adiantados e no caso da saída de produtos (venda/faturamento) um recebimento adiantado.

Acréscimos, descontos, tipos, percentuais e algumas condições podem ser impostas no momento do cadastro da condição de pagamento, além do prazo/quantidade das parcelas da movimentação.



Considerações


Aviso
titleExceção de datas em pagamentos

As condições de pagamento possuem cadastro de datas somente por regra. Não é possível configurar para não cair em determinados dias ou determinar acréscimos ou decréscimos de acordo com a forma de pagamento.

Aviso
titleAlternar data de vencimento dependendo do dia do pagamento

No módulo financeiro [SE1 - Títulos à Receber] é feito um tratamento que pega o vencimento E1_VENCTO, que tem seu valor calculado pelo campo E1_EMISSAO e, ajusta o vencimento real do vencimento do título para o dia útil mais próximo e grava reajustado no campo “Vencto. Real - [E1_VENCREA]”


Por esse motivo não é possível configurar condições de pagamento de maneira que, se o início da contagem da condição de pagamento estiver entre dia "W" e dia "X", o vencimento da duplicata ocorre no dia "A" e caso o pagamento ocorra entre o dia "Y" e o dia "Z", que o vencimento da duplicata ocorra no dia "B".



Expandir
titleDia "31" dos meses e dias úteis

Os prazos de pagamento contam dias corridos, então, quando o mês possui 31 dias, ele será contado para definição do prazo final.

A condição não valida dias úteis para sua formação fixa, possui apenas realocação ao dia útil mais próximo no campo "Vencto. Real (E1_VENCREA)", caso o vencimento fixo (E1_VENCTO) caia em um dia não útil (sábado, domingo ou feriados).


No entanto, para Tipos em que são definidas datas específicas para pagamento (Tipos 3/7) se utilizar a data "31" como dia fixo e o pagamento for calculado para cair no dia 31, porém, cair em um mês que não possui o dia 31 no Calendário, então será considerado o dia 30 tendo como regra o conceito de Mês Comercial (o qual considera que o ano possui 360 dias e cada um dos meses 30 dias, indistintamente).


Expandir
titleSimulação da condição de pagamento e gravação real do campo com a condição de pagamento

A aba Duplicata apresenta as informações referentes à data de vencimento e valores das duplicatas que serão geradas no ambiente Financeiro após a preparação do documento de saída. A regra seguida pelo sistema para cálculos das datas de vencimento das duplicatas na Planilha do Pedido de Venda possui o seguinte comportamento:

  • Caso não seja preenchido o campo DATA DE ENTREGA (campo C6_ENTREG), os dias para o vencimento da duplicata serão contados a partir da emissão do pedidos de venda (campo C5_EMISSAO);
  • Caso a DATA DE ENTREGA (campo C6_ENTREG) seja preenchida e seja menor que a data de de emissão do Pedido de Venda (C5_EMISSAO), os dias para vencimento da duplicata serão contados a partir da DATA DA ENTREGA (campo C6_ENTREG).


Isso ocorre pois pedidos de venda podem ser emitidos mas não liberados/faturados imediatamente, ou seja, o faturamento é superior a data de emissão do pedido de vendas, então a simulação calcula a partir do campo C5_EMISSAO para uma melhor visualização.

O parâmetro MV_DIACONT é importante nesse processo de determinação do vencimento do título gerado. (Define se o início é pela data da emissão da nota fiscal ou no dia posterior).

  • Exemplos de utilização desse parâmetro no tópico "Parâmetros" dessa documentação.


Expandir
titleCópia do pedido de venda e data da entrega

Quando realizar a cópia de um pedido de vendas, considerar o parâmetro MV_TIPCPDT para ajustar o Preenchimento da "Data de Entrega [C6_ENTREG]".

  • Exemplos de utilização desse parâmetro no tópico "Parâmetros" dessa documentação.


Expandir
titleAntecipar/prorrogar dia do vencimento

Quando utilizada uma condição de pagamento que configura dias específicos (Tipos 3/4/6), se o pagamento for calculado para uma data que não está entre as datas válidas configuradas no [E4_COND], então o sistema sempre irá prorrogar este pagamento para o próximo dia configurado como válido, o pagamento não é antecipado.


Expandir
titleRecebimento Adiantado (RA)

TDN: http:/FAT0149 - Recebimento Antecipado (RA/Adiantamento) no Pedido de Venda (MATA410)


Em Pedidos de Venda é possível relacionar a Venda com um Recebimento antecipado, de modo a gerar o parcelamento do restante com base na configuração da condição de pagamento.


Expandir
titleQuantidade de parcelas

KCS: Cross Segmentos - TOTVS Backoffice (Linha Protheus) - SIGAFAT - Funcionamento do parâmetro MV_1DUP

Por padrão o Protheus permite a inserção de 35 Parcelas (0 à 9 - A à Z), porém é possível aumentar este número a partir das configurações:

  • Parâmetro MV_1DUP: Por padrão possui o conteúdo A, podendo ser alterado para até 3 dígitos (AAA ou 001);

  • Campo E1_PARCELA: Por padrão possui a informação 1 (um dígito), pelo grupo de campos "PARCELA" do configurador pode ser alterado para até 3 dígitos.


Expandir
titleTítulos de Devolução NDF (Nota Débito Fornecedor) / NCC (Nota Crédito Cliente) parcelados/datados conforme a condição de pagamento

KCS: Cross Segmentos - TOTVS Backoffice (Linha Protheus) - SIGAFAT - Devoluções de compras ao faturar geram título único do tipo "NDF"


Quando em uma compra/venda onde é negociado o pagamento em 4 vezes e por algum motivo qualquer ocorre a desistência da compra dentro do prazo de devolução. Nesse caso é emitido uma nota de devolução do produto, para desfazer essa compra/venda.


O sistema não parcela o título de devolução (apesar da condição de pagamento selecionada) e gera apenas um título, com a data em que a compra está sendo desfeita, com o mesmo intuito, que é desfazer o pagamento/recebimento (não ocorrerá mais visto que o produto fora devolvido).


Expandir
titleImpostos acumulados em parcelas

KCS sobre "E4_IPI": Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "IPI (N/J/S)" (E4_IPI)

KCS sobre "E4_SOLID": Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "ICM Solid." (E4_SOLID)


Em uma compra/venda e negociado pagamento em 4 vezes, por algum motivo qualquer ocorre a desistência da compra dentro do prazo de devolução e é emitida uma nota de devolução do produto, para desfazer essa compra/venda.
No caso, o sistema não parcela o título de devolução (apesar da condição de pagamento selecionada) e gera apenas um título, com a data em que a compra está sendo desfeita, com o mesmo intuito, que é desfazer o pagamento/recebimento (não ocorrerá mais visto que o produto fora devolvido).


Sempre que configurar a condição de pagamento para Separar os Impostos (E4_IPI e/ou E4_SOLID) deve-se acrescentar o primeiro dígito da Condição de Pagamento (E4_COND) exclusivo para a duplicata de impostos.


  • Caso a nota emitida separe os impostos calculados:
    Serão gerados na primeira parcela configurada na Condição de Pgto.
    Deste modo, se desejar ratear o valor da duplicata em 3x mas com E4_IPI e/ou E4_SOLID = Separa, então é necessário configurar 4 parcelas na Condição, pois a primeira será de uso exclusivo para os impostos caso existam.

  • Caso a nota emitida não separe os impostos calculados:
    A primeira parcela configurada na Condição de Pagamento será desconsiderada, desde que E4_IPI e/ou E4_SOLID = Separa.


  • Campo IPI "E4_IPI" (N/J/S).

      N - Normal - O valor do IPI será cobrado/distribuído entre as "n" parcelas;

      J - Junta - O valor do IPI será cobrado integral na 1ª parcela;

      S - Separado - O valor do IPI será cobrado em um título à parte.

Complemento:

       Para que de fato a opção junta seja efetivada o campo ICM Solid. (E4_SOLID) deve estar preenchido com o Valor J (Junta) ou N (Normal), somente assim o valor do IPI será             somado ao valor da primeira parcela.


OBS: Para que o valor seja demonstrado corretamente no rateio entre as parcelas, a funcionalidade "Simulação" da rotina Cadastro de Condição de Pagamento [MATA360], o campo "Valor de Referência" deve compor o montante com os impostos, apesar de mencionar o valor específico dos impostos nos campos "Valor do IPI" e "Valor do ICMS Solidário".


Para reter PIS COFINS CSLL somente na primeira parcela da Nota Fiscal de Entrada, pode ser obtido através dos parâmetros:

  • MV_RATPIS

  • MV_RATCOF

  • MV_RATCSLL


Detalhes em: Condição de Pagamento_Retenção_de_PIS_COFINS_CSLL somente na primeira parcela da Nota Fiscal de Entrada

  • Dúvidas sobre retenção PIS/COFINS/CSLL na nota fiscal de entrada contate a Equipe Compras / GCP / GCT [SIGACOM].




Rateio das Despesas acessórias entre as parcelas

O valor das despesas acessórias (frete/seguro/despesas) compõem a base de cálculo e assim, por padrão, são somadas ao valor das mercadorias para rateio (divisão) entre as parcelas.
O valor das despesas acessórias não é gerado em título(s) a parte ou apenas na primeira parcela (como ocorre com impostos).





Tipos de Condição de Pagamento

Configurado pelo campo “Tipo* [E4_TIPO]” na rotina MATA360.


Deck of Cards
startHiddenfalse
effectDuration0.5
idCusto Médio
effectTypehorizontal
loopCardstrue
Card
defaulttrue
idCusto Médio
labelTIPO 1

Tipo 1:

Conector de Widget
urlhttps://www.youtube.com/watch?v=eLVsaIXSNCo&t=5s&ab_channel=TOTVSSoluções


Documentação KCS sobre a Condição de Pagamento Tipo 1:
https://centraldeatendimento.totvs.com/hc/pt-br/articles/14178272061463-Cross-Segmentos-TOTVS-Backoffice-Linha-Protheus-SIGAFAT-Faturamento-Criação-da-condição-de-pagamento-Tipo-1


Recomendado para condições de complexidade baixa;

É possível determinar a distância dos vencimentos entre as parcelas tendo como base a emissão do documento de saída.



Cadastrando:

  • E4_CODIGO = (critério do usuário)

  • E4_TIPO = 1

  • E4_COND = 00,30,60



OBS: Atente-se à configuração do parâmetro MV_DIACONT sendo 1 = Conta o dia atual ou 2 = Conta a partir do dia seguinte

  • Exemplos de utilização desse parâmetro no tópico "Parâmetros" dessa documentação.


GIF Exemplo do resultado da simulação utilizando a condição de pagamento acima (Tipo 1 - E4_TIPO = “1”):


Card
defaulttrue
idCusto Médio
labelTIPO 2

Tipo 2:

Conector de Widget
urlhttps://www.youtube.com/watch?v=Gjvx9kKxmf0&ab_channel=TOTVSSoluções


Documentação KCS sobre a Condição de Pagamento Tipo 2:
https://centraldeatendimento.totvs.com/hc/pt-br/articles/14191561177879-Cross-Segmentos-TOTVS-Backoffice-Linha-Protheus-SIGAFAT-Faturamento-Criação-da-condição-de-pagamento-Tipo-2


Recomendado para condições de pagamento de complexidade baixa;

Representa o tempo até o vencimento (com um multiplicador), o números das parcelas e o intervalo entre elas também com um multiplicador.



Cadastrando:

  • E4_CODIGO = 341 (Não é livre para escolha do usuário pois faz parte da composição da regra de condições de pagamento Tipo 2)

  • E4_TIPO = 2

  • E4_COND = 7 (nesse exemplo, o multiplicador tem valor 7)



GIF Exemplo do resultado da simulação utilizando a condição de pagamento acima (Tipo 2 - E4_TIPO = “2”).


Card
defaulttrue
idCusto Médio
labelTIPO 3

Tipo 3:

Conector de Widget
urlhttps://www.youtube.com/watch?v=o_Bm6xraczg&t=12s&ab_channel=TOTVSSoluções


Documentação KCS sobre a Condição de Pagamento Tipo 3:
https://centraldeatendimento.totvs.com/hc/pt-br/articles/14307548200215-Cross-Segmentos-TOTVS-Backoffice-Linha-Protheus-SIGAFAT-Faturamento-Criação-da-condição-de-pagamento-Tipo-3


Recomendado para condições de complexidade média;

Determina-se os dias até o primeiro vencimento, a quantidade de parcelas e os dias exatos de vencimento. (para o sistema ajustar para os dias colocados)



Cadastrando:

  • E4_CODIGO = (critério do usuário)

  • E4_TIPO = 3

  • E4_COND = 3,42,7,14,21,28



GIF Exemplo do resultado da simulação utilizando a condição de pagamento acima (Tipo 3 - E4_TIPO = “3”).


Card
defaulttrue
idCusto Médio
labelTIPO 4

Tipo 4:

Conector de Widget
urlhttps://www.youtube.com/watch?v=dPIaCPcL-aU&t=5s&ab_channel=TOTVSSoluções


Recomendado para condições de pagamento com média complexidade;

Declara-se a quantidade de parcelas, o intervalo entre estas e o dia da semana padrão de vencimento.



d(S) são os dias de semana, assume-se:

1 - Domingo

2 - Segunda-Feira

3 - Terça-Feira

4 - Quarta-Feira

5 - Quinta-Feira

6 - Sexta-Feira

7 - Sábado


OBS: O sistema não retrocede a data para a semana vigente ao vencimento. Quando por intervalo de parcelas O vencimento cair na Quarta-Feira, a mesma semana o sistema levará a regra como vencimento para a Terça-Feira da semana seguinte.



Exemplo:

Emissão 28/06/22 + 30 DDL
Vencimento cairia para o dia 27/07 (Quarta-Feira), como a regra no pagamento é toda Terça-Feira , o vencimento correto será dia 02/08/22 (terça-feira da próxima semana), então o sistema reajusta, se utilizar essa condição de pagamento.


Cadastrando:

  • E4_CODIGO = (critério do usuário)

  • E4_TIPO = 4

  • E4_COND = 4,30,3 (Terça-Feira)



Resultado:

Os pagamentos serão efetuados da seguinte forma:


• 1ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.• 2ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.

• 3ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.

• 4ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.


GIF Exemplo do resultado da simulação utilizando a condição de pagamento acima (Tipo 4 - E4_TIPO = “4”).


Card
defaulttrue
idCusto Médio
labelTIPO 5

Tipo 5:

Conector de Widget
urlhttp://youtube.com/watch?v=_NoztCn6f7w


Recomendado para condições de complexidade baixa;

Determina-se os dias até o primeiro vencimento, a quantidade de parcelas e a carência entre elas.



Cadastrando:

  • E4_CODIGO = (critério do usuário)

  • E4_TIPO = 5

  • E4_COND = 30,4,30



Resultado:

Os pagamentos serão efetuados da seguinte forma:


• 1ª parcela paga 30 dias após a emissão do documento de saída.

• 2ª parcela paga 30 dias após o vencimento da parcela anterior.

• 3ª parcela paga 30 dias após o vencimento da parcela anterior.

• 4ª parcela paga 30 dias após o vencimento da parcela anterior.



GIF Exemplo do resultado da simulação utilizando uma condição de pagamento Tipo 5 (Tipo 5 - E4_TIPO = “5”).


Card
defaulttrue
idCusto Médio
labelTIPO 6

Tipo 6:

Conector de Widget
urlhttp://youtube.com/watch?v=MHQ5TijxyGk


Recomendado para condições de complexidade alta;

Determina-se a quantidade de parcelas, o tempo em dias) até o início dos pagamentos, o dia da semana que o vencimento pode cair e a carência entre os vencimentos das parcelas (duplicatas).



d(S) são os dias de semana, assume-se:

1 - Domingo

2 - Segunda-Feira

3 - Terça-Feira

4 - Quarta-Feira

5 - Quinta-Feira

6 - Sexta-Feira

7 - Sábado


Cadastrando:

  • E4_CODIGO = (critério do usuário)

  • E4_TIPO = 6

  • E4_COND = 6,15,4 (Quarta-Feira),30



Resultado:

Os pagamentos serão efetuados da seguinte forma:


• 1ª parcela paga 15 dias após a emissão, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.

• 2ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.

• 3ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.

• 4ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.

• 5ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.

• 6ª parcela será paga após o vencimento da duplicata após os 30 dias de intervalo, a parcela será paga no reajuste para o dia da semana mais próximo (configurado) para cair.


GIF Exemplo do resultado da simulação utilizando a condição de pagamento acima (Tipo 6 - E4_TIPO = “6").


Card
defaulttrue
idCusto Médio
labelTIPO 7

Tipo 7:

Conector de Widget
urlhttp://youtube.com/watch?v=jWQjCBummWQ


Recomendado para condições de complexidade muito alta;

O primeiro algarismo simboliza a quantidade de parcelas, seguido dos dias do mês de cada mês que as parcelas cairão.


Somente um dia fixo no ano (independente da emissão)
Exemplo: Vencimento no dia 10/07

Criar uma condição de pagamento Tipo = 7 e Condição: 1,0,0,0,0,0,0,10,0,0,0,0,0 , onde o primeiro digito corresponde ao numero de parcelas e depois cada zero como corresponde a um mês do ano.

No sétimo zero foi inserido o dia do vencimento. Ao incluir uma nota na data de hoje, o vencimento ficará para 10/07.



Cadastrando:

  • E4_CODIGO = (critério do usuário)

  • E4_TIPO = 7

  • E4_COND = 03,05,10,15,20,25,30,05,10,15,20,25,30



Resultado:

Supondo que a emissão da nota fiscal de saída da compra foi emitida dia 01/01. Os pagamentos serão efetuados da seguinte forma:

• 1ª parcela paga dia 5 de janeiro.

• 2ª parcela paga dia 10 de fevereiro.

• 3ª parcela paga dia 15 de março.


OBS: O sistema não retrocede o mês para cálculo do vencimento.

Exemplo:

Se a Emissão: 10/01/22

O primeiro vencimento (janeiro) seria no dia 5 de janeiro, como foi emitido a nota fiscal em uma data superior a da primeira parcela, ele não retrocede e sim avança para a próxima, que é dia 10 de fevereiro.


GIF Exemplo do resultado da simulação utilizando a condição de pagamento acima (Tipo 7 - E4_TIPO = “7”).


Card
defaulttrue
idCusto Médio
labelTIPO 8

Tipo 8:

Conector de Widget
urlhttp://youtube.com/watch?v=UqeP6QTaFVs


Recomendado para condições de complexidade muito alta;

Determinado com dois blocos númericos. O primeiro determina a distância de dias para o vencimento das duplicatas (a partir da emissão da nota fiscal, assim como a condição de pagamento do Tipo 1). O segundo determina a porcentagem de pagamento em relação ao total das duplicatas a ser paga nas respectivas parcelas.



Os blocos devem ser separados por []:

  • Primeiro bloco: Vencimento das duplicatas (similar ao da condição de pagamento Tipo 1).

  • Segundo bloco: Percentuais acumulados (concentrados) em cada duplicata respectiva que está no primeiro bloco.


Atenção:

O segundo bloco de números deve possuir em sua soma 100% e deve ter a quantidade de números igual a quantidade de parcelas (do primeiro bloco)


Porcentagem decimal:

Caso o número da porcentagem seja “quebrado”, por exemplo a porcentagem “Quinze e meio por cento” deve ser representada como “15.5” (com ponto e não vírgula) e separada por vírgulas para que não afete a contagem das demais parcelas e porcentagens.


Cadastrando:

  • E4_CODIGO = (critério do usuário)

  • E4_TIPO = 8

  • E4_COND = [30,60,90],[50,22.5,22.5]



Resultado:

Supondo que o total das parcelas seja R$1000,00. Os pagamentos serão efetuados da seguinte forma:

• 1ª parcela 30 dias após a emissão com valor de R$550, que é 55% do valor total.

• 2ª parcela 60 dias após a emissão com valor de R$225, que é 22,5% do valor total.

• 3ª parcela 90 dias após a emissão com valor de R$225, que é 25,5% do valor total.


GIF Exemplo do resultado da simulação utilizando a condição de pagamento acima (Tipo 8 - E4_TIPO = “8”).


Card
defaulttrue
idCusto Médio
labelTIPO 9

Tipo 9:

Conector de Widget
urlhttp://youtube.com/watch?v=GYwJkZ0PN70


Recomendado para condições da mais extrema complexidade;

Determina-se manualmente no pedido de vendas (Rotina MATA410 - Tabela SC5), a data das parcelas e os valores das parcelas.


Caso nenhum dos Tipos de Condição disponíveis atenda plenamente a particularidade de sua necessidade, pode-se utilizar a Condição de Pagamento Tipo 9, que é usada quando não há um tipo que automatize a especificidade da regra do cliente.
Detalhes abaixo e no link: Condição_de_Pagto_Tipo_9

O cadastro é feito na rotina Condições de Pagamento - [Rotina MATA360 - Tabela SE4], mas a configuração dos valores das parcelas e data de vencimento das parcelas é informada na rotina Pedidos de Vendas - [Rotina MATA410 - Tabela SC5] ou Orçamentos de Vendas - [Rotina MATA415 - Tabela SCJ].


Há dois tipos de uso sobre a Condição de Pagamento Tipo 9, o modo por percentual e o modo por valor fixo.

  • Valor Fixo (E4_COND = 0): O valor das parcelas é determinado inteiramente.

  • Valor Percentual (E4_COND = %): O valor das parcelas é determinado em porcentagens em relação ao total das parcelas.


Exemplo de Cadastro - Condição de Pagamento Tipo 9 - Valor Fixo

  • E4_CODIGO = 001

  • E4_TIPO = 9

  • → E4_COND = 0 (Valor fixo)

  • E4_DESCRI = “TIPO 9 VALOR FIXO”


Exemplo de Cadastro - Condição de Pagamento Tipo 9 - Valor Fixo

  • E4_CODIGO = 002

  • E4_TIPO = 9

  • → E4_COND = % (Valor em percentual)

  • E4_DESCRI = “TIPO 9 PERCENTUAL”




Exemplo de Uso da condição “001” que é Tipo 9 e tem o valor fixo:


Pedido 1:

“Pedido de Vendas” - C5_NUM: 000001
“Condição de Pagamento” - C5_COND: 001

“Parcela 1” - C5_PARC1 = 100
“Parcela 2” - C5_PARC2 = 300
“Parcela 3” - C5_PARC3 = 300
“Parcela 4” - C5_PARC4 = 300

“Vencimento 1” - C5_DATA1 = 25/03/2022
“Vencimento 2” - C5_DATA1 = 20/04/2022
“Vencimento 3” - C5_DATA1 = 05/05/2022
“Vencimento 4” - C5_DATA1 = 10/06/2022


Valor Total do Pedido R$ 1.000,00 (Total de todos os itens [C6_VALOR])


Resultado do Pedido 1:

• Parcela 1: 100,00 e vencimento 25/03/2022
• Parcela 2: 300,00 e vencimento 20/04/2022
• Parcela 3: 300,00 e vencimento 05/05/2022
• Parcela 4: 300,00 e vencimento 10/06/2022




Exemplo de Uso da condição “002” que é Tipo 9 e tem valor em percentual:


Pedido 2:

“Pedido de Vendas” - C5_NUM: 000002
“Condição de Pagamento” - C5_COND: 002

“Parcela 1” - C5_PARC1 = 10
“Parcela 2” - C5_PARC2 = 30
“Parcela 3” - C5_PARC3 = 30
“Parcela 4” - C5_PARC4 = 30

“Vencimento 1” - C5_DATA1 = 25/03/2022
“Vencimento 2” - C5_DATA1 = 20/04/2022
“Vencimento 3” - C5_DATA1 = 05/05/2022
“Vencimento 4” - C5_DATA1 = 10/06/2022


Valor Total do Pedido R$ 1.000,00 (Total de todos os itens [C6_VALOR])


Resultado do Pedido 2:

• Parcela 1: 10% sobre o total do pedido (R$100,00) e vencimento 25/03/2022
• Parcela 2: 30% sobre o total do pedido (R$ 300,00) e vencimento 20/04/2022
• Parcela 3: 30% sobre o total do pedido (R$ 300,00) e vencimento 05/05/2022
• Parcela 4: 30% sobre o total do pedido (R$ 300,00) e vencimento 10/06/2022



Cada duplicata tem seu valor colocado em um campo (C5_PARC1/2/3/4 ou CJ_PARC1/2/3/4) e seu respectivo vencimento colocado em outro campo (C5_DATA1/2/3/4 ou CJ_DATA1/2/3/4) manualmente na tela das rotinas Pedidos de Venda e Orçamentos de Venda.

A quantidade de parcelas usadas em condição de pagamento do tipo 9 depende do parâmetro MV_NUMPARC.
Por padrão são 4 parcelas (MV_NUMPARC = 4). (totalizando 8 campos, pois cada campo de valor tem seu respectivo campo de vencimento).

  • Exemplos de utilização desse parâmetro no tópico "Parâmetros" dessa documentação.


OBS 1: Cada duplicata deve ter um valor (C5_PARCx) e data de vencimento (C5_DATAx) correspondente no pedido de vendas.

OBS 2: Cada projeção de orçamento deve ter um valor (CJ_PARCx) e data de vencimento (CJ_DATAx) correspondente no orçamento de vendas.


Exemplo:

Duplicata 1/Parcela 1 (Primeira parcela com o valor de R$200 com seu respectivo vencimento dia 01/05/2022)

  • “Parcela 1” C5_PARC1 = 200,00 e “Vencimento 1” C5_DATA1 = 01/05/2022 (no pedido de venda)

  • “Parcela 1” CJ_PARC1 = 200,00 e “Vencimento 1” CJ_DATA1 = 01/05/2022 (no orçamento de venda)


Duplicata 2/Parcela 2 (Segunda parcela com o valor de R$400,08 com seu respectivo vencimento dia 02/05/2022)

  • “Parcela 2” C5_PARC2 = 400,08 e “Vencimento 2” C5_DATA2 = 02/05/2022 (no pedido de venda)

  • “Parcela 2” CJ_PARC2 = 400,08 e “Vencimento 2” CJ_DATA2 = 02/05/2022 (no orçamento de venda)


Duplicata 3/Parcela 3 (Terceira parcela com o valor de R$777,77 com seu respectivo vencimento dia 16/07/2022)

  • “Parcela 3” C5_PARC3 = 777,77 e “Vencimento 3” C5_DATA3 = 16/07/2022 (no pedido de venda)

  • “Parcela 3" CJ_PARC3 = 777,77 e “Vencimento 3” CJ_DATA3 = 16/07/2022 (no orçamento de venda)


Duplicata 4/Parcela 4 (Quarta parcela com o valor de R$1234,56 com seu respectivo vencimento dia 28/09/2022)

  • “Parcela 4” C5_PARC4 = 1234,56 e “Vencimento 4” C5_DATA4 = 28/09/2022 (no pedido de venda)

  • “Parcela 4” CJ_PARC4 = 1234,56 e “Vencimento 4” CJ_DATA4 = 28/09/2022 (no orçamento de venda)




Aumentar quantidade de parcelas na condição de pagamento Tipo 9

Caso seja necessitado mais que 4 parcelas, deve-se fazer 3 processos para utilizar mais duplicatas no pedido de vendas:


Exemplo: Necessidade de ter 5 parcelas com a Condição de Pagamento Tipo 9:

1 - Criar os campos respectivos com estrutura igual aos nativos (C5_PARC1/2/3/4 e C5_DATA1/2/3/4 por exemplo) na tabela SC5 para os pedidos de venda.

  • C5_PARC5

  • C5_DATA5


2 - Criar os campos respectivos com estrutura igual aos nativos (CJ_PARC1/2/3/4 e CJ_DATA1/2/3/4 por exemplo) na tabela SCJ para os orçamentos de venda.

  • CJ_PARC5

  • CJ_DATA5


3 - Alterar o parâmetro de quantidade de parcelas

  • MV_NUMPARC = 5


OBSERVAÇÕES:

  • Em caso de aumento de parcelas, necessariamente a quantidades de parcelas no pedido de venda (SC5) deve ser igual a quantidade de parcelas no orçamento de venda (SCJ), mesmo que a empresa não utilize, por exemplo, os orçamentos de venda como regra de negócio/processo.
    Caso seja criado campos de “C5_PARCn e C5_DATAn” para mais duplicatas no pedido de venda e não sejam criadas respectivos campos para as mesmas duplicatas no orçamento de vendas (“CJ_PARCn” e ”CJ_DATAn”) o sistema apresentará inconsistências.

  • O parâmetro MV_NUMPARC deve ser igual o valor da quantidade das parcelas possíveis criadas para a Condição de Pagamento Tipo 9, caso contrário o sistema apresentará inconsistências.


Exemplo 1 (Protheus padrão):

  • C5_PARC1/2/3/4

  • CJ_PARC1/2/3/4

  • C5_DATA1/2/3/4

  • CJ_DATA1/2/3/4

  • MV_NUMPARC = 4

Não ocorre inconsistências e/ou HELPS.


Exemplo 2 (Em casos de aumento de parcelas, no exemplo foi criado campos para suportar 9 parcelas):

  • C5_PARC1/2/3/4/5/6/7/8/9

  • CJ_PARC1/2/3/4/5/6/7/8/9

  • C5_DATA1/2/3/4/5/6/7/8/9

  • CJ_DATA1/2/3/4/5/6/7/8/9

  • MV_NUMPARC = 4

Ocorre inconsistências e/ou HELPS pois o parâmetro não está: MV_NUMPARC = 9, que é a quantidade total das parcelas.


Card
defaulttrue
idCusto Médio
labelTIPO A

A Condição de Pagamento Tipo A não é utilizada no Faturamento - SIGAFAT.

Para informações e exemplos de uso, contate os módulos SIGAVEI - Veículos e SIGAOFI - Oficinas.


Card
defaulttrue
idCusto Médio
labelTIPO B

Tipo B:

Conector de Widget
urlhttp://youtube.com/watch?v=hrgiEgt3E7I


É possível combinar as condições de pagamento em uma só (Exceto as do Tipo 9/A/B).
Para isso é utilizado o item da rotina e configurado para cada uma seu tipo e a participação para compor o total da condição de pagamento única (rateio), para isso é utilizada a “Tabela SEC - Desmembramento de Condições de Pagamento”.


Na janela de inclusão de condição de pagamento, a área superior apresenta os campos para definição dos tipos das condições de pagamento já existentes; a área inferior, apresenta linhas para definição dos itens quando a Condição de Pagamento for Tipo B (E4_TIPO = B), neste caso, somente os campos definidos nos itens serão considerados para o cálculo dos vencimentos das duplicatas.




Cadastrando (misturando uma condição de pagamento do Tipo 1 e uma Tipo 5):

Data da emissão fiscal de saída (ou simulação), gerada por um pedido de venda no dia 01/01/2022:

  • E4_CODIGO = (critério do usuário)

  • E4_TIPO = B

  • E4_COND = 0 (o sistema desconsidera esta informação, pois trata-se do tipo B, esse campo é obrigatório, deve-se digitar qualquer valor)

  • E4_DESCRI = (critério do usuário)


Linha 1:

  • EC_ITEM = 01

  • EC_TIPO = 1

  • EC_COND = 00,30,90 (3 parcelas nesta linha)

  • EC_RATEIO = 60


Linha 2:

  • EC_ITEM = 02

  • EC_TIPO = 5

  • EC_COND = 30,3,30 (3 parcelas nesta linha)

  • EC_RATEIO = 40


Valor total de um pedido de vendas = R$1000,00 (para o exemplo de resultado à seguir:


Resultado:

Parcela 1: Valor da parcela R$200 - Data de vencimento da parcela: 01/01/2022

Parcela 2: Valor da parcela R$200 - Data de vencimento da parcela: 31/01/2022

Parcela 3: Valor da parcela R$200 - Data de vencimento da parcela: 01/04/2022

Parcela 4: Valor da parcela R$133,33 - Data de vencimento da parcela: 01/05/2022

Parcela 5: Valor da parcela R$133,33 - Data de vencimento da parcela: 31/01/2022

Parcela 6: Valor da parcela R$133,34- Data de vencimento da parcela: 30/06/2022




O campo Rateio “EC_RATEIO” é responsável por determinar a porcentagem em relação ao total das parcelas que será acumulada naquela condição de pagamento. A soma dos campos “EC_RATEIO” deve resultar em 100 (100% do valor assimilado).

No exemplo acima, na linha 1, há a Condição de Pagamento Tipo 1 e, nela será concentrado 60% do valor (R$600) para ser distribuida conforme sua regra. Na linha 2, há a Condição de Pagamento Tipo 5 e, nela será concentrado 40% do valor (R$400) para ser distribuida conforme sua regra.


MV_AGLDUPB - Parâmetro que define se quando existirem duplicatas com a mesma data de vencimento, estas deverão ser aglutinadas.

MV_DATDUPB - Parâmetro que indica se para o cálculo dos vencimentos, será aplicada a data do último título gerado como referência para a próxima condição (1=Atualiza) ou será utilizada sempre a data inicial (2-Inicial).

  • Exemplos de utilização desse parâmetro no tópico "Parâmetros" dessa documentação.




GIF Exemplo do resultado da simulação utilizando a condição de pagamento acima (Tipo B - E4_TIPO = “B”).


Card
defaulttrue
idCusto Médio
labelOutros

Caso nenhum dos Tipos de Condição disponíveis atenda plenamente a particularidade de sua necessidade, pode-se utilizar a Condição de Pagamento Tipo 9, que é usada quando não há um tipo que automatize a especificidade da regra do cliente.




Forma de pagamento 90 - Sem pagamento:

Por padrão, para que seja levada as formas de pagamento no XML é necessário que o campo esteja preenchido Forma Pgto. E4_FORMA.


Boletim da Issue: 10808039 DSERTSS1-16359 DT TAG indpag em branco para UF SE quando for Sem pagamento

KCS: Cross Segmentos - Backoffice Protheus - Doc. Eletrônicos - Como gerar a forma de pagamento 90 - Sem pagamento




Caminho, Campos e Tabelas

Deck of Cards
startHiddenfalse
effectDuration0.5
idOCORRÊNCIAS
effectTypehorizontal
loopCardstrue
Card
defaulttrue
idCusto Médio
labelCaminho

Caminho: Ambiente Faturamento (SIGAFAT) [05] → Atualizações → Cadastros → Condições de Pagamento [MATA360]


Card
defaulttrue
idCusto Médio
labelCampos do Cabeçalho (SE4)
Expandir
titleE4_FILIAL - “Filial” (nativamente obrigatório)

Grava a filial posicionada que você está inserido ao cadastrar a condição de pagamento.


Expandir
titleSaiba como o campo E4_FILIAL é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo E4_FILIAL




Expandir
titleE4_CODIGO - “Codigo” (nativamente obrigatório)

Código ID da condição de pagamento.


Expandir
titleSaiba como o campo E4_CODIGO é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "Código [E4_CODIGO]"





Expandir
titleE4_TIPO - “Tipo” (nativamente obrigatório)

Código que determina o tipo da condição de pagamento (1/2/3/4/5/6/7/8/9/A/B).


Expandir
titleSaiba como o campo E4_TIPO é alimentado e com quais parâmetros interage com exemplos:


KCS 3: Saiba como o campo E4_TIPO é alimentado e com quais parâmetros interage com exemplos:




Expandir
titleE4_COND - “Cond. Pagto” (nativamente obrigatório)

Regra a ser imposta nas duplicatas, tem de estar de acordo com o tipo cadastrado anteriormente [E4_TIPO].


Expandir
titleSaiba como o campo E4_COND é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "Cond. Pagto (E4_COND)"




Expandir
titleE4_DESCRI (nativamente obrigatório)

Campo para identificação da condição de pagamento pelo usuário.


Expandir
titleSaiba como o campo E4_DESCRI é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "Descricao (E4_DESCRI)"




Expandir
titleE4_IPI - “IPI (N/J/S)”

Define se o valor do IPI deve ser distríbuido entre as demais parcelas, se será cobrado na primeira parcela ou se será cobrado em um título gerado a parte.


Expandir
titleSaiba como o campo E4_IPI é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "IPI (N/J/S)" (E4_IPI)




Expandir
titleE4_DDD - “Dias da Cond”

Campo para impor regras sobre como será o início da contagem das datas dos vencimentos da parcela.


Expandir
titleSaiba como o campo E4_DDD é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmento - TOTVS Backoffice (Linha Protheus) - Condição de Pagamento "Dias da Cond E4_DDD - Fora o Dia"




Expandir
titleE4_DIADESC - “Dias p/Desc.”

Até quantos dias a partir da emissão do título haverá descontos ao realizar a baixa deste (pagar).


Expandir
titleSaiba como o campo E4_DIADESC é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento dos campos "Desc.Financ." (E4_DESCFIN) e "Dias p/Desc." (E4_DIADESC)




Expandir
titleE4_MSBLQL = “Status”

Campo de status do registro. Toda tabela tem. Determina se este registro/cadastro/array está ativo ou desativo.


Expandir
titleSaiba como o campo E4_MSBLQL é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "Status" (E4_MSBLQL)




Expandir
titleE4_DESCFIN - “Desc.Financ.”

Desconto que é levado para a nota fiscal ao utilizar a condição de pagamento no pedido de venda. Não é mostrado o desconto no pedido de venda, é concedido apenas na baixa do título.


Expandir
titleSaiba como o campo E4_DESCFIN é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento dos campos "Desc.Financ." (E4_DESCFIN) e "Dias p/Desc." (E4_DIADESC)




Expandir
titleE4_FORMA - “Forma Pgto”

Campo informativo de como será a forma de pagamento.


Para mais informações sobre o campo, contate a equipe especialista do SIGALOJA (Automação Comercial).





Expandir
titleE4_ACRSFIN - “% Acres.Fin.”

Campo destinado a determinar o acréscimo financeiro por porcentagem, aparece só em simulações na planilha financeira e é aplicado na geração da nota fiscal de saída.


Expandir
titleSaiba como o campo E4_ACRSFIN é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "% Acres.Fin." (E4_ACRSFIN)




Expandir
titleE4_SOLID - “ICM Solid.”

Campo destinado a determinar o imposto “ICMS Solidário”


Expandir
titleSaiba como o campo E4_SOLID é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "ICM Solid." (E4_SOLID)




Expandir
titleE4_ACRES - “Acres. Financ”

Campo destinado a determinar o acréscimo financeiro

Expandir
titleSaiba como o campo E4_ACRES é alimentado e com quais parâmetros interage com exemplos:


TDN: Campo E4_ACRES - Acréscimo Financeiro (MATA360 - SIGAFAT)




Expandir
titleE4_PERCOM - “% Comissao”

Percentual de comissão ao vendedor ao gerar documento de saída com a condição de pagamento.


Para mais informações sobre o campo, contate a equipe do SIGATMS (Gestão de Transportes).




Expandir
titleE4_SUPER - “Lim.Superior”

Valor máximo de venda utilizado para a condição de pagamento.


Expandir
titleSaiba como o campo E4_SUPER é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "Lim.Superior" (E4_SUPER)




Expandir
titleE4_INFER - “Lim.Inferior”

Valor mínimo de venda utilizado para a condição de pagamento.


Expandir
titleSaiba como o campo E4_INFER é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos – TOTVS Backoffice (Linha Protheus) – SIGAFAT – Preenchimento do campo "Lim. Inferior" (E4_INFER)




Expandir
titleE4_FATOR - “Fator Multip”

Valor mínimo de venda utilizado para a condição de pagamento.


Campo não utilizado (informativo exclusivo na rotina).




Expandir
titleE4_PLANO - “Plano”

Plano do Infocard.


Para mais informações sobre o campo, contate a equipe do SIGALOJA (Automação Comercial).




Expandir
titleE4_JURCART - “Juros Cartao”

Juros do cartão por conta informada, campo informativo no Faturamento (SIGAFAT).


Para mais informações sobre o campo, contate a equipe do SIGALOJA (Automação Comercial).




Expandir
titleE4_CTRADT - “Adiantamento”

Informa se a condição de pagamento permitirá recebimento adiantado.


Expandir
titleSaiba como o campo E4_CTRADT é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos - TOTVS Backoffice (Linha Protheus) - SIGAFAT - Preenchimento do campo "Adiantamento" (E4_CTRADT)




Expandir
titleE4_AGRACRS - “Agrega Acrs.”

Esse campo indicava no módulo SIGALOJA se agregava ou não o acréscimo financeiro no valor das parcelas da venda. Caso negativo, era considerado o acréscimo somente no título e não será incluído o valor no documento fiscal.


Campo descontinuado.




Expandir
titleE4_LIMACRS - “Lim. Dias Pg”

Indica o prazo limite de dias para pagamento a vista de todas as parcelas do título. A verificação é feita com a Database “DDATABASE” do sistema e o vencimento da primeira parcela.


Para mais informações sobre o campo, contate a equipe do SIGALOJA (Automação Comercial).




Expandir
titleE4_CCORREN - “Con Corrente”

Indica se usará dados da conta corrente.


Para mais informações sobre o campo, contate a equipe do SIGALOJA (Automação Comercial).




Expandir
titleE4_TPAY - “TOTVS Mais Negócio”

Indica se usará dados da conta corrente.


Indica se a condição de pagamento será integrada pelo TOTVS Mais Negócios (Integração Colaboração).
Card
defaulttrue
idCusto Médio
labelCampos dos Itens (SEC)

Campos da SEC (Usados apenas se E4_TIPO = B)


Expandir
titleEC_FILIAL - “Filial” (nativamente obrigatório e oculto)

Grava a filial posicionada que você está inserido ao cadastrar a condição de pagamento.


Expandir
titleSaiba como o campo EC_FILIAL é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos – TOTVS Backoffice (Linha Protheus) – Faturamento (SIGAFAT) – Preenchimento do campo "Filial" (EC_FILIAL)







Expandir
titleEC_CODIGO - “Codigo” (nativamente obrigatório e oculto)

Código ID da condição de pagamento desmembrada. Esse campo não é usado pois as condições de pagamento do item são vínculadas ao ID código da condição de pagamento do cabeçalho (E4_CODIGO).





Expandir
titleEC_ITEM - “Item” (nativamente obrigatório)

Posição na linha dentre as demais condições se existirem.

Expandir
titleSaiba como o campo EC_ITEM é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos – TOTVS Backoffice (Linha Protheus) – Faturamento (SIGAFAT) – Preenchimento do campo "Item" (EC_ITEM)




Expandir
titleEC_TIPO - “Tipo” (nativamente obrigatório)

Código que determina o tipo da linha desmembrada (1/2/3/4/5/6/7/8). Em condições do Tipo B, as condições 9/A/B não são permitidas.


Expandir
titleSaiba como o campo EC_TIPO é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos – TOTVS Backoffice (Linha Protheus) – Faturamento (SIGAFAT) – Preenchimento do campo "Tipo" (EC_TIPO)




Expandir
titleEC_COND - “Cond. Pagto” (nativamente obrigatório)

Regra a ser imposta nas duplicatas, tem de estar de acordo com o tipo cadastrado anteriormente [EC_TIPO].


Expandir
titleSaiba como o campo EC_COND é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos – TOTVS Backoffice (Linha Protheus) – Faturamento (SIGAFAT) – Preenchimento do campo "Cond. Pagto" (EC_COND)




Expandir
titleEC_IPI - “Ipi (N/J/S)”

Define se o valor do IPI deve ser distríbuido entre as demais parcelas, se será cobrado na primeira parcela ou se será cobrado em um título gerado a parte.


Expandir
titleSaiba como o campo EC_IPI é alimentado e com quais parâmetros interage com exemplos:


KCS: Cross Segmentos – TOTVS Backoffice (Linha Protheus) – Faturamento (SIGAFAT) – Nota sobre o campo EC_IPI




Expandir
titleEC_DDD - “Dias da Cond”

Campo para impor regras sobre como será o início da contagem das datas dos vencimentos da parcela.


Expandir
titleSaiba como o campo EC_DDD é alimentado e com quais parâmetros interage com exemplos.


Mesmo comportamento do campo E4_DDD.




Expandir
titleEC_SOLID - “ICM Solid.”

Campo destinado a determinar o imposto “ICMS Solidário”


Expandir
titleSaiba como o campo EC_SOLID é alimentado e com quais parâmetros interage com exemplos.


KCS: Cross Segmento - Backoffice (Linha Protheus) – Faturamento (SIGAFAT) – Nota sobre o campo EC_SOLID




Expandir
titleEC_RATEIO - “% Rateio” (nativamente obrigatório)

Participação de cada condição de pagamento colocada na linha. O total de todas as linhas deve ser 100%.


Expandir
titleSaiba como o campo EC_RATEIO é alimentado e com quais parâmetros interage diretamente com exemplos.


KCS: Cross Segmentos – TOTVS Backoffice (Linha Protheus) – Faturamento (SIGAFAT) – Preenchimento do campo "% Rateio" (EC_RATEIO)




Card
defaulttrue
idCusto Médio
labelTabelas

Tabelas da Condição de Pagamento (no Faturamento - SIGAFAT):

  • SE4 - Condições de Pagamento - [Cabeçalho]

  • SEC - Desmembramento de CondIções de Pagamento - [Item] - Usada somente se a condição de pagamento for Tipo B (E4_TIPO = B).


Principais tabelas envolvidas diretamente em movimentações em detrimento da Condição de Pagamento (no Faturamento - SIGAFAT):

  • SE1 - Títulos à Receber (Gera as duplicatas à serem recebidas)

  • FIE - Relacionamento de Pedidos x Adiantamentos (Caso a condição de pagamento permita o recebimento adiantado)






Perguntas mais usuais (F.A.Q.)





Como passar a usar a condição de pagamento no faturamento

Deck of Cards
startHiddenfalse
effectDuration0.5
idOCORRÊNCIAS
effectTypehorizontal
loopCardstrue
Card
defaulttrue
idCusto Médio
labelUsando para faturar (padrão)

1 - No pedido de venda [Rotina MATA410 - Tabela SC5], preencher o campo “Cond Pagto. [C5_CONDPAG]” com a condição criada.

2 - Liberar o pedido de vendas e posteriormente gerar o documento de saída (faturar).

3 - Visualizar os títulos com suas duplicatas geradas [Rotina FINA740 - Tabela SE1].


Card
defaulttrue
idCusto Médio
labelUsando para Recebimento Adiantado

1 - No cadastro da condição de pagamento, o campo “Adiantamento [E4_CTRADT]” igual a “1 - Sim”.

2 - No pedido de venda [Rotina MATA410 - Tabela SC5], preencher o campo C5_CONDPAG.

3 - No pedido de venda [Rotina MATA410 - Tabela SC5], entrar no botão “Outras Ações > Adiantam.” e vincular um Recebimento Adiantado.

4 - Liberar o pedido de vendas e posteriormente gerar o documento de saída (faturar).

5 - A primeira parcela da condição de pagamento estará compensada. [Rotina FATA740 - Tabela SE1].

6 - A compensação pode ser visualizada [Tabela FR3]


Aviso
titleOBSERVAÇÃO

Caso a condição de pagamento permita recebimento adiantado cheque nossas documentações detalhadas:

KCS sobre Recebimento Adiantado: [Cross Segmento - TOTVS Backoffice (Linha Protheus) - SIGAFAT- Como vincular ou Desvincular RA no Pedido de Vendas pela Rotina MATA410]

TDN sobre Recebimento Adiantado: https://tdn.totvs.com/x/GkD2Dw



Helps

Cross Segmentos - TOTVS Backoffice (Linha Protheus) - FAT - HELP LJLIMINFER Limite inferior e superior na condição de pagamento




Parâmetros


MV_DIACONT (Considera datas da contra-apresentação ou da parcela a vista da respectiva condição)

Válido apenas para Condição de Pagamento Tipo 1. Dependendo do valor posto começa a contar o prazo para pagamento à partir do próprio dia da emissão (E1_EMISSAO) ou no dia posterior (E1_EMISSAO + 1 dia). Pode atuar em conjunto do campo E4_DDD (o uso do parâmetro não invalida o uso do campo E4_DDD).

Expandir
titleExemplos de uso do parâmetro MV_DIACONT

KCS

Expandir
titleExemplos técnicos (testes) de uso do parâmetro MV_DIACONT

Opções de uso:  1  |  2


MV_DIACONT == 1 (considera que a data base para começar a contar o vencimento é o dia da emissão do título gerado [E1_EMISSAO])

MV_DIACONT == 2 (considera que a data base para começar a contar o vencimento é o dia psoterior à emissão do título gerado [E1_EMISSAO + 1 dia])


Expandir
titleExemplos de combinações para a geração do vencimento do título (E1_VENCTO) entre o parâmetro MV_DIACONT e o campo E4_DDD = D/L.
  • MV_DIACONT = 1 e E4_DDD = "Vazio" ou D - Data do dia":
    E4_TIPO = 1

    E4_COND = 5 (Cinco dias a partir da emissão do título á receber [E1_EMISSAO])

    D2_EMISSAO = 01/01/2023 → Permanece sem alteração considerável pois o campo E4_DDD está vázio.

    E1_EMISSAO = 01/01/2023 → Permanece sem alteração considerável pois o parâmetro MV_DIACONT está com o valor 1 e o campo D2_EMISSAO não foi alterado.

    E1_VENCTO = 05/01/2023 (Cinco dias a partir do dia 01/01/2023)



  • MV_DIACONT = 1 e E4_DDD = 'L - Fora o Dia':
    E4_TIPO = 1

    E4_COND = 5 (Cinco dias a partir da emissão do título á receber [E1_EMISSAO])

    D2_EMISSAO = 01/01/2023 (“emissão “real” do documento de saída que o sistema considera por causa do campo E4_DDD = ‘F - Fora o Dia’)

    E1_EMISSAO = 01/01/2023 (Como se fosse: 02/01/2023.) (Emissão “real” do título à receber que o sistema considera por causa do campo E4_DDD = ‘L - Fora o Dia’) (não é gravado no banco)

    E1_VENCTO = 06/01/2023 (Cinco dias a partir do dia 02/01/2023)




  • MV_DIACONT = 2 e E4_DDD = "Vazio" ou D - Data do dia":
    E4_TIPO = 1


    E4_COND = 5 (Cinco dias a partir da emissão do título á receber [E1_EMISSAO])

    D2_EMISSAO = 01/01/2023 (emissão “real” do documento de saída que o sistema considera por causa do campo E4_DDD = ‘D - Data do Dia’) (a suposição não é gravada no banco)

    E1_EMISSAO = 01/01/2023 (Como se fosse: 02/01/2023.) (Emissão “real” que o sistema considera por causa do parâmetro MV_DIACONT = 2 mais o campo E4_DDD = ‘D - Data do Dia’) (a suposição não é gravada no banco)

    E1_VENCTO = 06/01/2023 (Cinco dias a partir do dia 02/01/2023)



  • MV_DIACONT = 2 e E4_DDD = 'L - Fora o Dia':
    E4_TIPO = 1

    E4_COND = 5 (Cinco dias a partir da emissão do título á receber [E1_EMISSAO])

    D2_EMISSAO = 01/01/2023 (Como se fosse: D2_EMISSAO = 02/01/2023.) (Emissão “real” do documento de saída que o sistema considera por causa do campo E4_DDD = ‘L - Fora o Dia’) (não é gravado no banco)

    E1_EMISSAO = 01/01/2023 (Como se fosse: 03/01/2023.) (Emissão “real” do título à receber que o sistema considera por causa do parâmetro MV_DIACONT = 2 mais o campo E4_DDD = ‘L - Fora o Dia’) (não é gravado no banco)

    E1_VENCTO = 07/01/2023 (Cinco dias a partir do dia 03/01/2023)
Deck of Cards
startHiddenfalse
effectDuration0.5
idMVDIACONT
effectTypehorizontal
loopCardstrue
Card
defaulttrue
idCusto Médio
labelMV_DIACONT == 1

No sistema:

  • MV_DIACONT = 1


Cadastro da condição de pagamento:

  • E4_CODIGO = EX1 (Usuário escolhe)
  • E4_TIPO = 1 (Nesse exemplo)
  • E4_COND = 5 (Cinco dias a partir da emissão do documento de saída [D2_EMISSAO] para iniciar a contagem para vencer a parcela)
  • E4_DDD = Vazio


Emissão do pedido de vendas:

  • C5_EMISSAO = 02/02/2023 (pedido criado e emitido em fevereiro)
  • C5_CONDPAG = EX1


Faturamento do pedido de vendas:

  • D2_EMISSAO = 05/05/2023 (emissão do documento de saída, pedido faturado em maio)


Emissão do título:

  • E1_EMISSAO = 05/05/2023 (nova emissão real por causa do parâmetro MV_DIACONT = 1) (nessa combinação não altera)
  • E1_VENCTO = 09/05/2023 (vencimento normal)
Card
defaulttrue
idCusto Médio
labelMV_DIACONT == 2

No sistema:

  • MV_DIACONT = 2


Cadastro da condição de pagamento:

  • E4_CODIGO = EX2 (Usuário escolhe)
  • E4_TIPO = 1 (Nesse exemplo)
  • E4_COND = 5 (Cinco dias a partir da emissão do documento de saída [D2_EMISSAO] para iniciar a contagem para vencer a parcela)
  • E4_DDD = Vazio


Emissão do pedido de vendas:

  • C5_EMISSAO = 02/02/2023 (pedido criado e emitido em fevereiro)
  • C5_CONDPAG = EX2


Faturamento do pedido de vendas:

  • D2_EMISSAO = 05/05/2023 (emissão do documento de saída, pedido faturado em maio)


Emissão do título:

  • E1_EMISSAO = 05/05/2023  (Como se fosse: 06/05/2023) (“emissão real que o sistema considera por causa do parâmetro MV_DIACONT = 2) (não é gravado no banco)
  • E1_VENCTO = 10/05/2023 (vencimento acrescenta um dia)
Aviso
titleCampo E4_DDD = S/Q/F/Z (‘S - Fora Semana’/’Q - Fora quinzena’/’F - Fora Mes’ e ‘Z - Fora Dezena’)


A regra é a mesma porém com suas respectivas mudanças (Um é fora semana, outro fora quinzena, o penúltimo fora o mês e o último fora a dezena).




MV_1DUP (Define a inicialização da primeira parcela do título gerado. Exemplo: A -> Para sequência alfa)

Parâmetro MV_1DUP: Por padrão possui o conteúdo A, podendo ser alterado para até 3 dígitos (AAA ou 001). Pode atuar em conjunto do campo E1_PARCELA.

Expandir
titleExemplos conceituais de uso do parâmetro MV_1DUP

KCS: Cross Segmentos - TOTVS Backoffice (Linha Protheus) - SIGAFAT - Funcionamento do parâmetro MV_1DUP

Expandir
titleExemplos técnicos (testes) de uso do parâmetro MV_1DUP
Deck of Cards
startHiddenfalse
effectDuration0.5
idMVDIACONT
effectTypehorizontal
loopCardstrue

Forma como o sistema gravará a sequência das parcelas no campo "Parcelas E1_PARCELA", por letra ou por número e, a quantidade de algarismos.


Card
defaulttrue
idMV_1DUP = 1 ou 01 ou 001
labelMV_1DUP

Condição de pagamento:

  • E4_CODIGO = EX3 (Apenas um exemplo, o código o usuário escolhe)
  • E4_TIPO = 1 (Condição de pagamento do tipo 1)
  • E4_COND = 00,30 (2 parcelas)


Tamanho MÍNIMO do campo E1_PARCELAComo TEM DE estar o parâmetro MV_1DUPResultado ao faturar gerando dois títulos (E1_PARCELA)
11 ou A
MV_1DUP = 1
1 título2 título
12
MV_1DUPNAT = A

1 título2 título
AB
201 ou AA
MV_1DUP = 01
1 título2 título
0102
MV_1DUP = AA

1 título2 título
AAAB
3001 ou AAA
MV_1DUP = 001

1 título2 título
001002
MV_1DUP = AAA
1 título2 título
AAAAAB





MV_TIPCPDT

Preenchimento da data de entrega “Entrega [C6_ENTREG]” em cópias de pedidos de venda.

Expandir
titleExemplos conceituais de uso do parâmetro MV_TIPCPDT

KCS

Expandir
titleExemplos técnicos (testes) de uso do parâmetro MV_TIPCPDT
Deck of Cards
startHiddenfalse
effectDuration0.5
idMVDIACONT
effectTypehorizontal
loopCardstrue

Opções de uso:  1  |  2  |  3


MV_TIPCPDT == 1 (Copia a “Entrega [C6_ENTREG]” do pedido de venda original, que será copiado, independente da C5_EMISSAO do pedido cópia)

MV_TIPCPDT == 2 (Se o C6_ENTREG do pedido original for uma data anterior a data do C5_EMISSAO do pedido cópia, o C6_ENTREG fica com a data de emissão do pedido cópia novo do campo C5_EMISSAO. Se o C6_ENTREG do pedido original for após que o C5_EMISSAO do pedido cópia, o C6_ENTREG é mantido do pedido original)

MV_TIPCPDT == 3 Aplica a diferença de dias entre o C5_EMISSAO e C6_ENTREG no pedido cópia [No pedido cópia então: C5_EMISSAO = C6_ENTREG])


Card
defaulttrue
idMV_TIPCPDT == 1
labelMV_TIPCPDT == 1

Exemplo 1 (DDATABASE: 05/05/2023):


Pedido origem que vai ser copiado:

  • C5_NUM = PEDEX1 (exemplo de código pedido origem)
  • C5_EMISSAO = 10/05/2023 (pedido origem)
  • C6_ENTREG = 10/05/2023 (pedido origem)


Dados que virão no pedido cópia (pedido gerado pela cópia):

  • C5_NUM = PEDEX2 (pedido cópia)
  • C5_EMISSAO = 05/05/2023 (pedido cópia)
  • C6_ENTREG = 10/05/2023 (pedido cópia)




Exemplo 2 (DDATABASE: 15/05/2023):


Pedido origem que vai ser copiado:

  • C5_NUM = PEDEX3 (exemplo de código pedido origem)
  • C5_EMISSAO = 10/05/2023 (pedido origem)
  • C6_ENTREG = 10/05/2023 (pedido origem)


Dados que virão no pedido cópia (pedido gerado pela cópia):

  • C5_NUM = PEDEX4 (pedido cópia)
  • C5_EMISSAO = 15/05/2023 (pedido cópia)
  • C6_ENTREG = 10/05/2023 (pedido cópia)
Card
defaulttrue
idMV_TIPCPDT == 2
labelMV_TIPCPDT == 2

Exemplo 1 (DDATABASE: 05/05/2023):


Pedido origem que vai ser copiado:

  • C5_NUM = PEDEX5 (exemplo de código pedido origem)
  • C5_EMISSAO = 10/05/2023 (pedido origem)
  • C6_ENTREG = 10/05/2023 (pedido origem)


Dados que virão no pedido cópia (pedido gerado pela cópia):

  • C5_NUM = PEDEX6 (pedido cópia)
  • C5_EMISSAO = 05/05/2023 (pedido origem)
  • C6_ENTREG = 10/05/2023 (pedido origem)




Exemplo 2 (DDATABASE: 15/05/2023):


Pedido origem que vai ser copiado:

  • C5_NUM = PEDEX7 (exemplo de código pedido origem)
  • C5_EMISSAO = 10/05/2023 (pedido origem)
  • C6_ENTREG = 10/05/2023 (pedido origem)


Dados que virão no pedido cópia (pedido gerado pela cópia):

  • C5_NUM = PEDEX8 (pedido cópia)
  • C5_EMISSAO = 15/05/2023 (pedido origem)
  • C6_ENTREG = 15/05/2023 (pedido origem)


Card
defaulttrue
idMV_TIPCPDT == 3
labelMV_TIPCPDT == 3

Exemplo 1 (DDATABASE: 05/05/2023):


Pedido origem que vai ser copiado:

  • C5_NUM = PEDEX9 (exemplo de código pedido origem)
  • C5_EMISSAO = 10/05/2023 (pedido origem)
  • C6_ENTREG = 10/05/2023 (pedido origem)


Dados que virão no pedido cópia (pedido gerado pela cópia):

  • C5_NUM = PEDE10 (pedido cópia)
  • C5_EMISSAO = 05/05/2023 (pedido origem)
  • C6_ENTREG = 05/05/2023 (pedido origem)




Exemplo 2 (DDATABASE: 15/05/2023):


Pedido origem que vai ser copiado:

  • C5_NUM = PEDEX7 (exemplo de código pedido origem)
  • C5_EMISSAO = 10/05/2023 (pedido origem)
  • C6_ENTREG = 10/05/2023 (pedido origem)


Dados que virão no pedido cópia (pedido gerado pela cópia):

  • C5_NUM = PEDEX8 (pedido cópia)
  • C5_EMISSAO = 15/05/2023 (pedido origem)
  • C6_ENTREG = 15/05/2023 (pedido origem)



MV_LJOFFLN

Determina se o ambiente (Protheus) está ou não trabalhando Offline.

Para exemplos técnicos práticos de utilização, contate a equipe especialista do Protheus Automação Comercial (SIGALOJA).


MV_JFSINC

Determina se habilita ou não a fila de sincronização para integrar com outros sistemas e módulos. (SIGAPFS/Legal Desk)

Para exemplos técnicos práticos de utilização, contate a equipe do Protheus Jurídico (SIGAPFS).


MV_LJGRINT

Define se está ativa a integração Protheus.

Para exemplos técnicos práticos de utilização, contate a equipe especialista do Protheus Automação Comercial (SIGALOJA).


MV_RATPIS

Indica se deve ou não ratear o PIS retenção nas parcelas do titulo da nota fiscal de entrada

Para exemplos técnicos práticos de utilização, contate a equipe especialista do Protheus Compras/GCP/GCT (SIGACOM).


MV_RATCOF

Indica se deve ou não ratear COFINS retenção nas parcelas do titulo da nota fiscal de entrada.

Para exemplos técnicos práticos de utilização, contate a equipe especialista do Protheus Compras/GCP/GCT (SIGACOM).


MV_RATCSLL

Indica se deve ou não ratear CSLL retenção nas parcelas do titulo da nota fiscal de entrada.

Para exemplos técnicos práticos de utilização, contate a equipe especialista do Protheus Compras/GCP/GCT (SIGACOM).


MV_DATDUPB

Indica se a data de referência da condições de pagamento do Tipo B serão atualizadas ou sempre terão como base a data inicial.

Expandir
titleExemplos conceituais de uso do parâmetro MV_DATDUPB

KCS

Expandir
titleExemplos técnicos (testes) de uso do parâmetro MV_DATDUPB

KCS



MV_AGLDUPB

Define se quando existirem duplicatas com a mesma data de vencimento, estas deverão ou não ser aglutinadas.

Expandir
titleExemplos conceituais de uso do parâmetro MV_AGLDUPB

KCS

Expandir
titleExemplos técnicos (testes) de uso do parâmetro MV_AGLDUPB

KCS



MV_IPITP9

Define se o valor do IPI será incluso nas parcelas. A Condição de Pagamento Tipo 9 tem o valor definido pelo usuário em valor ou em percentual, sendo assim, se a opção escolhida for valor, o IPI pode ser distribuído nas parcelas como convier.

Expandir
titleExemplos conceituais de uso do parâmetro MV_IPITP9

KCS

Expandir
titleExemplos técnicos (testes) de uso do parâmetro MV_IPITP9

KCS



Pontos de Entrada

KCS: Cross Segmentos - TOTVS Backoffice (Linha Protheus) - SIGAFAT - Pontos de Entrada na rotina Condições de Pagamento (MATA360)

Deck of Cards
startHiddenfalse
effectDuration0.5
idVincular RA / Desvincular RA
effectTypehorizontal
loopCardstrue
Card
defaulttrue
idCusto Médio
labelNa rotina

MTA360MNU - Adiciona opções no MenuDef() da Condição de Pagamento

MT360DEL - Validar exclusão de condição de pagamento

MT360GRV - Após a atualização de todas as tabelas da rotina de condição de pagamento nas operações de inclusão, alteração e exclusão

MT360VLD - Está localizado na rotina de validação, Ma360VLD(), das informações da condição de pagamento


Card
defaulttrue
id0607202023
labelEm processos que envolvem a rotina:

M460RTPD - Executado antes do rateio das despesas acessórias

M460COND - Alteração de data inicial da condição de pagamento. Chamado antes de gerar o cabeçalho da nota fiscal de saída


M460FIM - Chamado apos a gravação da nota fiscal de saída, e fora da transação


M461VTot - Verifica o total da nota fiscal de saída e a condição de pagamento escolhida, antes de sua geração
OBS: O ponto de entrada não é chamado na opção Prep. Doc. Saída da rotina MATA410, é chamado na opção Prep. Doc. Saída da rotina MATA461.

MT461VCT - Alteração no vencimento e valor do título

M4601DUP - Possibilita a alteração do número da primeira parcela dos títulos. As demais serão uma sequência alfanúmerica destes


M460MOED - Altera definição da moeda do título

GEMXGRCVND - Manutenção da condição de pagamento no pedido de venda



ExecAuto()

ExecAuto da Rotina Condições de Pagamento (MATA360)


Sugestões


Gostaria de sugerir uma implementação diferente ou uma melhoria nessa documentação? Abra um ticket para nós, a Equipe Faturamento (SIGAFAT)!