Document de release de la version H2.01

   Ce document présente les évolutions survenues sur le module Qualiac® Achats en H2.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.

   Création de cet historique (CHECMA) en indiquant le numéro de l'étape, l'utilisateur ayant effectué l'étape, ainsi que la date et l'heure de réalisation de l'étape.

   La consultation de l'historique des étapes de marchés (CHECMA) est accessible à partir des marchés (GMARA).

GETPMA - Etapes de marchés achats (Transaction SAIETPM)
GETCMA - Etapes par classe de marchés (Transaction SAIETCM)
CHECMA - Historiques des étapes de marchés (Transaction SACHECM)
GMARA - Marchés (Transaction SAIMAR)
TPEMA - Passage d'étape des marchés (Transaction SATPEM)
TREIMA - Retour à l'étape initiale pour les marchés (Transaction SATEIM)
TASMMA - Affectation signataires multicritères marchés (Transaction SATASMM)
GSMMA - Signatures multicritères des marchés (Transaction SAISMM)
TRDFA - Répartition CGR et qtés du dossier de fabrication (Transaction SATRDF)
TCLOMA - Clôture marché achat (Transaction SATCMA)
TDCLOM - Dé-clôture marché achat (Transaction SATDCM)

   Pour chacun des traitements et/ou gestions définis par étape, c'est lors de la définition de l'étape par classe (GETCMA), que vous indiquez si la mémorisation est active ou non.

   Cette gestion permet de définir les étapes maximales autorisées en création, modification et suppression pour un complément de marchés publics.
Ces étapes sont définies par établissement, classe de marché et type de complément.

   Une initialisation de la table est effectuée par la release, pour chaque type de complément présent dans GCMP. Les étapes sont affectées à partir des étapes définies dans la classe de marchés (GNCM) pour le marché ou la ligne de marché suivant que le complément est rattaché à un marché, une ligne de marché ou une tranche.

GECMA - Etapes autorisées pour les compléments de marché (Transaction SAIECM)
GCMP - Compléments des marchés publics (Transaction SAICMP)

   Deux types d'actualisation sont possibles :
- globale : toutes les lignes du marché sont actualisées avec la même formule ;
- détaillée : sur un même marché, les lignes peuvent avoir une formule d'actualisation différente.

   1) Sélection
Les marchés sont actualisables ou pas en fonction de la valeur testée 1 de l'occurrence "forme de prix" du paramètre FDPSAMAR indiqué sur le marché. Pour que le marché soit actualisable, la valeur testée 1 doit être égale à "A".
Les lignes de marchés sélectionnées sont celles pour lesquelles la classe de marché est définie, pour le type de ligne correspondant, en génération de commandes et en cadencement manuel.

   En fonction du type d'actualisation, la sélection est différente.
Actualisation globale :
- la chaîne 1 de l'occurrence de paramètre associée à la forme de prix du marché (FDPSAMAR) doit être égale à G ;
- le marché ne doit pas avoir déjà été actualisé ;
- la date d'actualisation, renseignée à la soumission, doit être supérieure à la date de réception de l'offre. Il est possible d'ajouter un délai à la date de réception de l'offre, ce délai doit alors être renseigné dans la valeur 1 de l'occurrence de paramètre associée à la forme de prix du marché (FDPSAMAR). Ce délai est exprimé en jours. Il est donc impératif que la date de réception de l'offre du marché soit renseignée.

   Actualisation détaillée :
- la chaîne 1 de l'occurrence de paramètre associée à la forme de prix du marché (FDPSAMAR) doit être égale à D ;
- les lignes de marchés ne doivent pas avoir déjà été actualisées ;
- la date de réception de l'offre, doit être inférieure à la date de début d'exécution de la ligne de marché. Il est possible d'ajouter un délai à la date de réception de l'offre, ce délai doit alors être renseigné dans la valeur 1 de l'occurrence de paramètre associée à la forme de prix du marché (FDPSAMAR). Ce délai est exprimé en jours. Il est donc impératif que la date de réception de l'offre soit renseignée ainsi que la date d'exécution dans les lignes de marchés.

   2) Recherche de la formule
Pour chaque ligne de marchés (GMADA) sélectionnées, le coefficient d'actualisation est calculé à partir d'une formule de révision (GREP). Celle-ci est référencée dans les compléments de marchés publics (GCMP) de type "CP".
Si l'actualisation est globale, le complément doit être associé au marché, il y a donc une formule par marché, si aucune formule n'est trouvée, le marché est ignoré.
Si l'actualisation est détaillée, le complément peut être associé au marché, à la ligne ou à la tranche référencée parmi les lignes de marchés. Si aucune formule n'est trouvée, la ligne de marché est ignorée.

   La formule d'actualisation est composée d'indices de prix à des dates données. Ces indices sont référencés dans la gestion des indices de prix (GIDP) et des détails des indices de prix (GIDD), avec une valeur d'indice par période.

   3) Actualisation des lignes de marchés
La formule d'actualisation trouvée permet de calculer un coefficient auquel va être multiplié le prix, le montant prévu et le montant minimum de chacune des lignes de marchés sélectionnées.
Pour chacun des prix ou montants actualisés de la ligne de marché, il est créé un historique d'actualisation (CHACMA) dans lequel sont renseignés l'ancien et le nouveau prix ou montant. Le type de formule permet de distinguer quel prix (ou montant) est actualisé. Les valeurs possibles sont :
- AGP : actualisation globale du prix ;
- AGV : actualisation globale du montant prévu ;
- AGM : actualisation globale du montant minimum ;
- ADP : actualisation détaillée du prix ;
- ADV : actualisation détaillée du montant prévu ;
- ADM : actualisation détaillée du montant minimum.
Cet historique (CHACMA) est accessible à partir des marchés ou des lignes de marchés actualisées.

   L'actualisation d'une ligne de marché déclenche la mise à jour des montants du marché correspondant :
- Montant prévu : mis à jour avec la somme des écarts entre les anciens et les nouveaux montants prévus de toutes les lignes du marché ;
- Montant minimum prévu : mis à jour avec la somme des écarts entre les anciens et les nouveaux montants minimum prévus de toutes les lignes du marché ;
- Montant prévu ligne 1 : mis à jour avec la somme des écarts entre les anciens et les nouveaux montants prévus des lignes de type 1 du marché ;
- Montant minimum prévu ligne 1 : mis à jour avec la somme des écarts entre les anciens et les nouveaux montants minimum prévus des lignes de type 1 du marché ;
- Montant prévu ligne 2 : mis à jour avec la somme des écarts entre les anciens et les nouveaux montants prévus des lignes de type 2 du marché ;
- Montant minimum prévu ligne 2 : mis à jour avec la somme des écarts entre les anciens et les nouveaux montants minimum prévus des lignes de type 2 du marché.

   4) Actualisation des compléments
Si l'actualisation est globale, il est possible d'actualiser les compléments de marché de type "CS". Les informations actualisées sont le montant prévu et le montant maximum sous-traité.
Si l'actualisation est détaillée, il n'est pas possible d'effectuer la mise à jour des compléments via le traitement, il est nécessaire de les mettre à jour manuellement.

   5) Actualisation des commandes d'achats
Il est également possible d'actualiser les commandes d'achats associées au marché traité. Les commandes traitées sont celles qui sont non facturées, non réceptionnées et dont l'étape est inférieure à la valeur 1 de l'occurrence ETPACTxxxx (où xxxx représente la classe d'achats) du paramètre AUTACHAT.
Pour chaque ligne de commande correspondant à une ligne de marché (GMADA) actualisée, son prix tarif HT et prix commandé HT sont mis à jour en fonction du coefficient de révision appliqué à la ligne de marché correspondante.
Si pour la commande traitée, l'engagement (TVCCE) a déjà été effectué, il est annulé (TDEG) et il est refait afin de prendre en compte les prix actualisés de la commande.
De la même manière, si pour la commande traitée, le transfert en statistiques (TSTTCA) a déjà été effectué, il est annulé et il est refait afin de prendre en compte les prix actualisés de la commande.

TACMA - Actualisation des prix liés aux marchés (Transaction SATACM)
CHACMA - Historique actualisation prix des lignes de marché (Transaction SACHACM)

   Les prix des lignes de commandes sont révisables ou pas en fonction de la valeur testée 1 de l'occurrence "forme de prix" du paramètre FDPSAMAR indiqué sur le marché de la commande. La valeur testée 1 de l'occurrence doit être égale à R pour que le calcul de révision s'effectue.

   Afin de distinguer si le traitement calcule les révisions après commande ou après réception, le paramètre PRM associé au traitement a été mis en place. Il peut avoir les valeurs suivantes :
- C : le calcul est effectué après commande (TREVAC) ;
- R : le calcul est effectué après réception (TREVA).

   Pour chaque ligne de commande correspondant à une ligne de marché (GMADA), le montant de la révision est calculé à partir d'une formule de révision (GREP). Celle-ci est référencée dans les compléments de marchés publics (GCMP) de type "CP". Ce complément peut être associé au marché, à la ligne de marché ou à la tranche référencée parmi les lignes de marchés.

   La formule de révision est composée d'indices de prix à des dates données. Ces indices sont référencés dans la gestion des indices de prix (GIDP) et des détails des indices de prix (GIDD), avec une valeur d'indice par période. Ces valeurs sont à saisir régulièrement et manuellement afin d'appliquer les indices les plus justes au moment du calcul des révisions.
En théorie, la révision se calcule en fonction de l'évolution d'un indice entre la date de référence sur le marché (mois de référence indiqué au niveau du marché) et la date de commande. Mais parfois, ce calcul doit se faire en respectant une périodicité :
- annuellement au 1er janvier de l'année concernée ;
- trimestriellement au 1er jour du trimestre civil à compter de la date de référence du marché et au 1er jour des trimestres suivants ;
- mensuellement au 1er jour du mois civil à compter de la date de référence du marché et au 1er jour des mois suivants.
Cette périodicité est donnée par la valeur testée 2 de l'occurrence "forme de prix du marché" du paramètre FDPSAMAR. Si la valeur testée 2 est égale à :
- A : périodicité annuelle ;
- T : périodicité trimestrielle ;
- M : périodicité mensuelle ;
- non renseignée : pas de périodicité à appliquer.
Cette périodicité correspond elle-même à une occurrence du paramètre TYPOECAP. Pour chaque date utilisée dans la formule, il est donc recherché la période (GCAP) correspondant au type de période et c'est la date de début de la période trouvée qui est utilisée pour la recherche de l'indice correspondant.

   La formule de révision trouvée permet de calculer un coefficient auquel va être multiplié le montant commandé de la ligne afin de déterminer le montant de la révision.

   En fonction du paramétrage du traitement, il est possible d'effectuer une révision globale ou détaillée.
Si le paramètre PR1 associé au traitement est égal à :
- D : le traitement s'effectue en détaillé : une ligne de révision peut être créée par ligne de commande ;
- G : le traitement s'effectue en global : une ligne de révision peut être créée pour chaque article de révision trouvé pour la commande.

   La ligne de révision correspondant à la ligne de commande est créée comme suit :

   - article : l'article de révision est proposé dans l'ordre de priorité suivant :
             - article de révision renseigné au niveau du complément de marché public (GCMP) de type "CP", correspondant à la ligne de commande,
             - article référencé dans la formule (GREP) si renseigné,
             - article de la ligne de commande.
Attention : dans le cas où le traitement s'effectue en global, l'article de révision doit forcément être renseigné au niveau du complément ou de la formule ;

   - mode d'achat : il est proposé dans l'ordre de priorité suivant :
              - mode d'achat donné par l'équivalence de modes d'achat (GTRC) définie pour le mode d'achat de la ligne origine et le code du traitement de révision. Dans le cas où le traitement s'effectue en global, c'est le mode d'achat de la première ligne de commande regroupée qui est pris en compte pour effectuer la recherche d'équivalence (GTRC),
              - mode d'achat proposé par défaut.
Ce nouveau mode d'achat ne doit pas être réceptionnable, ne doit pas avoir influence sur les marchés et sur les immobilisations ;

   - libellé, compte, poste, taxe, informations liées à la déclaration d'échanges de biens, poids, volumes : ces informations sont proposées par défaut ;

   - CGR A, CGR B : ils sont affectés en fonction du paramètre PR2 associé au traitement. S'il est égal à :
           - O : le CGR A et le CGR B de la ligne origine sont recopiés sur la ligne de révision générée. Dans le cas où le traitement s'effectue en global, ce sont le CGR A et le CGR B de la première ligne de commande regroupée qui est pris en compte,
           - D : le CGR A et le CGR B sont proposés par défaut,
           - N : non renseignés ;

   - quantité commandée : quantité commandée de la ligne origine si le traitement s'effectue en détaillé, sinon égale à 1 ;

   - prix commandé : prix commandé de la ligne de commande origine, multiplié par le coefficient de révision si le traitement s'effectue en détaillé, sinon somme des montants révisés pour les lignes de commandes regroupées ;

   - type de la ligne : il est égal à "A" ;

   - numéro de ligne : il est égal au numéro de la ligne origine plus deux si ce numéro n'existe pas déjà et si le traitement s'effectue en détaillé, sinon il est attribué automatiquement.

   Pour chaque ligne de commande révisée, il est créé un historique des révisions (CHREA) dans lequel sont renseignés notamment la valeur révisée, la valeur de révision, le numéro de ligne de révision et le statut de la révision.

   Lors de la suppression d'une ligne de commande, lors de l'annulation d'une commande (TSRD) ou lors du retour à l'étape initiale (TANU), s'il existe un historique de révision (CHREA) pour la ou les lignes de commandes concernées, celui-ci est marqué comme étant annulé.

   Cet historique (CHREA) est accessible depuis les lignes de commandes (GLCA), les lignes de réceptions (SAILCR/SAILRM) et les lignes de factures (SAILCF).

   Lors de l'exécution du traitement de calcul des pénalités liées au marché (TPENA) et de l'exécution du traitement de calcul des révisions liées au marché après réception (TREVA), les lignes de révision générées ne sont pas prises en compte.

   De plus, les lignes de commandes révisées après commande (TREVAC) ne sont pas prises en compte lors du traitement de calcul des révisions après réception (TREVA).

   Les lignes de commandes dites de révision ayant un type particulier ("A"), il est possible, lors du traitement de recopie des commandes (TDCDA) et du traitement de duplication de factures (TDFAA), d'exclure ces lignes de la recopie. Cette possibilité est donnée par la valeur testée 1 du paramètre AUTACHAT occurrence LIGRP.
Si la valeur testée 1 vaut :
- N : les lignes de commandes issues des révisions (TREVAC) ne sont pas recopiées ;
- O : toutes les lignes de commandes sont recopiées.

TREVAC - Calcul des révisions liées au marché après cde (Transaction SATREVC)
CHREA - Historique révision prix lignes commandes achats (Transaction SACHRV)
TANU - Retour à l'étape initiale (Transaction SATANU)
TSRD - Annulation de demandes d'achats ou de commandes (Transaction SATSRD)
TDCDA - Duplication de commandes (Transaction SATDCDA)
TREVA - Calcul des révisions liées au marché après réc. (Transaction SATREV)
TSOLA - Solde des commandes d'achats après réception (Transaction SATSOLA)
TACRA - Annulation d'une commande réceptionnée (Transaction SATACR)
TSOLF - Solde des commandes d'achats après facture (Transaction SATSOLF)
TDFAA - Duplication de factures (Transaction SATDFA)

   Ce traitement doit être situé dans les étapes par classe (GETCA), après le ou les traitements d'éclatement (TCDA, TECLA) et avant les traitements d'engagement (TVCCE) et de transfert en statistiques (TSTTCA). Il doit être défini comme suit :
- mnémonique d'appel : TREVAC ;
- traitement associé : SATREVC ;
- traitement par commande : pssarevetp ;
- traitement par autre entité : pssarevetp.

   1) Retour à l'étape initiale (TANU) : le retour à l'étape initiale est interdit dans le cas où :
- l'année de la date logique est différente de l'année de la date comptable de l'engagement (TVCCE) de la commande ;
- ou la commande n'est pas engagée alors qu'il devrait y avoir un engagement (cas des sous-commandes en attente de réception issues de l'annulation des commandes réceptionnées (TACRA)).

   2) Annulation de commandes (TSRD) : si l'année de la date logique est différente de l'année de la date comptable de l'engagement (TVCCE) :
- l'écriture d'engagement de la commande n'est pas annulée en comptabilité ;
- les ventilations comptables correspondant à l'écriture d'engagement et associées à la commande sont mises à jour : l'état passe de la valeur "I" (imputé) à la valeur "T" (traité).

   3) Annulation des commandes réceptionnées (TACRA) : si l'année de la date d'annulation "potentielle" de l'écriture d'engagement (TVCCE) est différente de l'année de la date comptable :
- l'écriture d'engagement de la commande n'est pas annulée en comptabilité ;
- les ventilations comptables correspondant à l'écriture d'engagement et associées à la commande annulée sont mises à jour : l'état passe de la valeur "I" (imputé) à la valeur "T" (traité) ;
- la sous-commande en attente de réception n'est pas ré-engagée en comptabilité.

   4) Commandes réceptionnées sans factures (TRSF) : si l'année de la date d'annulation "potentielle" de l'écriture d'engagement (TVCCE) est différente de l'année de la date comptable :
- l'écriture d'engagement de la commande n'est pas annulée en comptabilité ;
- les ventilations comptables correspondant à l'écriture d'engagement et associées à la commande sont mises à jour : l'état passe de la valeur "I" (imputé) à la valeur "T" (traité).

   5) Génération de commandes multi-devises (TTPD) : dans le cas de la comptabilité publique, le nouveau cours de devise ne doit pas être appliqué aux ventilations comptables. La ventilation origine doit passer sur la sous-commande générée sans modification. Pour cela, la valeur testée 1 du paramètre AUTSATPD occurrence MAJVCC doit être égale à "N".

TANU - Retour à l'étape initiale (Transaction SATANU)
TSRD - Annulation de demandes d'achats ou de commandes (Transaction SATSRD)
TACRA - Annulation d'une commande réceptionnée (Transaction SATACR)
TRSF - Commandes réceptionnées sans facture (Transaction SATRSF)
TTPD - Génération de sous-commandes multi-devises (Transaction SATTPD)

   En effet, dans ce cas, l'écriture de comptabilisation de la facture (408/401) est équilibrée comptablement mais peut apparaître déséquilibrée (hors compte technique 99CT).
Le traitement de comptabilisation de la facture (TVCC) a donc été modifié afin de prendre en compte ces écarts et équilibrer "visuellement" l'écriture de la facture.

   Exemple:
Comptabilisation de la FNP : TVA à 20% avec un prorata à 90%

   Comptabilisation de la facture : TVA à 10% avec un prorata à 90%

Comptablement, l'écriture est équilibrée, mais dans le cadre de la comptabilité publique, les comptes 99CT sont masqués et l'écriture apparaît donc "déséquilibrée" (débit = 1210, crédit = 1120).

   Le transfert en comptabilité a donc été modifié afin de corriger cet écart et l'écriture obtenue est donc la suivante :

Création d'un mouvement sur le compte 6 avec, au crédit, l'écart dû au changement de taux de TVA (90).
Création d'un mouvement sur le compte 99CT avec, au débit, l'écart dû au changement de taux de TVA (90).
L'écriture est donc équilibrée en comptabilité générale et visuellement (débit = 1210, crédit = 1210).

TVCC - Comptabilisation des factures (Transaction SATVCC)

   1) Contrôle de tolérance pour ajustement d'engagement après réception (TCTRA)
Ce nouveau traitement par étape permet de contrôler que la somme des montants réceptionnés des lignes de commandes qui ont pu être ajoutées lors de la réception (ligne de révision, ligne de pénalité, ligne d'écart) ne dépasse pas une certaine tolérance par rapport au montant HT total de la réception.
Cette tolérance est donnée par les valeurs 1 et 2 du paramètre AUTSAAEF occurrence CTLMNT :
- la valeur 1 donne la tolérance en pourcentage ;
- la valeur 2 donne la tolérance en montant. Elle est exprimée en devise de référence.

   Si la somme des montants réceptionnés des lignes de commandes ajoutées lors de la réception (ligne de révision, ligne de pénalité, ligne d'écart) est supérieure à une de ces deux tolérances (ou les deux), la réception est bloquée : l'utilisateur doit saisir une commande complémentaire qui devra alors être rattachée à la facture.

   NB : afin d'identifier au mieux les lignes de commandes ajoutées à la réception pour lesquelles un ajustement d'engagement devra être effectué, il est désormais possible, lors de l'ajout d'une ligne à la réception, de contrôler que cette ligne soit une ligne de pénalité, de révision ou d'écart. Ce contrôle est effectué à partir de la valeur du type de la ligne et en fonction de la valeur testée 1 du paramètre AUTSAREC occurrence TYPLIG. Si la valeur testée 1 vaut :
- O : le type de la ligne ajoutée à la réception doit être égal à R (ligne de révision), P (ligne de pénalité) ou ER (ligne d'écart réception) ;
- N : aucun contrôle n'est effectué sur le type de la ligne ajoutée à la réception.

   2) Contrôle de tolérance pour ajustement d'engagement après facture (TCTFA)
Ce nouveau traitement par étape permet de contrôler que la somme des montants facturés des lignes de commandes qui ont pu être ajoutées lors de la facturation ou lors de la réception (ligne de révision, ligne de pénalité) ne dépasse pas une certaine tolérance par rapport au montant HT total de la facture.
Cette tolérance est donnée par les valeurs 1 et 2 du paramètre AUTSAAEF occurrence CTLMNT :
- la valeur 1 donne la tolérance en pourcentage ;
- la valeur 2 donne la tolérance en montant. Elle est exprimée en devise de référence.

   Si la somme des montants facturés des lignes de commandes ajoutées lors de la facturation ou lors de la réception (ligne de révision, ligne de pénalité) est supérieure à une de ces deux tolérances (ou les deux), la facture est bloquée : l'utilisateur doit saisir une commande complémentaire qui devra alors être rattachée à cette facture.

   NB : les lignes de facture créées par le traitement de génération de facture de co/sous-traitance (TGFCSA) ne sont pas prises en compte dans le calcul de la somme des montants facturés des lignes ajoutées à la facture.

   3) Ajustement d'engagement après facture (TAEFA)

   Ce traitement a pour but de générer une commande d'écart à partir des lignes de commandes qui ont pu être ajoutées à la facture ou lors de la réception (ligne de révision, ligne de pénalité, ligne d'écart) et également, à partir des lignes de commandes utilisant le prorata de TVA sur l'engagement juridique et/ou sur la demande de paiement et dont le taux change entre l'engagement et la facture, afin d'ajuster les engagements et les mettre en conformité avec la facture.

   Les lignes de factures créées par le traitement de génération de facture de co/sous-traitance (TGFCSA) ne sont pas prises en compte.

   La génération de la commande d'écart pour les lignes ajoutées à la facture et/ou à la réception est effectuée que si :
- la somme des montants facturés des lignes ajoutées est positive ;
- la somme des montants facturés des lignes ajoutées est négative et que la génération de la commande d'ajustement se fait sur la même année que l'engagement (TVCCE) de la commande initiale.

   Pour chacune des commandes de la facture où une ou plusieurs lignes ont été ajoutées (à la facture ou à la réception) ou pour une ou plusieurs lignes de commandes utilisant le prorata de TVA, un écart dû au changement de taux de TVA est constaté, une commande d'ajustement ou d'écart est générée par duplication de l'en-tête de la sous-commande origine avec modification de certaines informations :
- classe d'achats : donnée par la chaîne 1 de l'occurrence CLA-xxxx du paramètre AUTSAAEF où xxxx représente la classe d'achats de la commande origine. Cette nouvelle classe d'achats doit être différente de celle de la commande origine et son circuit d'étapes (GETCA) ne doit comporter essentiellement que l'étape de création (GCDA), l'étape d'engagement (TVCCE) et l'étape d'annulation de commandes (TSRD) ;
- date de commande : date logique ;
- date au plus tôt : date logique ;
- date au plus tard : non renseignée ;
- étape : étape par défaut pour la classe dans les étapes par classe (GETCA) ;
- programme créateur : code du traitement dans GTRB (SATAEF pour le traitement livré en standard).

   Les lignes générées sur la commande d'écart sont créées par duplication des lignes de la sous-commande origine avec modification de certaines informations :
- mode d'achat : il est donné par l'équivalence de modes d'achat (GTRC) définie pour le mode d'achat de la ligne origine et le code du traitement d'ajustement d'engagement (SATAEF pour le traitement livré en standard). Ce nouveau mode d'achat ne doit pas être réceptionnable, ne doit pas avoir influence sur les marchés, sur les statistiques et sur les immobilisations ;
- prix tarif, prix commandé :
    a) cas des lignes ajoutées à la facture : prix facture ou montant facturé divisé par la quantité facturée selon la valeur testée 1 du paramètre AUTSAFAA occurrence CALPVF,
    b) cas des écarts dus au prorata de TVA : montant de l'écart ;
- quantité commandée :
    a) cas des lignes ajoutées à la facture ou à la réception : quantité facturée de la ligne de commande ajoutée à la facture ou à la réception,
    b) cas des écarts dus au prorata de TVA : 1 si l'écart calculé est au débit, -1 si l'écart calculé est au crédit ;
- date prévue : non renseignée ;
- date initiale : non renseignée.

   Les tables annexes suivantes associés à l'en-tête de commande origine sont dupliquées :
- les échéances (GCAE) ;
- les gestionnaires (GCAG) ;
- les textes (GTXT) ;
- les paramètres (GCAPE) ;
- les rubriques (GRUCA) ;
- les ventilations par CGR (GVCG).

   Les tables annexes suivantes associés aux lignes de commandes origine sont dupliquées :
- les textes (GTXT) ;
- les paramètres (GCAPL) ;
- les rubriques (GRUCA) ;
- les ventilations par CGR (GVCG).

   Une fois la commande d'écart générée, elle est valorisée.

   Un lien (GLCD) est systématiquement créé entre la commande origine et la commande d'écart générée. Le type de lien est donné par la chaîne 1 de l'occurrence TYPLCD du paramètre AUTSAAEF.

   La commande d'écart est générée à l'étape par défaut pour la classe. Si, dans les étapes par classe (GETCA), celle-ci est active sur l'historisation, un enregistrement est créé dans l'historique (CHECA) en indiquant le numéro de l'étape, l'utilisateur ayant effectué l'étape (utilisateur de connexion) ainsi que la date et l'heure de réalisation de l'étape (date et heure d'exécution du traitement).

   Suivant la valeur du paramètre ETP associé au traitement, il est possible d'exécuter pour la commande d'écart générée, les traitements correspondant aux étapes par classe (GETCA) définis pour la classe d'achats (GNCA).

TCTRA - Ctrl. tolérance pour ajustement engagement (réc.) (Transaction SATCTR)
TCTFA - Contrôle de tolérance pour ajustement d'engagement (Transaction SATCTF)
TAEFA - Ajustement d'engagement après facture (Transaction SATAEF)

   1) Contrôle de tolérance pour ajustement d'engagement après réception (TCTRA)
Ce traitement doit être situé dans les étapes par classe (GETCA) après la saisie de la réception (GREC), après les traitements de calcul des révisions liées au marché (TREVA), de calcul des pénalités liées au marché (TPENA) et avant le traitement de solde des commandes d'achats (TSOLA) comme suit :
- mnémonique d'appel : TCTRA ;
- traitement associé : SATCRF ;
- traitement par commande : pssactfetp ;
- traitement par autre entité : pssactfetp.

   2) Contrôle de tolérance pour ajustement d'engagement après facture (TCTFA)
Ce traitement doit être situé dans les étapes par classe (GETCA) après la saisie de la facture (GFAA) et avant le traitement de mise à jour des montants co-traitant/sous-traitant (TMCSA) et avant le traitement de comptabilisation (TVCC) comme suit :
- mnémonique d'appel : TCTFA ;
- traitement associé : SATCTF ;
- traitement par commande : pssactfetp ;
- traitement par autre entité : pssactfetp.

   2) Ajustement d'engagement après facture (TAEFA)
Ce traitement doit être situé dans les étapes par classe (GETCA) après le traitement de comptabilisation (TVCC) comme suit :
- mnémonique d'appel : TAEFA ;
- traitement associé : SATAEF;
- traitement par commande : pssaaefetp ;
- traitement par autre entité : pssaaefetp.

   Ce traitement est dédié à la prise en charge du fichier de données au format XML, provenant de Chorus Pro et transmis par un tiers de télétransmission.

   Les données issues des fichiers XML sont intégrées dans les tables de sas des achats :
- SATFC : en-tête des factures achats (GTFCA) ;
- SATFL : lignes des factures achats (SAITFL) ;
- SATDO : documents associés (SAITDO) ;
- SATSF : suivi des factures (SAITSF).

   Les critères "Type de document" et "Entité de document" servent pour rechercher les documents à déposer dans le sas des documents, pour la facture.
S'ils sont égaux à ".", aucun document n'est déposé dans le sas des documents. Par défaut, ils sont proposés à ".".
S'ils sont renseignés, ils doivent être associés dans la gestion des associations entité-type (GTDAE). Les pièces jointes incluses au fichier XML sont générées dans le répertoire donné par le chemin (GPTH) associé à l'application GTI, le type QID et l'utilisateur PUBLIC.

   Si le type de document est centralisé, son chemin doit pointer vers le même chemin que celui où sont générées les pièces jointes incluses au fichier XML.
Si le type de document est basé, il est nécessaire de lancer le traitement TCDOC après l'exécution du traitement d'intégration des factures (TTFCA).

TICPFA - Intégration des factures achats Chorus Pro (Transaction SATICPFA)

   1) Chemins (GPTH) à créer :

   - répertoire des fichiers à traiter donné par le chemin (GPTH) associé à l'application SAC, le type CID et l'utilisateur PUBLIC. Ce répertoire est celui dans lequel le tiers de télétransmission dépose les fichiers.
- répertoire des fichiers en erreur donné par le chemin (GPTH) associé à l'application SAC, le type CIR et l'utilisateur PUBLIC.
- répertoire des fichiers traités donné par le chemin (GPTH) associé à l'application SAC, le type CIT et l'utilisateur PUBLIC.
Ces chemins doivent être accessibles depuis le serveur de traitement.

   2) Paramètre AUTSACPP :

   a) occurrence CODORI : donne l'origine de la facture dans la chaîne 1.

   b) occurrence MODPMT : proposition de l'échéance.
Si la valeur testée 1 vaut :
     - N : pas de proposition de l'échéance ;
     - O : proposition de l'échéance.
Par défaut, la valeur testée 1 est livrée à "O".

   c) occurrence RGMxx où xx correspond aux modalités de paiement Chorus : donne la correspondance entre les modalités de paiement Chorus et le mode de paiement Qualiac®. La chaîne 1 donne le mode de paiement Qualiac®.
Les valeurs possibles des modalités de paiement Chorus sont :
- 10 : espèce ;
- 20 : chèque ;
- 30, 31, 42 : virement ;
- 48, 49 : prélèvement ;
- 97 : report.

   d) occurrence FD-CLA : donne la classe de facturation directe dans la chaîne 1.

   e) occurrence DATRAF : donne la date utilisée pour la recherche de la référence article/fournisseur.
Si la valeur testée 1 vaut :
- S : date système ;
- F : date de facture ;
- RF : date de réception facture.
Par défaut, la valeur testée 1 est livrée à "F".

   f) occurrence FD-ART : donne le code de l'article générique dans la chaîne 1.
Ce code est utilisé dans le cas où il n'a pas été trouvé d'article référencé pour le fournisseur.

   g) occurrence FD-CGR : utilisée pour proposer le CGR.
Celui-ci est égal soit à la valeur de la rubrique contenue dans la chaîne 1 soit au CGR défini dans le texte. La rubrique doit être une rubrique associée à la référence article/fournisseur.

   NB : les occurrences FD-CLA, DATRAF, FD-ART et FD-CGR ne sont utilisées que pour la facturation directe.

   1) ELCUA : Liste de cueillette
Cette édition permet d'afficher les lignes de demandes de services réservées, c'est-à-dire les lignes pour lesquelles une réservation du stock a été effectuée soit manuellement avec SAIRDS soit en automatique par TRDS.

   Les données sont affichées par dépôt et demande de services. Deux critères de regroupement permettent de trier les lignes affichées.

   Via une personnalisation de la mise en forme, il est possible, à chaque client, d'utiliser l'étape PIE afin d'éditer du texte libre. Cette étape est alors affichée à la fin du tableau des lignes.
NB : cette étape n'est pas affichée en standard.

   2) EBLDSA : Bon de livraison des demandes de services
Cette édition permet d'afficher les lignes de demandes de services livrées, c'est-à-dire les lignes des demandes de services qui sont à une étape supérieure ou égale à l'étape de la gestion de livraison des demandes de services (GRDA).

   Les données sont affichées par dépôt, date de livraison de la ligne et demande de services. Un critère de regroupement permet de trier les lignes affichées.

   Un total est édité à la fin : il affiche le total des quantités et des montants HT.

   Il est également possible, via la case à cocher "Détail par lots et emplacements", d'éditer les détails par lots et/ou emplacements.

   Via une personnalisation de la mise en forme, il est possible, à chaque client, d'utiliser l'étape PIE afin d'éditer du texte libre. Cette étape est alors affichée à la fin du tableau des lignes, après le total.
NB : cette étape n'est pas affichée en standard.

ELCUA - Liste de cueillette (Transaction SAELCU)
EBLDSA - Bon de livraison des demandes de services (Transaction SAEBLDS)

   Pour cela, une gestion de saisie de répartition, appelable à partir des lignes de demandes d'achats a été créée.

   La saisie de la répartition et donc l'accès à cette gestion à partir d'une ligne de demande, est possible si :
- la valeur testée 1 de l'occurrence REPART du paramètre AUTSAREA est égale à "O" ;
- la date de livraison prévue (date de la ligne si renseignée sinon date de l'en-tête) est renseignée et référence une année future par rapport à la date de commande, le nombre de mois séparant les deux dates devant être supérieur ou égal au nombre de mois donné par la valeur 1 du paramètre AUTSAREA occurrence REPART.

   Les lignes de demandes d'achats pour lesquelles une répartition peut être saisie sont les lignes pour lesquelles :
- la quantité gratuite n'est pas renseignée ;
- le mode d'achat est défini en sortie de stock interdite.

   La saisie de la répartition est obligatoire si la valeur testée 2 de l'occurrence REPART du paramètre AUTSAREA vaut "O". Ce contrôle est effectué par les traitements de confirmation des demandes d'achats (TEDA ou TCDA).

   Si la quantité de la ligne de demande d'achats est égale à 1 ou -1, la répartition est effectuée sur le prix (ou montant) sinon, elle est effectuée sur la quantité.
Par défaut, la somme des répartitions doit être égale au total à répartir. Néanmoins, les valeurs 1 et 2 de l'occurrence ECART du paramètre AUTSAREA permettent d'autoriser des écarts.

   Quand une répartition par année est saisie, la quantité et le prix de la ligne de demande d'achats sont automatiquement mis à jour avec la quantité et le prix de l'année en cours de la répartition. De ce fait, il est impossible de modifier manuellement le prix et/ou la quantité de la ligne de demande d'achats : ils sont pilotés depuis la répartition par année. La date de livraison prévue de la ligne (ou celle de l'en-tête ) peut elle être modifiée mais doit toujours respecter les critères autorisant la saisie d'une répartition (année future, nombre de mois).

   En cas de suppression de la répartition, la quantité et le prix de la ligne de demande d'achats sont réinitialisés avec la quantité et le prix saisis avant la répartition.

   Cette répartition peut être effectuée, en amont, dans l'e_Procurement.
Afin que cette répartition saisie depuis le panier puisse suivre sur la demande d'achats générée, un sas des répartitions par année a été créé.

SAIREA - Répartition par année (Transaction SAIREA)
TEDA - Confirmation des demandes d'achats (Transaction SATEDA)
TCDA - Confirmation des commandes (Transaction SATCCDA)

   Il faut activer la fonctionnalité via l'occurrence REPART du paramètre AUTSAREA.

   La valeur testée 1 indique si la répartition par année est possible :
- O : la répartition par année est autorisée ;
- N : la répartition par année est interdite.

   Par défaut, la valeur testée 1 est livrée à "N".

   La valeur testée 2 indique si la répartition par année est obligatoire :
- O : la répartition par année est obligatoire ;
- F : la répartition par année est facultative.

   Par défaut, la valeur testée 2 est livrée à "F".

   La valeur 1 donne l'écart minimum, en mois, qu'il doit y avoir entre la période de début et la période de fin pour pouvoir effectuer une répartition par année, les périodes devant être sur deux années distinctes.

   Une autre occurrence de paramètre doit être positionnée : l'occurrence ECART du paramètre AUTSAREA. Elle indique les écarts d'arrondi autorisés :

   La valeur 1 donne l'écart autorisé, pour les quantités, c'est-à-dire l'écart autorisé entre la quantité de la ligne de demande d'achats et la somme des quantités réparties.

   La valeur 2 donne l'écart autorisé, pour les prix, c'est-à-dire l'écart autorisé entre le prix de la ligne de demande d'achats et la somme des prix répartis.

   Par défaut, ces deux valeurs sont livrées à 0.

   Pour cela, création d'un traitement permettant le recalcul des conditions de facturation liées aux piges : toutes les conditions de facturation associées à la commande qui ont la nature égale à "P" sont supprimées et les conditions de facturation associées à la classe et au statut dans GCFSA sont créées pour la commande.
De plus, si le statut du tiers a changé entre la commande et la réception, le statut de la commande est mis à jour avec le nouveau statut du tiers.

TRCSRA - Recalcul cond. de fact. liées au statut après réc. (Transaction SATRCSR)

   Ce traitement doit être défini dans les étapes (GETPA) et les étapes par classe (GETCA), après réception et avant facture, comme suit :
- mnémonique d'appel : TRCSRA ;
- traitement associé : SATRCSR ;
- traitement par commande : pssarcsetp ;
- traitement par autre entité : pssarcsetp.

   3) Pour cela, une nouvelle case à cocher "Suivi des factures" a été ajoutée dans :
- le traitement de duplication de factures (TDFAA) ;
- la forme détail "Duplication de factures" du contrôle facture (GFAA) ;
- la forme détail "Duplication de factures" de la facturation détaillée (GFAAD).

   Si cette case est cochée, lors de la duplication d'une facture, un "lien" est automatiquement créé entre la facture dupliquée et la facture générée.

GSVFA - Suivi des factures (Transaction SAISVF)
CSVFA - Consultation du suivi des factures (Transaction SACSVF)
SAITSF - Suivi des factures : Interface (Transaction SAITSF)
GTFCA - Factures achats : Interface (Transaction SAITFC)
TTFCA - Intégration des factures d'achats (Transaction SATTFC)
TDFAA - Duplication de factures (Transaction SATDFA)
GFAA - Contrôle facture (Transaction SAIFAA)
GFAAD - Facturation détaillée (Transaction SAIFAAD)

   Pour cela, de nouvelles informations ont été ajoutées au niveau des actions des signatures (GASMA) :
- génération de tâche à l'exécution de l'action : permet d'avertir les signataires mis en attente de signature lors de l'exécution d'une action ;
- génération de tâche aux traitements : permet de déterminer sur quel traitement les tâches sont générées. Il est possible de les générer au traitement d'affectation des signataires (TASMx), au traitement de délégations (TAGSM) ou les deux ;
- génération de tâche à l'acceptation du dernier signataire : permet d'avertir le destinataire du retour d'information via une tâche une fois que l'élément soumis est signé ;
- génération de tâche à l'acceptation du dernier signataire au traitement d'affectation : permet d'avertir le destinataire du retour d'information via une tâche une fois que l'élément soumis est signé automatiquement lors du traitement d'affectation des signataires (TASMx).

   Dans les détails de signataires (GDSMx), les tâches collaboratives peuvent être déclenchées lors de l'ajout, modification ou suppression d'un signataire si, pour l'action "Accepter" définie pour la règle de signature et le mnémonique de signature correspondant aux détails de signataires, l'information "Génération de tâche aux traitements" a pour valeur "Affectation" ou "Les deux".

   NB : La mise en place de la génération des tâches collaboratives nécessite du paramétrage au niveau de Qualiac® Planification, ainsi que la présence du module QNIREG.

GASMA - Actions des signatures multicritères (Transaction SAIASM)
TASMDA - Affectation des signataires multicritères des DA (Transaction SATASMD)
GDSMDA - Détail des signatures multicritères des DA (Transaction SAIDSMD)
GSMDA - Signatures multicritères des demandes d'achats (Transaction SAISMD)
TASMCA - Affectation signataires multicritères commandes (Transaction SATASMC)
GDSMCA - Détail des signatures multicritères des commandes (Transaction SAIDSMC)
GSMCA - Signatures multicritères des commandes d'achats (Transaction SAISMC)
TASMRA - Affectation signataires multicritères réceptions (Transaction SATASMR)
GDSMRA - Détail des signatures multicritères des réceptions (Transaction SAIDSMR)
GSMRA - Signatures multicritères des réceptions (Transaction SAISMR)
TASMFA - Affectation des signataires multicritères factures (Transaction SATASMF)
GDSMFA - Détail des signatures multicritères des factures (Transaction SAIDSMF)
GSMFA - Signatures multicritères des factures d'achats (Transaction SAISMF)
TASMMA - Affectation signataires multicritères marchés (Transaction SATASMM)
GDSMMA - Détail des signatures multicritères des marchés (Transaction SAIDSMM)
GSMMA - Signatures multicritères des marchés (Transaction SAISMM)

   Nécessité de formation.

   Ajout de la possibilité d'intégrer des rubriques directement à partir du sas des références articles/fournisseurs (GTRAF).

   Pour cela, ajout de 5 rubriques et de leurs valeurs dans le sas des références articles/fournisseur (GTRAF).
Si la rubrique correspond à du texte, la valeur à utiliser est la valeur texte (vx1sataf pour la rubrique 1, vx2sataf pour la rubrique 2, ...).
Si la rubrique correspond à une date, la valeur à utiliser est la valeur date (vd1sataf pour la rubrique 1, vd2sataf pour la rubrique 2, ...).
Si la rubrique correspond à un numérique, la valeur à utiliser est la valeur numérique (vn1sataf pour la rubrique 1, vn2sataf pour la rubrique 2, ...).

   Lors de l'intégration, si des rubriques sont précisées dans le sas, elles sont intégrées en même temps que la référence : si la rubrique n'existe pas dans les rubriques par articles/fournisseurs (GARURAF), elle est créée sinon elle est mise à jour.

GTRAF - Références articles/fournisseurs de transfert (Transaction SAITAF)
TIART - Intégration des articles de transfert (Transaction SGTTAR)

   Modification du principe de répercussion de la modification de l'adresse du tiers par établissement (GATE) sur les adresses du fournisseur (GFOU) quand celui-ci a été créé à partir du tiers par établissement (paramètre AUTSAFOU occurrence GENERE).

   Pour cela, ajout de l'occurrence MAJADR pour le paramètre AUTSAFOU.

   Si la valeur testée 1 vaut :
- O : pour chaque adresse du fournisseur, mise à jour de l'adresse à partir de celle du tiers par établissement uniquement si le tiers correspondant du fournisseur est égal au tiers par établissement et si l'ancienne adresse du fournisseur est égale à l'ancienne adresse du tiers par établissement ;
- N : pour chaque adresse du fournisseur, mise à jour de l'adresse à partir de celle du tiers par établissement que le tiers du fournisseur soit identique ou pas au tiers par établissement et que l'adresse du fournisseur ait été modifiée manuellement ou pas.

   Si la valeur testée 2 vaut :
- F : mise à jour de l'adresse de facturation du fournisseur uniquement ;
- T : mise à jour de toutes les adresses du fournisseur (facturation, paiement, logistique et commande).

   Dans le cas où la valeur testée 1 vaut "O", pour chaque adresse du fournisseur, la mise à jour n'est effectuée que si la destination de l'adresse du tiers par établissement est correcte (destination contenant le caractère "P" pour l'adresse de paiement, le caractère "F" pour l'adresse de facturation, ...).

   Par défaut, cette occurrence de paramètre est livrée avec la valeur testée 1 à "N" et la valeur testée 2 à "F".

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

   1) Ajout de l'établissement de l'accord cadre afin de pouvoir avoir un accord cadre qui porte sur un établissement différent de ceux des marchés subséquents.

   2) Ajout de 3 champs texte de 240 caractères dans les marchés.

   1) Pour cela :
- ajout d'un nouveau champ "Etablissement de l'accord cadre" dans la forme détail des marchés publics (GMARA) et dans le sas des marchés (GTMARA) ;
- ajout de la fourchette d'établissements accord cadre dans la forme sélection des marchés (CSMARA et TSMARA) ;
- ajout de l'établissement de l'accord cadre au niveau des colonnes à modifier dans le traitement de duplication de marchés (TDMARA) ;
- possibilité de modifier l'établissement de l'accord cadre, d'un ou plusieurs marchés, de manière simultanée, à partir de la gestion de modification de masse des marchés (GMMARA).

   2) Pour cela :
- ajout des textes 6, 7 et 8 (tx6samar, tx7samar et tx8samar) dans la forme détail "Interlocuteurs" (GMARA) et dans le sas des marchés (GTMARA) ;
- ajout des textes 6, 7 et 8 au niveau des colonnes à modifier dans le traitement de duplication de marchés (TDMARA). Pour cela, ajout d'un nouveau pavé "Textes à modifier" dans la forme détail "Colonnes à modifier" ;
- possibilité de modifier les textes 6, 7 et 8, d'un ou plusieurs marchés, de manière simultanée, à partir de la gestion de modification de masse des marchés (GMMARA).

GMARA - Marchés (Transaction SAIMAR)
GTMARA - Interface des marchés (Transaction SAITMR)
TTMRA - Intégration des marchés (Transaction SATTMR)
CSMARA - Sélection des marchés (Transaction SACSMAR)
TSMARA - Sélection des marchés (Transaction SATSMAR)
TDMARA - Duplication de marchés (Transaction SATDMAR)
TDMARAV - Création de marchés à valider (Transaction SATDMARV)
GMMARA - Modification des marchés (Transaction SAMMAR)

   Lors de la création automatique des références articles/fournisseurs (GRAF) à partir des lignes de marchés, l'unité de prix et les coefficients de prix de la référence article/fournisseur créée sont renseignés par défaut à 1 si les informations correspondantes de la ligne de marché ne sont pas renseignées.

GMADA - Lignes de marchés de type 1 (Transaction SAIMAD)
GMALA - Lignes de marchés de type 2 (Transaction SAIMAL)

   1) Ajout de l'information complémentaire dans la grille afin de pouvoir renseigner celle-ci lors de la livraison de la demande de services.

   2) Ajout de la possibilité d'appeler, en synchronisation, la gestion de livraison des demandes de services (GRDA) à partir d'autres transactions que celle des lignes de réceptions en quantité.

GRDA - Livraison des demandes de services (Transaction SAIRDA)

   Possibilité, à partir d'un nouveau bouton "Calcul des dates de livraison", de calculer les dates au plus tôt des lignes en fonction du délai de livraison proposé pour chacun des articles.

   Pour cela, la proposition du délai de livraison des lignes de commandes a été modifiée : il est proposé à partir du délai de livraison de la référence article/fournisseur (GRAF) si celle-ci existe et s'il est renseigné, sinon à partir du délai de livraison du fournisseur.

   Une fois toutes les lignes de commandes saisies, il est possible de calculer, pour chacune des lignes de la commande, la date au plus tôt de livraison :
- le délai de livraison est ajouté à la date de commande ;
- la date au plus tôt de l'en-tête de commande est mise à jour avec la plus petite des dates au plus tôt des lignes ;
- la date au plus tard de l'en-tête de commande est mise à jour avec la plus grande des dates au plus tôt des lignes.

   Pour que le calcul de dates puisse être effectué, il est nécessaire que :
- la commande soit à l'étape de création ;
- la date de recherche de validité des références articles/fournisseurs doit être égale à "C" (date de commande) ou "CO" (date de contrat).

GCDA - Commandes d'achats (Transaction SAICDA)
GLCA - Lignes de commandes d'achats (Transaction SAILCA)

   1) Possibilité, lors de la génération des demandes d'achats ou des commandes, pour des lignes de marchés définies en cadencement manuel, d'alimenter la date de commande, la date au plus tôt et/ou la date au plus tard avec la date de notification de la ligne de marché si elle est renseignée, sinon avec la date de notification de l'en-tête.

   2) Possibilité, lors de la génération des demandes d'achats ou des commandes pour un marché, de ne pas attribuer systématiquement un nouveau numéro de demande ou de commande à chaque appel, mais de générer des sous-demandes ou sous-commandes à partir de la première demande d'achats ou commande générée.

   1) Pour cela, au niveau du paramétrage de la classe de marchés (GNCM), ajout de la valeur "NO" pour la proposition de la date de commande, de la date au plus tôt et de la date au plus tard.

   2) La conservation de la classe et du numéro de demande d'achats ou de commande générée au premier appel est effectué sur l'en-tête du marché pour chacun des types de lignes, ce qui va permettre aux générations d'appels suivants de reprendre cette classe et ce numéro de demande ou de commande afin de générer des sous-demandes ou des sous-commandes.
Cette fonctionnalité est donnée par le paramétrage de la classe de marchés (GNCM), pour chacun des types de lignes : cases à cocher "Conservation du numéro de commande".

GNCM - Classes de marchés (Transaction SAINCM)
TGAMA - Génération des appels d'achats pour un marché (Transaction SATGAMA)

   Possibilité de tenir compte de la nature de frais, lorsque celle-ci est renseignée, pour la recherche de la référence article/fournisseur lors la saisie de l'article (cas où la nature de frais est renseignée à partir d'une liste de valeurs particulière sur le code article).

   Pour cela, ajout de l'occurrence NFRPRODFT du paramètre AUTACHAT.

   Si la valeur testée 1 vaut :
- O : la référence article/fournisseur recherchée est celle définie pour l'article et la nature de frais de la ligne ;
- N : la référence article/fournisseur recherchée est celle définie par défaut.

   Dans le cas où la nature de frais n'est pas renseignée, aucun changement : l'occurrence du paramètre n'est pas prise en compte et la référence article/fournisseur recherchée est celle définie par défaut.

   1) Ajout d'un groupe de cases à cocher permettant de redéfinir plus finement les propositions par défaut sur l'en-tête de demande d'achats ou de commande.

   2) Ajout de la possibilité de modifier le type, la nature, le genre et le rôle de la demande d'achats ou commande générée.

   1) La case à cocher "Défaut fournisseur" est conservée avec son fonctionnement actuel dans le cas où elle est cochée.
Par contre, si elle est décochée, le nouveau groupe de cases est accessible et les informations liées au fournisseur peuvent être soit recopiées à l'identique sur la demande d'achats ou commande générée soit, pour certaines, proposées par défaut en fonction des différentes cases à cocher :

   - Tiers et adresses :
       - si cette case est cochée, les tiers et adresses de facturation, paiement, logistique et commande de l'en-tête de la demande d'achats ou de la commande générée sont proposés par défaut. Ces propositions sont identiques à celles qui sont faites lors de la saisie d'une demande d'achats (GDAI) ou d'une commande (GCDA),
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, les tiers et adresses de facturation, paiement, logistique et commande sont recopiés à l'identique. Par contre, s'il y a un changement d'établissement, de fournisseur et/ou de marché, les défauts sont appliqués même si aucune de ces deux cases n'est cochée ;

   - Informations taxe :
       - si cette case est cochée, les informations taxe (type, mode, régime) de l'en-tête de la demande d'achats ou de la commande générée sont proposées par défaut. Ces propositions sont identiques à celles qui sont faites lors de la saisie d'une demande d'achats (GDAI) ou d'une commande (GCDA),
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, les informations taxe (type, mode, régime) sont recopiées à l'identique. Par contre, s'il y a un changement d'établissement, de classe, de fournisseur et/ou de marché, les défauts sont appliqués même si aucune de ces deux cases n'est cochée ;

   - Devise :
       - si cette case est cochée, la devise de l'en-tête de la demande d'achats ou de la commande générée est proposée par défaut. Cette proposition est identique à celle qui est faite lors de la saisie d'une demande d'achats (GDAI) ou d'une commande (GCDA),
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, la devise est recopiée à l'identique. Par contre, s'il y a un changement d'établissement, de classe, de fournisseur et/ou de marché, les défauts sont appliqués même si aucune de ces deux cases n'est cochée ;

   - Dépôts :
       - si cette case est cochée, le dépôt de livraison et le dépôt client/fournisseur de l'en-tête de la demande d'achats ou de la commande générée sont proposés par défaut. Ces propositions sont identiques à celles qui sont faites lors de la saisie d'une demande d'achats (GDAI) ou d'une commande (GCDA),
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, le dépôt de livraison et le dépôt client/fournisseur sont recopiés à l'identique. Par contre, s'il y a un changement d'établissement, de classe, de fournisseur et/ou de marché, les défauts sont appliqués même si aucune de ces deux cases n'est cochée ;

   - Informations transport :
       - si cette case est cochée, les informations transport (type de port, mode de transport, transporteur et transitaire) de l'en-tête de la demande d'achats ou de la commande générée sont proposées par défaut. Ces propositions sont identiques à celles qui sont faites lors de la saisie d'une demande d'achats (GDAI) ou d'une commande (GCDA),
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, les informations transport (type de port, mode de transport, transporteur et transitaire) sont recopiées à l'identique. Par contre, s'il y a un changement d'établissement, de fournisseur et/ou de marché, les défauts sont appliqués même si aucune de ces deux cases n'est cochée ;

   - Echéances :
       - si cette case est cochée, les échéances sont créées par défaut à partir de l'échéance du marché si elle est renseignée, sinon à partir de l'échéance du fournisseur,
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, les échéances de la demande d'achats ou commande origine sont recopiées à l'identique sur la demande d'achats ou commande générée. Par contre, s'il y a un changement d'établissement, de fournisseur et/ou de marché, les défauts sont appliqués même si aucune de ces deux cases n'est cochée ;

   - Conditions de facturation :
       - si cette case est cochée, les conditions de facturation sont créées par défaut à partir :
              - des conditions de facturation obligatoires (GCFGA) ;
              - des conditions de facturation associées au fournisseur (GTFF) ;
              - des conditions de facturation associées à la classe d'achats (GCFCA).
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, les conditions de facturation de la demande d'achats ou de la commande sont recopiées à l'identique sur la demande d'achats ou commande générée. Par contre, s'il y a un changement d'établissement, de classe et/ou de fournisseur, les défauts sont appliqués même si aucune de ces deux cases n'est cochée ;

   - Gestionnaires :
       - si cette case est cochée, les gestionnaires (GCAG) sont créés par défaut à partir des gestionnaires associés au fournisseur (GTFG) et des autorisations des gestionnaires par classe (GAGC),
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, les gestionnaires de la demande d'achats ou de la commande origine sont recopiés à l'identique sur la demande d'achats ou commande générée. Par contre, s'il y a un changement d'établissement, les défauts sont appliqués même si aucune de ces deux cases n'est cochée ;

   - Rubriques :
       - si cette case est cochée, les rubriques (GRUCA) associées à l'en-tête de la demande d'achats ou de la commande générée sont créées par défaut à partir des rubriques associées au fournisseur (GARUFOU) et à la classe d'achats (GARUNCA),
       - si cette case n'est pas cochée et si la case "Défaut fournisseur" n'est pas cochée, les rubriques associées à la demande d'achats ou à la commande origine sont recopiées à l'identique sur la demande d'achats ou commande générée. Par contre, s'il y a un changement d'établissement, les défauts sont appliqués même si aucune de ces deux cases n'est cochée.

   2) Pour cela, ajout du type, de la nature, du genre et du rôle dans les colonnes à modifier.

TDCDA - Duplication de commandes (Transaction SATDCDA)

   La confidentialité sur les postes est maintenant prise en compte dans les lignes de demandes d'achats, de commandes, de réceptions et de factures achats.

GDAL - Lignes de demandes d'achats (Transaction SAIDAL)
GLCA - Lignes de commandes d'achats (Transaction SAILCA)
SAILCR - Lignes de réceptions en quantité (Transaction SAILCR)
SAILRM - Lignes de réceptions en montant (Transaction SAILRM)
SAILCF - Lignes de facture (Transaction SAILCF)

   Afin de gérer la confidentialité sur les postes, il faut référencer les clés d'accès par utilisateur ou par profil dans la gestion de confidentialité GCNF.

   1) Ajout de nouveaux critères pour l'affectation des signataires.

   2) Ajout de nouveaux critères de recherche dans les différentes gestions de signatures.
Afin d'affiner la recherche des éléments à signer, de nouveaux critères de sélection ont été ajoutés.

   3) Ajout de la possibilité, via un nouveau bouton (Acceptation globale), d'effectuer l'action "Accepter" pour tous les éléments à signer.
Cette nouvelle fonctionnalité est disponible uniquement dans les gestions de signatures des demandes d'achats (GSMDA - GKSMDA) et des commandes (GSMCA - GKSMCA).

   4) Ajout de la possibilité, via un nouveau bouton (Rafraîchir), de rafraîchir l'affichage des éléments à signer lors de la signature.
Pour cela, mise à disposition d'un bouton "Rafraîchir" dans les différentes gestions de signatures : signatures des demandes d'achats (GSMCA), des commandes (GSMCA), des réceptions (GSMRA), des factures (GSMFA) et des marchés (GSMMA).
Ce bouton permet de relancer la recherche des éléments à signer afin de ne plus visualiser les éléments pour lesquels une action a déjà été effectuée.

   5) Ajout de la possibilité de "Refuser pour resoumettre" lors de la signature des réceptions.
Pour cela, l'action "Refuser pour resoumettre" (RR) doit être associée à la règle de signature des réceptions (GASMA).

   6) Ajout de la possibilité de "Refuser pour resoumettre" lors de la signature des factures.
Pour cela, l'action "Refuser pour resoumettre" (RR) doit être associée à la règle de signature des factures (GASMA).

   7) Lancement des traitements suivants après l'auto-signature.
Lors du traitement d'affectation des signataires (TASMx), si l'élément traité (demande d'achats, commande, réception, facture ou marché) passe automatiquement l'étape de signature, il est possible de lancer les traitements suivants. Cette possibilité est donnée par la case "Lancement des traitements suivants" de l'action "Accepter" associée à la règle de signature concernée (GASMA).
De la même manière, les traitements suivants peuvent être lancés en cas d'auto-signature lors du traitement d'affectation des signataires délégués (TAGSM).

   8) Affectation des signataires en facture (TASMFA) : contrôle des montants HT et TTC de la facture.
Si la facture traitée n'est pas transférée en comptabilité, il est nécessaire, lors de la valorisation de celle-ci, d'effectuer les contrôles d'écarts entre :
- le montant HT de la facture et le montant HT des conditions de facturation (GCAF) ;
- le montant TTC de la facture et le montant TTC des conditions de facturations (GCAF).
Les écarts maximum autorisés sont donnés par le type de ventilation (GTVCA) utilisé pour la comptabilisation de la facture (TVCC). Le type de ventilation est donné par la chaîne 1 de l'occurrence xCTLFFAA du paramètre AUTSASOL (où x représente la valeur du PR1 associé au traitement).

   9) Signature automatique des factures après BAP.
Il est possible de rendre automatique la signature des factures si le bon à payer (TTAC) a été délivré pour une facture.

   10) Délégations multiples.
Il est désormais possible d'interdire des délégations multiples (GGSMA), c'est à dire, interdire qu'un déléguant puisse déléguer à plusieurs signataires sur une même période. Cette possibilité est donnée par la case "Délégation multiple" de la règle de signature concernée (GRSMA).

   11) Affectation des délégations (TAGSM).
Désormais, si pour une règle de signature, un élément à signer est en-cours de signature, cela n'empêche plus la pose des délégations pour les autres éléments à signer de cette règle.
De plus, si l'affectation des délégations est effectuée plusieurs fois par jour, il est possible de ne pas re-traiter les éléments pour lesquels la ou les délégations ont été affectées le jour même. Cette possibilité est donnée à la soumission, par la case à cocher "Ne pas retraiter les éléments du jour".

   12) Suppression des délégations multicritères (PGSMA).
Ce nouveau traitement permet de supprimer les délégations des signatures multicritères (GGSMA) périmées, c'est à dire dont la date de fin de validité est inférieure à la date saisie à la soumission.

   1) Ajout de nouveaux critères pour l'affectation des signataires.
Nouveaux critères pouvant être utilisés pour les règles de signatures des demandes d'achats, des commandes, des réceptions et/ou des factures :
- l'objet (OBSSACDA) ;
- l'observation sur la réception (OBRSACDA) ;
- l'observation sur la facture (OBFSACDA) ;
- l'observation sur le paiement (OBRSACDA) ;
- l'interlocuteur externe (INXSACDA) ;
- l'interlocuteur logistique (INLSACDA) ;
- la priorité (URGSACDA) ;
- le montant commandé d'une ligne de demande d'achats ou de commande (MNTLIGC) ;
- le type de la classe d'achats (TYPSANCA) ;
- la nature de la classe d'achats (NATSANCA) ;
- le genre de la classe d'achats (GENSANCA) ;
- le rôle de la classe d'achats (ROLSANCA) ;
- le marché de la commande (MARSACDA) ;
- le gestionnaire du marché de la commande (GESSAMARC) ;
- le gestionnaire technique du marché de la commande (GETSAMARC) ;
- le gestionnaire commercial du marché de la commande (GECSAMARC) ;
- le gestionnaire complémentaire 1 du marché de la commande (GC1SAMARC) ;
- le gestionnaire complémentaire 2 du marché de la commande (GC2SAMARC) ;
- le gestionnaire complémentaire 3 du marché de la commande (GC3SAMARC).

   Nouveaux critères pouvant être utilisés pour les règles de signatures des réceptions :
- l'interlocuteur externe (INXSAREC) ;
- l'interlocuteur interne (INLSAREC) ;
- le montant réceptionné d'une ligne de réception (MNTLIGR) ;
- le montant commandé d'une ligne de commande (MNTLIGC).

   Nouveaux critères pouvant être utilisés pour les règles de signatures des factures :
- le libellé (LIBSAFAA) ;
- le destinataire (DESSAFAA) ;
- l'interlocuteur externe (INXSAFAA) ;
- l'interlocuteur interne (INLSAFAA) ;
- les informations complémentaires (INFSAFAA) ;
- le montant facturé d'une ligne de facture (MNTLIGF) ;
- le montant réceptionné d'une ligne de facture (MNTLIGR) ;
- le montant commandé d'une ligne de facture (MNTLIGC).

   Nouveau critère pouvant être utilisé uniquement pour les règles de signatures des demandes d'achats ou des commandes : contrôle budgétaire (CTLBUD). Ce critère va permettre d'affecter un ou des signataires en fonction du résultat du contrôle budgétaire effectué lors de l'engagement (TVCCE). Les valeurs possibles pour ce critère au niveau de la matrice des signatures multicritères (GMSMA) sont O ou N :
- N : sera affecté le signataire correspondant si un des mouvements de l'écriture d'engagement est marqué en dépassement budgétaire ;
- O : sera affecté le signataire correspondant si aucun des mouvements de l'écriture d'engagement n'est marqué en dépassement budgétaire.

   Ce nouveau critère implique donc que la signature soit effectuée après l'engagement (TVCCE) et que celui-ci, lorsque le contrôle budgétaire est paramétré en signalé, donne la possibilité d'indiquer le budget dépassé dans une des informations du mouvement concerné. Cette possibilité est donnée par le paramètre AUTOBD occurrence SUISIG :
- la valeur testée 1 indique si la fonctionnalité est active (A) ou non (I) ;
- la chaine 1 permet de préciser le champ du mouvement à affecter. A choisir parmi : P11OCMVC, P12OCMVC, P13OCMVC, P14OCMVC, P15OCMVC, I01OCMVC, I02OCMVC, I03OCMVC, I04OCMVC, G01OCMVC, G02OCMVC.
Si cette fonctionnalité n'est pas active, il n'est donc pas possible d'utiliser le critère CTLBUD.

   De plus, Il est désormais possible, pour tous les critères portant sur les informations CGR A et/ou CGR B, d'appliquer ces critères sur les ventilations par CGR. Pour cela, au niveau des critères de signatures (GCSMA), la case à cocher «Prise en compte des ventilations par CGR» a été ajoutée.
Elle n'est accessible que pour les critères suivants :
- au niveau des demandes d'achats et/ou des lignes de demandes d'achats, des commandes et/ou des lignes de commandes (CG1SACDA, CG2SACDA, CG1SALCA, CG2SALCA, GESCGRNIVA, GESCGRNIVR, CGRNIVA, CGRNIVR) ;
- au niveau des marchés et/ou des lignes de marchés (CGRSAMAR, CG2SAMAR, CG1SAMAD, CG2SAMAD, GESCGMNIVA, GESCGMNIVR, CGRMIVA, CGRMIVR).

   Exemples :
a) Pour le critère Cxx, la colonne du critère est égale à "CG1SALCA" et la case "Prise en compte des ventilations par CGR" est cochée. Lors du traitement d'affectation des signataires (TASMxx), ce critère va être appliqué dans l'ordre de priorité suivant :
- ventilations par CGR de la ligne (GVCG) si renseignés ;
- CGR A de la ligne si renseigné ;
- ventilations par CGR de l'en-tête de la commande (GVCG) si renseignés ;
- CGR A de l'en-tête de commande sinon.

   b) Pour le critère Cxx, la colonne du critère est égale à "CG1SALCA" et la case "Prise en compte des ventilations par CGR" n'est pas cochée. Lors du traitement d'affectation des signataires (TASMxx), ce critère va être appliqué dans l'ordre de priorité suivant :
- CGR A de la ligne si renseigné ;
- CGR A de l'en-tête de commande sinon.

   2) Ajout de nouveaux critères de recherche au niveau des différentes gestions de signatures.

            a) Signatures multicritères des demandes d'achats (GSMDA) et des commandes (GSMCA)
Il est désormais possible de sélectionner les demandes d'achats et/ou les commandes à signer à partir :
- du niveau et/ou du type de niveau du signataire ;
- d'un ou des gestionnaires de la demandes d'achats ou de la commande (GCAG) ;
- d'un montant.
Pour cela, dans les gestions de signatures des demandes d'achats (GSMDA - GKSMDA) et de signatures des commandes (GSMCA - GKSMCA), les critères de recherche suivants ont été ajoutés :
- fourchettes de sélection sur le niveau et le type de niveau ;
- fourchettes de sélection sur le code gestionnaire, la fonction et le rôle du gestionnaire ;
- trois codes gestionnaires possibles. La sélection à partir du gestionnaire s'effectue, soit à partir d'un des 3 codes gestionnaires soit à partir des fourchettes de sélection sur le code, la fonction et/ou le rôle ;
- fourchette de sélection sur le montant : pour que cette sélection puisse fonctionner, il est nécessaire, au niveau de la règle de signature (GRSMA), de préciser la condition de facturation (GCAF) à partir de laquelle la sélection montant va s'appliquer.

            b) Signatures multicritères des réceptions (GSMRA) et des factures (GSMFA)
Il est désormais possible de sélectionner les réceptions et les factures à signer à partir :
- du niveau et/ou du type de niveau du signataire ;
- d'un montant.
Pour cela, dans les gestions de signatures des réceptions (GSMRA - GKSMRA) et de signatures des factures (GSMFA - GKSMFA), les critères de recherche suivants ont été ajoutés :
- fourchettes de sélection sur le niveau et le type de niveau ;
- fourchette de sélection sur le montant : pour que cette sélection puisse fonctionner, il est nécessaire, au niveau de la règle de signature (GRSMA), de préciser la condition de facturation à partir de laquelle la sélection montant va s'appliquer.

            c) Signatures multicritères des marchés (GSMRA)
Il est désormais possible de sélectionner les marchés à signer à partir du niveau et/ou du type de niveau du signataire.
Pour cela, dans la gestion de signatures des marchés (GSMMA - GKSMMA), les fourchettes de sélection sur le niveau et le type de niveau ont été ajoutées.

   De plus, dans toutes les gestions de signatures, il est désormais possible de visualiser, après la recherche, en plus des éléments qui peuvent être réellement signés par l'utilisateur connecté, les éléments qui pourraient être signés par cet utilisateur mais qui sont bloqués par un autre signataire (éléments en cours de signature). Pour ces éléments bloqués, le signataire, la date et l'heure de blocage sont affichés à titre indicatif, mais aucune action n'est possible.
Cette possibilité est donnée par la case "Affichage des éléments bloqués" de la règle de signature concernée (GRSMA).

   4) Ajout de la possibilité, via un nouveau bouton (Rafraîchir), de rafraîchir l'affichage des éléments à signer lors de la signature.
En standard, ce nouveau bouton n'est pas intégré à la page principale des différentes gestions de signatures.
L'utilisateur doit donc effectuer une personnalisation afin d'ajouter ce nouveau bouton ("REFRESH").

   5) Ajout de la possibilité de "Refuser pour resoumettre" lors de la signature des réceptions.
Selon le circuit d'étapes, l'étape de refus ne peut pas être la même. Il a donc été ajouté une étape de refus supplémentaire pour gérer ces différentes possibilités.

   Exemples :

   a) Cas où la signature est effectuée avant la génération de solde (TSOLA) et avant le traitement en stock (TSTA) :
- 400 : Réception (GREC) ;
- 410 : Calcul des pénalités liées au marché (TPENA) ;
- 420 : Calcul des révisions liées au marché (TREVA) ;
   - 425 : Refus 1 de la signature ;
- 430 : Affectation des signataires de la réception (TASMRA) ;
- 435 : Signature de la réception (GSMRA) ;
- 440 : Solde des commandes d'achats après réception (TSOLA) ;
- 460 : Mise à jour des achats en stock (TSTA)
L'étape de refus doit se situer obligatoirement entre l'étape de calcul des révisions liées au marché et celle de l'affectation des signataires. Dans ce cas-là, il n'est pas nécessaire de renseigner l'étape alternative de refus.

   De plus, seuls les traitements suivants peuvent se situer entre l'étape de réception et l'étape de refus :
- Contrôles marchés public après réception (TCDMPA) ;
- Calcul des pénalités liées au marché (TPENA) ;
- Calcul des révisions liées au marché (TREVA).

   b) Cas où la signature est effectuée après la génération de solde (TSOLA) et après le traitement en stock (TSTA) :
- 400 : Réception (GREC) ;
   - 405 : Refus 1 de la signature ;
- 440 : Solde des commandes d'achats après réception (TSOLA) ;
- 460 : Transfert en stock (TSTA) ;
   - 505 : Refus 2 de la signature ;
- 510 : Affectation des signataires de la réception (TASMRA) ;
- 520 : Signature de la réception (GSMRA).

   Il est possible d'envisager 2 étapes de refus distinctes selon l'évolution de la réception :
- si aucune commande n'a généré de solde réception (TSOLA), aucun retour n'a été généré (GRET) et la réception n'a pas été traitée en stock (TSTA), il est possible d'effectuer un retour à une étape se situant avant la génération de solde (405) ;
- si celle-ci a généré une solde réception (TSOLA), un retour a été généré (GRET) ou si la réception a été traitée en stock (TSTA), l'étape de retour doit obligatoirement se situer après le transfert en stock et juste avant l'affectation des signataires (505). Il ne doit pas y avoir d'étapes entre cette étape de refus et celle du traitement d'affectation des signataires.
Donc, pour la règle de signature des réceptions, au niveau du paramétrage de l'action "Refuser pour resoumettre" (RR), l'étape de refus est égale à 405 et l'étape alternative de refus est égale à 505.

   De plus, une requête permettant de déclencher un WIM est également à disposition afin d'informer les créateurs ou les gestionnaires que leur réception a été refusée pour re-soumission : QLC_SAC_SMC_REC_UNI_RET_KO_RR.

   6) Ajout de la possibilité de "Refuser pour resoumettre" lors de la signature des factures.

   Exemples :

   a) Cas où la signature est effectuée avant la comptabilisation des factures (TVCC) :
- 700 : Facture (GFAA) ;
   - 705 : Refus 1 de la signature ;
- 710 : Affectation des signataires de la facture (TASMFA) ;
- 715 : Signature de la facture (GSMFA) ;
- 720 : Comptabilisation des factures (TVCC).
L'étape de refus doit obligatoirement se situer juste après l'étape de facturation (ou être égale à celle-ci). Dans ce cas-là, il n'est pas nécessaire de renseigner l'étape alternative de refus.

   b) Cas où la signature est effectuée après la comptabilisation des factures (TVCC) :
- 700 : Facture (GFAA) ;
- 710 : Comptabilisation des factures (TVCC) ;
   - 715 : Refus 1 de la signature ;
- 720 : Affectation des signataires de la facture (TASMFA) ;
- 725 : Signature de la facture (GSMFA).
L'étape de refus doit être supérieure ou égale à l'étape de comptabilisation (TVCC) des factures. Dans ce cas, il n'est pas nécessaire de renseigner l'étape alternative de refus.

   c) Cas où la signature est effectuée après la génération de solde (TSOLF) et avant la comptabilisation des factures (TVCC) :
- 700 : Facture (GFAA) ;
   - 701 : Refus 1 de la signature ;
- 704 : Mise à jour des montants co-traitant/sous-traitant   (TMCSA) ;
- 705 : Solde des commandes d'achats après facture (TSOLF) ;
   - 706 : Refus 2 de la signature ;
- 710 : Affectation des signataires de la facture (TASMFA) ;
- 715 : Signature de la facture (GSMFA) ;
- 720 : Comptabilisation des factures (TVCC).

   Il est possible d'envisager 2 étapes de refus distinctes selon l'évolution de la facture :
- si pour la facture refusée, aucune commande n'a généré de solde de facturation (TSOLF), il est possible d'effectuer un retour à une étape se situant avant le traitement de solde des commandes (701). Il ne doit pas avoir d'étapes entre cette étape et l'étape de facturation (GFAA) ;
- si une des commandes de la facture a généré un solde de facturation (TSOLF), l'étape de refus doit obligatoirement se situer après le traitement de solde (TSOLF) et avant l'affectation des signataires (TASMFA). Il ne doit pas avoir d'étapes entre cette étape de refus et celle du traitement d'affectation des signataires (TASMFA).
NB : dans le cas où pour cette facture, une récupération d'avance a été générée (TRAA), l'étape de refus doit obligatoirement se situer juste avant l'affectation des signataires (TASMFA).
Donc, pour la règle de signature des factures, au niveau du paramétrage de l'action "Refuser pour resoumettre" (RR), l'étape de refus est égale à 701 et l'étape alternative de refus est égale à 706.

   De plus, une requête permettant de déclencher un WIM est également à disposition afin d'informer les créateurs ou les gestionnaires que leur facture a été refusée pour re-soumission : QLC_SAC_SMC_FAA_UNI_RET_KO_RR.

   9) Signature automatique des factures après BAP.
Si pour la règle de signature des factures (GRSMA), la case à cocher "Signature automatique après BAP" est cochée et que l'affectation des signataires des factures (TASMFA) est effectuée après le bon à payer (TTAC), deux cas de figure se présentent :
- le code rejet de la facture est renseigné (affecté par le bon à payer (TTAC)) : les signataires de la facture sont affectés normalement ;
- le code rejet de la facture n'est pas renseigné : la facture est signée automatiquement sans affectation de signataires.

   Pour cela, au niveau des règles de signatures facture, la case à cocher « Signature si rejet BAP » est modifiée : elle devient « Signature automatique après BAP » et sa prise en compte a également été modifiée dans l'affectation des signataires après facture (TASMFA).
Elle permet, lors de l'affectation des signataires (TASMFA), d'indiquer si l'affectation des signataires doit être effectuée dans le cas où le bon à payer a été délivré (TTAC) sur la facture :
- si elle est cochée : les signataires ne sont pas affectés et la facture passe automatiquement à l'étape de signature (GSMFA) ;
- si elle n'est pas cochée : les signataires sont affectés et la signature (GSMFA) doit être effectuée par chacun d'entre eux.
Dans tous les cas, si le bon à payer n'a pas été délivré (code rejet de la facture renseigné), les signataires sont affectés et la signature (GSMFA) doit être effectuée par chacun d'entre eux.
NB : cette fonctionnalité ne doit être utilisée que dans le cas où la signature (GSMFA) est effectuée après le bon à payer (TTAC).

GRSMA - Règles des signatures multicritères (Transaction SAIRSM)
GCSMA - Critères de signatures (Transaction SAICSM)
GMSMA - Matrice des signatures multicritères (Transaction SAIMSM)
GASMA - Actions des signatures multicritères (Transaction SAIASM)
TASMDA - Affectation des signataires multicritères des DA (Transaction SATASMD)
GSMDA - Signatures multicritères des demandes d'achats (Transaction SAISMD)
GDSMDA - Détail des signatures multicritères des DA (Transaction SAIDSMD)
TASMCA - Affectation signataires multicritères commandes (Transaction SATASMC)
GSMCA - Signatures multicritères des commandes d'achats (Transaction SAISMC)
GDSMCA - Détail des signatures multicritères des commandes (Transaction SAIDSMC)
TASMRA - Affectation signataires multicritères réceptions (Transaction SATASMR)
GSMRA - Signatures multicritères des réceptions (Transaction SAISMR)
GDSMRA - Détail des signatures multicritères des réceptions (Transaction SAIDSMR)
TASMFA - Affectation des signataires multicritères factures (Transaction SATASMF)
GSMFA - Signatures multicritères des factures d'achats (Transaction SAISMF)
GDSMFA - Détail des signatures multicritères des factures (Transaction SAIDSMF)
TASMMA - Affectation signataires multicritères marchés (Transaction SATASMM)
GSMMA - Signatures multicritères des marchés (Transaction SAISMM)
GDSMMA - Détail des signatures multicritères des marchés (Transaction SAIDSMM)
GGSMA - Délégations des signatures multicritères (Transaction SAIGSM)
TAGSM - Affectation délégations signatures multicritères (Transaction SATAGSM)
PGSMA - Suppression des délégations multicritères (Transaction SAPGSM)

   Prise en compte de l'étape maximale saisie à la soumission lors de l'édition d'une sous-commande seule. Ceci peut être utilisé, par exemple, pour ne pas éditer une sous-commande annulée.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   Ajout de l'établissement dans l'écran :
- des demandes d'achats d'interface (GTDAI) ;
- des commandes d'interface (GTCDA) ;
- des bons de livraison d'interface (GTBLA) ;
- des réceptions d'interface (GTREA) ;
- des factures d'interface (GTFCA).

   Ajout d'une fourchette d'établissements dans la soumission des traitements :
- d'intégration des demandes d'achats et des commandes (TTCDA) ;
- d'intégration des bons de livraison (TTBLA) ;
- d'intégration des réceptions (TTREA).

   NB : la fourchette d'établissements était déjà présente dans la soumission du traitement d'intégration des factures (TTFCA).

GTDAI - Interface des demandes d'achats (Transaction SAITCD)
GTCDA - Commandes d'interface (Transaction SAITCD)
GTBLA - Sas de saisie du BL (Transaction SAITBL)
GTREA - Réception des commandes d'achats : Interface (Transaction SAITRE)
GTFCA - Factures achats : Interface (Transaction SAITFC)
TTCDA - Intégration des commandes ou demandes d'achats (Transaction SATTCD)
TTBLA - Intégration des bons de livraison (Transaction SATTBL)
TTREA - Intégration des réceptions (Transaction SATTRE)

   Possibilité de paramétrer par défaut la date de réception, la référence BL, le dépôt, le dépôt fournisseur et le code qualité réception.

GRCPA - Réception (Transaction SAIRCP)

   1) Ajout de la possibilité de ne pas recopier les lignes créées à la réception sur la sous-commande générée en attente de réception.

   2) Ajout de la possibilité de générer une écriture d'engagement pour la sous-commande générée en attente de réception même s'il n'existe pas d'engagement sur la sous-commande à annuler.

   1) Pour cela, création de l'occurrence DUPLCR pour le paramètre AUTSAREC.

   Si la valeur testée 1 vaut :
- O : les lignes créées à la réception sont recopiées sur la sous-commande générée ;
- N : les lignes créées à la réception ne sont pas recopiées sur la sous-commande générée.

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

   2) Pour cela, ajout de l'occurrence ENG-xxxx où xxxx représente la classe de commandes pour le paramètre AUTSAREC.

   La chaîne 1 donne le type de ventilation à utiliser pour la génération de l'engagement.

   Si l'occurrence n'est pas définie pour la classe de la commande à annuler, c'est l'occurrence ENG, si elle existe, qui est prise en compte.
Si aucune de ces deux occurrences n'existe, l'engagement de la sous-commande en attente de réception n'est pas effectué.

TACRA - Annulation d'une commande réceptionnée (Transaction SATACR)

   Il est désormais possible (via un paramétrage au mnémonique du traitement TAMIMP) de transférer une immobilisation provisoire en immobilisation définitive après la réception de la commande associée (donc avec un code traitement égal à "RC"), sans attendre le contrôle facture.

   Pour cela, certaines gestions et traitements achats ont été modifiés pour prendre en compte cette possibilité.

   Lors de la facturation :
-   si la fiche d'immobilisation a un code traitement égal à "RC", pas de changement : le code traitement passe à "F" lors du contrôle facture (GFAA). Il passera ensuite à "FC" lors du traitement de mise à jour des immobilisations provisoires (TIMO) ;
- si la fiche d'immobilisation a un code traitement égal à "T", aucune mise à jour n'est effectuée sur la fiche d'immobilisation aussi bien lors du contrôle facture (GFAA) que lors du TIMO.

   Lors de l'annulation d'une commande réceptionnée (TACRA) :
- si la fiche d'immobilisation a un code traitement égal à "RC", pas de changement ;
- si la fiche d'immobilisation a un code traitement égal à "T", une fiche d'immobilisation de sens inverse est générée avec un code traitement égal à "RC" afin d'annuler la fiche d'immobilisation origine.

SAIFLC - Lignes à facturer (Transaction SAIFLC)
SAILCF - Lignes de facture (Transaction SAILCF)
TIMO - MAJ des immobilisations provisoires après facture (Transaction SATIMO)
TACRA - Annulation d'une commande réceptionnée (Transaction SATACR)

   Dans le cadre des droits d'auteurs, il est parfois nécessaire, au moment de la facturation, de recalculer les conditions de facturation liées aux auteurs.

   Ce recalcul est effectué sur le bouton "Valorisation" du contrôle facture en fonction de l'occurrence CAFPIG du paramètre AUTSAFAA.
Si la valeur testée 1 vaut :
- O : le recalcul des conditions de facturation liées aux piges est effectué sur le bouton "Valorisation" ;
- N : le recalcul des conditions de facturation liées aux piges n'est pas effectué.
Par défaut, la valeur testée 1 de cette occurrence a été initialisée à "N" par la release.

   Toutes les conditions de facturation qui ont la nature égale à "P" sont supprimées et les conditions de facturation associées à la classe et au statut dans GCFSA sont créées pour la commande.

   De plus, si le statut du tiers a changé entre la commande et la facture, le statut de la commande est mis à jour avec le nouveau statut du tiers.
La date utilisée pour la recherche du statut est donnée par l'occurrence STAxxxx, où xxxx représente la classe de commandes, du paramètre AUTSADAU.
Si le texte vaut :
- DATSAFAA : la date utilisée est la date de facture ;
- DECSAFAA : la date utilisée est la date comptable de facture ;
- DRFSAFAA : la date utilisée est la date de réception facture.
Le texte de cette occurrence n'a pas été initialisé par la release, il doit être renseigné si le recalcul doit se faire à la facture.

GFAA - Contrôle facture (Transaction SAIFAA)

   Lors de la suppression d'un en-tête de facture d'interface :
- contrôle qu'il n'existe pas d'enregistrement, pour la facture, dans la gestion des changements de signataires d'interface (SAITSG) ;
- suppression physique des réalisations d'abonnements à transférer (GTABT) pour la facture.

GTFCA - Factures achats : Interface (Transaction SAITFC)
GTABT - Réalisations des abonnements à transférer (Transaction OCITAT)

   Dans le cas où le regroupement des commandes n'est pas demandé, modification de l'affectation de la référence de la facture générée. Celle-ci peut désormais dépendre de la classe de la commande.

   Si le regroupement des commandes n'est pas demandé, la référence de la facture est affectée avec la référence de la commande rattachée à la facture si la valeur testée 1 de l'occurrence RCDE-xxxx, où xxxx représente la classe, du paramètre AUTSAFAA est égale à "O" ou, si cette occurrence n'existe pas, si la valeur testée 1 de l'occurrence REFCDE du paramètre AUTSAFAA est égale à "O". Si aucune de ces deux occurrences n'existe, la référence de la facture générée est affectée avec le numéro de la facture générée.

TGFAA - Génération automatique de factures (Transaction SATGFAA)
TGFAE - Génération automatique de factures (étape) (Transaction SATGFAE)

   1) Modification de l'affectation du compte des lignes générées.

   2) Possibilité de recopier les documents rattachés à la facture d'origine sur les factures générées.

   1) Le compte des lignes générées (lignes négatives et positives) est égal soit au compte des lignes origine soit au compte donné par la chaîne 1 du paramètre AUTSACSF occurrence PROCPT. Cela dépend de la valeur testée 1 de cette même occurrence.
Si la valeur testée 1 vaut :
- N : le compte de la ligne générée est égal au compte de la ligne origine ;
- O : le compte est égal au compte défini dans la chaîne 1. Ce compte doit être défini en génération de pièces interdite.

   2) Pour cela, ajout de la case à cocher "Recopie des documents" dans la gestion et dans le traitement de génération des factures de sous-traitance (SAIGFCS et TGFCSA).
Ne suivent que les documents dont le format de l'identifiant est conforme à l'entité de document (GTDEN) livré en standard (ACHAT FACTURE).

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)

   1) Ajout de la possibilité d'alimenter les identifiants longs 1 et 2 et les numériques 1 et 2 des mouvements comptables.

   2) Ajout de la possibilité d'envoyer les dates 1, 2 et 3 des lignes de commandes dans les dates 1 et 2 des mouvements comptables.

   3) Possibilité d'envoyer la classe, le numéro, le sous-numéro de commande, le code tiers et le nom réduit du tiers dans le libellé de l'écriture, le libellé complémentaire de l'écriture et/ou le libellé des mouvements.

   1) Pour cela, la gestion de paramétrage du transfert en comptabilité (GTVCA) a été modifiée afin d'ajouter des zones permettant de paramétrer l'alimentation des identifiants longs 1 et 2 et des numériques 1 et 2 des mouvements comptables. Ces zones ont été ajoutées sur la forme détail "Compléments".
Les identifiants longs des mouvements comptables peuvent être alimentés avec les identifiants 1, 2 et 3 des lignes de commandes.
Les numériques des mouvements comptables peuvent être alimentés avec les numériques 1, 2 et 3 des lignes de commandes.

   2) Les dates 1, 2 et 3 des lignes de commandes ont été ajoutées dans la liste des dates pouvant alimenter les dates 1 et 2 des mouvements comptables. Cette liste est donnée par les zones Date 1 et Date 2 de la gestion de paramétrage du transfert en comptabilité (GTVCA).

   3) Dans la gestion de paramétrage du transfert en comptabilité (GTVCA), ajout de la valeur "ST" (Sous-commande + Tiers) pour les valeurs possibles pour l'affectation des libellés et prise en compte de celle-ci dans les différents transferts en comptabilité.

GTVCA - Paramétrage transfert comptabilité achat (Transaction SAITVC)
TVCCD - Pré-engagement (Transaction SATVCCD)
TVCCE - Engagement (Transaction SATVCCE)
TVCCP - Factures non parvenues (Transaction SATVCCP)
TVCC - Comptabilisation des factures (Transaction SATVCC)
TDEG - Annulation des ventilations (Transaction SATDEG)

   Ajout de la possibilité, pour les lignes réceptionnables en montant et pour lesquelles la quantité solde facture est renseignée à 1 ou -1, de ne pas générer de solde en montant à zéro dans le cas où il n'y a aucun écart entre le montant facturé et le montant reçu s'il est renseigné sinon, avec le montant commandé.

   Cela dépend de l'occurrence SLDMNTZER du paramètre AUTSASOL.
Si la valeur testée 1 vaut :
- O : une sous-commande solde de montant zéro est générée ;
- N : aucune sous-commande solde n'est générée.
La valeur testée 1 de cette occurrence a été initialisée à "O" par la release.

TSOLF - Solde des commandes d'achats après facture (Transaction SATSOLF)

   Ajout de la possibilité d'exclure du contrôle les pièces de retenue de garantie.

   Pour cela, ajout du paramètre RGT associé au traitement.
Si la valeur du paramètre vaut :
- N : les échéances de pièces correspondant à des retenues de garantie ne sont pas contrôlées ;
- O : toutes les échéances de pièces sont contrôlées.
La valeur de ce paramètre a été initialisée à "O" par la release.

TCFP - Contrôle des factures payées (Transaction SATCFP)

   1) Ajout de la case à cocher "Report selon les informations commande".

   2) Ajout de la case à cocher "Paramètre à alimenter pour l'écriture de report".

   1) Dans le cas où sont reportées des commandes qui ont été imputées en comptabilité sur l'ancien exercice (engagement ou facture non parvenue effectué) et non annulées, cette case permet, lors du report, de générer l'écriture, sur le nouvel exercice, avec les informations actuelles de la commande et non pas avec les informations de l'écriture origine, notamment les informations analytiques (CGR A, CGR B). Ceci implique, par contre, que toute l'écriture est reportée et non pas uniquement les mouvements portant sur un CGR A et/ou un CGR B.

   2) Dans le cas de suivi de report de budgets, il est nécessaire d'identifier, en comptabilité, les mouvements de reports afin de ne pas impacter les budgets habituels.
Pour ce faire, une zone est prévue sur les mouvements afin d'alimenter un budget dédié au report : celle-ci est donnée par le paramètre AUTOBD occurrence REPORT et le paramètre du mouvement choisi doit être alimenté avec la valeur "R".

   Lorsque le traitement de report à nouveau (TRAN) créé l'écriture de report, il est désormais possible de faire en sorte que celui-ci alimente cette information sur les mouvements générés. Ceci est possible si la case "Paramètre à alimenter pour l'écriture de report" est cochée et si le report s'effectue selon les informations commande.

   Le paramètre des lignes de commandes à partir duquel le paramètre des mouvements est alimenté avec la valeur "R" est donné par la chaine 1 du paramètre AUTSAVCC occurrence REPORT-PRM. Les différentes valeurs possibles sont un des quinze paramètres associés aux lignes de commandes (GCAPL) : L01, L02, ..., L15 ou un des trois paramètres des lignes de commandes : PR1, PR2 ou PR3. Pour que l'alimentation du paramètre du mouvement soit effectué, il est nécessaire que le type de ventilation utilisé pour l'engagement et donc, pour l'écriture de report, soit paramétré afin d'alimenter les paramètres des mouvements HT à partir des paramètres des lignes de commandes.

TRAN - Report d'engagement (Transaction SATRAN)

   Dans le cas d'un écart sur la quantité reçue, recopie des conditions de facturation des lignes de commandes origine sur les lignes de commandes générées.

TGCAVA - Génération de commandes d'avoir (Transaction SATGCAV)

   Modification du traitement afin que celui-ci soit compatible Qualiac® Edition.

PCDA - Purge des demandes et des commandes d'achats (Transaction SAPCDA)

   Possibilité de découper le CGR A par segment dans le formulaire de recherche ceci afin de pouvoir faire des recherches, non pas pour le CGR A en totalité, mais par segment.

   Pour cela, ajout du paramètre CGR associé aux mnémoniques des consultations des demandes d'achats (CCDAD), des commandes d'achats (CCDAC), des lignes de demandes d'achats (CLCAD) et des lignes de commandes d'achats (CLCA).

   Si la valeur du paramètre vaut :
- O : le découpage du CGR A est effectué dans le formulaire de recherche ;
- N : le découpage du CGR A n'est pas effectué dans le formulaire de recherche.
La valeur est initialisée à "N" par la release.

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

   Lors de la recherche, ajout de la possibilité de ramener les commandes annulées sans toutefois les prendre en compte dans le calcul des différents cumuls.

   Pour cela, ajout du paramètre PR2 au mnémonique de la consultation.
Si la valeur du paramètre vaut :
- N : les commandes annulées ne sont pas prises en compte lors de la recherche. Seules les commandes dont l'étape est inférieure à la valeur 1 du paramètre AUTACHAT occurrence ETPANUxxxx où xxxx représente la classe d'achats sont affichées ;
- O : les commandes annulées sont prises en compte lors de la recherche. Les commandes sont ramenées quelle que soit leur étape.

CCDCA - Consultation des DA ou des commandes cumulées (Transaction SACCDC)
SBCCDC - Détail de la commande (demande) (Transaction SBCCDC)

   Prise en compte de l'établissement de la ligne de commande, réception ou facture lors de la recherche des compositions d'articles (GCAR) quand le chemin de composition (GCHC) indique que les compositions sont définies par établissement.

   Dans les lignes de commandes (GLCA) et les lignes de factures (SAILCF), l'établissement est pris en compte dans la recherche des articles composants quand l'article de la ligne est défini en génération composants (GATA).

   Dans les lignes de réceptions en quantité (SAILCR), l'établissement est pris en compte dans le cas où la ligne à substituer est renseignée pour contrôler qu'il existe bien une composition entre l'article à substituer et l'article de substitution.

GLCA - Lignes de commandes d'achats (Transaction SAILCA)
SAILCR - Lignes de réceptions en quantité (Transaction SAILCR)
SAILCF - Lignes de facture (Transaction SAILCF)

   Ajout d'une fourchette d'établissements dans le formulaire de recherche.

CVCC - Consultation des ventilations comptables achats (Transaction SACVCC)

   Dans le secteur Public, l'engagement n'est jamais annulé aussi, pour une commande, il est possible d'avoir, à un instant "t", plusieurs ventilations en cours ce qui est bloquant lors de la clôture des Achats (TCLOA). Pour pallier à cela, il faut donc pouvoir exclure le type de ventilation d'engagement du contrôle de cohérence des ventilations comptables.

   Pour cela, ajout de la zone "Type de ventilation à exclure" dans la gestion de clôture des achats (GCLOA).

   Dans le secteur Public, ce type de ventilation doit être renseigné avec le type de ventilation d'engagement.

GCLOA - Clôture des achats (Transaction SAICLO)
TCLOA - Clôture des achats (Transaction SATCLO)

   Correction de la mise à jour des stocks lors de la livraison d'une demande de service avec une quantité négative.

TSDA - Mise à jour en stock des demandes de services (Transaction SATSDA)
GRDA - Livraison des demandes de services (Transaction SAIRDA)
SAILAL - Détails par lots et emplacements (Transaction SAILAL)

   Correction d'un plantage (erreur NullPointerException) lors de la saisie d'un tiers si le champ établissement n'est pas renseigné.

GFOU - Fournisseurs (Transaction SAIFOU)

   1) Modification des contrôles liés aux marchés publics afin de ne plus prendre en compte les commandes annulées c'est à dire les commandes pour lesquelles l'étape est supérieure ou égale à l'étape donnée par la valeur 1 de l'occurrence ETPANUxxxx, avec xxxx égale à la classe d'achats, du paramètre AUTACHAT.

   2) Ajout des contrôles sur la cohérence des montants de l'accord cadre et des marchés subséquents dans le traitement de duplication de marché (TDMARA) et dans le traitement d'intégration des marchés (TTMRA).

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)
TDMARA - Duplication de marchés (Transaction SATDMA)
GTMARA - Interface des marchés (Transaction SAITMR)
TTMRA - Intégration des marchés (Transaction SATTMR)

   Correction des stocks projetés lors de la modification du dépôt si l'ancien et le nouveau dépôt n'ont pas la même influence en stock.

GCDA - Commandes d'achats (Transaction SAICDA)

   Correction de l'inversion des zones :
- taxe origine fin et taxe fin ;
- CGR B fin et taxe fin.

TSLCA - Sélection des lignes de commandes (Transaction SATSLCA)

   Correction test avant l'édition de l'étape DER.

   Le paramètre TRI remplace le paramètre DEP depuis la version H1_01. Ce paramètre DEP permettait de trier les lignes par dépôt et d'éditer l'étape DER si elle était présente dans la mise en forme. Un test avant l'édition de cette étape DER a été corrigé.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   1)   Lors de la mise à jour de la ligne de mouvement de stocks, correction de l'arrondi du prix afin que celui-ci ait le même nombre de décimales significatives que le prix du détail de PUMP.

   2) Correction des quantités et montants remontés dans le prix du détail de PUMP et dans les détails de la valorisation FIFO ou LIFO lorsque la réception d'un article est faite sur plusieurs emplacements et que le traitement est lancé en SQR.

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

   1) Correction, lors de l'import des données dans la grille, de l'affectation du contenu du champ classement (clasataf).

   2) Correction de la recherche du libellé de l'article lorsque le sas des références articles/fournisseurs (GTRAF) est ouvert à partir du sas des articles achetés (GTAA).

GTRAF - Références articles/fournisseurs de transfert (Transaction SAITAF)

   Lors de la génération du fichier résultat au format EDI, pas d'utilisation de séparateur de milliers pour les quantités, les prix et les montants.

EHCDA - Connecteur HOSPITALIS : commandes d'achats (Transaction SAEHCDA)

   1) Lors de la saisie d'un code qualité réception, dès la recherche, la propagation de ce code sur toutes les lignes ramenées n'est effectuée que pour les lignes portant sur un article pour lequel le contrôle qualitatif est actif dans GATA.

   2) Lors de la saisie d'un code qualité réception sur un article pour lequel le contrôle qualitatif n'est pas actif, affichage d'un message bloquant.

GRCPA - Réception (Transaction SAIRCP)
SAIRDT - Réception détail (Transaction SAIRDT)

   Correction de l'affectation des prix à zéro lors de la saisie d'une ligne de réception en quantité ou en montant avec un mode d'achat n'ayant pas d'influence sur la valorisation.

SAILCR - Lignes de réceptions en quantité (Transaction SAILCR)
SAILRM - Lignes de réceptions en montant (Transaction SAILRM)

   1) Correction de la recherche effectuée pour savoir si le dépôt client est géré par emplacement : c'est le dépôt physique du dépôt client qui est pris en compte pour cette recherche.

   2) Correction de la proposition de la quantité reçue en fonction du paramètre AUTSAREC occurrence QLAL-xxxx où xxxx représente la classe d'achats.

SAILAL - Détails par lots et emplacements (Transaction SAILAL)

    Lors de la génération de la sous-commande solde, correction de l'affectation de la quantité prévue achat au niveau des stocks projetés dans le cas où la réception de la ligne est partielle et qu'un retour temporaire a été effectué sur la ligne.

TSOLA - Solde des commandes d'achats après réception (Transaction SATSOLA)

   Suppression du contrôle sur l'appartenance du pays d'origine à l'Union Européenne.

LDEBA - Contrôle de la déclaration des échanges de biens (Transaction SGLDEB)

   1) Correction de la gestion du multi-établissements dans la matrice des signatures multicritères (GMSMA) : prise en compte des cases à cocher "Création", "Modification" et "Suppression", définies dans GTMME, lors de la création, modification ou suppression d'un enregistrement sur l'établissement cible.

   2) Correction d'un plantage (erreur NullPointerException) lors de l'ouverture de la gestion des signatures multicritères quelle que soit l'entité traitée (marché, demande d'achats, commande, réception, facture).

   3) Lors du traitement d'affectation des signataires (TASMCA) ou du traitement des délégations (TAGSM), dans le cas de l'auto-signature, affectation de la date et de l'heure de l'action.

   4) Correction afin de délivrer le bon à payer pour la facture, lors du passage d'étape, dans le cas de l'auto-signature.

GMSMA - Matrice des signatures multicritères (Transaction SAIMSM)
GSMDA - Signatures multicritères des demandes d'achats (Transaction SAISMD)
GSMCA - Signatures multicritères des commandes d'achats (Transaction SAISMC)
GSMRA - Signatures multicritères des réceptions (Transaction SAISMR)
GSMFA - Signatures multicritères des factures d'achats (Transaction SAISMF)
GSMMA - Signatures multicritères des marchés (Transaction SAISMM)
TASMCA - Affectation signataires multicritères commandes (Transaction SATASMCA)
TAGSM - Affectation délégations signatures multicritères (Transaction SATAGSM)

   Les liens vers Qualiac® RIA, contenus dans les e-mails envoyés à partir des WIMs des signatures multicritères, ne fonctionnaient pas lorsque le protocole https était utilisé.

   Pour corriger cela, la variable globale (GGLO) WIM_SBAMFSEC a été créée. Pour que les URL vers Qualiac® RIA fonctionnent, il faut que la valeur de cette variable globale soit égale à "&amfsecure=N" et que la variable globale WIM_SBQRROOT ne contienne plus cette valeur.

TAREQS - Exécution WIM signatures multicritères (Transaction SATREQS)
RSMCA - WIM récapitulatif des signatures multicritères (Transaction SARSMC)

   Si le traitement est lancé en batch, correction de l'affectation de la classe lors de la mémorisation de l'étape (CHECA).

TCEQ - Contrôle des équipements (Transaction SATCEQ)

   Correction de la recherche de l'étape du traitement lorsque celui-ci est lancé à partir de la soumission unique et que l'archivage est actif.

PCDA - Purge des demandes et des commandes d'achats (Transaction SAPCDA)

   Correction afin de ne pas mettre à jour la date et l'utilisateur d'acceptation si le type d'acceptation n'est pas modifié.

GFAA - Contrôle facture (Transaction SAIFAA)

   Correction du contrôle d'unicité dans le cas où la valeur testée 1 est égale à OM, RM, A, AM, B, BM, C, CM, D ou DM.

TGFAA - Génération automatique de factures (Transaction SATGFAA)
TGFAE - Génération automatique de factures (étape) (Transaction SATGFAE)

   Pour utiliser ce module, il est nécessaire de l'acquérir et d'avoir une formation. De la documentation peut être demandée auprès de votre commercial.

   Elle permet de visualiser tous les éléments à signer à partir d'un seul écran et il est possible d'accéder à un détail contenant des informations supplémentaires (Conditions de facturation, CGR, Gestionnaires, ...) pour les éléments à signer afin d'aider à la décision.

   Au niveau du paramétrage, afin que les éléments à signer soient visibles dans l'application mobile, il est nécessaire que la règle de signatures (GRSMA) soit définie active pour la signature mobile.

   De plus, les occurrences du paramètre AUTSASMM permettent de paramétrer l'affichage de l'application :
- LIB-SADAE : permet de déterminer le libellé à afficher pour les demandes d'achats à signer ;
- LIB-SACDA : permet de déterminer le libellé à afficher pour les commandes d'achats à signer ;
- LIB-SAREC : permet de déterminer le libellé à afficher pour les réceptions à signer ;
- LIB-SAFAA : permet de déterminer le libellé à afficher pour les factures à signer ;
- LIB-SAMAR : permet de déterminer le libellé à afficher pour les marchés à signer ;
- GES-SADAE : permet d'indiquer la fonction et le rôle du gestionnaire qui doit être affiché lors de la visualisation d'une demande d'achats. La chaîne 1 donne le rôle et la chaîne 2 donne la fonction ;
- GES-SACDA : permet d'indiquer la fonction et le rôle du gestionnaire qui doit être affiché lors de la visualisation d'une commande d'achats. La chaîne 1 donne le rôle et la chaîne 2 donne la fonction ;
- GES-SAREC : permet d'indiquer la fonction et le rôle du gestionnaire qui doit être affiché lors de la visualisation d'une réception. La chaîne 1 donne le rôle et la chaîne 2 donne la fonction ;
- GES-SAFAA : permet d'indiquer la fonction et le rôle du gestionnaire qui doit être affiché lors de la visualisation d'une facture. La chaîne 1 donne le rôle et la chaîne 2 donne la fonction ;
- LIGNRE : permet de déterminer, lors de la visualisation d'une réception, si les lignes non réceptionnées doivent être affichées ou pas. Cette possibilité est donnée par la valeur testée 1 ;
- LIGNFA : permet de déterminer, lors de la visualisation d'une facture, si les lignes non facturées doivent être affichées ou pas. Cette possibilité est donnée par la valeur testée 1.

   Possibilité d'intégrer à l'en-tête :
- une adresse de facturation ;
- une adresse de paiement ;
- une échéance ;
- une domiciliation.

   Pour cela, ajout de quatre occurrences pour le paramètre AUTSAFAC :
- TAFSATFC pour l'adresse de facturation ;
- TIASATFC pour l'adresse de paiement ;
- ECHSATFC pour l'échéance ;
- DOMATFC pour la domiciliation.

TFAAC - Extraction des factures achats CEGEDIM (Transaction SATFAAC)

   Remplacement du point-virgule par une virgule dans les valeurs exportées.

TFOUCG - Extraction des fournisseurs CEGEDIM (Transaction SATFOUCG)

   Remplacement du point-virgule par une virgule dans les valeurs exportées.

TEABCG - Extraction des abonnements CEGEDIM (Transaction SATEABCG)

   Remplacement du point-virgule par une virgule dans les valeurs exportées.

TECDCG - Extraction des commandes CEGEDIM (Transaction SATECDCG)

   Suppression des messages identiques dans le fichier warning pour éviter d'avoir des fichiers trop volumineux.

TFOURD - Extraction des fournisseurs ReadSoft (Transaction SATFOURD)

   Possibilité d'intégrer à l'en-tête :
- une adresse de facturation ;
- une adresse de paiement ;
- une échéance ;
- une domiciliation.

   Pour cela, ajout de quatre occurrences pour le paramètre AUTSAFAR :
- TAFSATFC pour l'adresse de facturation ;
- TIASATFC pour l'adresse de paiement ;
- ECHSATFC pour l'échéance ;
- DOMATFC pour la domiciliation.

TFAAR - Extraction des factures achats ReadSoft (Transaction SATFAAR)

   Prise en compte d'un type de ventilation particulier pour vérifier que toutes les commandes de la facture traitée aient été prises en charge au niveau FNP.

   Ce type de ventilation de factures non parvenues est donné par la chaîne 1 du paramètre AUTSAMDT occurrence MDTAUTO. Si elle n'est pas renseignée, la vérification s'effectue sans tenir compte du type de ventilation.

TSOLF - Solde des commandes d'achats après facture (Transaction SATSOLF)
TVFMA - Validation auto. des factures pour le mandatement (Transaction SATVFM)

   Ajout des colonnes :
ERASAASM - Etape alternative de refus
TEASAASM - Génération de tâche à l'exécution de l'action
TDSSAASM - Génération de tâche au dernier signataire
TSASAASM - Génér. tâche dernier signataire au trt d'affect.
TATSAASM - Génération de tâche aux traitements

   Modification des colonnes :
DTMSAASM - Destinataire de retour d'information : libellé "Destinataire e-mail retour" revu

   Modification de la colonne :
TYPSAASS - Type de mouvement comptable : libellé revu, "Type de mouvement" remplacé par "Type de mouvement comptable"

   Ajout des colonnes :
POSCNF - Confidentialité "Poste"

   Ajout des colonnes :
TVCSACLO - Type de ventilation à exclure

   Ajout des colonnes :
TRXSACSG - Date et heure

   Ajout des colonnes :
PVCSACSM - Prise en compte des ventilations par CGR

   Modification de la colonne :
BASSADRP - Base de calcul : libellé revu, "Base" remplacé par "Base de calcul"

   Ajout des colonnes :
TRXSADSM - Date et heure de l'action

   Modification des colonnes :
LUSSADSM - Choix parmi liste d'utilisateurs :
TMSSADSM - Timestamp :

   Modification de la colonne :
CODSAEAT - Code retour traitement : libellé revu, "Code retour" remplacé par "Code retour traitement"

   Ajout des colonnes :
NBASAEQM - Nombre de BT annulés
TARSAEQM - Tarif
GAMSAEQM - Gamme opératoire modèle
GDISAEQM - Génération (Obligatoire)

   Modification de la colonne :
DELSAFOU - Délai de livraison (en jours) : libellé revu, "Temps d'acheminement" remplacé par "Délai de livraison (en jours)"

   Ajout des colonnes :
TRXSALSG - Date et heure d'exécution

   Modification de la colonne :
MVCSALTA - Numéro du mouvement comptable : libellé revu, "Numéro du mouvement" remplacé par "Numéro du mouvement comptable"

   Ajout des colonnes :
CL1SAMAR - Classe de la DA ou de la cde ligne de type 1
NM1SAMAR - Numéro de la DA ou de la cde ligne de type 1
CL2SAMAR - Classe de la DA ou de la cde ligne de type 2
NM2SAMAR - Numéro de la DA ou de la cde ligne de type 2
EACSAMAR - Etablissement de l'accord cadre
TX6SAMAR - Texte 6
TX7SAMAR - Texte 7
TX8SAMAR - Texte 8

   Ajout des colonnes :
CN1SANCM - Conservation du numéro de DA ou commande 1
CN2SANCM - Conservation du numéro de DA ou commande 2

   Modification de la colonne :
CRESAPMC - Type de crédit par personne : libellé revu, "Type de crédit" remplacé par "Type de crédit par personne"

   Modification des colonnes :
MPMSAPPX - MAJ prix dans la ligne de mouvement de stock : libellé revu, "MAJ prix dans la ligne de mouvement" remplacé par "MAJ prix dans la ligne de mouvement de stock"
CMFSAPPX - Classe de mouvements de stock frais : libellé revu, "Classe de mouvements frais" remplacé par "Classe de mouvements de stock frais"
CMASAPPX - Classe de mouvements de stock avoir : libellé revu, "Classe de mouvements avoir" remplacé par "Classe de mouvements de stock avoir"

   Modification de la colonne :
DLVSARAF - Délai de livraison : libellé revu, "Délai habituel" remplacé par "Délai de livraison"

   Modification de la colonne :
DELSARFP - Signe : libellé revu, "Délai" remplacé par "Nbe de jours"

   Ajout des colonnes :
SGMSARSM - Signature mobile (Obligatoire)
AEBSARSM - Affichage des éléments bloqués (Obligatoire)
DLMSARSM - Délégation multiple (Obligatoire)
CFGSARSM - Cond. de facturation pour rech. par mnt (Facultative)

   Modification des colonnes :
TTASARSM - Signature automatique après BAP : libellé "Signature si rejet BAP" revu

   Modification de la colonne :
NRTSASTT - Nbe lignes avec retour article : libellé revu, "Nombre de lignes retours" remplacé par "Nbe lignes avec retour article"

   Ajout des colonnes :
ETASASVF - Etat
TYPSASVF - Type
NATSASVF - Nature
GENSASVF - Genre
ROLSASVF - Rôle
INFSASVF - Informations complémentaires
UDMSASVF - Utilisateur de modification
DDMSASVF - Date de modification

   Modification de la colonne :
FAGSASVF - Numéro de facture liée : libellé revu, "Numéro de facture liée" remplacé par "Numéro de facture générée"

   Ajout des colonnes :
RU1SATAF - Rubrique 1
VR1SATAF - Valeur de la rubrique 1
VD1SATAF - Valeur date de la rubrique 1
VX1SATAF - Valeur texte de la rubrique 1
VN1SATAF - Valeur numérique de la rubrique 1
RU2SATAF - Rubrique 2
VR2SATAF - Valeur de la rubrique 2
VD2SATAF - Valeur date de la rubrique 2
VX2SATAF - Valeur texte de la rubrique 2
VN2SATAF - Valeur numérique de la rubrique 2
RU3SATAF - Rubrique 3
VR3SATAF - Valeur de la rubrique 3
VD3SATAF - Valeur date de la rubrique 3
VX3SATAF - Valeur texte de la rubrique 3
VN3SATAF - Valeur numérique de la rubrique 3
RU4SATAF - Rubrique 4
VR4SATAF - Valeur de la rubrique 4
VD4SATAF - Valeur date de la rubrique 4
VX4SATAF - Valeur texte de la rubrique 4
VN4SATAF - Valeur numérique de la rubrique 4
RU5SATAF - Rubrique 5
VR5SATAF - Valeur de la rubrique 5
VD5SATAF - Valeur date de la rubrique 5
VX5SATAF - Valeur texte de la rubrique 5
VN5SATAF - Valeur numérique de la rubrique 5

   Modification de la colonne :
DLVSATAF - Délai de livraison : "Délai habituel" remplacé par "Délai de livraison"

   Ajout des colonnes :
MESSATFC - Message d'erreur

   Ajout des colonnes :
MESSATFL - Message d'erreur

   Modification de la colonne :
DELSATFO - Délai de livraison (en jours) : libellé revu, "Temps d'acheminement" remplacé par "Délai de livraison (en jours)"

   Ajout des colonnes :
EACSATMR - Etablissement de l'accord cadre
TX6SATMR - Texte 6
TX7SATMR - Texte 7
TX8SATMR - Texte 8

   Ajout des colonnes :
TRXSATSG - Date et heure

   Modification de la colonne :
NECSAVLC - Numéro du mouvement comptable : libellé revu, "Numéro échéance mouvement" remplacé par "Numéro du mouvement comptable"

   Ajout des colonnes :
DTXSAWSC - Date de blocage
HRXSAWSC - Heure de blocage

   Ajout des colonnes :
DTXSAWSR - Date de blocage
HRXSAWSR - Heure de blocage

   Ajout des colonnes :
DTXSAWSF - Date de blocage
HRXSAWSF - Heure de blocage

   Ajout des colonnes :
DTXSAWMS - Date de blocage
HRXSAWMS - Heure de blocage