|
Standard |
Ce paramètre permet, en validation de facture, de gérer des cumuls au niveau de certaines conditions tarifaires.
Au niveau de la génération des ristournes, il est possible de mettre à jour ces cumuls.
Il permet également de personnaliser la gestion des primes de volume dans le cadre de la collecte des céréales (gestion des primes de campagne).
|
Attention En C/S, en dehors de l’option N1=1 et le mode reprise par la fonction GRIHE, le paramètre ne fonctionne actuellement qu’avec le moteur de validation de facture. Il n’est pas compatible avec le paramètre GENECR. Il faut donc, si l'interface comptable est désactivée, mettre en place un paramétrage minimum (journal des ventes). D’autre part, seul le contrat d’entête d’événement est utilisé pour la recherche des conditions tarifaires (CTS) de type Qui = 4 (contrat) (même en présence du paramètre NUMCNT avec A2=P) |
Fonctions concernées : GBFA - GRIH – GRIHE -
Utilisation avec d’autres paramètres :
| L1 |
|
Contient une concaténation (par série de 3 caractères) des types de conditions tarifaires concernées. Par défaut, elles sont de type RIA. Exemple : « RIALIGPAN » pour les types de condition « RIA », « LIG » et « PAN ». |
| A1 | = O |
|
Dans GCTV, permet de modifier les cumuls manuellement. Remarque : il faut que le mode des types de seuil soit renseigné par 1, 3 (cumul sur Chiffre d'Affaires) ou 2, 4 (cumul sur quantité) pour que les cumuls soient réalisés. Pour en savoir plus, consultez la documentation de référence GTTSE. Pour la mise à jour du CA atteint (CTS.mtacquis) des conditions tarifaires de mode seuil 1, 3 (cumul sur Chiffre d'Affaires), le montant par défaut est le montant du poste, calculé ainsi : (evp.qtecde – evp.qtegrt) * evp.prxvdu). |
| N1 | = 1 |
Le traitement différé de génération déclenche d’abord la mise à jour des conditions tarifaires (CTS) de prime de volume (mode « majria »), sur la base du fichier d’extension « .ext », avant de procéder à la génération des avoirs/factures (mode « generer »). Le mode « majria » et le mode « generer » sont déclenchés au cours du même traitement différé, en un seul lancement). Cette option peut être utilisée en mode « simuler ». Dans ce cas, les CTS sont mises à jour lors de la première simulation, l’indicateurEVR.indtrt passe à 1 pour ne pas les traiter une deuxième fois. |
|
|
|
Le lancement du traitement sur une sélection plus restrictive donnera un calcul faussé. En effet, le seuil sera basé sur un cumul fait sur les sélections des simulations précédentes et celui-ci prendra en compte des événements non sélectionnés dans le traitement en cours. Dans le cas contraire où l’on élargit la sélection (exemple : traitement d’une période plus grande, …), cela ne posera pas de problème. |
||
| N2 |
Permet de piloter la date de référence utilisée pour le cumul des valeurs atteintes dans les CTS (de mode seuil 1, 2, 3, 4 et 7) dans le mode N1=1 Attention : cette option ne pilote pas la date utilisée pour la recherche des CTS de ristourne (qui reste EVE.dateve en mode non cumul, la date de traitement en mode application sur cumul de CA et/ou de quantité). |
||
| = 1 |
Pour la date provenant de l’entête d’événement courant, on utilise la date d’expédition (eve.datexp). |
||
| = 2 |
Pour la date provenant de l’entête d’événement courant, on utilise la date de livraison (eve.datliv). |
||
| = 3 |
Pour la date provenant de l’entête d’événement courant, on utilise la date de validation (eve.datval). |
||
| = 10 |
Pour la date provenant de l’entête de l’événement d’origine du poste courant, on utilise la date d’expédition (eve.datexp). |
||
| = 11 |
Pour la date provenant de l’entête de l’événement d’origine du poste courant, on utilise la date d’expédition (eve.datexp). |
||
|
= 12 |
Pour la date provenant de l’entête de l’événement d’origine du poste courant, on utilise la date de livraison (eve.datliv). |
||
| = 13 | Pour la date provenant de l’entête de l’événement d’origine du poste courant, on utilise la date de validation (eve.datval). |
