Renvoyer les approbations pour la propriété de réévaluation

La propriété d’achat sn_shop.approval.reassessment.resend détermine si une approbation doit être réévaluée à la suite d’une révision ou d’une fusion. La révision peut être celle d’un bon de commande ou d’une demande d’achat. Cette propriété ne s’applique que si la même règle d’approbation est déclenchée. Si une nouvelle règle est déclenchée, cette propriété n’est pas applicable et un nouveau plan d’approbation est généré.

Pour plus d’informations sur les groupes de règles d’approbation et le séquencement, et leur impact sur la propriété, reportez-vous à la section Regroupement et séquencement des règles d’approbation.

Une révision de réduction des fonds n’est pas autorisée si le montant est inférieur à ce qui a déjà été expédié ou livré. Les révisions ne sont pas autorisées sur les lignes rejetées et, par conséquent, la réévaluation des approbations n’est pas applicable.

Pour en savoir plus sur les règles d’approbation, reportez-vous aux sections Types de règles d'approbation et Créer une règle d’approbation.

Lorsqu’une réévaluation d’approbation est envoyée aux approbateurs, le montant approuvé à prendre en compte doit inclure le montant initial de la ligne révisée et l’augmentation des fonds. Par exemple, si le montant initial de la ligne est de 1 000 $ et qu’une augmentation de la révision des fonds fait en sorte que le montant de la ligne est de 1 500 $, le montant à prendre en compte pour la réévaluation et l’approbation est de 1 500 $.

Lorsque la propriété d’évaluation de renvoi des approbations est définie sur Oui, s’il existe un enregistrement de plan d’approbation en cours et qu’une révision ou une fusion se produit avant que le plan ne soit terminé, son état est mis à jour sur N’est plus nécessaire et un nouveau plan est créé. Si la propriété est définie sur Non et si le plan d’approbation existant est en cours, il est réutilisé.

Lors d’une réévaluation d’approbation, le rejet d’une ligne entièrement reçue n’est pas autorisé. Dans ShoppingHub, la ligne entièrement reçue s’affiche sous l’onglet Approuvé .

Renseignement de la date d’échéance sur approbations

Les enregistrements d’approbation parallèles ont la même date d’échéance. Pour les approbations séquentielles, la date d’échéance du premier approbateur est renseignée en fonction de la valeur de propriété définie, la date d’échéance du deuxième approbateur est calculée une fois la première approbation terminée, et ainsi de suite.

Création d’une tâche de révision des approbations violées

Si la date d’échéance d’une approbation n’est pas respectée, une nouvelle tâche est automatiquement créée à l’aide de la tâche planifiée [PSM] Date d’échéance d’approbation non respectée, qui s’exécute une fois par jour. Cette tâche est une tâche d’achat, avec le sous-type Approbation, et est affectée à la même personne que celle à qui la demande d’achat est affectée.

Pour une approbation séquentielle, cette tâche d’achat est créée pour chaque enregistrement d’approbateur en retard. Pour les approbations parallèles, une seule tâche est créée avec une liste connexe affichant tous les enregistrements d’approbateur pertinents qui ont été violés.

La date d’échéance de cette tâche est renseignée avec l’heure de violation sur l’enregistrement d’instance de SLA associé à la définition de SLA pour l’examen des approbations violées.

Pour les approbations qui ne sont plus requises ou qui sont annulées, la création de la tâche de révision des approbations violées n’est pas déclenchée. Les SLA de revue des approbations rompus sont supprimés, car ils ne sont plus nécessaires.