Document de release de la version I2.01

   Ce document présente les évolutions survenues sur l'application Cegid XRP Ultimate Achats en I2.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.

   Possibilité d'envoyer l'e-mail du bon de commande à un ou des destinataires particuliers.

   Pour cela, création d'un nouveau traitement par étape, situé avant le bon de commande (EBCDA02).
Ce traitement recherche, dans le paramétrage des messages électroniques (GTUPME), le texte modèle associé au traitement du bon de commande (SAEBCDA2) ainsi que les destinataires principaux ou en copie et, génère la structure de l'e-mail pour la commande.

   Une fois la structure de l'e-mail générée, celle-ci est visualisable via la gestion des messages électroniques pour les traitements (GKTUMELT).

   NB : Il est possible de ne pas utiliser le nouveau traitement et de créer la structure de l'e-mail manuellement, directement dans la gestion GKTUMELT via le bouton "Générer les messages".

TGMET - Génér. des messages électroniques pour les trts (Transaction SATGMET)
GKTUMELT - Message électronique pour les traitements (Transaction TUIMELT)

   Ce nouveau traitement doit être défini dans les étapes par classe (GETCA), il doit être situé avant l'édition du bon de commandes (EBCDA02).
Il doit être défini comme suit :
- mnémonique d'appel : TGMET ;
- traitement associé : SATGMET ;
- traitement par commande : pssatgmetetp ;
- traitement par autre entité : pssatgmetetp.

   Le paramétrage des messages électroniques (GTUPME) doit être défini : il permet d'associer le traitement du bon de commande (SAEBCDA2) à un texte modèle paramétré dans la gestion des modèles de texte contextualisé (GNMTE).

   Les destinataires de l'e-mail sont à saisir dans la gestion de paramétrage des destinataires supplémentaires (GTUPDE).

   Par défaut, le lien entre les commandes d'achats (GCDA) et le message électronique pour les traitements (GKTUMELT) n'est pas livré. Il faut donc créer l'association de mnémoniques (GAMN) entre ces deux transactions.
Il faut également créer les paramètres de synchronisation pour la transaction correspondant aux commandes (SAICDA en standard). Ces paramètres doivent être définis en sortie :
- le paramètre ENTITE pour lequel il faut affecter la colonne avec la constante SACDA ;
- le paramètre IDENT6 pour lequel il faut affecter la colonne à NUISACDA.

   Attention : Pour effectuer le paramétrage dans son intégralité, nécessité de formation.

   Ajout de la possibilité de contrôler que les factures des co/sous-traitants associées à la facture d'un titulaire aient atteint une certaine étape pour pouvoir comptabiliser la facture du titulaire.

   Pour cela, création d'un nouveau traitement par étape à insérer dans le circuit des factures des titulaires et dans le circuit de commande négative de co/ sous-traitance (si utilisation de deux circuits).
Ce traitement doit être situé avant comptabilisation.

   L'étape des commandes des factures de co/sous-traitance doit être supérieure ou égale à l'étape donnée par la valeur 1 de l'occurrence CTLETPxxxx (xxxx représente la classe d'achats) du paramètre AUTSACSF.

TAFCSA - Ctrl. avancement des factures de co/sous-traitance (Transaction SATAFCS)

   Le traitement doit être défini dans les étapes par classe (GETCA), pour les classes correspondant aux factures des titulaires. Il doit être situé après facture et avant comptabilisation.
Il doit être défini comme suit :
- mnémonique d'appel : TAFCSA ;
- traitement associé : SATAFCS ;
- traitement par commande : pssaafcsetp ;
- traitement par autre entité : pssaafcsetp.

   Les occurrences CTLETPxxxx du paramètre AUTSACSF doivent être créées pour toutes les classes des factures de co/sous-traitance. La valeur 1 doit contenir l'étape minimale à laquelle doivent être les commandes des factures de co/sous-traitance.

   Afin de garantir une déclaration de TVA correcte, mise en place d'une nouvelle façon de gérer la LASM.
Pour rappel, le principe de la LASM (Livraison à soi-même) est de collecter une partie de la TVA, cette TVA étant une charge en plus.

   Afin de faire cohabiter les deux façons de gérer la LASM, l'ancien principe est basé sur des conditions de facturation de type "LS" et le nouveau principe est basé sur des conditions de facturation de type "LC". Pour une commande, seul un des deux types est autorisé.

   Attention : il n'est pas possible de gérer la LASM sur des commandes avec du prorata de TVA.

   1) Il est nécessaire de créer trois nouvelles conditions de facturation générales (GCFGA) avec un numéro supérieur à celui de la condition de type "M " (Marchandise) et inférieur à celui de la condition de type "T" (Base de TVA) :

   - une condition de facturation de type "LC" (Livraison à soi-même charge).
Celle-ci doit être définie avec un taux qui doit être positif.
Le code TVA doit être renseigné : le taux du code TVA doit être égal à zéro et la part du code TVA doit être égale à "Z" (LASM) ;

   - une condition de facturation de type "LT" (Livraison à soi-même taxe).
Celle-ci doit être définie avec un taux qui doit être négatif.
Le code TVA doit être renseigné : la part du code TVA doit être égale à "L" (LASM).
Le compte de charge doit être renseigné et défini en TVA collectée ;

   - une condition de facturation de type "LF" (Livraison à soi-même fictive).
Celle-ci doit être définie avec un taux et ce dernier doit être positif.
Le code TVA doit être renseigné : le taux du code TVA doit être égal à zéro et la part du code TVA doit être égale à "L" (LASM).

   Le compte de charge doit être renseigné et défini en TVA collectée.

   Le taux des conditions de facturation de type "LT" et "LF" doit être identique en valeur absolue.

   Le compte des conditions de facturation de type "LT" et "LF" doit être identique.

   Ces conditions de facturation doivent être associées aux commandes pour lesquelles la LASM doit être gérée. Pour cela, il est nécessaire d'associer la condition de facturation de type "LC" aux articles concernés par la LASM à partir des conditions de facturation des articles achetés (GACFA) ou des conditions de facturation articles/fournisseurs (GRCFA). Si vous souhaitez gérer cette nouvelle condition de facturation, il est donc nécessaire de supprimer auparavant, les anciennes conditions de facturation de type "LS", associées à vos articles (GACFA-GRCFA).
Au moment de la création d'une ligne de commande pour un article, pour lequel une condition de type "LC" est définie, cette condition de facturation est créée automatiquement dans les conditions de facturation associées à la ligne (SAICFL).

   2) Modification du traitement d'éclatement des commandes pour la LASM (TLASMA) afin que :
- la commande soit éclatée en sous-commandes si les caractéristiques des conditions de facturation pour le type "LC" sont différentes d'une ligne de commande à une autre ;
- la condition de facturation de type "LC" soit créée au niveau des conditions de facturation de la commande (GCAF) ;
- les conditions de facturation de type "LT" et "LF" soient créées au niveau des conditions de facturation de la commande (GCAF). Ces deux conditions sont données respectivement par la chaîne 1 et la chaîne 2 du paramètre AUTLASM occurrence le numéro de condition de facturation de type "LC".

   A la création de la condition de facturation (GCAF) de type "LC", il est recherché une taxe équivalente telle que :
   - le type est égal au type de l'en-tête de commande ;
   - le mode est égal au mode de l'en-tête de commande ;
   - le régime est égal au régime de l'en-tête de commande ;
   - le taux est égal au taux du code de TVA de la condition de facturation générale (GCFGA) (rappel : le taux du code TVA doit être égal à zéro) ;
   - la part est égale à la part du code TVA de la condition de facturation générale (GCFGA) (rappel : la part du code TVA doit être égale à "Z").

   A la création de la condition de facturation (GCAF) de type "LT", il est recherché une taxe équivalente telle que :
   - le type est égal au type de l'en-tête de commande ;
   - le mode est égal au mode de l'en-tête de commande ;
   - le régime est égal au régime de l'en-tête de commande ;
   - le taux est égal au taux de la condition de facturation de type "LC" ;
   - la part est égale à la part du code TVA de la condition de facturation générale (GCFGA) (rappel : la part du code TVA doit être égale à "L").

   A la création de la condition de facturation (GCAF) de type "LF", il est recherché une taxe équivalente telle que :
   - le type est égal au type de l'en-tête de commande ;
   - le mode est égal au mode de l'en-tête de commande ;
   - le régime est égal au régime de l'en-tête de commande ;
   - le taux est égal au taux du code de TVA de la condition de facturation générale (GCFGA) (rappel : le taux du code TVA doit être égal à zéro) ;
   - la part est égale à la part du code TVA de la condition de facturation générale (GCFGA) (rappel : la part du code TVA doit être égale à "L").

   Des codes de TVA dédiés devront être paramétrés.

   Pour une commande, il n'est pas possible de gérer à la fois la LASM via les conditions de facturation de type "LS" et via les conditions de facturation de type "LC".

   Remarque: les conditions de facturation de type "LC" ne peuvent pas être définies ni par fournisseur (GTFF), ni par classe d'achats (GCFCA).

   3) Modification du transfert en comptabilité (TVCCx), afin de prendre en compte la TVA collectée pour le mouvement correspondant à la condition de facturation de type "LT".

   4) Exemple de schéma d'écriture pour une commande de 1000 HT, TVA de 20% et une LASM de 10% :
- Ligne de 1000 HT, TVA 20DH avec un taux de 20%, compte de charge 606100 ;
- Condition de facturation 3115 de type LC, taux 10%, TVA Z0DZ avec taux 0% et part Z ;
- Condition de facturation 3215 de type LT, taux -100%, compte 606LASM en TVA collectée, TVA 10DL avec taux 10% ;
- Condition de facturation 3315 de type LF, taux 100%, compte 606LASM en TVA collectée, TVA Z0DL avec taux 0%.

GCFGA - Conditions de facturation des achats (Transaction SAICFG)
GACFA - Conditions de facturation des articles achetés (Transaction SAIACF)
GRCFA - Conditions de facturation articles/fournisseurs (Transaction SAIRCF)
GTFF - Conditions de facturation des fournisseurs (Transaction SAITFF)
GCFCA - Conditions de facturation par classe (Transaction SAICFC)
GTACFA - Conditions de facturation de trf articles achetés (Transaction SAITCF)
GTRCFA - Condition fact. de trf réf. art./fourn. (Transaction SAITRCF)
TLASMA - Eclatement des commandes pour la LASM (Transaction SATLASM)
TVCCE - Engagement (Transaction SATVCCE)
TVCCP - Factures non parvenues (Transaction SATVCCP)
TVCC - Comptabilisation des factures (Transaction SATVCC)

   Lors de l'ajout d'une ligne, le calcul automatique du numéro de ligne n'est plus effectué pour le numéro interne de la demande ou de la commande mais, pour toutes les sous-demandes de la demande ou pour toutes les sous-commandes de la commande, ceci afin d'éviter le message SALCA145 (Numéro de ligne associé à un autre article).

   Ceci n'est effectué que lors de la saisie manuelle d'une ligne dans les gestions :
- lignes de demandes d'achats (GDAL) ;
- lignes de commandes d'achats (GLCA) ;
- lignes d'appels d'offre (GLAO) ;
- lignes de BL (SAILBL) ;
- lignes de réceptions en quantité (SAILCR) ;
- lignes de réceptions en montant (SAILRM) ;
- lignes de factures (SAILCF).

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

   Ajout de la possibilité de suivre des fournisseurs étrangers.

   Il est dorénavant possible de suivre les fournisseurs étrangers depuis Cegid XRP Ultimate. La recherche, pour l'inscription, est effectuée dans cet ordre :
- inscription avec le code SIRET de l'adresse du fournisseur s'il est renseigné ;
- inscription avec le code ISO du pays de l'adresse du fournisseur s'il est renseigné et avec le code DUNS du complément de tiers ;
- inscription avec le numéro de TVA intracommunautaire de l'adresse du fournisseur s'il est renseigné sinon, avec le numéro de TVA intracommunautaire du tiers ;
Si la recherche n'aboutit pas, aucune inscription du fournisseur n'est effectuée.

   NB : auparavant, l'inscription s'effectuait uniquement avec le code SIRET.

   Pour bénéficier de cette évolution, lors de l'abonnement au WebService Provigis, il est nécessaire de prendre un abonnement avec :
- ajout d'un fournisseur international (DUNS) ;
- ajout manuel d'un fournisseur international.

SACPVGF - Informations du fournisseur via Provigis (Transaction SACPVGF)
GKPVG - Informations du fournisseur via Provigis (Transaction SACPVGF)

   Ajout de la possibilité, à l'ouverture de la gestion de génération des commandes à partir des demandes d'achats, de supprimer les éléments bloqués pour l'utilisateur connecté lorsque ses éléments sont bloqués, dans la table de travail, au-delà d'un certain délai.

   Les données traitées par la génération de commandes à partir de demandes d'achats sont enregistrées dans une table intermédiaire (SADAI).

   Il est possible, dans certains cas, que ces données soient bloquées dans cette table alors que la génération n'a pas été lancée et que le numéro de travail n'a pas été attribué (exemple : coupure de courant, fermeture du navigateur en HTML5, ...). Pour pouvoir traiter ces données, il faut alors les supprimer de la table intermédiaire et faire à nouveau la génération.

   Pour cela, il est désormais possible, à l'ouverture de la gestion :
- de supprimer les éléments bloqués pour l'utilisateur connecté. Les éléments bloqués ne peuvent être supprimés qu'au-delà d'un certain délai. Celui-ci est donné par la valeur 1 du paramètre AUTSADUB occurrence SADAI. Cette valeur peut être exprimée en heures ou en minutes.
Si la valeur testée 1 vaut :
           -   H : la valeur 1 est exprimée en heures,
           -   M : la valeur 1 est exprimée en minutes.
Si la valeur 1 n'est pas renseignée ou est égale à zéro, aucun déblocage n'est effectué ;
- de supprimer les éléments bloqués depuis la veille pour les utilisateurs autres que l'utilisateur connecté. Cette possibilité est donnée par la valeur testée 2 du paramètre AUTSADUB occurrence SADAI. Si la valeur testée 2 vaut :
           -   N : la suppression des éléments bloqués depuis la veille n'est pas effectuée,
           -   O : la suppression les éléments bloqués depuis la veille est effectuée.

   Si la valeur testée 1 n'est pas renseignée, elle est initialisée à "H" par la release.
Si la valeur testée 2 n'est pas renseignée, elle est initialisée à "N" par la release.

GTDAC - Génération de commandes à partir de DA (Transaction SAIDAC)
TDAI - Génération de commandes à partir de DA (Transaction SATDAI)

   Dans le cas où l'option "RAZ ligne" est cochée, conservation de la quantité commandée origine (1 ou -1) pour les lignes de commandes réceptionnables en montant.

TDCDA - Duplication de commandes (Transaction SATDCDA)

   1) Modification de la prise en compte de la durée de blocage des éléments à signer.

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

   3) Lors de la signature, stockage des avis successifs.

   4) Dans le cas où la signature peut être effectuée en fonction du type de niveau (pour un niveau donné et un même type de niveau, un seul signataire doit signer), possibilité d'alimenter dynamiquement le type de niveau des signataires.

   5) Ajout de la possibilité de sélectionner ou désélectionner tous les éléments à signer.

   6) Lors d'une acceptation globale des factures, ajout de la possibilité de ne pas prendre en compte les factures à signer suite à un litige.

   7) Dans le compte rendu complet du traitement de purge des signatures multicritères (TPSMA), ajout de la date et de l'heure de réservation de l'élément bloqué.

   1) Modification de la prise en compte de la durée de blocage des éléments à signer.

   Désormais, à l'ouverture de l'écran de signatures, les éléments à signer, bloqués par l'utilisateur connecté, sont débloqués sans délai.

   De plus, pour les éléments à signer qui sont bloqués par d'autres utilisateurs, il est possible de paramétrer la durée de blocage des éléments à signer.
Si la valeur testée 1 de l'occurrence SADSM du paramètre AUTSADUB vaut :
- H : la durée de blocage est exprimée en heures ;
- M : la durée de blocage est exprimée en minutes.
La durée de blocage est donnée par la valeur 1.
Dans le cas où la durée de blocage est exprimée en minutes, il est fortement conseillé de mettre au moins 15 minutes.

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

   Nouveaux critères pouvant être utilisés pour les règles de signatures des demandes d'achats, des commandes, des réceptions et/ou des factures :
- catégorie du fournisseur de la commande (CATFOUC) ;
- rôle d'une ligne (ROLSALCA).

   Nouveau critère pouvant être utilisé pour les règles de signatures des réceptions : catégorie du fournisseur de la réception (CATFOUR).

   Nouveaux critères pouvant être utilisés pour les règles de signatures des factures :
- catégorie du fournisseur de la facture (CATFOUF) ;
- code rejet de la facture (RJTSAFAA).

   3) Lors de la signature, stockage des avis successifs.

   Désormais, si un utilisateur demande un avis (DA), donne son avis (AV) ou ajoute un signataire (JS) plusieurs fois au même niveau pour un élément à signer, les détails de signature (GDSMx) sont conservés pour chacune de ses actions.

   4) Dans le cas où la signature peut être effectuée en fonction du type de niveau (pour un niveau donné et un même type de niveau, un seul signataire doit signer), possibilité d'alimenter dynamiquement le type de niveau des signataires.

   Lors du traitement d'affectation des signataires (TASMDA, TASMCA, etc.), le type de niveau des signataires est affecté avec la même valeur pour plusieurs signataires différents si ces derniers sont posés au même niveau pour les mêmes critères de signature (GMSMA).
Cela permet, ainsi, à une seule personne de signer parmi tous les signataires ayant les mêmes critères de signature à un niveau donné.

   Pour activer cette fonctionnalité, il faut :
- au niveau de la règle de signature (GRSMA), l'information "Action si plusieurs signataires au même niveau" doit être positionnée à "N" (en fonction du type de niveau) ;
- définir un type de niveau particulier, utilisable uniquement dans la matrice (GMSMA). La valeur testée 2 de l'occurrence correspondant à ce type de niveau pour le paramètre TNISAMSM doit être égale à "D" ;
- dans les éléments de la matrice (GMSMA), pour une règle de signature, si à un niveau donné, un élément est défini avec un type de niveau défini en dynamique, alors, tous les types de niveau de ce niveau doivent être égaux au type de niveau défini en dynamique.

   Lors du traitement d'affectation des signataires, un type de niveau identique est donc affecté pour les signataires se trouvant au même niveau et pour les mêmes valeurs de critères de signatures. Le type de niveau est incrémenté avec des valeurs numériques de 1 en 1 allant jusqu'à 9999999999.
Les occurrences correspondantes du paramètre TNISAMSM sont alors créées automatiquement avec la valeur testée 1 égale à "U".

   Exemple : L'occurrence DYN du paramètre TNISAMSM avec la valeur testée 2 égale à "D". Les éléments, au niveau de la matrice pour la règle de signature RSIG1, sont définis tel que :
- Signataire U1, niveau 10 , type de niveau DYN, ensemble de critères 1
- Signataire U2, niveau 10 , type de niveau DYN, ensemble de critères 1
- Signataire U3, niveau 10 , type de niveau DYN, ensemble de critères 2
- Signataire U4, niveau 10 , type de niveau DYN, ensemble de critères 2
- Signataire U5, niveau 10 , type de niveau DYN, ensemble de critères 3
- Signataire U6, niveau 20 , type de niveau DYN, ensemble de critères 3
- Signataire U7, niveau 20 , type de niveau DYN, ensemble de critères 3
- Signataire U8, niveau 20 , type de niveau DYN, ensemble de critères 4

   Après affectation des signataires (TASMxx), les signataires seront affectés de la manière suivante :

   Ainsi, lors de la signature, si l'utilisateur U1 accepte, la signature n'est alors plus nécessaire pour l'utilisateur U2 et son statut est positionné à "Non requis" (NR).

   5) Ajout de la possibilité de sélectionner ou désélectionner tous les éléments à signer.

   Pour cela, ajout des boutons   :
- "Sélectionner tout" (champ SELECTALL) : permet de sélectionner tous les éléments à signer afin d'y affecter une action commune. La case "Sélectionner" est alors cochée pour tous les éléments à signer ;
- "Désélectionner tout" (champ DESELECATLL) : permet de désélectionner tous les éléments à signer pour lesquels la case "Sélectionner" est cochée.

   Ces boutons doivent être ajoutés par personnalisation. Ils sont disponibles pour tous les mnémoniques de signatures (GSMDA/GKSMDA, GSMCA/GKSMCA, GSMRA/GKSMRA, GSMFA/GKSMFA, GSMMA/GKSMMA).

   6) Lors d'une acceptation globale des factures, ajout de la possibilité de ne pas prendre en compte les factures à signer suite à un litige.

   Pour cela, ajout du bouton "Acceptation globale sans litige" (champ ACCEPT_ALL_SANS_LITIGE).
Ce bouton doit être ajouté par personnalisation, pour le mnémonique de signatures des factures (GSMFA/GKSMFA).

   NB : Cette possibilité est donnée uniquement pour les factures qui seront mises en litige après la mise en place de cette fonctionnalité.

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)
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)
CDSMA - Consultation des signatures multicritères (Transaction SACDSM)
GDSMMA - Détail des signatures multicritères des marchés (Transaction SAIDSMM)
GSMMA - Signatures multicritères des marchés (Transaction SAISMM)
CDSMMA - Consultation des signatures multicritères marchés (Transaction SACDSMM)
TPSMA - Purge des signatures multicritères (Transaction SATPSM)

   1) Ajout de la possibilité, à l'ouverture de la réception, de supprimer les éléments bloqués pour l'utilisateur connecté lorsque ses éléments sont bloqués, dans les tables de travail, au-delà d'un certain délai.

   2) Lors de la duplication d'une ligne de réception au niveau de la réception détail (SAIRDT, appelée en synchronisation des réceptions (GRCPA)), la ligne est créée en tant que nouvelle ligne de commande.

   1) Les données traitées par la réception sont enregistrées dans plusieurs tables intermédiaires :
- SARCP pour les données de la réception globale ;
- SARLG pour les lots et/ou emplacements de la réception globale ;
- SARDT pour les données du détail de la répartition de la réception.

   Il est possible, dans certains cas, que ces données soient bloquées dans ces tables alors que la génération d'une réception n'a pas été effectuée (exemple : coupure de courant, fermeture du navigateur en HTML5, ...). Pour pouvoir traiter ces données, il faut alors les supprimer des tables intermédiaires et faire à nouveau la sélection. Cette suppression peut être effectuée :
-   pour un utilisateur donné (utilisateur connecté et/ou autre utilisateur suivant la fourchette d'utilisateurs précisée) par la purge des tables de travail de la réception (GPRCP ou TPRCP) ;
- automatiquement, à l'ouverture de la gestion, pour l'utilisateur connecté. Les éléments bloqués ne peuvent être supprimés qu'au-delà d'un certain délai. Celui-ci est donné par la valeur 1 du paramètre AUTSADUB occurrence SARCP. Ce délai peut être exprimé en heures ou en minutes. Si la valeur testée 1 vaut :
           -   H : le délai est exprimé en heures,
           -   M : le délai est exprimé en minutes.
Si la valeur 1 n'est pas renseignée ou est égale à zéro, aucun déblocage n'est effectué ;
- automatiquement, à l'ouverture de la gestion, pour les données bloquées depuis la veille et appartenant à des utilisateurs autres que l'utilisateur connecté. Cette possibilité est donnée par la valeur 2 du paramètre AUTSADUB occurrence SARCP. Si la valeur testée 2 vaut :
           -   N : la suppression des éléments bloqués depuis la veille n'est pas effectuée,
           -   O : la suppression les éléments bloqués depuis la veille est effectuée.

   Si la valeur testée 1 n'est pas renseignée, elle est initialisée à "H" par la release.
Si la valeur testée 2 n'est pas renseignée, elle est initialisée à "N" par la release.

   2) Ceci est désormais possible pour les lignes réceptionnées en montant et pour les lignes réceptionnées en quantité si l'article de ces dernières n'est pas géré par lot et/ou emplacement.

GRCPA - Réception (Transaction SAIRCP)
SAIRDT - Réception détail (Transaction SAIRDT)
GPRCP - Purge des tables de travail de la réception (Transaction SAIPRC)
TPRCP - Purge des tables de travail de la réception (Transaction SATPRC)

   Dans le cadre de la comptabilité publique, lors de l'annulation d'une commande réceptionnée avec changement d'exercice comptable, possibilité d'annuler les mouvements relatifs à une charge (compte de classe 6) de l'écriture de facture non parvenue sur un compte particulier.

   Si l'année de la date d'annulation "potentielle" de l'écriture de facture non parvenue est différente de l'année de la date comptable de l'écriture de facture non parvenue, il est possible, selon la valeur testée 1 du paramètre AUTM9 occurrence CPTASF, d'effectuer l'annulation des mouvements relatifs à une charge (compte de classe 6) sur un compte particulier donné par cette même occurrence. Il s'agit d'un compte 7583x ou 110x selon si la société est soumis ou pas à l'impôt sur les sociétés.

   Si la valeur testée 1 vaut :
- O : la société est soumis à l'impôt sur les sociétés, l'annulation des mouvements relatifs à une charge (compte de classe 6) s'effectue avec le compte donné par la chaîne 1. De façon générale, il s'agit de comptes 7583x (Produits de gestion provenant de l'annulation de demandes de paiement des exercices antérieurs) devant être gérés en TVA facultative ;
- N : la société n'est pas soumis à l'impôt sur les sociétés, l'annulation des mouvements relatifs à une charge (compte de classe 6) s'effectue avec le compte donné par la chaîne 2. De façon générale, il s'agit de comptes 110x (Report à nouveau) devant être gérés en TVA facultative ;
- I : fonctionnalité inactive.

TACRA - Annulation d'une commande réceptionnée (Transaction SATACR)
TRSF - Commandes réceptionnées sans facture (Transaction SATRSF)

   Ajout de la possibilité de proposer la date comptable de la facture à partir de la date de réception facture.

   Pour cela, ajout de la valeur "RF" pour la valeur testée 2 de l'occurrence DECFAA du paramètre AUTSAFAA.

   Attention : il n'est pas possible de proposer à la fois la date de réception facture dans la date comptable et la date comptable dans la date de réception facture. Aussi, il est interdit d'avoir la valeur testée 2 de l'occurrence DECFAA du paramètre AUTSAFAA égale à "RF" si la valeur testée 2 de l'occurrence DRFFAA du paramètre AUTSAFAA est égale à "DF".

GFAA - Contrôle facture (Transaction SAIFAA)
GTFCA - Factures achats : Interface (Transaction SAITFC)
TTFCA - Intégration des factures d'achats (Transaction SATTFC)

   Dans le cas des établissements publics, il est désormais possible de gérer les statuts Chorus 04 et 05.

   1) Il est désormais possible de saisir manuellement les statuts Chorus 04 ou 05 dans la gestion des données brutes des factures achats à intégrer (GTFBA). Ceci n'est possible que si la facture n'a pas déjà été intégrée en exploitation (nuesatfb non renseigné).

   2) Lorsqu'une facture a été intégrée en exploitation et présente une erreur de montant par exemple, il est possible de la mettre en litige dans le contrôle facture (GFAA). Pour cela, il est nécessaire de détacher toutes les commandes de la facture puis de saisir un code litige pour lequel la chaîne 2 du paramètre LITSAFAA occurrence le code litige est renseignée et égale au statut 04 ou 05.

   3) Modification du traitement de génération des statuts des factures achats Chorus Pro (TSCPFA) pour prendre en compte le statut lié au code litige de la facture (chaîne 2 du paramètre LITSAFAA occurrence le code litige).

GTFBA - Factures achats à intégrer : données brutes (Transaction SAITFB)
GFAA - Contrôle facture (Transaction SAIFAA)
TSCPFA - Génér. des statuts des factures achats Chorus Pro (Transaction SATSCPFA)

   Ajout de la possibilité d'intégrer des QR-Codes SUISSES (GQRS) associés à la facture.

   Pour cela, il faut préciser le QR-Code dans la table d'interface des QR-Codes Suisses (ocqrt). Celui-ci est référencé pour :
- le numéro de facture (facocqrt) : numéro de facture à intégrer ;
- l'établissement (etsocqrt) : établissement de la facture à intégrer.

GTFCA - Factures achats : Interface (Transaction SAITFC)
GQRT - Sas des QR-Codes suisses (Transaction OCIQRT)
TTFCA - Intégration des factures d'achats (Transaction SATTFC)

   Lors de l'annulation d'une facture, ajout de la suppression des tâches collaboratives pour les signatures multicritères.

TAFAA - Annulation facture (Transaction SATAFA)

   Ajout du bouton permettant de générer un fichier ZIP regroupant tous les documents présents dans la grille.

CIDAA - Impression de documents attachés Achats (Transaction SACIDA)

   Correction pour éviter un message d'erreur intempestif lors de l'exécution d'une recherche lorsque la confidentialité est active.

GLMA - Liens des marchés (Transaction SAILMA)

   Correction pour ne pas avoir de message intempestif "SAREC001" (Réception inexistante ou non utilisable) lors de l'insertion d'une nouvelle réception si le mnémonique lié aux textes (GTXT) est ouvert via synchronisation ou présent dans un conteneur.

GREC - Contrôle des réceptions (Transaction SAIREC)
GTXT - Textes (Transaction SAITXT)

   1) Lors de la création d'une ligne de réception en montant, ne pas proposer l'unité de prix et affectation du prix réceptionné, du prix tarif et du prix commandé égaux au montant réceptionné saisi par l'utilisateur.

   2) Correction pour ne plus décocher de manière intempestive la case à cocher "Arrêt" lors d'un changement d'enregistrement dans la grille.

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

   Lors de l'intégration d'un avoir :
- si le montant des avoirs est non signé dans le fichier Chorus, les montants de l'en-tête de facture sont passés en négatif pour être en phase avec les lignes de la facture ;
- si l'information IdFactureOrigine n'est pas renseignée pour l'avoir, l'insertion de cette facture dans le SAS n'est plus bloquée mais celle-ci est intégrée sans le suivi des factures (SAITSF).

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

   Correction pour afficher le bon titulaire du marché dans le cas où le marché ne possède pas de complément de marchés de type cession et que plusieurs marchés sont édités.

EMBCA - Suivi des marchés publics à bons de commande (Transaction SAEMBC)

   Correction pour ne pas réaffecter l'origine des délégations des signatures multicritères lors de l'exécution du traitement de duplication d'établissements (TCDETS).

TCDETS - Module Référentiels - Duplication établissements (Transaction MITCDE)
GGSMA - Délégations des signatures multicritères (Transaction SAIGSM)

   Correction afin de supprimer les éléments en cours de signature bloqués dans la table de travail lors des traitements d'annulation ou de retour à l'étape.

TREIMA - Retour à l'étape initiale pour les marchés (Transaction SATEIM)
GMARA - Marchés (Transaction SAIMAR)
TANU - Retour à l'étape initiale (Transaction SATANU)
GDAI - Demandes d'achats (Transaction SAIDAE)
GDAI - Demandes d'achats (Transaction SAICDA)
TSRD - Annulation de demandes d'achats ou de commandes (Transaction SATSRD)
GREC - Contrôle des réceptions (Transaction SAIREC)
TACRA - Annulation d'une commande réceptionnée (Transaction SATCRA)
TRSF - Commandes réceptionnées sans facture (Transaction SATRSF)
GFAA - Contrôle facture (Transaction SAIFAA)
TAFAA - Annulation facture (Transaction SATAFA)

   Correction de la quantité des fiches d'immobilisation issues d'une ligne d'une sous-commande solde facture, réceptionnable en montant : la quantité de ces fiches d'immobilisation est dorénavant égale à 0 afin que la somme des quantités, côté immobilisation, reste à 1.

GAMIMP - Immobilisations provisoires (Transaction AMIIMP)

   Ajout de nouvelles fonctionnalités permettant :
- de générer les commandes d'acomptes selon l'étape de la commande origine ;
- d'effectuer le contrôle des montants selon une fourchette d'étapes ;
- d'exécuter les traitements sur la commande d'acompte créée dès la génération de celle-ci ;
- de pouvoir associer manuellement une commande origine avec une commande d'acompte.

   1) Ajout des informations suivantes au niveau du paramétrage de la génération des demandes d'acomptes (GPACA) :
- fourchette d'étapes de contrôle : cette fourchette d'étapes est utilisée pour :
       - le contrôle d'interdiction de génération d'acompte si aucune sous-commande de la commande origine n'est à une étape comprise entre ces étapes,
       - le contrôle montant selon étapes,
       - le contrôle de suppression des associations entre commande origine et commande d'acompte ;
- contrôle montant selon étapes : si cette case est cochée, il est contrôlé, au traitement de contrôle des montants d'acompte (TCMACA), que le montant des acomptes disponibles ne dépasse pas la somme des sous-commandes origines en cours ;
- contrôle suppression des liens : permet d'indiquer comment est effectué le contrôle de suppression d'une association (suppression logique) entre une commande origine et une commande d'acompte :
       - B : le contrôle est effectué et est bloquant s'il existe une commande origine dont l'étape est comprise dans la fourchette d'étapes de contrôle,
       - S : le contrôle est effectué et n'est pas bloquant s'il existe une commande origine dont l'étape est comprise dans la fourchette d'étapes de contrôle,
       - R : le contrôle n'est pas effectué ;
-   envoi des traitements : si cette case est cochée, les traitements correspondant aux étapes par classe (GETCA) définis pour la classe d'achats de la commande d'acompte générée, sont exécutés lors de la génération de la commande d'acompte.

   2) Génération de la commande d'acompte (bouton "Génération acompte" dans GCDA) :
- contrôle que la génération de la commande d'acompte n'est possible que si l'étape d'au moins une des sous-commandes de la commande à l'origine de l'acompte est comprise entre les étapes de la fourchette d'étapes de contrôle du paramétrage du type de demande d'acompte ;
- selon la case "Envoi des traitements" du paramétrage du type de demande d'acompte, les traitements correspondant aux étapes par classe (GETCA), définis pour la classe d'achats de la commande d'acompte générée, sont exécutés pour la commande d'acompte générée.

   3) Contrôle des montants d'acompte (TCMACA) :
Contrôle que le montant des acomptes disponibles ne dépasse pas un certain pourcentage de la somme des montants des sous-commandes origines en cours. Ce contrôle est effectué ou pas selon l'information "Contrôle montant selon étapes" donnée par le type de demande d'acompte ayant permis la génération de la commande d'acompte.
Si les acomptes sont facturés et transférés en comptabilité, le montant pris en compte est le solde de la pièce d'acompte sinon, le montant 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.
Pour les sous-commandes origine dont l'étape est comprise dans la fourchette d'étapes donnée par le type de demande d'acompte, le montant pris 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.

   4) Association commandes et acomptes (GASCACA) :
Nouvelle gestion permettant, selon certaines conditions, de pouvoir saisir une association manuellement entre une commande origine et une commande d'acompte.
Pour cela, il ne doit pas y avoir une autre association, à l'état "Actif', pour cette commande d'acompte et une autre commande origine. S'il en existe une, il est nécessaire de la mettre à l'état "Supprimé" (suppression logique). Selon le paramétrage du type de demande d'acompte, la suppression de cette association (suppression logique) peut être contrôlée ou non et le contrôle peut être bloquant ou signalé : si l'étape d'une des sous-commandes origine est comprise dans la fourchette d'étapes de contrôle, alors message d'alerte ou bloquant selon le paramétrage.
De plus, pour pouvoir supprimer cette association, il ne doit pas exister une récupération d'acompte (SAIRAA), non traitée, pour la commande d'origine.

   A la saisie de l'association entre la commande origine et la commande d'acompte, différents contrôles sont effectués :
- la classe d'achats de la commande d'acompte doit être une classe de commandes. Aucune mise à jour marché ne doit être précisée c'est à dire qu'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 ;
- la commande d'acompte ne doit avoir qu'une seule ligne de commande ;
- l'article de la ligne d'acompte doit correspondre à l'article donné par le paramétrage du type de demande d'acompte ;
- le compte (GCPT) de la ligne d'acompte doit être un compte 409xxxx défini en génération de pièce obligatoire et en TVA interdite ;
- le taux du code TVA de la ligne d'acompte doit être égal à zéro ;
- l'étape de la commande origine doit être inférieure à la valeur 1 du paramètre AUTACHAT occurrence ETPANUxxxx où xxxx représente la classe d'achats de la commande origine ;
- les contrôles de montants sont effectués à l'identique du traitement de contrôle des montants d'acompte (TCMACA).

   Afin de différencier les associations créées automatiquement lors de la génération d'un acompte à partir d'une commande origine et les associations créées manuellement dans cette gestion, les associations sont identifiées par l'information "Type de lien d'acompte" :
- G : associations créées automatiquement ;
- S : associations saisies manuellement.

   Aucune information des associations, mise à part l'état, n'est accessible et modifiable par l'utilisateur.

GPACA - Paramétrage des demandes d'acomptes (Transaction SAIPAC)
GCDA - Commandes d'achats (Transaction SAICDA)
TCMACA - Contrôle des montants d'acompte (Transaction SATCMAC)
GASCACA - Association commandes et acomptes (Transaction SAIASCAC)
CASCACA - Consultation associations commandes et acomptes (Transaction SACASCAC)

   Ajout de la prise en compte des validités des structures (GTDTE) lors de l'intégration dans les tables d'exploitation.

   Ajout de la prise en compte des validités des structures (GTDTE) lors de l'intégration dans les tables d'exploitation.

   Ajout de la prise en compte des validités des structures (GTDTE) lors de l'intégration dans les tables d'exploitation.

   Ajout des colonnes :
TLASAACA - Type de lien d'acompte (Obligatoire)
ETASAACA - Etat (Obligatoire)
UDMSAACA - Utilisateur de modification
DDMSAACA - Date de modification

   Ajout des colonnes :
MSMSADSM - Numéro interne de la matrice
NUASADSM - Numéro d'avis

   Ajout des colonnes :
ECDSAPAC - Etape de contrôle début (Obligatoire)
ECFSAPAC - Etape de contrôle fin (Obligatoire)
CMESAPAC - Contrôle montant selon étapes (Obligatoire)
CSLSAPAC - Contrôle suppression des liens (Obligatoire)
TRTSAPAC - Envoi des traitements (Obligatoire)

   Ajout des colonnes :
HRXSARCP - Heure de création (Obligatoire)
TRXSARCP - Date et heure de création