Document de release de la version H5.01

   Ce document présente les évolutions survenues sur l'application Cegid XRP Ultimate Achats en H5.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 nouvelles tables de sas en amont de celles du sas facture. Ces tables sont dédiées à la prise en charge des données provenant de Chorus Pro et transmises par un tiers de télétransmission :
- SATFB : en-tête des factures achats (GTFBA) ;
- SATDB : lignes des factures achats (SAITDB) ;
- SATDD : documents associés (SAITDD) ;
- SATDS : suivi des factures (SAITDS).

GTFBA - Factures achats à intégrer : données brutes (Transaction SAITFB)
SAITDB - Lignes de factures à intégrer : données brutes (Transaction SAITDB)
SAITDD - Documents associés aux factures à intégrer (Transaction SAITDD)
SAITDS - Suivi des factures à intégrer : données brutes (Transaction SAITDS)

   Les occurrences suivantes du paramètre AUTSACPP doivent, si elles ne le sont pas déjà, être mises en place pour le fonctionnement de ce connecteur :

   a) 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".

   b) 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 Cegid XRP Ultimate. La chaîne 1 donne le mode de paiement Cegid XRP Ultimate.
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.

   c) 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".

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

   e) 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.

   f) 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 DATRAF, FD-CLA, FD-ART et FD-CGR ne sont utilisées que pour la facturation directe.

   Lors de la valorisation d'une commande, ajout de la possibilité de contrôler combien il faudrait commander de plus pour que le franco de port soit atteint.

   Pour cela, ajout de l'occurrence FRANCO du paramètre AUTSACDA.

   Si la valeur testée 1 vaut :
- R : aucun contrôle n'est effectué ;
- B : le contrôle est effectué avec affichage d'un message d'erreur bloquant ;
- S : le contrôle est effectué avec affichage d'un message d'alerte.

   La chaîne 1 donne le type de condition de facturation à contrôler.

   La valeur testée 1 a été initialisée à "R" par la release.

GCDA - Commandes d'achats (Transaction SAICDA)

   Ajout de la possibilité de contrôler l'existence d'un document pour l'en-tête et/ou les lignes d'une demande d'achats, d'une commande, d'une réception et/ou d'une facture.

   Pour cela, création d'une gestion permettant de paramétrer les contrôles à effectuer (GCEDA) et d'un traitement par étape réalisant les contrôles pour les demandes d'achats (TCEDDA), les commandes (TCEDCA), les réceptions (TCEDRA) et/ou les factures (TCEDFA).
Pour chacun des traitements, le contrôle doit être décliné par entité de documents (GTDEN) et, éventuellement, par type de documents (GTDTY). Il peut être effectué pour les documents rattachés à l'en-tête ou les documents rattachés aux lignes et peut être bloquant ou signalé.

   Ne peuvent être contrôlés que les documents dont le format de l'identifiant est conforme aux GTDEN livrés en standard :
- ACHAT COMMANDE : numéro interne de la demande d'achats ou de la commande ;
- ACHAT RECEPTION : établissement de la réception concaténé au numéro de la réception ;
- ACHAT FACTURE : établissement de la facture concaténé au numéro de la facture ;
- ACHAT LIGNE : numéro interne de la demande d'achats ou de la commande concaténé au numéro de ligne.

GCEDA - Paramétrage pour ctrl. d'existence des documents (Transaction SAICED)
TCEDDA - Contrôle existence des documents des DA (Transaction SATCEDD)
TCEDCA - Contrôle existence des documents des commandes (Transaction SATCEDC)
TCEDRA - Contrôle existence des documents des réceptions (Transaction SATCEDR)
TCEDFA - Contrôle existence des documents des factures (Transaction SATCEDF)

   Chacun des traitements doit être défini dans les étapes par classe (GETCA) après la création de l'élément à contrôler. Ils doivent être définis comme suit :
- mnémonique d'appel : TCEDDA pour les demandes d'achats, TCEDCA pour les commandes, TCEDRA pour les réceptions et TCEDFA pour les factures ;
- traitement associé : SATCEDD pour les demandes d'achats, SATCEDC pour les commandes, SATCEDR pour les réceptions et SATCEDF pour les factures ;
- traitement par commande : pssacedetp ;
- traitement par autre entité : pssacedetp.

   Dans le but de simplifier et diminuer la quantité d'informations à saisir lors des délégations, ajout d'un nouveau processus de délégations permettant de saisir une délégation valable pour une ou plusieurs entités (demande d'achats, commande, réception, facture et/ou marché) et pour une liste d'établissements.

   Cette nouvelle saisie s'effectue à partir du conteneur des délégations simplifiées des signatures multicritères (GKDGMA) :
- la première partie de l'écran permet de saisir le signataire délégant, le délégué, la période de délégation et les entités auxquelles la délégation doit s'appliquer. Les entités autorisées pour un signataire délégant sont définies au niveau du paramétrage des utilisateurs délégants (GPUDA) : demandes d'achats, commandes, réceptions, factures et marchés. Les autorisations peuvent être définies pour chacun des utilisateurs délégants ou pour l'utilisateur "*". Les autorisations définies pour l'utilisateur "*" s'appliquent pour tous les utilisateurs délégants pour lesquels aucun paramétrage n'est défini en particulier ;
- la deuxième partie de l'écran permet d'indiquer pour la délégation en cours de saisie, les établissements auxquels la délégation doit s'appliquer. A partir du paramétrage des utilisateurs délégants (GPUDA), il est possible de définir, si tous les établissements ramenés par la recherche, sont sélectionnés par défaut ou non lors de la saisie d'une délégation simplifiée.

   A la validation de la délégation simplifiée, les délégations correspondantes (GGSMA) sont créées pour toutes les règles de signatures (GRSMA) définies pour les entités et les établissements sélectionnés.

   En fonction de la valeur du paramètre PR1 associé au mnémonique, l'utilisateur signataire est accessible ou non, c'est à dire que soit seul le délégant est autorisé à saisir les délégations le concernant, soit n'importe quelle personne peut le faire à sa place.
Si la valeur vaut :
- O : l'utilisateur signataire est accessible ;
- N : l'utilisateur signataire n'est pas accessible.

   Lors de la suppression d'une délégation simplifiée, la délégation est supprimée physiquement ou de façon logique (passage de l'état de l'enregistrement à la valeur "S") selon la valeur testée 1 du paramètre AUTSADGM occurrence SUPDGM.
Si la valeur testée 1 vaut :
- O : les délégations simplifiées sont supprimées physiquement ;
- N : les délégations simplifiées sont supprimées de façon logique par un passage de l'état à la valeur "S".

   Remarques :
- les délégations créées à partir des délégations simplifiées (GKDGMA) ne peuvent pas être modifiées ou supprimées à partir des délégations (GGSMA). Il est donc nécessaire d'effectuer la modification ou la suppression à partir du conteneur des délégations simplifiées (GKGDMA) ;
- la mise en place des délégations simplifiées impose qu'aucune délégation (GGSMA) ne soit en cours de validité ou valide ultérieurement pour une des règles de signatures concernées par la ou les entités de la délégation simplifiée.

   Afin de pouvoir différencier les règles de signatures appliquées aux demandes d'achats et celles appliquées aux commandes et afin de pouvoir limiter la durée des délégations, de nouveaux champs ont été ajoutés dans les règles de signatures (GRSMA) :
- "Règle pour" : dans le cas où la règle de signatures est définie pour l'entité "SACDA", cette information permet d'indiquer si la règle de signatures est définie pour des demandes d'achats, des commandes ou les deux ;
- "Délai maximal d'une délégation" : il est exprimé en jours. Il permet de limiter la durée d'une délégation.
Exemple : si le délai est positionné à 20 jours, il n'est pas possible de saisir une délégation allant du 01/01 au 25/01.

GPUDA - Paramétrage des utilisateurs délégants (Transaction SAIPUD)
GKDGMA - Délégations simplifiées signatures multicritères (Transaction SAIDGM)
GRSMA - Règles des signatures multicritères (Transaction SAIRSM)
GGSMA - Délégations des signatures multicritères (Transaction SAIGSM)

   Ajout de la possibilité de gérer le fait qu'un marché soit cédé à un autre fournisseur.

   Pour cela :
- création de l'occurrence CESSION pour le paramètre AUTSAREC. Si la valeur testée 1 vaut :
       - O : la cession est gérée ,
       - N : la cession n'est pas gérée ;
- création d'un nouveau type de complément de marchés publics (GCMP) : CM (cession de marchés) afin de pouvoir stocker, dans le tiers et l'adresse co-traitant, le tiers et l'adresse correspondant au nouveau fournisseur. Ce type de complément doit obligatoirement être associé au marché et la date de cession doit être saisie dans la date de signature.

   Lors du traitement de solde des commandes d'achats après réception (TSOLA), si la valeur testée 1 du paramètre AUTSAREC occurrence CESSION est égale à "'O" et s'il existe une cession pour le marché, les tiers et adresses de facturation, paiement et logistique de la commande origine et de la sous-commande solde générée sont modifiés avec ceux du nouveau fournisseur.

   De même, lors d'un retour temporaire (GRET) ou de l'annulation d'une commande réceptionnée (TACRA), si la valeur testée 1 du paramètre AUTSAREC occurrence CESSION est égale à "'O" et s'il existe une cession pour le marché, les tiers et adresses de facturation, paiement et logistique de la sous-commande générée en attente de réception sont affectés avec ceux du nouveau fournisseur.

   NB : s'il existe plusieurs compléments de marchés publics de type "CM" pour le marché, est pris en compte celui pour lequel la date de cession est inférieure à la date de la réception.

TSOLA - Solde des commandes d'achats après réception (Transaction SATSOLA)
GRET - Retours (Transaction SAIRET)
TACRA - Annulation d'une commande réceptionnée (Transaction SATACR)
TSOLAF - Solde de réception après facture (Transaction SATSOLAF)

   Ajout de la possibilité de mettre à jour le statut directement dans le SAS des données brutes.

   Ce traitement peut désormais mettre à jour le statut dans la table de SAS des données brutes pour qu'il soit transmis, par un tiers de télétransmission, à Chorus Pro.
Pour que ce traitement fonctionne, certaines occurrences du paramètre AUTSACPP doivent, si elles ne le sont pas déjà, être mises en place :
- les factures traitées sont celles ayant une origine commençant par la chaîne 1 du paramètre AUTSACPP occurrence CODORI ceci afin de gérer le changement du code origine si, à l'intégration de la facture, la valorisation n'est pas faite ;
- l'occurrence APPEME du paramètre AUTSACPP donne le code de l'application émettrice dans la chaîne 1 et son libellé dans le texte ;
- l'occurrence APPREC du paramètre AUTSACPP donne le code de l'application réceptrice dans la chaîne 1 et son libellé dans le texte ;
- l'occurrence STAxx (où xx correspond au code statut pour Chorus) du paramètre AUTSACPP donne la correspondance entre les étapes de commandes Cegid XRP Ultimate et le statut Chorus. Les valeurs 1 et 2 donnent l'étape ou la fourchette d'étapes correspondantes au statut (pour gérer une seule étape, mettre la valeur 2 égale à la valeur 1).

   Les valeurs possibles des statuts Chorus sont :
- 05 : Rejetée par l'ordonnateur pour autre motif ;
- 08 : Mandatée /DP validée ;
- 09 : Mise à disposition du comptable ;
- 10 : Comptabilisée.

TSCPFA - Génér. des statuts des factures achats Chorus Pro (Transaction SATSCPFA)

   1) Ajout de la possibilité de supprimer physiquement un marché dans le cas où la classe du marché n'est pas définie en multi-établissements.

   2) Si la case "Blocage en montant" est cochée pour le marché, contrôle que le montant prévu du marché ne soit pas inférieur à la somme des montants en cours et réalisé du marché. Ce contrôle est également effectué pour les montants prévus des lignes de type 1 et des lignes de type 2 du marché.

   1) Un marché peut être supprimé physiquement si les conditions suivantes sont remplies :
- il n'existe pas de lignes de marchés (GMADA/GMALA) pour le marché ;
- il n'existe pas de compléments de marchés publics (GCMP) pour le marché ;
- il n'existe pas de demandes d'achats ou de commandes, pour le marché, dont l'étape est inférieure à l'étape d'annulation (TSRD). Cette étape est donnée par l'occurrence ETPANUxxxx du paramètre AUTACHAT (où xxxx représente la classe d'achats).
Dans le cas où une de ces conditions n'est pas vérifiée, un message bloquant est affiché et le marché n'est pas supprimé.
Si le marché est supprimé, les informations liées au marché sont également supprimées (textes, ventilations par CGR, ventilations par pays d'origine, liens, rubriques, détails de signatures, historiques, contrats de services).

   NB : si la classe du marché est définie en multi-établissements, la suppression physique du marché est impossible. La suppression se traduit alors par une suppression logique du marché c'est à dire par un passage à l'état "S".

GMARA - Marchés (Transaction SAIMAR)

   1) Ajout de la possibilité de mettre à jour les quantités en cours et réalisées des lignes de marchés à partir des quantités commandées, reçues ou facturées ramenées en unité d'achat de la ligne de marché correspondante.

   2) Si la case "Blocage en montant" est cochée pour la ligne de marché, contrôle que le montant prévu de la ligne de marché ne soit pas inférieur à la somme des montants en cours et réalisé de la ligne de marché.

   1) Pour cela, une case à cocher "Mise à jour selon l'unité" a été ajoutée au niveau des classes de marchés (GNCM) :
Si cette case est cochée, les quantités en cours et réalisée des lignes de marchés sont mises à jour en tenant compte de l'unité d'achat des lignes de marchés : lors des différentes mises à jour, la quantité commandée, réceptionnée ou facturée des lignes de commandes est ramenée en unité d'achat de la ligne de marché correspondante. Pour cela, il est nécessaire de paramétrer les coefficients de conversions (GUNC) entre l'unité d'achat des lignes de commandes et l'unité d'achat des lignes de marchés correspondantes.
Si elle n'est pas cochée, les quantités en cours et réalisée des lignes de marchés sont mises à jour à partir de la quantité commandée, réceptionnée ou facturée des lignes de commandes sans tenir compte de l'unité d'achat de la ligne de marché correspondante.

   Il n'est pas possible de modifier la valeur de cette case à cocher si, pour un marché de la classe de marchés, il existe une commande dont l'étape est inférieure à la valeur 1 de l'occurrence ETPANUxxxx du paramètre AUTACHAT (où xxxx représente la classe d'achats).

   Cette case a été initialisée à "Non cochée" par la release.

GNCM - Classes de marchés (Transaction SAINCM)
GMADA - Lignes de marchés de type 1 (Transaction SAIMAD)
GLCA - Lignes de commandes d'achats (Transaction SAILCA)
GLAO - Lignes d'appels d'offre (Transaction SAILAO)
SAILCR - Lignes de réceptions en quantité (Transaction SAILCR)
SAILRM - Lignes de réceptions en montant (Transaction SAILRM)
SAIFLC - Lignes à facturer (Transaction SAILFLC)
SAILCF - Lignes de facture (Transaction SAILCF)
TMARAR - Cumul des cdes dans les marchés après réception (Transaction SATMARR)
TMARAF - Cumul des commandes dans les marchés après facture (Transaction SATMARF)
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)
GRET - Retours (Transaction SAIRET)
TAFAA - Annulation facture (Transaction SATAFA)
TGCAVA - Génération de commandes d'avoir (Transaction SATGCAV)

   Lors de la clôture d'un marché, si la classe de marchés (GNCM) est définie en multi-établissements, la clôture est effectuée sur tous les établissements de la composition (GCET) donnée par la classe de marchés.

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

   Ajout du statut dans le suivi des commandes et dans le suivi des factures.

   Pour que le statut des commandes soit affiché correctement dans le suivi des commandes, il est nécessaire de définir les occurrences du paramètre ACHSTATU telles que :
- CDE-01 : les chaînes 1 et 2 et les valeurs 1 et 2 représentent respectivement les fourchettes d'étapes minimales et maximales dans lesquelles doit être comprise l'étape de la commande pour que celle-ci soit au statut "Commandée" ;
- CDE-02 : les chaînes 1 et 2 et les valeurs 1 et 2 représentent respectivement les fourchettes d'étapes minimales et maximales dans lesquelles doit être comprise l'étape de la commande pour que celle-ci soit au statut "Commande réceptionnée" ;
- CDE-03 : les chaînes 1 et 2 et les valeurs 1 et 2 représentent respectivement les fourchettes d'étapes minimales et maximales dans lesquelles doit être comprise l'étape de la commande pour que celle-ci soit au statut "Commande facturée" ;
- CDE-04 : les chaînes 1 et 2 et les valeurs 1 et 2 représentent respectivement les fourchettes d'étapes minimales et maximales dans lesquelles doit être comprise l'étape de la commande pour que celle-ci soit au statut "Réceptionnée partiellement" ;
- CDE-05 : les chaînes 1 et 2 et les valeurs 1 et 2 représentent respectivement les fourchettes d'étapes minimales et maximales dans lesquelles doit être comprise l'étape de la commande pour que celle-ci soit au statut "Facturée partiellement".

   Pour que le statut des factures soit affiché correctement dans le suivi des factures, il est nécessaire de définir les occurrences du paramètre ACHSTATU telles que :
- FAC-01 : les valeurs 1 et 2 représentent la fourchette d'étapes dans laquelle doit être comprise l'étape des commandes rattachées à la facture pour que celle-ci soit au statut "Enregistrée" ;
- FAC-02 : les valeurs 1 et 2 représentent la fourchette d'étapes dans laquelle doit être comprise l'étape des commandes rattachées à la facture pour que celle-ci soit au statut "Comptabilisée" ;
- FAC-03 : les valeurs 1 et 2 représentent la fourchette d'étapes dans laquelle doit être comprise l'étape des commandes rattachées à la facture et les chaînes 1 et 2 représentent la fourchette de types d'acceptation (correspondant au litige) dans laquelle doit être compris le type d'acceptation de la facture pour que celle-ci soit au statut "En litige" ;
- FAC-04 : les valeurs 1 et 2 représentent la fourchette d'étapes dans laquelle doit être comprise l'étape des commandes rattachées à la facture et les chaînes 1 et 2 représentent la fourchette de types d'acceptation (correspondant au bon à payer) dans laquelle doit être compris le type d'acceptation de la facture pour que celle-ci soit au statut "Bon à payer" ;
- FAC-05 : les valeurs 1 et 2 représentent la fourchette d'étapes dans laquelle doit être comprise l'étape des commandes rattachées à la facture pour que celle-ci soit au statut "Payée".

   Pour toutes ces occurrences, il est possible de définir une pastille de couleur. Pour cela, il est nécessaire de renseigner la zone texte de chacune des occurrences avec :
- bulletsmallGN.png : Verte ;
- bulletsmallYL.png : Jaune ;
- bulletsmallRD.png : Rouge.

   Exemple pour le flux d'étapes suivant :
- 100 : Commande (GCDA) ;
- 120 : Confirmation de la commande (TCDA) ;
- 250 : Edition du bon de commande (EBCDA02) ;
- 300 : Transfert commandes en statistiques (TSTTCA) ;
- 400 : Réception (GREC) ;
- 440 : Solde des commandes après réception (TSOLA) ;
- 700 : Facturation (GFAA) ;
- 710 : Comptabilisation des factures (TVCC) ;
- 900 : Bon à payer (TTAC) ;
- 940 : Contrôle des factures payées (TCFP).

   Il faut paramétrer les occurrences telles que :

   Lors de l'intégration d'un fournisseur à partir du bouton "Intégration" de la gestion des fournisseurs de transfert (GTFOA), affichage d'un message informatif indiquant le code du fournisseur généré.

GTFOA - Fournisseurs de transfert (Transaction SAITFO)

   1) Ajout de la possibilité, lors de l'intégration des demandes d'achats ou des commandes (TTCDA), de renseigner le CGR A des lignes de demandes d'achats ou de commandes générées à partir d'une clé de proposition (GPCLA) pouvant prendre en compte le segment renseigné dans le sas des lignes.

   2) Ajout de la possibilité, lors de l'intégration des demandes d'achats ou des commandes (TTCDA), de préciser comment est renseignée la date au plus tôt de l'en-tête des demandes d'achats ou des commandes générées si la date au plus tôt de l'interface n'est pas renseignée.

   1) Pour cela, ajout de la possibilité de :
- pouvoir indiquer une clé de proposition (GPCLA) au niveau du paramétrage de la classe de transfert (GTNC) ;
- saisir l'entité MDEXT comme entité de recherche de cette clé de proposition (GPCLA). Dans ce cas, le segment correspondant à cette entité est affecté avec la valeur du CGR A renseigné dans le sas des lignes (SAITLC).

   Lors de l'intégration d'une ligne de demande d'achats ou de commande, s'il n'existe pas pour cette ligne de ventilations par CGR (GVCG) avec CGR A renseigné, le CGR A de la ligne est affecté en fonction du paramétrage de la classe de transfert (GTNC) :
- la clé de proposition CGR A n'est pas renseignée : le CGR A de la ligne de demande d'achats ou de commande générée est égal au CGR A du sas s'il est renseigné, sinon il est proposé par défaut ;
- la clé de proposition CGR A est renseignée : le CGR A de la ligne de demande d'achats ou de commande générée est proposée en fonction de cette clé de proposition et, éventuellement, du CGR A du sas si l'entité MDEXT est définie comme entité de recherche de cette clé de proposition.

   2) Pour cela, une nouvelle zone "Date au plus tôt de l'en-tête" a été ajoutée au niveau des classes de transfert (GTNC).
Si elle est égale à :
- date de commande : la date au plus tôt de l'en-tête de la demande d'achats ou de la commande générée est égale à la date de commande de la table d'interface si renseignée, sinon elle est égale à la date du jour de lancement du traitement d'intégration ;
- plus petite date prévue lignes : elle est affectée dans l'ordre de priorité suivant :
       - la date au plus tôt de l'en-tête de la demande d'achats ou de la commande générée est égale à la plus petite date prévue des lignes de la table d'interface si renseignée. Si la date au plus tôt ainsi affectée devient plus petite que la date de commande, celle-ci est alors renseignée avec la date au plus tôt,
       - la date de commande de la table d'interface si renseignée,
       - la date du jour de lancement du traitement d'intégration.

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

   Ajout d'informations complémentaires dans l'en-tête des demandes d'achats et des commandes.

   Ajout des libellés 1, 2, 3, 4 et 5 sur 60 caractères, des identifiants 1, 2, 3, 4 et 5 sur 20 caractères, des numériques 1, 2 et 3 et des dates 1, 2 et 3 dans une nouvelle fenêtre détail "Autres informations" des gestions des demandes d'achats (GDAI) et des commandes (GCDA), des sas des demandes d'achats (GTDAI) et des commandes (GTCDA) et également des formes sélections des commandes (CSCDA et TSCDA).

   Ajout de ces informations dans les colonnes pouvant être modifiées lors de :
- la duplication d'une commande : fenêtre détail "Duplication de commandes" et traitement de duplication de commandes (TDCDA) ;
- la modification des commandes (GMCDA).

GDAI - Demandes d'achats (Transaction SAIDAE)
GCDA - Commandes d'achats (Transaction SAICDA)
GKDAI - Demandes d'achats (Transaction SAIDAE)
GKCDA - Commandes d'achats (Transaction SAICDA)
GDAIC - Demandes d'achats (Transaction SAIDAEC)
GCDAC - Commandes d'achats (Transaction SAICDAC)
GTDAI - Interface des demandes d'achats (Transaction SAITCD)
GTCDA - Commandes d'interface (Transaction SAITCD)
TDCDA - Duplication de commandes (Transaction SATDCDA)
GMCDA - Modification des commandes (Transaction SAMCDA)
CSCDA - Sélection des commandes ou demandes d'achats (Transaction SACSCDA)
TSCDA - Sélection des commandes ou demandes d'achats (Transaction SATSCDA)

   Ajout de la possibilité, une fois la recherche effectuée, de remplir une liste (GLSCA) à partir des éléments sélectionnés dans la grille.

   Pour cela :

   a) au niveau du formulaire de recherche, ajout des informations suivantes :
           - un bouton de choix permettant d'indiquer si le code liste précisé permet d'effectuer ou pas la recherche :
                    - Affichage : le code liste permet d'effectuer la recherche,
                    - Insertion : le code liste n'est pas pris en compte lors de la recherche mais une fois que celle-ci a été effectuée. Les éléments sélectionnés dans la grille sont alors mis dans cette liste. Ce code liste est à nouveau renseigné dans l'en-tête de grille mais il peut être modifié ;
           - un bouton RAZ qui permet de supprimer les éléments (GELCA) qui composent la liste (GLSCA) précisée.

   b) au niveau de l'en-tête de grille, ajout des informations suivantes :
           - code liste : proposé égal au code liste du formulaire de recherche s'il est renseigné et si l'option "Insertion/Affichage" est égal à "Insertion". Il peut être modifié par l'utilisateur ;
           - bouton Générer : permet, à partir des éléments sélectionnés dans la grille, d'alimenter la liste (GLSCA) ;
           - bouton RAZ/Suppression : permet de supprimer les éléments (GELCA) qui composent la liste (GLSCA) précisée. Lorsque les éléments présents dans la grille sont issus de la recherche des éléments de la liste et qu'un ou plusieurs éléments sont sélectionnés dans la grille, ce bouton devient "Suppression". Son utilisation entraîne la suppression des éléments sélectionnés de la liste.

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)

   Ajout de la possibilité d'indiquer si les traitements, correspondant aux étapes par classe (GETCA) définis pour les classes des commandes générées, sont exécutés lors de la génération.

   Pour cela, ajout d'une case à cocher "Envoi des traitements" dans la fenêtre détail "Ajout des commandes générées dans la liste".

   Si la case est cochée, les traitements correspondant aux étapes (GETCA) définies pour les classes des commandes générées, sont exécutés lors de la génération. Les traitements sont alors effectués pour toutes les commandes générées, en fin de transformation des demandes d'achats en commande.

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)

   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'information de la première ligne de marché concernée par la génération.

   Pour cela, au niveau de la classe de marchés (GNCM), ajout de la valeur "F" 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)

   Lors de la duplication d'une demande d'achats ou d'une commande, ajout de la possibilité de modifier les interlocuteurs externe et logistique par rapport à ceux de la demande d'achats ou de la commande origine.

   Pour cela, ajout de ces informations dans les colonnes à modifier.

GCDA - Commandes d'achats (Transaction SAICDA)
TDCDA - Duplication de commandes (Transaction SATDCDA)

   En modification d'une ligne de demande d'achats déjà existante, possibilité en cas :
- de changement du code article, de re-proposer ou non l'intitulé, les prix, le compte, le poste, le CGR A, le CGR B, la TVA et/ou le dépôt ;
- de changement de la quantité demandée, de re-proposer ou non les prix.

   Pour cela, ajout de plusieurs paramètres associés au mnémonique permettant d'indiquer si la re-proposition doit être effectuée ou non :

   - INT pour l'intitulé. Si la valeur du paramètre vaut :
         - O : l'intitulé de la ligne de demande d'achats est proposé lors de la modification du code article,
         - N : l'intitulé de la ligne de demande d'achats n'est pas proposé lors de la modification du code article ;

   - PPX pour le prix tarif, la remise, le prix commandé et l'unité de prix. Si la valeur du paramètre vaut :
         - OO : les informations prix de la ligne de demande d'achats sont proposées lors de la modification du code article et lors de la modification de la quantité,
         - ON : les informations prix de la ligne de demande d'achats sont proposées lors de la modification du code article mais ne sont pas proposées lors de la modification de la quantité,
         - NO : les informations prix de la ligne de demande d'achats ne sont pas proposées lors de la modification du code article mais elles sont proposées lors de la modification de la quantité,
         - NN : les informations prix de la ligne de demande d'achats ne sont pas proposées lors de la modification du code article et lors de la modification de la quantité ;

   - DEP pour le dépôt. Si la valeur du paramètre vaut :
         - O : le dépôt de la ligne de demande d'achats est proposé lors de la modification du code article,
         - N : le dépôt de la ligne de demande d'achats n'est pas proposé lors de la modification du code article ;

   - CPT pour le compte. Si la valeur du paramètre vaut :
         - O : le compte de la ligne de demande d'achats est proposé lors de la modification du code article,
         - N : le compte de la ligne de demande d'achats n'est pas proposé lors de la modification du code article ;

   - POS pour le poste. Si la valeur du paramètre vaut :
         - O : le poste de la ligne de demande d'achats est proposé lors de la modification du code article,
         - N : le poste de la ligne de demande d'achats n'est pas proposé lors de la modification du code article ;

   - CG1 pour le CGR A. Si la valeur du paramètre vaut :
         - O : le CGR A de la ligne de demande d'achats est proposé lors de la modification du code article,
         - N : le CGR A de la ligne de demande d'achats n'est pas proposé lors de la modification du code article ;

   - CG2 pour le CGR B. Si la valeur du paramètre vaut :
         - O : le CGR B de la ligne de demande d'achats est proposé lors de la modification du code article,
         - N : le CGR B de la ligne de demande d'achats n'est pas proposé lors de la modification du code article ;

   - TVA pour le code taxe. Si la valeur du paramètre vaut :
         - O : le code taxe de la ligne de demande d'achats est proposé lors de la modification du code article,
         - N : le code taxe de la ligne de demande d'achats n'est pas proposé lors de la modification du code article.

   Les paramètres INT, DEP, CPT, POS, CG1, CG2 et TVA ont été initialisés à "O" par la release.
Le paramètre PPX a été initialisé à "OO" par la release.

GDAL - Lignes de demandes d'achats (Transaction SAIDAL)

   Ajout de la possibilité de modifier le CGR A et le CGR B sur une sous-commande solde facture.

GMLCA - Modification des lignes de commandes (Transaction SAMLCA)

   Lors des traitements d'éclatement des demandes d'achats ou des commandes, ajout de la possibilité de :
- ne pas recopier toutes les conditions de facturation non obligatoires sur les sous-demandes ou sous-commandes générées ;
- proratiser les conditions de facturation recopiées, non obligatoires, définies en montant (mode de calcul est égal à "+").

   Pour cela, ajout de l'occurrence xDUPCAF du paramètre AUTSACDA avec x égal à la valeur du PRM associé au traitement d'éclatement.
Si la valeur testée 1 vaut :
- O : toutes les conditions de facturation non obligatoires présentes sur la demande d'achats ou commande origine sont recopiées sur les sous-demandes d'achats ou sous-commandes générées ;
- N : seules les conditions de facturation dont le type est précisé dans la chaîne1 sont recopiées sur les sous-demandes d'achats ou sous-commandes générées. Plusieurs types, séparés par une virgule, peuvent être précisés dans la chaîne 1.

   Si la valeur testée 2 vaut :
- N : les conditions de facturation définies en montant (mode de calcul égal à "+") ne sont pas proratisées lors de la recopie ;
- O : les conditions de facturation définies en montant (mode de calcul égal à "+") sont proratisées lors de la recopie. Il est possible de proratiser toutes les conditions de facturation en montant qui sont recopiées ou seulement certaines. Dans ce cas, la chaîne 2 donne le type des conditions de facturation à proratiser. Plusieurs types, séparés par une virgule, peuvent être précisés dans la chaîne 2.

   Les valeurs testées 1 et 2 ont été initialisées respectivement à "O" et "N" par la release.

TEDA - Confirmation des demandes d'achats (Transaction SATEDA)
TCDA - Confirmation des commandes (Transaction SATCCDA)
TECLA - Eclatement par caractéristique article (Transaction SATECLA)
TLASMA - Eclatement des commandes pour la LASM (Transaction SATLASMA)

   Ajout de la possibilité de gérer plusieurs conditions de facturation avec le même type, dans les conditions de facturation des lignes de commandes.
Ces conditions doivent être de type "TX".

GCFGA - Conditions de facturation des achats (Transaction SGICFG)
GTFF - Conditions de facturation des fournisseurs (Transaction SAITFF)
GACFA - Conditions de facturation des articles achetés (Transaction SAIACF)
GRCFA - Conditions de facturation articles/fournisseurs (Transaction SAIRCF)
GCFCA - Conditions de facturation par classe (Transaction SAICFC)
GCFSA - Conditions de facturation par classe et statut (Transaction SAICFS)
SAICFL - Conditions de facturation des lignes de commandes (Transaction SAICFL)
TEDA - Confirmation des demandes d'achats (Transaction SATEDA)
TCDA - Confirmation des commandes (Transaction SATCCDA)
TECLA - Eclatement par caractéristique article (Transaction SATECLA)
TLASMA - Eclatement des commandes pour la LASM (Transaction SATLASMA)

   Ajout de la possibilité d'autoriser la modification des informations règlement (mode de règlement, délai, date, domiciliation du tiers) via la gestion de modification de masse des échéances (GMCAE) pour une commande dont l'écriture d'engagement (TVCCE) et/ou l'écriture de facture non parvenue (TVCCP) a été générée et n'est pas annulée : les informations règlements des pièces (GPIE) correspondantes sont également modifiées.

   Pour cela, la case à cocher "Modification des informations règlement après comptabilisation" a été remplacée par un bouton de choix.

   Les différentes options sont :

   - Commande/Réception :
        - si la modification des informations règlement intervient sur une commande non facturée pour laquelle une écriture d'engagement (TVCCE) et/ou une écriture de facture non parvenue (TVCCP) a été générée et n'est pas annulée, la modification est autorisée et les informations règlement des pièces (GPIE) correspondantes sont également modifiées,
         - si la modification des informations règlement intervient sur une commande facturée et que la facture est transférée en comptabilité (TVCC), la modification n'est pas autorisée ;

   - Commande/Réception/Facture : si la modification des informations règlement intervient sur une commande non facturée pour laquelle une écriture d'engagement (TVCCE) et/ou une écriture de facture non parvenue (TVCCP) a été générée et n'est pas annulée ou sur une commande facturée et que la facture est transférée en comptabilité (TVCC), la modification est autorisée et les informations règlement des pièces (GPIE) correspondantes sont également modifiées ;

   - Facture : si la modification des informations règlement intervient sur une commande facturée et que la facture est transférée en comptabilité (TVCC), la modification est autorisée et les informations règlement des pièces (GPIE) correspondantes sont également modifiées ;

   - Rien : si la modification des informations règlement intervient sur une commande non facturée pour laquelle une écriture d'engagement (TVCCE) et/ou de facture non parvenue (TVCCP) a été générée et n'est pas annulée ou sur une commande facturée et que la facture est transférée en comptabilité (TVCC), la modification n'est pas autorisée.

   Remarque : dans le cadre de la comptabilité publique, cette option ne peut pas être égale à "Commande/Réception" ou "Commande/Réception/Facture".

GNCA - Classes d'achats (Transaction SAINCA)
GMCAE - Modification des échéances (Transaction SAMCAE)

   1) Actions des signatures (GASMA) : ajout du bouton "Proposition".

   2) Possibilité de gérér une auto-signature en fonction des critères de signatures.

   3) Lancement des WIMs à la signature.

   4) Paramétrage de la durée de blocage des éléments à signer.

   5) Ajout d'un lien vers l'application mobile à partir des mails issus de certains WIMs.

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

   1) Actions des signatures (GASMA) : ajout du bouton "Proposition"
Pour chacune des actions à paramétrer pour une règle de signatures, ce bouton permet de proposer par défaut certains informations liées à l'action, comme par exemple : le nom du WIM à déclencher lors de l'exécution de l'action, lors de l'acceptation du dernier signataire, si les traitements suivants doivent être lancés, l'étape de refus, etc. .

   2) Possibilité de gérer une auto-signature en fonction des critères de signatures
Il est désormais possible de gérer l'auto-signature à un niveau donné en fonction des critères de signatures pour un signataire défini comme étant créateur de l'élément à signer. Cela permet de valider automatiquement la signature de ce signataire à ce niveau pour certains critères et non pas de façon générale.
Pour cela, un enregistrement doit être défini dans la matrice des signatures multicritères (GMSMA) pour un niveau donné, avec le code utilisateur signataire non renseigné et un type d'affectation égal à "A".
Lors du traitement d'affectation des signataires (TASMxA), si pour l'élément traité, il existe un enregistrement dans la matrice des signataires (GMSMA) correspondant aux critères sélectionnés et tel que le type d'affectation est égal à "A", alors le créateur de l'élément traité est créé dans les détails de signatures (GDSMxA) en tant que signataire avec un statut égal à "AS" (auto-signature).
Pour pouvoir gérer l'auto-signature au niveau des critères, elle ne doit pas être prise en compte de manière globale au niveau du paramétrage de la règle de la signature (GRSMA).

   3) Lancement des WIMs à la signature
Ajout de la possibilité de déterminer, si le traitement permettant de déclencher les WIMs suite à une action lors de la signature (GSMxA), est exécuté en immédiat ou en différé.
Pour cela, la valeur testée 2 de l'occurrence JOBEXE du paramètre AUTACHAT doit être renseignée telle que :
- I : le traitement est lancé en immédiat ;
- D : le traitement est lancé en différé.

    Remarque : lors de la signature, si plusieurs éléments sont traités simultanément à partir du bouton "Tout soumettre", alors les traitements permettant de déclencher les WIMs sont lancés de manière différée quel que soit le paramétrage.

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

   4) Paramétrage de la durée de blocage des éléments à signer
Il est désormais possible de paramétrer la durée de blocage d'un élément à signer par un signataire. Pour cela, il est nécessaire de renseigner la valeur 1 de l'occurrence SADSM du paramètre AUTSADUB. Cette valeur est exprimée en heures.
Si la valeur 1 n'est pas renseignée, alors le délai est illimité.

   Exemple : si un signataire recherche une commande à signer et qu'il part en laissant l'écran de signature ouvert, alors il perdra la "réservation" de cette commande si un autre signataire ramène cette même commande à signer dès lors que le délai de réservation est dépassé.

   5) Ajout d'un lien vers l'application mobile à partir des mails issus de certains WIMs
Les WIMs concernés sont :
- QLC_SAC_SMC_DA_UNI_SIG : Demande d'achats à signer ;
- QLC_SAC_SMC_CDA_UNI_SIG : Commande d'achats à signer ;
- QLC_SAC_SMC_REC_UNI_SIG : Réception à signer ;
- QLC_SAC_SMC_FAA_UNI_SIG : Facture à signer ;
- QLC_SAC_SMC_MAR_UNI_SIG : Marché à signer.

   6) Ajout de nouveaux critères pour l'affectation des signataires.
Nouveau critère pouvant être utilisé pour les règles de signatures des demandes d'achats, des commandes, des réceptions et/ou des factures : fournisseur de la commande (FOUSACDA).
Nouveau critère pouvant être utilisé pour les règles de signatures des réceptions : fournisseur de la réception (FOUSAREC) ;
Nouveau critère pouvant être utilisé pour les règles de signatures des factures : fournisseur de la facture (FOUSAFAA).

GASMA - Actions des signatures multicritères (Transaction SAIASM)
GCSMA - Critères de signatures (Transaction SAICSM)
GMSMA - Matrice des signatures multicritères (Transaction SAIMSM)
TASMDA - Affectation des signataires multicritères des DA (Transaction SATASMD)
TASMCA - Affectation signataires multicritères commandes (Transaction SATASMC)
TASMRA - Affectation signataires multicritères réceptions (Transaction SATASMR)
TASMFA - Affectation des signataires multicritères factures (Transaction SATASMF)
TASMMA - Affectation signataires multicritères marchés (Transaction SATASMM)
GSMDA - Signatures multicritères des demandes d'achats (Transaction SAISMD)
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)

   Ajout de la possibilité d'éditer un total par sous-commande lorsque le bon de commande est :
- lancé par liste ;
- avec édition de la sous-commande seule et saut de page à la sous-commande ;
- avec découpage du bon de commande, pour un envoi par fax ou par mail, par sous-commande.

   Pour cela, ajout du paramètre TOT au traitement.
Si sa valeur vaut :
- O : le total est édité par sous-commande ;
- N : le total est édité par commande.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   Ajout de la possibilité de lancer les traitements suivants réception par réception.

   Pour cela, ajout d'un nouveau champ "Envoi des traitements" dans le sas des réceptions (GTREA) et dans le sas de saisie du BL (GTBLA).
Ce champ permet d'indiquer réception par réception ou BL par BL, si l'envoi des traitements suivants doit être effectué ou pas :
- si la valeur est égale à "I", l'envoi des traitements suivants n'est pas effectué quel que soit la valeur testée 1 de l'occurrence TRTSAS du paramètre AUTSAREC ;
- si la valeur n'est pas renseignée, l'envoi des traitements est effectué en fonction de la valeur testée 1 de l'occurrence TRTSAS du paramètre AUTSAREC.

GTREA - Réception des commandes d'achats : Interface (Transaction SAITRE)
GTBLA - Sas de saisie du BL (Transaction SAITBL)
TTREA - Intégration des réceptions (Transaction SATTRE)
TTBLA - Intégration des bons de livraison (Transaction SATTBL)

   Ajout des informations suivantes à titre informatif :
- montant initial commandé : il représente la somme des montants commandés des lignes des sous-commandes regroupées ;
- montant restant à réceptionner : il représente la somme des montants restant à réceptionner des lignes des sous-commandes regroupées.

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

   Ajout de la possibilité de faire de la réception qualitative tout en obligeant pas la saisie du code qualité.

   C'est l'article acheté (GATA) qui va piloter si la réception qualitative peut être facultative. Pour cela, la case à cocher "Contrôle qualitatif" a été remplacée par un bouton de choix :
- Obligatoire ;
- Interdit ;
- Facultatif.

   Lors de la validation de la réception qualitative (TRQL ou TTAC), si l'article de la ligne est défini en contrôle qualitatif :
- obligatoire : le code qualité saisi sur la ligne sera comparé à un code paramétré afin de déterminer si la ligne est correcte ou non ;
- facultatif : la saisie du code qualité pour la ligne n'est pas obligatoire. Si le code qualité n'est pas renseigné, la ligne sera considérée comme conforme et s'il est renseigné, il sera comparé à un code paramétré afin de déterminer si la ligne est correcte ou non.

GATA - Articles achetés (Transaction SAIATA)
GRCPA - Réception (Transaction SAIRCP)
SAIRDT - Réception détail (Transaction SAIRDT)
SAILCR - Lignes de réceptions en quantité (Transaction SAILCR)
GRQL - Réception qualitative (Transaction SAIRQL)
TRQL - Validation de la réception qualitative (Transaction SATRQL)
TTAC - Bon à payer (Transaction SATTAC)
TASLF - Acceptation des lignes de signatures après facture (Transaction SATASLF)

   Possibilité d'effectuer, selon paramétrage, la génération de l'écriture de facture non parvenue alors que la commande est facturée.

   Si le paramètre PR2 associé au traitement des factures non parvenues (SATVCCP en standard) vaut :
- N : l'écriture de facture non parvenue est générée même s'il en existe déjà une en cours pour la commande traitée ;
- O : l'écriture de facture non parvenue est générée uniquement s'il n'en existe pas déjà une en cours pour la commande traitée ;
- C : l'écriture de facture non parvenue est générée uniquement s'il n'en existe pas déjà une comptable en cours pour la commande traitée.

   Le paramètre PR2 est initialisé à "N" par la release.

TVCCP - Factures non parvenues (Transaction SATVCCP)

   1) Ajout de la possibilité d'effectuer uniquement le rattachement en-tête de commande lors de l'intégration des factures.

   2) Ajout de la possibilité de renseigner le type de collectif et/ou le compte collectif de l'échéance sur les commandes rattachées à la facture.

   3) Ajout de la possibilité d'avoir le compte rendu en format ASCII : génération d'un fichier Excel.

   1) Pour cela, ajout d'une nouvelle valeur de la zone "Rattachement lignes" dans le sas des lignes de facture (SATFL) : "C". Cette nouvelle valeur permet d'effectuer le rattachement en-tête de commande uniquement.
Pour un même numéro de facture SAS, si la zone "Rattachement lignes" d'un des enregistrements de l'interface des lignes de factures (satfl) est égale à "C" (en-tête de commande), tous les enregistrements de l'interface des lignes de facture pour cette facture doivent avoir la même valeur pour cette zone.

   2) Pour cela, deux nouveaux champs "Type de collectif" (colsatfc) et "Compte collectif" (cptsatfc) ont été ajoutés dans le sas des factures d'achats (GTFCA). Ils permettent de pouvoir affecter un nouveau type de collectif et/ou un nouveau compte sur l'échéance des commandes d'achats.

   Lors de l'intégration de la facture, il est ainsi possible d'affecter le type de collectif de l'échéance avec la valeur en entrée du sas :
- en création de l'échéance lorsque le code échéance est renseigné dans le sas ;
- en création de l'échéance lors de la facturation directe ;
- en modification de l'échéance.

   L'affectation du compte de l'échéance se fait de la même manière : en création de l'échéance lorsque le code échéance est renseigné dans le sas ou en modification de l'échéance.

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

   Ajout de la possibilité, lors de la duplication d'une facture, de recopier les documents associés à l'en-tête de la facture origine.

   Pour cela, ajout de la case à cocher "Recopie des documents".
Si la case est cochée, les documents associés à l'en-tête de facture origine pour lesquels l'entité de documents (GTDEN) est égale à celle précisée, sont copiés.
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 précisé sont copiés. Dans ce cas, jusqu'à trois types de documents différents peuvent être précisés.
Ne peuvent être copiés que les documents dont le format de l'identifiant est conforme au GTDEN livré en standard (ACHAT FACTURE) : établissement concaténé au numéro de la facture.

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

   Le contrôle 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 (lignes de révision, lignes de pénalité) ne dépasse pas une certaine tolérance par rapport au montant HT ou TTC total de la facture a été modifié afin que les lignes de factures créées par le traitement de génération de facture de co/sous-traitance (TGFCSA) ne soient pas prises en compte dans le montant total HT et/ou TTC de la facture.

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

   1) Ajout de la possibilité, lors de la génération de l'écriture de facture, de ne pas remplacer le compte de pénalités (471x) ajoutés au service fait, par le compte technique correspondant.

   2) Si un équilibrage des comptes techniques de l'écriture de facture est effectué afin de régulariser des arrondis de centimes, ajout de la possibilité d'effectuer l'équilibrage à partir des informations comptables (compte, poste, CGR A) d'une des lignes de la facture.

   1) Pour ce faire, il faut que le compte de pénalités soit égal à la chaîne 1 ou à la chaîne 2 de l'occurrence CPTPEN du paramètre AUTM9. Ceci aura donc pour incidence de laisser visible le compte de pénalités sur l'écriture 408/401 afin d'être compatible avec la fonctionnalité de l'Application Finances permettant la consommation de CP.

   2) Pour cela, ajout de la valeur testée 1 égale à "L" pour l'occurrence CPTAEQL du paramètre AUTM9.
Dans ce cas, il est possible d'identifier la ligne de facture à prendre en compte, par la saisie de la valeur "M" dans une des zones de cette ligne.
La chaîne 1 indique alors la zone à alimenter : au choix parmi G01 (identifiant 1), G02 (identifiant 2), G03 (identifiant 3), G04 (identifiant 4), L01 (Libellé 1), L02 (Libellé 2), L03 (Libellé 3), L04 (Libellé 4) ou L05 (Libellé 5).
Si aucune des lignes de la facture n'est marquée, alors le mouvement d'équilibre est créé avec les informations comptables (compte, poste, CGR A) de la première ligne de la facture.

TVCC - Comptabilisation des factures (Transaction SATVCC)

   Ajout de la possibilité de générer une ligne sur la commande d'ajustement, si un équilibrage des comptes techniques de l'écriture de facture a eu lieu lors de la comptabilisation (TVCC) ceci afin de régulariser des problèmes d'arrondis de centimes entre les mouvements de factures et les mouvements d'annulation de la FNP correspondante.

   Cette possibilité est donnée par la valeur testée 1 du paramètre AUTSAAEF occurrence CPTAEQL. Si elle est égale à :
- N : aucune ligne de commande d'ajustement correspondant au rééquilibrage des comptes techniques n'est créée ;
- O : une ligne de commande d'ajustement est créée correspondant au rééquilibrage des comptes techniques. Les informations suivantes doivent alors être renseignées :
             - le texte donne l'article sur lequel va être créée la ligne d'ajustement,
             - la chaîne 1 donne le mode d'achat sur lequel va être créée la ligne d'ajustement. Il ne doit pas avoir influence en réception, en stock, en immobilisation, en statistiques, en marché.

   Si cette ligne d'ajustement est créée, les informations comptables de cette ligne (compte, poste, CGR A) sont renseignées égales aux informations comptables qui ont été affectées sur le mouvement d'équilibre lors du rééquilibrage des comptes techniques.

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

   Prise en compte de nouvelles dates pour l'affectation des dates de début et de fin de lissage des mouvements comptables.

   Pour cela, ajout des occurrences suivantes du paramètre LISSGTVC :

   - DA1E :
          - date 1 de l'en-tête de commande pour un lissage effectué lors d'un pré-engagement (TVCCD), engagement (TVCCE) et/ou facture non parvenue (TVCCP),
          - date 1 de l'en-tête de facture si renseignée, sinon date 1 de l'en-tête de commande pour un lissage effectué lors de la comptabilisation d'une facture (TVCC) ;

   - DA2E :
          - date 2 de l'en-tête de commande pour un lissage effectué lors d'un pré-engagement (TVCCD), engagement (TVCCE) et/ou facture non parvenue (TVCCP),
          - date 2 de l'en-tête de facture si renseignée, sinon date 1 de l'en-tête de commande pour un lissage effectué lors de la comptabilisation d'une facture (TVCC) ;

   - DA3E :
          - date 3 de l'en-tête de commande pour un lissage effectué lors d'un pré-engagement (TVCCD), engagement (TVCCE) et/ou facture non parvenue (TVCCP),
          - date 3 de l'en-tête de facture si renseignée, sinon date 1 de l'en-tête de commande pour un lissage effectué lors de la comptabilisation d'une facture (TVCC) ;

   - DA1L : date 1 de la ligne de commande pour un lissage effectué lors d'un pré-engagement (TVCCD), engagement (TVCCE), facture non parvenue (TVCCP) et/ou lors de la comptabilisation d'une facture (TVCC) ;

   - DA2L : date 2 de la ligne de commande pour un lissage effectué lors d'un pré-engagement (TVCCD), engagement (TVCCE), facture non parvenue (TVCCP) et/ou lors de la comptabilisation d'une facture (TVCC) ;

   - DA3L : date 3 de la ligne de commande pour un lissage effectué lors d'un pré-engagement (TVCCD), engagement (TVCCE), facture non parvenue (TVCCP) et/ou lors de la comptabilisation d'une facture (TVCC).

   Si une des dates de lissage (date de début ou date de fin) est égale à une des trois dates en-tête, alors l'autre date de lissage doit également être égale à une des trois dates en-tête.
Si une des dates de lissage (date de début ou date de fin) est égale à une des trois dates ligne, alors l'autre date de lissage doit également être égale à une des trois dates ligne.

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)

   Ajout de la possibilité, lors de la génération de la commande d'avoir, de créer des lignes de commandes d'avoir pour les lignes créées à la facture.

   Pour cela, une case à cocher "Prendre en compte les lignes créées à la facture" a été ajoutée à la soumission.

   Si la case est cochée et, selon le type d'écart géré, la quantité commandée et le prix commandé de la ligne de commande d'avoir, correspondant à une ligne créée à la facture, sont renseignés de la manière suivante :

   - Ecart prix :
        - quantité commandée = quantité facturée de la ligne créée à la facture,
        - prix commandé = prix facturé de la ligne créée à la facture multiplié par -1 ;

   - Ecart quantité reçue :
        - quantité commandée = quantité facturée de la ligne créée à la facture multipliée par -1,
        - prix commandé = prix facturé de la ligne créée à la facture ;

   - Ecart quantité commandée - facturée :
        - quantité commandée = -1,
        - prix commandé = quantité facturée de la ligne créée à la facture * prix facturé de la ligne créée à la facture.

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

   1) Ajout de la possibilité, lors de l'annulation d'une facture, de créer un nouvel en-tête de facture. Il est possible, pour cette nouvelle facture, d'alimenter le suivi des factures (CSVFA) et de recopier les documents associés à l'en-tête de facture origine.

   2) Lors de la création de l'en-tête de facture négative et du nouvel en-tête de facture positive, le contrôle d'unicité est effectué ou pas selon le paramètre AUTSAFAA occurrence CTLUNI.

   1) Si la case "Création en-tête de facture" est cochée, une nouvelle en-tête de facture est générée identique à la facture à annuler, sauf pour :
- le numéro de facture : numéro de facture saisi par l'utilisateur si l'occurrence SAINUM du paramètre AUTSAFAA indique que la numérotation des factures est manuelle, sinon numéro de facture attribué automatiquement à partir du compteur des factures (GNFA) ;
- la référence : est affectée selon l'option "Affectation référence" pour la nouvelle facture. Si elle est égale à :
         - "Manuelle" : référence saisie par l'utilisateur,
         - "Numéro de facture" : numéro de facture origine auquel est ajouté le préfixe saisi par l'utilisateur,
         - "Référence" : référence de la facture origine à laquelle est ajouté le préfixe saisi par l'utilisateur ;
- transaction de création : code du traitement d'annulation facture (SATAFA pour le traitement standard) ;
- utilisateur de création : est affecté selon la case à cocher "Recopie créateur" :
          - si la case est cochée : utilisateur de création de la facture origine,
          - si la case n'est pas cochée : utilisateur qui lance le traitement d'annulation facture.

   De plus, si la case "Suivi facture" est cochée, une ligne de données est automatiquement créée, dans le suivi des factures (CSVFA) afin d'indiquer, pour la facture origine, le numéro de la nouvelle facture générée.

   Selon la case à cocher "Recopie des documents", il est également possible pour cette nouvelle facture, de dupliquer les documents associés à l'en-tête de la facture origine.
Si la case est cochée, les documents associés à l'en-tête de la facture origine pour lesquels l'entité de documents (GTDEN) est égale à celle précisée, sont copiés.
Il est 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 précisé sont copiés. Dans ce cas, jusqu'à trois types de documents différents peuvent être précisés.
Ne peuvent être copiés que les documents dont le format de l'identifiant est conforme au GTDEN livré en standard (ACHAT FACTURE) : établissement concaténé au numéro de la facture.

TAFAA - Annulation facture (Transaction SATAFA)

   Modification de la recherche des anomalies dans les éditions.

   Pour les éditions d'analyse des anomalies (EANOCA) et du résultat du CHD par catégorie, période, structure (ERDCA), la recherche des erreurs se fait différemment.
Sont prises en compte uniquement les factures refusées lors de la signature (action "Refuser pour resoumettre" (RR)) pour lesquelles la valeur du code refus correspond à une occurrence du paramètre RETSACDA avec la chaîne 1 égale à "CHD".
Désormais, une anomalie est dite patrimoniale si la chaîne 2 du paramètre RETSACDA occurrence correspondant au code refus est égale à "P".

EANOCA - CHD : Analyse des anomalies (Transaction SAEANOC)
ERDCA - Résultats du CHD par catégorie, période, structure (Transaction SAERDC)

   Suppression d'un message intempestif, lors de la saisie d'une domiciliation bancaire, dans le cas où le tiers qui est envoyé en comptabilité (tiers de paiement ou tiers de facturation) n'est pas renseigné.

GTFOA - Fournisseurs de transfert (Transaction SAITFO)

   Correction d'un message d'erreur lié à un problème de confidentialité dans le cas où les dates de validité sont modifiées à la soumission.

ERAF - Edition des articles référencés par fournisseur (Transaction SAERAF)

   Correction des listes de valeurs dans le cas où l'établissement de la demande d'achats ou de la commande est différent de l'établissement de connexion.

GTDAI - Interface des demandes d'achats (Transaction SAITCD)
GTCDA - Commandes d'interface (Transaction SAITCD)

   Correction d'un problème d'activation / désactivation du champ "Dépôt client ou fournisseur".

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

   Correction du contrôle de saisie, de modification et/ou de suppression en fonction de l'étape de la commande à partir des lignes de réception en montant (SAILRM).

SAILRM - Lignes de réceptions en montant (Transaction SAILRM)
GCAPL - Paramètres des lignes de commandes (Transaction SAICAP)

   Correction de l'affichage de l'information "Montant ligne" dans le cas où l'article de la ligne de commande est défini en "Génération composants".

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

   Correction pour gérer correctement le calcul du nombre total de pages de la commande éditée lorsque le recto verso est utilisé.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   Lors de l'affectation des signataires des signatures multicritères après facture (TASMFA), si la règle de signature indique que la signature est automatique après BAP, le traitement d'affectation des signataires ne pose aucun signataire et la facture traitée passe automatiquement à l'étape de signature facture (GSMFA) associée dans le cas où le bon à payer (TTAC) a été donné précédemment sur la facture avec le type d'acceptation égal à celui donné par la règle de signature.
Dans tous les autres cas (pas de bon à payer, bon à payer refusé avec code rejet ou bon à payer donné avec un type d'acceptation différent de celui de la règle de signature), le traitement d'affectation des signataires pose les signataires et la facture doit être signée.

TASMFA - Affectation des signataires multicritères factures (Transaction SATSMF)

   Ajout des contrôles suivants lors de la modification de la date de facture ou de la date comptable d'une facture (GFAA) :
- contrôle que la date comptable soit bien supérieure ou égale à la date de réception de chacune des commandes rattachées dans le cas où la chaîne 1 de l'occurrence DECFAA du paramètre AUTSAFAA est égale à "O" ;
- contrôle que la date de facture ou la date comptable de facture soit supérieure à la date de dernière clôture en fonction du paramétrage de la clôture (GCLOA).

GFAA - Contrôle facture (Transaction SAIFAA)

   Correction afin de ne plus affecter à zéro les numériques 1, 2 et 3 sur la facture générée lorsqu'ils ne sont pas renseignés sur la facture origine.

TDFAA - Duplication de factures (Transaction SATDFA)

   Le compte de l'immobilisation est affecté avec celui envoyé en comptabilité pour la ligne concernée (compte d'exception ou compte de la ligne).

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

   Correction pour ne pas avoir d'anomalie si un des éléments liés n'est pas une demande d'achats ou une commande. Cet élément ne doit pas alors être affiché dans la consultation.

CDCDA - Consultation de l'évolution d'une commande (Transaction SACDCD)

   Correction pour que le multi-établissements (GTMME) sur l'entité "SACMA" fonctionne correctement.

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

   1) Paramétrage de la génération des demandes d'acompte (GPACA)
Cette transaction permet de définir, pour une classe de commandes, différents types de demandes d'acomptes. Chacun d'eux va permettre de paramétrer :
- comment vont être générées les commandes d'acomptes (classe d'achats, échéance, article, montant) ;
- un contrôle de dépassement, afin que la totalité des commandes d'acomptes générées pour une commande ne dépasse pas un certain montant de la commande origine.

   Pour chaque type de demande d'acompte, il est nécessaire de définir :
- si le montant de l'acompte est calculé à partir d'un pourcentage ou s'il est égal à un montant fixe ;
- une condition de facturation à partir de laquelle le montant de l'acompte est calculé si le mode de calcul est "Pourcentage". Dans ce cas, le numéro de condition de facturation doit être :
            - de type marchandise, base de TVA, total TTC ou net à payer,
            - identique pour tous les types de demandes d'acomptes définis pour une classe de commandes ;
- la classe d'achats sur laquelle vont être générées les commandes d'acompte. Cette classe doit être une classe de commandes et elle doit être définie en numérotation automatique. Aucune mise à jour marché ne doit être précisée : au niveau de la classe d'achats (GNCA), le contrôle "Mise à jour du marché" doit être égal à "Pas de contrôle" et aucune étape de mise à jour marché (TMARAx) ne doit être présente dans les étapes par classe (GETCA) de la classe d'acomptes ;
- un article acheté : il s'agit de l'article sur lequel va être créée la ligne de commande d'acompte. Le compte (GCPT) proposé à partir de cet article acheté doit être un compte 409xxxx défini en génération de pièce obligatoire et en TVA interdite ;
- un code échéance : s'il est renseigné, les échéances (GCAE) de la commande d'acompte sont créées à partir de ce code échéance ;
- pourcentage de contrôle de dépassement : permet d'indiquer un pourcentage d'un montant de la commande origine à ne pas dépasser pour la totalité des acomptes générés. Ce contrôle est effectué lors du traitement de contrôle des montants d'acompte (TCMACA), qui doit être mis en place dans les étapes par classe (GETCA) de la commande d'origine et dans les étapes par classe (GETCA) des commandes d'acomptes liées.
Le pourcentage de contrôle doit être identique pour tous les types de demandes d'acomptes définis pour une classe de commandes ;
- condition de facturation pour le contrôle de dépassement : permet d'indiquer à partir de quelle condition de facturation (GCAF) est effectué le contrôle de dépassement. La condition de facturation doit être :
            - de type marchandise, base de TVA, total TTC ou net à payer,
            - identique pour tous les types de demandes d'acomptes définis pour une classe de commandes.

   2) Ajout d'une fenêtre détail à partir de GCDA (Acompte) permettant de générer une commande d'acompte
Il est nécessaire de préciser :
- un type de demande d'acompte (GPACA) défini pour la classe de la commande ;
- un montant d'acompte ou un pourcentage, selon le paramétrage du type de demande d'acompte (GPACA), à appliquer à la commande origine pour calculer le montant d'acompte ;
- un code échéance (facultatif), proposé à partir du type de demande d'acompte (GPACA). Les échéances (GCAE) de la commande d'acompte sont créées à partir de ce code échéance s'il est renseigné, sinon du code échéance du type de demande d'acompte s'il est renseigné, sinon à partir des échéances de la commande origine.

   Le bouton "Génération" permet de créer une commande d'acompte, si au moins une ligne de commande a été saisie pour la commande origine.

   L'en-tête de commande d'acompte est créée à l'identique de la commande origine sauf pour :
- la classe : classe d'acompte définie pour le type de demande d'acompte (GPACA) ;
- le numéro de commande attribué automatiquement ;
- le sous-numéro : égale à 1 ;
- étape : étape par défaut pour la classe dans les étapes par classe d'acompte (GETCA).
Toutes les autres informations de la commande d'acompte sont identiques à celles de la commande origine (marché, fournisseur, tiers et adresses, devise, dépôt, date de commande, date au plus tôt, date au plus tard, date comptable, date de contrat, informations taxes, informations transport, ...).

   Création des tables annexes liées à l'en-tête :
- conditions de facturations (GCAF) : 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és à la classe d'achats (GCFCA) ;
- échéances : à partir du code échéance saisi par l'utilisateur, sinon du code échéance du type de demande d'acompte, sinon elles sont recopiées à partir des échéances de la commande origine ;
- gestionnaires (GCAG)) : les gestionnaires sont créés par défaut à partir des gestionnaires associés au fournisseur (GTFG) et des autorisations des gestionnaires par classe (GAGC) ;
- textes (GTXT) : les textes sont générés par défaut à partir des textes modèles définis éventuellement pour le fournisseur (GTXEFOU), la classe d'achats (GTXENCA) et le pays (GTXEPAYS) ;
- rubriques (GRUCA) : les rubriques sont créées par défaut à partir des rubriques associées au fournisseur (GARUFOU) et à la classe d'achats (GARUNCA).

   Création de la ligne d'acompte avec les informations suivantes :
- article : article défini pour le type de demande d'acompte ;
- libellé de la ligne : proposé par défaut ;
- quantité : égale à 1 ;
- prix tarif, prix commandé : montant de l'acompte saisi par l'utilisateur si le mode de calcul pour le type de demande d'acompte est égal à "Montant", sinon montant calculé : pourcentage saisi par l'utilisateur appliqué au montant de la condition de facturation définie pour le type de demande d'acompte ;
- unité de prix : non renseignée ;
- mode d'achat : proposé par défaut ;
- compte : proposé par défaut. Le compte (GCPT) doit être défini en génération de pièce obligatoire et en TVA interdite ;
- poste : proposé par défaut ;
- CGR A, CGR B : proposés par défaut ;
- taxe : il est recherché une taxe telle que :
            - le taux du code TVA est égal à zéro,
            - le type de taxe est égal au type de taxe de l'en-tête de commande,
            - le mode de taxe est égal au mode de taxe de l'en-tête de commande,
            - le régime de taxe est égal au régime de taxe de l'en-tête de commande,
            - la part de la taxe est égale à la part de la taxe proposée ;
- informations immobilisations : non renseignées ;
- informations liées à la DEB : non renseignées.

   Pour plus de détails sur les propositions par défaut, vous pouvez vous reporter à la documentation de GLCA ou au récapitulatif des propositions par défaut.

   Création des tables annexes liées à la ligne :
- textes (GTXT) : les textes sont générés par défaut à partir des textes modèles définis éventuellement pour la référence article/fournisseur (GRAF), pour l'article acheté (GATA), et/ou pour l'article principal (GTXEART) ;
- rubriques (GRUCA) : les rubriques sont créées par défaut à partir des rubriques définies pour l'article par établissement (GARU), pour l'article acheté (GARUATA).

   La commande d'acompte est valorisée.

   Les associations commandes et acomptes (CASCACA) sont alimentées, afin de pouvoir retrouver les commandes d'acomptes générées pour une commande donnée.

   3) Contrôle des montants d'acompte (TCMACA)
Ce traitement permet de contrôler que le montant total des commandes d'acomptes associées à une commande origine, ne dépasse pas un certain pourcentage du montant de la commande origine. Le montant à prendre en compte correspond au montant de la condition de facturation utilisée pour le contrôle de dépassement donné par le type de demande d'acompte ayant permis la génération de la commande d'acompte.

   Ce traitement correspond à une étape qui doit être définie de manière générale dans les étapes (GETPA) et également dans les étapes par classe (GETCA) pour la classe de la commande origine et pour la classe des acomptes.

   Il doit être situé avant le traitement de confirmation de commandes (TCDA).

   Mise en place dans GETPA/GETCA :
- Mnémonique d'appel : TCMACA
- Traitement associé : SATCMAC
- Traitement par commande : pssacmacetp
- Traitement par autre entité : pssacmacetp

   Remarque : il est obligatoire que le paramétrage de la classe (GNCA) de la commande origine et de la classe d'acompte interdise la modification des lignes de commandes une fois le traitement effectué, afin que le contrôle des montants soit cohérent avec la valorisation des différentes commandes impliquées. Si une modification doit être effectuée, il est alors nécessaire d'effectuer un retour à l'étape initiale (TANU).

   4) Création des récupérations d'acompte (TCRACA)
Ce traitement permet pour les commandes d'une facture pour lesquelles un ou plusieurs acomptes ont été générés, de créer les récupérations d'acomptes (SAIRAA) correspondantes, au prorata du montant TTC de la commande. Pour chaque commande de la facture, il est créé autant de récupération que de commandes d'acomptes liées facturées, comptabilisées et dont l'étape est inférieure à la valeur 1 du paramètre AUTSAFAA occurrence ANU-XXXX où XXXX représente la classe d'achats.

   Les acomptes à récupérer (SAIRAA) sont créés pour chaque échéance de la commande traitée :
- commande d'acompte : classe, numéro, sous-numéro de la commande d'acompte liée ;
- facture : numéro de facture de la commande d'acompte ;
- pièce : numéro de pièce d'acompte à partir de laquelle la récupération doit être effectuée. Elle est proposée égale à la pièce correspondant à la ligne de facture d'acompte qui a été générée lors de la comptabilisation (TVCC) de la facture d'acompte ;
- montant à récupérer : calculer en fonction du solde de la pièce d'acompte et du montant TTC de l'échéance de la commande traitée ;
- informations paiement (mode de règlement, délai, date) : proposées de l'échéance de la commande traitée ;
- informations comptables (compte collectif, CGR A, CGR B) : proposées de l'échéance de la commande traitée ;
- date d'échéance : date d'échéance de l'échéance de la commande traitée ;
- domiciliation : domiciliation de l'échéance de la commande traitée.

   Les acomptes à récupérer sont alors pris en compte par le traitement de récupération d'acomptes (TRACA), ce qui permet lors de la comptabilisation (TVCC) de la facture, de réduire le montant à payer du fournisseur.

   Ce traitement correspond à une étape qui doit être définie de manière générale dans les étapes (GETPA) et également dans les étapes par classe (GETCA) pour la classe de la commande ayant généré des acomptes.

   Il doit être situé avant le traitement de récupérations d'acomptes (TRACA).

   Mise en place dans GETPA/GETCA :
- Mnémonique d'appel : TCRACA
- Traitement associé : SATCRAC
- Traitement par commande : pssacracetp
- Traitement par autre entité : pssacracetp

   5) Récupération d'acomptes (TRACA)
Ce traitement a pour but de récupérer un ou plusieurs acomptes associés à la facture. Cela se traduit par :
- la génération d'une écriture de récupération d'acomptes pour chacune des récupérations d'acomptes (SAIRAA) liées à la facture ;
- l'extourne partielle ou totale de la pièce d'acompte origine en associant celle-ci avec la pièce générée par l'écriture de récupération d'acompte ;
- l'association de la pièce générée par l'écriture de récupération d'acompte à la commande en cours de facturation dans les associations commandes d'achats - pièces (GPIAA). La comptabilisation de la facture (TVCC) qui va suivre va, grâce à cette association, associer la pièce de récupération d'acompte à la pièce de facture afin de réduire le montant à payer au fournisseur.

   Le type de ventilation (GTVCA) utilisé doit être de type "Récupération d'avance ou d'acompte" et être défini avec "Regroupement des mêmes échéances".

   Ce traitement correspond à une étape qui doit être définie de manière générale dans les étapes (GETPA) et également dans les étapes par classe (GETCA) pour la classe de la commande ayant généré des acomptes.

   Il doit être situé avant le traitement comptabilisation des factures (TVCC).

   Mise en place dans GETPA/GETCA :
- Mnémonique d'appel : TRACA
- Traitement associé : SATRAC
- Traitement par commande : pssaraaetp
- Traitement par autre entité : pssaraaetp
- Mnémonique des critères : SATRAC

   6) Annulation des commandes (TSRD)
Suivant la valeur du paramètre PR1 associé au traitement, il est possible de ne pas traiter les commandes pour lesquelles une commande d'acompte dont l'étape est inférieure à la valeur 1 du paramètre AUTACHAT occurrence ETPANUxxxx, où xxxx représente la classe de la commande d'acompte, a été générée.
Si la valeur du paramètre vaut :
- O : les commandes pour lesquelles une commande d'acompte a été générée ne peuvent pas être annulées ;
- N : les commandes pour lesquelles une commande d'acompte a été générée peuvent être annulées.

   Exemples :

   1) Ajout de la possibilité de renseigner de nouveaux champs lors de l'intégration des marchés par Contrat'tech Legisway.

   2) Ajout de la possibilité de ne pas faire de mise à jour dans les tables d'exploitation des marchés.

   1) Les nouveaux champs pris en compte, lors de l'intégration des marchés par Contrat'tech Legisway, sont :
- échéance ;
- gestionnaire ;
- gestionnaire technique ;
- gestionnaire commercial ;
- gestionnaire complémentaire 1 ;
- gestionnaire complémentaire 2 ;
- gestionnaire complémentaire 3 ;
- Interlocuteur 2 ;
- texte 6 ;
- texte 7 ;
- texte 8 ;
- type ;
- nature.

   2) Pour cela, ajout d'une case à cocher "Mise à jour" à la soumission qui indique si la mise à jour des tables d'exploitation est autorisée ou pas.
Dans le cas de la table des compléments des marchés publics (sacmp), la mise à jour ne se fait pas s'il existe un enregistrement pour le marché, l'établissement, le numéro de ligne de marché, la tranche et le type de complément, quel que soit le numéro de complément.

TLWMARA - Contrat'tech Legisway : Intégration des marchés (Transaction SATLWMAR)

   1) Ajout de la possibilité de renseigner les champs suivants lors de l'appel du WebService :
- marché ;
- numériques 1, 2 et 3 ;
- libellés 1, 2, 3, 4 et 5 ;
- identifiants 1, 2, 3, 4 et 5 ;
- dates 1, 2 et 3 ;
- type de collectif ;
- compte collectif.

   2) Modification pour éviter d'avoir un statut intempestif égal à 4 lors d'une intégration réussie.

   Modification du WebService pour prendre en compte le nouveau champ "Envoi des traitements" (trtsatre) dans le sas des réceptions (GTREA).

   Possibilité de déterminer le nombre d'éléments traités à afficher.

   Pour cela, ajout de l'occurrence TRTAFF du paramètre SASMCMOB.
La valeur 1 donne le nombre maximum d'éléments à ramener dans les éléments traités.
La valeur 2 donne la période au cours de laquelle sont ramenés les éléments. Elle est exprimée en mois.

   Exemple :
- si la valeur 1 est égale à 10, seuls les 10 derniers éléments signés sont affichés dans les éléments traités ;
- si la valeur 2 est égale à 6, seuls les éléments signés au cours des 6 derniers mois sont affichés dans les éléments traités.
Il est possible de mélanger ces deux possibilités ou d'en utiliser qu'une des deux.

   Modification de la colonne :
CALSAACF - Méthode de calcul : libellé revu, "Mode de calcul" remplacé par "Méthode de calcul"

   Modification de la colonne :
CALSACAF - Méthode de calcul : libellé revu, "Mode de calcul" remplacé par "Méthode de calcul"

   Ajout des colonnes :
IN3SACDA - Informations 3
IN4SACDA - Informations 4
IN5SACDA - Informations 5
NU1SACDA - Numérique 1
NU2SACDA - Numérique 2
NU3SACDA - Numérique 3
L01SACDA - Libellé 1
L02SACDA - Libellé 2
L03SACDA - Libellé 3
L04SACDA - Libellé 4
L05SACDA - Libellé 5
G01SACDA - Identifiant 1
G02SACDA - Identifiant 2
G03SACDA - Identifiant 3
G04SACDA - Identifiant 4
G05SACDA - Identifiant 5
DA1SACDA - Date 1
DA2SACDA - Date 2
DA3SACDA - Date 3

   Modification de la colonne :
CALSACFC - Méthode de calcul : libellé revu, "Mode de calcul" remplacé par "Méthode de calcul"

   Modification de la colonne :
CALSACFL - Méthode de calcul : libellé revu, "Mode de calcul" remplacé par "Méthode de calcul"

   Modification de la colonne :
CALSACFS - Méthode de calcul : libellé revu, "Mode de calcul" remplacé par "Méthode de calcul"

   Ajout des colonnes :
ORISAGSM - Origine (Obligatoire)

   Modification des colonnes :
P01SAMAD - Paramètre complémentaire 1 : libellé revu, "Paramètre 1" remplacé par "Paramètre complémentaire 1"
P02SAMAD - Paramètre complémentaire 2 : libellé revu, "Paramètre 2" remplacé par "Paramètre complémentaire 2"
P03SAMAD - Paramètre complémentaire 3 : libellé revu, "Paramètre 3" remplacé par "Paramètre complémentaire 3"
P04SAMAD - Paramètre complémentaire 4 : libellé revu, "Paramètre 4" remplacé par "Paramètre complémentaire 4"
P05SAMAD - Paramètre complémentaire 5 : libellé revu, "Paramètre 5" remplacé par "Paramètre complémentaire 5"
P06SAMAD - Paramètre complémentaire 6 : libellé revu, "Paramètre 6" remplacé par "Paramètre complémentaire 6"
P07SAMAD - Paramètre complémentaire 7 : libellé revu, "Paramètre 7" remplacé par "Paramètre complémentaire 7"
P08SAMAD - Paramètre complémentaire 8 : libellé revu, "Paramètre 8" remplacé par "Paramètre complémentaire 8"
P09SAMAD - Paramètre complémentaire 9 : libellé revu, "Paramètre 9" remplacé par "Paramètre complémentaire 9"
P10SAMAD - Paramètre complémentaire 10 : libellé revu, "Paramètre 10" remplacé par "Paramètre complémentaire 10"
P11SAMAD - Paramètre complémentaire 11 : libellé revu, "Paramètre 11" remplacé par "Paramètre complémentaire 11"
P12SAMAD - Paramètre complémentaire 12 : libellé revu, "Paramètre 12" remplacé par "Paramètre complémentaire 12"
P13SAMAD - Paramètre complémentaire 13 : libellé revu, "Paramètre 13" remplacé par "Paramètre complémentaire 13"
P14SAMAD - Paramètre complémentaire 14 : libellé revu, "Paramètre 14" remplacé par "Paramètre complémentaire 14"
P15SAMAD - Paramètre complémentaire 15 : libellé revu, "Paramètre 15" remplacé par "Paramètre complémentaire 15"
P16SAMAD - Paramètre complémentaire 16 : libellé revu, "Paramètre 16" remplacé par "Paramètre complémentaire 16"
P17SAMAD - Paramètre complémentaire 17 : libellé revu, "Paramètre 17" remplacé par "Paramètre complémentaire 17"
P18SAMAD - Paramètre complémentaire 18 : libellé revu, "Paramètre 18" remplacé par "Paramètre complémentaire 18"
P19SAMAD - Paramètre complémentaire 19 : libellé revu, "Paramètre 19" remplacé par "Paramètre complémentaire 19"
P20SAMAD - Paramètre complémentaire 20 : libellé revu, "Paramètre 20" remplacé par "Paramètre complémentaire 20"

   Modification des colonnes :
P01SAMAR - Paramètre complémentaire 1 : libellé revu, "Paramètre 1" remplacé par "Paramètre complémentaire 1"
P02SAMAR - Paramètre complémentaire 2 : libellé revu, "Paramètre 2" remplacé par "Paramètre complémentaire 2"
P03SAMAR - Paramètre complémentaire 3 : libellé revu, "Paramètre 3" remplacé par "Paramètre complémentaire 3"
P04SAMAR - Paramètre complémentaire 4 : libellé revu, "Paramètre 4" remplacé par "Paramètre complémentaire 4"
P05SAMAR - Paramètre complémentaire 5 : libellé revu, "Paramètre 5" remplacé par "Paramètre complémentaire 5"
P06SAMAR - Paramètre complémentaire 6 : libellé revu, "Paramètre 6" remplacé par "Paramètre complémentaire 6"
P07SAMAR - Paramètre complémentaire 7 : libellé revu, "Paramètre 7" remplacé par "Paramètre complémentaire 7"
P08SAMAR - Paramètre complémentaire 8 : libellé revu, "Paramètre 8" remplacé par "Paramètre complémentaire 8"
P09SAMAR - Paramètre complémentaire 9 : libellé revu, "Paramètre 9" remplacé par "Paramètre complémentaire 9"
P10SAMAR - Paramètre complémentaire 10 : libellé revu, "Paramètre 10" remplacé par "Paramètre complémentaire 10"
P11SAMAR - Paramètre complémentaire 11 : libellé revu, "Paramètre 11" remplacé par "Paramètre complémentaire 11"
P12SAMAR - Paramètre complémentaire 12 : libellé revu, "Paramètre 12" remplacé par "Paramètre complémentaire 12"
P13SAMAR - Paramètre complémentaire 13 : libellé revu, "Paramètre 13" remplacé par "Paramètre complémentaire 13"
P14SAMAR - Paramètre complémentaire 14 : libellé revu, "Paramètre 14" remplacé par "Paramètre complémentaire 14"
P15SAMAR - Paramètre complémentaire 15 : libellé revu, "Paramètre 15" remplacé par "Paramètre complémentaire 15"
P16SAMAR - Paramètre complémentaire 16 : libellé revu, "Paramètre 16" remplacé par "Paramètre complémentaire 16"
P17SAMAR - Paramètre complémentaire 17 : libellé revu, "Paramètre 17" remplacé par "Paramètre complémentaire 17"
P18SAMAR - Paramètre complémentaire 18 : libellé revu, "Paramètre 18" remplacé par "Paramètre complémentaire 18"
P19SAMAR - Paramètre complémentaire 19 : libellé revu, "Paramètre 19" remplacé par "Paramètre complémentaire 19"
P20SAMAR - Paramètre complémentaire 20 : libellé revu, "Paramètre 20" remplacé par "Paramètre complémentaire 20"

   Ajout des colonnes :
MQUSANCM - Mise à jour selon l'unité (Obligatoire)

   Ajout des colonnes :
PRCSARAA - Programme créateur

   Modification des colonnes :
PIESARAA - Numéro de pièce :
NECSARAA - Numéro d'échéance de pièce :
MNTSARAA - Montant de la récupération :

   Ajout des colonnes :
MICSARCP - Montant initial commandé
MRRSARCP - Montant restant à réceptionner

   Ajout des colonnes :
RDCSARSM - Règle pour les demandes / commandes (Obligatoire)
DMDSARSM - Délai maximal délégation

   Ajout des colonnes :
NU1SATCD - Numérique 1
NU2SATCD - Numérique 2
NU3SATCD - Numérique 3
L01SATCD - Libellé 1
L02SATCD - Libellé 2
L03SATCD - Libellé 3
L04SATCD - Libellé 4
L05SATCD - Libellé 5
G01SATCD - Identifiant 1
G02SATCD - Identifiant 2
G03SATCD - Identifiant 3
G04SATCD - Identifiant 4
G05SATCD - Identifiant 5
DA1SATCD - Date 1
DA2SATCD - Date 2
DA3SATCD - Date 3

   Modification de la colonne :
CALSATCF - Méthode de calcul : libellé revu, "Mode de calcul" remplacé par "Méthode de calcul"

   Ajout des colonnes :
CPTSATFC - Compte collectif
COLSATFC - Type de collectif

   Modification de la colonne :
CALSATFF - Méthode de calcul : libellé revu, "Mode de calcul" remplacé par "Méthode de calcul"

   Modification des colonnes :
P01SATMD - Paramètre complémentaire 1 : libellé revu, "Paramètre 1" remplacé par "Paramètre complémentaire 1"
P02SATMD - Paramètre complémentaire 2 : libellé revu, "Paramètre 2" remplacé par "Paramètre complémentaire 2"
P03SATMD - Paramètre complémentaire 3 : libellé revu, "Paramètre 3" remplacé par "Paramètre complémentaire 3"
P04SATMD - Paramètre complémentaire 4 : libellé revu, "Paramètre 4" remplacé par "Paramètre complémentaire 4"
P05SATMD - Paramètre complémentaire 5 : libellé revu, "Paramètre 5" remplacé par "Paramètre complémentaire 5"
P06SATMD - Paramètre complémentaire 6 : libellé revu, "Paramètre 6" remplacé par "Paramètre complémentaire 6"
P07SATMD - Paramètre complémentaire 7 : libellé revu, "Paramètre 7" remplacé par "Paramètre complémentaire 7"
P08SATMD - Paramètre complémentaire 8 : libellé revu, "Paramètre 8" remplacé par "Paramètre complémentaire 8"
P09SATMD - Paramètre complémentaire 9 : libellé revu, "Paramètre 9" remplacé par "Paramètre complémentaire 9"
P10SATMD - Paramètre complémentaire 10 : libellé revu, "Paramètre 10" remplacé par "Paramètre complémentaire 10"
P11SATMD - Paramètre complémentaire 11 : libellé revu, "Paramètre 11" remplacé par "Paramètre complémentaire 11"
P12SATMD - Paramètre complémentaire 12 : libellé revu, "Paramètre 12" remplacé par "Paramètre complémentaire 12"
P13SATMD - Paramètre complémentaire 13 : libellé revu, "Paramètre 13" remplacé par "Paramètre complémentaire 13"
P14SATMD - Paramètre complémentaire 14 : libellé revu, "Paramètre 14" remplacé par "Paramètre complémentaire 14"
P15SATMD - Paramètre complémentaire 15 : libellé revu, "Paramètre 15" remplacé par "Paramètre complémentaire 15"
P16SATMD - Paramètre complémentaire 16 : libellé revu, "Paramètre 16" remplacé par "Paramètre complémentaire 16"
P17SATMD - Paramètre complémentaire 17 : libellé revu, "Paramètre 17" remplacé par "Paramètre complémentaire 17"
P18SATMD - Paramètre complémentaire 18 : libellé revu, "Paramètre 18" remplacé par "Paramètre complémentaire 18"
P19SATMD - Paramètre complémentaire 19 : libellé revu, "Paramètre 19" remplacé par "Paramètre complémentaire 19"
P20SATMD - Paramètre complémentaire 20 : libellé revu, "Paramètre 20" remplacé par "Paramètre complémentaire 20"

   Modification des colonnes :
P01SATMR - Paramètre complémentaire 1 : libellé revu, "Paramètre 1" remplacé par "Paramètre complémentaire 1"
P02SATMR - Paramètre complémentaire 2 : libellé revu, "Paramètre 2" remplacé par "Paramètre complémentaire 2"
P03SATMR - Paramètre complémentaire 3 : libellé revu, "Paramètre 3" remplacé par "Paramètre complémentaire 3"
P04SATMR - Paramètre complémentaire 4 : libellé revu, "Paramètre 4" remplacé par "Paramètre complémentaire 4"
P05SATMR - Paramètre complémentaire 5 : libellé revu, "Paramètre 5" remplacé par "Paramètre complémentaire 5"
P06SATMR - Paramètre complémentaire 6 : libellé revu, "Paramètre 6" remplacé par "Paramètre complémentaire 6"
P07SATMR - Paramètre complémentaire 7 : libellé revu, "Paramètre 7" remplacé par "Paramètre complémentaire 7"
P08SATMR - Paramètre complémentaire 8 : libellé revu, "Paramètre 8" remplacé par "Paramètre complémentaire 8"
P09SATMR - Paramètre complémentaire 9 : libellé revu, "Paramètre 9" remplacé par "Paramètre complémentaire 9"
P10SATMR - Paramètre complémentaire 10 : libellé revu, "Paramètre 10" remplacé par "Paramètre complémentaire 10"
P11SATMR - Paramètre complémentaire 11 : libellé revu, "Paramètre 11" remplacé par "Paramètre complémentaire 11"
P12SATMR - Paramètre complémentaire 12 : libellé revu, "Paramètre 12" remplacé par "Paramètre complémentaire 12"
P13SATMR - Paramètre complémentaire 13 : libellé revu, "Paramètre 13" remplacé par "Paramètre complémentaire 13"
P14SATMR - Paramètre complémentaire 14 : libellé revu, "Paramètre 14" remplacé par "Paramètre complémentaire 14"
P15SATMR - Paramètre complémentaire 15 : libellé revu, "Paramètre 15" remplacé par "Paramètre complémentaire 15"
P16SATMR - Paramètre complémentaire 16 : libellé revu, "Paramètre 16" remplacé par "Paramètre complémentaire 16"
P17SATMR - Paramètre complémentaire 17 : libellé revu, "Paramètre 17" remplacé par "Paramètre complémentaire 17"
P18SATMR - Paramètre complémentaire 18 : libellé revu, "Paramètre 18" remplacé par "Paramètre complémentaire 18"
P19SATMR - Paramètre complémentaire 19 : libellé revu, "Paramètre 19" remplacé par "Paramètre complémentaire 19"
P20SATMR - Paramètre complémentaire 20 : libellé revu, "Paramètre 20" remplacé par "Paramètre complémentaire 20"

   Ajout des colonnes :
DRDSATNC - Proposition date au plus tôt en-tête (Obligatoire)

   Ajout de la colonne :
TRTSATRE - Envoi des traitements