Sommaire
Acceptation des lignes de signatures
Pour une ligne de demande d'achats, de commande, de réception ou de facture, plusieurs lignes de signatures ont pu être créées lors de la génération des lignes de signatures (TLSGD, TLSGC, TLSGR ou TLSGF) en fonction du paramétrage des signataires des lignes (GSGLA).
Une fois les lignes de signatures visées par le ou les signataires (GLSGD, GLSGC, GLSGR ou GLSGF), l'acceptation d'une ligne de commande dépend de l'acceptation de chacune des équivalences qui la composent et de la valeur testée 2 du paramètre AUTSALSG occurrence yLSGxxxx où "xxxx" représente la classe d'achats et "y" représente la valeur du paramètre PR3 associé au traitement d'acceptation.
Si la valeur testée 2 vaut :
- AA :
- s'il existe au moins une équivalence acceptée pour la ligne, la ligne est acceptée ;
- s'il n'existe pas d'équivalence acceptée et qu'il existe au moins une équivalence refusée pour la ligne, la ligne est refusée ;
- s'il existe au moins une équivalence supprimée pour la ligne, la ligne est supprimée.
- AR :
- s'il existe au moins une équivalence acceptée pour la ligne et aucune équivalence supprimée, la ligne est acceptée ;
- si toutes les équivalences sont refusées pour la ligne, la ligne est refusée ;
- s'il existe au moins une équivalence supprimée pour la ligne, la ligne est supprimée.
- RA :
- s'il existe au moins une équivalence refusée pour la ligne, la ligne est refusée ;
- s'il n'existe pas d'équivalence refusée et qu'il existe au moins une équivalence acceptée pour la ligne, la ligne est acceptée ;
- s'il existe au moins une équivalence supprimée pour la ligne, la ligne est supprimée.
- RR :
- s'il existe au moins une équivalence refusée pour la ligne, la ligne est refusée ;
- si toutes les équivalences sont acceptées pour la ligne, la ligne est acceptée ;
- s'il existe au moins une équivalence supprimée pour la ligne, la ligne est supprimée.
Si pour une ligne de commande, l'équivalence n'est pas renseignée sur aucune des lignes de signature, tous les utilisateurs sont au même niveau.
L'acceptation d'une équivalence dépend de l'acceptation d'une ligne. Elle est effectuée selon la chaîne 2 du paramètre AUTSALSG occurrence yLSGxxxx où "xxxx" représente la classe d'achats et "y" représente la valeur du paramètre PR3 associé au traitement d'acceptation.
Si la chaîne 2 vaut :
- TA : une équivalence est acceptée si toutes les lignes de l'équivalence sont acceptées ;
- UA : une équivalence est acceptée si au moins une ligne de l'équivalence est acceptée.
Une demande d'achats, une commande, une réception ou une facture est considérée comme acceptée si toutes les lignes qui la composent sont acceptées.
Si une des lignes de la demande d'achats, de la commande, de la réception est refusée, la demande d'achats ou la commande ne passe pas l'étape du traitement. Il est alors possible d'effectuer un déblocage à partir des gestions correspondantes :
- déblocage des lignes de signatures des demandes d'achats (GDSLD) ;
- déblocage des lignes de signatures des commandes (GDSLC) ;
- déblocage des lignes de signatures des réceptions (GDSLR).
Si une des lignes de la facture est refusée, il est nécessaire que le ou les utilisateurs signataires acceptent cette ligne, à partir de la gestion de signature des lignes de facture (GLSGF), afin que la facture soit acceptée et ainsi que la ou les commandes de la facture passent l'étape du traitement.
Exemples
Traitement d'une équivalence
Chaîne 2 = TA : une équivalence est acceptée si toutes les lignes d'équivalence sont acceptées.
Chaîne 2 = UA : une équivalence est acceptée si au moins une ligne d'équivalence est acceptée.
| Utilisateur | Equivalence | Avis | Avis | Avis | Avis | Avis | Avis | Avis | Avis |
|---|---|---|---|---|---|---|---|---|---|
| User 1 | 10 | Refusée | Refusée | Acceptée | Attente | Attente | Attente | Acceptée | Acceptée |
| User 2 | 10 | Acceptée | Refusée | Acceptée | Refusée | Acceptée | Attente | Refusée | Supprimée |
| User 3 | 10 | Acceptée | Acceptée | Acceptée | Consultée | Consultée | Consultée | Consultée | Consultée |
| Chaîne 2 = TA | Refusée | Refusée | Acceptée | Refusée | Non traitée | Non traitée | Refusée | Supprimée | |
| Chaîne 2 = UA | Acceptée | Acceptée | Acceptée | Refusée | Acceptée | Non traitée | Acceptée | Supprimée |
Traitement d'une ligne
| Utilisateur | Equivalence | Avis | Avis | Avis | Avis | Avis | Avis | Avis | Avis | Avis | Avis | Avis | Avis | Avis |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| User 1 | 10 | |||||||||||||
| User 2 | 10 | R | R | A | R | A | 0 | A | A | 0 | R | A | 0 | S |
| User 3 | 10 | |||||||||||||
| User 1 | 20 | |||||||||||||
| User 2 | 20 | R | A | A | 0 | 0 | 0 | A | 0 | 0 | 0 | 0 | 0 | A |
| User 3 | 20 | |||||||||||||
| User 1 | 30 | |||||||||||||
| User 2 | 30 | R | R | R | R | R | R | A | A | A | 0 | 0 | 0 | 0 |
| User 3 | 30 | |||||||||||||
| Valeur testée 2 = AA | R | A | A | R | A | R | A | A | A | R | A | 0 | S | |
| Valeur testée 2 = AR | R | A | A | 0 | A | 0 | A | A | A | 0 | A | 0 | S | |
| Valeur testée 2 = RA | R | R | R | R | R | R | A | A | A | R | A | 0 | S | |
| Valeur testée 2 = RR | R | R | R | R | R | R | A | 0 | 0 | R | 0 | 0 | S |
R pour Refusée, A pour Acceptée, S pour Supprimée, 0 pour non traitée (consultée ou en attente).
Eclatement des lignes
Lors du traitement d'acceptation des lignes de signatures des demandes d'achats ou des commandes, il est possible, selon le paramètre AUTSASLSG occurrence yECLLSG où "y" représente la valeur du paramètre PR3 associé au traitement, d'éclater les lignes de demandes d'achats ou de commandes qui sont considérées comme étant à "Supprimée" ou à "Refusée". Ceci permet d'avoir sur la demande d'achats ou commande initiale uniquement les lignes qui sont considérées comme étant à "Acceptée".
Dans ce cas, une sous-demande ou une sous-commande est créée à l'identique de la sous-commande initiale : même classe, même numéro. Le sous-numéro est incrémenté de 1 en 1.
La sous-demande ou la sous-commande est créée à l'étape où se situe la sous-demande ou la sous-commande initiale.
Les informations annexes associées à l'en-tête de la sous-demande ou de la sous-commande initiale sont dupliquées sur la sous-commande générée : gestionnaires (GCAG), échéances (GCAE), conditions de facturation (GCAF), textes avec ligne à 0 (GTXT), paramètres avec ligne à 0 (GCAPE), ventilations par CGR avec ligne à 0 (GVCG), rubriques avec ligne à 0 (GRUCA) et liens avec numéro de ligne non renseigné (GLCD) et dont le domaine est donné par la gestion des domaines des liens à dupliquer (GDLDA).
Les informations annexes associées aux lignes de la sous-demande ou de la sous-commande initiale passent sur les lignes de la sous-commande générée (le numéro interne de commande est mis à jour) : textes sur ligne (GTXT), paramètres sur ligne (GCAPL), ventilations par CGR sur ligne (GVCG), rubriques sur ligne (GRUCA), détails de remises (GDRLA), conditions de facturation des lignes (SAICFL), les liens sur ligne (GLCD) dont le domaine est égal au domaine donné par la gestion des domaines des liens à dupliquer (GDLDA) et les lignes de signatures (CLSGA).
Suivant l'occurrence yECLLSG du paramètre AUTSALSG où "y" représente la valeur du paramètre PR3 associé au traitement d'acceptation, il est possible de générer un lien entre la sous-commande initiale et la sous-commande générée. Le type de lien est donné par cette même occurrence.
L'utilisateur de création et la date de création des sous-demandes ou des sous-commandes générées sont affectés en fonction de l'occurrence USRTRF du paramètre AUTACHAT.
S'il existe un pré-engagement pour la demande d'achats origine ou un engagement pour la commande origine, les ventilations comptables (CVCC) correspondantes sont éclatées entre la demande d'achats origine ou la commande origine et la sous-demande ou sous-commande générée.
Suppression des lignes
Lors de la signature des lignes des demandes d'achats ou des commandes (GLSGD, GLSGC), il est possible de mettre des lignes à l'état de signature "Supprimé".
Une ligne de demande d'achats ou de commande est considérée comme "Supprimée" dès lors qu'une équivalence pour la ligne est à l'état "Supprimé".
Si pour toutes les lignes de la demande d'achats ou de la commande traitée, il existe au moins une équivalence avec l'état signature "Supprimé", la demande d'achats ou la commande traitée est annulée et passe à une étape "poubelle" (étape du traitement d'annulation d'une commande (TSRD)).
Si pour une ligne de la demande d'achats ou de la commande traitée, il existe au moins une équivalence avec l'état signature "Supprimé" et il existe au moins une ligne avec l'état signature égal à "Accepté", selon l'occurrence yECLLSG du paramètre AUTSALSG où "y" représente la valeur du paramètre PR3 associée au traitement, soit la ligne de demande d'achats ou de commande est supprimée, soit la demande d'achats ou la commande est éclatée.
Dans le cas où la demande d'achats ou la commande est éclatée, l'éclatement est effectué comme décrit ci-dessus.
La nouvelle sous-demande ou sous-commande générée est annulée et passe à une étape "poubelle" (étape du traitement d'annulation d'une commande (TSRD)).
Si la demande d'achats ou la commande n'est pas éclatée, la ligne de demande d'achats ou de commande est supprimée physiquement. Dans ce cas :
- les mises à jour des stocks et des marchés sont effectuées pour la ligne supprimée ;
- s'il existe un pré-engagement pour la demande d'achats origine ou un engagement pour la commande origine, une écriture est générée afin d'annuler l'écriture origine. Cette écriture est identique à celle qui aurait été générée par le traitement d'annulation en comptabilité (TDEG) si la demande d'achats ou la commande avait suivi un cycle normal. Un nouvel pré-engagement ou engagement est alors fait pour la demande d'achats ou pour la commande traitée en tenant compte des lignes supprimées ;
- si la demande d'achats ou la commande traitée a été transférée en statistiques, elle est annulée des statistiques et elle est re-traitée en tenant compte des lignes supprimées ;
- les tables annexes liées à la ligne sont également supprimées : textes sur ligne (GTXT), paramètres sur ligne (GCAPL), ventilations par CGR sur ligne (GVCG), rubriques sur ligne (GRUCA), détails de remises (GDRLA), conditions de facturation des lignes (SAICFL), les liens sur ligne (GLCD) et les lignes de signatures (CLSGA).
Contrôles des lignes de factures
Lors de l'acceptation des lignes de factures (TASLF), une fois le contrôle des lignes de signatures effectué et toutes les lignes acceptées, il est possible d'effectuer des contrôles supplémentaires sur les lignes de factures :
- contrôle des prix ;
- contrôles des quantités ;
- contrôle qualité.
Même si l'un de ces contrôles est bloquant, la facture est acceptée. La ou les commandes de la facture passent l'étape du traitement d'acceptation.
Contrôle des prix : contrôle de l'écart entre le prix facturé et le prix commandé pour chacune des lignes de la facture.
Le contrôle est effectué selon la valeur testée 1 de l'occurrence CTLPRXxxxx du paramètre AUTSATAC où xxxx représente la classe de commandes d'achats.
La facture n'est pas acceptée si pour une des lignes de la facture :
- le prix facturé est supérieur au prix commandé avec un pourcentage de tolérance donné par la valeur 1 de l'occurrence CTLPRXxxxx du paramètre AUTSATAC ;
- une ligne est créée lors du contrôle facture (GFAA) : un écart de prix est alors systématiquement détecté.
Si le pourcentage de tolérance n'est pas renseigné, aucun contrôle n'est effectué.
Les écarts de prix peuvent être visualisés dans la grille des lignes de factures (SAILCF).
Contrôle des quantités : contrôle de l'écart entre la quantité facturée et la quantité commandée pour chacune des lignes de la facture.
Le contrôle est effectué selon la valeur testée 1 de l'occurrence CTLQTExxxx du paramètre AUTSATAC où xxxx représente la classe de commandes d'achats.
La facture n'est pas acceptée si pour une des lignes de la facture :
- la quantité facturée est supérieure à la quantité commandée avec un pourcentage de tolérance donné par la valeur 1 de l'occurrence CTLQTExxxx du paramètre AUTSATAC ;
- une ligne est créée lors du contrôle facture (GFAA) : un écart de quantité est alors systématiquement détecté.
Si le pourcentage de tolérance n'est pas renseigné, aucun contrôle n'est effectué.
Les écarts de quantités peuvent être visualisés dans la grille des lignes de factures (SAILCF).
Contrôle qualité : il est possible d'accepter la facture selon le code qualité des lignes de la facture si la réception qualité (GRQL) a été effectuée.
Le contrôle est effectué selon la valeur testée 1 de l'occurrence CTLQALxxxx du paramètre AUTSATAC où xxxx représente la classe de commandes d'achats. Si toutes les lignes réceptionnées qui portent sur un article pour lequel le contrôle qualitatif est actif au niveau de l'article acheté (GATA) ont un code qualité supérieur au code qualité de référence, alors la facture est acceptée. Le code qualité de référence est donné par la chaîne 1 de l'occurrence CTLQALxxxx du paramètre AUTSATAC. Aucun contrôle de qualité n'est effectué si la chaîne 1 n'est pas renseignée.
Mise à jour des commandes
Si le traitement se déroule sans anomalie, l'étape des commandes est égale à l'étape du traitement.
La mise à jour est réalisée si l'étape de la commande est strictement inférieure à l'étape du traitement. Le traitement ne peut être effectué qu'une seule fois.
Mise à jour, sur la commande, de la date de la dernière étape réalisée, elle est égale à la date à laquelle est exécuté le traitement.
Traitement d'une liste de commandes
Lorsque le traitement s'est déroulé sans anomalie pour au moins une commande et qu'il est lancé par liste, modification de la liste pour indiquer la dernière étape réalisée.
Mise à jour de l'étape : elle est égale à l'étape du traitement d'acceptation des lignes de signatures.
Mise à jour de la date de dernier traitement.
Mise à jour de l'utilisateur ayant réalisé le traitement.
Mise à jour du dernier traitement réalisé.
Historique de l'étape
Comme pour toutes les transactions référencées dans les étapes, possibilité de conserver, au niveau de la commande, une trace de l'étape réalisée. Création de cet historique en indiquant le numéro de l'étape, l'utilisateur ayant effectué l'étape, ainsi que la date et l'heure de réalisation de l'étape.
C'est lors de la définition de l'étape par classe (GETCA) que vous indiquez si la mémorisation est active ou non.