Document de release de la version I1.01

   Ce document présente les évolutions survenues sur l'application Cegid XRP Ultimate Achats en I1.01.

      Afficher / Masquer le détail                                                   Format PDF

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

   Pour cela, création d'un traitement par étape, situé après la confirmation des commandes (TCDA), qui va contrôler qu'il n'existe pas une autre commande dans une plage de dates définies, pour le même établissement, le même fournisseur et le même montant TTC, une tolérance pouvant être appliqué sur le montant.

TUCDA - Contrôle de l'unicité d'une commande (Transaction SATUCD)

   Ce traitement doit être situé, dans les étapes par classe (GETCA), après la confirmation des commandes (TCDA) et doit être défini comme suit :
- mnémonique d'appel : TUCDA ;
- traitement associé : SATUCD ;
- traitement par commande : pssaucdetp ;
- traitement par autre entité : pssaucdetp.

   De plus, les occurrences suivantes du paramètre AUTSAUCD doivent être définies :

   a) occurrence CTLUNI

   La valeur testée 1 indique le type de contrôle. Si la valeur testée 1 vaut :
     - B : le contrôle est bloquant ;
     - S : le contrôle est signalé ;
     - R : le contrôle n'est pas effectué.
La valeur testée 1 est livrée à "R" par la release.

   La valeur testée 2 donne la date à partir de laquelle est calculée la période. Si la valeur testée 2 vaut :
     - C : date de commande ;
     - CO : date de contrat ;
     - CR : date de création ;
     - DC : date comptable ;
     - RD : date au plus tôt ;
     - RF : date au plus tard.

   Le texte indique le nombre de jours à appliquer à la date pour calculer la période.

   La valeur 1 indique le niveau de tolérance, en pourcentage, à appliquer au montant TTC.
La valeur 2 indique le niveau de tolérance, en montant, à appliquer au montant TTC. Il est exprimé en devise de référence.

   La valeur testée 2, la valeur 1, la valeur 2 et le texte ne sont pas renseignés par la release.

   b) occurrence ETP-xxxx (où xxxx représente la classe d'achats)
La valeur 1 donne l'étape maximale à laquelle doivent être les commandes à contrôler. Cette étape doit correspondre à une étape avant réception et avant facturation.

   Pour cela, création du traitement de visualisation des documents associés (TVTDO) qui permet, via le navigateur internet, de visualiser les fichiers présents dans le sas des documents associés (SAITDO) qui n'ont pas encore été intégrés en base (TCDOC).
Les fichiers doivent être présents dans le répertoire du serveur de traitements, là où sont placées les images associées aux documents à transférer.
Les erreurs qui surviennent lors de l'exécution du traitement sont visibles, à partir de la consultation des travaux (CJOB), dans le compte rendu des anomalies (GTCJCRA).

TVTDO - Visualisation des documents associés (Transaction SATVTDO)

   Pour cela, création d'un traitement qui permet de transférer un document basé, présent dans les documents associés aux factures à intégrer (SAITDD), en un document centralisé associé à la facture (GFAA).
Ce traitement peut être systématisé à une fréquence équivalente à celle de la réception des données dans le sas des données brutes (GTFBA).

TTDDA - Intégr. des documents associés aux factures (Transaction SATTDD)

   Prérequis :
- ne peuvent être traité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 facture ;
- l'association entre l'entité de documents et le type de documents (GTDAE) doit être définie ;
- la variable globale URLQWS doit être définie, dans GGLO, en tant que WebService REST ;
- si dans le chemin qui est spécifié dans le type de documents (GTDTY), une ou plusieurs variables sont utilisées afin d'avoir des sous-répertoires dynamiques, il est nécessaire de créer les occurrence GEDx du paramètre AUTSAFAA (où x représente un nombre de 1 à 5 correspondant au nombre de variables utilisées). Ces occurrences vont permettre de remplacer les variables par le contenu du champ correspondant aux factures :
          - la chaîne 1 doit contenir le nom de la variable sans le '$',
          - la chaîne 2 doit contenir le nom de la colonne correspondante de la table SAFAA,
          - le texte permet de gérer le format des dates (YYYY : année sur 4 caractères, YY : année sur 2 caractères, MM : mois sur 2 caractères, DD : jour sur 2 caractères). Si le texte n'est pas renseigné, le format standard est appliqué.

   Exemple 1 :
Chemin du type de documents : \\serveur\ged\$NUMSAFOU\

   Occurrence GED1 du paramètre AUTSAFAA avec :
- chaîne 1 = NUMSAFOU ;
- chaîne 2 = fousafaa ;
- texte non renseigné.

   Exemple 2 :
Chemin du type de documents : \\serveur\ged\$NUMSAFOU\$DATEF\

   Occurrence GED1 du paramètre AUTSAFAA avec :
- chaîne 1 = NUMSAFOU ;
- chaîne 2 = fousafaa ;
- texte non renseigné.

   Occurrence GED2 du paramètre AUTSAFAA avec :
- chaîne 1 = DATEF ;
- chaîne 2 = datsafaa;
- texte = YYYY-MM-DD.

   Pour cela, création d'un traitement qui permet de purger les données des factures présentes dans le sas des données brutes des factures (GTFBA).
La sélection des données à purger est faite à partir du numéro de facture d'exploitation, en prenant en compte le statut Chorus ainsi que la date de modification de celui-ci.

TPFBA - Purge du sas des données brutes de factures (Transaction SATPFBA)

   Il est dorénavant possible de pouvoir télécharger les documents officiels depuis Cegid XRP Ultimate sans passer par la fiche fournisseur.

   Pour cela, ajout de trois boutons permettant de télécharger :
- l'extrait KBIS du fournisseur ;
- la déclaration URSSAF du fournisseur ;
- la déclaration LNTE du fournisseur.

   Pour bénéficier de cette possibilité, lors de l'abonnement au WebService Provigis, il faut prendre un abonnement étendu (niveau 3).

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

   Dans le cas où le mode de taxe est proposé à partir d'une clé de répartition (GCRC), modification afin de pouvoir gérer des modes de taxe sur plus de deux caractères.

   Si le mode de taxe est géré sur plus de deux caractères, il est nécessaire de mettre celui-ci, non pas directement dans la nature de la clé de répartition, mais dans la chaîne 1 de l'occurrence correspondant à la nature de la clé de répartition.

GVCMA - Ventilations par CGR des marchés (Transaction SAIVCM)
GVCG - Ventilations par CGR (Transaction SAIVCG)

   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 la référence fournisseur et/ou la référence fabricant.

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

   - RFO pour la référence fournisseur. Si la valeur du paramètre vaut :
         - O : la référence fournisseur de la ligne de demande d'achats est re-proposée lors de la modification du code article,
         - N : la référence fournisseur de la ligne de demande d'achats n'est pas re-proposée lors de la modification du code article ;

   - RFB pour la référence fabricant. Si la valeur du paramètre vaut :
         - O : la référence fabricant de la ligne de demande d'achats est re-proposée lors de la modification du code article,
         - N : la référence fabricant de la ligne de demande d'achats n'est pas re-proposée lors de la modification du code article.

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

   Ajout de la possibilité de laisser en attente les lignes de demandes de services pour lesquelles le mode d'achat est défini en sortie de stock facultative lorsque la quantité en stock n'est pas suffisante pour les honorer.

   Le mode d'achat de ces lignes n'est pas modifié pour être remplacé par un mode d'achat défini en sortie de stock interdite.
Un éclatement a lieu entre les lignes pour lesquelles le stock est suffisant et celles sans stock.
Les lignes pour lesquelles le stock est suffisant se retrouvent sur une sous-commande qui passe à l'étape du traitement TEDA. Cette sous-commande pourra ensuite passer le traitement de réservation en stock TRDS.
Les lignes sans stock se retrouvent sur une sous-commande qui reste en attente, à l'étape avant le traitement TEDA, jusqu'à ce que le stock soit disponible.

   Cette possibilité est donnée par l'occurrence STOCKDISPO du paramètre AUTSASCA.
Si la valeur testée 1 vaut :
- O : les lignes pour lesquelles le mode d'achat est défini en sortie de stock facultative et qui ne peuvent pas être honorées restent en attente ;
- N : les lignes pour lesquelles le mode d'achat est défini en sortie de stock facultative et qui ne peuvent pas être honorées ne restent pas en attente. Le mode d'achat de ces lignes est remplacé par un mode d'achat en sortie de stock interdite. Ainsi, ces lignes feront l'objet d'une commande (fonctionnement actuel).

   La valeur testée 1 de cette occurrence a été initialisée à "N" par la release.

   Exemple :

   3 modes d'achat :
- SSF : sortie de stock facultative ;
- SSO : sortie de stock obligatoire ;
- SSI : sortie de stock interdite.

   Création de la demande de services DA 10 1 :
          Ligne 10 : Article ART1 Mode d'achat SSF Quantité demandée 100 Quantité en stock 100
          Ligne 20 : Article ART2 Mode d'achat SSF Quantité demandée 150 Quantité en stock 0
          Ligne 30 : Article ART3 Mode d'achat SSF Quantité demandée 200 Quantité en stock 120

   Une fois le traitement TEDA passé, on obtient :

   a) Si la valeur testée 1 vaut « O » :

   Demande de services DA 10 1. Cette demande est à l'étape du traitement TEDA :
          Ligne 10 : Article ART1 Mode d'achat SSO Quantité demandée 100
          Ligne 30 : Article ART3 Mode d'achat SSO Quantité demandée 120

   Demande de services DA 10 2. Cette demande est générée à l'étape avant le traitement TEDA :
          Ligne 20 : Article ART2 Mode d'achat SSF Quantité demandée 150
          Ligne 30 : Article ART3 Mode d'achat SSF Quantité demandée 80

   b) Si la valeur testée 1 vaut « N » :

   Demande de services DA 10 1. Cette demande est à l'étape du traitement TEDA :
          Ligne 10 : Article ART1 Mode d'achat SSO Quantité demandée 100
          Ligne 30 : Article ART3 Mode d'achat SSO Quantité demandée 120

   Demande de services DA 10 2. Cette demande est à l'étape du traitement TEDA :
          Ligne 20 : Article ART2 Mode d'achat SSI Quantité demandée 150
          Ligne 30 : Article ART3 Mode d'achat SSI Quantité demandée 80

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

   1) Lors de l'intégration d'une ligne de demande d'achats ou de commande, si l'article de la ligne à intégrer est défini en génération composé/composant et si la classe de transfert (GTNC) est paramétrée pour créer les lignes de demandes d'achats ou de commandes correspondantes à l'article composant, il est désormais possible de copier l'unité fonctionnelle de la ligne du composé sur la ligne du composant.

   2) Amélioration du compte rendu.

   1) Pour cela, ajout du champ "Recopie unité fonctionnelle interne" dans la gestion des classes de transfert (GTNC).

   2) Pour cela :

   - ajout des informations suivantes permettant de mieux identifier la demande d'achats ou la commande du sas qui est traitée : classe, numéro, numéro interne, fournisseur ;

   - ajout d'un bouton de choix permettant de définir le type de compte rendu souhaité :
          - Erreurs : permet d'éditer les demandes d'achats ou commandes en erreur lors de l'intégration et un récapitulatif (nombre de demandes d'achats ou de commandes intégrées, nombre de demandes d'achats ou de commande en erreur et le nombre total de demandes d'achats ou de commandes traitées),
          - Global : permet d'éditer uniquement un récapitulatif (nombre de demandes d'achats ou de commandes intégrées, nombre de demandes d'achats ou de commande en erreur et le nombre total de demandes d'achats ou de commandes traitées),
          - Détaillé : permet d'éditer les demandes d'achats ou commandes qui sont intégrées, les demandes d'achats ou commandes qui sont en erreur lors de l'intégration et un récapitulatif (nombre de demandes d'achats ou de commandes intégrées, nombre de demandes d'achats ou de commande en erreur et le nombre total de demandes d'achats ou de commandes traitées).

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

   Ajout de la possibilité, à l'ouverture de la gestion de génération des commandes à partir des demandes d'achats (GTDAC, TDAI), de supprimer les éléments bloqués pour l'utilisateur connecté lorsque ces é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 (GTDAC,TDAI) 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.

   Il est désormais possible, à l'ouverture de la gestion de génération des commandes à partir des demandes d'achats (GTDAC, TDAI), de supprimer les éléments bloqués pour l'utilisateur connecté lorsque ces éléments sont bloqués au-delà d'un certain délai. Celui-ci est donné par la valeur 1 du paramètre AUTSADUB occurrence SADAI. Cette valeur est exprimée en heures.

   Si la valeur 1 n'est pas renseignée ou est égale à zéro, aucun déblocage n'est effectué.

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

   Ajout de la possibilité, à partir des ventilations par CGR d'une ligne de demande d'achats, de commande, de réception ou de facture, de modifier toutes les ventilations par CGR des autres lignes de la demande d'achats, de la commande, de la réception ou de la facture.

   Pour cela, ajout du bouton "Appliquer sur les autres lignes". Il est accessible uniquement pour les ventilations par CGR associées à une ligne de demande d'achats, de commande, de réception et/ou de facture.
Il a pour action de :
- supprimer toutes les ventilations par CGR sur les lignes autres que la ligne courante et de les recréer à l'identique à partir des ventilations par CGR de cette ligne ;
- mettre à blanc le CGR des lignes pour lesquelles il est renseigné.

GVCG - Ventilations par CGR (Transaction SAIVCG)

   Lors de la valorisation d'une commande, si le Franco de port ou l'application d'une condition de facturation est contrôlé, ajout de la possibilité d'afficher le message correspondant au contrôle effectué que jusqu'à une certaine étape.

   L'étape de la commande est prise en compte uniquement dans le cas où le contrôle est effectué avec affichage d'un message d'alerte.

   Franco de port
L'étape est donnée par la valeur 1 du paramètre AUTSACDA occurrence FRANCO.
Si la valeur 1 est renseignée et si la valeur testée 1 est égale à "S" alors le message correspondant au contrôle effectué est affiché jusqu'à ce que la commande est atteint l'étape donnée par la valeur 1.
Si la valeur 1 n'est pas renseignée ou si la valeur testée 1 est égale à "B" alors le message correspondant au contrôle effectué est affiché quelle que soit l'étape de la commande.

   Contrôle d'application d'une condition de facturation
L'étape est donnée par la valeur 1 du paramètre AUTSACDA occurrence CAFxxxx où xxxx représente le numéro de la condition de facturation à contrôler.
Si la valeur 1 est renseignée et si la valeur testée 1 est égale à "S" alors le message correspondant au contrôle effectué est affiché jusqu'à ce que la commande est atteint l'étape donnée par la valeur 1.
Si la valeur 1 n'est pas renseignée ou si la valeur testée 1 est égale à "B" alors le message correspondant au contrôle effectué est affiché quelle que soit l'étape de la commande.

GCDA - Commandes d'achats (Transaction SAICDA)

   Ajout de la possibilité de sélectionner les demandes d'achats ou les commandes à partir de certaines informations des classes d'achats.

   Pour cela, ajout d'une nouvelle forme sélection sur les classes d'achats, permettant :
- de sélectionner les demandes d'achats ou les commandes en fonction du type, de la nature, du genre et/ou du rôle de la classe d'achats ;
- d'exclure des classes de la sélection.

CSNCA - Sélection des classes (Transaction SACSNCA)
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é, lors de la recherche, de sélectionner les lignes de demandes d'achats ou de commandes pour lesquelles l'article appartient à une liste d'articles achetés (GLAEA).

   Pour cela, ajout de la liste d'articles achetés dans les critères de recherche.

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

   Dans le cas de la comptabilité publique et des évolutions GBCP, lors de l'annulation d'une commande réceptionnée (TACRA), prise en compte qu'un retrait d'engagement a été réalisé lors d'une précédente annulation de commande réceptionnée.

   Si la valeur testée 2 du paramètre AUTM9 occurrence RETENG est égale à "O", l'année de la date d'annulation "potentielle" de l'écriture d'engagement est identique à l'année de la date comptable et le type d'écriture de l'engagement à annuler correspond au type d'écriture donné par la chaîne 2 du paramètre AUTM9 occurrence RETENG, alors :
- l'écriture d'engagement (TVCCE) de la commande est annulée en comptabilité mais sur un journal et un type d'écriture particuliers. Ces derniers sont donnés respectivement par le texte et la chaîne 2 du paramètre AUTM9 occurrence RETENG ;
- la sous-commande en attente de réception est ré-engagée en comptabilité, en date logique, sur le journal et le type d'écriture donnés respectivement par le texte et la chaîne 2 du paramètre AUTM9 occurrence RETENG. Cette écriture permet d'avoir un engagement mais sans impact sur les budgets.

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

   Ajout de la possibilité de mettre à la poubelle la sous-commande générée en attente de réception.

   Pour cela, les cases à cocher "Abandon de la sous-commande générée en attente de réception" et "Libération des lignes de marchés" ont été rajoutées à la soumission.

   La case à cocher "Abandon de la sous-commande générée en attente de réception" permet de lancer automatiquement le traitement d'annulation de demandes d'achats ou de commandes (TSRD) sur la nouvelle sous-commande générée.

   Si la case "Libération des lignes de marchés" est cochée, lors de la mise à la poubelle de la commande d'achats, le numéro de commande est effacé au niveau de la ligne de marché afin que celle-ci puisse permettre la génération d'une nouvelle demande ou commande. De plus, si la classe de marchés, est définie, pour le type de ligne concerné, en génération d'avenant, la classe et le numéro de demande ou de commande sont mémorisés au niveau de la ligne de marché, afin de permettre la génération d'une nouvelle sous-demande ou sous-commande au lieu d'une nouvelle demande ou commande.

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

   Si une liste de commandes est précisée à la soumission, les commandes directes générées lors de l'intégration des réceptions ou lors de l'intégration des factures sont désormais insérées dans cette liste.

TTREA - Intégration des réceptions (Transaction SATTRE)
TTFCA - Intégration des factures d'achats (Transaction SATTFC)

   1) Ajout de la case à cocher "Facturation globale" permettant à l'utilisateur d'effectuer une facturation des lignes des commandes rattachées à la facture. Elle n'est accessible que si la facturation s'effectue en une seule étape (GFAA).

   2) Ajout de zones supplémentaires de la facture pouvant être modifiées même si celle-ci est transférée en comptabilité.

   3) Il est désormais possible d'interdire la modification des informations de l'en-tête d'une facture dans le cas où une des commandes rattachées à cette facture a atteint l'étape maximale autorisée. Cette étape est donnée par la valeur 2 du paramètre AUTSAFAA occurrence FAAMAJ.
Sont exclues de ce contrôle les informations de l'en-tête de facture qu'il est possible de modifier même si la facture est transférée en comptabilité (TVCC).

   4) Ajout de la possibilité, en création de lignes pour une facture qui concerne un marché (facturation directe ou ajout de lignes en facture) :
- de contrôler l'appartenance de l'article au marché de la facture ;
- d'effectuer les contrôles de dépassement de quantités et/ou de montants lors de la mise à jour de l'encours du marché.

   1) Si les informations classe, numéro et, éventuellement sous-numéro, sont renseignées et que la case "Facturation globale" est cochée, les lignes de commandes sont facturées lors de la création de l'en-tête de facture et du rattachement des commandes :
- la quantité facturée est renseignée égale à la quantité réceptionnée si celle-ci est renseignée, sinon à la quantité commandée ;
- le prix facturé est renseigné égal au prix réceptionné si celui-ci est renseigné, sinon au prix commandé ;
- le montant facturé est calculé : il est égal à la quantité facturée multiplié par le prix facturé et l'unité de prix.

   Si la case n'est pas cochée, les lignes de commandes ne sont pas facturées lors du rattachement des commandes à la facture. Pour les facturer, utilisez la gestion des lignes à facturer (SAIFLC).

   2) Chacune des nouvelles zones modifiables est paramétrée. Les occurrences suivantes du paramètre SAMAJTRF correspondent aux nouvelles zones modifiables de la facture :
- L01SAFAA : libellé 1 ;
- L02SAFAA : libellé 2 ;
- L03SAFAA : libellé 3 ;
- L04SAFAA : libellé 4 ;
- L05SAFAA : libellé 5 ;
- G01SAFAA : identifiant 1 ;
- G02SAFAA : identifiant 2 ;
- G03SAFAA : identifiant 3 ;
- G04SAFAA : identifiant 4 ;
- G05SAFAA : identifiant 5 ;
- DA1SAFAA : date 1 ;
- DA2SAFAA : date 2 ;
- DA3SAFAA : date 3 ;
- NU1SAFAA : numérique 1 ;
- NU2SAFAA : numérique 2 ;
- NU3SAFAA : numérique 3.
Si la valeur testée 1 de l'occurrence vaut :
- O : la modification de la zone est autorisée ;
- N : la modification de la zone est interdite.
Pour chaque occurrence, la valeur testée 1 est initialisée à "N" par la release.

   4) Lors de la création d'une ligne pour une facture qui concerne un marché (facturation directe ou ajout de lignes en facture), si le mode d'achat (GMDA) de la ligne de facture a une influence sur les marchés alors le contrôle d'appartenance de l'article au marché est effectué selon la chaîne 1 du paramètre AUTSAFAA occurrence CTLMARxxxx où xxxx représente la classe de commandes.
Si la chaîne 1 vaut :
- O : le contrôle d'appartenance de l'article au marché est effectué en fonction du paramétrage de la classe de commandes (GNCA) ;
- N : le contrôle d'appartenance de l'article au marché n'est pas effectué.

   De plus, dans le cas où l'encours du marché est mis à jour, il est désormais possible d'effectuer les contrôles de dépassement de quantités et/ou de montants selon la valeur testée 1 du paramètre AUTSAFAA occurrence CTLMARxxxx où xxxx représente la classe de commandes.
Si la valeur testée 1 vaut :
- O : les contrôles de dépassement des quantités et/ou des montants du marché sont effectués lors de la mise à jour de l'encours du marché en fonction du paramétrage de ce dernier ;
- N : les contrôles de dépassement des quantités et/ou des montants du marché ne sont pas effectués lors de la mise à jour de l'encours.

   Si l'occurrence n'existe pas pour la classe, les contrôles d'appartenance et de dépassement ne sont pas effectués. Si vous voulez mettre en place ces contrôles, vous devez définir ces occurrences (GPAR) pour les classes concernées.

GFAA - Contrôle facture (Transaction SAIFAA)
SAILCF - Lignes de facture (Transaction SAILCF)

   1) Lors du transfert en comptabilité des factures (TVCC), ajout de la possibilité d'alimenter l'information des pièces et, éventuellement, le libellé complémentaire des mouvements.

   2) Lors de l'annulation d'une écriture, si les dates 1 et 2 des mouvements de l'écriture d'engagement ou de FNP ont été alimentées avec les dates 1, 2 ou 3 des lignes de commandes, alors les dates 1 et 2 des mouvements de l'écriture d'annulation correspondantes sont alimentées avec les mêmes valeurs.

   Le même principe est appliqué pour les identifiants longs 1, 2, 3, 4 et 5 des mouvements ainsi que pour les numériques 1 et 2.

   1) Pour cela, la gestion de paramétrage du transfert en comptabilité (GTVCA) a été modifiée afin d'ajouter des zones permettant de paramétrer l'alimentation de l'information des pièces. Ces zones ont été ajoutées sur la forme détail "Compléments".
L'information des pièces peut être alimentée avec le libellé de la facture, l'information de la facture, les libellés 1, 2, 3, 4 et 5 de la facture.
En fonction du paramètre AUTCPT occurrence INFECT, les 60 premiers caractères de la zone "information" peuvent être repris dans le libellé complémentaire des mouvements.

   2) Pour cela, lors du transfert en comptabilité, les identifiants 1, 2, 3, 4 et 5, les numériques 1, 2 et 3 et les dates 1, 2 et 3 des lignes de commandes sont conservés, respectivement, dans les identifiants 1, 2, 3, 4 et 5, les numériques 1, 2 et 3 et les dates 1, 2 et 3 des lignes des ventilations comptables.

GTVCA - Paramétrage transfert comptabilité achat (Transaction SAITVC)
TVCC - Comptabilisation des factures (Transaction SATVCC)
CVCC - Consultation des ventilations comptables achats (Transaction SACVCC)

   1) Possibilité d'effectuer un "Refus pour détacher" (RD) pour les factures directes.

   2) Possibilité d'effacer ou pas la référence de la facture lors de l'action "Refuser pour détacher" (RD).

   3) Possibilité d'effectuer la suppression logique de la facture lors de l'action "Refuser pour détacher" (RD).

   4) Possibilité de ne pas prendre en compte les signataires ayant déjà validés en commande.

   1) Possibilité d'effectuer un "Refus pour détacher" (RD) pour les factures directes :
Lors de l'action "Refuser pour détacher" pour une facture directe, il est désormais possible de mettre à une étape "poubelle" les commandes de la facture. L'étape d'annulation à laquelle sont mises les commandes de la facture directe est donnée par l'étape alternative de refus, paramétrée dans les actions des signataires (GASMA), pour l'action "RD" (Refus pour détacher). Elle doit être définie, dans les étapes par classe (GETCA), de la classe de facturation directe et doit correspondre à une étape d'annulation de commandes (TSRD).
Dans le cas où l'étape alternative de refus n'est pas renseignée pour l'action "RD", il n'est pas possible d'effectuer un refus pour détacher lors de la signature d'une facture directe.

   Lors du refus pour détacher, plusieurs actions sont effectuées :
- si la facture directe est concernée par un flux de dépenses sans engagement préalable et qu'une écriture de facture extra-comptable (TVCCx) a été générée précédemment pour la facture, cette écriture est supprimée ;
- si la facture directe est une facture de co-traitance ou de sous-traitance et que la mise à jour des montants co-traitants/sous-traitants (TMCSA) a été effectuée, alors celle-ci est annulée ;
- si la facture directe concerne un marché, l'encours du marché (GMARA) et de la ligne de marché (GMADA) sont mis à jour en fonction du paramétrage de la classe d'achats (GNCA) ;
- s'il existe des fiches d'immobilisations pour les lignes de la facture directe, elles sont supprimées ;
- s'il existe des co-traitants/sous-traitants (SAICSF) non traités pour les lignes de la facture, ils sont supprimés ;
- s'il existe des récupérations d'avances (SAIRAA) non traitées pour les lignes de la facture, elles sont annulées ;
- les détails de signatures sont supprimés ou historisés selon le paramètre AUTACHAT occurrence SUPSIG.

   Il n'est pas possible d'effectuer l'action "Refuser pour détacher" pour une facture directe si :
- des co-traitants/sous-traitants (SAICSF) interviennent pour la facture et que le traitement de génération de factures de co/sous-traitance (TGFCSA) a été effectué ;
- il existe au moins une récupération d'acompte créée pour la facture par le traitement de création des récupérations d'acompte (TCRACA) ;
- la facture a généré une récupération d'avance (TRAA) ou une récupération d'acompte (TRACA) ;
- la facture est transférée en comptabilité (TVCC).

   2) Possibilité d'effacer ou pas la référence de la facture lors de l'action "Refuser pour détacher" (RD) :
Pour cela, ajout d'une case à cocher "Effacement référence facture" au niveau des actions des signatures (GASMA).

   Lors de l'action "Refuser pour détacher", si la case "Effacement référence facture" est cochée, la référence de la facture est effacée, sinon elle est conservée.

   Cette case a été initialisée à "Cochée" pour l'action "Refuser pour détacher" (RD) par la release.

   3) Possibilité d'effectuer la suppression logique de la facture lors de l'action "Refuser pour détacher" (RD) :
Pour cela, ajout d'une case à cocher "Suppression logique facture" au niveau des actions des signatures (GASMA).

   Lors de l'action "Refuser pour détacher", si la case "Suppression logique facture" est cochée, la facture est supprimée de façon logique par un passage de l'état à la valeur "S".

   Cette case a été initialisée à "Décochée" pour l'action "Refuser pour détacher" (RD) par la release.

   4) Possibilité de ne pas prendre en compte les signataires ayant déjà validés en commande :
Pour cela, ajout d'une case à cocher "Signataire n'ayant pas déjà validé en commande" et d'un champ "Règle pour signataire ayant déjà validé" dans les règles des signatures (GRSMA).

   L'utilisateur est défini comme "ayant déjà validé en commande" si celui-ci est déjà intervenu sur une des commandes de la facture et qu'il est le dernier à avoir signé donc, si c'est lui qui a permis à la commande de passer à l'étape de signature.

   Lors du traitement d'affectation des signataires facture (TASMFA), si la case "Signataire n'ayant pas déjà validé en commande" est cochée, une vérification est effectuée, pour chaque signataire posé, que celui-ci ne soit pas le dernier signataire d'une des commandes. Si c'est le cas, ce dernier est créé avec le statut "Non requis" (NR). Ainsi, il ne peut pas signer la facture.

   Lors du traitement d'affectation des signataires facture (TASMFA), si seuls des signataires ayant déjà validé en commande sont affectés, il est alors considéré qu'aucun signataire n'est défini. Aussi :
- en cas de signature obligatoire, un message bloquant apparait ;
- en cas de signature facultative, l'étape de signature passe automatiquement.

   Concernant les délégations (TAGSM), si un signataire délégué, considéré comme "ayant déjà validé en commande", reçoit le pouvoir d'un signataire n'ayant pas déjà validé en commande, alors le délégué est affecté en tant que signataire.

   Au niveau de la facture, il n'est pas possible d'ajouter manuellement (GDSMFA) un signataire ayant déjà validé en commande.

   De même, lors de la signature facture (GSMFA), il n'est pas possible d'affecter un signataire ayant déjà validé en commande pour les actions suivantes :
- "Transférer" (TR) ;
- "Ajouter un signataire" (JS) ;
- "Ajouter un signataire et accepter" (AJ) ;
- "Mettre en litige et transférer à un autre signataire" (LT).
Par contre, il est possible de "Demander un avis" (DA) à un signataire ayant déjà validé en commande, car sur cette action, il n'y a pas de transfert de pouvoir.

GRSMA - Règles des signatures multicritères (Transaction SAIRSM)
GASMA - Actions des signatures multicritères (Transaction SAIASM)
GDSMFA - Détail des signatures multicritères des factures (Transaction SAIDSMF)
TASMFA - Affectation des signataires multicritères factures (Transaction SATASMF)
GSMFA - Signatures multicritères des factures d'achats (Transaction SAISMF)
TAGSM - Affectation délégations signatures multicritères (Transaction SATAGSM)

   1) Modification des contrôles du montant facturé par rapport aux montants réceptionné et commandé (écart en pourcentage, écart en montant) afin de prendre en compte ou pas les lignes ajoutées à la facture.

   2) Le bon à payer est désormais donné sur les factures dont le montant TTC est égal à zéro et pour lesquelles le transfert en comptabilité (TVCC) n'a pas généré de pièce car les montants à zéro sont interdits en comptabilité (valeur testée 1 de l'occurrence MNTZER du paramètre AUTCPT égale à "I").

   1) Lors du contrôle de l'écart entre le montant facturé et les montants réceptionné et commandé, il est possible d'exclure ou pas les lignes ajoutées à la facture du calcul des montants réceptionné et commandé.
Si le contrôle de l'écart est en pourcentage, cela dépend de la chaîne 1 du paramètre AUTSATAC occurrence CTLMTPxxxx (où xxxx représente la classe d'achats).
Si le contrôle de l'écart est en montant, cela dépend de la chaîne 1 du paramètre AUTSATAC occurrence CTLMNTxxxx (où xxxx représente la classe d'achats).
Dans les deux cas, si la chaîne 1 vaut :
- O ou non renseignée : les lignes ajoutées à la facture sont prises en compte dans le calcul du montant commandé et du montant réceptionné ;
- N : les lignes ajoutées à la facture sont exclues dans le calcul du montant commandé et du montant réceptionné.

TTAC - Bon à payer (Transaction SATTAC)
GTAC - Acceptation de la facture (Transaction SAITAC)
GDLI - Déblocage litige facture (Transaction SAITAC)
TASMFA - Affectation des signataires multicritères factures (Transaction SATASMF)
TAGSM - Affectation délégations signatures multicritères (Transaction SATAGSM)
GKSMFA - Signatures multicritères des factures d'achats (Transaction SAISMF)

   Possibilité de sauvegarder, au niveau des lignes de factures, le plan de contrôle sélectionné lors du traitement d'affectation des signataires en fonction du plan de contrôle (TASPCA).

   Pour cela, il est nécessaire d'indiquer, dans la chaîne 1 de l'occurrence PDCLIG du paramètre AUTASPC, la zone des lignes de factures à renseigner :
- L01 : libellé 1 (l01salca) ;
- L02 : libellé 2 (l02salca) ;
- L03 : libellé 3 (l03salca) ;
- L04 : libellé 4 (l04salca) ;
- L05 : libellé 5 (l05salca).

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

   Correction pour que les textes associés aux lignes de demandes d'achats ou de commandes ne soient pas générés en double dans le cas où la génération des articles composés/composants est paramétrée au niveau de la classe de transfert (GTNC) et que les textes doivent être créés à partir des textes modèles définis pour la référence article/fournisseur (GTXERAF), l'article acheté (GTXEATA) et l'article générique (GTXEART).

TTCDA - Intégration des commandes ou demandes d'achats (Transaction SATTCDA)

   1) Si l'auto-signature se fait en fonction du gestionnaire, celle-ci ne s'effectuait pas si le code gestionnaire et le code utilisateur étaient différents.

   2) Dans le cas où les critères de signatures (GCSMA) sont de type montant ou numérique (par exemple, le montant de la condition de facturation) et que la fourchette de début au niveau de la matrice (GMSMA) n'est pas renseignée, il arrivait que le signataire ne soit pas posé si le montant à prendre en compte était inférieur à -99 999.

   Exemple :
- au niveau de la facture, le montant de la condition de facturation 1000 (GCAF) est de -180 000 EUR ;
- au niveau de la matrice (GMSMA), le signataire A est posé si le montant de la condition de facturation 1000 est inférieur ou égal à 10000 EUR.
Lors du traitement d'affectation, le signataire A n'était pas affecté car le montant de la condition de facturation est inférieur à -99 999 EUR.

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)

   Correction afin de ne plus avoir le message "SAFAA001 : Facture d'achat inexistante ou non utilisable" lors de la création d'une nouvelle facture alors que l'écran des échéances (GCAE) est déjà ouvert en synchronisation.

GCAE - Echéances des commandes (Transaction SAICAE)

   Dans le cas où la facturation des lignes non réceptionnées est autorisée (occurrence LIGREC du paramètre AUTSAFAA), correction de l'affectation du prix réceptionné pour les lignes définies en réception montant : le prix réceptionné est affecté égal au montant facturé, même si le paramétrage indique que le prix facturé doit être calculé à partir du montant facturé (occurrence CALPVF du paramètre AUTSAFAA).
De plus, il est désormais interdit de saisir une quantité solde facture.

SAIFLC - Lignes à facturer (Transaction SAIFLC)
SAILCF - Lignes de facture (Transaction SAILCF)
TTFCA - Intégration des factures d'achats (Transaction SATTFC)

   Ce connecteur permet d'automatiser la chaîne de traitements des factures fournisseurs.
Solution SaaS, la plateforme Esker communique par WebServices avec l'ERP Cegid XRP Ultimate.

   Les fonctionnalités proposées sont, entre autres :
- réception de factures multi-formats ;
- traitement des factures multi-langues, multi-devises ;
- proposition de découpage automatique des factures ;
- extraction et vérification des données factures ;
- traitement des anomalies, réalisé via un écran Esker, ergonomique et intuitif, permettant d'interroger de nombreuses données Cegid XRP Ultimate ;
- intégration des factures dans Cegid XRP Ultimate ;
- archivage du document facture dans la GED Cegid XRP Ultimate ;
- archivage à valeur probante dans Esker.

   La solution Esker, ainsi que le connecteur, nécessitent l'acquisition de licences et des formations associées.

   Ajout de la possibilité de modifier le type de retour du payload.

   Pour cela, ajout d'un paramètre en entrée "payloadArray".
Si la valeur est égale à "true", alors le payload retourné est typé en tant que liste.
La valeur est initialisée à "false" par défaut afin de garder le fonctionnement existant.

   Ajout de la possibilité de modifier le type de retour du payload.

   Pour cela, ajout d'un paramètre en entrée "payloadArray".
Si la valeur est égale à "true", alors le payload retourné est typé en tant que liste.
La valeur est initialisée à "false" par défaut afin de garder le fonctionnement existant.

   Ajout de la possibilité de modifier le type de retour du payload.

   Pour cela, ajout d'un paramètre en entrée "payloadArray".
Si la valeur est égale à "true", alors le payload retourné est typé en tant que liste.
La valeur est initialisée à "false" par défaut afin de garder le fonctionnement existant.

   Ajout de la possibilité de modifier le type de retour du payload.

   Pour cela, ajout d'un paramètre en entrée "payloadArray".
Si la valeur est égale à "true", alors le payload retourné est typé en tant que liste.
La valeur est initialisée à "false" par défaut afin de garder le fonctionnement existant.

   Ajout de la possibilité de modifier le type de retour du payload.

   Pour cela, ajout d'un paramètre en entrée "payloadArray".
Si la valeur est égale à "true", alors le payload retourné est typé en tant que liste.
La valeur est initialisée à "false" par défaut afin de garder le fonctionnement existant.

   Ajout de la possibilité de modifier le type de retour du payload.

   Pour cela, ajout d'un paramètre en entrée "payloadArray".
Si la valeur est égale à "true", alors le payload retourné est typé en tant que liste.
La valeur est initialisée à "false" par défaut afin de garder le fonctionnement existant.

   Ajout de la possibilité de modifier le type de retour du payload.

   Pour cela, ajout d'un paramètre en entrée "payloadArray".
Si la valeur est égale à "true", alors le payload retourné est typé en tant que liste.
La valeur est initialisée à "false" par défaut afin de garder le fonctionnement existant.

   Ajout des colonnes :
RUFSATNC - Recopie unité fonctionnelle interne composé (Obligatoire)

   Ajout des colonnes :
SPVSARSM - Signataire n'ayant pas déjà validé en commande (Obligatoire)
RSVSARSM - Règle pour signataire ayant déjà validé

   Ajout des colonnes :
EFRSAASM - Effacement référence facture (Obligatoire)
SLFSAASM - Suppression logique facture (Obligatoire)

   Ajout des colonnes :
SVCSADSM - Signataire ayant déjà validé en commande

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

   Ajout des colonnes :
TVLSAVLC - Code TVA ligne
NU1SAVLC - Numérique 1 ligne
NU2SAVLC - Numérique 2 ligne
NU3SAVLC - Numérique 3 ligne
G01SAVLC - Identifiant 1 ligne
G02SAVLC - Identifiant 2 ligne
G03SAVLC - Identifiant 3 ligne
G04SAVLC - Identifiant 4 ligne
G05SAVLC - Identifiant 5 ligne
DA1SAVLC - Date 1 ligne
DA2SAVLC - Date 2 ligne
DA3SAVLC - Date 3 ligne

   Modification des colonnes :
RETSAWHD - Code refus : passe sur 60 caractères