Edition des en-têtes contrat (ICEVE2)

Introduction

L’édition des contrats de service peut être activée de ICEV via le menu "Editer… En-tête".

Elle permet :
  • L’édition des contrats,
  • La validation en liste des contrats,
  • La suppression en liste des contrats,
  • La révision des contrats,
  • Le renouvellement des contrats,
  • L’édition des cut-offs.
  • La mise à jour des indices de revalorisation des nouveaux contrats

Les critères de sélection et de tri de la fonction ICEVE2 se rapportent aux données des en-têtes et des couvertures d’un contrat. La vue « v_iceicl» est basée sur les tables ICE (en-tête contrat) et ICL (couverture contrat).. L’utilisateur peut sélectionner ou trier des événements en fonction des champs de l’entête ou des couvertures des contrats (pour les éditer).

les champs datsup1 et datsup2 sont des champs virtuels de ICEV_1, utilisés en tant que critères de sélection.

datsup1 : si elle est renseignée, on considère qu'il s'agit d'un contrat reconduit. Donc on ne calcule plus d'échéances pour ce contrat (cf ICEV_8). Le batch de révision de prix met à jour la datsup1 avec la date de fin réelle du contrat. Lors de la suppression d'un contrat, cette date permet de mettre à jour la date de fin réelle de la version origine.

Iceve2_b05 Edition des indices de revalorisation du poste du contrat
iceve2_b10 Edition des entêtes contrat
iceve2_b11 Edition des postes contrat
iceve2_b12 Edition échéances contrat
iceve2_b13 Edition du domaine de couverture attaché à l'en-tête du contrat
iceve2_b14 Edition du domaine de couverture attaché aux postes du contrat
iceve2_b15 Edition du texte libre attaché à l'en-tête du contrat
iceve2_b16 Edition du texte libre attaché aux postes du contrat.
iceve2_b17 Bloc qui fait apparaître par contrat et par facture les données de l'en-tête de la facture (numéro, date, ht, ttc, tiers…), le montant facturé, le montant à ventiler et la ventilation sur 12 mois. Utilisé pour éditer les cut-offs.
iceve2_b18 Informations révisions prix.
iceve2_b19 Valeurs indices
iceve2_b31 Entêtes prestations d’une entête d’un contrat de service
iceve2_b32 Postes prestations d’une entête d’un contrat de service
iceve2_b33 Entêtes prestations d’un poste d’un contrat de service
iceve2_b34 Postes prestations d’un poste d’un contrat de service
iceve2_b40 Edition des entêtes contrat (cumul)

L'édition ICEVE2 permet d'éditer les informations du contrat créé (renouvelé et/ou révisé). Les informations des blocs 20 et 40 correspondent aux infos du contrat origine afin de garder les éventuelles possibilités de tri (sigle contrat, date d'échéance…) sauf la partie correspondant au CA et aux cut-offs. Toutes les infos des autres blocs correspondent au contrat créé.

Edition des contrats après sélection sur les en-têtes

Lancement par le menu à Editer à En-têtes

A partir de la même fonction, en utilisant le lanceur ICE_ED2 qui propose une sélection sur les en-têtes de contrat, il est possible en utilisant différentes maquettes d’édition, d’effectuer, les opérations suivantes :

· Edition des en-têtes de contrat

· Edition du CA prévisionnel des contrats

· Edition des cut-offs

· Révision des contrats

· Recherche des indices de revalorisation pour les contrats nouvellement créés

Le paramètre maquette DERNIERE_VERSION permet de n'éditer que la dernière version du contrat.

Si on ne précise aucune valeur au paramètre, le batch travaille uniquement sur la dernière version du contrat quelque soit sont état.

Pour travailler sur la dernière version valide du contrat, il est nécessaire de donner comme valeur au paramètre la liste des code état permettant de considérer que le contrat est valide.

Exemple :

P DERNIERE_VERSION="CVX" Dans ce cas, le batch ne travaille que sur la dernière version valide du contrat, le contrat étant considéré comme valide s'il se trouve dans un des états suivants : "C", "V" ou "X".

Mois de traitement. (sous la forme MM AAAA).

Cette information est exploitée lorsque l'on édite le CA des contrats et les cut-offs.

Edition du CA des contrats

L'édition prévoit une présentation du CA prévisionnel sur 24 périodes. Les 12 premières périodes correspondent à un montant mois par mois, la 13ième période correspond au CA des contrats pour le reste de l'année en cours, les périodes suivantes correspondent au CA prévisionnel des années suivantes.

Les montants édités sont des montants HT mais par un paramètre maquette, on peut demander l'édition des montants TTC (Paramètre maquette CA_TTC positionné).

Les montants édités sont édités dans la devise du contrat mais si on place le paramètre maquette DEVNAT, les montants édités sont convertis dans la devise nationale.

Edition des cut-offs sur les contrats

Principe général

Les états de cut-off concernent les contrats dont la périodicité de facturation est supérieure ou égale à 1 mois.

Suivant que ces contrats sont en terme à échoir ou en terme échu, on facture plusieurs mois d’avance ou on facture après plusieurs mois de prestation. En revanche, les charges liées à l’activité de service sont étalées sur tous les jours de l’année.

Ex. Les contrats pluriannuels dont le montant annuel est facturé au 1er janvier. Les prestations de service seront réalisées tout au long de l’année alors que la totalité du service est facturé au début de l’exercice. On constate donc d’avance le produit des contrats alors que l’on constate les charges associées au contrat au moment réel ou l’entreprise les subit.

Les états de cut-off ont pour but de répartir sur des périodes mensuelles les montants facturés d’avance (produits constatés d’avance = PCA) et les montants à recevoir (produits à recevoir = PAR). De cette manière on obtient une vision des produits qui est plus conforme à l’activité : en lissant les pics de facturation liés à la périodicité de facturation choisie, on met en phase les produits et les charges liés à l’activité.

Dans le module Service, les états de cut-off sont exprimés sur 12 périodes mensuelles :

- sur les 12 périodes suivant la date de cut-off dans l’édition des PCA

- sur les 12 périodes précédant la date de cut-off dans l’édition des PAR.

La date de cut-off est toujours le 1er jour du mois de cut-off saisi dans le lanceur. Par défaut le mois de cut-off est le mois courant mais on peut saisir un autre mois, soit pour simuler les cut-offs à une date future, soit pour faire le bilan des retards de facturation.

L’édition des cut-offs s’effectue à partir de la fonction d’édition des en-têtes de contrat (ICEVE2).

Les postes du contrat dont le type de facturation est 'U' (facturation unique à la première échéance) ne sont pas concernés car ce mode de facturation est surtout utilisé pour facturer des frais de dossier.

L’édition des PCA est disponible à partir de la V4.1-01.

L’édition des PAR est disponible à partir de la V4.2-00.

Pour chaque contrat sélectionné, on édite :

En = montant de la dernière échéance facturée.

N1 = nbre de jours facturés = date du 1er jour du mois du cut-off – date de la dernière échéance facturée.

N2 = nbre de jours entre la date de la dernière échéance facturée et la date de la prochaine échéance.

N3 = nbre de jours dans le mois Mn

N4 = nbre de jours à ventiler = date de la prochaine échéance – date du 1er jour du mois du cut-off.

Montant à ventiler V = En – ( En x N1 / N2)

Montant sur le mois Mn = V x N3 / N4 uniquement jusqu’à la date de prochaine échéance.

Paramétrage du lanceur

- Sélectionner les contrats dont le terme des conditions de facturation est ‘A échoir’ pour les PCA ou ‘Echu’ pour les PAR.

- Sélectionner les contrats dont la périodicité de facturation est supérieure à un mois.

- Sélectionner les contrats déjà facturés (date de dernière échéance facturée <= date du jour).

- La date de cut-off est toujours le 1er jour du mois de cut-off saisi dans le lanceur. es états de cut-off sont exprimés sur 12 périodes mensuelles :

à sur les 12 périodes suivant la date de cut-off dans l’édition des PCA

à sur les 12 périodes précédant la date de cut-off dans l’édition des PAR.

Paramètres maquette

à CA_TTC : pour éditer les cut-offs en montants TTC. Par défaut, les cut-offs sont édités en HT.

à PERCU_AVANCE : pour mémoriser dans les champs du bloc 10 de la fonction ICEVE2 les montants des cut-offs au lieu du CA prévisionnel. Le paramètre peut prendre les valeurs suivantes :

P PERCU_AVANCE="PCA" Edition des PCA

P PERCU_AVANCE="PAR" Edition des PAR

à DEVNAT : pour convertir les montants en devises dans la devise nationale.

Edition des cut-offs pour les PCA

Cet état concerne les prestations qui ont déjà été facturées mais dont les prestations ne sont pas encore complètement réalisées.

Sélection des contrats :

- à périodicité de facturation supérieure ou égale à 1 mois

- à terme de facturation ‘à échoir’ dont l’échéance immédiatement antérieure à la date de cut-off a été facturée. Montant à ventiler = montant de la dernière échéance.

Pour que l’on ait effectivement un produit constaté d’avance sur un contrat en terme à échoir, il faut que l’échéance située immédiatement avant la date de cut-off ait été facturée. Si cette échéance n’a pas été facturée, son montant n’est pas pris en compte dans les PCA mais dans les PAR.

Format de l'édition standard des cut-offs pour les PCA.

Date de cut-off = date du 1er jour du mois de cut-off saisi dans le lanceur (défaut = mois courant).

Editer les colonnes suivantes dans l’ordre demandé.

Colonne 1 = Tiers souscripteur / No contrat

Colonne 2 = No de facture (une ligne par facture)

Colonne 3 = Montant de la dernière échéance facturée

Colonne 4 = Montant total constaté d’avance : Em = N2 x Mj avec Mj = En / N1 où :

En = Montant de la dernière échéance si celle-ci a été facturée.

Mj = Montant journalier.

N1 = Nbre de jours entre la dernière échéance facturée et la prochaine échéance à facturer.

N2 = Nbre de jours pris en compte pour les produits constatés d’avance (prochaine échéance - date de cut off).

Colonne 5 = Montant constaté d’avance mois 1 : M1 = N3 x Mj où :

N3 = Nbre de jours du mois 1

Colonne 6 = Montant constaté d’avance mois 2

Colonne 7 = Montant constaté d’avance mois 3

etc.

L’édition des cut-offs pour les PAR

Cet état concerne les prestations qui ont déjà été prestées mais qui ne sont pas encore facturées.

Il concerne également les contrats « à échoir » en retard de facturation.

Sélection des contrats :

- à périodicité de facturation supérieure ou égale à 1 mois

- à terme de facturation ‘à échoir’ ou ‘échu’ ayant au moins une échéance non facturée dans les 12 périodes précédant la date de cut-off.

- à terme de facturation ‘échu’ dont l’échéance immédiatement postérieure à la date de cut-off n’a pas été facturée.

-

Format de l'édition standard des cut-offs pour les PAR

Date de cut-off = date du 1er jour du mois de cut-off saisi dans le lanceur (défaut = mois courant).

Editer les colonnes dans l’ordre suivant :

Colonne 1 = Tiers souscripteur / No contrat

Colonne 2 = No de facture (une ligne par facture)

Colonne 3 = Montant de la prochaine échéance à facturer

Colonne 4 = Montant total à recevoir : Em = N2 x Mj avec Mj = En / N1 où :

En = Montant de la prochaine échéance si celle-ci n’a pas été facturée.

Mj = Montant journalier.

N1 = Nbre de jours entre la dernière échéance facturée et la prochaine échéance à facturer.

N2 = Nbre de jours pris en compte pour les produits à recevoir (date de cut-off – date de dernière échéance).

Colonne 5 = Montant à recevoir mois 1 : M1 = N3 x Mj où :

N3 = Nbre de jours du mois 1

Colonne 6 = Montant recevoir mois 2

Colonne 7 = Montant recevoir mois 3

Révision des contrats

Ce traitement effectue la révision des contrats sélectionnés, c’est-à-dire la revalorisation des prix du contrat avec génération automatique d’une nouvelle version de contrat.

Pour ce faire, il vous faut positionner le paramètre REVISION dans la maquette d'édition. Le traitement utilise des formules de révision de prix (fonction GIVA).

Les différentes options du paramètre permettent :

- de simuler la révision de prix en éditant le résultant de la révision sans l’enregistrer dans les tables,

- d’indiquer si l’on autorise une révision de prix à la baisse ou non.

Depuis la version 4.2-00, un autre mode de révision n’utilise pas les formules de révision mais déclenche un appel prix pour chaque poste de contrat traité.

Ce mode révision ne modifie pas un prix modifié manuellement par l’utilisateur. Pour utiliser ce mode de révision, il faut positionner le paramètre maquette REVISION=APPEL_PRIX.

Les options disponibles dans le paramètre sont les suivantes :

P REVISION ou (Révision sans baisse de prix autorisée).

P REVISION="BAISSE" ou (Révision avec baisse de prix autorisée)

P REVISION="SIM" ou (Simulation d'une révision sans baisse de prix autorisée)

P REVISION="BAISSE, SIM" ou (Simulation d'une révision avec baisse de prix autorisée)

P REVISION="SIM,BAISSE" ou Idem

P REVISION= ‘’APPEL_PRIX’’ (Révision par appel prix)

Caractéristiques de la nouvelle version créée
  • Le contrat est entièrement dupliqué : sans les échéances

  • Le contrat origine du contrat créé est mis à jour avec le contrat initial,

  • La date de prochaine révision (révision suivante) est calculée,

  • Le contrat origine est mis à jour avec le contrat initial (contrat révisé),

Attention, la révision d'un contrat utilise le champ datsup1 de la table ICE.

Ce champ permet de stocker la date de fin réelle éventuellement mise à jour par l'utilisateur.

Lors de la révision d'un contrat, le contrat révisé est donc mis à jour avec datsup1 = date de fin réelle (datfre).

La date de révision correspond au premier du mois indiqué lors du lancement du traitement de révision. Exemple : mois saisi lors du lancement = 07/2001, la révision s'effectuera au 01/07/2001. Toutefois si le A1 du paramètre DATREV est positionné à "O" sur la fonction batch de révision, alors la date de révision ne correspondra pas au premier jour du mois saisi mais au dernier jour du mois saisi.

Si aucun mois n'a été précisé lors du lancement du traitement, la révision s'effectue à la date du jour.

  • Le prix1 est révisé uniquement
    • s'il est en vigueur à la date de révision
    • Si la date limite de révision du prix1 est inférieure à la date de révision
  • Le prix2 est toujours révisé à condition
    • que la date limite de révision du prix1 soit inférieure à la date de révision
    • que la date limite de révision du prix2 soit inférieure à la date de révision si une date limite de révision du prix2 a été renseignée (PPE DATREV)

La valeur de l'indice V correspond à la valeur de l'indice connue à la date de révision.

La valeur des indices V0 correspond
  • Pour prix1, à la valeur de l'indice connue
    • à la date limite de réactualisation du poste si le poste en possède une sinon
    • à la date de début d'application du poste.
  • Pour prix2, à la valeur de l'indice connue
    • à la date limite de réactualisation du prix2 si le prix 2 en possède une
    • à la date limite de réactualisation du prix1 si le poste en possède une
    • à la date d'application du prix2

Dès qu'un prix est révisé (prix1 ou Prix2), la date de révision est mémorisée au niveau du poste (icf.datrev)

La version à l'origine de la révision peut être mémorisée dans une donnée complémentaire de l'entête du contrat. Dans ce cas, positionner le PPE ICEORI au niveau de la fonction ICEVE2. A partir de la version 4.3-00, cette information permet d'éditer sur la facture de service (EDEVE) des informations supplémentaires concernant le contrat à l'origine de la révision (Données complémentaires, indices de revalorisation, etc…) offrant ainsi la possibilité de justifier le prix révisé lors de l'édition de la facture.

Les prix avant révision peuvent être mémorisés dans des zones paramétrées du poste du contrat : cf Paramètre ICFREV. Cependant, si un prix n'est pas révisé pour une raison quelconque, (prix1 plus en vigueur, Date limite donnée par PPE DATREV pas encore atteinte) il n'est pas mémorisé.

Les prix révisés sont arrondis en fonction du nombre de décimales paramétré pour la devise du contrat (GDEM). Le paramètre PRXARR est actif et permet de gérer les prix unitaires avec plus de deux décimales.

La valeur des indices est enregistrée dans une table attachée au poste du contrat : IIC. Lorsque le système recherche la valeur des indices V0 il utilise les données enregistrées dans cette table. Lorsqu'un indice recherché n'est pas trouvé dans la table IIC, il est recherché en table.

La valeur des indices V sont, quant à eux, recherchés en table et mémorisés dans nouvelle version du contrat (version révisée) afin d'être exploités lors de la prochaine révision.

Les paramètres ICFIP1 et ICFIP2 permettent toutefois de mémoriser la valeur des indices V dans des données complémentaires du poste afin de les restituer lors de l'édition du contrat et de la facture.

Lorsqu'un nouveau contrat ou un nouveau poste de contrat est créé, les indices V0 ne sont pas mémorisés dans la table IIC. Il convient donc, lorsqu'on lance la révision des contrats de respecter la procédure suivante :
  • Enregistrement des indices sur les nouveaux postes (Batch iceve2, paramètre maquette MAJ_INDICES)

  • Mise à jour éventuelle des indices (fonction GIVA )

  • Révision des contrats.

Remarque :

Attention, avec cette façon de procéder, les résultats obtenus peuvent dépendre de la fréquence des traitements de révision.

Exemples :

Valeurs des indices :

01/04/01 è 100

01/06/01 è 110

01/10/01 è 120

Donnée du poste du contrat :

Date d'application : 01/05/2001

Prix1 : 500 €

Date d'application du prix2 : 01/05/2002

Prix2 : 800 €

Pas de date limite de réactualisation du poste.

1er exemple :

Le traitement de révision est lancé le 01/07/2001 et le 01/01/2002
  • Au 01/07/2001 , prix2 est révisé (car pas de date limite de réactu) mais sa valeur reste inchangée par contre les indices utilisés pour le calcul sont eux stockés dans le poste et serviront lors de la prochaine réactualisation.

Indice V0 = 110 (indice au 01/06/2001 retrouvé en utilisant datapp2 soit 01/05/2002)

Indice V = 110 (indice au 01/06/2001 retrouvé en utilisant la date de révision

01/07/2001)

La valeur de l'indice 110 est stockée au niveau du poste
  • Au 01/01/2002 , prix2 est à nouveau révisé. Sa valeur passe de 800 € à 872,72 (800 * (120/110))

Indice V0 = 110 (indice au 01/06/2001 retrouvé dans les données du poste)

Indice V = 120 (indice au 01/10/2001 retrouvé en utilisant la date de révision

01/01/2002)

La valeur de l'indice 120 est stockée au niveau du poste

2ème exemple :

Le traitement de révision est lancé pour la première fois le 01/01/2002
  • Au 01/01/2002 , prix2 est révisé mais sa valeur reste inchangée

Indice V0 = 120 (indice au 01/10/2001 retrouvé en utilisant datapp2 soit 01/05/2002)

Indice V = 120 (indice au 01/10/2001 retrouvé en utilisant la date de révision

01/01/2002)

La valeur de l'indice 120 est stockée au niveau du poste

Conclusion : Avec les mêmes données mais uniquement en modifiant la fréquence des traitements de révision, prix2 vaudra, au 01/01/2002, 872,72 € ou 800 €.

Algorithme de la révision de contrat.

Boucle de lecture sur les postes et sous postes du contrat (Table ICF)

Pour chaque poste lu, s'il existe des composants, revaloriser chaque composant et recalculer le prix du kit (poste de niveau 1) par cumul du prix des composants

S'il n'existe pas de composant, appliquer la formule de révision sur le prix du poste

Mise à jour des indices de revalorisation pour les contrats nouvellement créés

Le paramètre maquette MAJ_INDICE, permet de mémoriser les indices de revalorisation utilisés par la formule de révision du contrat. Ces indices de revalorisation peuvent également être mémorisés dans des données complémentaires du postes du contrat (se reporter à la documentation des paramètres ICFIP1 et ICFIP2).

Deux options :

1- P MAJ_INDICE

Mise à jour des indices pour Prix1 et Prix2 s'il est renseigné, uniquement pour les postes n'ayant pas encore fait encore l'objet d'une révision (postes créés depuis la dernière révision c'est à dire pour qui la date de dernière révision n'est pas renseignée (icf.datdrv = " ")).

Les postes ayant déjà fait l'objet d'une révision seront également mis à jour mais uniquement si aucun indice n'a encore été mémorisé dans le poste. Plus exactement, les indices utilisés pour réviser prix1 seront mémorisés dans le poste du contrat uniquement si toutes les données complémentaires référencées au travers du paramètre ICFIP1 sont vides et les indices utilisés pour réviser prix2 seront mémorisés dans le poste du contrat si toutes les données complémentaires référencées au travers du paramètre ICFIP2 sont vides. Cela traite le cas où le prix2 ne serait pas saisi tout de suite (avant la première révision du contrat) ; cela permet aussi de fonctionner en mode "reprise" et d'initialiser les indices de tous les postes si les paramètres ICFIP1 et ICFIP2 n'étaient pas présents dans le paramétrage lors du dernier traitement de révision.

2- P MAJ_INDICE="TOUT"

Ce paramètre permet de mettre à jour les indices pour Prix1 et Prix2 même si le poste a déjà été révisé.

Il est surtout prévu pour être utilisé en mode "Remise à jour" pour recharger ponctuellement des indices qui auraient été mal chargés dans les contrats.

Pour mettre à jour les indices, le système procède donc de la façon suivante :
  • Pour Prix1 :

    · Si le poste n'a pas encore été révisé (date de dernière révision non renseignée : icf.datdrv = " "), le système recherche les indices avec la date limite de réactualisation du poste si elle est renseignée (cf PPE DATREV) sinon avec la date d'application du poste.

    · Si le poste a déjà été révisé et que le prix 1 était encore en vigueur lors de la dernière révision (icf.datdrv < icf.datapp2), la recherche des indices s'effectue à la date de dernière révision (icf.datdrv). Cette recherche est systématique si le mot clé "TOUT" est présent au niveau de l'instruction maquette MAJ_INDICE. Dans le cas contraire, cette recherche n'a lieu que si aucun indice n'a encore été mémorisé pour prix1 au niveau des zones paramétrées du poste.

  • Pour Prix2 :

    · Si le prix2 n'a pas encore été révisé (date de dernière révision non renseignée ou inférieure à la date limite de réactualisation du prix2 : icf.datdrv = " " ou icf.datdrv < date limite donnée par PPE DATREV), la recherche des indices s'effectue

    o à la date limite de réactualisation du prix2 si elle est renseignée

    o sinon à la date limite de réactualisation du poste (CF PPE DATREV) si elle est renseignée et inférieure à la date d'application du prix2,

    o à défaut à la date d'application du prix2.

    · Si le Prix2 a déjà fait l'objet d'une révision (Date de dernière révision connue et supérieure à la date limite de réactualisation du prix2), la recherche des indices s'effectue à la date de dernière révision. Comme pour le prix1, cette recherche est systématique si le mot clé "TOUT" est présent au niveau de l'instruction maquette MAJ_INDICE. Dans le cas contraire, cette recherche n'a lieu que si aucun indice n'a encore été mémorisé pour prix2 au niveau des zones paramétrées du poste

Remarque : Associer de préférence cette instruction maquette à l'instruction maquette DERNIERE_REVISION afin de n'affecter que la dernière version des contrats.