Cegid XRP Ultimate  |  I3   Actualisé le 06/10/2022
	Ventes
TSCE - Actions réalisées par le traitement d'éclatement des commandes par échéance

Réalisation de l'éclatement en sous-commandes

Les commandes à traiter sont triées par établissement, classe de commandes, numéro et sous-numéro.    Pour que le traitement puisse se réaliser, il faut que l'étape de la commande soit inférieure à celle du traitement TSCE.    Après avoir vérifié la cohérence de l'étape de la commande, le traitement contrôle que la commande comporte au moins une ligne. Ensuite, il vérifie que parmi les lignes de la commande le code échéance soit renseigné et si c'est le cas le traitement d'éclatement est réalisé, sinon l'étape de la commande évolue et aucune modification n'est apportée sur la commande.    Pour chaque commande, les lignes sont triées et regroupées par code échéance. Les lignes dont le mode de vente n'autorise pas l'éclatement en sous-commandes ne sont pas prises en compte. Sur ces lignes, le code échéance est effacé même s'il avait été affecté par les conditions commerciales.    Avant de scinder la commande en plusieurs sous-commandes, le traitement contrôle les codes échéance présents sur les lignes. En fonction du tri des échéances (occurrence TRIECH du paramètre AUTSVSCE), la recherche du code échéance est différente. Si le tri est par code échéance sans priorité d'utiliser toutes les correspondances avec les échéances scindées de l'échéance de la ligne, alors recherche s'il existe un code échéance dans GECH dont : - le délai de règlement est égal à celui de la première échéance de la ligne de commande ; - la date de règlement est égale à celle de la première échéance de la ligne de commande. Si le tri est par code échéance avec priorité d'utiliser toutes les correspondances avec les échéances scindées de l'échéance de la ligne, alors recherche s'il existe un code échéance dans GECH dont : - le délai de règlement de chaque détail est respectivement égal au délai de règlement de chaque détail de l'échéance de la ligne de commande ; - la date de règlement de chaque détail est respectivement égale à la date de règlement de chaque détail de l'échéance de la ligne de commande ; - le pourcentage de chaque détail est respectivement égal au pourcentage de chaque détail de l'échéance de la ligne de commande. Dans les deux cas, les informations suivantes doivent être vérifiées : - le mode de règlement est égal à celui de la première échéance de la commande ou à celui de la première échéance de l'échéance par défaut du client de la commande, s'il n'y a pas d'échéances sur la commande ; - l'état est actif ; - la condition de facturation est égale à celle de l'échéance de la ligne. L'échéance de la ligne ne fait pas obligatoirement référence à une condition de facturation de type "Escompte". Si pas de code échéance trouvé, le traitement est stoppé en erreur. Si un code échéance est trouvé, il est affecté sur la ligne de commande.    Après cette vérification :    1) Si toutes les lignes ont même échéance, alors : - le code échéance est effacé sur toutes les lignes ; - l'échéance de la commande devient égale à celle des lignes ; - la condition de facturation éventuellement associée à l'ancienne échéance de la commande est supprimée de la commande ; - la condition de facturation éventuellement associée à l'échéance des lignes est générée sur la commande, en contrôlant sa cohérence (occurrence CTLECH du paramètre AUTSVCFG) ; - si l'ancienne et la nouvelle condition de facturation sont égales, le taux ou montant à appliquer est mis à jour.    2) Si les lignes ont des codes échéance différents, création d'une sous-commande par code échéance identique. La sous-commande est créée à l'identique de la commande initiale, même classe, même numéro, seul le sous-numéro est incrémenté de 1 en 1. L'échéance de la commande est remplacée par l'échéance des lignes en prenant en compte la condition de facturation associée à l'échéance (même principe que dans le cas 1 ci-dessus). La sous-commande est générée à l'étape du traitement TSCE. La sous-commande générée est valorisée. Si la valeur du paramètre ETP associé au traitement vaut "O" ou si la case "Envoi des traitements" est cochée, les traitements sont exécutés pour les sous-commandes générées. Les traitements exécutés sont tous ceux non encore réalisés, jusqu'à trouver un arrêt proposition dans les étapes par classe (GETCV).    Lorsque toutes les sous-commandes ont été créées, la commande initiale est re-valorisée. La commande initiale conserve les lignes qui n'ont pas entraîné la création de sous-commandes, c'est-à-dire en priorité les lignes sans échéance ou les lignes faisant référence au code échéance le plus fréquent sur l'ensemble de la commande.    Après traitement, il ne doit plus exister de lignes avec le code échéance renseigné, il est effacé sur toutes les lignes.    Le traitement contrôle que le composé et ses composants sont sur la même sous-commande.

Traitement d'une liste de commandes

Si l'élément traité est une liste de commandes, vérification en fonction du paramétrage, si autorisation de traiter des commandes relatives à différents établissements (occurrence V du paramètre AUTLISTE).    Lorsque le traitement se déroule sans anomalie, 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'éclatement des sous-commandes par échéance. 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é au niveau de la commande de conserver 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 (GETCV) que vous indiquez si la mémorisation est active ou non.