Contabilidade > Utilitários > Resincronizações > Histórico de vencimentos 

Este utilitário permite resincronizar a tabela de histórico dos vencimentos (HISTODUD) que está actualizado quando o código de actividade HDU está activo, e desde que um vencimento está modificado.

Esta ressincronização pode ser de dois tipos :

  • primeiro caso : detenção de anomalias sobre os registos existentes e correscção destas anomalias, mas sem criação de novos registos. Neste caso, a res-sincronização/correcção realiza dois tipos de controlo :
    • A pesquisa de incoerências entre, de uma parte os dados da tabela de referência (GACCDUDATE), e de outra parte os dados da tabela de histórico dos vencimentos (HISTODUD).
      Se incoerências são detectadas entre as duas tabelas, a tabela HISTODUD está actualizada via a ressincronização sobre a base do conteúdo da tabela GACCDUDATE.
    • A verificação de coerência de certos dados próprios à tabela HISTODUD sobre a base de um certo número de regras.
  • Segundo caso : apagamento dos registos exsitentes (se existem) e a criação de novos registos de histórico :
    • a reconstituição dos registos de histórico tem por vocação de suprimir os registos já constituidos e de criar de novo registo, compreendendo no caso onde o código actividade HDU será activado em curso de exploração.
      SEEWARNING Esta reconstituição de histórico não se apoia pelos seus fluxos de módulos a montante da contabilidade mas sobre a conciliação(em saber mais...).

Pré-requisitos

SEEREFERTTO Consulte a docuemntação de Implementação

Gestão do ecrã

As duas check boxes a assinalar Res-sincronização e Apagamento permitem reter um ou outro dos dois modos operatórios de actualização da tabela.HISTODUD.
A check box Traço detalhado permite dispor de uma lista dos registos impactados ou criados pela res-sincronização.

Combinações possíveis e impactos.

Res-sincronização

Apagamento

Rasto detalhado

Impactos

Exemplos de informações obtidos no rasto

Não

Não

Não

Fichriro rasto listando as anomalias nos registos existentes. Nenhuma correcção nem criação.

Documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 (151016)
/  / : Data incorrecta => 10/02/11

Com informação do número de vencimento historizado ([F:HDU]NUMHDU) assim que a natureza de anomalia (como uma DATEVT incorrecta).

 Sim

Não

Não

Correcção das anomalias detectadas sobre os registos existentes.

Ficheiro rasto listando as anomalias corrigidas.

Documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 (151020)
   15/09/11 : Data incorrecta => 10/02/11

 

Não

Sim

Não

Ficheiro rasto listando os registos que o utilitário é susceptível de criar se lançado em real (sem ter em conta destes dois já existentes).

Documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1
Criação documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 12/02/11
Criação documento FAC FCRHDU10102VEN00001 Linha 1 vencimento 1 10/02/11

Com em última informação da DATEVT aplicada se o utilitário está lançado em modo real.

Não

Sim

Sim

Ficheiro rasto listando os registos existentes que serão apagados se o utilitário está lançado em modo real.

Ficheiro rasto listando os registos que o utilitário é susceptível de criar se lançado em modo real (sem ter em conta destes dois já existentes).

*** 150983 10/02/11

Documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1
Criação documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 12/02/11
Criação documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 10/02/11

O registo a suprimir está identificado via o seu [F:HDU]NUMHDU e sua DATEVT.

Com em última informação da DATEVT aplicada se o utilitário está lançado em modo real.

 Sim

 Sim

Não

Supressão dos registos existentes e criação dos novos registos de histórico dos vencimentos.
Ficheiro rasto listando os novos registos criados pelo utilitário.

Documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1
Criação documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 (151017) 12/02/11
Vencimento documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 (151018) 10/02/11

 

 Sim

 Sim

Sim

Supressão dos registos existentes e criação dos novos registos de histórico dos vencimentos..
Ficheiro rasto listando os novos registos apagados e os novos registos criados pelo utilitário.

Documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1
***151017 /  / 
***151018 /  / 
Criação documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 (151019) 12/02/11
Criação documento FAC FCRHDU10102VEN00001 Linha 1 Vencimento 1 (151020) 10/02/11

 

Ecrã de registo

Campos

Os seguintes campos estão presentes neste separador :

Cabeçalho

No help linked to this field.

Critérios

  • Todos estab. (campo ALLFCY)

No help linked to this field.

 

  • Todos tipos terceiros (campo ALLTYPBPR)

 

  • Tipo de terc. (campo TYPBPR)

 

  • Todos terceiros (campo ALLBPR)

 

 

 

  • Todos colectivos (campo ALLSAC)

 

 

  • Colectivo (campo SAC)

 

Bloco número 3

  • Resincronização (campo RECUP)

A res-sincronização está realizada unicamente sobre os registos cuja lista DUDSTA tem por valor "dois", o que corresponde a um vencimento ligado a um documento contabilizado (por oposição por exemplo aos vencimentos ligados a facturas não contabilizadas).

Um certo número de zonas da tabela HISTODUD não estão actualizados, a saber :

  • a chave NUMHDU,
  • os campos de rastrabilidade CREDAT e CREUSR,
  • os campos permitem fazer a ligação com a tabela de referência GACCDUDATE : TYP, NUM, LIG e DUDLIG,
  • de outros campos diversos, tais que FLGPAZ, DUDDAT, PAYDAT e TYPDUD.

Certos campos são res-soincronizados pela aplicação de uma regra, a saber :

  • campo Saldado : este campo caracteriza o vencimento por relação ao seu saldo e pode tomar os valores seguintes:
    • "0" ou "1" quando o vencimento não está saldado ou saldado parcialmente,
    • "2" quando o vencimento está saldado definitivamente (montante de vencimento AMTCUR = montante pago contabilizado PAYCUR e AMTCUR <> 0 ; ou AMTCUR=0 e o montante vencimento AMTLOC = montante pago contabilizado PAYLOC),
    • "3" quando o vencimemto histórico foi suprimido,
    • "4" quando o vencimento está saldado temporariamente (montante de vencimento AMTCUR = montante pago contabilizado PAYCUR + montante pago não contabilizado TMPCUR e AMTCUR<>0 ; ou AMTCUR=0 e montante de vencimento AMTLOC = montante pago contabilizado PAYLOC + montante pago não contabilizado TMPLOC).

      O valor deste campo está controlado e eventualmente corrigido unicamente para os casos onde está diferente de "3".
      Para os registos de histórico tendo um campo Saldado diferente de "3", as zonas Montante vencimento em divisa (AMTCUR), Montante divisa local (AMTLOC), Montante pago (PAYCUR), Regra sociedade (PAYLOC), Montante pago provisório (TMPCUR) e Pagamento provisório soc (TMPLOC) são lidos em seguida re-avaliar o valor do campo Saldado segundo a regra definida em cima.
  • campo Data de evento :
    • no caso onde o Montante pago é superior a "0", o utilitário res-sincroniza a data de evento por relação à data contabilística máxima do grupo de conciliação : com efeito o utilitário reencontra a linha de registo de origem do vencimento via o número de conta ACCNUM da tabela dos documentos contabilísticos GACCENTRYD. Como a linha está conciliada (a linha Montante "MTC" da tabela GACCENTRYD não está vazia), o utilitário toma em conta o montante da data contabilística máxima de conciliação "MTCDATMAX" da linha da tabela GACCENTRYD.
    • no caso onde o vencimento não está saldado (se o campo Saldado é inferior a 2), o utilitário res-sincroniza a data de evento por relação à data contabilística ACCDAT do documento (a data está reencontrada via o número de conta ACCNUM da tabela GACCENTRYD)

SEEINFO Os campos ligados aos montantes não fazem objecto de uma res-sincronização :

  • As zonas de montante do vencimento (AMT*),
  • as zonas de montante pago (PAY*),
  • as zonas de montante pago provisório (TMP*).
  • Apagar (campo DEL)

A opção "Apagar" criada de novo registo de historização. Os dados do ficheiro dos vencimentos constituem o ponto de partida desta criação.

  • para um vencimento DUD sem ligação com a tabela das linhas de registos GACCENTRYD, o histórico criado vai ser :
    • um único registo com [F:HDU]DUDSTA = 0 (documento origem não contabilizado) e com [F:HDU]DATEVT inicializado com a data de vencimento [F:DUD]DUDDAT,
  • para um vencimento DUD com uma ligação com GACCENTRYD e sem conciliação ([F:DAE]MTC a vazio), histórico criado vai ser :
    • um registo com [F:HDU]DUDSTA = 0 (documento origem não contabilizado) e com [F:HDU]DATEVT inicializado com a data de vencimento [F:DUD]DUDDAT,
    • um registo com [F:HDU]DUDSTA = 2 (documento origem não contabilizado) e com [F:HDU]DATEVT inicializado com a data contabilística do documento [F:HAE]ACCDAT,
  • para um vencimento DUD com uma ligação com GACCENTRYD e sem conciliação ([F:DAE]MTC diferente de vazio), o histórico criado vai ser :
    • um registo com [F:HDU]DUDSTA = 0 (documento origem não contabilizado) e com [F:HDU]DATEVT inicializado com a data de vencimento [F:DUD]DUDDAT,
    • um registo com [F:HDU]DUDSTA = 2 (documento contabilizado) e com [F:HDU]DATEVT inicializado com a data contabilística do documento [F:HAE]ACCDAT,
    • um registo com [F:HDU]DUDSTA = 2  (documento contabilizado) e com [F:HDU]DATEVT inicializado com a data contabilística máxima do grupo de conciliação [F:DAE]MTCDATMAX.
LIMITE n°1

A ressincronização com apagamento não se apoia pas sur les flux dans les modules en amont de la comptabilité mais sur l’événement comptable qu’est le lettrage.
De ce fait, pour un groupe de pièces lettrées, la mise à jour du solde ne peut être constatée au fur et à mesure mais uniquement à la date comptable maximale du groupe de lettrage ([F:DAE]MTCDATMAX).

Exemplo :
No caso de uma factura conciliada minúscula com dois pagamentos A e B de datas contabilísticas A e B diferentes. os novos registos criados constaterão o saldo da factura na data contabilística a mais elevada das duas, B, e não sucessivamente e progressivamento às datas contabilísticas de cada uma dos dois pagamentos.
A data contabilística do pagamento A, o balancete de idades vai restituir a factura pelo seu montante total de origem, assim que o pagamento A, pelo seu montante total também, seja um saldo global representando bem o líquido.
A data contabilística do pagamento B, o balancete de idades vai restituir que a factura pelo seu saldo líquido (desflacado cujo do montante dos pagamentos A e B).

LIMITE n°2

A ressicronização com apagamento não permite gerar o caso de uma anulação de pagamento que intervierá à posteriori desta ressicronização.
Seja um grupo constituido de pelo menos dois pagamentos de datas contabilísticas diferentes, este grupo tendo sofrido o apagamento com ressincronização. Se uma anulação contabilística está em seguida constatado sobre um dos pagamentos do grupo (outro que aquele com a data contabilística a mais elevada), a actualização de histórico de anulação não permitirá detectar a anulação; a situação intermediária constatada no balancete de idades não terá em conta desta anulação.

Exemplo :
Seja a contabilização de uma factura de 10.000 em data contabilística do 01/03/11.
Seja a contabilização de um pagamento A de 500 em data contabilística do 08/03/11.
Seja a contabilização de um pagamento B de 600 em data contabilística do 14/03/11.
Seguido uma res-sincronização com apagamento.
Seguido de uma anulação contabilística do pagamento A em data contabilística de 08/03/11.
Balancete de idades em 08/03/11 : a factura aparece para um saldo de 10.000 e o pagamento para -500 seja um saldo de 9.500. A anulação não será tida em conta.
Balancete de idades em 14/03/11 : a factura aparece para um saldo de 9.400.

Em relançando uma res-sicronização com apagamento sobre o terceiro afectado, os novos dados de histórico são reconstituido sem este limite.

  • Rastro detalhado (campo TRC)

Se o rasto detalhado está pedido, o ficheiro rasto está completado pela lista dos registos HISTODUD susceptíveis de serem suprimidos no momento da fase de apagamento (com ou sem res-sincronização).

Fechar

 

Tarefa batch

Esta função pode ser lançada em batch. A tarefa standard ACCRECHDU está prevista p/esse efeito.

Mensagens de erro

Para além das mensagens genéricas, as seguintes mensagens de erro podem aparecer durante o reg. :

Certos campos directamente ligados à tabela de referência GACCDUDATE são actualizados, as mensagens de erro estando então idênticos utilizados em res-sincronização dos vencimetos,a saber :
- ACCNUM : Número interno incorrecto
- CPY : Sociedade incorrecta
- FCY : Estabelecimento incorrecto
- CUR : Divisa incorreta
- SNS : Sentido incorrecto
- SAC : Colectivo incorreto
- BPR / BPRTYP / BPRPAY : Terceiros incorrecto

Tabelas consideradas

SEEREFERTTO Consulte a docuemntação de Implementação