Document de release de la version H4.01

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

   Pour cela, création d'une gestion et d'un traitement de clôture des marchés.

   1) Gestion de clôture des marchés (GCMAA)

   Elle donne l'étape à laquelle va être mis le marché une fois qu'il sera clôturé et permet de définir certains contrôles à effectuer lors de la clôture :
- contrôle des avances récupérées ;
- contrôle que le montant minimum soit atteint ;
- contrôle que les marchés subséquents soient clôturés.

   2) Traitement de clôture des marchés (TCLMA)

   Selon le paramétrage de la clôture des marchés (GCMAA), différents contrôles sont effectués :
- si la date de fin de validité n'est pas précisée à la soumission, le marché ne doit plus être valide à la date du jour ;
- il ne doit plus y avoir de commandes rattachées au marché telles que l'étape soit strictement inférieure à l'étape minimale paramétrée par la clôture des marchés (GCMAA) ;
- si la case "Avances récupérées" est cochée, il ne doit pas y avoir d'avances à récupérer pour ce marché : les pièces d'avances générées à partir des commandes dîtes d'avances doivent être soldées. Les commandes prises en compte sont celles dont la classe d'achats est donnée par le paramètre AUTSACLM occurrence AVP-XXXX où XXXX représente la classe d'achats ;
- si la case "Montant minimum atteint" est cochée et si la classe de marchés (GNCM) est définie en bon de commande (typologie de la classe de marchés est égale à "BDC"), le montant réalisé du marché, le montant réalisé général des lignes de type 1, le montant réalisé général des lignes de type 2, ainsi que le montant réalisé de chaque ligne de marché doivent être supérieurs au montant minimum associé. De même, la quantité réalisée de chaque ligne de marché doit être supérieure à la quantité minimale ;
- si la case "Clôture des marchés subséquents" est cochée et si la classe de marchés (GNCM) est définie en accord cadre (typologie de la classe de marchés est égale à "ACC"), les marchés subséquents à l'accord cadre (marchés qui référencent le marché accord cadre) doivent eux-mêmes être clôturés : l'étape des marchés subséquents doit être égale ou supérieure à l'étape de clôture paramétrée pour la classe de marchés (GMCAA) de chaque marché subséquent.

   Si aucune anomalie est détectée et si le traitement est lancé en réel :
- si la date de fin de validité de la soumission est renseignée, la date de fin de validité du marché est mise à jour avec cette date ;
- l'étape du marché est mise à jour : elle est égale à l'étape de clôture donnée par le paramétrage de la clôture des marchés (GCMAA). Cette étape doit être définie dans les étapes par classe des marchés (GETCMA).

GCMAA - Clôture des marchés achats (Transaction SAICMA)
TCLMA - Clôture des marchés (Transaction SATCLMA)

   L'étape de clôture doit être située dans les étapes par classe (GETCMA). Elle doit être définie comme suit :
- mnémonique d'appel : non renseigné ;
- traitement associé : non renseigné ;
- traitement par commande : non renseigné ;
- traitement par autre entité : non renseigné.

   Cette étape doit être supérieure ou égale à l'étape maximale autorisée pour la modification et la suppression des marchés et des lignes de marchés.

   Eléments de listes de signataires (GELUA) : quelle que soit l'action choisie, sont sélectionnés tous les éléments de listes d'utilisateurs signataires où l'utilisateur d'origine est référencé, valides à la date de la soumission.

   Matrice des signataires (GMSMA) : quelle que soit l'action choisie, sont sélectionnés les éléments de la matrice des signataires où l'utilisateur d'origine est référencé pour le type d'affectation égal à "Utilisateur" ou "Utilisateur + choix dans liste".

   Droits utilisateurs (GMSMA) : quelle que soit l'action choisie, sont sélectionnés les éléments où l'utilisateur d'origine est référencé.

   Délégations (GGSMA) : quelle que soit l'action choisie, sont sélectionnés les délégations pour lesquelles l'utilisateur signataire est égal à l'utilisateur d'origine ou le délégué est égal à l'utilisateur d'origine valides à la date de la soumission.
Remarque : dans le cas d'une duplication d'une délégation ou d'un remplacement, le droit de déblocage budgétaire ne peut être affecté pour le nouveau signataire que si celui-ci possède lui-même les droits de déblocage (GUSMA).

   Eléments en cours de signature (GDSMDA, GDSMCA, GDSMRA, GDSMFA, GDSMMA) : quelle que soit l'action choisie, ne sont concernés que les éléments (demande d'achats, commande, réception, facture, marché) pour lesquels il existe au moins un signataire qui n'a pas encore signé.

   Si le traitement est lancé en réel, une trace de l'action réalisée est historisée (CHRSA).

   NB : si le traitement effectue une duplication, un remplacement ou une suppression d'un signataire parmi les délégations (GGSMA) et/ou les éléments en cours de signatures (GDSMDA, GDSMCA, GDSMRA, GDSMA, GDSMMA), il est nécessaire de lancer le traitement d'affectation des délégués (TAGSM).

TRSGA - Remplacement de signataires (Transaction SATRSG)
CHRSA - Historique des remplacements de signataires (Transaction SACHRS)

   Ajout de la possibilité de contrôler qu'une commande ne soit pas entièrement réceptionnée à zéro.

   Pour cela, création d'un traitement par étape, situé après réception, qui contrôle que pour une commande, il existe au moins une ligne qui ne soit pas réceptionnée à zéro.

   Une commande réceptionnée à zéro est une commande pour laquelle toutes les lignes ayant influence sur la réception ont une quantité ou un prix réceptionné, suivant si la ligne est réceptionnable en quantité ou en montant, égal à zéro ou non renseigné.

TCRZA - Contrôle des réceptions à zéro (Transaction SATCRZ)

   Ce traitement doit être situé, dans les étapes par classe (GETCA), après la réception (GREC). Il doit être défini comme suit :
- mnémonique d'appel : TCRZA ;
- traitement associé : SATCRZ ;
- traitement par commande : pssacrzetp ;
- traitement par autre entité : pssacrzetp.

   Création de trois éditions pour le contrôle hiérarchisé de la dépense :

   1) Edition du récapitulatif annuel des contrôles (ERACA)

   2) Edition de l'analyse des anomalies (EANOCA)

   3) Résultats du CHD par catégorie, période, structure (ERDCA)

   1) Edition du récapitulatif annuel des contrôles (ERACA)
Cette édition affiche le nombre de factures qui ont été soumises au CHD sur une période souhaitée ainsi que la somme des montants TTC de ces dernières. Les éléments sont cumulés mensuellement pour ensuite, être affichés de manière synthétique.

   NB : Si une facture n'a pas été traitée par le traitement d'affectation des signataires en fonction du plan de contrôle (TASPCA), elle n'est pas prise en compte pour cette édition.

   2) Edition de l'analyse des anomalies (EANOCA)
Cette édition affiche, pour toutes les factures soumises à validation lors du traitement d'affectation des signataires en fonction du plan de contrôle (TASPCA), le nombre de factures pour lesquelles une anomalie a été saisie lors de la signature. L'anomalie est prise en compte, dès lors qu'au niveau de la signature facture, l'action "Refuser pour resoumettre (RR)" a été réalisée et qu'un code retour a été précisé (RETSADSM).

   Les données sont cumulées par plan de contrôle et par code retour. Il est ainsi possible de voir, pour un plan de contrôle, le nombre d'anomalies saisies pour chaque code retour (RETSACDA). Il est possible de visualiser jusqu'à 20 codes retour (RETSACDA).

   Si la case "Edition des totaux" est cochée, un tableau récapitulatif, permettant de visualiser les nombres d'anomalies patrimoniales et non patrimoniales, par plan de contrôle, est édité.
Une anomalie est patrimoniale si la chaîne 1 du paramètre RETSACDA de l'occurrence correspondant au code rejet est égale à "P".

   3) Résultats du CHD par catégorie, période, structure (ERDCA)
Cette édition affiche toutes les lignes des factures soumises à validation lors du traitement d'affectation des signataires en fonction du plan de contrôle (TASPCA).
Pour une ligne, sont visualisés :
- le numéro de facture ;
- le numéro de ligne ;
- le numéro de pièce ;
- le compte de la ligne ;
- le montant TTC de la ligne ;
- le code rejet s'il a été saisi lors de la signature ;
- le montant des erreurs si le code rejet est renseigné (montant TTC de la ligne).

   Un récapitulatif permet également de visualiser un total pour les anomalies patrimoniales et non patrimoniales.
Une anomalie est patrimoniale si la chaîne 1 du paramètre RETSACDA de l'occurrence correspondant au code rejet est égale à "P".

ERACA - CHD : Récapitulatif annuel des contrôles (Transaction SAERAC)
EANOCA - CHD : Analyse des anomalies (Transaction SAEANOC)
ERDCA - Résultats du CHD par catégorie, période, structure (Transaction SAERDC)

   Lors de l'intégration d'un tiers, si le code du tiers est affecté automatiquement, possibilité de mettre à jour le code du fournisseur, dans le sas des fournisseurs, avec le code tiers généré.

   S'il existe un enregistrement dans le sas des fournisseurs (GTFOA) avec le code fournisseur égal au code tiers du sas des tiers, lors de la création du tiers dans la table définitive (GTIE), si le numéro du tiers est affecté automatiquement, le code fournisseur, dans le sas des fournisseurs, est mis à jour avec le code du tiers généré.

   Cette mise à jour est effectuée :
- systématiquement si le tiers est généré à partir du bouton « Transfert » de la gestion des tiers à transférer (GTTE) ;
- selon la valeur du paramètre PR3 associé au traitement de transfert des tiers en comptabilité (TTTE) si le tiers est généré à partir du traitement.

   Si la valeur du paramètre PR3 vaut :
- O : la mise à jour est effectuée ;
- autre valeur ou paramètre inexistant pour le traitement : la mise à jour n'est pas effectuée.

   En standard, le paramètre PR3 n'est pas livré pour le traitement (TTTE). Il faut donc le créer, avec une valeur égale à "O", pour activer cette fonctionnalité.

   Cette mise à jour concerne le code fournisseur dans le sas des :
- fournisseurs (GTFOA) ;
- gestionnaires du fournisseur (GTGFA) ;
- rubriques du fournisseur (GTARUFOU) ;
- codes services (GETSE).

GTTE - Tiers à transférer (Transaction OEITTE)
TTTE - Transfert des tiers en comptabilité (Transaction OETTTE)

   Ajout d'une fourchette de fournisseurs à la soumission.

TTFOU - Intégration des fournisseurs (Transaction SATTFO)

   Ajout de la possibilité de créer le fabricant (GFAB) lors de l'intégration d'une référence article/fournisseur.

   Pour cela, ajout du tiers, de l'adresse et des intitulés complet et réduit du fabricant dans le sas des références articles/fournisseurs (GTRAF).

   Lors de l'intégration, si le tiers et l'adresse du fabricant sont renseignés et que le numéro interne du fabricant n'est pas renseigné dans le sas, recherche d'un fabricant pour l'établissement, le tiers, l'adresse, l'article et la période maximale (correspond à la date minimale (01/01/1900) et la date maximale (31/12/2099)).

   Si un fabricant est trouvé :
- mise à jour du fabricant dans GFAB : mise à jour de la référence du fabricant (refsafab) avec la référence fabricant (rfbsataf) précisée dans le sas ;
- mise à jour du sas des références articles/fournisseurs (GTRAF) : mise à jour du numéro interne du fabricant (fabsataf) avec le numéro interne du fabricant trouvé ;
- création ou mise à jour de la référence article/fournisseur (GRAF) avec les données précisées dans le sas.

   Si aucun fabricant n'est trouvé :
- création d'un fabricant (GFAB) pour l'établissement, le tiers, l'adresse, l'article et la période maximale. Les intitulés complet et réduit du fabricant sont affectés avec les intitulés complet et réduit précisés dans le sas pour le fabricant. S'ils ne sont pas renseignés dans le sas, le fabricant est créé avec les intitulés de la référence article/fournisseur s'ils sont renseignés dans le sas, sinon avec ceux de l'article acheté ;
- mise à jour du sas des références articles/fournisseurs (GTRAF) : mise à jour du numéro interne du fabricant (fabsataf) avec le numéro interne du fabricant créé ;
- création de la référence article/fournisseur dans GRAF avec les données précisées dans le sas.

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

   Ajout de la possibilité de modifier la famille supérieure du fournisseur dans la gestion des fournisseurs (GFOU).

   Pour cela, ajout de l'occurrence MAJFAM du paramètre AUTSAFOU.
Si la valeur testée 1 vaut :
- N : pas de mise à jour possible de la famille supérieure du fournisseur, la famille n'est pas accessible ;
- S : si une seule famille fournisseur est déjà associée au fournisseur, la famille supérieure est accessible dans la gestion et la mise à jour se traduit par :
        1) suppression des anciennes compositions de familles fournisseurs pour les chemins en génération automatique,
        2) création de la nouvelle association entre le fournisseur et la nouvelle famille supérieure pour tous les chemins de composition en génération automatique avec date de début égale au 01/01/1900 et date de fin égale au 31/12/2099 ;
- M : si une seule famille supérieure est déjà associée au fournisseur à la date du jour, la famille supérieure est accessible dans la gestion et la mise à jour se traduit différemment selon si le chemin de la composition est défini pour les statistiques ou pas :
       1) le type de chemin de la composition n'est pas défini pour les statistiques :
            - fermeture de la composition existante à la date du jour moins un jour,
            - création de la nouvelle association entre le fournisseur et la nouvelle famille supérieure pour tous les chemins de composition en génération automatique avec la date de début égale à la date du jour et date de fin égale au   31/12/2099.
       2) le type de chemin de la composition est défini pour les statistiques :
            - suppression des anciennes compositions familles fournisseurs pour les chemins en génération automatique ;
            - création de la nouvelle association entre le fournisseur et la nouvelle famille supérieure pour tous les chemins de composition en génération automatique avec la date de début égale au 01/01/1900 et date de fin égale au 31/12/2099.

   NB : la modification de la famille supérieure du fournisseur n'est possible qu'à partir de la gestion des fournisseurs (GFOU), elle n'est pas possible à partir du sas des fournisseurs.

GFOU - Fournisseurs (Transaction SAIFOU)

   1) Ajout de la possibilité d'avertir l'utilisateur quand le montant prévu du marché ou du marché pour les lignes de type 1 ou du marché pour les lignes de type 2 dépasse le montant de l'acte d'engagement suivant un écart autorisé prédéfini.

   2) Ajout de la possibilité, lors de la saisie d'une ligne pour une commande portant sur un marché, d'avertir l'utilisateur que le montant hors taxe de la ligne cumulé au montant en cours et au montant réalisé du marché a atteint un certain seuil. Ce seuil correspond à un pourcentage du montant prévu. Le message indiquant que le seuil est atteint est seulement signalé. La saisie de commandes n'est pas bloquée.

   3) Ajout de la possibilité de renseigner une date de notification en dehors de la période de validité du marché.

   1) Pour cela, une nouvelle fenêtre détail "Marchés publics" a été ajoutée au niveau de la classe de marchés (GNCM) avec les informations suivantes :
- un bouton de choix "Contrôle selon montant de l'acte d'engagement" : il permet de définir si le contrôle est bloquant, signalé ou n'est pas effectué ;
- un champ "Montant prévu contrôlé" : il indique le montant à partir duquel le contrôle est effectué :
        - MTPSAMAR : montant prévu général du marché,
        - MP1SAMAR : montant prévu du marché pour les lignes de type 1,
        - MP2SAMAR : montant prévu du marché pour les lignes de type 2 ;
- un champ "Ecart autorisé" : pourcentage en plus appliqué au montant de l'acte d'engagement avant de le comparer au montant prévu souhaité.

   Si le montant contrôlé dépasse le montant de l'acte d'engagement auquel on a ajouté le pourcentage maximal autorisé, alors un message apparaît à l'écran.
Si le contrôle est bloquant, la saisie du marché est bloquée.
Si le contrôle n'est pas bloquant, le dépassement est seulement signalé. La saisie du marché n'est pas bloquée.

   2) Pour cela, des seuils d'alertes, exprimés en pourcentage, ont été ajoutés au niveau de la classe de marchés (GNCM). Il est possible de définir des seuils différents pour :
- le montant prévu général du marché (seuil marché) ;
- le montant prévu du marché pour le type de ligne de marché associée à la ligne de commande (seuil marché ligne de type 1, seuil marché ligne de type 2) ;
- le montant prévu de la ligne de marché (seuil ligne de type 1, seuil ligne de type 2).

   Le contrôle est effectué dès lors que l'option "Contrôle mise à jour du marché" est cochée pour la classe (GNCA) de la commande, que le mode d'achat (GMDA) de la ligne influe sur les marchés et que le seuil est renseigné.

   3) Pour cela, ajout d'une case à cocher "Date de notification incluse dans la période de validité du marché" dans la nouvelle fenêtre détail "Marchés publics" des classes de marchés (GNCM).

   Si la case est cochée, la date de notification doit obligatoirement être incluse dans la période de validité du marché : date de notification de la ligne de marché si elle est renseignée, sinon date de notification du marché.
Si la case n'est pas cochée, il est possible de renseigner une date de notification hors de cette période que ce soit au niveau du marché ou des lignes de marchés.

GNCM - Classes de marchés (Transaction SAINCM)
GMARA - Marchés (Transaction SAIMAR)
GMADA - Lignes de marchés de type 1 (Transaction SAIMAD)
GMALA - Lignes de marchés de type 2 (Transaction SAIMAL)
GLCA - Lignes de commandes d'achats (Transaction SAILCA)
TGAMA - Génération des appels d'achats pour un marché (Transaction SATGAM)

   1) Lors de la mise à jour des compléments des marchés publics (GCMP) à partir de différents traitements, si la classe de marchés (GNCM) est définie en multi-établissements, la mise à jour est effectuée sur tous les établissements de la composition (GCET) donnée par la classe de marchés.

   2) Lors de l'actualisation des prix liés aux marchés (TACMA), si la classe de marchés (GNCM) est définie en multi-établissements, l'actualisation est effectuée sur tous les établissements de la composition (GCET) donnée par la classe de marchés.

   3) Lors de l'ajout d'un établissement dans une composition d'établissements utilisée dans le cadre de la gestion des marchés multi-établissements (TMMEA), l'historique de l'actualisation des prix des lignes de marchés (CHACMA) est créé sur l'établissement cible.

   4) Dans les lignes de marchés, ajout de la possibilité de passer d'un type de tranche "Conditionnel" à "Ferme" lorsque la classe de marchés est définie en multi-établissements à partir du moment où il existe une commande portant sur le marché pour un des établissements de la composition.

   5) Possibilité de signer des marchés (GSMMA/GKSMMA) pour lesquels la classe de marchés (GNCM) est définie en multi-établissements.

   1) Les différentes mises à jour concernées sont :
- la mise à jour des montants co-traitants/sous-traitant (TMCSA) ;
- la mise à jour des avances récupérées lors de la récupération d'avances (TRAA).

   5) Lorsque le traitement d'affectation des signataires (TASMMA) traite un marché pour lequel la classe de marchés est définie en multi-établissements, les signataires sont affectés uniquement sur le marché de l'établissement traité, selon la matrice (GMSMA) définie pour cet établissement et la règle de signature associée.
Pour les marchés de même numéro mais, pour les autres établissements de la composition (GCET) donnée par la classe de marchés, seule l'étape du traitement est mise à jour.

   De même, lors de la signature d'un marché (GKSMMA/GSMMA) pour lequel les signataires ont été affectés, la mise à jour de l'étape de signature est effectuée sur tous les marchés de même numéro pour tous les établissements de la composition (GCET) donnée par la classe d'achats.

   Afin de pouvoir visualiser les détails de signatures des marchés (GDSMMA) à partir d'un marché (GMARA) pour lequel la classe de marchés est définie en multi-établissements, le paramètre PRE associé au mnémonique permet d'indiquer si la visualisation s'effectue uniquement pour l'établissement du marché courant ou pour tous les établissements de la composition (GCET) donnée par la classe de marchés.
Si la valeur du paramètre vaut :
- N : la recherche des détails de signatures s'effectue pour le marché et uniquement pour l'établissement du marché courant ;
- O : la recherche des détails de signatures s'effectue pour le marché et pour tous les établissements de la composition (GCET) définie pour la classe de marchés.

   De même, à partir de la consultation des détails de signatures (CDSMMA), il est désormais possible de rechercher les détails de signatures pour tous les établissements appartenant à une composition d'établissements (GCET).

TMCSA - Mise à jour des montants co-traitant/sous-traitant (Transaction SATMCS)
TRAA - Récupération d'avances (Transaction SATRAA)
TACMA - Actualisation des prix liés aux marchés (Transaction SATACM)
GMADA - Lignes de marchés de type 1 (Transaction SAIMAD)
GMALA - Lignes de marchés de type 2 (Transaction SAIMAL)
TASMMA - Affectation signataires multicritères marchés (Transaction SATASMM)
GDSMMA - Détail des signatures multicritères des marchés (Transaction SAIDSMM)
CDSMMA - Consultation des signatures multicritères marchés (Transaction SACDSMM)
GSMMA - Signatures multicritères des marchés (Transaction SAISMM)

   Ajout de la possibilité de choisir la valeur à affecter à la case à cocher « A traiter » pour les lignes de marchés dupliquées.

   Pour cela, ajout de deux boutons de choix pour le traitement de duplication des marchés (TDMARA) et pour la fenêtre détail "Recopie" de la gestion des marchés (GMARA) : un bouton de choix pour les lignes de type 1 et un pour les lignes de type 2.

   Pour chacun de ces boutons de choix, trois valeurs sont possibles :
- Recopie : la valeur du champ "A traiter" (trtsamad) de la ligne origine est recopiée dans la nouvelle ligne dupliquée ;
- A traiter : affectation du champ "A traiter" pour la nouvelle ligne dupliquée avec la valeur égale à "A" (case cochée) ;
- Non traité : affectation du champ "A traiter" pour la nouvelle ligne dupliquée avec la valeur égale à "I" (case décochée).

GMARA - Marchés (Transaction SAIMAR)
TDMARA - Duplication de marchés (Transaction SATDMAR)

   1) Lors de la suppression d'un en-tête de demande ou de commande d'interface, suppression de toutes les informations annexes associées à la demande ou à la commande : lignes d'interface, gestionnaires d'interface, textes d'interface en-tête et ligne, ventilations par CGR d'interface en-tête et ligne, ...

   2) Ajout de la possibilité d'ouvrir le mnémonique des lignes de demandes ou de commandes d'interface (SAITLC) de manière autonome, sans passer par la transaction gérant l'en-tête (GTDAI ou GTCDA).
NB : pour pouvoir créer une ligne, il est nécessaire que l'en-tête de la demande ou de la commande d'interface existe déjà dans la table de sas.

GTDAI - Interface des demandes d'achats (Transaction SAITCD)
GTCDA - Commandes d'interface (Transaction SAITCD)
SAITLC - Lignes de commandes d'achats : Interface (Transaction SAITLC)

   Dans le cas où la taxe du sas est renseignée, ajout de la possibilité de proposer une taxe équivalente à celle-ci, compatible avec les informations taxes de l'en-tête de la demande d'achats ou de la commande.

   Pour cela, ajout d'un bouton de choix "Taxe" dans les classes de transfert (GTNC).
Deux valeurs sont possibles :
- "Taxe interface" : la taxe de la ligne de demande d'achats ou de commande générée est égale à la taxe du sas si elle est renseignée, sinon elle est proposée par défaut ;
- "Taux taxe interface" : la taxe de la ligne de demande d'achats ou de commande générée est égale à la taxe du sas si elle est renseignée et si elle est compatible avec les informations taxes de l'en-tête de la demande d'achats ou de la commande générée, sinon il est recherché une taxe telle que :
     - le type de taxe est égal au type de taxe de l'en-tête de demande d'achats ou de commande,
     - le mode de taxe est égal au mode de taxe de l'en-tête de demande d'achats ou de commande,
     - le régime de taxe est égal au régime de taxe de l'en-tête de demande d'achats ou de commande,
     - le code taxe est égal au code de la taxe du sas,
     - la part de la taxe est égale à la part de la taxe du sas.
Dans le cas où la taxe du sas n'est pas renseignée, elle est proposée par défaut.

   L'information "Taxe" des différentes classes de transfert (GTNC) a été initialisée à la valeur "Taxe interface" par la release.

GTNC - Classes de transfert (Transaction SAITNC)
TTCDA - Intégration des commandes ou demandes d'achats (Transaction SATTCDA)

   Possibilité, lors de la génération d'une demande d'achats ou d'une commande, pour des lignes de marchés définies en cadencement manuel, d'alimenter l'objet de la demande d'achats ou de la commande, avec l'intitulé de la première ligne de marché concernée par la génération.

   Pour cela, au niveau du paramétrage de la classe de marchés (GNCM), ajout de la valeur "L" pour la proposition de l'objet commande.

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

   1) Pour cela, ajout d'un pavé "Documents" dans la forme détail "Recopie des lignes".

   Si la case "Recopie des documents" est cochée, les documents associés aux lignes de la demande d'achats ou de la commande origine pour lesquels l'entité de documents (GTDEN) est égale à celle précisée, sont copiés.
Ne peuvent être copiés que les documents dont le format de l'identifiant est conforme au GTDEN livré en standard (ACHAT LIGNE) : numéro interne de la demande d'achats ou de la commande concaténé au numéro de ligne.

   Il est également possible de préciser si tous les types de documents (GTDTY) associés à l'entité (GTDAE) doivent être copiés ou si, seuls les documents dont le type est indiqué sont copiés. Dans ce cas, jusqu'à trois types de documents différents peuvent être précisés.

   2) Pour cela, ajout d'une forme détail "Duplication" permettant de dupliquer la demande ou la commande actuellement affichée dans GDAI ou GCDA. La demande d'achats ou la commande est dupliquée à l'identique ou en modifiant certaines informations.

GDAI - Demandes d'achats (Transaction SAIDAE)
GCDA - Commandes d'achats (Transaction SAICDA)

   1) Pour cela, ajout de la case à cocher "Hors marché".
Si la case est cochée, les informations fournisseur, devise, tiers et adresse de facturation, tiers et adresse de paiement, tiers et adresse logistiques, tiers et adresse de commande, dépôt, mode de transport, type de port, destination et échéances ne sont pas proposées à partir du marché mais à partir du fournisseur même si le marché est renseigné.
Si cette case n'est pas cochée, ces informations sont proposées à partir du marché s'il est renseigné, sinon à partir du fournisseur.

   2) Pour cela, ajout d'une nouvelle forme détail "Documents".
La recopie des documents associés à l'en-tête est distincte de la recopie des documents associés aux lignes grâce aux cases à cocher "Recopie des documents en-tête" et "Recopie des documents lignes".

   Si la case "Recopie des documents" (en-tête et/ou ligne) est cochée, les documents associés à l'en-tête et/ou aux lignes de la demande d'achats ou de la commande origine pour lesquels l'entité de documents (GTDEN) est égale à celle précisée, sont copiés.
Ne peuvent être copiés que les documents dont le format de l'identifiant est conforme au GTDEN livré en standard :
- ACHAT COMMANDE pour les documents associés à l'en-tête : numéro interne de la demande d'achats ou de la commande ;
- ACHAT LIGNE pour les documents associés aux lignes : numéro interne de la demande d'achats ou de la commande concaténé au numéro de ligne.

   Il est également possible de préciser si tous les types de documents (GTDTY) associés à l'entité (GTDAE) doivent être copiés ou si, seuls les documents dont le type est indiqué sont copiés. Dans ce cas, jusqu'à trois types de documents différents peuvent être précisés.

TDCDA - Duplication de commandes (Transaction SATDCDA)

   Ajout de la possibilité de sélectionner les demandes d'achats ou les commandes à partir de leur montant.

   Pour cela, dans la fenêtre détail "Conditions de facturation", ajout d'un pavé "Sélection montants" avec une condition de facturation et une fourchette de montants.
Il est ainsi possible de sélectionner, par exemple, toutes les commandes dont le montant HT est compris entre 1000 et 5000 Euros en précisant, le numéro de la condition de facturation correspondant au Montant marchandises dans la zone "Condition de facturation" et, 1000 à 5000 dans la fourchette de montants.

   NB : pour pouvoir être sélectionnée, la demande d'achats ou la commande doit être, au préalable, valorisée.

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

   Ces deux possibilités sont données par le paramètre AUTACHAT occurrence PROPTVA.

   Si la chaîne 1 est égale à :
- O : la classe est obligatoire. Les propositions de TVA doivent obligatoirement être définies par classe d'achats ;
- N : la classe n'est pas obligatoire. Les propositions de TVA peuvent être définies sans classe d'achats.

   Si le type de CGR est égal à "A" et si la chaîne 2 est égale à :
- CGR : les propositions de TVA sont définies pour un segment de CGR A ;
- PR1OECGR, PR2OECGR, ...., P20OECGR : les propositions de TVA sont définies pour le paramètre correspondant du segment de CGR A.

   Remarque : si des propositions de TVA sont définies pour une classe donnée, les informations taxes de l'en-tête de demande d'achats ou de commande ainsi que la taxe des lignes de demandes d'achats, de commandes, de réceptions ou de factures sont recherchées parmi les différentes propositions de TVA définies pour cette classe. Les propositions de TVA qui sont définies sans la classe d'achats ne sont pas prises en compte.

   NB : les chaînes 1 et 2 sont initialisées respectivement à "O" et "CGR" par la release.

GPPTA - Proposition TVA (Transaction SAIPPT)
GDAI - Demandes d'achats (Transaction SAIDAE)
GDAL - Lignes de demandes d'achats (Transaction SAIDAL)
TGDVA - Génération des devis (Transaction SATGDV)
TADVA - Acceptation des devis (Transaction SATADV)
GTDAC - Génération de commandes à partir de DA (Transaction SAITDAC)
TDAI - Génération de commandes à partir de DA (Transaction SATDAI)
TGDAI - Génération automatique de commandes à partir de DA (Transaction SATGDAI)
GCDA - Commandes d'achats (Transaction SAICDA)
GLCA - Lignes de commandes d'achats (Transaction SAILCA)
TDCDA - Duplication de commandes (Transaction SATDCDA)
TTCDA - Intégration des commandes ou demandes d'achats (Transaction SATTCDA)
TGCDA - Génération des commandes d'achats / fournisseur(s) (Transaction SATGCDA)
TGAMA - Génération des appels d'achats pour un marché (Transaction SATGAM)
SAILCR - Lignes de réceptions en quantité (Transaction SAILCR)
SAILRM - Lignes de réceptions en montant (Transaction SAILRM)
SAILCF - Lignes de facture (Transaction SAILCF)
TRFPA - Génération des remises de fin de période (Transaction SATRFP)
TGCEA - Génération de commandes d'écart (Transaction SATGCE)

   Lors du traitement d'application du seuil (TSIMA), possibilité de modifier le mode d'achat de la ligne en comparant le montant du seuil, permettant de définir si l'article de la ligne doit être immobilisé ou non, soit au montant HT de la ligne soit au prix commandé de la ligne.

   Pour cela, la case à cocher « Seuil immobilisation » des articles achetés (GATA) est remplacée par un bouton de choix :
- Montant unitaire : c'est le montant de la ligne qui est comparé au montant du seuil ;
- Prix unitaire : c'est le prix commandé de la ligne qui est comparé au montant du seuil ;
- Non géré : pas de prise en compte du seuil et pas de modification du mode d'achat.

   Rappel : le montant du seuil est donné par la valeur 1 de l'occurrence SEUIL du paramètre AUTSAIMO.

GATA - Articles achetés (Transaction SAIATA)
GTAA - Articles achetés de transfert (Transaction SAITAA)
TSIMA - Application du seuil d'immobilisation (Transaction SATSIM)

   1) Ajout de la possibilité de gérer une autre destination que FAX, MAIL, Imprimante ou aucun envoi.

   2) Lors d'un envoi par mail du bon de commande, ajout de la possibilité de choisir l'adresse de l'expéditeur du mail et de demander un accusé de réception au fournisseur.

   3) Ajout de la possibilité d'inclure la révision au prix de chaque ligne de commande.

   1) Pour cela, ajout de l'occurrence "A" pour le paramètre EDTSAFOU permettant d'envoyer le bon de commande sur une destination non définie par Qualiac^®.

   Cette nouvelle destination doit être précisée dans le texte de cette occurrence et doit commencer par $$DST. A cette destination, sont ajoutés la classe, le numéro, le sous-numéro, l'établissement et le numéro interne de la commande et le $$FINDST qui marque la fin de la chaîne destination.

   Attention : la gestion de cette nouvelle destination dans le gtusend doit être gérée par le client.

   2) Jusqu'à présent, les courriels contenant les bons de commande avait comme expéditeur l'adresse électronique contenue dans la globale MAIL_FROM.
Il est dorénavant possible de choisir l'adresse électronique de l'expéditeur et de systématiser une demande d'accusé de réception, qui sera reçue par l'expéditeur du mail portant le bon de commande.

   Pour cela, ajout de l'occurrence MAIL_FROM du paramètre EDTBCDEA.
Si la valeur testée 1 vaut :
- N : l'adresse de l'expéditeur du bon de commande correspond à l'adresse électronique contenue dans la globale MAIL_FROM ;
- O : l'adresse de l'expéditeur du bon commande correspond à l'adresse électronique du gestionnaire de l'utilisateur créateur de la commande.

   Si la valeur testée 2 vaut :
- N : pas d'accusé de réception ;
- O : un accusé de réception est reçu par l'expéditeur du bon de commande dès que l'email a été reçu par le fournisseur ceci, à condition que la boîte mail du fournisseur ne bloque pas les accusés.

   3) Pour cela, ajout du paramètre PR9 au traitement. Si sa valeur vaut :
- O : la ligne de révision est regroupée avec la ligne de commande ;
- N : la ligne de révision n'est pas regroupée avec la ligne de commande.

   Principe de regroupement :
- la taxe de la ligne de commande et de sa ligne de révision doit être identique ;
- l'unité de prix de la ligne de commande révisée doit être égale à 1 ou non renseignée ;
- il ne doit pas y avoir de remise sur la ligne de commande révisée c'est-à-dire que le prix tarif HT doit être égal au prix commandé HT.

   Si une des lignes révisées ne peut pas être regroupée, pas d'édition du bon de commande et une erreur associée au travail, via le compte rendu des anomalies (mnémonique GTCJCRA), est générée.

   Pas de différence de fonctionnement entre la révision globale ou détaillée.

   Edition des lignes révisées :
- pas d'édition des lignes de révisions (type des lignes égal à A ou R), elles sont incluses à la ligne de commande ;
- ajout, au prix de la ligne de commande, du prix de la révision à partir de la table des historiques des révisions de lignes ;
- édition uniquement des informations de la ligne commandée tel que compte, poste et CGR.

   Edition des lignes non révisées : pas de changement par rapport au fonctionnement actuel, ces lignes ne doivent pas avoir le type égal à A ou R.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   1) Dans le cas où l'engagement (TVCCE) est réalisé à la suite de l'acceptation du dernier signataire et que l'engagement ne peut pas s'effectuer faute de budget, il est désormais possible d'autoriser le déblocage budgétaire lors de l'acceptation d'une commande.
Pour cela, il est nécessaire de définir des personnes ayant le droit de déblocage budgétaire (GUSMA). Ces personnes ne sont pas forcément les signataires usuels des commandes à signer, mais lors de l'acceptation de la commande, si celle-ci ne peut pas être engagée, le dernier utilisateur qui accepte, peut alors transférer ou ajouter un signataire qui lui, a le droit de déblocage budgétaire.
Ce nouveau signataire peut accepter la commande en donnant son accord de déblocage budgétaire : l'engagement (TVCCE) est alors effectué en forçant le contrôle budgétaire.
Pour que cela fonctionne, il est nécessaire d'indiquer, au niveau du type de ventilation (GTVCA) utilisé pour l'engagement, la règle de signature (GRSMA) à prendre en compte pour la recherche de l'accord de déblocage parmi les détails de signatures de la commande traitée.

   Ce droit de déblocage ainsi que l'accord de déblocage par défaut (GUSMA) peuvent également être consentis à un ou plusieurs signataires usuels des commandes. Ces informations sont alors affectées lors de la pose des différents signataires :
         - affectation des signataires (TASMCA) ;
         - affectation des signataires hors étape (TASSEA) ;
         - saisie manuelle dans la gestion des détails des signatures (GDSMCA) ;
         - affectation des délégations (TAGSM) ;
         - ajout d'un signataire (AJ) ou transfert à un signataire (TR) lors de la signature (GSMCA/GKSMCA).
Il est également possible, à un signataire possédant le droit de déblocage, de déléguer ce droit lors de la délégation (GGSMA).

   Lors de l'acceptation du signataire, si celui-ci a le droit de déblocage, il peut ainsi donner son accord (soit il est affecté par défaut, soit il coche la case « Accord de déblocage budgétaire). Cet accord de déblocage est pris en compte lors de l'engagement uniquement s'il intervient pour le dernier signataire qui accepte : la commande passe alors l'étape de signature et l'engagement (TVCCE) est effectué.

   Remarque : si le droit de déblocage budgétaire est donné (ou supprimé) pour un ou plusieurs signataires, alors que des commandes sont en cours de signatures pour ces personnes, il est nécessaire de relancer le traitement d'affectation des signataires hors étape (TASSEA) afin que ce nouveau droit soit pris en compte pour les éléments en cours de validation.
De même, si une délégation est donnée avec droit de déblocage budgétaire (GGSMA) pour un ou plusieurs signataires, alors que des commandes sont en cours de validation, il est nécessaire de relancer le traitement d'affectation des délégations (TAGSM) afin que le droit de déblocage soit pris en compte pour les éléments en cours de validation.

   Cette nouvelle fonctionnalité implique le paramétrage suivant :
- la validation de la commande (GSMCA/GKSMCA) précède la génération de l'écriture d'engagement (TVCCE) ;
- le contrôle budgétaire est paramétré comme bloquant ;
- l'étape suivant immédiatement la validation (GSMCA/GKSMCA) est la génération de l'écriture d'engagement (TVCCE) et elle est définie en interactif dans les étapes par classe (GETCA) ;
- le lancement des traitements suivants est actif pour l'action "AC" pour la règle de signature concernée (GASMA) ;
- la chaîne 2 du paramètre AUTGTI occurrence CTLEDE ne doit pas être renseignée de manière à ne pas pouvoir passer l'étape de signature si une erreur intervient au moment de l'engagement (TVCCE).

   2) Ajout de la possibilité de définir un nombre maximum d'éléments à signer lors de la recherche des éléments à signer.

   Pour cela, ajout, au niveau des règles de signatures (GRSMA), de l'information "Nombre maximum d'éléments à signer". Ce nombre permet de déterminer le nombre maximum d'éléments qui seront ramenés lors de la recherche pour le mnémonique de signature défini au niveau de la règle de signature.

   NB : cette information doit être identique pour un même mnémonique de signature quel que soit l'établissement.

   3) Ajout de la possibilité de valider différemment un niveau selon son type dans le cas où plusieurs signataires sont définis au même niveau.

   Jusqu'à présent, dans le cas où plusieurs signataires sont définis pour un même niveau, au niveau du paramétrage de la règle de signature (GRSMA), il est possible d'indiquer si tous les signataires doivent signer (T) ou si un seul signataire doit signer (U). Désormais, il est également possible d'indiquer que le choix de tous les signataires ou d'un seul s'effectue selon le type de niveau (N).

   Dans le cas où le type de niveau est géré, c'est la valeur testée 1 des occurrences "type de niveau" du paramètre TNISAMSM qui indique comment doit être validé le niveau.
Si la valeur testée 1 est égale à :
- T ou non renseignée : tous les signataires du niveau de ce type doivent signer ;
- U : un seul signataire du niveau de ce type doit signer.
Dans le cas où le type de niveau n'est pas géré (non renseigné), c'est la valeur testée 1 de l'occurrence "N" du paramètre PSMSARSM (Action si plusieurs signataires au même niveau) qui indique comment doit être validé le niveau dont le type n'est pas renseigné.
Si la valeur testée 1 est égale à :
- T ou non renseignée : tous les signataires du niveau pour lequel le type de niveau n'est pas renseigné doivent signer ;
- U : un seul signataire du niveau dont le type de niveau n'est pas renseigné doit signer.

   Exemple :

   Pour une facture, les signataires sont positionnés tels que :
- U1 au niveau 10, type de niveau VF ;
- U2 au niveau 10, type de niveau VF ;
- U3 au niveau 10, type de niveau VD ;
- U4 au niveau 10, type de niveau VD ;
- U5 au niveau 10, type de niveau "non renseigné" ;
- U6 au niveau 10, type de niveau "non renseigné".

   La valeur testée 1 de l'occurrence VF du paramètre TNISAMSM est égale à "U" (un seul signataire doit signer pour le type de niveau).
La valeur testée 1 de l'occurrence VD du paramètre TNISAMSM est égale à "T" (tous les signataires doivent signer pour le type de niveau).
La valeur testée 1 de l'occurrence N du paramètre PSMSARSM est égale à "U" (un seul signataire doit signer pour le type de niveau "non renseigné").

   Si U1 signe, alors le niveau 10 de type VF est validé : U2 n'est pas requis.
Si U3 signe alors U4 doit aussi signer car tous les signataires ayant le type de niveau VD doivent signer.
Si U5 signe alors le type de niveau "non renseigné" est validé : U6 n'est pas requis.

   4) Lors de la signature (GSMDA/KGSMDA, GSMCA/GKSMDA, GSMRA/GKSMRA, GSMFA/GKSMFA, GSMMA/GKSMMA), possibilité de relancer automatiquement la recherche des éléments à signer après avoir validé un ou plusieurs éléments.

   Pour cela, ajout du paramètre PR1 au mnémonique de signature.
Si la valeur du paramètre vaut :
- O : la recherche des éléments à signer est relancée après la validation des éléments signés ;
- N : la recherche des éléments à signer n'est pas relancée après la validation des éléments signés.

   6) Signature des factures (GSMFA/GKSMFA) : sur les actions "Refuser pour resoumettre" (RR) et "Refuser pour détacher" (RD), possibilité d'annuler plusieurs étapes de signatures consécutives.

   Lors de l'action "Refuser pour resoumettre" ou "Refuser pour détacher", si le flux d'étapes possède plusieurs étapes de signatures avant comptabilisation (TVCC), il est possible de retourner à l'étape de facturation. Dans ce cas, l'étape de retour, renseignée au niveau de l'action de signature (GASMA), doit être égale à l'étape de facturation (GFAA) ou à une étape dédiée située juste après l'étape de facturation.
De plus, dans le cas de l'action "Refuser pour resoumettre", il est quand même possible de retourner à une étape juste avant l'étape d'affectation des signataires (TASMFA) correspondant à la signature en cours.

   Il est possible de retourner à l'étape de facture si pour la facture :
- aucune commande n'a généré de solde de facturation (TSOLF) ;
- la facture n'a pas été transférée en comptabilité (TVCC) ;
- aucune récupération d'avance n'a été générée (TRAA).

   Si une des conditions ci-dessus n'est pas respectée, alors l'étape de retour devra se situer juste avant l'étape du traitement d'affectation des signataires (TASMFA) correspondant à la signature en cours.
Rappel : si une des conditions ci-dessus n'est pas respectée, l'action "Refuser pour détacher" n'est pas possible.

   Exemples :
a) Cas où la signature est effectuée avant la comptabilisation des factures (TVCC) :
- 700 : Facture (GFAA) ;
- 701 : Refus 1 de la signature ;
- 705 : Affectation des signataires de la facture 1 (TASMFA1) ;
- 706 : Signature de la facture 1 (GSMFA1) ;
- 715 : Affectation des signataires de la facture 2 (TASMFA2) ;
- 716 : Signature de la facture 2 (GSMFA2) ;
- 720 : Comptabilisation des factures (TVCC).

   Pour la seconde signature facture (GSMFA2), l'étape de refus peut se situer :
- juste après l'étape de facturation (ou être égale à celle-ci) (700 ou 701);
- juste avant l'étape d'affectation des signataires facture 2 (715).

   b) Cas où la signature est effectuée après la comptabilisation des factures (TVCC) :
- 700 : Facture (GFAA) ;
- 701 : Refus 1 de la signature ;
- 705 : Affectation des signataires de la facture 1 (TASMFA1) ;
- 706 : Signature de la facture 1 (GSMFA1) ;
- 710 : Comptabilisation des factures (TVCC) ;
- 711 : Refus 2 de la signature ;
- 715 : Affectation des signataires de la facture 2 (TASMFA2) ;
- 716 : Signature de la facture 2 (GSMFA2).

   Pour la seconde signature (GSMFA2), l'étape de refus doit se situer juste avant l'étape d'affectation des signataires facture 2 (TASMFA2), ici 711.

   c) Cas où 3 signatures sont effectuées avant le traitement de solde des commandes après facture (TSOLF) :
- 700 : Facture (GFAA) ;
- 701 : Refus 1 de la signature ;
- 705 : Affectation des signataires de la facture 1 (TASMFA1) ;
- 706 : Signature de la facture 1 (GSMFA1) ;
- 711 : Refus 2 de la signature ;
- 715 : Affectation des signataires de la facture 2 (TASMFA2) ;
- 716 : Signature de la facture 2 (GSMFA2) ;
- 720 : Solde des commandes d'achats après facture (TSOLF) ;
- 721 : Refus 3 de la signature ;
- 725 : Affectation des signataires de la facture 3 (TASMFA3) ;
- 726 : Signature de la facture 3 (GSMFA3).

   Lors du "Refus pour resoumettre" pour la signature facture 3 (GSMFA3) :
- il n'est pas possible de retourner à l'étape du "Refus 1 de la signature" (701) si une des commandes de la facture a générée un solde de facturation (TSOLF) ;
- il n'est pas possible de retourner à l'étape du "Refus 2 de la signature" (711) dans tous les cas ;
- il est possible de retourner à l'étape du "Refus 3 de la signature" dans tous les cas.

   7) Ajout de la possibilité d'affecter une action pour plusieurs éléments à signer simultanément.

   Pour cela :
- ajout de la case à cocher "Sélection" permettant de sélectionner plusieurs éléments à signer ;
- possibilité d'affecter une action sur les éléments à signer sélectionnés soit à partir d'une liste de valeurs, soit à partir d'un bouton (un bouton par action possible).

   Selon le fonctionnement choisi, il est possible d'ajouter les champs nécessaires via personnalisation :
- case à cocher "Sélection" : champ "WCHECKELT" ;
- liste de valeurs avec toutes les actions possibles : champ combo "WACTIONLIBGEN" ou un champ bouton "BUTTON_ACTION_XX" où XX représente l'action à réaliser.

   Liste des boutons d'actions disponibles pour tous les mnémoniques de signatures (GSMDA/GKSMDA, GSMCA/GKSMCA, GSMRA/GKSMRA, GSMFA/GKSMFA, GSMMA/GKSMMA) :
- BUTTON_ACTION_AC : "Accepter" ;
- BUTTON_ACTION_AJ : "Ajouter signataire et accepter" ;
- BUTTON_ACTION_AV: "Donner son avis" ;
- BUTTON_ACTION_DA : "Demander un avis" ;
- BUTTON_ACTION_EM : "Mettre en attente"
- BUTTON_ACTION_JS : "Ajouter un signataire"
- BUTTON_ACTION_RP : "Retour au niveau précédent" ;
- BUTTON_ACTION_RR : "Refuser pour resoumettre" ;
- BUTTON_ACTION_TR : "Transférer à un autre signataire".

   Liste des boutons d'actions disponibles en plus pour les mnémoniques de signatures de demandes d'achats ou de commandes d'achats (GSMDA/GKSMDA, GSMCA/GKSMCA) :
- BUTTON_ACTION_RA : "Refuser pour annulation".

   Liste des boutons d'actions disponibles en plus pour les mnémoniques de signatures de factures (GSMFA/GKSMFA) :
- BUTTON_ACTION_EL : "Mettre en litige" ;
- BUTTON_ACTION_LT : "Litige et trf. signataire" ;
- BUTTON_ACTION_RD : "Refuser pour détacher".

   L'action choisie (soit par la liste de valeurs, soit par bouton), est affectée ensuite à tous les éléments à signer et la validation peut se faire de manière générale à partir du bouton "TOUT SOUMETTRE" ou élément par élément à partir du bouton "SOUMETTRE".

   8) Tâches collaboratives : génération d'une tâche par utilisateur pour les éléments à signer.

   Auparavant, si plusieurs signataires devaient signer un élément, au même moment, une seule tâche collaborative (GNTAC) était générée pour les signataires.
Désormais, dans ce cas, une tâche est générée pour chacun des signataires.

GUSMA - Droits utilisateurs des signatures multicritères (Transaction SAIUSM)
GGSMA - Délégations des signatures multicritères (Transaction SAIGSM)
GRSMA - Règles des signatures multicritères (Transaction SAIRSM)
GDSMCA - Détail des signatures multicritères des commandes (Transaction SAIDSMC)
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)
CDSMA - Consultation des signatures multicritères (Transaction SACDSM)
GTVCA - Paramétrage transfert comptabilité achat (Transaction SAITVC)
TVCCE - Engagement (Transaction SATVCCE)

   Ajout de la possibilité de faire une clôture partielle du BL, en fin de mois.

   Pour cela, ajout du paramètre PRM associé au traitement de clôture. Si la valeur vaut :
- T : la clôture est totale ;
- P : la clôture est partielle.

   Selon si la clôture est partielle ou totale (valeur du PRM), toutes les règles définies dans la gestion des écarts de quantités en réception (GEQRA) ne s'appliquent pas. Cela dépend du type (typsaeqr) de la règle.
Si le type vaut :
- D : la règle s'applique que la clôture soit totale ou partielle ;
- T ou non renseigné : la règle s'applique si la clôture est totale ;
- P : la règle s'applique si la clôture est partielle.

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

   NB : Aucun traitement (GTRB) n'a été livré, en standard, avec la valeur du paramètre PRM positionnée à "P". Pour faire de la clôture partielle, il est donc nécessaire d'en créer un en le dupliquant à partir du traitement associé au mnémonique TCBLA.

TCBLA - Clôture du BL (Transaction SATCBL)

   Ajout de la possibilité d'effectuer un "retour" à une certaine étape pour une réception c'est à dire de ramener les commandes de la réception à une étape donnée ceci, afin de pouvoir effectuer certaines modifications sur les lignes de la réception.

   Pour cela, il est nécessaire, via personnalisation de GREC/GKREC, d'ajouter le bouton "RETOUR".

   Le paramètre AUTSAREC occurrence RET-XXXX où XXXX représente la classe d'achats donne :
- l'étape à laquelle les commandes de la réception sont retournées (valeur 1). Cette étape doit être définie dans les étapes par classe (GETCA). Elle doit être supérieure ou égale à l'étape de réception (GREC) ;
- l'étape jusqu'à laquelle il est possible d'effectuer un retour (valeur 2).

   Pour que le retour puisse s'effectuer, il est nécessaire que les commandes de la réception respectent un certain nombre de conditions :
- aucune ligne de la réception n'a généré de sous-commande solde réception (TSOLA) ;
- aucune ligne de la réception n'a généré de retour (GRET) ;
- la mise à jour des stocks n'a pas été effectuée (TSTA) ;
- la mise à jour des marchés après réception (TMARAR) n'a pas été effectuée ;
- la mise à jour en statistique n'a pas été effectuée (TSTTRA) ;
- les fiches d'immobilisations n'ont pas été traitées (TIMOR) ;
- il ne doit pas exister d'acompte transféré en comptabilité pour une commande de la réception (pas d'enregistrement dans GAAIA avec l'état égal à "T" pour l'événement égal à « Réception ») ;
- aucune commande de la réception ne doit avoir généré de facture non parvenue (TVCCP) ;
- aucune commande de la réception ne doit être associée à une facture.

   Si le retour est possible, les actions suivantes sont réalisées :
- si le traitement de calcul de pénalités liées au marché (TPENA) a été réalisé, l'historique de pénalités (CHPNA) est supprimé et les lignes de pénalités sont supprimées ;
- si le traitement de calcul des révisions liées au marché après réception (TREVA) a été réalisé, l'historique de révisions (CHREA) est supprimé et les lignes de révisions créées à la réception sont supprimées ;
- si une signature (GSGCA) a été effectuée entre l'étape à laquelle on retourne et l'étape à laquelle se situe les commandes de la réception avant d'être retournées, les commandes ne sont plus signées ;
- si une ou plusieurs signatures multicritères (GSMRA) ont été effectuées entre l'étape à laquelle on retourne et l'étape à laquelle se situe les commandes de la réception avant d'être retournées, les détails de signatures (GDSMRA) correspondant sont supprimés ou annulés selon le paramétrage (valeur testée 1 du paramètre AUTACHAT occurrence SUPSIG) ;
- l'étape des commandes de la réception est mise à jour et si, dans les étapes par classe (GETCA), l'étape à laquelle on retourne est active sur la mémorisation, un enregistrement est créé dans l'historique (CHECA).

GREC - Contrôle des réceptions (Transaction SAIREC)
GKREC - Contrôle des réceptions (Transaction SAIREC)
GRECR - Contrôle des réceptions (Transaction SAIRECR)

   1) Dans le cas d'écart d'arrondi entre les montants de la fiche d'immobilisation (montant HT, montant condition de facturation et montant prorata de TVA) et les montants comptabilisés, il est possible d'effectuer un équilibrage du montant immobilisé.

   2) Calcul du montant prorata pour les codes de TVA à la fois intra-communautaire et soumis au prorata.

   1) Cette possibilité est donnée par la valeur testée 1 du paramètre AUTSAIMO occurrence CTLEQL.
Si la valeur testée 1 vaut :
- N : l'équilibrage n'est pas effectué ;
- O : l'équilibrage est effectué.

TIMOR - MAJ immobilisations provisoires après réception (Transaction SATIMOR)
TIMO - MAJ des immobilisations provisoires après facture (Transaction SATIMO)

   Cette possibilité est donnée par la valeur testée 1 du paramètre AUTM9 occurrence RETENG. Si elle est égale à :
- N : le retrait d'engagement n'est pas effectué lors des différents traitements d'annulation de commandes ;
- O : le retrait d'engagement est effectué lors des différents traitements d'annulation de commandes.

   Si la valeur testée 1 vaut "O" :

   1) 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 est ré-engagée en comptabilité, en date logique, sur un nouveau journal et un nouveau type d'écriture. Ces deux informations sont données respectivement par le texte et la chaîne 2 du paramètre AUTM9 occurrence RETENG. Cette écriture permet d'avoir un engagement mais sans impact sur les budgets.

   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) ou si le type d'écriture de l'engagement correspond au type d'écriture du retrait d'engagement donné par la chaîne 2 du paramètre AUTM9 occurrence RETENG : l'écriture d'engagement de la commande est annulée en comptabilité mais sur un nouveau journal et un nouveau type d'écriture. Ils sont donnés respectivement par le texte et la chaîne 1 du paramètre AUTM9 occurrence RETENG.

TACRA - Annulation d'une commande réceptionnée (Transaction SATACR)
TSRD - Annulation de demandes d'achats ou de commandes (Transaction SATSRD)

   1) La quantité réceptionnée est alors égale à la quantité facturée et le prix réceptionné est égal au prix facturé.

   La case à cocher "Partiel" permet d'indiquer si l'on souhaite effectuer une facturation (réception) partielle et ainsi, d'affecter la quantité solde adéquate. En effet, dans ce cas, c'est la quantité solde réception qui est affectée égale à la quantité facturée et non pas la quantité solde facture. Le montant réceptionné et le montant facturé sont égaux aussi, le solde qui doit être généré correspond à la différence entre le montant commandé et le montant réceptionné, c'est une sous-commande solde réception qui doit être générée en attente de réception. Il est donc nécessaire, d'avoir dans le flux des étapes (GETCA), un traitement de solde des commandes d'achats après réception (TSOLAF par exemple), juste après l'étape du contrôle facture (GFAA).
Ce traitement (TSOLAF) doit être paramétré de manière à effectuer les mêmes contrôles de cohérence sur la facture que le traitement de comptabilisation (TVCC), à savoir les contrôles des montants HT et/ou TTC et éventuellement le réajustement des écarts. Pour cela, la valeur testée 1 de l'occurrence xCTLRFAA du paramètre AUTSASOL doit être égale à "O" (x représente la valeur du PR1 associé au traitement). La chaîne 1 de cette même occurrence permet de définir le type de ventilation (GTVCA) à prendre en compte pour effectuer les contrôles.

   NB : le traitement "TSOLAF" n'est pas livré en standard. Il doit être dupliqué à partir du traitement "TSOLA".

   4) Pour l'adresse du tiers, cette possibilité est donnée par le paramètre AUTSAFAA occurrence MAJADR.
Si la valeur testée 1 est égale à :
- R : l'adresse n'est pas re-proposée ;
- N : l'adresse est vidée : l'utilisateur devra la renseigner ;
- P : l'adresse est re-proposée égale à l'adresse définie pour le tiers associé à l'établissement (GATE). L'adresse est recherchée pour le type de collectif donné par la chaîne 1 si elle est renseignée, sinon elle est recherchée pour le premier type de collectif fournisseur trouvé.

   La valeur testée 1 de cette occurrence est initialisée à "R" par la release.

   Pour la domiciliation des échéances (GCAE), cette possibilité est donnée par le paramètre AUTSAFAA occurrence MAJDOM.
Si la valeur testée 1 est égale à :
- R : la domiciliation n'est pas re-proposée ;
- N : la domiciliation est vidée : l'utilisateur devra la renseigner ;
- A : la domiciliation est re-proposée égale à celle définie pour l'adresse du tiers (GTIA) ;
- T : la domiciliation est re-proposée égale à celle définie pour le tiers associé à l'établissement (GATE). La domiciliation est recherchée pour le type de collectif donné par la chaîne 1 si elle est renseignée, sinon elle est recherchée pour le premier collectif fournisseur trouvé ;
- P : la domiciliation est re-proposée égale à la domiciliation principale du tiers (GTID). La domiciliation principale est celle pour laquelle la destination est égale à "P".

   En fonction de la valeur testée 2 de cette même occurrence, il est possible d'alerter l'utilisateur d'un changement de la valeur de la domiciliation.
Si la valeur testée 2 est égale à :
- O : un message avertit l'utilisateur que la domiciliation a été modifiée ou mise à blanc ;
- N : aucun message d'alerte avertit l'utilisateur.

   La valeur testée 1 de cette occurrence est initialisée à "R" et la valeur testée 2 à "N" par la release.

SAIFLC - Lignes à facturer (Transaction SAIFLC)
SAILCF - Lignes de facture (Transaction SAILCF)
TGFAA - Génération automatique de factures (Transaction SATGFAA)
TGFAE - Génération automatique de factures (étape) (Transaction SATGFAE)
TTFCA - Intégration des factures d'achats (Transaction SATTFC)
TDFAA - Duplication de factures (Transaction SATDFA)
TSOLA - Solde des commandes d'achats après réception (Transaction SATSOLA)

   Le traitement "TSOLAF" n'est pas livré en standard. Il doit être dupliqué à partir du traitement "TSOLA" et mis en place dans les étapes (GETPA) et dans les étapes par classes (GETCA) comme suit :
- mnémonique d'appel : TSOLAF ;
- traitement associé : SATSOLAF ;
- traitement par commande : pssasolaetp ;
- traitement par entité : pssasolaetp ;
- mnémonique des critères : SATSOLA.

   Ce traitement doit être situé à une étape juste après le contrôle facture (GFAA).

   Afin que les lignes négatives et les lignes positives générées n'aient pas d'influence en immobilisation, elles sont créées sans les informations immobilisations (les informations type de transfert, type d'immobilisation, ... ne sont pas renseignées).

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)

   Ajout de la possibilité d'effectuer le contrôle de tolérance en HT ou en TTC.

   Cette possibilité est donnée par la valeur testée 1 du paramètre AUTSAAEF occurrence CTLMNT.
Si la valeur testée 1 est égale à :
- H : le contrôle de tolérance est effectué en HT : contrôle que la somme des montants facturés HT 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 ;
- T : le contrôle de tolérance est effectué en TTC : contrôle que la somme des montants facturés TTC 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 TTC total de la facture.

   Le même principe est appliqué pour le contrôle de tolérance pour l'ajustement d'engagement après réception (TCTRA).

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

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)

   Si une ligne pour laquelle une fiche d'immobilisation a été créée à la réception est facturée partiellement, création d'une fiche d'immobilisation sur la ligne solde générée lors du traitement de solde après facture (TSOLF). La fiche d'immobilisation est créée avec un code traitement égal à "RC".

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

   Ajout de la possibilité d'indiquer si la commande d'ajustement est créée avec les informations taxes de l'en-tête de la commande origine ou avec les informations taxes de l'en-tête de la facture origine.

   Cette possibilité est donnée par le paramètre AUTSAAEF occurrence PROTVA.
Si la valeur testée 1 est égale à :
- C : la commande d'ajustement est créée avec les informations taxes de l'en-tête de la commande origine ;
- F : la commande d'ajustement est créée avec les informations taxes de l'en-tête de la facture origine.

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

TAEFA - Ajustement d'engagement après facture (Transaction SATAEF)

   1) Ajout de la possibilité d'affecter la date comptable et/ou la date d'émission des écritures générées avec la date de signature.

   2) Ajout de la possibilité de prendre en compte la date de clôture des achats pour l'affectation de la date comptable de l'écriture générée.

   3) Calcul du prorata pour les codes de TVA à la fois intra-communautaire et soumis au prorata.

   1) Dans le cas où la comptabilisation est réalisée suite à l'acceptation du dernier signataire, il est possible d'effectuer la comptabilisation (TVCCx) en date de signature. Pour cela, il est nécessaire de positionner la valeur "DS" pour la proposition de la date comptable et/ou la proposition de la date d'émission dans la transaction de paramétrage du transfert en comptabilité (GTVCA). Il faut également préciser, dans cette même transaction, la règle de signature (GRSMA) à prendre en compte pour la recherche de la date de signature parmi les détails de signatures de l'élément traité (demande d'achats, commande, réception, facture).

   2) Cette possibilité est donnée, au niveau du type de ventilation (GTVCA), par la case à cocher "Prise en compte de la clôture des achats" pour l'affectation de la date comptable de l'écriture.

   Si cette case est cochée et si la date comptable donnée par le paramétrage est inférieure à la date de dernière clôture des achats pour la classe, la date comptable de l'écriture est égale à la date de dernière clôture des achats plus un jour.
Dans le cas de la comptabilisation d'une facture avec plusieurs commandes de classes d'achats différentes, est prise en compte, la plus grande des dates de dernière clôture des différentes classes d'achats.

   Si cette case n'est pas cochée, la date comptable de l'écriture est celle donnée par le paramétrage quelle que soit sa valeur.

   3) Désormais, dans ce cas (tva intra-communautaire et soumis au prorata), un mouvement est créé sur un compte de TVA dédié, pour la partie non récupérable, en sens inverse du montant HT traité. Le compte de TVA dédié est donné par la chaîne 1 du paramètre AUTCPT occurrence CPTATT.

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)

   1) Possibilité d'enchaîner les traitements suivants si la signature n'est pas nécessaire

   2) Ajout du plan de contrôle dans le compte-rendu du traitement d'affectation des signataires en fonction du plan de contrôle

   1) Il est désormais possible d'enchaîner les traitements suivants lorsque la signature d'une facture n'est pas nécessaire lors de l'affectation des signataires en fonction du plan de contrôle (TASPCA).
Cette possibilité est donnée par le même paramétrage que celui permettant d'enchaîner les traitements lors de la signature (GSMFA) : au niveau des actions des signatures multicritères (GASMA), pour la règle de signature concernée, la case à cocher "Lancement des traitements suivants" doit être cochée pour l'action "AC" (Accepter).

GRSMA - Règles des signatures multicritères (Transaction SATASPC)
TASPCA - Affect. des signataires en fonct. du plan de ctrl. (Transaction SATASPC)

   Ajout d'un contrôle permettant de délivrer ou de refuser le bon à payer selon l'écart en pourcentage entre la somme des montants facturés et la somme des montants réceptionnés et commandés de chacune des sous-commandes de la facture.

   Le contrôle est effectué selon la valeur testée 1 de l'occurrence CTLMTPxxxx du paramètre AUTSATAC où xxxx représente la classe de commandes d'achats.
Ce contrôle est effectué pour chaque sous-commande de la facture.
Le bon à payer ne peut pas être délivré si :
- la somme des montants facturés est supérieure à la somme des montants réceptionnés avec un pourcentage de tolérance donné par la valeur 1 de l'occurrence CTLMTPxxxxx du paramètre AUTSATAC ;
- la somme des montants facturés est supérieure à la somme des montants commandés avec un pourcentage de tolérance donné par la valeur 1 de l'occurrence CTLMTPxxxxx du paramètre AUTSATAC ;
- la somme des montants facturés est inférieure à la somme des montants réceptionnés avec un pourcentage de tolérance donné par la valeur 2 de l'occurrence CTLMTPxxxxx du paramètre AUTSATAC ;
- la somme des montants facturés est inférieure à la somme des montants commandés avec un pourcentage de tolérance donné par la valeur 2 de l'occurrence CTLMTPxxxxx du paramètre AUTSATAC.

   Dans le cas d'une réception en montant, le montant réceptionné d'une ligne de facture est égal à la quantité facturée multipliée par le prix réceptionné et par l'unité de prix.
Dans le cas d'une réception en quantité, le montant réceptionné d'une ligne de facture est égal à la quantité facturée (sans les gratuits) multipliée par le prix commandé et par l'unité de prix.
Le montant commandé d'une ligne de facture est égal à la quantité facturée (sans les gratuits) multipliée par le prix commandé et par l'unité de prix.

   Si le contrôle est bloquant, le bon à payer n'est pas délivré et le code rejet de la facture est mis à jour avec la valeur "V".

TTAC - Bon à payer (Transaction SATTAC)

   Le champ établissement n'est pas accessible dans la gestion.

GARURAF - Rubriques par articles/fournisseurs (Transaction SAIARRAF)

   Suppression d'un message intempestif lors de la suppression d'un enregistrement si la domiciliation est supérieure à 2 caractères.

GTCDA - Commandes d'interface (Transaction SAITCD)

   Correction de l'arrondi sur les numériques lors d'une modification générale.

GMFOU - Modification des fournisseurs (Transaction SAMFOU)
GMATA - Modification des articles achetés (Transaction SAMATA)
GMMARA - Modification des marchés (Transaction SAMMAR)
GMRAF - Modification des références articles/fournisseurs (Transaction SAMRAF)
GMCDA - Modification des commandes (Transaction SAMCDA)
GMLCA - Modification des lignes de commandes (Transaction SAMLCA)
GMCAE - Modification des échéances (Transaction SAMCAE
GMCAF - Modification des conditions de facturation (Transaction SAMCAF)

   Correction de la proposition du CGR des lignes de marchés dans le cas où l'entité "OEGES" (Gestionnaire) est définie dans la proposition de la clé analytique (GPCLC).

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

   Correction de l'affectation de la destination (le mode de transport était copié dans la destination quand cette dernière n'était pas renseignée).

TGAMA - Génération des appels d'achats pour un marché (Transaction SATGAM)

   Correction afin d'afficher le message signalé ou bloquant de rupture de stock "Réservée > Stock pour Dépôt : $1 - Article $2 - Lot: $3 ($4)" (SKSTL058), lors d'une livraison de demandes de services (GRDA), si la quantité du détail par lot et/ou emplacement est modifiée.

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

   Cette correction permet de bloquer le passage d'étape lors de l'insertion manuelle d'un signataire au statut "AS" (auto-signature) dans le cas où l'élément à signer n'a pas passé le traitement d'affectation des signataires (TASMDA, TASMCA, TASMRA, TASMFA, TASMMA).

GDSMDA - Détail des signatures multicritères des DA (Transaction SAIDSMD)
GDSMCA - Détail des signatures multicritères des commandes (Transaction SAIDSMC)
GDSMRA - Détail des signatures multicritères des réceptions (Transaction SAIDSMR)
GDSMFA - Détail des signatures multicritères des factures (Transaction SAIDSMF)
GDSMMA - Détail des signatures multicritères des marchés (Transaction SAIDSMM)

   Lors du traitement d'affectation des délégués (TAGSM), si les tâches collaboratives sont paramétrées via l'action "AC" (GASMA) de la règle de signature, elles sont désormais envoyées uniquement aux délégués créés par le traitement.

TAGSM - Affectation délégations signatures multicritères (Transaction SATAGSM)

   1) Dans le cas où la fourchette de CGR B était renseignée dans la forme sélection des lignes de commandes (CSLCA), elle n'était pas prise en compte sur le bouton "Cumul sélection".

   2) Correction pour ne plus afficher le masque de recherche "Analytique" si le paramètre CGR lié au mnémonique est égal à "N".

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

   Prise en compte des factures possédant une étape de signature avant celle du contrôle hiérarchisé de la dépense (CHD) lors du traitement d'affectation des signataires en fonction du plan de contrôle (TASPCA).

TASPCA - Affect. des signataires en fonct. du plan de ctrl. (Transaction SATASPC)

   Lors d'une demande d'avis, il arrivait que les actions réalisées par d'autres signataires, au même niveau, soient effacées et du coup, que ces derniers soient obligés de re-signer. Ce problème a été corrigé.

   Correction lors d'un retour à un niveau précédent afin que les délégations soient réaffectées correctement pour l'élément traité.

   Correction lors du traitement de délégation (TAGSM) pour ne pas perdre le statut "Non requis" (NR) dans certains cas.

GSMCA - Signatures multicritères des commandes d'achats (Transaction SAISMC)
TAGSM - Affectation délégations signatures multicritères (Transaction SATAGSM)

   Correction de l'affectation des informations concernant le tiers de livraison dans l'en-tête du bon de commande dans le cas où :
- l'édition est lancée par liste ;
- il existe une commande comprenant des sous-commandes avec des dépôts différents à l'en-tête.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   Liste des indicateurs existants disponible via ce lien.

   Ajout de la possibilité de mettre la date système pour le champ "date de réception facture".

   Pour cela, il faut positionner la chaine 1 du paramètre AUTSAFAR occurrence DRFSATFC à "S" et la valeur testée 1 à "O".

   Dans ce cas :
- si le texte contient une balise et que celle-ci est présente et renseignée dans le fichier à intégrer, la valeur de la balise est prise en compte lors de l'insertion dans l'interface ;
- si le texte contient une balise et que celle-ci est présente mais non renseignée dans le fichier à intégrer, la date système est prise en compte lors de l'insertion dans l'interface ;
- si le texte ne contient pas de balise, la date système est prise en compte lors de l'insertion dans l'interface.

TFAAR - Extraction des factures achats ReadSoft (Transaction SATFAAR)

   Ajout de la possibilité de mettre la date système pour le champ "date de réception facture".

   Pour cela, il faut positionner la chaine 1 du paramètre AUTSAFAC occurrence DRFSATFC à "S" et la valeur testée 1 à "O".

   Dans ce cas :
- si le texte contient une balise et que celle-ci est présente et renseignée dans le fichier à intégrer, la valeur de la balise est prise en compte lors de l'insertion dans l'interface ;
- si le texte contient une balise et que celle-ci est présente mais non renseignée dans le fichier à intégrer, la date système est prise en compte lors de l'insertion dans l'interface ;
- si le texte ne contient pas de balise, la date système est prise en compte lors de l'insertion dans l'interface.

TFAAC - Extraction des factures achats CEGEDIM (Transaction SATFAAC)

   1) Possibilité de choisir les entités de documents à consulter

   2) Visualisation des textes des éléments à signer

   3) Possibilité d'ajouter des champs personnalisables

   1) Possibilité de choisir les entités de documents à consulter
Le paramètre SASMCGED permet de choisir les entités de documents (GTDEN) visibles dans l'application mobile. Les occurrences représentent les entités de signature :
  - SADAE : demandes d'achats ;
  - SACDA : commandes d'achats ;
  - SAREC : réceptions ;
  - SAFAA : factures ;
  - SAMAR : marchés.
Les entités de documents (GTDEN) doivent être renseignées au niveau du texte de ces occurrences.

   Par exemple, si pour l'occurrence SACDA, la zone texte est renseignée avec "ACHAT COMMANDE,ACHAT LIGNE" alors la recherche des documents à afficher est effectuée pour ces entités de documents.

   Ne peuvent être affichés que les documents pour lesquels l'identifiant est conforme au GTDEN livré en standard :
- ACHAT COMMANDE pour les documents associés à l'en-tête : numéro interne de la demande d'achats ou de la commande ;
- ACHAT LIGNE pour les documents associés aux lignes : numéro interne de la demande d'achats ou de la commande concaténé au numéro de ligne ;
- ACHAT RECEPTION pour les documents associés aux réceptions : établissement de la réception concaténé au numéro de réception ;
- ACHAT FACTURE pour les documents associés aux factures : établissement de la facture concaténé au numéro de facture ;
- ACHAT MARCHE pour les documents associés aux marchés : établissement du marché concaténé au numéro de marché.

   2) Visualisation des textes des éléments à signer
Le paramètre SASMCTXT permet de choisir les destinations de textes à afficher dans l'application mobile. Les occurrences représentent les entités de signature :
  - SADAE : demandes d'achats ;
  - SACDA : commandes d'achats ;
  - SAREC : réceptions ;
  - SAFAA : factures ;
  - SAMAR : marchés.
Les destinations à afficher doivent être renseignées au niveau du texte de ces occurrences. Elles doivent être séparées par une virgule.

   3) Possibilité d'ajouter des champs personnalisables
Le paramètre SASMCFLD permet de choisir les champs supplémentaires à afficher dans l'application. Chaque occurrence représente un champ à afficher.
Occurrences pour les demandes/commandes :
  - DRDSACDA : Date au plus tôt ;
  - DRFSACDA : Date au plus tard ;
  - DECSACDA : Date comptable ;
  - INXSACDA : Interlocuteur externe ;
  - INLSACDA : Interlocuteur logistique.

   Occurrences pour les lignes de demandes d'achats :
  - CPASALCAD : Compte ;
  - POSSALCAD : Poste ;
  - DTRSALCAD : Date prévue ;
  - DERSALCAD : Dépôt.

   Occurrences pour les lignes de commandes :
  - CPASALCAC : Compte ;
  - POSSALCAC : Poste ;
  - DTRSALCAC : Date prévue ;
  - DERSALCAC : Dépôt.

   Occurrences pour les réceptions :
  - RFBSAREC : Référence ;
  - INXSAREC : Interlocuteur externe ;
  - INLSAREC : Interlocuteur interne.

   Occurrences pour les lignes de réceptions :
  - CPASALCAR : Compte ;
  - POSSALCAR : Poste ;
  - DTRSALCAR : Date prévue ;
  - DERSALCAR : Dépôt.

   Occurrences pour les factures :
  - INFSAFAA : Informations ;
  - INXSAFAA : Interlocuteur externe
  - INLSAFAA : Interlocuteur interne.

   Occurrences pour les lignes de factures :
  - CPASALCAF : Compte ;
  - POSSALCAF : Poste ;
  - DTRSALCAF : Date prévue ;
  - DERSALCAF : Dépôt.

   Occurrences pour les marchés :
  - DDCSAMAR : Date de début du contrat ;
  - DRCSAMAR : Durée du contrat ;
  - GESSAMAR : Gestionnaire ;
  - GETSAMAR : Gestionnaire technique ;
  - GECSAMAR : Gestionnaire commercial.

   Occurrences pour les lignes de marchés :
  - CPASAMAD : Compte ;
  - POSSAMAD : Poste ;
  - TTVSAMAD : Taux de TVA.

   La valeur testée 1 de chacune de ces occurrences indique si le champ est affiché ou pas.
Si elle vaut :
- O : le champ est visible dans l'application mobile ;
- N : le champ n'est pas visible dans l'application mobile.

TFAAC - Extraction des factures achats CEGEDIM (Transaction SATFAAC)

   Ajout des colonnes :
DDBSADSM - Droit de déblocage budgétaire (Obligatoire)
ADBSADSM - Accord de déblocage budgétaire (Obligatoire)
SIRSADSM - Utilisateur signataire remplaçant
SISSADSM - Utilisateur signataire supprimé

   Ajout des colonnes :
DDBSAGPS - Délégation du droit de déblocage budgétaire (Obligatoire)

   Ajout des colonnes :
DDBSAGSM - Délégation du droit de déblocage budgétaire (Obligatoire)

   Ajout des colonnes :
CAESANCM - Contrôle selon montant acte d'engagement (Obligatoire)
MPCSANCM - Montant prévu contrôlé
EMPSANCM - Ecart pour contrôle montant prévu
CDNSANCM - Ctrl. date de notification dans période validité (Obligatoire)
SMPSANCM - Seuil montant prévu
SM1SANCM - Seuil montant prévu marché ligne 1
SM2SANCM - Seuil montant prévu marché ligne 2
SL1SANCM - Seuil montant prévu ligne 1
SL2SANCM - Seuil montant prévu ligne 2

   Modification des colonnes :
OJ1SANCM - Proposition objet commande type 1 : libellé revu, "Proposition objet 1" remplacé par "Proposition objet commande type 1"
OJ2SANCM - Proposition objet commande type 2 : libellé revu, "Proposition objet 2" remplacé par "Proposition objet commande type 2"

   Modification des colonnes :
CLASAPPT - Classe : devient facultatif

   Ajout de la colonne :
NMESARSM - Nombre maximum d'éléments à signer

   Ajout des colonnes :
TIFSATAF - Tiers fabricant
ADFSATAF - Adresse fabricant
ICFSATAF - Intitulé complet fabricant
IRFSATAF - Intitulé réduit fabricant

   Ajout des colonnes :
PTXSATNC - Proposition taxe (Obligatoire)
CG1SATNC - Proposition CGR A

   Ajout des colonnes :
CETSAWAM - Chemin composition ets