|
Depuis la version ACE 5.0-00, Edition Spéciale 1 , les formats d’intégrateur commencent à la position n° 1 (et non plus à la position n° 0, comme auparavant). |
- Si l’événement existe déjà, alors on force la valeur du type de mise à jour à 2 (Modification).
- Si l’événement n’existe pas alors on force la valeur du type de mise à jour à 1 (Création).
- Dans le cas de l’option Gérer, l’identifiant de l’en-tête de l’événement est obligatoire (Achvte/Typeve/Numeve).
En supprimant l’entête, tout est supprimé. Si ce n’est pas le cas (par exemple s’il reste encore des lignes, ou des commentaires ou des postes de frais divers...), le système envoie un message d’erreur non bloquant.
En création
Il est possible de positionner dans le fichier le caractère tilda « ~ » à la place des champs suivants : sigtie, dateve, datliv, datexp, codeta, refext, coddev, pardev, numadr, sigtra, modtra, sigrep, modrgl, delrgl, coddpt, codqua, posfis, codtva, libcom, sigdep, codctg, datcre, codbar.
Dans ce cas, l’intégrateur reprend les valeurs de ces champs dans les éléments de l’entête de l’événement origine.
1) Si le numéro d’événement n’est pas renseigné, le système attribue automatiquement un numéro à l’événement en fonction du code achat/vente (achvte) et du type d’événement (typeve) paramétrés pour la fonction .
2) Si les dates de livraison et d’expédition ne sont pas renseignées, elles sont calculées automatiquement à partir des informations paramétrées pour la fonction .
3) Si l’on n’a pas cité un événement origine, les informations suivantes sont alimentées avec les données du tiers :
| Type de facturation | typfac |
| Nombre de factures | nbrfac |
| Périodicité de facturation | perfac |
| Taux d’escompte | tauesc |
| Mode de livraison | modliv |
La zone Date client (datcli) est initialisée « à blanc ».
De même, si elles n’ont pas été alimentées au niveau du fichier, les informations suivantes sont récupérées au niveau du tiers :
| Sigle transporteur | sigtra |
| Mode de transport | modtra |
| Sigle représentant | sigrep |
| Mode de règlement | modrgl |
| Délai de règlement | delrgl |
| Code départ | coddpt |
| Quantième | codqua |
| Position fiscale | posfis |
- Date de l’événement (dateve) = date du jour si non renseignée dans l’entête d’événement. Code devise (coddev) := code devise du tiers sinon devise nationale (paramètreDEVNAT ).
- Parité de la devise (pardev) = dev.pardev
- Numéro d’adresse (numadr) = 1
- Date de règlement (datrgl) : calculée par rapport aux données de règlement (code départ, quantième, délai ...).
4) Si l’on a cité un événement origine…
L’entête de l’événement est créé avec les éléments de l’entête de l’événement origine
Si le code fonction est égal à GBFA, l’entête de l’événement est créé avec les éléments de l’entête de l’événement origine mais les informations suivantes sont alimentées avec les informations de la commande (événement origine de l’événement origine) :
| Nombre de facture | nbrfac |
| Type de facturation | typfac |
| Périodicité de facturation | perfac |
| Code devise | coddev |
| Parité de la devise | pardev |
| Montant de l’acompte | monaco |
| Date de l’acompte | dataco |
| Taux d’escompte | tauesc |
| Mode de règlement | modrgl |
| Code départ | coddpt |
| Délai de règlement | delrgl |
| Code quantième | codqua |
| Type de remise | typrem |
| Taux de remise | taurem |
| Taux de remise 2 | taurem2 |
| Taux de remise 3 | taurem3 |
| Montant de la remise | monrem |
| Taux de commission | taucom |
| Numéro de contrat | numcnt |
| Sigle représentant | sigrep |
| Code analytique 1 | codana |
| Code analytique 2 | codana1 |
| Code analytique 3 | codana2 |
| Position fiscale | posfis |
| Libellé complémentaire | libcom |
La zone Date client (datcli) est initialisée « à blanc » si on simule le binaire GBFA.
|
|
Attention Si l'évènement d'origine possède une date client (datcli), et que, sur la ligne d'enregistrement du fichier à intégrer, le binaire (et non le code fonction associé) GCOV ouGBLV est simulé, la date client est initialisée avec la date client de l'évènement d'origine. Cette règle ne s’applique pas si le paramètre FACDAT est positionné sur la fonction utilisant GBFA. |
5) Si le sigle tiers n'est pas renseigné, on rapatrie le sigle tiers du dernier tiers intégré, s'il existe. Cette fonctionnalité permet d'intégrer simultanément un format tiers suivi d'un format d'entête d'événement commercial.
En suppression
Si on supprime l'en-tête, on vérifie qu'il n'existe plus de postes avant d'activer la suppression, et on supprime tout ce qui est associé à l'entête (commentaires, données complémentaires, frais divers, ...).
S'il existe au moins un poste, l'événement n'est pas supprimé.
En validation
La validation d’un enregistrement ne peut intervenir qu’en modification (typmaj = 2).
· Avant la version ACE 1.2, la validation génère d’abord une modification de l’enregistrement (en-tête) puis la validation de l’événement.
· Depuis la version ACE 1.2 (comprise), la validation modifie uniquement le champ « codeta ».
La validation sera effectuée si le code état est positionné avec le caractère « ~ ».
S’il y a besoin de valider directement, il suffit de créer l’enregistrement à l’état « V » et de paramétrer une opération de stock de mise à jour adéquate.
En modification
Il est possible de positionner dans le fichier le caractère tilda « ~ » à la place des champs suivants : sigtie, dateve, datliv, datexp, codeta, refext, coddev, pardev, numadr, sigtra, modtra, sigrep, modrgl, delrgl, coddpt, codqua, posfis, codtva, libcom, sigdep, codctg, datcre, codbar.
Dans ce cas, l’intégrateur reprend les anciennes valeurs de ces champs dans l’enregistrement EVE correspondant.
En règle générale, en modification, lorsque la donnée n’est pas initialisée, le système laisse la donnée initiale. Ceci est vrai sauf pour les infos dateve, datliv, datexp, refext, codtva, codctg et datcre pour lesquelles il faut obligatoirement passer par le caractère « ~ » si on veut conserver les données initiales.
4) Si code état n’est pas renseigné, on tient compte du paramétrage de la fonction. Si le code état associé à ce paramétrage est également vide, la valeur « C » est prioritaire.
4) Si la date de dernière modification n’est pas renseignée, la date du jour est prise par défaut.
En confirmation d’une commande Extranet Fournisseur
Un format C5 permet la confirmation d’une commande côté Extranet Fournis
La confirmation d’un enregistrement ne peut intervenir qu’en modification (typmaj = 2) sur une commande (codfct = GCOV).
Le paramètre GESCONF.N1=1 doit être positionné sur la cible qui sert à la confirmation via l’intégrateur. La valeur 1 indique que l’on est côté Extranet Fournisseur. Les paramètres STAEVE1 et STAEVE2 sont également nécessaires. Ce paramétrage permet de contrôler les autorisations d’accès en modification aux lignes prévisionnelles de la commande.
La confirmation n’est possible que s’il n’existe plus de ligne à traiter par le fournisseur sur le portail Extranet Fournisseur, c'est-à-dire des lignes dont le statut est ‘A confirmer’ ou ‘En conflit’. Un message d’erreur bloquant est alors affiché (code EX_LIGCONF).
La confirmation effectue les mises à jour suivantes:
- Création d’une nouvelle version de lignes prévisionnelles dans la table EVL_PRV par duplication des lignes prévisionnelles de
version 0. Sur la nouvelle version, mise à jour des données suivantes:
-
Utimajconf avec l’agent ayant confirmé
- Datmajconf avec la date de confirmation
-
Heumajconf avec l’heure de confirmation
Les lignes de cette nouvelle version correspondent à la proposition du fournisseur qui sera archivée une fois la confirmation terminée et consultable via l’icône Historique sur l’écran de confirmation de la commande côté BTOE.
-
- Mise à jour de données sur les lignes de la version 0:
-
Indicateur de saisie : valeur 1 (modification possible, suppression impossible). Les lignes de la version 0 correspondent aux lignes qui seront accessibles par l’acheteur sur l’écran de confirmation de la commande côté BTOE une fois la confirmation terminée.
- Version précédente : mis à jour avec le numéro de la nouvelle version créée.
-
- Mise à jour du statut de l’entête de l’événement (champ « statut_eve ») avec le statut le plus pessimiste des lignes prévisionnelles de la commande.
| Nom | Désignation |
Version ACE |
Position | Taille | Valeurs | Type | Règles de gestion | |
| typenr | Type d'enregistrement | 4.1-00 | 1 | 2 | 01 | Num | Entête d'événement. | |
|
11 C5 |
Validation d'événement. Confirmation d’une commande Extranet Fournisseur. |
|||||||
| typmaj | Type de mise à jour | 4.1-00 | 3 | 1 | 1 | Num | Création d'un événement. | |
| 2 | Modification d'un événement. | |||||||
| 3 |
Suppression d'un événement.
|
|||||||
| 5.0-00 | 5 |
Invalidation d'événement. L’invalidation d’un enregistrement ne peut intervenir qu’en modification (typmaj = 2).
En invalidation seuls les champs suivants sont obligatoires : Typenr, typmaj, Fonc, Codpev et Numeve
|
||||||
| 9 |
Gestion (création ou modification) d'un événement.
|
|||||||
| codfct | Binaire à simuler | 4.1-00 | 4 | 8 | GCOV | Char |
Gestion des commandes.
|
|
| GBLV |
Gestion des bons de livraison.
|
|||||||
| GBFA |
Gestion des factures et avoirs.
|
|||||||
| codpev |
Code transaction (Cible)
|
4.1-00 | 12 | 8 | Char |
Code de la fonction dont l'intégrateur doit reproduire les règles de gestion, c'est à dire le comportement. Doit obligatioirement être renseigné. Doit être définie dans le configurateur fonctionnel GPEV.
|
||
| numeve_7 | Numéro d’événement | 4.1-00 | 20 | 7 | ZZZZZZZ | Num |
Si numéro événement compris entre 10 000 000 et 999 999 999 alors c’est le champ numeve en position 648.
|
|
| sigtie |
Sigle tiers
|
4.1-00 | 27 | 12 | Char | Doit être défini dans la table des tiers GTIE. | ||
| numevo_7 | Numéro de l’événement origine | 4.1-00 | 39 | 7 | ZZZZZZZ | Num |
Si numéro événement origine compris entre 10 000 000 et 999 999 999 alors c’est le champ numevo en position 657.
|
|
| dateve |
Date de l’événement
|
4.1-00 | 46 | 8 | AAAAMMJJ | Date | ||
| datliv |
Date de livraison
|
4.1-00 | 54 | 8 | AAAAMMJJ | Date | ||
| datexp |
Date d’expédition
|
4.1-00 | 62 | 8 | AAAAMMJJ | Date | ||
| codeta |
Code état de l’entête
|
4.1-00 | 70 | 1 | Char | |||
| refext_16 |
Référence externe
|
4.1-00 | 71 | 16 | Char |
Depuis la version ACE 1.60, ce champ est remplacé par le champ refext (position 763) géré sur 30 caractères au format UTF8. Néanmoins, il reste actif si le champ refext n’est pas alimenté.
|
||
| coddev |
Code devise
|
4.1-00 | 87 | 3 | Char | Doit être défini dans la table des devises GDEM. | ||
| pardev |
Parité de la devise
|
4.1-00 | 90 | 10 | ZZZZZZZ.ZZ | Dec | ||
| numadr |
Numéro d’ordre de l’adresse
|
4.1-00 | 100 | 3 | ZZZ | Num |
|
|
| sigtra |
Sigle transporteur
|
4.1-00 | 103 | 12 | Char | |||
| modtra |
Mode de transport
|
4.1-00 | 115 | 2 | Char | |||
| sigrep |
Sigle représentant
|
4.1-00 | 117 | 12 | Char | |||
| modrgl |
Mode de règlement
|
4.1-00 | 129 | 2 | Char | |||
| delrgl |
Délai de règlement
|
4.1-00 | 131 | 3 | ZZZ | Num | ||
| coddpt |
Code départ
|
4.1-00 | 134 | 1 | Char | |||
| codqua |
Quantième
|
4.1-00 | 135 | 2 | ZZ | Num | ||
| Posfis_1 |
Position fiscale
|
4.1-00 | 137 | 1 | Char |
Depuis la version ACE 1.6.0, ce champ est remplacé par le champ posfis (position 1605) géré sur 6 caractères. Néanmoins, il reste actif si le champ posfis n’est pas alimenté.
|
||
| codtva |
Code TVA
|
4.1-00 | 138 | 1 | Char | |||
| libcom_30 |
Libellé complémentaire
|
4.1-00 | 139 | 30 | Char |
Depuis la version ACE 1.60, ce champ est remplacé par le champ libcom (position 883) géré au format UTF8. Néanmoins, il reste actif si le champ libcom n’est pas alimenté.
|
||
| sigdep |
Sigle dépôt
|
4.1-00 | 169 | 12 | Char | |||
| codctg |
Catégorie d’événement
|
4.1-00 | 181 | 2 | Char |
|
||
| datcre |
Date création
|
4.1-00 | 183 | 8 | AAAAMMJJ | Date | ||
| etbcod | Code établissement | 4.1-00 | 191 | 3 | Char |
En mode multi établissements, doit être défini dans la liste des établissements(GETS). Le statut de l’événement sera alors positionné à 1 (entité mono-établissement).
|
||
| numfil |
N° de filière
|
4.1-00 | 194 | 3 | ZZZ | Num | ||
| codbar |
Code barème
|
4.1-00 | 197 | 3 | Char | |||
| numcnt |
Numéro de contrat
|
4.1-00 | 200 | 9 | Char | |||
| datval |
Date de validation
|
4.1-00 | 209 | 8 | AAAAMMJJ | Char | ||
| typliv |
Type du tiers livré
|
4.1-00 | 217 | 3 | Char | |||
| sigliv |
Sigle du tiers livré
|
4.1-00 | 220 | 12 | Char | |||
| codtrn |
Code tournée
|
4.1-00 | 232 | 6 | Char | |||
| typfac |
Type de facturation
|
4.2-00 | 238 | 3 | ZZZ | Num | ||
| nbrfac |
Nombre de factures
|
4.2-00 | 241 | 1 | Z | Num | ||
| perfac |
Code périodicité de facturation
|
4.2-00 | 242 | 1 | Char | |||
| tauesc |
Taux d'escompte
|
4.2-00 | 243 | 6 | ZZZ.ZZ | Dec | ||
| taurem |
1er taux de remise globale
|
4.2-00 | 249 | 6 | ZZZ.ZZ | Dec | ||
| taurem2 |
2ème taux de remise globale
|
4.2-00 | 255 | 6 | ZZZ.ZZ | Dec | ||
| taurem3 |
3ème taux de remise globale
|
4.2-00 | 261 | 6 | ZZZ.ZZ | Dec | ||
| monrem |
Montant de la remise
|
4.2-00 | 267 | 10 | ZZZZZZZ.ZZ | Dec | ||
| datcli |
Date comptable
|
4.2-00 | 277 | 8 | Char | |||
| modliv |
Code mode de livraison
|
4.2-00 | 285 | 3 | Char | |||
| modloc_30 |
Localité associée
|
4.2-00 | 288 | 30 | Char |
Depuis la version ACE 1.60, ce champ est remplacé par le champ modloc (position 1003) géré au format UTF8. Néanmoins, il reste actif si le champ modloc n’est pas alimenté.
|
||
| codurg |
Code urgence
|
4.2-00 | 318 | 1 | Num | |||
| relica |
Indicateur reliquat
|
4.2-00 | 319 | 1 | Char | |||
| p_ribcod |
Code de la domiciliation bancaire
|
4.2-00 | 320 | 3 | Char | |||
| totht |
Montant hors taxe
|
4.2-00 | 323 | 12 | ZZZZZZZ.ZZ | Dec |
Uniquement pris en compte pour les achats pour GBFA.
|
|
| cumtva |
Montant TVA
|
4.2-00 | 335 | 12 | ZZZZZZZ.ZZ | Dec | Uniquement pris en compte pour les achats pour GBFA. | |
| datrgl |
Date d’échéance
|
4.2-00 | 347 | 8 | AAAAMMJJ | Date | ||
| sigtrs |
Sigle transitaire
|
4.2-00 | 355 | 12 | Char | |||
| numlcr |
Numéro de lettre de crédit
|
4.2-00 | 367 | 7 | Num | |||
| batvol_30 |
Nom du bateau ou numéro de vol
|
4.2-00 | 374 | 30 | Char |
Depuis la version ACE 1.60, ce champ est remplacé par le champ batvol (position 1123) géré au format UTF8. Néanmoins, il reste actif si le champ batvol n’est pas alimenté.
|
||
| cmpnie_30 |
Compagnie
|
4.2-00 | 404 | 30 | Char |
Depuis la version ACE 1.60, ce champ est remplacé par le champ cmpnie (position 1243) géré au format UTF8. Néanmoins, il reste actif si le champ cmpnie n’est pas alimenté.
|
||
| nlta_30 |
Numéro de document de transport
|
4.2-00 | 434 | 30 | Char |
Depuis la version ACE 1.60, ce champ est remplacé par le champ nlta (position 1363) géré au format UTF8. Néanmoins, il reste actif si le champ nlta n’est pas alimenté.
|
||
| datdep |
Date de départ
|
4.2-00 | 464 | 8 | Char | |||
| datarr |
Date d'arrivée
|
4.2-00 | 472 | 8 | Char | |||
| heuarr |
Heure d'arrivée
|
4.2-00 | 480 | 8 | Char | |||
| heudep |
Heure de départ
|
4.2-00 | 488 | 8 | Char | |||
| guidrgl |
Guide de règlement
|
4.2-00 | 496 | 3 | Char | |||
| codeop |
Opération commerciale
|
4.2-00 | 499 | 12 | Char |
Si le paramètreGESOPEest positionné dans le paramétrage de la fonction avec N1=1, alors le système considère que ce champ correspond à un code avantage (et non pas un code opération). Il détermine alors automatiquement le code opération associée à partir : - du code avantage, - de la date de commande (contrôle par rapport aux dates de validité de l'opération commerciale), - de l'indicateur de validité de l'opération enregistré en donnée paramétrée de l'opération commerciale (cf A3, N3 et D3 du paramètre GESOPE). Si plusieurs codes opérations répondent à ces critères, le système retient la première opération trouvée.
|
||
| ean13_com |
ean13 adresse commande
|
4.2-00 | 511 | 13 | Char |
Voir description ci-après pour récupérer le sigle tiers et de l’adresse correspondante à partir d’un code EAN13.
|
||
| ean13_liv |
ean13 adresse livraison
|
4.2-00 | 524 | 13 | Char |
Voir description ci-après pour récupérer le sigle tiers et de l’adresse correspondante à partir d’un code EAN13.
|
||
| ean13_fac |
ean13 adresse facture
|
4.2-00 | 537 | 13 | Char |
Voir description ci-après pour récupérer le sigle tiers et de l’adresse correspondante à partir d’un code EAN13.
|
||
| ean13_pay |
ean13 adresse règlement
|
4.2-00 | 550 | 13 | Char |
Voir description ci-après pour récupérer le sigle tiers et de l’adresse correspondante à partir d’un code EAN13
|
||
| achvte_cat |
Code achat/vente catalogue
|
4.4-00 | 563 | 1 | Char | |||
| codcat |
Code catalogue
|
4.4-00 | 564 | 6 | Char | |||
| numadr |
Numéro d’ordre de l’adresse
|
4.4-00 | 570 | 5 | ZZZZZ | Num |
Si ce champ est renseigné, il est prioritaire par rapport au numadr positionné en place 99 (Correction depuis la 4.2-00).
|
|
| camion_10 |
Numéro du camion
|
4.4-01 | 575 | 10 | Char |
Depuis la version ACE 1.60, ce champ est remplacé par le champ camion (position 1483) géré sur 30 caractères au format UTF8. Néanmoins, il reste actif si le champ camion n’est pas alimenté. Alimente le champ « eve.camion ».
|
||
| heueve |
Heure de l’événement
|
4.4-01 | 585 | 10 | zz.zzzzzzz | Dec | Format HH.MMSSmss. | |
| heuexp1 |
Début plage horaire expédition
|
4.4-01 | 595 | 10 | zz.zzzzzzz | Dec | Format HH.MMSSmss. | |
| heuexp2 |
Fin plage horaire expédition
|
4.4-01 | 605 | 10 | zz.zzzzzzz | Dec | Format HH.MMSSmss. | |
| heuvali |
Heure de validation
|
4.4-01 | 615 | 10 | zz.zzzzzzz | Dec | Format HH.MMSSmss. | |
| heuliv1 |
Début plage horaire livraison
|
4.4-01 | 625 | 10 | zz.zzzzzzz | Dec | Format HH.MMSSmss. | |
| heuliv2 |
Fin plage horaire livraison
|
4.4-01 | 635 | 10 | zz.zzzzzzz | Dec | Format HH.MMSSmss. | |
| typrem |
Type de remise globale
|
4.5-00 | 645 | 3 | Char | |||
| numeve |
Numéro événement
|
4.5-00 | 648 | 9 | zzzzzzzzz | Num | Numéro événement jusque 999 999 999. | |
| numevo |
Numéro événement origine
|
4.5-00 | 657 | 9 | zzzzzzzzz | Num | Numéro événement origine jusque 999 999 999. | |
| facrel |
Indicateur « Bon à payer »
|
4.2-00 | 666 | 1 | Char |
« O » : Oui. « N » : Non. |
||
| tauagio |
Taux d’agio
|
5.0-00 | 667 | 6 | Dec | |||
| codrgm |
Code régime de transport
|
5.2-00 | 673 | 1 | Char | Table TRPRGM. | ||
| codvhc |
Code type de véhicule
|
5.2-00 | 674 | 1 | Char | Table TRPVHC. | ||
| modappro | Mode approvisionnement | ACE 1.2 | 675 | 1 | Char |
D : dépôt. F : fournisseur. T : transit.
|
||
| achvte_ach |
Code achat/vente de l’événement d’achat
|
ACE 1.3 | 676 | 1 | Char |
Les champs achvte_ach, typeve_ach et numeve_ach sont utilisés par le module Grand Import pour les événements appartenant au portail « Achat de prestations ». Ils permettent de relier la commande ou la facture de prestation à un événement d’achat (commande import ou acheminement).
Lors de l’intégration d’une réception import (le type d’événement import dans la table TEV = REI), ces champs sont utilisés pour identifier la commande d’achat à l’origine de la réception (information importante dans le cas d’un acheminement multi-commandes et multi fournisseurs pour retrouver le fournisseur de la réception ainsi que la devise dans laquelle est exprimée la réception).
|
||
| typeve_ach |
Type d’événement de l’événement d’achat
|
ACE 1.3 | 677 | 3 | Char |
Pour une réception import, si ces champs ne sont pas renseignés, le système considère qu’il s’agit de la réception associée à la première commande d’achat sélectionnée pour créer l’acheminement (c'est-à-dire à celle indiquée comme événement origine sur l’en-tête d’acheminement).
|
||
| numeve_ach |
Numéro d’événement de l’événement d’achat
|
ACE 1.3 | 680 | 9 | Num | |||
| siglie_emb |
Lieu d'embarquement (Import)
|
ACE 1.3 | 689 | 12 | Char |
L’intégrateur contrôle automatiquement l'existence du lieu d'embarquement dans la tableTIE :
|
||
| siglie_deb | Lieu de débarquement (Import) | ACE 1.3 | 701 | 12 | Char |
L’intégrateur contrôle automatiquement l'existence du lieu de débarquement dans la tableTIE :
|
||
| codpay_dep | Code pays départ (Import) | ACE 1.3 | 713 | 3 | Char | |||
| codpay_emb |
Code pays d'embarquement (Import)
|
ACE 1.3 | 716 | 3 | Char | L’intégrateur contrôle automatiquement l'existence du pays d’embarquement dans la table PAY. | ||
| codpay_deb | Code pays de débarquement (Import) | ACE 1.3 | 719 | 3 | Char |
L’intégrateur contrôle automatiquement l'existence du pays de débarquement dans la tablePAY.
|
||
| codjal | Code jalon | ACE 1.3 | 722 | 6 | Char |
L’intégrateur contrôle automatiquement l'existence du code jalon dans la table JAL.
|
||
| indfac | indicateur facturation | ACE 1.3 | 728 | 1 | Char |
L’intégrateur contrôle automatiquement l’indicateur « Facturée » dont les seules valeurs possibles sont « O » ou « N ».
|
||
| achvta | Ind. A/V de l'acheminement origine | ACE 1.3 | 729 | 1 | Char |
L’intégrateur contrôle automatiquement l'existence de l'acheminement origine. Le champ « numeva » doit être différent de « 0 ».
|
||
| typeva | Type d'événement de l'ach. origine | ACE 1.3 | 730 | 3 | Char | |||
| numeva |
N° de l'acheminement origine
|
ACE 1.3 | 733 | 9 | Long |
|
||
| codsoc_o |
Code société origine
|
ACE 1.4 | 742 | 4 | Long | |||
| typtie |
Type de tiers
|
ACE 1.4 | 746 | 3 | Char | |||
| codfil | Code de filière | ACE 1.4 | 749 | 12 | Char |
|
||
| achvto |
Code achat/vente de l’événement origine
|
ACE 1.4 | 761 | 1 | Char |
Code A/V de l'origine. Si non renseigné, comme aujourd'hui, pev.achvto.
|
||
| typevo | Type d'événement de l'origine | ACE 1.4 | 762 | 3 | Char |
Code du type d’évènement de l'origine. Si non renseigné, comme aujourd'hui, pev.achvto : la champ « numevo » doit être différent de « 0 ».
|
||
| refext |
Référence externe
|
ACE 1.6.0 | 765 | 120 | UTF8 | Renseigner au maximum 30 caractères. | ||
| libcom |
Libellé complémentaire
|
ACE 1.6.0 | 885 | 120 | UTF8 | Renseigner au maximum 30 caractères. | ||
| modloc |
Localité associée
|
ACE 1.6.0 | 1005 | 120 | UTF8 | Renseigner au maximum 30 caractères. | ||
| batvol |
Nom du bateau ou numéro de vol
|
ACE 1.6.0 | 1125 | 120 | UTF8 | Renseigner au maximum 30 caractères. | ||
| cmpnie |
Compagnie
|
ACE 1.6.0 | 1245 | 120 | UTF8 | Renseigner au maximum 30 caractères. | ||
| nlta |
Numéro de document de transport
|
ACE 1.6.0 | 1365 | 120 | UTF8 | Renseigner au maximum 30 caractères. | ||
| camion | Numéro du camion | ACE 1.6.0 | 1485 | 120 | UTF8 |
Renseigner au maximum 30 caractères.
|
||
| posfis | Position fiscale | ACE 1.6.0 | 1605 | 6 | CHAR | Ce code doit appartenir à la table PFI. | ||
Spécificités de l’Import
Devise spécifique à l’acheminement
Si l’événement créé est un acheminement (tev.typeve_imp = "ACH"),
- Eve.Coddev = zone A1 du paramètre DEVNAT ==> l'acheminement est créé en devise nationale.
-
Eve.Pardev = 0.
-
Eve.Achvta = Eve.Achvte.
-
Eve.Typeva = Eve.Typeve.
-
Eve.Numeva = Eve.Numeve.
-
Eve.datexp = Eve_origine.datexp.
-
Eve.datliv = Eve_origine.datexp.
-
Eve.datval = " " (espace).
Remise à zéro des remises globales
-
Eve.taurem = 0.
- Eve.taurem2 = 0.
-
Eve.taurem3 = 0.
-
Eve.monrem = 0.
Eve.typrem = " " (espace).
Avec Eve_origine correspondant aux données de la commande origine utilisée pour créer l'en-tête d'acheminement.
Contrôle des dates saisies
En entrée:
- Eve.Datliv : date de livraison.
- Eve.datexp : date d’expédition.
- Eve.Datdep : date de départ (embarquement).
- Eve.Datarr : date d’arrivée (débarquement).
Suivant les options du paramètre CTRDAT, certains contrôles sont déclenchés:
- à Si N1 du paramètre CTRDAT = 1, alors,
Si Eve.datexp < eve.datliv, alors message d'erreur EVE_DATLIV.
- à Si N2 du paramètre CTRDAT = 1, alors,
Si Eve.datarr < eve.datdep, alors message d'erreur EVE_DATARR.
Propagation des containers prévisionnels
Lorsque des containers prévisionnels ont été saisis sur la commande d’achat import, ils sont automatiquement propagés sur l’acheminement.
- Eve_origine : évènement origine.
- Eve_destinataire : évènement créé.
-
Eve_col.achvte = Eve_origine.achvte.
-
Eve_col.typeve = Eve_origine.typeve.
- Eve_col.numeve = Eve_origine.numeve.
-
Eve_col_destinataire.achvte = Eve_destinataire.achvte.
-
Eve_col_destinataire.typeve = Eve_destinataire.typeve.
-
Eve_col_destinataire.numeve = Eve_destinataire.numeve.
Intégration d’une réception import
- Comme événement origine, l’acheminement,
- Comme événement d’achat, la commande import à l’origine de la réception. A défaut, le système détermine la commande d’achat à partir de l’événement origine indiqué sur l’en-tête d’acheminement.
Récupération du sigle tiers et de son adresse à partir d’un code EAN13
Paramétrage
Pour activer cette fonctionnalité, il faut tout d’abord positionner les paramètres GENCOD et INTPAR.
Principes
L’intégrateur d’événement comprend quatre champs pour saisir le code EAN13 :
- EAN13_COM,
- EAN13_LIV,
- EAN13_FAC,
- EAN13_PAY.
Le champ EAN13_COM doit être renseigné car il déclenche le traitement de recherche du tiers et de son adresse.
Si on gère les codes EAN13 sur les adresses de livraison uniquement, il faut obligatoirement positionner le code EAN13 de l’adresse de livraison sur le champ EAN13_COM du fichier d’intégration et gérer le paramètre INTPAR avec M1 = LIV.
Les champs EAN13_LIV, EAN13_FAC et EAN13_PAY du fichier d’intégration s’utilisent en complément pour identifier un tiers à partir des différents codes EAN13 définis sur chaque type d’adresse.
Ce fonctionnement s’impose dans le cadre d’une gestion de filières où l’on définit plusieurs adresses de livraison et de facturation.
Dans ce cas le paramètre INTPAR doit être positionné avec M1=COM.
Contrôles effectués avant l’activation de la recherche
- Si le sigle tiers ou le numéro d’adresse ne sont pas alimentés dans le fichier d’intégration, il est obligatoire d’alimenter le champ EAN13_COM.
Si le sigle tiers ou le numéro d’adresse sont alimentés, les champs EAN13_COM, EAN13_LIV, EAN13_FAC, EAN13_PAY doivent rester vides.
Algorithme de recherche
Le système lance une recherche à partir du champ EAN13_COM parmi toutes les adresses (table ADR).
Pour chaque adresse physique, une recherche des liens permet de retrouver les adresses logiques (table LAD) qui y sont associées.
Chaque tiers, numéro d’adresse, EAN13 trouvés sont enregistrés temporairement dans un « tableau en mémoire ».
Dans ce tableau, on dispose des champs ean13_com, ean13_liv, ean13_fac et ean13_pay. Ces derniers sont alimentés au fur et à mesure des liens trouvés et en fonction du type d’adresse traité. Pour exemple, « ean13_liv » ne sera alimenté que si l’on traite une adresse de livraison.
Le tableau est parcouru une seconde fois pour compléter les codes ean13 manquants et demandés par le fichier d’intégration.
Ex : Si EAN13_LIV est alimenté dans le fichier d’intégration, on alimente tous les champs ean13_liv du tableau en mémoire.
En fonction de ces éléments, le système récupère le tiers correspondant aux codes EAN13 saisis dans le fichier d’intégration ainsi que son adresse de livraison et sa filière.
Un message d’erreur alerte l’utilisateur si aucune adresse n’a été trouvée ou si plusieurs adresses ont été trouvées.
Exemple
- Client ACE LILLE
| Filière 1 |
Adresse COM LIV FAC PAY
|
|
|
Adresse COM n° 1 : 9 av de la créativité V. D’ASCQ EAN13 : 3333333333406 |
| Filière 2 |
Adresse COM FAC PAY |
Adresse LIV |
| Adresse COM n°1 |
Adresse LIV n°2 : 7 av de la créativité V. D’ASCQ EAN13 : 3333333333307 |
- Client ACE RUEIL
| Filière 1 | Adresse COM LIV |
Adresse FAC PAY |
|
Adresse COM n° 1 : 2, rue J. Daguerre RUEIL MALMAISON EAN13 : 3333333333505 |
ACE LILLE adresse COM n° 1 |
Fichier intégré :
EAN13_COM = 3333333333406
EAN13_LIV = 3333333333307
INTPAR M1=COM
Alimentation du tableau mémoire :
Client ACE LILLE Adresse 1
ean13_com = 3333333333406
ean13_liv=3333333333406
ean13_fac = 3333333333406
ean13_pay = 3333333333406
Client ACE LILLE Adresse 2
ean13_com=3333333333406
ean13_liv=3333333333307
ean13_fac=3333333333406
ean13_pay=3333333333406
Client ACE RUEIL Adresse 1
ean13_com =3333333333505
ean13_liv=3333333333505
ean13_fac=3333333333406
ean13_pay=3333333333406
Résultat :
La commande doit être créée pour le client ACE LILLE, filière 2, adresse de livraison n°2.
NB : Dans cet exemple, on aurait également pu alimenter le fichier d’intégration de la manière suivante :
EAN13_COM = 333333333307
INTPAR M1=LIV
Recherche automatique du numéro de contrat
Le paramètre NUMCNT permet la recherche automatique du numéro de contrat si celui ci n’est pas renseigné.
Cette recherche n'est active qu'au niveau des en-têtes d'événement. Elle utilise uniquement les zones A1 et N2 du paramètre NUMCNT.
Le système parcourt les contrats du tiers et attribue le contrat dont la date d'échéance sera postérieure à la date de commande et sera la plus proche. Si un des contrats du tiers n'a pas de date d'échéance, le système prendra ce contrat en priorité. Si la date d'échéance n'est pas gérée sur les contrats, le système attribue le premier contrat trouvé.
En cas de gestion d'une hiérarchie groupe, le système parcourt tous les contrats et contrôle pour chacun d'entre eux qu'ils appartiennent au tiers de l'événement ou à l'un de ses groupes.
