Document de release de la version H3.01

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

   Ce traitement permet soit de supprimer physiquement de la base de données les statistiques (GSTTA) sélectionnées soit d'alimenter la table d'archivage des statistiques achats avec les statistiques sélectionnées.

   Selon le paramétrage défini pour l'entité correspondant aux statistiques achats (entité SAAST) dans la gestion des entités à archiver (GACH), le traitement effectue soit une suppression physique des statistiques dans la base de données, soit alimente la table d'archivage des statistiques achats (saast). Dans ce dernier cas, la copie des données et la purge réelle sont effectuées par le module Archivage.

PSTTA - Purge des statistiques achats (Transaction SAPSTT)

   Actuellement, il n'est pas possible d'ajouter un établissement dans une composition d'établissements utilisée dans le cadre de la gestion des marchés multi-établissements. Ceci est impossible car rien ne permet de reprendre les marchés de l'établissement modèle sur l'établissement à ajouter.
Pour pallier à cela, un nouveau traitement, permettant de reprendre les marchés d'un établissement modèle sur un établissement cible, pour les classes de marchés définies en multi-établissements, a été créé.

   Ce traitement permet de :
- sélectionner un ensemble de marchés sur un établissement modèle (soit la totalité des marchés, soit uniquement les marchés valides, soit un seul marché) ;
- choisir un établissement cible ;
- dupliquer, sur l'établissement cible, les marchés sélectionnés ;
- en fin de traitement, s'il n'y a pas d'erreur, ajouter l'établissement cible à la composition d'établissements.

   L'ensemble des structures doivent être créées, au préalable, sur l'établissement cible (fournisseurs, articles, ...).

   Tous les enregistrements sont validés ou aucun : à la moindre erreur, l'utilisateur doit corriger et relancer le traitement.

TMMEA - Marchés multi-établissements : ajout établissement (Transaction SATMME)

   Ce traitement est dédié à générer des fichiers de données au format XML pour qu'il soit transmis, par un tiers de télétransmission, à Chorus Pro.

   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.

   Le répertoire des fichiers statut est donné par le chemin (GPTH) associé à l'application SAC, le type COT et l'utilisateur PUBLIC. Ce répertoire est celui dans lequel le tiers de télétransmission récupère les fichiers.

   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 Qualiac® et le statut Chorus. La valeur 1 et la valeur 2 donnent l'étape ou la fourchette d'étapes correspondante 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 ;
- 11 : Mise en paiement.

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

   Le CHD, ou Contrôle Hiérarchisé de la Dépense, est une pratique proposée, depuis une quinzaine d'années aux Agents Comptables des établissements publics, leur permettant de ne pas contrôler toutes les factures (demandes de paiement ou DP en langage public). L'objectif est de réduire le nombre (à environ 20%) pour tout de même contrôler un fort montant de l'ensemble de la dépense (environ 80%).

   Afin de gérer cela, deux nouvelles gestions ainsi qu'un nouveau traitement ont été créés.

   La gestion des plans de contrôle (GPDCA) permet, pour chaque catégorie du plan de contrôle, d'indiquer par date et par seuil de montant, quel pourcentage de DP sera à contrôler. Elle permet aussi d'avoir un aperçu sur le nombre de factures soumises à validation ainsi que le nombre de factures totales traitées.

   La gestion des liens plan de contrôle / classes d'achats (GPCA) permet de faire le lien entre le plan de contrôle et les classes de commandes d'achats avec, une exception sur les classes de marchés. Elle contient également la règle de signature à appliquer ainsi que les étapes qui seront positionnées en cas de validation requise ou pas. Il est conseillé de créer deux nouvelles étapes. Celles-ci sont à positionner :
      - la première juste avant le traitement d'affectation des signataires si la validation est requise ;
      - la seconde juste après l'étape de signature si la validation n'est pas requise.
Attention : une facture multi-classes pourra potentiellement être multi-plans de contrôle mais elle devra nécessairement être mono règle de signature (GRSMA).

   Exemple de flux d'étapes à créer :
- 700 : Facture (GFAA) ;
- 704 : Etape si validation requise ;
- 705 : Affectation des signataires de la facture ;
- 710 : Signature de la facture (avec comme suivante normale l'étape 720) ;
- 711 : Etape si validation non requise ;
- 720 : Comptabilisation des factures (TVCC).

   Le traitement d'affectation des signataires en fonction du plan de contrôle (TASPCA) permet de sélectionner les factures à traiter. Il s'agit des factures correspondant aux critères de sélection et :
- n'étant pas déjà soumises à un précédent contrôle (aucun enregistrement au niveau des détails de signatures (GDSMFA)) ;
- respectant le type de contrôle (a priori / a posteriori).

   Lors de l'exécution du traitement, les factures sélectionnées sont traitées une à une afin de déterminer à quel plan de contrôle elles sont associées et si le montant oblige la validation de cette dernière.

   L'occurrence TRTFAA du paramètre AUTASPC permet de piloter les objectifs à atteindre lors de l'exécution du traitement et permet également de déterminer la date utilisée pour rechercher la catégorie du plan de contrôle à appliquer.
La valeur testée 1 donne la date à utiliser pour rechercher la catégorie du plan de contrôle. Si la valeur testée 1 vaut :
      - F : date de facture ;
      - C : date comptable de la facture ;
      - L : date logique.
La valeur 1 représente le pourcentage minimum de factures sélectionnées à soumettre à validation lors de l'exécution du traitement (exemple 20%).
La valeur 2 représente le pourcentage du montant minimum des factures sélectionnées à soumettre à validation lors de l'exécution du traitement (exemple 80%).

   Avant de déterminer si une facture est à soumettre à validation ou pas, pour chaque facture, la catégorie du plan de contrôle est recherchée, en fonction du montant de la facture (somme des montants facturés HT des lignes de la facture) et de la date sélectionnée (en fonction de la valeur testée 1 de l'occurrence TRTFAA du paramètre AUTASPC). La catégorie recherchée doit avoir le même type de contrôle (a priori / a posteriori) que celui précisé à la soumission du traitement. Par ailleurs, si plusieurs catégories du plan de contrôle sont trouvées, est prise celle qui possède la date de version la plus grande.

   Les factures sélectionnées sont traitées en deux passages :
- le premier parcours permet de déterminer les factures qui doivent obligatoirement être signées, c'est-à-dire celles où le pourcentage de contrôle, défini dans la transaction GPDCA, est de 100 %. Sur ce parcours, si le pourcentage de contrôle est inférieur à 100% et que l'on est en avance par rapport à la catégorie du plan de contrôle (le pourcentage de contrôle est inférieur au ratio factures soumises / factures traitées), la facture ne doit pas être signée ;
- lors du second passage, les factures restantes sont soumises à validation, de manière aléatoire, jusqu'à atteindre les objectifs paramétrés au niveau de l'occurrence TRTFAA du paramètre AUTASPC expliqué plus haut.

   Si une facture doit être validée, elle est positionnée à l'étape "si validation requise" définie dans GPCA et, le traitement d'affectation des signataires, correspondant à la règle de signature (GRSMA) définie également dans GPCA, est alors exécuté. La facture se retrouve donc à l'étape du traitement d'affectation des signataires. Attention : si la facture est multi-classes, les différentes classes d'achats doivent posséder le même flux d'étapes et la même règle de signature.
Si la validation de la facture n'est pas requise, elle est positionnée à l'étape "si validation non requise" définie dans GPCA.

GPDCA - Plans de contrôle (Transaction SAIPDC)
GPCA - Liens plan de contrôle / classe d'achats (Transaction SAIPCA)
TASPCA - Affect. des signataires en fonct. du plan de ctrl. (Transaction SATASPC)

   Cette transaction permet de définir les caractéristiques nécessaires pour l'accès aux Web Services des référentiels externes concernant les fournisseurs.
Elle est utilisée dans le cadre du connecteur développé pour la solution Provigis (cf explication sur le connecteur Provigis).

GSEA - Services externes achats (Transaction SAIISE)

   Ajout de la possibilité que le calcul des révisions liées au marché puisse s'effectuer de manière semestrielle.

   La périodicité est donnée par la valeur testée 2 de l'occurrence "forme de prix du marché" du paramètre FDPSAMAR.
Si la valeur testée 2 est égale à :
- A : périodicité annuelle ;
- SE : périodicité semestrielle ;
- T : périodicité trimestrielle ;
- M : périodicité mensuelle ;
- non renseignée : pas de périodicité à appliquer.
Cette périodicité correspond elle-même à une occurrence du paramètre TYPOECAP.

   Pour gérer une périodicité semestrielle, il faut donc que la forme de prix du marché soit une occurrence du paramètre FDPSAMAR telle que la valeur testée 2 de cette occurrence soit égale à "SE".

TREVAC - Calcul des révisions liées au marché après cde (Transaction SATREVC)
TREVA - Calcul des révisions liées au marché après réc. (Transaction SATREV)

   Ajout de la possibilité d'effectuer un équilibrage des comptes techniques de l'écriture de facture (TVCC) afin de régulariser des problèmes d'arrondis de centimes entre les mouvements de la facture et les mouvements de l'annulation de la FNP correspondante.

   Cette possibilité est donnée par la valeur testée 1 du paramètre AUTM9 occurrence CPTAEQL. Si elle est égale à :
- N : l'équilibrage entre les comptes techniques de l'écriture de facture n'est pas effectué ;
- O : l'équilibrage entre les comptes techniques de l'écriture de facture est effectué. Les informations suivantes doivent alors être renseignées :
         - la chaîne 1 donne le compte d'équilibre. Il doit être défini en TVA interdite,
         - la chaîne 2 donne le poste,
         - le texte donne le CGR A,
         - la valeur 1 donne la tolérance en montant. Elle est exprimée en devise de référence.

   Si un écart est détecté, inférieur à la tolérance, il est alors créé deux mouvements d'équilibre : un mouvement portant sur le compte d'équilibre et un autre mouvement en sens inverse sur le compte technique défini en TVA interdite (compte donné par le paramètre AUTM9 occurrence CPTACHI).

TVCC - Comptabilisation des factures (Transaction SATVCC)

   Concernant le flux de dépenses sans engagement préalable, la consommation des autorisations d'engagement doit se faire à la validation de la demande de paiement par l'ordonnateur et la consommation des crédits de paiement à la prise en charge par l'agence comptable.

   Afin de répondre à cette exigence, il est nécessaire d'apporter des modifications de paramétrage et de mettre en place les fonctionnalités suivantes :
1) Mise en place, dans le flux de facturation directe, d'une nouvelle étape permettant de générer pour la facture, une écriture extra-comptable (TVCCx).
Ce traitement n'est pas livré en standard. Il doit être dupliqué à partir d'un TVCC mais avec le paramétrage suivant :
     - la valeur du paramètre PR1 associé au traitement du "TVCCx" doit être égale à "N" ;
     - la valeur du paramètre PRM associé au traitement du "TVCCx" doit être égale à "E" ;
     - le montant à traiter, donné par le type de ventilation (GTVCA) utilisé par le "TVCCx" doit être égal au montant facturé ;
     - le type d'écriture, donné par le type de ventilation utilisé par le "TVCCx", doit être différent de "C" afin de générer des écritures extra-comptables ;
     - le journal, donné par le type de ventilation utilisé par le "TVCCx", ne doit pas être en validation automatique et son origine doit être paramétrée afin d'autoriser la suppression des écritures de transfert non validées (la chaîne 1 et la chaîne 2 du paramètre OCR occurrence l'origine du journal doivent respectivement être égales à "TMS" et "AS").
La fenêtre de critères du SATVCC doit également être dupliquée en "SATVCCx" .

   2) Mise en place, dans le flux de facturation directe, d'une nouvelle étape correspondant au traitement de suppression d'écriture temporaire (TSEMA). Ce traitement permet de supprimer physiquement une écriture de facture extra-comptable générée sur un flux de facturation.

   3) Bouton "RETOUR" de la demande de paiement (GFAA) : ce bouton, en plus d'effectuer un "retour" à une certaine étape pour une facture, permettra de supprimer, si besoin, l'écriture de facture extra-comptable qui a pu être générée précédemment. Pour cela, positionner le paramètre AUTSAMDT occurrence SUPECR s'il est déjà présent, sinon le paramètre AUTSAFAA occ RET-xxxx où xxxx représente la classe d'achats (si aucun de ces deux paramètres n'est présent, c'est le paramètre AUTSAFAA occurrence RET-xxxx qu'il faut positionner).

   4) Evolution de l'action "RR" des signatures multicritères facture afin de pouvoir supprimer, si besoin, l'écriture de facture extra-comptable qui a pu être générée précédemment.

GFAA - Contrôle facture (Transaction SAIFAA)
GSMFA - Signatures multicritères des factures d'achats (Transaction SAISMF)
TSEMA - Suppression écriture temporaire (Transaction SATSEM)

   Nécessité de formation.

   1) Ajout de la possibilité de contrôler que la somme des avances prévues pour un marché ne dépasse pas un certain pourcentage du montant prévu du marché.

   2) Lors de la création d'un complément de marchés publics pour un marché portant sur une classe définie en multi-établissements dans GNCM, création de ce complément sur tous les établissements de la composition d'établissements. Idem en modification ou en suppression d'un complément sur un établissement de la composition : modification ou suppression du complément sur tous les établissements de la composition.
Attention : même si la classe de marchés est définie en multi-établissements, le traitement de mise à jour des montants co-traitant/sous-traitant (TMCSA) reste mono-établissement c'est à dire que seul le complément de marchés publics correspondant à l'établissement de la facture sera mis à jour.

   1) Cette possibilité est donnée par le paramètre AUTSAMAR occurrence CTLAVP.
Si la valeur testée 1 est égale à :
- P : le contrôle est effectué à partir du montant prévu général du marché ;
- P1 : le contrôle est effectué à partir du montant prévu des lignes de type 1 de l'en-tête du marché ;
- P2 : le contrôle est effectué à partir du montant prévu des lignes de type 2 de l'en-tête du marché.

   La chaîne 1 donne l'information du marché permettant d'indiquer le pourcentage à appliquer au montant prévu. Les différentes possibilités sont :
- MC1 : montant complémentaire 1 ;
- MC2 : montant complémentaire 2 ;
- MC3 : montant complémentaire 3 ;
- MC4 : montant complémentaire 4 ;
- MC5 : montant complémentaire 5.

GCMP - Compléments des marchés publics (Transaction SAICMP)
GMARA - Marchés (Transaction SAIMAR)

   1) Ajout de zones manquantes, relatives aux marchés et aux lignes de marchés, dans l'édition.

   2) Possibilité d'éditer les compléments des marchés publics (GCMP).

   1) Ajout des zones suivantes pour le marché :
- Gestionnaire technique ;
- Gestionnaire commercial ;
- Montant minimum prévu du marché ;
- Montant minimum prévu des lignes de type 1 ;
- Montant prévu des lignes de type 1 ;
- Montant en cours des lignes de type 1 ;
- Montant réel des lignes de type 1 ;
- Montant minimum prévu des lignes de type 2 ;
- Montant prévu des lignes de type 2 ;
- Montant en cours des lignes de type 2 ;
- Montant réel des lignes de type 2 ;
- Blocage quantité des lignes de type 1 ;
- Blocage montant des lignes de type 1 ;
- Blocage quantité des lignes de type 2 ;
- Blocage montant des lignes de type 2 ;
- Etablissement et numéro de l'accord cadre ;
- Montant de l'acte d'engagement ;
- Montant plafond ;
- Date de notification ;
- Durée du marché (en mois) ;
- Date de réception de l'offre ;
- Date de signature interne ;
- Forme de prix ;
- Mode de passation ;
- Mode de déclenchement ;
- Type de pouvoir ;
- Convention ;
- Garantie ;
- Mode de facturation ;
- Cession de créances ;
- Jalon facturable ;
- Gestionnaires complémentaires 1, 2 et 3 ;
- CGR B ;
- Clé de confidentialité du CGR ;
- Paramètres 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 et 20 ;
- Montants complémentaires 1, 2, 3, 4 et 5 ;
- Identifiants 1, 2, 3, 4 et 5 ;
- Dates complémentaires 1, 2, 3, 4 et 5 ;
- Classe et numéro de la DA ou de la commande générée pour les lignes de type 1 ;
- Classe et numéro de la DA ou de la commande générée pour les lignes de type 2 ;
- Textes 6, 7 et 8.

   Ajout des zones suivantes pour les lignes de marchés :
- Taxe ;
- Classe et numéro avenant ;
- Phase ;
- Type de tranche ;
- Numéro de tranche ;
- Déclenché ;
- Date de notification ;
- Date de début d'exécution ;
- Durée du marché (en mois) ;
- Quantité minimale ;
- Montant minimum ;
- Paramètres 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 et 20 ;
- Montants complémentaires 1, 2, 3, 4 et 5 ;
- Identifiants 1, 2, 3, 4 et 5 ;
- Dates complémentaires 1, 2, 3, 4 et 5.

   2) Pour cela, ajout de la case à cocher "Compléments des marchés publics" à la soumission de l'édition.

EMARA - Edition des marchés (Transaction SAEMAR)

   Modification de l'affichage de la période à répartir : passage d'un affichage par mois et année à un affichage par jour, mois et année.

   Possibilité de modifier la période de début aussi bien en création qu'en modification.

SAIREA - Répartition par année (Transaction SAIREA)

   Possibilité de paramétrer l'emplacement avec lequel la recherche en stock est effectuée dans le cas où la quantité demandée est négative.

   Pour cela, ajout de l'occurrence PROEMPNEG pour le paramètre AUTSARDA.
Si la valeur testée 1 vaut :
- N : la recherche de l'emplacement est inchangée ;
- O : la recherche s'effectue avec l'emplacement proposé à partir de l'occurrence PROEMP du paramètre AUTSTOCK. Si l'article est également géré par lot, aucune proposition n'est effectuée et la saisie des détails par lot et/ou emplacement devra être faite lors de la livraison des demandes de services (GRDA).

   NB : par défaut, la valeur testée 1 est initialisée avec la valeur "N" par la release.

TRDS - Réservation en stock des demandes de services (Transaction SATRDS)
SAIRDS - Réservation du stock pour les demandes de services (Transaction SAIRDS)

   Possibilité de paramétrer la date à partir de laquelle est effectuée la mise à jour des stocks pour les demandes de services.

   Pour cela, ajout de l'occurrence DATLIV pour le paramètre AUTSARDA.
Si la valeur testée 1 vaut :
- RD : la date pour la mise à jour des stocks est la date prévue de la ligne de demande si elle renseignée sinon, la date au plus tôt de l'en-tête de demande ;
- L : la date pour la mise à jour des stocks est la date logique ;
- S : la date pour la mise à jour des stocks est la date système.

   NB : par défaut, la valeur testée 1 est initialisée avec la valeur "RD" par la release.

TSDA - Mise à jour en stock des demandes de services (Transaction SATSDA)

   Modification pour ne plus avoir le message "Les informations que vous avez créées vont être détruites" sur toutes les fermetures de la gestion qui ont lieu après une recherche qui n'a rien ramené.

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

   Ajout d'une fourchette d'établissements à la soumission.

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

   Ajout de la possibilité, à la saisie du marché, de ne pas proposer le fournisseur du marché si celui-ci est renseigné, ainsi que la devise, les tiers et adresses (tiers et adresses de commande, livraison, facturation, paiement, à facturer) et les informations liées au transport (dépôt, mode de transport, type de port, destination). Ces informations seront proposées du fournisseur à la saisie de celui-ci.
De même, l'échéance de la commande ne sera pas créée à partir de l'échéance du marché mais à partir de celle du fournisseur.

   Cette possibilité est donnée par le paramètre PFM associé au mnémonique.
Si la valeur du paramètre vaut :
- O : les informations sont proposées à partir du marché si elles sont renseignées ;
- N : les informations ne sont pas proposées à partir du marché.

   Remarque : Dans le cas où le fournisseur n'est pas proposé à partir du marché mais est saisi, il est impératif que le paramétrage de la classe d'achats (GNCA) autorise que :
- le fournisseur n'appartienne pas obligatoirement au marché si le fournisseur saisi n'est pas référencé au niveau de l'en-tête du marché (GMARA) et/ou au niveau des lignes de marchés (GMADA - GMALA) ;
- la devise, les tiers et adresses de commande, de livraison, de facture et de paiement puissent être différents de la devise, des tiers et adresses du marché.

GCDA - Commandes d'achats (Transaction SAICDA)

   1) Ajout de la possibilité de modifier le type, la nature, le genre, le rôle, l'observation réception, l'observation facture et l'observation paiement par rapport à la demande d'achats ou la commande origine.

   2) Ajout de la possibilité de recopier la date comptable et/ou la date de contrat de la commande origine ou de proposer ces dates par défaut.

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

   2) Pour cela, ajout des cases à cocher "Date comptable" et "Date de contrat".
Si la case "Date comptable" est cochée, la date comptable de la demande d'achats ou de la commande générée est proposée par défaut.
Si la case "Date comptable" n'est pas cochée, la date comptable de la demande d'achats ou de la commande générée est recopiée de la demande d'achats ou de la commande origine.

   Même principe avec la date de contrat.

TDCDA - Duplication de commandes (Transaction SATDCDA)

   1) Ajout de la possibilité de paramétrer l'affectation du compte client pour Hospitalis.

   2)   Ajout de la possibilité de générer ou pas le fichier EDI en fonction du type de document à éditer du fournisseur (GFOU).

   1) Pour cela, ajout de l'occurrence REFCLI du paramètre EDTBCDEA.
La chaîne 1 indique comment est affecté le compte client :
- si la chaîne 1 contient la valeur "refsafou", le compte client est affecté avec la référence fournisseur (valeur de la zone refsafou (GFOU)) ;
- si la chaîne 1 n'est pas renseignée ou est différente de la valeur "refsafou" ou si la référence fournisseur n'est pas renseignée dans GFOU, le compte client est alimenté avec le texte de la rubrique "COMPTE_CLI" associée au fournisseur (GARUFOU).

   NB : la chaîne 1 est livrée sans valeur par la release.

   2) Pour cela, ajout de l'occurrence HOSPITAL du paramètre EDTBCDEA.
Si la valeur testée 1 vaut :
- O : génération du fichier uniquement si le type de document à éditer du fournisseur (zone edtsafou) contient la valeur "H" ;
- N : génération du fichier quelle que soit la valeur du type de document à éditer.

   NB : la valeur testée 1 est initialisée à "N" par la release.

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

   Ajout de la possibilité de gérer le multi-langues soit avec la conversion des libellés (GTCL) soit avec le mécanisme propre au système Qualiac® Editions.

   Jusqu'à présent, il était possible de gérer le multi-langues grâce à la gestion des conversions de libellés (GTCL). Ceci quel que soit le libellé.
Il est dorénavant possible de gérer le multi-langues grâce au mécanisme propre à Qualiac® Editions mais ceci uniquement pour les libellés fixes.
Pour cela, ajout de l'occurrence LANG du paramètre EDTBCDEA.
Si la valeur testée 1 vaut :
- O : les libellés prévus par le programme sont traduits via GTCL ;
- N : les libellés fixes sont traduits par le mécanisme propre à Qualiac® Editions.

   NB : par défaut, la valeur testée 1 est initialisée avec la valeur "O" par la release.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   Ajout de la possibilité de saisir un montant dans les échéances des commandes et des factures (GCAE).

   Pour cela, ajout d'un nouveau champ, non basé (WMONTANT).
Ce champ n'est pas visible en standard. Pour pouvoir le gérer, il est nécessaire de faire une personnalisation de la transaction afin de l'ajouter.

   Lors de la saisie de ce montant, le pourcentage correspondant est automatiquement recalculé.
Si la commande ne possède que deux détails d'échéance et que le montant d'un de ces deux détails est modifié, non seulement, le pourcentage du détail d'échéance modifié est recalculé mais également, à la validation, celui de l'autre détail d'échéance ceci afin d'obtenir 100 %.

   NB : afin que le champ WMONTANT soit bien initialisé et que le calcul du pourcentage puisse être correct, il est nécessaire de valoriser la commande ou la facture avant de pouvoir modifier le montant.

GCAE - Echéances des commandes (Transaction SAICAE)

   Il est désormais possible qu'une clé de répartition (GCRC) puisse être constituée de CGR de segments différents. Dans ce cas, lors de la génération des ventilations par CGR A (GVCG) à partir de cette clé de répartition, les ventilations par CGR A sont créées à l'identique de la clé de répartition.

   Cette possibilité est donnée par le paramètre AUTODE occurrence CTLCRC.
Si la valeur testée 1 est égale à :
- A : une clé de répartition (GCRC), utilisable dans Qualiac® Achats, ne doit contenir que des CGR combinaison ou des CGR de même numéro de segment (s'il est renseigné). Lors de la création des ventilations par CGR A associées à une ligne de commande, à partir de cette clé de répartition (GCRC), les ventilations par CGR A sont créées à partir des CGR A définis dans la clé de répartition et à partir du CGR A saisi sur la ligne de commande s'il est renseigné ou sinon du CGR A saisi sur l'en-tête ;
- I : une clé de répartition (GCRC), utilisable dans Qualiac® Achats, peut contenir des CGR de numéro de segment différents. Lors de la création des ventilations par CGR A associées à une ligne de commande, à partir de cette clé de répartition, les ventilations par CGR A sont créées à l'identique de la clé de répartition.

   NB : la valeur testée 1 est initialisée à "A" par la release.

GCRC - Clé de répartition des CGR (Transaction OEICRC)
GVCG - Ventilations par CGR (Transaction SAIVCG)

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

   2) Possibilité de rendre la saisie d'un commentaire obligatoire lors de la signature de demandes d'achats, de commandes, de réceptions, de factures et de marchés.

   3) Possibilité de rendre la saisie d'un code refus obligatoire lors de l'action "Refuser pour resoumettre" pour les demandes d'achats, les commandes, les réceptions, les factures et les marchés.

   4) Evolution des détails de signatures.

   5) Ajout de la possibilité de "Refuser pour détacher" lors de la signature de factures.
Pour cela, l'action "Refuser pour détacher" (RD) doit être associée à la règle de signature des factures dans la gestion des actions des signatures multicritères (GASMA).

   6) Ajout de l'historique de signature au niveau de certains WIMs.

   7) Ajout de la possibilité de faire une "Acceptation globale" lors de la signature des réceptions, des factures et des marchés.
Pour cela, ajout du bouton "Acceptation globale" dans la gestion de signatures des réceptions (GSMRA/GKSMRA), des factures (GSMFA, GKSMFA) et des marchés (GSMMA/GKSMMA).
Ce bouton permet de passer automatiquement tous les éléments à signer au statut "Accepté".

   8) Possibilité de sauvegarder les anciens statuts lors d'un refus pour resoumettre (action RR), d'un retour à l'étape initiale (TANU), de l'annulation d'une demande d'achats ou d'une commande (TSRD), de l'annulation d'une commande réceptionnée (TACRA), des commandes réceptionnées sans facture (TRSF), de l'annulation d'une facture (TAFAA), d'un retour à l'étape initiale pour les marchés (TREIMA).

   9) Possibilité de déterminer le type d'exécution des traitements suivants, lancés automatiquement après la signature.

   10) Possibilité de pouvoir réaffecter les signataires pour les demandes d'achats, les commandes, les réceptions, les factures ou les marchés si des modifications ont été apportées à la matrice alors que pour ces éléments, le détail des signataires a déjà été posé mais que l'élément n'est pas encore signé dans sa totalité.

   1) Ajout de nouveaux critères pour l'affectation des signataires.
Nouveaux critères pouvant être utilisés pour les règles de signatures des demandes d'achats, des commandes, des réceptions et/ou des factures :
- code confidentialité du CGR de la ligne de commande (CNFCGRA) ;
- fonction de l'article (FONSGART) ;
- marque de l'article (ARMSGART) ;
- forme de l'article (ARFSGART) ;
- série de l'article (ARSSGART) ;
- présentation de l'article (ARPSGART) ;
- emballage de l'article (ARESGART) ;
- regroupement de l'article (ARGSGART).

   Nouveaux critères pouvant être utilisé pour les règles de signatures des factures :
- type d'acceptation de la facture (TACSAFAA) ;
- utilisateur d'acceptation de la facture (UACSAFAA).

   Nouveau critère pouvant être utilisé pour les règles de signatures des marchés : code confidentialité du CGR de la ligne de marché (CNFCGRMA).

   2) Possibilité de rendre la saisie d'un commentaire obligatoire lors de la signature de demandes d'achats, de commandes, de réceptions, de factures et de marchés. Cette possibilité dépend de l'action choisie lors de la signature.
Pour cela, ajout de la case à cocher "Commentaire obligatoire" au niveau des actions des signatures multicritères (GASMA).

   3) Possibilité de rendre la saisie d'un code refus obligatoire lors de l'action "Refuser pour resoumettre" pour les demandes d'achats, les commandes, les réceptions, les factures et les marchés.
Pour cela, il est nécessaire de cocher la case "Code refus obligatoire" au niveau de l'action de signature "Refuser pour resoumettre" (RR) pour la règle de signature souhaitée.

   4) Evolution des détails de signatures.
Afin d'avoir une meilleure traçabilité des détails de signatures, ajout de nouvelles zones permettant de savoir par qui et quand le signataire a été affecté. Ces zones sont :
- l'utilisateur d'affectation ;
- la date d'affectation ;
- l'heure d'affectation.

   5) Ajout de la possibilité de "Refuser pour détacher" lors de la signature de factures.
Afin que les commandes de la facture puissent être détachées, il est nécessaire qu'elles retournent à une étape autorisant le détachement. Cette étape est à renseigner, au niveau de l'étape de refus de l'action « RD », dans les actions des signataires (GASMA) (par exemple : 700).
Une fois que les commandes de la facture sont retournées à cette étape, le détachement est réalisé. Les commandes sont alors positionnées à l'étape où elles se situaient avant d'être facturées.

   Afin que les commandes de la facture puissent être détachées, il est nécessaire de respecter les conditions suivantes :
- aucune des commandes de la facture ne doit avoir généré un solde facture ;
- la facture ne doit pas avoir été transférée en comptabilité (TVCC) ;
- la facture ne doit pas avoir généré une récupération d'avance (TRAA) ;
- la facture ne doit pas posséder une ligne créée à la facture.

   Une fois les commandes détachées de la facture, la référence de la facture est remise à blanc.

   Une requête permettant de déclencher un WIM est à disposition afin d'informer les créateurs ou les gestionnaires que les commandes ont été détachées de la facture : QLC_SAC_SMC_FAA_UNI_RET_KO_RD.

   6) Ajout de l'historique de signature au niveau de certains WIMs.
Afin de compléter les informations au niveau des WIMs pour les signatures multicritères, l'historique de signature a été ajouté au WIMs permettant :
   - d'informer les signataires qu'ils ont une demande d'achats, une commande, une réception, une facture ou un marché à signer :
             - QLC_SAC_SMC_DA_UNI_SIG : demande d'achats à signer,
             - QLC_SAC_SMC_CDA_UNI_SIG : commande à 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 ;
   - d'informer les créateurs ou les gestionnaires que leur demande d'achats, leur commande, leur réception, leur facture ou leur marché est accepté(e) :
             - QLC_SAC_SMC_DA_UNI_RET_OK : demande d'achats acceptée,
             - QLC_SAC_SMC_CDA_UNI_RET_OK : commande acceptée,
             - QLC_SAC_SMC_REC_UNI_RET_OK : réception acceptée,
             - QLC_SAC_SMC_FAA_UNI_RET_OK : facture acceptée,
             - QLC_SAC_SMC_MAR_UNI_RET_OK : marché accepté.

   8) Possibilité de sauvegarder les anciens statuts lors d'un refus pour resoumettre (action RR), d'un retour à l'étape initiale (TANU), de l'annulation d'une demande d'achats ou d'une commande (TSRD), de l'annulation d'une commande réceptionnée (TACRA), des commandes réceptionnées sans facture (TRSF), de l'annulation d'une facture (TAFAA), d'un retour à l'étape initiale pour les marchés (TREIMA).

   Cette possibilité est donnée par la valeur testée 2 de l'occurrence SUPSIG du paramètre AUTACHAT. Si la valeur testée 2 est égale à :
- N : le code statut des détails des signatures annulées passe à "AN" et la date et l'heure d'action sont égales à la date et l'heure à laquelle l'annulation est effectuée ;
- O : le code statut des détails des signatures annulées est de la forme AN-XX où XX représente l'ancien statut du détail de signature et la date et l'heure de l'action d'origine sont conservées.

   Exemple :

   9) Possibilité de déterminer le type d'exécution des traitements suivants, lancés automatiquement après la signature d'une demande d'achats, d'une commande, d'une réception, d'une facture ou d'un marché.
Pour cela, ajout de l'occurrence JOBEXE du paramètre AUTACHAT. Si la valeur testée 1 est égale à :
- D : les traitements suivants sont exécutés en différé ;
- I : les traitements suivants sont exécutés en immédiat.

   Rappel : La zone "Lancement des traitements suivants", au niveau des actions des signatures multicritères (GASMA), permet de déterminer si, lors de l'acceptation (action AC), les traitements par étape suivants sont lancés.
NB : Si plusieurs éléments sont traités via le bouton « Tout soumettre », les traitements suivants sont exécutés de manière différée.

   10) Pour qu'un élément puisse être traité, il ne doit pas être :
- verrouillé par un utilisateur (être en cours de signature par un des signataires) ;
- partiellement signé si la case « Blocage si signature en cours » est cochée. Si cette case n'est pas cochée (et si l'élément est partiellement signé), les détails de signatures pour cet élément sont supprimés et sont réaffectés en fonction de la matrice (GMSMA) correspondante.

   Si la case « Compte rendu complet » est cochée, cela permet d'éditer pour chacun des éléments traités, les anciens signataires qui ont été supprimés et les nouveaux signataires qui sont réaffectés.

GASMA - Actions des signatures multicritères (Transaction SAIASM)
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)
GCSMA - Critères de signatures (Transaction SAICSM)
GMSMA - Matrice des signatures multicritères (Transaction SAIMSM)
GDSMDA - Détail des signatures multicritères des DA (Transaction SAIDSMD)
GDSMCA - Détail des signatures multicritères des commandes (Transaction SAIDSMC)
GDSMRA - Détail des signatures multicritères des réceptions (Transaction SAIDSMR)
GDSMFA - Détail des signatures multicritères des factures (Transaction SAIDSMF)
GDSMMA - Détail des signatures multicritères des marchés (Transaction SAIDSMM)
CDSMA - Consultation des signatures multicritères (Transaction SACDSM)
CDSMMA - Consultation des signatures multicritères marchés (Transaction SACDSMM)
TASSEA - Affectation des signataires hors étape (Transaction SATASSE)
TASMSEA - Affectation des signataires hors étape (marchés) (Transaction SATASMSE)

   Au moment de la signature d'une demande d'achats, d'une commande ou d'une facture, afin que le passage d'étape de l'élément signé se fasse correctement, prise en compte du fait que l'élément ait pu être signé précédemment par un délégué, alors que cette délégation est périmée.

GSGDA - Signatures des demandes d'achats (Transaction SAISGD)
GSGCA - Signatures des commandes d'achats (Transaction SAISGC)
GSGFA - Signatures des factures d'achats (Transaction SAISGF)
GCSGA - Changement de signataires (Transaction SAICSG)

   Lorsque la commande n'est pas réceptionnée, possibilité de paramétrer la date utilisée pour la recherche des informations des droits d'auteurs et le recalcul des conditions de facturation correspondantes.

   Pour cela, ajout du paramètre AUTSADAU occurrence DATRECNUL.
La valeur testée 1 donne la date à partir de laquelle les informations sont recherchées. Si la valeur testée 1 vaut :
- C : date de commande ;
- L : date logique ;
- S : date système.

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

   NB : si la commande est réceptionnée, c'est la date de réception qui est utilisée.

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

   1) Afin de pouvoir gérer correctement le prorata de TVA dans les immobilisations provisoires, le calcul du montant du prorata de TVA n'est plus effectué lors du traitement de transfert de l'immobilisation provisoire en définitive (TAMIMT) mais est effectué directement par Qualiac® Achats par les traitements de mise à jour des immobilisations provisoires après réception (TIMOR) et après facture (TIMO).

   2) Possibilité d'envoyer l'unité fonctionnelle interne dans la fiche d'immobilisation. La zone dans laquelle elle est envoyée est définie dans la gestion de paramétrage de la création des immobilisations (GAMPCI).

   1) Pour cela, une nouvelle zone "Montant du prorata de TVA" a été ajoutée dans les immobilisations provisoires (GAMIMP) et les immobilisations de transfert (GAMIMT).
Cette nouvelle zone est renseignée automatiquement par les traitements de mise à jour des immobilisations provisoires après réception (TIMOR) et après facture (TIMO).

   Cela permet de résoudre les cas suivants :
- restitution des immobilisations provisoires dans toutes les éditions avec les montants correspondants à ceux passés en comptabilité ;
- taux de prorata différents entre celui de la commande et celui des conditions de facturation pris en compte (auparavant, lorsque le calcul était effectué lors du transfert de l'immobilisation (TAMIMT), un seul taux de TVA était recherché dans GPTV) ;
- taux de prorata recherchés dans GPTV qui peuvent être différents si la date comptable de l'écriture et la date d'acquisition de l'immobilisation sont différentes.

   2) Pour cela, ajout de l'occurrence UFISALCA pour le paramètre LBAAMPCI.

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

   1) Possibilité de prendre en compte une date particulière, autre que celle donnée par le paramétrage du transfert en comptabilité (GTVCA), pour l'annulation en comptabilité de la sous-commande à annuler ainsi que pour le ré-engagement de la sous-commande générée en attente de réception.

   2) Ajout d'une fourchette d'établissements à la soumission.

   1) Pour cela, ajout, à la soumission, d'un radio bouton "Prise en compte date" avec les valeurs suivantes :
- Stock : si la date est renseignée à la soumission, la sous-commande générée pour annuler les stocks est créée avec une date de commande égale à cette date. Les stocks et les prix sont annulés avec cette date. Par contre, cette date n'est pas prise en compte pour l'annulation en comptabilité qui est effectuée en fonction du paramétrage du transfert en comptabilité (GTVCA) ;
- Comptabilité : si la date est renseignée à la soumission, cette date est prise en compte pour l'annulation en comptabilité de la sous-commande à annuler ainsi que pour le ré-engagement de la sous-commande générée en attente de réception. Par contre, cette date n'est pas prise en compte pour l'affectation de la date de commande de la sous-commande générée pour annuler les stocks et n'est pas prise en compte pour l'annulation des stocks et des prix ;
- Les deux : si la date est renseignée à la soumission :
           - la sous-commande générée pour annuler les stocks est créée avec une date de commande égale à cette date. Les stocks et les prix sont annulés avec cette date,
           - cette date est prise en compte pour l'annulation en comptabilité de la sous-commande à annuler ainsi que pour le ré-engagement de la sous-commande générée en attente de réception ;
- Aucune : la date ne peut pas être renseignée à la soumission.

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

   1) Agrandissement du libellé de la facture à 60 caractères.

   2) Ajout d'informations complémentaires dans l'en-tête de facture.

   3) Ajout du marché dans l'en-tête de facture.

   2) 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" de la gestion des factures, du sas des factures (GTFCA) et également des formes sélections des factures (CSFAA et TSFAA).

   Ajout de ces informations dans les colonnes pouvant être modifiées lors de la duplication d'une facture (fenêtre détail "Duplication de factures" et traitement de duplication de factures (TDFAA)).

   3) Ajout du marché dans la grille de l'en-tête de facture. La zone est également disponible dans le formulaire mais n'est pas présente dans le masque fourni en standard.

   Si le marché est renseigné dès la saisie de l'en-tête de facture, seules les commandes et les lignes de commandes concernant ce marché peuvent être rattachées à la facture.
Si le marché n'est pas renseigné dès la saisie de l'en-tête de facture, il est possible de rattacher des commandes et des lignes de commandes concernant des marchés différents : aucune restriction par rapport au marché n'est effectué.

   Le marché peut être précisé sur la facture une fois que les commandes ont été rattachées à la facture uniquement s'il est égal au marché de toutes les commandes rattachées.

GFAA - Contrôle facture (Transaction SAIFAA)
GFAAG - Facturation globale (Transaction SAIFAAG)
GFAAD - Facturation détaillée (Transaction SAIFAAD)
SAIFCD - Commandes à facturer (Transaction SAIFCD)
SAIFLC - Lignes à facturer (Transaction SAIFLC)
SAILCF - Lignes de facture (Transaction SAILCF)
TGFAA - Génération automatique de factures (Transaction SATGFAA)
TGFAE - Génération automatique de factures (étape) (Transaction SATGFAE)
TDFAA - Duplication de factures (Transaction SATDFA)
TAFAA - Annulation facture (Transaction SATAFA)
GTFCA - Factures achats : Interface (Transaction SAITFC)
TTFCA - Intégration des factures d'achats (Transaction SATTFC)
CSFAA - Sélection des factures d'achats (Transaction SACSFAA)
TSFAA - Sélection des factures d'achats (Transaction SATSFAA)

   Ajout dans le dictionnaire de l'édition des factures :
- du marché ;
- des libellés 1, 2, 3, 4 et 5 ;
- des identifiants 1, 2, 3, 4 et 5 ;
- des numériques 1, 2 et 3 ;
- des dates 1, 2 et 3.

EFAA - Edition des factures (Transaction SAEFAA)

   Ajout dans le dictionnaire de l'édition :
- du marché de la facture ;
- des libellés 1, 2, 3, 4 et 5 de la facture ;
- des identifiants 1, 2, 3, 4 et 5 de la facture ;
- des numériques 1, 2 et 3 de la facture ;
- des dates 1, 2 et 3 de la facture.

LCDA - Liste des commandes ou demandes d'achats (Transaction SALCDA)

   Possibilité d'effectuer ou pas le contrôle du prix facturé par rapport au prix commandé en fonction du mode d'achat des lignes de factures.

   Le prix facturé peut être différent du prix commandé selon le paramétrage de :
- l'article acheté (GATA) ;
- l'occurrence CTLPRIxxxx (où xxxx représente le mode d'achat de la ligne de facture) du paramètre AUTSAFAA ;
- l'occurrence CTLPRI du paramètre AUTSAFAA.

   Si le contrôle des prix n'est pas paramétré au niveau de l'article acheté (la valeur du contrôle prix/montant est égale à "Rien" ou les écarts inférieur ou supérieur ne sont pas renseignés), le contrôle est effectué par rapport à l'occurrence CTLPRIxxxx du paramètre AUTSAFAA.
L'occurrence CTLPRIxxxx du paramètre AUTSAFAA est facultative. Si elle n'existe pas, c'est l'occurrence générale CTLPRI du paramètre AUTSAFAA qui est prise en compte.

SAIFLC - Lignes à facturer (Transaction SAIFLC)
SAILCF - Lignes de facture (Transaction SAILCF)

   Ajout, en facture, de la possibilité de calculer la date d'échéance à partir de la date la plus récente entre la date de réception de la commande et la date de réception de la facture.

   Pour cela, la valeur testée 1 de l'occurrence SAFAA du paramètre AUTSAECH doit être égale à "M".

GFAA - Contrôle facture (Transaction SAIFAA)

   1) Afin que les factures à zéro dues à de la sous-traitance totale ne génèrent plus d'anomalie au niveau de la comptabilisation de la facture (comptes techniques non équilibrés, pas de déclenchement du calcul du prorata de TVA, solde de FNP erroné), il est possible, lors de la génération de factures de co/sous-traitance (SAIGFCS, TGFCSA), de déduire la part du sous-traitant (lignes négatives), non pas sur la même commande que celle du titulaire, mais sur une nouvelle commande de facturation directe associée à la facture du titulaire.

   2) Modification de l'affectation du poste des lignes générées.

   3) Modification de l'affectation de la taxe des lignes générées.

   4) Possibilité d'appliquer les exceptions sur comptes (GCPTA) pour la proposition du compte des échéances des commandes des co-sous/traitants générées (cas de co-sous/traitance avec immobilisation).

   5) Si pour une facture d'un fournisseur titulaire, une erreur de saisie a été détectée sur les co/sous-traitants alors que les factures correspondantes ont été générées (SAIGFCS, TGFCSA), il est désormais possible, si aucune des factures concernées (facture du titulaire et factures des co/sous-traitants) n'a été transférée en comptabilité (TVCC), d'effectuer des modifications afin de pouvoir saisir des nouveaux co/sous-traitants et de re-générer les nouvelles factures de co/sous-traitants.

   6) Le contrôle de cohérence des tiers n'est pas effectué si le co-sous/traitant est saisi sur une ligne de pénalité ou de révision.

   1) Cette possibilité est donnée par la valeur testée 1 du paramètre AUTSACSF occurrence CDENEG. Si la valeur testée 1 est égale à :
- N : les lignes négatives sont créées sur la même commande que celle du titulaire ;
- O : les lignes négatives sont créées sur une nouvelle commande de classe de facturation directe.

   Dans le cas où les lignes négatives sont créées sur une nouvelle commande, un lien (GLCD) est créé entre la commande origine et la nouvelle commande. La création du lien est obligatoire et le type de lien est donné par la chaîne 1 du paramètre AUTSACSF occurrence TYPLCD.

   2) Dans le cas où le compte des lignes générées (lignes négatives et positives) est égal au compte défini dans la chaîne 1 de l'occurrence PROCPT du paramètre AUTSACSF, le poste des lignes est affecté en fonction de la valeur testée 2 de cette même occurrence.
Si la valeur testée 2 vaut :
- N : le poste est égal au poste de la ligne origine ;
- O : le poste est égal au poste défini dans la chaîne 2 de l'occurrence ;
- C : le poste est égal au poste du compte défini dans la chaîne 1 de l'occurrence.
NB : si le compte de la ligne générée est égal au compte de la ligne origine (valeur testée 1 égale à N), alors le poste de la ligne générée est égal au poste de la ligne origine (quelle que soit la valeur testée 2).

   3) La taxe des lignes négatives générées est égale à :
- la taxe de la ligne origine si elle n'a pas été modifiée au niveau de la ligne de co-sous/traitance (SAICSF) ;
- une taxe équivalente à la taxe de la ligne de co-sous-traitance (SAICSF), si elle est différente de la taxe de la ligne origine. Il est recherché une taxe équivalente telle que :
         - le type de taxe est égal au type de taxe de l'en-tête de facture du titulaire,
         - le mode de taxe est égal au mode de la taxe de la ligne de co-sous/traitance,
         - le régime de taxe est égal au régime de la taxe de la ligne de co-sous/traitance,
         - le code taxe est égal au code de la taxe de la ligne de co-sous/traitance,
         - la part de la taxe est égale à la part de la taxe de la ligne de co-sous/traitance.

   La taxe des lignes positives générées est égale à une taxe équivalente à la taxe de la ligne de co-sous-traitance (SAICSF). Il est recherché une taxe équivalente telle que :
- le type de taxe est égal au type de taxe de l'en-tête de facture du co-sous/traitant ;
- le mode de taxe est égal au mode de la taxe de la ligne de co-sous/traitance ;
- le régime de taxe est égal au régime de la taxe de la ligne de co-sous/traitance ;
- le code taxe est égal au code de la taxe de la ligne de co-sous/traitance ;
- la part de la taxe est égale à la part de la taxe de la ligne de co-sous/traitance.

   4) Cette possibilité est donnée par le paramètre CPT associé :
- au mnénonique de génération de factures de co-traitance/sous-traitance (SAIGFCS livré en standard) ;
- au traitement de génération de factures de co-traitance/sous-traitance (SATGFCS livré en standard).

   Si la valeur du paramètre CPT est égale à :
- N : le compte des échéances des commandes des co-sous/traitants est égal au compte proposé par défaut ;
- O : le compte des échéances des commandes des co-sous/traitants est proposé à partir des exceptions sur compte (GCPTA).
La recherche des exceptions sur compte est effectuée pour :
- l'établissement de la facture du co-sous/traitant ;
- le type d'exception égal à "I" (immobilisation) ;
- la classe d'achats de la commande de facturation directe du co-sous/traitant (facultatif) ;
- la position fiscale égale au type de taxe de l'en-tête de la facture du co-sous/traitant (facultatif) ;
- le type de collectif de l'échéance de la commande du co-sous/traitant (facultatif) ;
- le mode d'achat de la première de ligne de la commande du co-sous/traitant (facultatif) ;
- le compte proposé par défaut de l'échéance de la commande du co-sous/traitant ;
- le type de ventilation non renseigné.

   5) Pour cela, il est nécessaire de :
- mettre à l'état « Supprimé » toutes les factures de co-traitance/sous-traitance qui ont été générées pour un titulaire ;
- mettre à l'état « Supprimé » les enregistrements de co-traitance/sous-traitance (SAICSF) concernés et éventuellement les supprimer physiquement ;
- supprimer les lignes de factures négatives correspondant à la sous-traitance sur la facture du titulaire.

   Une fois cela effectué, il sera alors possible de saisir des nouveaux co/sous-traitants sur la facture du titulaire et de re-générer la ou les factures de co/sous-traitants.

SAICSF - Co-traitants/sous-traitants de la facture (Transaction SAICSF)
SAIGFCS - Génér. de factures de co-traitance/sous-traitance (Transaction SAIGFCS)
TGFCSA - Trt de génér. de factures de co/sous-traitance (Transaction SATGFCS)

   1) La mise en place de cette fonctionnalité pouvant nécessiter une modification de paramétrage, veuillez contacter votre responsable Qualiac®.

   Ajout des contrôles des montants HT et TTC de la facture.

   Lors de la mise à jour des montants co-traitant/sous-traitant, si la facture n'est pas encore transférée en comptabilité, il est nécessaire d'effectuer les contrôles d'écarts entre :
- le montant HT de la facture et le montant HT des conditions de facturation (GCAF) ;
- le montant TTC de la facture et le montant TTC des conditions de facturations (GCAF).
Les écarts maximum autorisés sont donnés par le type de ventilation (GTVCA) utilisé pour la comptabilisation de la facture (TVCC). Le type de ventilation est donné par la chaîne 1 du paramètre xCTLFFAA du paramètre AUTSASOL (où x représente la valeur du PR2 associé au traitement de mise à jour des montants co-traitant/sous-traitant).

TMCSA - Mise à jour des montants co-traitant/sous-traitant (Transaction SATMCS)

   1) Prorata de TVA : dans le cas où un mouvement supplémentaire est généré pour la TVA non récupérable, il est possible d'affecter, sur ce mouvement, un CGR A et/ou un poste particulier.

   2) Lors du lissage (GEPL) effectué par le transfert en comptabilité (TVCCx), possibilité de ne pas affecter le montant du lissage dans GEPL.

   1) Cette possibilité est donnée par la valeur testée 2 du paramètre AUTCPT occurrence PROTVA. Si elle est égale à "V" ou "D" :
- le CGR A est égal au texte du paramètre AUTCPT occurrence PROTVA si il est renseigné, sinon il est égal au CGR A du mouvement concernant le code TVA porteur du prorata ;
- le poste est égal à la chaîne 1 du paramètre AUTCPT occurrence PROTVA si elle est renseignée, sinon il est égal au poste du mouvement concernant le code TVA porteur du prorata.

   2) Cette possibilité est donnée par la valeur testée 2 du paramètre TYEOCEDC occurrence le type de traitement utilisé pour le lissage.
Si la valeur testée 2 est égale à :
- O ou n'est pas renseignée : le montant est affecté ;
- N : le montant n'est pas affecté.

TVCCD - Pré-engagement (Transaction SATVCCD)
TVCCE - Engagement (Transaction SATVCCE)
TVCCP - Factures non parvenues (Transaction SATVCCP)
TVCC - Comptabilisation des factures (Transaction SATVCC)
TDEG - Annulation des ventilations (Transaction SATDEG)

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

   Le contrôle est effectué selon la valeur testée 1 de l'occurrence CTLMT1xxxx du paramètre AUTSATAC où xxxx représente la classe d'achats.
Les valeurs 1 et 2 donnent les écarts autorisés entre les montants et sont exprimés en devise de référence de l'établissement.
Ce contrôle est effectué pour chaque sous-commande de la facture.

   Le bon à payer ne peut pas être délivré si :
- la somme des montants facturés est supérieure à la somme des montants réceptionnés en tenant compte du seuil de tolérance donné par la valeur 1 de l'occurrence CTLMT1xxxx du paramètre AUTSATAC ;
- la somme des montants facturés est inférieure à la somme des montants réceptionnés en tenant compte du seuil de tolérance donné par la valeur 2 de l'occurrence CTLMT1xxxx du paramètre AUTSATAC.
Dans le cas d'une réception en montant, le montant réceptionné d'une ligne de facture est égal à la quantité réceptionnée multiplié par le prix réceptionné et par l'unité de prix.
Dans le cas d'une réception en quantité, le montant réceptionné d'une ligne de facture est égal à la quantité réceptionnée (sans les gratuits) multiplié par le prix commandé et par l'unité de prix.

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

TTAC - Bon à payer (Transaction SATTAC)
GTAC - Acceptation de la facture (Transaction SAITAC)
GFAA - Contrôle facture (Transaction SAIFAA)
GFAAD - Facturation détaillée (Transaction SAIFAAD)
GFAAG - Facturation globale (Transaction SAIFAAG)

   Ajout de la possibilité de lancer plusieurs fois le traitement de génération de commandes d'avoir (TGCAVA) pour une commande afin de pouvoir gérer plusieurs types d'écarts pour cette commande.

   Lorsqu'une commande d'écart est générée par le traitement, un lien est généré entre la commande origine et la commande générée. Le type de lien est donné par la chaîne 1 de l'occurrence TYPLCD du paramètre AUTSACAV. Dès lors qu'il existe un lien de ce type pour une commande, le traitement ne peut plus être relancé. Or, le type d'écart étant à la soumission, pour pouvoir gérer plusieurs écarts pour la même commande, il est nécessaire de pouvoir lancer le traitement plusieurs fois. Pour permettre cela, il faut donc pouvoir gérer des liens à la ligne.
Le traitement a donc été modifié dans ce sens. Le paramètre PR1 associé au traitement indique si le lien généré est à la commande ou à la ligne.
Si la valeur du paramètre PR1 vaut :
- C : lien à la commande. Le traitement ne pourra être lancé qu'une seule fois pour une commande ;
- L : lien à la ligne. Le traitement pourra être lancé plusieurs fois pour une commande : autant de fois qu'il y a de type d'écart à traiter.

   La valeur du paramètre PR1, associé au traitement livré en standard, est initialisée à "C" par la release.

   NB : le type de lien (chaîne 1 de l'occurrence TYPLCD du paramètre AUTSACAV) doit être un type de lien commande si la valeur du paramètre PR1 associé au traitement vaut "C" et un type de lien ligne si la valeur du paramètre PR1 vaut "L".

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

   Possibilité d'éditer ou non les en-têtes de colonnes dans le fichier ASCII généré.

   L'édition ou non de l'en-tête de colonnes se paramètre au niveau de la définition de la mise en forme (GTMEF).
Si la case "Edition de l'en-tête" est cochée, la ligne d'en-tête est éditée ;
Si la case "Edition de l'en-tête"n'est pas cochée, la ligne d'en-tête n'est pas éditée.

   Par défaut, dans les éditions de Qualiac® Achats, l'en-tête n'est pas édité.

EANA - Analyse des achats (Transaction SAEANA)

   Ajout de la possibilité de paramétrer la date à laquelle sont recherchées les commandes pour lesquelles il n'y a pas de réception et qui sont pourtant à une étape comprise entre la fourchette d'étapes de réception donnée par le paramétrage de la clôture (GCLOA).
Exemple : commandes d'avoir générées lors d'un retour définitif.

   Pour cela, ajout du paramètre DAT associé au traitement.
Si la valeur du paramètre vaut :
- DCR : recherche des commandes pour lesquelles la date de création est comprise entre la date de dernière et la date de prochaine clôture ;
- DCD : recherche des commandes pour lesquelles la date de commande est comprise entre la date de dernière et la date de prochaine clôture.

   La valeur de ce paramètre est initialisée à "DCR" par la release.

TCLOA - Clôture des achats (Transaction SATCLO)

   Ajout de la possibilité de sélectionner les demandes d'achats ou les commandes à insérer dans la liste à partir de deux rubriques caractères, deux rubriques dates et deux rubriques numériques.

   Pour cela, ajout de quatre rubriques (deux rubriques dates et deux rubriques numériques) dans la forme détail "Rubriques" de la soumission du traitement de constitution de listes (TLSCA).

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

   Ajout de la prise en compte des filtres appliqués sur les données de la grille, dans le calcul des cumuls, lors de l'appui sur le bouton "Cumul sélection".

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é de sélectionner les lignes de demandes d'achats ou de commandes à partir d'une liste de demandes d'achats ou de commandes.

   Pour cela, ajout de la liste dans les critères de sélection des consultations des lignes de demandes d'achats (CLCAD) et des lignes de commandes (CLCA).

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

   Au niveau des gestions d'interface, les champs de types "radio bouton" ou "case à cocher" ont été remplacés par des champs de saisie classique.

   Articles achetés de transfert (GTAA) :
Modification des champs "Génération composants", "Génération composé", "Lien fabricant", "Contrôle qualitatif", "Lissage", "Seuil immobilisation", "Type de frais", "Frais PUMP", "Contrôle quantité ou montant", "Contrôle prix/montant", "Contrôle quantité facturée/reçue" et "Contrôle quantité facturée/commandée".

   Références articles/fournisseurs de transfert (GTRAF) :
Modification du champ "Par défaut".

   Interface des lignes de marché (GTMADA) :
Modification du champ "A traiter".

   Gestionnaires des fournisseurs de transfert (GTGFA) :
Modification du champ "Proposé par défaut".

GTAA - Articles achetés de transfert (Transaction SAITAA)
GTRAF - Références articles/fournisseurs de transfert (Transaction SAITAF)
GTMADA - Interface des lignes de marché (Transaction SAITMD)
GTGFA - Gestionnaires des fournisseurs de transfert (Transaction SAITGF)

   Lors de la saisie de l'article dans GRAF, correction afin de pouvoir visualiser les intitulés des unités logistiques proposées à partir de l'article.

GRAF - Articles référencés par fournisseur (Transaction SAIRAF)

   Correction pour conserver les informations complémentaires des lignes de demandes de services (infsalca) lors de l'intégration.

GTDA - Demandes de services (Transaction SAITDA)
TTDA - Intégration des demandes de services (Transaction SATTDA)

   Correction pour ne plus avoir le message d'erreur "Commande d'achats inexistante (ou d'un autre fournisseur ou sans ligne)" (SACDA001) lors de l'ouverture de la transaction à partir du sas des commandes d'achats (GTCDA).

GTCDA - Commandes d'interface (Transaction SAITCD)
GTAAIA - Informations acompte : Interface (Transaction SAITAI)

   Lors de la modification du regroupement des mouvements comptables, correction de l'accessibilité aux champs identifiants longs et numériques.

GTVCA - Paramétrage transfert comptabilité achat (Transaction SAITVC)

   Correction de l'affectation de l'ouverture semaine de la commande générée : ouverture semaine du dépôt si elle est renseignée sinon, ouverture semaine du fournisseur.

GTDAC - Génération de commandes à partir de DA (Transaction SAITDAC)
TGDAI - Génération automatique de commandes à partir de DA (Transaction SATGDAI)

   Correction afin de prendre en compte l'étape définie dans le paramétrage des textes (GPTXA) lors de la création d'un texte.

GTXT - Textes (Transaction SAITXT)

   Correction d'un problème d'arrondi sur l'unité de prix.

GMLCA - Modification des lignes de commandes (Transaction SAMLCA)

   Correction pour que le dernier signataire soit bien édité.

EBCDA02 - Bon de commande QED (Transaction SAEBCDA2)

   Correction de l'inversion des options "Solde de réception" et "Solde de facture" pour le choix des commandes à prendre en compte.

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

   1) Correction pour éviter une sortie en erreur du programme lors de la prise en compte de la forme sélection des lignes de commandes (CSLCA).

   2) Correction pour éviter une sortie en erreur du programme si la fourchette sur le CGR A est renseignée sur la forme sélection des CGR (CSCPTA).

CVCC - Consultation des ventilations comptables achats (Transaction SACVCC)
CSLCA - Sélection des lignes de commandes (Transaction SACSLCA)
CSCPTA - Sélection des CGR (Transaction SACSCPT)

   Correction, lors de l'ouverture de la forme sélection des marchés (TSMARA), si la préférence utilisateur des séparateurs des milliers est différente de "Espace".

TSMARA - Sélection des marchés (Transaction SATSMAR)

   Correction pour éviter une sortie en erreur du programme dans le cas où une facture à un montant égal à zéro.

EMBCA - Suivi des marchés publics à bons de commande (Transaction SAEMBC)
EMBCAGA - Ed. du suivi des marchés à bons de commande agrégé (Transaction SAEMBCG)

   Contrat'tech Legisway : Intégration des marchés (TLWMARA) :
Le but de cette interface est d'intégrer les données issues de Legisway dans les tables de sas des marchés. Les tables concernées sont :
- SATMR : sas des marchés (GTMARA) ;
- SATMD : sas des lignes de marchés (GTMADA) ;
- SATMP : sas des compléments des marchés publics (GTMPA).

   Cette interface récupère tous les fichiers présents dans le répertoire donné par la soumission. Les fichiers doivent être des fichiers .xml et doivent être visibles depuis le serveur de traitements. L'ensemble des données présentes dans ces fichiers sont intégrées dans les tables de sas.

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

   La plateforme Provigis offre un accès instantané aux attestations légales obligatoires dans le cadre du devoir de vigilance et la lutte contre le travail dissimulé.
Elle donne accès à ses données sous la forme d'un abonnement auquel nos clients doivent souscrire en complément de l'acquisition du module.

   Afin de donner plus de souplesse à ses utilisateurs voulant bénéficier des données de ce service, Qualiac® Achats propose ainsi :
- la possibilité de se connecter automatiquement à Provigis grâce à un utilisateur générique enregistré dans une table de paramétrage ;
- l'ouverture contextualisée de la fiche fournisseur Provigis en fonction du fournisseur consulté dans Qualiac ;
- le marquage d'un fournisseur afin d'indiquer à la plateforme le désir de le "suivre" ;
- la récupération en masse des données de vigilance des fournisseurs dits "suivis" (fonctionnalité disponible fin 2017).

   En terme de paramétrage, il faut d'abord configurer la gestion des services externes achats (GSEA).

SACPVGF - Informations du fournisseur via Provigis (Transaction SACPVGF)

   Nécessité de formation.

   Les données visualisables sont :
- un écran d'accueil regroupant plusieurs informations générales pour le fournisseur connecté ;
- le tiers associé et les informations associées (adresses, domiciliations bancaires, informations millésimées et agréments qualité) ;
- les commandes en cours du fournisseur ;
- les factures en cours du fournisseur.

   Afin que l'accueil fonctionne, il est nécessaire de renseigner deux occurrences du paramètre AUTSAEFO :
- ETPCDE : la valeur 1 représente l'étape maximale des commandes en cours (CPNCC) ;
- ETPFAA : les chaînes 1 et 2 représentent la fourchette de codes litige et la valeur 1 représente l'étape maximale des factures en litige (CPNFL).

CPCAF - Chiffre d'affaires fournisseur (Transaction SACPCAF)
CPNCC - Nombre de commandes en cours (Transaction SACPNCC)
CPNFL - Nombre de factures en litige (Transaction SACPNFL)
CPMAP - Montant en attente de paiement (Transaction SACPMAP)
GTIEP - Identité (Transaction OEPTIE)
GTIAP - Adresses (Transaction OEPTIA)
GTIDPF - Domiciliations bancaires (Transaction OEPTID)
GTIMP - Informations (Transaction OEPTIM)
GTAQP - Agréments qualité (Transaction OEPTAQ)
CPCDA - Commandes d'achats (Transaction SACPCDA)
CPFAA - Factures (Transaction SACPFAA)
CPLCA - Lignes de commandes (Transaction SACPLCA)
CPLCF - Lignes de factures (Transaction SACPLCF)

   Nécessité de formation.

   Modification des colonnes :
TVASAACF - TVA : passe sur 10 caractères

   Ajout de la colonne :
CMOSAASM - Commentaire obligatoire (Obligatoire)

   Modification des colonnes :
TVASACAF - TVA : passe sur 10 caractères
TC1SACAF - TVA 1 origine commande : passe sur 10 caractères
TC2SACAF - TVA 2 origine commande : passe sur 10 caractères
TC3SACAF - TVA 3 origine commande : passe sur 10 caractères
TC4SACAF - TVA 4 origine commande : passe sur 10 caractères
TC5SACAF - TVA 5 origine commande : passe sur 10 caractères
TVCSACAF - TVA origine commande : passe sur 10 caractères

   Modification des colonnes :
TV1SACDA - Première TVA : passe sur 10 caractères
TV2SACDA - Deuxième TVA : passe sur 10 caractères
TV3SACDA - Troisième TVA : passe sur 10 caractères
TV4SACDA - Quatrième TVA : passe sur 10 caractères
TV5SACDA - Cinquième TVA : passe sur 10 caractères

   Modification des colonnes :
TVASACFL - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASACLR - TVA : passe sur 10 caractères

   Ajout des colonnes :
NUESACSF - Numéro interne de la commande générée

   Modification des colonnes :
TVASACSF - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASADAI - TVA : passe sur 10 caractères

   Ajout des colonnes :
UAFSADSM - Utilisateur d'affectation
DAFSADSM - Date d'affectation
HAFSADSM - Heure d'affectation
TAFSADSM - Date et heure d'affectation
SDSSADSM - Statut du dernier signataire

   Ajout des colonnes :
MARSAFAA - Marché
NU1SAFAA - Numérique 1
NU2SAFAA - Numérique 2
NU3SAFAA - Numérique 3
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

   Modification des colonnes :
LIBSAFAA - Libellé : passe sur 60 caractères

   Modification des colonnes :
TVASALCA - TVA : passe sur 10 caractères
TVCSALCA - TVA origine : passe sur 10 caractères

   Modification des colonnes :
TVASALFE - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASAMAD - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASAPPT - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASARAF - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASARDT - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASARPL - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASATAF - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASATCF - TVA : passe sur 10 caractères

   Ajout des colonnes :
MARSATFC - Marché
NU1SATFC - Numérique 1
NU2SATFC - Numérique 2
NU3SATFC - Numérique 3
L01SATFC - Libellé 1
L02SATFC - Libellé 2
L03SATFC - Libellé 3
L04SATFC - Libellé 4
L05SATFC - Libellé 5
G01SATFC - Identifiant 1
G02SATFC - Identifiant 2
G03SATFC - Identifiant 3
G04SATFC - Identifiant 4
G05SATFC - Identifiant 5
DA1SATFC - Date 1
DA2SATFC - Date 2
DA3SATFC - Date 3

   Modification des colonnes :
LIBSATFC - Libellé : passe sur 60 caractères

   Modification des colonnes :
TVASATFF - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASATFL - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASATLC - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASATMD - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASATRL - TVA : passe sur 10 caractères

   Modification des colonnes :
TVASAVLC - TVA : passe sur 10 caractères
TVOSAVLC - Code TVA origine : passe sur 10 caractères
ECHSAVLC - Numéro d'échéance de la pièce : libellé revu, "Numéro d'échéance" remplacé par "Numéro d'échéance de la pièce"

   Modification des colonnes :
TVASAWRN - TVA : passe sur 10 caractères
ECHSAWRN - Numéro d'échéance de la pièce : libellé revu, "Numéro d'échéance" remplacé par "Numéro d'échéance de la pièce"