Document de release de la version H1.01

   Ce document présente les évolutions survenues sur le module Qualiac® Achats en H1.01.

      Afficher / Masquer le détail                                                   Format PDF

   Aucune modification de paramétrage n'est nécessaire pour que le fonctionnement soit comme avant le passage de la release.

   Le paramétrage à mettre en place est le suivant :

   - GRSMA : cette transaction permet de définir la règle de signature et conditionne le comportement d'ordre général de la validation qui y est paramétrée ;

   - GASMA : cette transaction permet de définir les actions proposées au signataire dans la transaction de signature (GSMxA). On peut également y définir les droits autorisés dans la transaction de détail de signatures (GDSMxA). De plus il est possible d'y associer des WIMs qui seront déclenchés au traitement d'affectation des signataires ou lors d'une signature ;

   - GCSMA : cette transaction permet de définir les critères qui vont permettre de déterminer les signataires ;

   - GMSMA : cette transaction permet de définir la matrice des signataires (utilisateur ou liste d'utilisateurs (GLUSA/GELUA)) pour chaque ensemble de critères précédemment définis ;

   - TASMDA, TASMCA, TASMRA, TASMFA et TASMMA: ces traitements d'affectations des signataires doivent être placés dans les étapes par classe (GETCA) pour les demandes d'achats, les commandes (avant ou après engagement), les réceptions, les factures (après comptabilisation si le BAP doit être donné), (GETCMA) pour les marchés comme suit :
           - mnémonique d'appel : TASMDA, TASMCA, TASMRA, TASMFA ou TASMMA,
           - traitement associé : SATASMD, SATASMC, SATASMR, SATASMF ou SATASMM,
           - traitement par commande ou par marché: pssaasmcetp,
           - traitement par autre entité : pssaasmcetp ;

   - GSMDA (GKSMDA), GSMCA (GKSMCA), GSMRA (GKSMRA), GSMFA (GKSMFA) et GSMMA (GKSMMA) : ces gestions de signatures doivent être placées dans les étapes par classe après les traitements d'affectations.
NB : si deux classes d'achats (ou de marchés) doivent avoir des règles de signatures différentes, alors le traitement d'affectation doit être dupliqué (mnémonique, transaction et traitement), ainsi que la gestion de signature ;

   - GDSMDA, GDSMCA, GDSMRA, GDSMFA, GDSMMA : ces transactions de détail des signatures multicritères des demandes d'achats, des commandes, des réceptions, des factures et des marchés permettent de visualiser les signataires intervenant pour une entité, leurs actions respectives (Acceptation, Transfert,...) et permettent également, en fonction des actions définies pour la transaction de détail (GASMA), de déterminer un signataire, modifier les signataires éventuellement d'attribuer par le traitement d'affectation des signataires ;

   - GGSMA : cette transaction permet de définir des délégations pour une règle de signature et une période. Dès la création d'un enregistrement dans cette transaction, une table de travail est mise à jour afin de gérer les délégations en cascade (par ex : le signataire A délègue au signataire B, qui délègue lui-même au signataire C).
Pour que ces délégations complexes soient prises en compte quotidiennement, il est nécessaire de lancer tous les jours (et ce hors période d'exploitation) le traitement d'affectation des délégations (TAGSM). Ce traitement a pour but d'alimenter le détail des signataires avec les délégations du jour. De plus, les délégations sont affectées lors de l'exécution du traitement d'affectation des signataires ;

   - TPSMA : ce traitement permet, à un utilisateur privilégié, de débloquer les demandes d'achats, les commandes, les réceptions, les factures ou les marchés qui seraient restées bloqués dans les tables de travail permettant de verrouiller les éléments en cours de signature ;

   - CDSMA : cette transaction permet de consulter les détails de signatures multicritères pour les demandes d'achats, les commandes, les réceptions ou les factures. Elle permet de visualiser les signataires :
           - qui ont été générés par les traitements d'affectation des signataires multicritères (TASMDA, TASMCA, TASMRA, TASMFA et/ou TAGSM) ;
           - ayant accepté ou refusé depuis les gestions de signatures multicritères (GSMDA, GSMCA, GSMRA et/ou GSMFA) ;

   - CDSMMA : permet de consulter les détails de signatures multicritères pour les marchés. Elle permet de visualiser les signataires :
           - qui ont été générés par le traitement d'affectation des signataires multicritères (TASMMA et/ou TAGSM) ;
           - ayant accepté ou refusé depuis la gestion de signatures multicritères (GSMMA).

   Un ensemble de requêtes permettant d'envoyer des WIMs sont également à disposition afin :

   - d'informer les signataires qu'ils ont une demande d'achats, une commande, une réception, une facture ou un marché à signer :
             - QLC_SAC_SMC_DA_UNI_SIG : demande d'achats à signer,
             - QLC_SAC_SMC_CDA_UNI_SIG : commande à signer,
             - QLC_SAC_SMC_REC_UNI_SIG : réception à signer,
             - QLC_SAC_SMC_FAA_UNI_SIG : facture à signer,
             - QLC_SAC_SMC_MAR_UNI_SIG : marché à signer ;

   - d'informer les créateurs ou les gestionnaires que leur demande d'achats, leur commande, leur réception, leur facture ou leur marché est accepté(e) :
             - QLC_SAC_SMC_DA_UNI_RET_OK : demande d'achats acceptée,
             - QLC_SAC_SMC_CDA_UNI_RET_OK : commande acceptée,
             - QLC_SAC_SMC_REC_UNI_RET_OK : réception acceptée,
             - QLC_SAC_SMC_FAA_UNI_RET_OK : facture acceptée,
             - QLC_SAC_SMC_MAR_UNI_RET_OK : marché accepté ;

   - d'informer les créateurs ou les gestionnaires que leur demande d'achats, leur commande, leur marché est refusé(e) pour re-soumission :
             - QLC_SAC_SMC_DA_UNI_RET_KO_RR : demande d'achats refusée pour re-soumission,
             - QLC_SAC_SMC_CDA_UNI_RET_KO_RR : commande refusée pour re-soumission,
             - QLC_SAC_SMC_MAR_UNI_RET_KO_RR : marché refusé pour re-soumission ;

   - d'informer les créateurs ou les gestionnaires que leur demande d'achats, leur commande, leur réception, leur facture ou leur marché est refusé(e) pour annulation :
             - QLC_SAC_SMC_DA_UNI_RET_KO_RA : demande d'achats refusée pour annulation,
             - QLC_SAC_SMC_CDA_UNI_RET_KO_RA : commande refusée pour annulation,
             - QLC_SAC_SMC_MAR_UNI_RET_KO_RA : marché refusé pour annulation.

   Ces différentes requêtes sont à définir au niveau des actions des signatures multicritères (GASMA).

   Les requêtes suivantes permettent d'avoir des WIMS récapitulatifs afin :

   - d'informer les signataires de toutes les demandes d'achats, les commandes, les réceptions, les factures ou les marchés en attente de validation de leur part, pour une sélection d'établissements et de règles de signatures :
             - QLC_SAC_SMC_DA_RPF_SIG : liste des demandes d'achats en attente de validation,
             - QLC_SAC_SMC_CDA_RPF_SIG : liste des commandes en attente de validation,
             - QLC_SAC_SMC_REC_RPF_SIG : liste des réceptions en attente de validation,
             - QLC_SAC_SMC_FAA_RPF_SIG : liste des factures en attente de validation,
             - QLC_SAC_SMC_MAR_RPF_SIG : liste des marchés en attente de validation ;

   - d'informer les créateurs ou gestionnaires des demandes d'achats, des commandes ou des marchés pour lesquels un retour a été effectué : QLC_SAC_SMC_RPF_RET.

   Ces différentes requêtes doivent être lancées à partir du traitement RSMCA.

GRSMA - Règles des signatures multicritères (Transaction SAIRSM)
GASMA - Actions des signatures multicritères (Transaction SAIASM)
GCSMA - Critères de signatures (Transaction SAICSM)
GMSMA - Matrice des signatures multicritères (Transaction SAIMSM)
GGSMA - Délégations des signatures multicritères (Transaction SAIGSM)
GDSMDA - Détail des signatures multicritères des DA (Transaction SAIDSMD)
GDSMCA - Détail des signatures multicritères des commandes (Transaction SAIDSMC)
GDSMRA - Détail des signatures multicritères des réceptions (Transaction SAIDSMR)
GDSMFA - Détail des signatures multicritères des factures (Transaction SAIDSMF)
GDSMMA - Détail des signatures multicritères des marchés (Transaction SAIDSMM)
TASMDA - Affectation des signataires multicritères des DA (Transaction SATASMD)
TASMCA - Affectation signataires multicritères commandes (Transaction SATASMC)
TASMRA - Affectation signataires multicritères réceptions (Transaction SATASMR)
TASMFA - Affectation des signataires multicritères factures (Transaction SATASMF)
TASMMA - Affectation signataires multicritères marchés (Transaction SATASMM)
GSMDA - Signatures multicritères des demandes d'achats (Transaction SAISMD)
GKSMDA - Signatures multicritères des demandes d'achats (Transaction SAISMD)
GSMCA - Signatures multicritères des commandes d'achats (Transaction SAISMC)
GKSMCA - Signatures multicritères des commandes d'achats (Transaction SAISMC)
GSMRA - Signatures multicritères des réceptions (Transaction SAISMR)
GKSMRA - Signatures multicritères des réceptions (Transaction SAISMR)
GSMFA - Signatures multicritères des factures d'achats (Transaction SAISMF)
GKSMFA - Signatures multicritères des factures d'achats (Transaction SAISMF)
GSMMA - Signatures multicritères des marchés (Transaction SAISMM)
GKSMMA - Signatures multicritères des marchés (Transaction SAISMM)
TAGSM - Affectation délégations signatures multicritères (Transaction SATAGSM)
TAREQS - Exécution WIM signatures multicritères (Transaction SATREQS)
RSMCA - WIM récapitulatif des signatures multicritères (Transaction SARSMC)
TPSMA - Purge des signatures multicritères (Transaction TPSMA)
CDSMA - Consultation des signatures multicritères (Transaction SACDSM)
CDSMMA - Consultation des signatures multicritères marchés (Transaction SACDSMM)

   Nécessité de formation.

   Les fournisseurs sont sélectionnés à partir d'une fourchette d'établissements, une fourchette de fournisseurs et/ou à partir de la forme sélection des fournisseurs.

   Pour chaque fournisseur sélectionné, il est possible de contrôler l'appartenance ou la non appartenance de celui-ci soit à une liste de commandes soit à un ensemble de commandes représentées par des fourchettes de classes, de numéros et de sous-numéros et par des critères supplémentaires définis dans la forme sélection des commandes. Le choix du type de contrôle à effectuer est défini, à la soumission, grâce au bouton de choix "Appartient/N'appartient pas".

   Les fournisseurs identifiés comme possédant ou ne possédant pas de commandes peuvent ensuite être marqués. La zone utilisée pour le marquage, ainsi que la valeur à lui affecter, sont données à la soumission du traitement. La zone à marquer correspond à une information de la fiche fournisseur et à une occurrence du paramètre COLIDFOU :
- état ;
- cotation ;
- genre ;
- nature ;
- rating ;
- type.

   Le marquage d'une des zones de la fiche fournisseur n'est pas obligatoire. Si la zone à marquer n'est pas renseignée, les fournisseurs identifiés sont juste édités.

TIFOA - Identification des fournisseurs (Transaction SATIFO)

   Prenons pour exemple la comptabilisation d'une facture de 100 EUR. Le jeu d'écritures attendu est le suivant :

   Si la valeur testée 1 de l'occurrence GESM9 du paramètre AUTM9 est égale à "A" et si la valeur du paramètre PRM associé au traitement du transfert en comptabilité des factures (SATVCC) est égale à "CP", le TVCC a été modifié afin de :
- regrouper les mouvements d'annulation de FNP et les mouvements de comptabilisation de la facture ;
- les mouvements d'annulation de FNP sont flagués avec le C01OCMVC égal à "P" ;
- les comptes de charges et d'immobilisations sont conservés pour des raisons techniques :
       - les comptes sont remplacés selon les occurrences du paramètre AUTM9 :
              - la chaîne 1 de l'occurrence CPTACHI donne un compte 9 défini en TVA interdite,
              - la chaîne 1 de l'occurrence CPTACHF donne un compte 9 défini en TVA facultative,
              - la chaîne 1 de l'occurrence CPTACHO donne un compte 9 défini en TVA obligatoire,
       - la chaîne 1 du paramètre AUTM9 occurrence CPTAORI donne la zone du mouvement (GMVC) dans laquelle va être mémorisé le compte d'origine (G01 pour l'identifiant long 1, G02 pour l'identifiant long 2, I01 pour l'identifiant 1, I02 pour l'identifiant 2, I03 pour l'identifiant 3, I04 pour l'identifiant 4).

   L'écriture ainsi obtenue :

   Remarques :

   1) Dans le cadre de la GBCP, les engagements de commande ne doivent pas être annulés par l'écriture de FNP, il est donc nécessaire de positionner la valeur du paramètre PRM à "E" pour le traitement associé à la facture non parvenue (TVCCP).

   2) Les journaux définis pour les types de ventilations concernant l'engagement et la facture non parvenue ne doivent pas être définis en lettrage achats.

   3) Pour les types de ventilations concernant la facture non parvenue et la comptabilisation de la facture, le regroupement des mouvements doit être défini en détaillé.

   4) Selon si c'est le tiers de paiement ou le tiers de facturation qui est affecté dans le tiers auxiliaire de la pièce générée par le transfert en comptabilité, le tiers de paiement (ou de facturation) de la facture ne peut pas être différent du tiers de paiement (ou de facturation) de la commande rattachée à la facture.

   De plus, il est désormais possible, lors des différents transferts en comptabilité (TVCCx), de renseigner la date 1 et la date 2 des mouvements générés. Pour cela, le paramétrage des transferts en comptabilité (GTVCA) a été modifié afin de pouvoir indiquer comment sont affectées les dates 1 et 2. Les valeurs sont des occurrences du paramètre D01SGTVC.

GTVCA - Paramétrage transfert comptabilité achat (Transaction SAITVC)
TVCCE - Engagement (Transaction SATVCCE)
TVCCP - Factures non parvenues (Transaction SATVCCP)
TVCC - Comptabilisation des factures (Transaction SATVCC)
CVCC - Consultation des ventilations comptables achats (Transaction SACVCC)

   Nécessité de formation.

   Les avances vont donc être saisies :
- sur une classe d'achats dédiée pour laquelle le contrôle "Mise à jour marché" est égal à "Pas de contrôle" et pour laquelle aucun traitement de cumul des commandes d'achats dans les marchés (TMARAx) n'est défini dans le circuit des étapes par classes (GETCA). Ceci, afin que les avances n'aient aucun impact sur la mise à jour des marchés (GMARA/GMADA) ;
- un mode d'achat avec influence sur marché, afin de pouvoir mettre à jour l'avance facturée (TMCSA) au niveau des compléments de marchés publics (GCMP) ;
- des comptes d'avances définis en génération de pièces et en TVA interdite.
De plus, le type de ventilation facture (GTVCA) à partir duquel l'écriture d'avance va être générée (TVCC), doit être défini avec "Regroupement des mêmes échéances".

   Les factures de prestations ou de marchandises vont être saisies sur une autre classe d'achats au fur et à mesure que celles-ci arrivent. Et le moment venu, il faut donc rapprocher la facture de prestation ou de marchandises à la pièce d'avance, et ceci pour une partie de son montant.
Ce rapprochement avec la pièce d'avance va s'effectuer à partir de la transaction de récupération d'avances (SAIRAA) accessible à partir :
- des commandes (GCDA) ;
- des lignes de commandes à facturer (SAIFLC) ;
- des lignes de facture (SAILCF).

   Puis un nouveau traitement par étape, récupération d'avances (TRAA), défini dans les étapes par classes (GETCA) avant la comptabilisation de la facture (TVCC) va permettre :
- de générer une écriture d'avance ;
- d'extourner partiellement la pièce d'origine en associant celle-ci avec la pièce générée sur la facture d'avance ;
- d'associer la nouvelle pièce générée à la commande en cours de facturation dans les associations commandes d'achats - pièces (GPIAA). Le traitement de comptabilisation de la facture (TVCC) qui va suivre va, grâce à cette association, associer la pièce de récupération à la pièce de facture afin de réduire le montant à payer au fournisseur ;
- de mettre à jour l'avance récupérée des compléments de marché public (GCMP) de type CS liés à la facture.

   Pour ce nouveau traitement de récupération d'avances (TRAA), il va être nécessaire de définir un nouveau paramétrage de transfert en comptabilité (GTVCA) de type "Récupération d'avance".

   De plus, pour alerter l'utilisateur qu'une récupération d'avance pourrait être saisie sur la facture dès lors que le montant facturé à atteint un certain pourcentage (65 %) du montant prévu, le traitement de mise à jour des montants co-traitants/sous-traitants (TMCSA) a évolué. Il alerte désormais l'utilisateur (message non bloquant), dès lors que :
- le ratio entre montant facturé et le montant prévu des compléments de marché public (GCMP) de type CS mis à jour atteint un certain pourcentage et ne dépasse pas un certain pourcentage : cette fourchette de pourcentages est à définir dans les valeurs 1 et 2 du paramètre AUTSAMCS occurrence F-x-MAJ où x représente C ou S selon si la mise à jour concerne des co-traitants (C) ou des sous-traitants (S) ;
- l'avance récupérée est inférieure à l'avance facturée.

   Il faut donc que le traitement de mise à jour des montants co-traitants/sous-traitants (TMCSA) soit défini dans les étapes par classe (GETCA) :
- après la saisie de factures (GKFAA) ;
- avant le traitement de récupération d'avances (TRAA) ;
- exécutable en interactif et avec arrêt proposition.

   Prenons pour exemple, une avance de 100 EUR et une récupération partielle de 40 EUR :

   1) Saisie de la facture d'avance de 100 EUR et comptabilisation de celle-ci :

La pièce P1 sera soldée par un compte de banque afin d'être payée.

   2) Saisie d'une facture de 1000 EUR sur le marché, de la récupération de l'avance de 40 EUR dans la transaction de récupération d'avances (SAIRAA) et comptabilisation de cette dernière (TRAA) :

Les pièces P2 et P3 sont associées. Le solde de la pièce P2 est alors de 60 EUR. La pièce P4 est associée automatiquement à la facture dans les associations commandes d'achats - pièces (GPIAA).

   3) Comptabilisation de la facture (TVCC) avec ici annulation de la FNP (contexte GBCP) :

Conséquence directe de l'association de la pièce de récupération d'avance à la facture (GPIAA), la pièce P4 est associée à la pièce de facture P5. Le montant de 1200 EUR à régler au fournisseur sera donc amputé de 40 EUR.

SAIRAA - Récupération d'avances ou d'acomptes (Transaction SAIRAA)
TRAA - Récupération d'avances (Transaction SATRAA)
GTVCA - Paramétrage transfert comptabilité achat (Transaction SAITVC)
TMCSA - Mise à jour des montants co-traitant/sous-traitant (Transaction SATMCS)
GCDA - Commandes d'achats (Transaction SAICDA)
SAIFLC - Lignes à facturer (Transaction SAIFLC)
SAILCF - Lignes de facture (Transaction SAILCF)
TSRD - Annulation de demandes d'achats ou de commandes (Transaction SATSRD)
TRSF - Commandes réceptionnées sans facture (Transaction SATRSF)
TACRA - Annulation d'une commande réceptionnée (Transaction SATACR)
TAFAA - Annulation facture (Transaction SATAFA)

   Nécessité de formation.

   Récupération d'avances (TRAA) :
Ce traitement doit être situé dans les étapes par classe (GETCA) après la mise à jour des montants co-traitant/sous-traitant (TMCSA) et avant le traitement comptabilisation de la facture (TVCC) comme suit :
- mnémonique d'appel : TRAA ;
- traitement associé : SATRAA ;
- traitement par commande : pssaraaetp ;
- traitement par autre entité : pssaraaetp ;
- mnémonique des critères : SATRAA.

   Lors de l'enregistrement de factures de sous-traitance, il apparaît difficile, voire impossible, pour l'utilisateur, de rapprocher à chaque ligne de sous-commande, la part de chaque sous-traitant. Un nouveau principe de saisie est alors introduit pour ne pas avoir à rapprocher les lignes de sous-traitance des lignes de commandes de manière détaillée.

   L'idée de base est :
- d'une part, de déduire sur la facture du titulaire, chaque part de chaque sous-traitant, ceci par la création d'une ou plusieurs lignes négatives. Ces lignes ont le type égal à "S" ;
- d'autre part, de créer une facture directe positive (facture sans commande) pour chaque sous-traitant ayant une ligne négative. La nature de cette facture est positionnée à "S".

   Afin de conserver la cohérence avec le suivi, côté marché, il faut que chaque ligne qui est créée (négative ou positive) :
- ait influence sur les marchés (via le mode d'achat) ;
- pointe sur une ligne de marché (le sous-traitant pouvant être déclaré à la ligne de marché, à la tranche, ou globalement au marché).

   Ainsi, l'utilisateur doit cibler sur quelle ligne "modèle" il veut déclarer un sous-traitant :
- code article et nature de frais permettent d'indiquer quelle ligne de marché est impactée (donc quelle fiche sous-traitant est mise à jour dans les compléments de marchés publics) ;
- compte, poste, CGR A et B sont utilisés pour la création des lignes négatives et positives.

   Sur la ligne modèle, l'utilisateur doit déclarer :
- le code fournisseur du sous-traitant. Sont alors proposés les tiers et adresses de facture et de paiement, l'échéance, la domiciliation bancaire. Ces informations sont modifiables ;
- le montant HT à attribuer à ce sous-traitant (le taux de TVA sera identique au taux de TVA de la "ligne modèle" ou égal à 0). Si le sous-traitant n'est pas soumis au même régime, il n'est pas nécessaire de changer la TVA ici : le traitement le fera automatiquement au moment de la génération de la nouvelle facture, en fonction des type, mode et régime du sous-traitant.

   Cette déclaration se fait dans une nouvelle gestion car il est possible de déclarer plusieurs sous-traitants sur la même ligne modèle. Cette gestion (SAICSF) est appelable depuis les lignes de factures.

   La somme des montants déclarés pour les sous-traitants d'une ligne de facture peut dépasser le montant de la ligne. Un paramètre permet toutefois d'activer ou non ce contrôle. Il s'agit du paramètre AUTSACSF occurrence CTLMNT.
Si la valeur testée 1 vaut :
- O : le contrôle est activé ;
- N : le contrôle n'est pas activé.

   Il est également possible de contrôler que le tiers sous-traitant soit déclaré sur le marché. Cela dépend du paramètre AUTSACSF occurrence CTLTIE.
Si la valeur testée 1 vaut :
- O : le contrôle est effectué ;
- N : le contrôle n'est pas effectué.

   Cette génération peut être effectuée, facture par facture, à partir d'un nouvel écran SAIGFCS, appelable depuis l'en-tête de facture (GFAA), ou, pour un ensemble de factures, à partir d'un traitement avec soumission TGFCSA.

   Une nouvelle consultation Suivi des factures générées (CSVFA) a été créée afin de pouvoir retrouver les factures générées.

GFAA - Contrôle facture (Transaction SAIFAA)
SAILCF - Lignes de facture (Transaction SAILCF)
SAICSF - Co-traitants/sous-traitants de la facture (Transaction SAICSF)
SAIGFCS - Génér. de factures de co-traitance/sous-traitance (Transaction SAIGFCS)
TGFCSA - Trt de génér. de factures de co/sous-traitance (Transaction SATGFCS)
CSVFA - Consultation du suivi des factures (Transaction SACSVF)

   Nécessité de formation.

   1) Pour cela, une nouvelle case à cocher "Contrôle des dates" a été ajoutée au niveau de la classe de marchés (GNCM). Pour que les contrôles sur les dates soient effectués, il faut que cette case soit cochée et que la typologie de marché de la classe de marchés soit renseignée.

   Plusieurs types de contrôles ont été ajoutés :
- des contrôles entre les dates du marché et les dates des lignes du marché ;
- des contrôles entre les dates du marché et/ou des lignes du marché et les dates des commandes rattachées à ce marché ;
- des contrôles entre les dates du marché et/ou des lignes du marché et les dates de réception des commandes rattachées à ce marché.

   a) Contrôles entre les dates du marché et des lignes du marché :
- si elle est renseignée, la date de notification du marché doit être comprise dans la période de validité du marché ;
- si elle est renseignée, la date de notification de la ligne de marché doit être comprise dans la période de validité du marché ;
- la date de notification de la ligne de marché doit être supérieure ou égale à la date de notification du marché. Le contrôle n'est effectué que si les deux dates sont renseignées ;
- si elle est renseignée, la date de livraison prévue de la ligne de marché doit être comprise dans la période de validité du marché ;
- la date de livraison de la ligne de marché doit être supérieure ou égale à la date de notification du marché. Le contrôle n'est effectué que si les deux dates sont renseignées ;
- la date de livraison de la ligne de marché doit être supérieure ou égale à la date de notification de la ligne de marché. Le contrôle n'est effectué que si les deux dates sont renseignées ;
- la date de livraison de la ligne de marché doit être supérieure ou égale à la date de début d'exécution de la ligne de marché. Le contrôle n'est effectué que si les deux dates sont renseignées ;
- si elle est renseignée, la date de début d'exécution de la ligne de marché doit être comprise dans la période de validité du marché ;
- la date de début d'exécution de la ligne de marché doit être supérieure ou égale à la date de notification du marché. Le contrôle n'est effectué que si les deux dates sont renseignées ;
- la date de début d'exécution de la ligne de marché doit être supérieure ou égale à la date de notification de la ligne de marché. Le contrôle n'est effectué que si les deux dates sont renseignées.

   b) Contrôles entre les dates du marché et/ou des lignes du marché et les dates des commandes rattachées à ce marché :
- pour pouvoir saisir une commande sur un marché, il faut que la date de notification du marché soit renseignée ;
- la date de commande doit être supérieure ou égale à la date de notification du marché ;
- la date au plus tôt de la commande doit être supérieure ou égale à la date de notification du marché ;
- la date prévue de la ligne de commande si elle est renseignée sinon, la date au plus tôt de la commande doit être supérieure ou égale à la date de début d'exécution de la ligne de marché correspondant à la ligne de commande. Si la date de début d'exécution de la ligne de marché n'est pas renseignée, le contrôle n'est pas effectué ;
- la date prévue de la ligne de commande si elle est renseignée sinon, la date au plus tôt de la commande doit être supérieure ou égale à la date de livraison de la ligne de marché correspondant à la ligne de commande. Si la date de livraison de la ligne de marché n'est pas renseignée, le contrôle n'est pas effectué ;
- la date prévue de la ligne de commande si elle est renseignée sinon, la date au plus tôt de la commande doit être supérieure ou égale à la date de notification du marché.

   c) Contrôles entre les dates du marché et/ou des lignes du marché et les dates de réception des commandes rattachées à ce marché :
- la date de réception doit être supérieure ou égale à la date de notification du marché des commandes de la réception ;
- la date de réception doit être supérieure ou égale à la date de début d'exécution de chaque ligne du marché des commandes de la réception.
Ces contrôles ne sont pas effectués directement à la saisie de la réception mais par un nouveau traitement par étape (TCDMPA) qui doit être défini, dans les étapes (GETPA) et les étapes par classe (GETCA) de la façon suivante :
- mnémonique d'appel : TCDMPA ;
- traitement associé : SATCDMP ;
- traitement par commande : pssacdmpetp ;
- traitement par autre entité : pssacdmpetp.

   2) Ajout de contrôles sur la période de validité, sur les montants et sur la cohérence des tiers entre les marchés subséquents et l'accord cadre.
Pour cela, ajout de 3 nouvelles cases à cocher au niveau de la classe de marchés (GNCM) : "Contrôle des dates", "Contrôle des montants" et "Contrôle des tiers".

   a) Contrôle des dates :
Pour que ce contrôle soit effectué, il faut que la case à cocher "Contrôle des dates" soit cochée. Le contrôle effectué est : les périodes de validité des marchés subséquents doivent être comprises dans celle de l'accord cadre.

   b) Contrôle des montants :
Pour que ces contrôles soient effectués, il faut que la case à cocher "Contrôle des montants" soit cochée. Les contrôles effectués sont :
- la devise des marchés subséquents doit être la même que celle de l'accord cadre correspondant ;
- la somme des montants prévus des marchés subséquents doit être inférieure ou égale au montant prévu de l'accord cadre correspondant.

   c) Contrôle des tiers :
Pour que ces contrôles soient effectués, il faut que la case à cocher "Contrôle des tiers" soit cochée. Les contrôles effectués sont :
- le fournisseur du marché subséquent doit être le même que celui de l'accord cadre ou être égal à un fournisseur co-traitant de l'accord cadre ;
- les fournisseurs co-traitants des marchés subséquents doivent être égaux au fournisseur de l'accord cadre ou à un fournisseur co-traitant de l'accord cadre ;
- les couples fournisseurs co-traitants / fournisseurs sous-traitants des marchés subséquents doivent se trouver parmi les couples fournisseurs co-traitants / fournisseurs sous-traitants de l'accord cadre.

   Pour que ces contrôles soient effectués, les cases à cocher doivent être activées sur la classe de marchés de l'accord cadre.

GNCM - Classes de marchés (Transaction SAINCM)
GMARA - Marchés (Transaction SAIMAR)
GMADA - Lignes de marchés de type 1 (Transaction SAIMAD)
GMALA - Lignes de marchés de type 2 (Transaction SAIMAL)
GCDA - Commandes d'achats (Transaction SAICDA)
GLCA - Lignes de commandes d'achats (Transaction SAILCA)
GREC - Contrôle des réceptions (Transaction SAIREC)

   Cette possibilité est donnée par l'occurrence MARG05 du paramètre AUTACHAT.
Si la valeur testée 1 vaut :
- O : recopie du marché dans l'identifiant 5 des lignes ;
- N : pas de recopie du marché dans l'identifiant 5 des lignes.

   Cette valeur testée est initialisée à "N" par la release.

   Cette fonctionnalité doit être activée pour les marchés publics.

GDAI - Demandes d'achats (Transaction SAIDAE)
GDAL - Lignes de demandes d'achats (Transaction SAIDAL)
GCDA - Commandes d'achats (Transaction SAICDA)
GLCA - Lignes de commandes d'achats (Transaction SAILCA)
GREC - Contrôle des réceptions (Transaction SAIREC)
SAILCR - Lignes de réceptions en quantité (Transaction SAILCR)
SAILRM - Lignes de réceptions en montant (Transaction SAILRM)
GFAA - Contrôle facture (Transaction SAIFAA)
SAILCF - Lignes de facture (Transaction SAILCF)

   Prise en compte des validités à date (GTDTE/GTCDT) lors du contrôle de la domiciliation dans Qualiac® Achats.

GCAE - Echéances des commandes (Transaction SAICAE)

   Ajout de la possibilité d'effectuer un retour à l'étape initiale pour un marché pour lesquelles il existe des commandes réceptionnées et/ou facturées.

   Pour cela, au niveau de la classe de marchés (GNCM), la case à cocher "Marché avec commande" a été remplacée par un bouton de choix :
- Sans commande : il n'est pas possible d'effectuer un retour à l'étape initiale pour un marché pour lequel il existe des commandes ;
- Avec commandes non réceptionnées, non facturées : un retour à l'étape initiale est possible pour un marché pour lequel il existe des commandes à condition que ces commandes ne soient ni réceptionnées, ni facturées ;
- Avec commandes réceptionnées ou facturées : un retour à l'étape initiale est possible pour un marché pour lequel il existe des commandes réceptionnées et/ou facturées.

GNCM - Classes de marchés (Transaction SAINCM)
GMARA - Marchés (Transaction SAIMAR)
TREIMA - Retour à l'étape initiale pour les marchés (Transaction SATEIM)

   Dans le cadre de la génération automatique des fournisseurs à partir des tiers par établissement (paramètre AUTSAFOU occurrence GENERE), ajout de la possibilité, de répercuter la modification du rating et/ou de la cotation du tiers par établissement (GATE) sur le fournisseur (GFOU).

   Pour cela, deux nouvelles occurrences MAJRAT et MAJCOT ont été ajoutées au paramètre AUTSAFOU.

   Si la valeur testée 1 de l'occurrence MAJRAT vaut :
- O : mise à jour du rating du fournisseur à partir de celui du tiers par établissement ;
- N : pas de mise à jour du rating du fournisseur.

   Si la valeur testée 1 de l'occurrence MAJCOT vaut :
- O : mise à jour de la cotation du fournisseur à partir de celle du tiers par établissement ;
- N : pas de mise à jour de la cotation du fournisseur.

   Ces deux valeurs testées sont initialisées à « N » par la release.

GATE - Associations des tiers aux établissements (Transaction OEIATE)
GFOU - Fournisseurs (Transaction SAIFOU)

   Modification du traitement de confirmation de commandes (TCDA) afin de remplacer l'échéance créée par défaut lors de la création de la commande par une échéance particulière pour les piges.

   Si l'occurrence STAxxxx du paramètre AUTSADAU (xxxx représente la classe d'achats) existe, si le statut est renseigné sur la commande et si la valeur testée 1 de l'occurrence ECH-xxxx (xxxx représente la classe) du paramètre AUTSADAU est égale à "O", suppression de l'échéance de la commande afin de recréer celle-ci en fonction des données du tiers par établissement (GATE) définies pour le tiers et le statut :
- proposition du mode, du délai et de la date de règlement ainsi que de la domiciliation et du type de collectif (GATE) ;
- recherche d'une échéance à 100 % pour le mode, le délai et la date de règlement (GECH et GECD). Si aucune échéance n'est trouvée, le traitement sort en erreur ;
- proposition du compte collectif et des CGR en fonction de ce qui est défini dans la gestion des comptes collectifs par classe d'achats (GCCOA).
Si l'occurrence ECH-xxxx du paramètre AUTSADAU n'existe pas ou si la valeur testée 1 est égale à "N", l'échéance origine est conservée pour la commande.

   Remarques :
- ce fonctionnement implique que l'on perd toute modification manuelle des échéances dans GCAE ;
- ce principe ne fonctionne pas en facturation directe.

TCDA - Confirmation des commandes (Transaction SATCCDA)

   Modification de la gestion de modification de masse des échéances (GMCAE) afin d'ajouter la possibilité de :
- supprimer ou ajouter une échéance ;
- remplacer une échéance par une autre.

   Pour cela, ajout du champ "Action" permettant de choisir l'action à effectuer pour toutes les commandes sélectionnées : Créer, Modifier, Remplacer, Supprimer.

   Ajout des champs échéance et échéance détail dans le masque principal. Ces champs ne sont accessibles qu'en création ou en remplacement d'échéance. Ils permettent de préciser l'échéance à créer.
Le champ échéance détail n'est pas obligatoire. S'il n'est pas renseigné, création de toutes les échéances détail correspondant à l'échéance précisée.

GMCAE - Modification des échéances (Transaction SAMCAE)
GMCAEC - Modification des échéances (Comptabilité) (Transaction SAMCAE)

   1) Ajout de la possibilité de trier les lignes de commandes par date de livraison prévue.

   2) Lors de l'envoi par fax ou par mail du bon de commande pour une commande (classe, numéro), possibilité d'envoyer un fichier pour chaque sous-commande (classe, numéro et sous-numéro) ou pour la commande (classe, numéro).

   3) Ajout de la possibilité d'afficher le dernier signataire de plus haut niveau des signatures multicritères lors de l'édition de la commande. Ce signataire n'est affiché qu'une fois que la commande a atteint l'étape du bon de commande.

   1) Jusqu'à présent, il était possible de trier les lignes de commandes par numéro de ligne ou par dépôt. Cela dépendait du paramètre DEP associé au traitement (GTRB).
Il est dorénavant possible de trier les lignes par date de livraison.
Pour cela, le paramètre DEP a été supprimé et remplacé par le paramètre TRI. Si le paramètre TRI existe et si sa valeur vaut :
- DEP : les lignes de commandes sont triées par dépôt ;
- DAT : les lignes de commandes sont triées par date de livraison prévue.
Si le paramètre TRI n'est pas présent, le tri se fait par numéro de ligne de commande.

   Le paramètre TRI est initialisé, par la release, en fonction du paramètre DEP. Si la valeur du paramètre DEP est égale à "O", la valeur du paramètre TRI est positionnée à "DEP" sinon le paramètre TRI n'est pas créé.

   2) Cela dépend de l'occurrence TYPFIC du paramètre EDTBCDEA. Si la valeur testée 1 vaut :
- C : envoi d'un fichier par commande (classe, numéro) ;
- S : envoi d'un fichier par sous-commande (classe, numéro et sous-numéro). Pour chaque sous-commande, un en-tête complet est édité sur la première page et réduit sur les pages suivantes. Les conditions de facturation sont éditées pour chaque sous-commande. Ce fonctionnement n'est possible que si un saut de page à la sous-commande a été demandé à la soumission.

   La valeur testée 1 est initialisée à "C" par la release.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   3) Dans les paramètres supportés par un objet (GTIOBP), créer le paramètre SIG, pour l'objet (GOBJ) saebcda2.sqt, avec comme valeur, la règle de signature (GRSMA) associée à l'entité SACDA pour laquelle il faut éditer le signataire.

   Dans les paramètres d'un traitement (GTITBP), créer le paramètre SIG, pour le traitement (GTRB) correspondant à votre bon de commande (SAEBCDA2 en standard), avec la valeur égale à votre règle de signature.

   Les variables suivantes peuvent ensuite être utilisées dans les mises en forme Qualiac^® Edition :
- $aplsigsmc : code du gestionnaire signataire des signatures multicritères ;
- $codesigsmc : code du dernier signataire des signatures multicritères de la commande ;
- $nomsigsmc : nom du dernier signataire des signatures multicritères de la commande ;
- $wnmpmgessigsmc : nom + prénom du gestionnaire associé à l'utilisateur signataire des signatures multicritères de la commande ;
- $wnomgessigsmc : nom du gestionnaire associé à l'utilisateur signataire des signatures multicritères de la commande ;
- $wprngessigsmc : prénom du gestionnaire signataire des signatures multicritères de la commande.

   Dans le cas où la date de réception n'est pas saisie à la soumission et que le regroupement des commandes n'est pas demandé (case à cocher "Regroupement des commandes" non cochée), ajout de la possibilité de proposer la date de réception à partir d'une des dates de la commande.

   Cette possibilité est donnée par l'occurrence DATCDE du paramètre AUTSAREC.
Si la valeur testée 1 vaut :
- C : la date de réception est égale à la date de commande de la commande ;
- RD : la date de réception est égale à la date au plus tôt de la commande ;
- RF : la date de réception est égale à la date au plus tard de la commande.

   Si cette occurrence n'existe pas ou si la date à prendre en compte n'est pas renseignée, la date de réception est renseignée, comme auparavant, en fonction de l'occurrence xDATREC du paramètre AUTSAREC (x représente la valeur du paramètre PR3 associé au mnémonique de la réception),

   Cette occurrence n'est pas livrée par la release.

TGREC - Génération automatique de réceptions (Transaction SATGREC)
TGREE - Génération automatique de réceptions (étape) (Transaction SATGREE)

   Ajout de la possibilité d'effectuer la réception à partir de la consultation des lignes de commandes.

   Pour cela, les mnémoniques de saisie de réceptions (GREC, GKREC, GRCPA) sont accessibles à partir de la consultation des lignes de commandes (CLCA) et le paramètre PR2 associé au mnémonique de la consultation a été ajouté.
Si la valeur du paramètre PR2 vaut :
- N : la gestion des réceptions (GREC, GKREC ou GRCPA) n'est pas accessible et il n'est pas possible de réceptionner la commande visualisée ;
- Q : la gestion des réceptions (GREC, GKREC ou GRCPA) est accessible et il est possible d'effectuer la réception à partir des éléments de la commande visualisée (établissement, classe, numéro, sous-numéro). Une fois la réception validée (GREC, GKREC) ou générée (GRCPA), une recherche automatique des lignes de commandes correspondantes aux critères préalablement saisis est effectuée.

   La valeur du paramètre PR2 est initialisée à "N" par la release.

   NB : si la commande sur laquelle l'utilisateur est positionné, dans la consultation, est déjà réceptionnée, il est possible d'accéder aux gestions de réceptions GREC ou GKREC pour visualiser la réception quelle que soit la valeur du paramètre PR2 associé au mnémonique. Par contre, la gestion de réceptions GRCPA est inaccessible.

CLCA - Consultation des lignes de commandes d'achats (Transaction SACLCA)
GREC - Contrôle des réceptions (Transaction SAIREC)
GKREC - Contrôle des réceptions (Transaction SAIREC)
GRCPA - Réception (Transaction SAIRCP)

   Modification de l'édition afin de rendre celle-ci compatible Qualiac® Edition.

EETQR - Etiquettes de réception (Transaction SAEETQR)
RETQR - Réédition des étiquettes de réception (Transaction SARETQR)

   1) Ajout de la possibilité d'effectuer le contrôle qualité pour les achats stockés.

   2) Ajout de la possibilité d'effectuer la réception qualitative dès la réception.

   1) Cette possibilité est donnée par l'occurrence RQLSTOCK du paramètre AUTSAREC.
Si la valeur testée 1 vaut :
- O : le contrôle qualité est autorisé pour les achats stockés ;
- N : le contrôle qualité n'est pas autorisé pour les achats stockés.

   Cette valeur testée est initialisée à "N" par la release.

   2) Jusqu'à présent, le code qualité ne pouvait être saisi que lors de la réception qualitative dans GRQL. Dorénavant, le code qualité peut être saisi dès la réception.
Pour cela, le code qualité a été ajouté dans :
- les lignes de réceptions en quantité (SAILCR) ;
- les lignes de réceptions en montant (SAILRM) ;
- le sas des lignes de réceptions (SAITRL) ;
- la réception (GRCPA) ;
- la réception détail (SAIRDT) ;
- la réception détaillée (GRPLA) et la réception détaillée par utilisateur (GRPLU).

   De plus, pour pouvoir faire de la réception qualitative dans l'e-Procurement, il faut modifier les personnalisations des transactions SBIRCP et SBIRDT :
- SBIRCP (Réception) : il faut ajouter le champ de saisie CRQSARCP dans la grille et le champ de saisie WCRQ dans le masque au-dessus de la grille ;
- SBIRDT (Réception détail) : il faut ajouter le champ de saisie CRQSARDT dans la grille.

GRQL - Réception qualitative (Transaction SAIRQL)
TRQL - Validation de la réception qualitative (Transaction SATRQL)
TTAC - Bon à payer (Transaction SATTAC)
SAILCR - Lignes de réceptions en quantité (Transaction SAILCR)
SAILRM - Lignes de réceptions en montant (Transaction SAILRM)
GRCPA - Réception (Transaction SAIRCP)
SAIRDT - Réception détail (Transaction SAIRDT)
GRPLA - Réception détaillée (Transaction SAIRPL)
GRPLU - Réception détaillée par utilisateur (Transaction SAIRPL)
GTREA - Réception des commandes d'achats : Interface (Transaction SAITRE)
SAITRL - Lignes de réceptions : Interface (Transaction SAITRL)

   1) Ajout de la possibilité d'ajouter jusqu'à cinq gestionnaires sur les commandes rattachées à la facture.

   2) Lors du contrôle du montant HT de l'en-tête de facture, au moment de la valorisation, il est possible de prendre en compte un écart autorisé.

   1) Pour cela, ajout de 5 gestionnaires (ge1satfc, ge2satfc, ..., ge5satfc), 5 fonctions (fo1satfc, fo2satfc, ..., fo5satfc) et 5 rôles (ro1satfc, ro2satfc, ..., ro5satfc) dans le sas facture (GTFCA).
Lors de l'intégration (TTFCA), s'ils n'existent pas déjà, ces gestionnaires sont affectés à chaque commande rattachée à la facture avec la fonction et le rôle précisés dans la table d'interface.

   2) Cet écart est donné par la valeur 2 du paramètre AUTSAFAA occurrence INTFAA. Il doit correspondre au plus petit écart HT donné par les différents types de ventilations (GTVCA) utilisés pour le transfert en comptabilité (TVCC). Il est exprimé en devise de référence.
La valeur 2 de ce paramètre n'est pas initialisée par la release.

GTFCA - Factures achats : Interface (Transaction SAITFC)
TTFCA - Intégration des factures d'achats (Transaction SATTFC)

   1) Ajout de la possibilité de modifier certaines zones de la facture même si celle-ci a été transférée en comptabilité.

   2) Ajout de la possibilité de lancer les traitements pour un ensemble de factures sélectionnées dans la grille.

   1) Cette possibilité est donnée par l'occurrence MAJTRF du paramètre AUTSAFAA.
Si la valeur testée 1 vaut :
- O : la modification de la facture est autorisée ;
- N : la modification de la facture est interdite.
Cette valeur testée est initialisée à "N" par la release.

   Chaque zone modifiable est paramétrée.
Pour cela, un nouveau paramètre SAMAJTRF a été créé. Les occurrences correspondent aux zones modifiables de la facture :
- CU1SAFAA : nature de la pièce ;
- CU2SAFAA : genre de la pièce ;
- CU3SAFAA : rôle de la pièce ;
- DESSAFAA : destinataire ;
- GENSAFAA : genre ;
- INFSAFAA : informations complémentaires ;
- INLSAFAA : interlocuteur logistique ;
- INXSAFAA : interlocuteur externe ;
- LIBSAFAA : libellé ;
- MNESAFAA : mnémonique ;
- NATSAFAA : nature ;
- PR1SAFAA : code statistique 1 ;
- PR2SAFAA : code statistique 2 ;
- PR3SAFAA : code statistique 3 ;
- ROLSAFAA : rôle ;
- TYPSAFAA : type.
Si la valeur testée 1 de l'occurrence vaut :
- O : la modification de la zone est autorisée ;
- N : la modification de la zone est interdite.
Pour chaque occurrence, la valeur testée 1 est initialisée à "N" par défaut.

GFAA - Contrôle facture (Transaction SAIFAA)

   Ajout de la possibilité d'ajouter une ligne en facture ou de créer une facture directe avec un mode d'achat réceptionnable en montant.

SAILCF - Lignes de facture (Transaction SAILCF)

   1) Ajout de la possibilité de dupliquer une facture avec commandes en une facture directe.

   2) Ajout de nouveaux critères dans les colonnes pouvant être modifiées entre la facture origine et la facture dupliquée.

   3) Ajout de la possibilité de paramétrer la recopie des lignes de factures :
- de co-traitants et de sous-traitants ;
- de révisions et de pénalités.

   1) Pour cela, ajout d'une classe à la soumission permettant de préciser la classe de facturation directe. Cette classe ne doit être renseignée que si la facture à dupliquer est une facture avec commandes.

   2) Ajout des colonnes :
- destinataire ;
- mnémonique ;
- nature de la pièce ;
- genre de la pièce ;
- rôle de la pièce ;
- paramètre 1 ;
- paramètre 2 ;
- paramètre 3 ;
- type ;
- nature ;
- genre ;
- rôle.

   3) La possibilité de recopier les lignes de co-traitants (type "C') et de sous-traitants (type "S") est donnée par la valeur testée 1 du paramètre AUTACHAT occurrence LIGCS.
Si la valeur testée 1 vaut :
- O :   les lignes de co-traitants et les lignes de sous-traitants sont recopiées ;
- N : les lignes de co-traitants et les lignes de sous-traitants ne sont pas recopiées.

   La valeur testée 1 de ce paramètre est initialisée à O par la release.

   La possibilité de recopier les lignes de révisions (type "R") et de pénalités (type "P") est donnée par la valeur testée 1 du paramètre AUTACHAT occurrence LIGRP.
Si la valeur testée 1 vaut :
- O : les lignes de révisions et les lignes de pénalités sont recopiées ;
- N : les lignes de révisions et les lignes de pénalités ne sont pas recopiées.

TDFAA - Duplication de factures (Transaction SATDFA)
GFAA - Contrôle facture (Transaction SAIFAA)

   Lors de la mise en litige d'une facture dans GSGFA, possibilité de mettre à jour la pièce même si celle-ci est soldée.

   Pour cela, dans le paramétrage des signatures (GPSGA), possibilité de cocher la case "Mise à jour des pièces soldées" même si la case "Bon à payer" n'est pas cochée.

GPSGA - Paramétrage des signatures (Transaction SAIPSG)

   Ajout de la possibilité d'éditer un récapitulatif, par classe, du nombre d'anomalies.

   Pour cela, ajout d'une case à cocher "Nombre d'anomalies par classe" dans la soumission.

TCLOA - Clôture des achats (Transaction SATCLO)

   Ajout de la possibilité de sélectionner les demandes d'achats ou les commandes à partir des conditions de facturation.

   Pour cela, ajout d'une forme détail "Conditions de facturation" dans la soumission afin de pouvoir sélectionner les demandes d'achats ou les commandes en fonction de trois conditions.
Si plusieurs conditions sont renseignées, il faut que la demande d'achats ou la commande possède toutes les conditions de facturation précisées pour pouvoir être sélectionnée.

TLSCA - Constitution de listes de DA ou commandes d'achats (Transaction SATLSC)

   Affichage des prix et des montants TTC dans la grille de la consultation.

   Les prix et montants TTC affichés sont :
- le prix tarif TTC ;
- le prix commandé TTC ;
- le prix proposé TTC ;
- le prix réceptionné TTC ;
- le montant réceptionné TTC ;
- le prix tarif facturé TTC ;
- le prix facturé TTC ;
- le montant facturé TTC.

CLCAD - Consultation des lignes de demandes d'achats (Transaction SACLCAD)
CLCA - Consultation des lignes de commandes d'achats (Transaction SACLCA)

   Ajout de la possibilité, lorsque l'éclatement en sous-commandes est réalisé, d'exécuter pour les sous-commandes générées, les traitements correspondant aux étapes par classe (GETCA) définis pour la classe d'achats (GNCA).

   Pour cela, ajout du paramètre ETP associé au traitement. Si la valeur vaut :
- O : le lancement des traitements par étape est effectué   ;
- N : le lancement des traitements par étape n'est pas effectué.

   La valeur du paramètre est initialisée à "N" par la release.

TCDA - Confirmation des commandes (Transaction SATCCDA)

   Ajout de la possibilité, lorsque l'éclatement en sous-demandes est réalisé, d'exécuter pour les sous-demandes générées, les traitements correspondant aux étapes par classe (GETCA) définis pour la classe d'achats (GNCA).

   Pour cela, ajout du paramètre ETP associé au traitement. Si la valeur vaut :
- O : le lancement des traitements par étape est effectué   ;
- N : le lancement des traitements par étape n'est pas effectué.

   La valeur du paramètre est initialisée à "N" par la release.

TEDA - Confirmation des demandes d'achats (Transaction SATEDA)

   Ajout de la possibilité d'exécuter pour les sous-demandes ou sous-commandes générées les traitements correspondants aux étapes par classe (GETCA) définis pour la classe d'achats (GNCA).

   Pour cela, ajout du paramètre ETP associé au traitement. Si la valeur vaut :
- O : le lancement des traitements par étape est effectué   ;
- N : le lancement des traitements par étape n'est pas effectué.

   La valeur du paramètre est initialisée à "N" par la release.

TECLA - Eclatement par caractéristique article (Transaction SATECLA)

   Désormais, dans les différents conteneurs où la barre d'avancement est souhaitée, il n'est plus nécessaire d'avoir la barre d'avancement (CAETAx) en tant que consultation dans un des panneaux du conteneur.
Il suffit, par personnalisation, d'intégrer dans les écrans principaux traitant les demandes d'achats et les commandes, un champ de type barre d'avancement : son code est AVANCEMENT.
Remarque : pour être utilisable, il est nécessaire, comme auparavant, de définir au préalable les groupes d'étapes pour les classes de demandes d'achats (GGETAD) et les classes de commandes (GGETAC).

GKCDA - Commandes d'achats (Transaction SAICDA)
GCDA - Commandes d'achats (Transaction SAICDA)
GKDAI - Demandes d'achats (Transaction SAIDAE)
GDAI - Demandes d'achats (Transaction SAIDAI)
CCDAC - Consultation des commandes d'achats (Transaction SACCDAC)
CCDAD - Consultation des demandes d'achats (Transaction SACCDAD)

   Correction de la prise en compte des étapes définies dans la "Sélection appels d'offres" lors de l'appel à partir de la consultation des fournisseurs (CFOU) ou de la consultation des articles achetés (CATA).

CSDEA - Sélection des données d'exploitation achats (Transaction SACSDEA)
CATA - Consultation des articles achetés (Transaction SACATA)
CFOU - Consultation des fournisseurs (Transaction SACFOU)

   Correction de la proposition du tiers, de l'adresse et de l'échéance du sous-traitant.

GTMPA - Sas des compléments des marchés publics (Transaction SAITMP)
TTMRA - Intégration des marchés (Transaction SATTMR)

   Correction afin de contrôler le champ p12satcp par rapport au paramètre P12SACAP.

SAITCP - Paramètres des commandes : Interface (Transaction SAITCP)

   Correction sur les champs "Immobilisations" dans le cas où l'application Qualiac® Immobilisations n'est pas présente chez le client.

SAITLC - Lignes de commandes d'achats : Interface (Transaction SAITLC)

   Correction de la recherche du nom du fournisseur.

GTARUFOU - Rubriques de transfert des fournisseurs (Transaction SAITRAFO)

   Correction de la taille maximale du champ "Numéro de ligne" : elle passe de 999 à 999999999.

GRAF - Articles référencés par fournisseur (Transaction SAIRAF)

   Correction afin de ne plus pouvoir détacher une commande dont la quantité BL n'est pas renseignée mais dont la quantité réceptionnée est renseignée.

SAILBL - Lignes BL (Transaction SAILBL)
SAIRCL - Commandes BL (Transaction SAIRCL)

   Correction de l'affectation de la référence lorsque le préfixe est utilisé.

   Correction de la prise en compte des étapes lors de la duplication des ventilations par CGR.

TDFAA - Duplication de factures (Transaction SATDFA)
GFAA - Contrôle facture (Transaction SAIFAA)

   Correction de l'affectation de la référence lorsque le préfixe est utilisé.

TAFAA - Annulation facture (Transaction SATAFA)

   Correction lors de l'utilisation du référentiel centralisé : initialisation de la devise et du taux à appliquer.

GACFA - Conditions de facturation des articles achetés (Transaction SAIACF)

   Correction du plantage, en recherche, lorsque la confidentialité est active.

GPDE - Priorité d'affectation dépôt et emplacement (Transaction SAIPDE)

   Correction des problèmes de saisie d'un acompte après réception lorsqu'il existe déjà un acompte après commande.
Correction pour le mnémonique GAAIAC : l'accès n'est autorisé qu'en consultation.

GAAIA - Informations acompte (Transaction SAIAAI)
GAAIAC - Informations acompte (Transaction SAIAAIC)

   Correction de l'affichage du libellé de l'article ou de la famille d'articles après une recherche et lors d'un export de données.

GTFA - Remise famille articles - fournisseurs (Transaction SAITFA)

   Correction de l'affectation du nombre de décimales du prix de la tranche lorsque la remise est une remise de fin de période de type "Prix forfaitaire".

GPTA - Tranches remises articles - fournisseurs (Transaction SAITTA)

   Correction du calcul du montant des conditions de facturation dans le cas où :
- la condition de facturation ne porte pas sur une TVA particulière (numéro de TVA non renseigné dans GCAF) ;
- la case "Ventilation par taxe" n'est pas coché pour la condition de facturation ;
- la case "Montant TTC" est cochée pour le type de transfert (GAMPCI).

TIMOR - MAJ immobilisations provisoires après réception (Transaction SATIMOR)

   Correction des messages tronqués dans la mise en forme Qualiac® Edition.

TSTA - Mise à jour des achats en stock (Transaction SATSTA)
TSTAF - Mise à jour des achats en stock (après facture) (Transaction SATSTAF)

   Correction de l'affichage de la commande générée dans le compte-rendu du traitement.

TDCDA - Duplication de commandes (Transaction SATDCDA)

   Correction du plantage à l'ouverture de la fenêtre de critères du traitement des commandes réceptionnées sans facture quand celui-ci est appelé à partir des enchaînements dynamiques (GEDEA).

TRSF - Commandes réceptionnées sans facture (Transaction SATRSF)

   Ajout d'un contrôle interdisant la génération d'un marché sur une classe de marchés définie en multi-établissements.

GCCMA - Paramétrage création CGR et marché (Transaction SAICCM)
TCCMA - Création CGR et/ou marché (Transaction SATCCM)

   Correction du calcul du montant commandé HT dans le cas d'une commande réceptionnée en montant, facturée partiellement mais dont la sous-commande solde facture n'a pas encore été générée.

CCDCA - Consultation des DA ou des commandes cumulées (Transaction SACCDC)

   Correction, lors de l'affichage dans la grille, de l'inversion des zones cotation et priorité d'une part et rating et qualité d'autre part.

CNFOU - Consultation des critères de notation fournisseur (Transaction SACNFO)

   Possibilité d'extraire les doublons de fournisseurs.

   Pour cela, création de l'occurrence DOUBLON du paramètre AUTFOURD. Si la valeur testée 1 vaut :
- O : les doublons sont extraits ;
- N : les doublons ne sont pas extraits.

TFOURD - Extraction des fournisseurs ReadSoft (Transaction SATFOURD)

   Possibilité d'intégrer :
- à l'en-tête : cinq gestionnaires ainsi que leurs fonctions et rôles ;
- à la ligne : un dépôt ;
- à l'en-tête et à la ligne : un sous-numéro de commande ;
- des réalisations d'abonnements à partir de la référence contrat ou du numéro d'abonnement.

   Possibilité de proposer une TVA au niveau des lignes de factures.

   Si le taux de la condition de facturation est égal à zéro, la condition de facturation n'est pas renseignée dans le sas.

   Pour l'intégration des gestionnaires, ajout de 16 occurrences au paramètre AUTSAFAR :
- GE1SATFC, GE2SATFC, GE3SATFC, GE4SATFC et GE5SATFC pour les gestionnaires ;
- FO1SATFC, FO2SATFC, FO3SATFC, FO4SATFC et FO5SATFC pour les fonctions ;
- RO1SATFC, RO2SATFC, RO3SATFC, RO4SATFC et RO5SATFC pour les rôles.

   Pour l'intégration du dépôt, ajout de l'occurrence DERSATFL pour le paramètre AUTSAFAR.
Pour un dépôt différent sur chaque ligne, il faut utiliser la balise par défaut "Depot".

   Ajout de deux nouvelles balises pour permettre l'intégration du sous-numéro de commande : SnuCommande et LI_SnuCommande.
Si la balise SnuCommande est renseignée, intégration du même sous-numéro sur toutes les commandes intégrées.
Si la balise LI_SnuCommande est renseignée, intégration d'un sous-numéro par commande intégrée.
Si les deux balises sont renseignées, seule la balise LI_SnuCommande est prise en compte.

   Ajout de quatre nouvelles balises pour permettre l'intégration des réalisations d'abonnements : NumContrat, RefContrat, DatePeriodePrestaDebut et DatePeriodePrestaFin.
Si la balise NumContrat est renseignée, intégration d'une réalisation par facture.
Si les balises RefContrat, DatePeriodePrestaDebut et DatePeriodePrestaFin sont renseignées, intégration, dans les réalisations d'abonnements, des abonnements actifs dont la date de début ou la date de fin est comprise dans la période de l'abonnement.
Si les quatre balises sont renseignées, seule la balise Numcontrat est prise en compte.

   La possibilité de proposer une TVA au niveau des lignes de factures est donnée par la valeur testée 1 de l'occurrence PROTVA du paramètre QIN_READ.
Si la valeur testée 1 vaut :
- N : la TVA n'est pas proposée ;
- O : la TVA est proposée à partir du type, du régime et du mode de TVA du fournisseur et du taux donné par la balise TauxTva ou la balise LI_TauxTVA.
La balise LI_TauxTVA est prise en priorité si les deux balises sont renseignées.
La valeur testée 1 du paramètre est initialisée à "N" par la release.

TFAAR - Extraction des factures achats ReadSoft (Transaction SATFAAR)

   Possibilité d'intégrer :
- à l'en-tête : cinq gestionnaires ainsi que leurs fonctions et rôles ;
- à la ligne : un dépôt ;
- des réalisations d'abonnements à partir de la référence contrat.

   Possibilité de proposer une TVA au niveau des lignes de factures.

   Si le taux de la condition de facturation est égal à zéro, la condition de facturation n'est pas renseignée dans le sas.

   Pour l'intégration des gestionnaires, ajout de 16 occurrences au paramètre AUTSAFAC :
- GE1SATFC, GE2SATFC, GE3SATFC, GE4SATFC et GE5SATFC pour les gestionnaires ;
- FO1SATFC, FO2SATFC, FO3SATFC, FO4SATFC et FO5SATFC pour les fonctions ;
- RO1SATFC, RO2SATFC, RO3SATFC, RO4SATFC et RO5SATFC pour les rôles.

   Pour l'intégration du dépôt, ajout de l'occurrence DERSATFL pour le paramètre AUTSAFAC.
Pour un dépôt différent sur chaque ligne, il faut utiliser la balise par défaut "Depot".

   Ajout de trois nouvelles balises pour permettre l'intégration des réalisations d'abonnements : RefContrat, DatePeriodePrestaDebut et DatePeriodePrestaFin.
Actuellement, si la balise NumContrat est renseignée, intégration d'une réalisation par facture.
Dorénavant, si les balises RefContrat, DatePeriodePrestaDebut et DatePeriodePrestaFin sont renseignées, intégration, dans les réalisations d'abonnements, des abonnements actifs dont la date de début ou la date de fin est comprise dans la période de l'abonnement.
Si les quatre balises sont renseignées, seule la balise Numcontrat est prise en compte.

   La possibilité de proposer une TVA au niveau des lignes de factures est donnée par la valeur testée 1 de l'occurrence PROTVA du paramètre QIN_CEGE.
Si la valeur testée 1 vaut :
- N : la TVA n'est pas proposée ;
- O : la TVA est proposée à partir du type, du régime et du mode de TVA du fournisseur et du taux donné par la balise TauxTva ou la balise LI_TauxTVA.
La balise LI_TauxTVA est prise en priorité si les deux balises sont renseignées.
La valeur testée 1 du paramètre est initialisée à "N" par la release.

TFAAC - Extraction des factures achats CEGEDIM (Transaction SATFAAC)

   Correction de la taille du Numéro de contrat.

TFAAC - Extraction des factures achats CEGEDIM (Transaction SATFAAC)

   Ajout des colonnes :
wdssaasm       Wim à déclencher au dernier signataire
ewmsaasm      Envoi du WIM à déclencher à l'exécution de l'action au traitement d'affectation
ewssaasm       Envoi du WIM à déclencher au dernier signataire au traitement d'affectation
dtmsaasm       Destinataire du mail de retour
fodsaasm       Fonction du gestionnaire destinataire du mail de retour
rodsaasm       Rôle du gestionnaire destinataire du mail de retour
apcsaasm       Mnémonique de consultation
gdmsaasm       Gestionnaire destinataire du marché

   Ajout de la colonne :
avrsacmp       Avance récupérée

   Ajout des colonnes :
taosadsm       Type d'acceptation origine
uaosadsm       Utilisateur d'acceptation origine
daosadsm       Date d'acceptation origine

   Modication des colonnes :
dacsadsm       Date de l'action : rendue non obligatoire
hacsadsm       Heure de l'action : rendue non obligatoire

   Ajout de la colonne :
mtmsaelu       Montant du marché

   Modification du libellé de la colonne :
persagsm       Utilisateur délégué

   Ajout de la colonne :
lsmsalus       Liste pour signature des marchés

   Ajout des colonnes :
cdtsancm       Contrôle des dates
actsancm       Accord cadre : contrôle des tiers
acdsancm       Accord cadre : contrôle des dates
acmsancm       Accord cadre : contrôle des montants
cn1sancm       Non géré
cn2sancm       Non géré

   Ajout de la colonne :
crqsarcp       Code qualité réception

   Ajout de la colonne :
crqsardt       Code qualité réception

   Ajout de la colonne :
crqsarpl       Code qualité réception

   Ajout des colonnes :
dccsarsm       Date de validité des compositions de CGR
gassarsm       Gestionnaire marché pour auto-signature

   Suppression de la colonne :
valsarsm       Valorisation

   Ajout des colonnes :
ge1satfc       Gestionnaire 1
fo1satfc       Fonction du gestionnaire 1
ro1satfc       Rôle du gestionnaire 1
ge2satfc       Gestionnaire 2
fo2satfc       Fonction du gestionnaire 2
ro2satfc       Rôle du gestionnaire 2
ge3satfc       Gestionnaire 3
fo3satfc       Fonction du gestionnaire 3
ro3satfc       Rôle du gestionnaire 3
ge4satfc       Gestionnaire 4
fo4satfc       Fonction du gestionnaire 4
ro4satfc       Rôle du gestionnaire 4
ge5satfc       Gestionnaire 5
fo5satfc       Fonction du gestionnaire 5
ro5satfc       Rôle du gestionnaire 5

   Ajout des colonnes :
cposavlc       Compte comptable origine
poosavlc       Poste origine