Données transverses

 

Contenu dans cette page

les SOCIÉTÉS

les SAISONS

les MONNAIES

les TOLÉRANCES de dates

les MOTIFS

les TYPES DE MOUVEMENT

les TEXTES

 

 

 

les SOCIÉTÉS

La société est utilisée dans de nombreuses parties de Cegid Orli à des fins diverses et variées.
‎Afin de clarifier précisément les domaines d’application dans lesquels elle peut être utilisée, différents contextes sont prévus. Ils ont pour but de spécifier dans quel cadre une valeur est autorisée. Ce qui a pour conséquence directe de limiter les choix possibles aux seuls codes société appartenant au contexte correspondant à la typologie de la société traitée.

Cela permet ainsi d’épurer les valeurs possibles en saisie utilisateur (contrôle sur la zone société et liste de valeurs limitative).

Dans Cegid Orli, la notion de société n’est pas exclusivement comptable mais recouvre d’autres domaines. On pourrait ainsi l’appeler société de gestion plutôt que société comptable.

Du fait qu’il s’agit d’une table de paramétrage général ayant d’importantes conséquences sur le comportement applicatif, la maintenance des sociétés est généralement assurée par des administrateurs.

 

Sociétés de contexte GESTION

 

Définition des contextes GESTION

• Société commerciale = liée à la division commerciale.
• Société client = représente les clients.
  Pas nécessairement comptable.
• Société article (exemple : représente une collection)
• Société matière = représente les matières liées à une collection.
• Société production = liée à la division de production.

N.B. :
une société de contexte production doit obligatoirement être également de contexte comptable, ceci dans le but de pouvoir refacturer les flux entre différents sites de production.
‎Voir documentations du module « Groupes Multi-Sociétés »

Toute société doit appartenir à au moins un de ces cinq contextes (les cinq sont compatibles).

Ainsi lors de la saisie d’une société, le contrôle de cohérence vérifie l’existence du code mais également l’appartenance au bon contexte. La liste de valeurs associées est également limitative par rapport au contexte traité.

 

 

Utilisation

Ce tableau répertorie les contextes de sociétés obligatoires pour chaque principale fonctionnalité de Cegid Orli (il est bien sûr possible d’avoir une société à plusieurs contextes pour chacune de ces fonctionnalités).

Pour certaines fonctionnalités, la saisie de la société est, sur option, obligatoire ou facultative.
‎Ces fonctionnalités sont repérables grâce à un *.

* saisie de la société sur option.

 

Sociétés de contexte COMPTABLE

Société comptable juridique = société étant mise à jour en comptabilité

Dans le cadre du module de Gestion des Groupes, les notions de société juridique et analytique sont indispensables
(voir doc « Gestion des Groupes »).

 

Société comptable juridique

Une société doit obligatoirement être juridique si des données comptables sont renseignées.
‎Il s’agit de la société qui sera mise à jour en comptabilité.

Une société juridique peut également être en même temps analytique.

 

Société comptable analytique

Une société analytique n’est pas obligatoirement mise à jour en comptabilité (si elle n’est pas déclarée en même temps juridique).

Une société analytique non juridique doit obligatoirement être rattachée à une société juridique.

exemple : la société juridique X de l’entreprise X fabriquant des vêtements pour enfants (pôle V) et des jouets en tissu pour enfants (pôle J) pourra avoir deux sociétés analytiques différentes pour chacune de ses activités, qui toutes deux, seront rattachées à la société juridique de l’entreprise.
La classification en sociétés analytiques différentes permet une gestion et un suivi plus ciblés des deux activités de l’entreprise, tout en n’ayant qu’une seule comptabilité à gérer pour la société X.

 

Tout mouvement entre 2 sociétés analytiques d'une même société juridique entraîne un simple équilibrage analytique. En revanche, un mouvement entre 2 sociétés analytiques de sociétés juridiques différentes induit une refacturation intra groupe.

 

Société juridique de rattachement

Code de la société juridique à laquelle doit être rattachée la société analytique.

Cette société juridique de rattachement est obligatoire si la société en cours n'est pas une société comptable juridique.

Deux cas sont alors possibles pour une société analytique :

exemple : la société B est à la fois juridique et analytique.
La société A, quant à elle, est analytique mais rattachée à la société Y.
Il y a donc 2 sociétés juridiques différentes, Y et B.

 

Remarques sur les différentes sociétés :

• Toute société dite « comptable » peut être soit analytique soit juridique.
• Une société analytique doit obligatoirement être rattachée à une société juridique. (ou elle est également juridique, comme la société B dans l’exemple précédent)
• Une société analytique peut être affectée aux magasins ce qui signifie que la société juridique du magasin est alors celle de la société analytique concernée.
• Une commande fournisseur matière (CO) ou articles (LA/NE) est obligatoirement mono société analytique ou juridique (ce qui signifie que tous les magasins de la commande doivent avoir la même société, que celle-ci soit analytique ou juridique).
  Selon les options CDE_MULT_SOCANA (pour les commandes) et RES_MULT_SOCANA (pour les réservations), il est ensuite possible de définir si en lignes de commandes, la gestion est mono-société analytique ou multi société analytique.
• La société analytique peut également être affectée aux ateliers et aux divisions de production s’il s’agit du critère de facturation de la prestation – en fait, elle peut être affectée à toute entité qui se facture ou se valorise (aspect comptable oblige)
• Les sociétés non analytiques ou juridiques (qu’elles soient matières, articles, commerciales ou production) ne peuvent pas être affectées aux magasins et ateliers en termes de société de facturation de la prestation.

• Au niveau de la GCAO, les contrôles suivants sont mis en place :
  • fiche CLIENT :
    la société doit toujours être une société client et doit être une société juridique si le paramètre SOC_EGAL_DIV=0
  • fiche DIVISION COMMERCIALE :
    la société doit être juridique si le paramètre SOC_EGAL_DIV=1.
  • Une société est implicitement comptable juridique du fait qu’elle est rattachée à un CODE COMPTABILITE et à un PRODUIT COMPTABLE.

N.B. :
les coches « société analytique » et « société juridique » ne changent en rien le fonctionnement des coches de contexte dit de gestion. Dans tous les cas, au moins une des cinq coches de contexte de gestion doit être renseignée, quel que soit le contexte comptable choisi. Dans le cas contraire, le message « Au moins un des contextes doit être défini pour la société » bloquera la saisie.

 

Il est donc impossible d’avoir une société Y ou Z ainsi déclarée dans TA009 :

 

Au moins un contexte de gestion doit être déclaré pour que la société ainsi créée puisse être utilisée dans le reste de Cegid Orli (voir tableau).

De plus, ces coches de contexte de gestion permettent de classifier les sociétés et de filtrer les listes de valeurs.

‎ 

 

TA009 : Société

TA009W01
Cette fonction permet de gérer les sociétés de Cegid Orli (Contextes, coordonnées, données comptables, données complémentaires, DAS…)

Pour l'entité article, la société est le premier niveau de classement juste au-dessus de la division commerciale, et la plupart des états (confirmation de commande, relevé de commande…)
‎sont triés dans l’ordre de la société.

Pour l'entité client, la société définit les clients, car c’est l’association de la société avec le code client ou le nom abrégé qui définit un client.

CLIENT = client / société. Dans toute l’application, lorsque l’on parle de client, il est sous-entendu que l’on parle de client/société.

Pour les entités article et client, le code société est obligatoire et unique.

Pour une entreprise mono-société, elle n’est jamais saisie, car la société du site est automatiquement prise en compte.

L'entité matière peut aussi être associée à une société.

 

TA009 est composé de plusieurs onglets :

1. Coordonnées
2. Données comptables
3. Données comptables complémentaires
4. Données DAS
5. Valorisation

‎ 

 

1 / onglet COORDONNÉES

Il référence les différents contextes :

• Société commerciale
• Société client
• Société article
• Société matière
• Société de production
• Société comptable analytique
• Société juridique de rattachement
• Société comptable juridique

 

Contrairement aux autres coches, les derniers flags "comptable" ne sont pas cochés par défaut.

Une « Société juridique de rattachement » ne peut être qu’une société comptable juridique.

Les contrôles existants sont les suivants :

• Obligation de saisir une société juridique de rattachement
  si « Société comptable analytique » est cochée
• Obligation de cocher « Société comptable juridique »
  s’il existe un « Code comptable » et un « Produit comptable »
• Obligation de cocher l’un des deux contextes comptables
  si la société est de contexte production

 

Cet onglet permet également de définir toutes données les administratives
‎(adresse, téléphone, télécopie, mail…), les informations commerciales et les passerelles.

• Contact :
  Cette zone correspond au nom de la personne à contacter et à faire figurer sur la déclaration.
• Préfixe PF :
  Cette zone devient accessible et rentre dans la composition du code article si l'option AR001W01/ARTICLE=8,9 et 10
• Préfixe matière :
  Cette zone devient accessible et rentre dans la composition du code matière si l'option MA001W01/CODE_MATIERE=4.
• Code société entête de document :
  Cette zone permet d’éditer en entête de documents les informations de cette société au lieu de celle traitée. Cette société a dû être créée au préalable. Elle est utilisée dans la DEB si on a plusieurs sociétés rattachées à une société mère et dont la DEB doit être faite avec l’entête de la société mère.
• TVA :
  N° de TVA qui est édité sur les factures et/ou avoirs U.E.
  ‎Il est repris sur la déclaration d’échange de biens entre pays membres de l’U.E.
• Lieu abrégé :
  utilisé par l’édition des traites, la zone du format AFNOR étant très courte.
• N° de SIRET :
  facultatif
• Code EDI :
  code EDI rattaché à la société, utilisé par le Suivi Atelier.

 

2 / Onglet DONNÉES COMPTABLES

Il vous permet d’associer les données comptables au produit comptable externe (logiciel de comptabilité) utilisé.

Il permet également de définir un organisme de crédit, les données GENCOD, les données DEB et les données comptables spécifiques pour chaque société.

 

• Code comptabilité : Il s’agit du code société référencé dans le produit comptable externe. Il est utilisé par toutes les passerelles avec cette comptabilité.

 

• Adresse TCP/IP : Adresse ou nom de la machine sur laquelle est installé le produit comptable externe.

Cette adresse permet d’envoyer à la comptabilité les fichiers extraits de Cegid Orli (Clients, Fournisseurs, journal Vente, journal Effets, journal Achat).

Le login et le mot de passe de connexion à la machine sont ceux saisis ci-après.

 

• Produit comptable : Sa saisie est obligatoire si le code comptabilité société a été renseigné. C’est le code du format de fichier, qui varie selon le produit comptable utilisé pour cette société. Cegid Orli est interfaçable en standard via les formats de fichier suivants :

 

• CPT_S5_S7
  (format de la comptabilité standard Cegid Finance)
  • Clients / Fournisseurs / journal Vente / journal Achat / journal Effets / Plan de paiement
  • remontée Encours Traites / Solde Clients.
  • remontée des Règlement commissions

     

• PAS_CPT_V2
  (format standard Cegid Orli, issu de compta Cegid)
  • Clients / Fournisseurs / journal Vente / journal Achat / journal Effets / Plan de paiement

     

• PAS_CPT_IT
  (format standard Cegid Orli, issu de compta Cegid, avec mise en conformité pour l'Italie)
  • Clients / Fournisseurs / journal Vente / journal Achat / journal Effets / Plan de paiement

     

• PAS_CPT_V1
  (format standard Cegid Orli, issu de compta ALIX)
  • Clients / Fournisseurs / journal Vente / journal Achat / Plan de paiement

     

• SETEC
  (format de la comptabilité ALIX)
  • Clients / Fournisseurs / journal Vente / journal Achat / Plan de paiement
  • remontée Encours Traites / Solde Clients / Commissions sur encaissement

 

 

• Séquence FRS : pour numéroter différemment les numéros de pièces selon le code société, il suffit de saisir dans l’onglet Données comptables, un code de deux chiffres dans le champ Séquence FRS. Ce code sera ensuite référencé dans JP020 pour la séquence de numérotation. Par défaut, le code s’appelle FAC_FOUR. Si la séquence FRS est renseignée, il faudra utiliser le code FAC_FOU_xx, xx étant le nombre compris entre 01 et 99 saisi dans TA009.

  N.B. :
  TA497 permet d’obtenir une numérotation différente par type de document. Si des informations y sont renseignées, elles sont prioritaires sur celles définies en TA009.

   

• Utilisateur : Nom de l’utilisateur du login pour accéder à l’application comptable.
  ‎Utilisé pour transférer en automatique les fichiers nécessaires à la comptabilité.
  ‎Prévu pour les comptabilités Cegid et ALIX.

   

• Mot de passe utilisateur : Mot de passe de l’utilisateur login pour accéder à l’application comptable.

   

• Répertoire de transfert :
  ‎Saisie obligatoire si le code comptable de la société a été indiqué.
  ‎Il est utilisé dans le cadre des automatismes dans les procédures.
  
  Racine de répertoire selon les serveurs d’édition :

• D:\orli\...

• C:\orli\...

‎ (pour serveurs où il n’y a plus de lecteur D:\ )

 

N.B. :
cette racine étant implicite, pas besoin de la préciser ci-dessous

 

Où se trouve le répertoire de transfert ?

• Soit sous cette racine :
  ‎ dans ce cas, le répertoire de transfert est « relatif » (donc pas de « / » au début)

  Exemple :
  compta/
  ‎ (pour compta CPT_S5_S7)

• Soit dans un répertoire « absolu » :
  ‎ le répertoire de transfert est alors décrit dans sa totalité (et commence par « / »)

Exemple :
‎ /home/orco/transfert
‎ (pour compta SETEC)

• Code adhérent :
  Correspond au code adhérent de la société chez l’organisme de crédit.
  ‎Il est facultatif et non contrôlé

   

• Nom adhérent :
  Correspond au nom de l’adhérent chez l’organisme de crédit.
  ‎Il est facultatif et non contrôlé.

   

• N° fiscal adhérent :
  Correspond au N° fiscal de l’adhérent chez l’organisme de crédit.
  ‎Il est facultatif et non contrôlé.

   

• Code International Entreprise :
  Permet de saisir la codification internationale de l’entreprise. Il n’y a pas de blocage par rapport au CNUF, bien que ces 2 champs soient liés, et ce dans le cas d’une éventuelle ouverture internationale.

   

• CNUF colis :
  Permet de saisir le Code National Unifié Fournisseur.
  ‎Il peut être utilisé pour le formatage en code-barres (GS1-128) des colis PF.
  ‎Il peut prendre la même valeur que le CNUF utilisé dans la codification article en EAN13.

   

• CNUF article :
  Permet de saisir le Code National Unifié Fournisseur article. Il peut être utilisé pour le formatage en code barre des colis PF dans la norme EAN13.

   

• Indicatif CIP :
  Code Interface Produit. La longueur du champ est de 10 caractères (standard JP020), 4 caractères au maximum sont autorisés, les premiers sont obligatoirement CIP. Le 4^ème est laissé au choix de l’utilisateur, mais l’indicatif ainsi composé doit exister dans JP020.

   

• Niveau de chiffre d’affaires en introduction
• Niveau de chiffres d’affaires en expédition :
  Ces niveaux sont utilisés pour la déclaration d'échanges de biens entre membres de l’U.E. (DEBWEB2)

 

Représentant Fiscal : Si coché alors on n’a pas accès aux coches définissant le contexte des différentes sociétés : Société commerciale, Société client, Société article, Société matière, Société de production, Société comptable analytique, Société comptable juridique.

Le fait de ne pas donner accès à ces coches permet de ne pas pouvoir saisir ou visualiser cette notion de représentation fiscal dans les différents fonctions ou on doit saisir une société à par entière.

L’avantage de gérer la notion de représentant fiscal dans la fonction des sociétés, sert uniquement pour paramétrer les données nécessaires pour la déclaration d’échanges de bien et aussi pour récupérer la notion de No de TVA exportateur pour les éditions (Factures notamment).

 

Récapitulatif des valeurs possibles :

 

• N° d’habilitation
• Mot de passe :
  attribués par le CISD de rattachement, ils servent à la génération du fichier INTRACOM 

   

• Répertoire DEB

Répertoire sur lequel le fichier INTRACOM doit être copié (mettre / à la fin).
‎Cette donnée, lorsqu'elle est renseignée vient en lieu et place de l'option FA030W01/DIR_FIC_CEE.
‎Si non renseigné, on prendra alors la valeur définie dans l'option.

‎ 

En cas de mono CNUF pour une entreprise, celui-ci doit être défini dans TA009 pour toutes les sociétés ARTICLE qu'il concerne.

En cas de multi CNUF, on utilise TA384 (table GEST_CNUF) dont la société est à ce jour une société ARTICLE. Lors de la génération des EAN pour un article, aucune information ne nous permet de rattacher l'article à une société COMPTABLE si elle n'est pas la même que sa société ARTICLE.

Dans un premier temps, il est donc considéré que la société ARTICLE est suffisante pour rechercher les bons CNUF et CIP.

En cas de besoin à terme, on pourrait envisager d'ajouter les données CATEGORIE ARTICLE dans cette table (réseau, marque, activité, ligne de produit, forme) en supposant qu'elles permettraient bien de définir le CNUF et le CIP à utiliser.

N.B. :
il ne paraît pas logique de passer par la société DIVISION COMMERCIALE pour rechercher une éventuelle société COMPTABLE de l'article, un article pouvant être vendu par plusieurs divisions de sociétés différentes.

 

Données comptables spécifiques :

• Société comptable ou gérée
• Société gérante du pool
• établissement de la Société gérante du pool
• Compte de trésorerie
• Nature Opération de trésorerie
• Code instrument de paiement

 

Gestion TVA forfaitaire :
Cette coche conditionne la dématérialisation des pièces de cette société pour l'Italie.

 

Gestion TVA sur les débits :
Cette coche conditionne la dématérialisation des pièces de cette société pour la France (rubrique "432").

Pour plus de précisions, Cf.  Facturation Électronique (France / Loi de Finance 2026)

 

 

3 / Onglet DONNÉES COMPTABLES COMPLÉMENTAIRES

Cet onglet concerne principalement des données du module Groupe Multi-Sociétés
‎ (sauf les 3 dernières zones, qui elles sont accessibles tout le temps)

• N° compte bancaire 
• Formatage client comptable 
• Formatage fournisseur comptable 
• Journal de vente EXPORT 
• Journal de vente SITE 
• Journal d’achat EXPORT 
• Journal d’achat SITE 
• Journal factures pays <> SITE 
• Journal factures pays du SITE
• Magasin comptable PF 
• Magasin comptable Matières 
• Ventilation des remises
• Journal pour le CUT OFF 
• Journal pour valorisation des stocks 
• Journal pour envoi des charges à prévoir 

 

4 / Onglet DONNÉES DAS

Cet onglet concerne les données DAS (Demande Autorisation Sortie) référencées par société client, et éditées sur les factures.

 

5 / Onglet VALORISATION

Cet onglet concerne des données de tarifs et d’échanges inter-société

 

6 / Onglet CORRESPONDANCE CLIENT

Cet onglet permet de référencer en tant que CLIENT une société juridique dans une autre société juridique du groupe (permettant de demander une statistique en précisant une société juridique de restitution) ; ainsi, on obtient automatiquement les bonnes données,
‎en ne prenant en compte que les pièces appartenant à la société de restitution et valorisées au bon tarif, c'est-à-dire au prix de vente ou au prix d'achat de la société de restitution.

 

Utilisation du paramètre GEST_SOC_WEB (Code société sur 3 caractères)

Il est possible de gérer le code société sur 3 caractères selon la valeur du paramètre GEST_SOC_WEB.

Le paramètre GEST_SOC_WEB permet d’identifier le fait que la société est gérée sur 1 ou 3 caractères.

Celui-ci peut prendre 2 valeurs possibles :

• 0 : gestion de la société sur 1 caractère (valeur par défaut)
• 1 : gestion de la société sur 3 caractères

N.B. :
cette deuxième valeur entraîne des contraintes de gestion liées aux envois de données aux logiciels externes. Si vous utilisez XC930, consulter l'aide avant de changer la valeur de cette option.

Si vous gérez des fonctions spécifiques : ‎La gestion sur 3 caractères entraîne la révision des fonctions spécifiques pour les adapter
‎ (pour cela, vous devez contacter Cegid)

 

Utilisation du paramètre SOC_EGAL_DIV

Le paramètre SOC_EGAL_DIV permet d’influer la société qui est prise en compte en tant que société juridique.

Ce paramètre permet ainsi d'avoir un seul fichier client enregistré dans 1 société, tout en gérant plusieurs sociétés juridiques, et donc comptables.

La société juridique est la notion commerciale correspondant à la société comptable :

• Si SOC_EGAL_DIV=0, on utilise la société du client comme société juridique (une société analytique ne sera pas acceptée)
• Si SOC_EGAL_DIV=1, on utilise alors la société de la division commerciale comme société juridique (la société du client ne doit alors pas être nécessairement comptable, juridique ou analytique).

Ainsi, lors de la communication de la société comptable via l’interface standard à destination de la comptabilité, on recherche dans TA009 la correspondance « société comptable » soit de la société client, soit de la société de la division commerciale en fonction de ce paramètre.

 

exemple :

Le client CLI01 travaille avec la société juridique Y, pour la division commerciale YYY, mais aussi avec la société juridique B, pour la division commerciale BBB.

Si SOC_EGAL_DIV=0
‎on devra créer deux fiches clients :

Si SOC_EGAL_DIV=1
‎on ira tout d’abord renseigner les données suivantes dans TA126 :

Dans CL001, on aura une seule fiche :

Ainsi le client CLI01 de la société Y peut aussi travailler avec la société B.

Mais on peut également avoir la fiche client suivante, dans l’hypothèse où l’on souhaite gérer les clients dans une société de contexte uniquement client, (exemple : société C) ni juridique, ni analytique :

Ainsi le client CLI01 de la société C peut également travailler avec les sociétés juridiques B et Y.

 

 

Utilisation de la monnaie de la société juridique (Si module Groupe Multi-Sociétés)

Elle sert exclusivement dans FA007 (Maj en sortie de facturation), FA030 (Edition de la D.E.B.) et FA026 (Journal des ventes).

Dans FA007, FA030, Plans paiement, et interfaces compta, la monnaie juridique de la société (monnaie renseignée dans l’onglet « Valorisation » du TA009 - Société) sera prise en compte en priorité, et si elle n’est pas renseignée, c’est la monnaie de tenue (paramètre MON_TENU) qui sera prise en compte.

Dans FA026, c’est la monnaie d’impression qui prime, si elle n’est pas renseignée, c’est la monnaie de la société juridique, et s’il n’y en a pas, c’est la monnaie saisie dans le paramètre MON_TENU. La monnaie du profil culturel n’est donc pas utile dans cette fonction.

‎ 

les SAISONS

TA073W01
Cette fonction permet de gérer les saisons par date, par contexte

La saison est une notion très utilisée dans Cegid Orli.

Les 2 principaux domaines d'utilisation de cette notion de saison sont :

• les saisons ARTICLE (saison dans laquelle est affecté l'article)
• les saisons COMMANDE (saison à laquelle est rattachée une commande CLIENT).

Les modèles commerciaux, les matières commerciales, les matières techniques et les réservations commandes/matières sont eux aussi rattachés à une saison.

Ces saisons doivent être référencées de préférence sous le code année + type de saison afin de rationaliser leur utilisation au niveau de différents traitements (comparatifs saisonniers, etc...)
‎Une particularité existe pour les entreprises gérant des articles ou matières permanentes (sans saison). Dans ce cas, il faut créer un code saison spécial intitulé : 00P = saison permanente
‎
‎Une saison est caractérisée par les informations suivantes :

• Code saison

  Le code saison est obligatoire et non modifiable en maintenance.
  ‎Il est composé de l'année (donnée alphanumérique saisie sans contrôle) et du le type de saison

• Libellé de la saison
• Dates de début, de fin

  Facultatives, elles sont utilisées pour contrôler que la date d'une commande client saisie dans CD001 est bien comprise dans la fourchette date début - date fin de la saison. Si cette date n'est pas saisie, le contrôle de la date de commande client n'a lieu que sur la date de fin de la saison. Si les 2 dates début/fin ne sont pas saisies, aucun contrôle n'est fait en saisie de commande.
  Ce contrôle en saisie des commandes n'est pas bloquant, mais seulement informatif.
  ‎Quand elles sont saisies, elles font l'objet d'un contrôle de tolérance (défini dans TA526).

• Type de saison

  La saisie du type de saison est obligatoire. Il est utilisé dans la fiche matière commerciale (TC001) en fonction de la saison attribuée à la matière commerciale créée.
  ‎Si l'option TEST_TYP_SAIS=1, la gestion du code et du type de saison est libre; sinon le type de saison est égale au 3^ème caractère du code saison, son type permanent ou non.

   

• Permanent : coche permettant de définir la saison comme permanente

   

• Un contexte permettant de clarifier le domaine d’application de la saison. Valeurs de contexte possibles :
  • saison commerciale (avec une date d'arrêt associée)
  • saison produit finis
  • saison matière

     

• Fonctionnalité de saison

  Cette fonctionnalité est utilisée uniquement dans le cas ou l'option AR001W01/ARTICLE=6. Cette fonctionnalité permet, lors de la création du code article, de chercher un compteur associé à cette fonctionnalité dont l'indicatif est CODE_ART_x (x étant la fonctionnalité), et d'intégrer la valeur de ce compteur dans le code article (Code article = [Code reseau||Valeur compteur ]), ce codage devant permettre de distinguer rapidement un article de cette saison "spéciale". Les indicatifs doivent être crées dans JP020, en fonction des fonctionnalités qui seront utilisées. Elle est accessible par option.

• la saison identique précédente (S.I.P.)

  Ce champ représente la saison identique précédente qui est utilisée comme base de comparaison avec la saison en-cours dans le module de prévisions de vente. Sa saisie est facultative, mais fortement conseillée si votre société utilise le module de prévisions de vente(que ce soit au niveau des objectifs, des prévisions). Cette saison est également exploitée dans le module de gestion de collection. Ce code SIP ne peut être la saison permanente (00P) ni la saison en cours. On a accès à cette zone si les paramètres GEST_PREV_VEN=1, ou GEST_PREV_VEN=0 avec GEST_OBJ_VEN=1,  et dans le cadre du module collection (GDC).

• la saison identique précédente antérieure de 2 années, de 3 années

  Ce champ représente la saison identique précédente qui est utilisée comme base de comparaison avec la saison en-cours dans le module de prévisions de vente. Sa saisie est facultative, mais cependant fortement conseillée si votre société utilise le module de prévisions de vente(que ce soit au niveau des objectifs, des prévisions).
  ‎Cette saison est également exploitée dans le module de gestion de collection.
  ‎Ce code SIP ne peut être la saison permanente (00P) ni la saison en cours.
  ‎On a accès à cette zone si les paramètres GEST_PREV_VEN=1, ou GEST_PREV_VEN=0 avec GEST_OBJ_VEN=1,  et dans le cadre du module collection (GDC).

• Code de correspondance

Cette zone permet de faire une correspondance entre les codes saisons gérés par Cegid Orli et les codes saisons gérés par d'autres logiciels (en particulier le logiciel de boutique). ‎Cette zone ne doit contenir que des nombres.

 

Fonctionnement

Afin de clarifier précisément les domaines d’application dans lesquels elle peut être utilisée, des contextes ont pour but de spécifier dans quel cadre une valeur est autorisée, ce qui a pour conséquence directe de limiter les choix possibles aux seuls codes saison appartenant au contexte correspondant à la typologie de la saison traitée.

Cela permet ainsi d’épurer les valeurs possibles en saisie utilisateur (contrôle sur la zone saison et liste de valeurs limitative).

Trois contextes ont été définis dans TA073 : SAISONS

• Contexte Commercial
• Contexte P.F. (produit fini)
• Contexte Matière (technique)

 

 

Les contextes

Toute saison doit appartenir à au moins un contexte.

Une saison de contexte commercial ne peut pas être cochée « Saison permanente ».

Les saisons de contexte commercial sont associées à des entités principales :

Saison de commercialisation
‎ Filtre produit, pour sélectionner l’ensemble des produits prévus dans la collection,‎ donc vendables dans une saison de vente donnée

Saison de vente
‎ Saison de commande client (CD001)
‎ Saison du taux de change (TA100, TA082)

Saison d’approvisionnement Matière
‎ Saison de commande fournisseur Mat. (CO021)

Saison d’approvisionnement PF
‎ Saison de commande fournisseur PF (LA001)

Saison d’une prévision de vente

Saison d’une facture

Saison des besoins

Saison des propositions d’achat

Saison d’un planning

Saison d’une réservation Matière

 

Un produit est dit prévu dans une saison de commercialisation si

La saison produit est identique à la saison de commercialisation

OU

La saison produit est nulle et la saison de l’article associé est identique à la saison de commercialisation

OU

La saison article ou produit est cochée permanente

OU

L’article ou le produit est prorogé dans la saison de commercialisation

OU

Le produit est coché comme étant un Hors-cours (*)

Saison de prorogation

 

Saison dans laquelle on fait « vivre » un produit non prévu initialement dans cette saison de contexte commercial

 

(*) Un Hors-cours est un produit qui n’est plus autorisé à la fabrication mais pour lequel il reste du stock à vendre. Le but étant d’écouler le plus rapidement possible ce stock. C’est pourquoi le produit en question devient valable dans toute saison de commercialisation car il doit être vendable dès que possible jusqu’à épuisement du stock.

Les saisons de contexte PF sont associées à des données de base en rapport avec les produits finis :

• Saison article
• Saison de création du code article
• Saison produit
• Saison de création du code coloris d’un article
• Saison modèle
• Saison de création du code modèle
• Saison tissu
• Saison de création de la matière commerciale

Les saisons de contexte Matière sont associées à des données de base en rapport avec les matières techniques :

• Saison matière
• Saison de création du code matière

‎ 

Les saisons permanentes

Une coche saison permanente est disponible. Elle permet de spécifier si une saison est de type permanent ou non. Ce qui donne la possibilité de gérer plusieurs saisons permanentes.

La saison ‘00P’ restant obligatoirement gérée et permanente par défaut. Elle ne peut pas être de contexte commercial ; elle doit être de contexte produit finis, matière et être de type permanent.

 

 

La date d’arrêt pour le contexte commercial

Au contexte commercial, on a associé une date d’arrêt.

On peut ainsi déclarer une saison associée à ce contexte comme étant terminée (clôture de la saison de contexte commercial) ; c'est à dire que si sa date d’arrêt est strictement inférieure à une date de référence (exemple : date de commande client), elle n’est plus saisissable dans les fonctions où l’on travaille sur une saison dite commerciale et où l’on peut créer ou modifier des données
(exemple : en effet, une saison même arrêtée doit rester saisissable dans les fonctions de consultation ou d’édition).

Une saison arrêtée n’est plus prise en compte non plus dans les traitements qui balaient les fichiers des entités principales (exemple : calcul de reste à lancer qui lit tout le portefeuille de commande ou les prévisions par saison de vente).

Cette position permet enfin d’éviter les erreurs de saisie où involontairement, un utilisateur choisirait une saison passée.

 

 

Documentations annexes

Pour plus de précisions, Cf. Prorogés, Reconduits, Hors-cours

‎ 

les MONNAIES

Chaque monnaie utilisée dans Cegid Orli doit être répertoriée, avec son nombre de décimales, ainsi que le nombre d’unités relatif aux taux de change.

 

TA016 : Monnaies

TA016W01
Cette fonction permet la gestion des différentes monnaies

La modification du nombre de décimales et du nombre d’unités est impossible si la monnaie à modifier est répertoriée dans la fonction gérant les taux de change.

 

Nombre d’unités : correspond au nombre d’unité de conversion par rapport à la monnaie du site (paramètre MON_TENU).

Si le nombre d’unité est à 1000 alors on donnera le taux de change pour 1000 unités.

 

Nombre de décimales : doit tenir compte de 2 éléments :

• la taille de stockage standard de 10 chiffres, pour les valeurs de montants et de prix
  • avec une monnaie SANS décimale
    on peut stocker une valeur maximale de 10 milliards (9 999 999 999)
  • avec une monnaie à 2 décimales :
    ‎on tombe à une valeur maximale de 100 millions (99 999 999,99)

     

• la catégorie de la monnaie, selon son taux de change;
  ‎parmi les monnaies courantes, on peut en distinguer 3 :
  • catégorie "1"

    taux de change moyen : 1EUR = 1x

    le stockage est généralement sur 2 décimales

    • exemples :
      ‎$ (américain, canadien, australien)
      ‎CHF (Suisse)
      ‎GBP (Grande Bretagne)
      ‎TND (Tunisie)
  • catégorie "10"

    taux de change moyen : 1EUR = 10x

    le stockage est généralement sur 2 décimales
    (mais on tombe à une valeur maximale de 10 millions d'équivalent euro)

    • exemples :
      ‎CNY (Chine)
      ‎MAD (Maroc)
  • catégorie "100"
    ‎taux de change moyen : 1EUR = 100x

    le stockage doit se faire obligatoirement SANS décimale
    (afin de conserver la même capacité que pour EUR)

    • exemple typique : JPY (Japon)

 

N.B. :
un tarif étant associé à une monnaie, ‎le nombre de décimales de ce tarif sera déterminé par le nombre de décimales de la monnaie.

 

Norme Factoring (facultatif) : permet de faire le lien entre le code monnaie attribué par l’entreprise et celui attribué par l’organisme de factoring.

 

Norme ISO : Correspondance dans la norme ISO 4217 (obligatoire pour les échanges avec Cegid Retail Y2).

 

On peut associer à chaque monnaie un symbole graphique (exemple : « ¥ » pour le Yen).
‎Il n'est pas toujours possible de saisir tous les symboles existants (cas de l'EURO, son symbole « € » n'étant restituable qu'en codage UTF, pas en codage ISO); pour vérifier si un symbole est autorisé il faut saisir celui-ci dans la zone "symbole" et après validation, réinterroger la liste pour vérifier que celui-ci est toujours bien affiché. S'il a été transformé en un autre symbole (exemple : « ? »), cela signifie que ce symbole n'est pas autorisé il faut alors en saisir un autre (voire ne rien mettre).

On peut associer à chaque monnaie des séparateurs (de millier, de décimale), utilisés lors de l'édition des prix sur les étiquettes consommateur et les étiquettes produit fini dites mixtes.

Séparateur de millier :
‎nul
> pas de séparateur (par défaut)
sinon 
> espace, sinon tout autre caractère.

Séparateur de décimale :
‎nul
> « . » (par défaut)
sinon tout autre caractère
(exemple : « , »).

 

N.B. :
ne pas mettre le même caractère pour le séparateur de millier et celui de décimale ; la valeur pour ces séparateurs est dans un premier temps lue au niveau du tarif‎ (si les deux séparateurs sont nuls, on prend alors en compte ceux de la monnaie).

 

 

Application des monnaies :

• paramètre général MON_TENU :
  ‎il indique donne la monnaie de l’entreprise (obligatoire)

   

• critère Monnaie de JP533 (facultatif) :
  ‎il indique la monnaie de présentation pour les utilisateurs d’un groupe donné
  si ce critère est vide, la monnaie de présentation est la monnaie de MON_TENU

   

• critère Monnaie de présentation de tout écran MUL ou de tout état valorisé (facultatif) :
  ‎il indique la monnaie de chaque colonne suffixée « en monnaie de présentation »
  ‎si ce critère est vide, la monnaie de présentation est la monnaie de JP533

 

 

TA100 / Taux de change

TA100W01
Cette fonction permet de référencer les taux entre 2 monnaies

 

Un taux de change est déterminé par :

• une saison de commande (facultative), l'avantage étant de connaître l'évolution de la marge sur une saison ‎sans se poser la question des changements de taux de change durant la saison.
• une date d'effet
• un type de taux (pour spécifier son champ d’application)
• un code monnaie à exprimer

Valeur de taux sur 12 caractères numériques dont 6 décimales.

 

Différentes applications selon le type de taux :

1. ACHATS
2. VENTES Commandes
3. REDEVANCES Boutiques
   (dans ce cas, la saison de commande ne doit pas être définie)
4. VENTES Facturation
5. ACHATS Autres
   uniquement utilisé pour la facturation des achats fournisseurs (Contrôle factures et Transfert des factures fournisseurs en compta), permettant de réactualiser régulièrement le taux qui sert de base sans modifier le taux d'achat classique qui est notamment utilisé pour le calcul des PRI
6. DUPLICATION Tarif de vente
7. CALCUL Prix de Revient
   • Article (PR231)
   • Matière composée (IN211)
   • PRMP PF, PRI OF (PR531), PRI réel PF (PR431)
   • tous les calculs automatiques de prix matière dans MA001 ‎
     (initialisation ou calcul du prix PRI à partir des prix d'achat fournisseur)

 

‎ Règles d'application du type de taux :

• Si type taux 7 non renseigné (CALCUL Prix de Revient)
  • type taux 1 OU type taux NUL ‎
• Si type taux 5 non renseigné (ACHATS)
  • type taux 1 OU type taux NUL ‎
• Si type taux 4 non renseigné (‎VENTES Facturation)
  • type taux 2 OU type taux NUL ‎
• Si type taux 1/2/3/6 non renseigné (autres cas)
  • taux et saison de commande définis pour le type taux NUL ‎

 

Tableau récapitulatif des applications selon le type taux (et report sur autre type taux quand le type taux recherché n'existe pas)

1	ACHATS	è NUL
2	VENTES Commandes	è NUL
3	REDEVANCES Boutiques	è NUL
4	VENTES Facturation	è 2	è NUL
5	ACHATS Autres	è 1	è NUL
6	DUPLICATION Tarif de vente	è NUL
7	CALCUL Prix de Revient	è 1	è NUL

 

Cegid Orli conserve le taux de change au niveau des commandes clients, et applique en priorité les taux de changes définis avec un type de taux de renseigné avant d'utiliser les taux de changes définis sans type de taux. La quantité commandée est valorisée sur le taux de change de la date de la commande (alors que les quantités préparables, reste à facturer sont valorisées sur le taux de change de la date courante).

 

 

TA431 / Liens monnaies

TA431W01
Cette fonction permet de référencer les taux entre 2 monnaies ‎de rattachement

Liste des monnaies rattachées (notion de monnaie « IN ») à une monnaie de rattachement.
‎Le seul cas utile à ce jour a été celui de l’Euro en 2001.

On peut indiquer une période transitoire (sous forme de date début et date de fin) pendant laquelle vont "cohabiter" les monnaies IN et leur monnaie de rattachement. Après cette période, l'utilisation de ces monnaies IN sera interdite.

Indication du taux de conversion "officiel" entre ces monnaies IN et leur monnaie de rattachement.

Une période indicative permettra d'éditer des mentions d'équivalences sur certains documents (confirmation de commandes, factures) dans cette période; on pourra aussi indiquer un taux "indicatif" qui en dehors de la période transitoire, sera utilisé dans les mentions d'équivalence.

 

TA432 / Calculette conversion monnaies

TA432W01
Cette fonction permet de réaliser des conversions d'une monnaie dans une autre

On a la possibilité de choisir pour la conversion :

• La date d'effet du taux
• La saison du taux
• le type de taux à appliquer

 

N.B. :
toutes les données hormis la saison du taux sont obligatoires.

 

 

les TOLÉRANCES de dates

Lors de la saisie d’une date, on applique généralement quelques contrôles « basiques » pour vérifier que la valeur saisie est cohérente, notamment le dépassement par rapport à la date du jour qui n’est pas toujours autorisé.

Cependant, la saisie d’une date plus ancienne est toujours permise (soit volontairement, soit par erreur de saisie).

Dans le but de contrôler ceci (notamment par rapport aux mouvements de stock dépendants de situations comptables qu’il faut arrêter à instant ‘t’), un module de gestion de la tolérance de date prévoit de limiter les valeurs possibles pour les dates saisies en fonction d’un intervalle paramétré (date de début et date de fin).

Dans JP525 (PERSONNALISATION TOLÉRANCES DE DATES), le principe consiste à pouvoir paramétrer soit un intervalle de dates, soit un intervalle de durées (permettant d’obtenir un intervalle de date évoluant en fonction de la date du jour), soit les deux, à ne pas dépasser lors de la saisie d’une date dans une fonction.

Ce qui permet dans certains cas d’interdire tout mouvement avec « une date inférieure à … » ‎et ainsi, de pouvoir faire des arrêtés comptables à des dates précises.

 

Fonctionnement

JP525W01
Cette fonction définit la bibliothèque des dates sur lesquelles la fonctionnalité de tolérance des dates est gérée ainsi que la gestion des liens des dates fonctionnelles par fonction

 

2 types de dates sont définis :

les dates techniques qui sont valables pour une fonction précise

• les dates fonctionnelles qui ne sont pas liées à une fonction, mais qui permettent de définir un ensemble de couples « fonction / date technique ».

 

Cette dernière notion permet de gérer une valeur de tolérance qui va s’appliquer à l’ensemble des couples « fonction / date technique » associés (cela évite de saisir ou modifier une tolérance sur chaque « fonction / date technique »)

• Gestion des fonctions par dates (bibliothèque des dates)

On définit toutes les dates saisissables par fonction Cegid Orli.
‎Si le code fonction est laissé à nul, la date saisie correspond alors à une date fonctionnelle.

Cette notion de date fonctionnelle est créée pour faciliter la saisie de la tolérance : dans le premier onglet est définie la date fonctionnelle et dans le second, le lien de cette date avec les fonctions. Ainsi dans la fonction de GESTION DES TOLÉRANCES DE DATES, il suffit de saisir la date fonctionnelle pour que la tolérance soit appliquée aux fonctions concernées.
‎Remarque : Pour modifier un enregistrement, il faut au préalable le supprimer et le créer de nouveau.

• Gestion des liens dates fonctionnelles par fonction

On définit les liens entre une date fonctionnelle saisie dans le premier onglet et des fonctions / dates techniques saisies également dans cet onglet.
‎En création, seules les dates, présentes dans le premier onglet, avec le code fonction nul peuvent être saisies dans la zone "Date fonctionnelle" et seules les fonctions + dates techniques du premier onglet peuvent être saisies dans les zones "Fonction" + "Date Technique" associable à la date fonctionnelle.

 

La liste des dates techniques par fonction sur lesquelles on contrôle la tolérance et des dates fonctionnelles standards sont figées par Cegid.

Par contre, dans un souci de paramétrage par client, la possibilité de gérer une date fonctionnelle spécifique est prévue.

La règle pour créer des dates fonctionnelles consiste à faire commencer leur codification par le caractère ‘Z’ (au même titre que les fonctions internes). Ce qui permet de différencier les dates fonctionnelles standards Cegid de celles spécifiques au client et surtout, de les conserver en cas de mise à jour de ce fichier.
‎ 

TA526W01
Gestion de la tolérance de dates par fonction par intervalle de dates ou durée

Cette fonction permet de définir les tolérances de dates par fonction, en saisissant les intervalles limites à ne pas dépasser pour les dates techniques et/ou fonctionnelles.

L’ensemble des fonctions/dates possibles est pré-remplie à l'aide de la fonction JP525 de PERSONNALISATION DES TOLÉRANCES DES DATES.

Les dates fonctionnelles sont affichées au début de la liste.

Cette saisie est possible soit en donnant précisément la date de début et la date de fin à ne pas dépasser, soit en donnant une durée limite de début et de fin (ce qui au final nous donne un intervalle de date qui évolue en fonction de la date du jour : date du jour moins durée de début = date de début à ne pas dépasser, date du jour plus durée de fin = date de fin à ne pas dépasser), soit en renseignant les deux sachant que les bornes des deux intervalles sont facultatives.

 

L’utilisation des dates fixes et des durées sur une même date technique ou fonctionnelle a sa raison d’être.

exemple :

• une date de début minimale fixe (date de début dans l’intervalle sans date de fin)
• une date de fin variable (durée de fin dans l’intervalle sans durée de début)

 

Pour faciliter l'utilisation des dates fonctionnelles et pour connaître l'étendue de son champ d'action, un bouton permet d'afficher l'écran de GESTION DES LIENS DATES FONCTIONNELLES PAR FONCTIONS. Seules les dates sans code fonction ont accès à ce bouton.

Une date technique peut être associée à une ou plusieurs dates fonctionnelles. Dans ce cas, le principe consiste à rechercher le plus petit intervalle commun à toutes les dates fonctionnelles prévues et à appliquer la tolérance obtenue.

N.B. :
si un intervalle est associé à une date technique et à une date fonctionnelle, on ne prend que l’intervalle de la date technique. C’est uniquement lorsqu’il n’y a pas de tolérance saisie au niveau de la date technique qu’on va lire les éventuels intervalles de dates saisis au niveau des dates fonctionnelles associées.

‎

exemple :

Soit les dates fonctionnelles : DATE_ARRET_STK et DATE_ARRET_MVT

Soit la date technique : DATE_MVT_STOCK

Cette date technique est liée aux deux dates fonctionnelles décrites.

On a la tolérance suivante pour chacune des dates fonctionnelles :

DATE_ARRET_STKdu 01/01 au 15/01

DATE_ARRET_MVTdu 05/01 au 31/01

Lorsque l’utilisateur saisit une date dans la zone DATE_MVT_STOCK, il ne peut saisir qu’une valeur comprise entre le 05/01 et le 15/01 (soit le plus petit intervalle commun aux dates fonctionnelles associées à la date technique traitée)

 

Un message (ORA-20001) mentionne les dates inférieures, et supérieures de saisie autorisées.

‎ 

les MOTIFS

Lors de la saisie de modification de données, des motifs sont prévus dans certaines fonctions pour expliquer la raison de cette saisie, associés à une fonctionnalité et à un contexte.
‎

La fonctionnalité (« quoi ») d’un motif limite l’usage de ce motif à des domaines précis
‎(visu des seuls motifs autorisés pour la fonction) :

• 01 = annulation client
• 02 = annulation entreprise
• 03 = retour marchandise
• 04 = régularisation commerciale entraînant une majoration sans transfert de biens
• 05 = reliquats soldés
• 06 = arrêt commercialisation d'1 article/produit

Le contexte (« où ») donne la liste des motifs disponibles par fonction.

 

2 fonctions prévues pour gérer ceci :

• JP529 : CONTEXTES DE MOTIFS/BIB CHAMPS MOTIFS
• TA029 : MOTIFS DE MAINTENANCE

 

Le principe consiste à associer un ou des contextes pour chaque motif et à restreindre l’utilisation du motif aux seules fonctions concernées par les contextes. Ainsi, la liste de valeurs associée ne va contenir qu’un ensemble limité de motifs ne correspondant qu'à la typologie de la fonction utilisée (d’où un choix plus simple pour l’utilisateur).

Si un motif appartient à 2 contextes, on fait l'union des valeurs.

 

N.B. :
la gestion des motifs de perte des clients ou les motifs de blocage des commandes clients font l'objet d'une gestion à part (contextes particuliers), via TA215 et TA435.

‎ 

Fonctionnement

JP529W01
Bibliothèque contextes, Définition des couples « fonction / code technique motif » gérant la fonctionnalité de filtre des motifs par contexte

JP529 est la bibliothèque de tous les contextes existants et de tous les couples « fonction / code technique motif » gérant la fonctionnalité de filtre des motifs par contexte.

Dans ce module, les contextes ne sont pas figés en dur par Cegid. Seule une liste de contextes standards est pré-initialisée par défaut. En effet, il s’avère que le degré de finesse demandé au niveau de cette gestion est très variable en fonction de l’activité du site.

Ainsi, le client peut s’il le désire personnaliser ses contextes en fonction de ses besoins.

La règle pour créer des contextes consiste à faire commencer leur codification par le caractère ‘Z’ (au même titre que les fonctions internes). Ce qui permet de différencier les contextes standards Cegid de ceux spécifiques au client et surtout, de les conserver en cas de mise à jour de ce fichier.

Le second onglet de cette fonction permet chez le client d’associer les couples « fonction / code technique motif » à des contextes (soit les contextes standards Cegid, soit les contextes spécifiques client).

 

 

On ne retrouve pas dans BI :

• La différenciation Matière / PF
• La différenciation annul Entreprise / Tiers

 

Contextes standards définis par Cegid

 

Contextes correspondants à la modification d'une entité principale

Client : Tout motif correspondant à une modification des données client (*)

Article / Produit : Tout motif correspondant à une modification d'une entité principale article, produit ou modèle.

Matière : Tout motif correspondant à une modification d'une entité principale matière ou composant technique(*)

 

Contexte correspondant à un changement de statut de l'une de ces entités

Arrêt Produit Fini : Motif d'arrêt Fabrication/Commercialisation d'un Article/Produit.

Rejet Organisme Crédit : Motif de rejet du client par organisme de crédit.

 

Contextes correspondants à un "événement" de la vie d'une des entités principales

Maintenance Cde Client: Tout motif correspondant à une modification d'une commande client.

Avoir Cde Client : Motif d'avoir sur commande client.

Retour Client: Motif de retour au service après-vente.

Appro Produit Fini : Dans l'avenir, tout motif correspondant à une modification de l'approvisionnement des produits finis (motif de maintenance d'un OF ou cde négoce) (*)

Retour Fournisseur PF : Motif de retour au fournisseur Négoce saisi par NE006 ou SP001.

Appros Matière : Tout motif correspondant à une modification de l'approvisionnement des matières techniques. Motifs de maintenance des commandes ou réservations fournisseurs.

Retour Fournisseur MAT : Motif de retour au fournisseur Matière.

Dossier Technique : Motif de maintenance du dossier technique.

 

Contextes directement liés à la gestion des stocks

Mvt Stock Produit-Finis : Tout motif de mouvement divers de stocks produits finis (sorties, mouvements manuels inter-magasins, etc.).

Mvt Stocks Matière: Tout motif de mouvement de stocks composants (réceptions, mouvements manuels inter-magasins, affectation, désaffection, etc..).

 

(*): Ces contextes sont créés en vue d'éventuelles évolutions des fonctions gérant ces entités, la notion de motif n'étant pas gérée actuellement en cas de maintenance.
‎

TA029W01
Cette fonction permet la gestion des motifs de maintenance

La fonction TA029 permet de :

• Définir la bibliothèque de tous les motifs existants
• Définir les liens entre les contextes existants et les motifs
• Consulter les différents liens déjà existants entre les Contextes et les fonctions Cegid Orli
  ‎

Bibliothèque des motifs

Gestion des différents motifs et fonctionnalités des motifs utilisables dans Cegid Orli.
‎À chaque motif de maintenance, correspond une fonctionnalité.

Les codes motifs de maintenance utilisés à différents niveaux et notamment :

• pour les mouvements de stock matière première, stock produits finis.
• pour les modifications des commandes clients, commandes des fournisseurs.
• pour toutes modifications du dossier technique.
• pour la saisie des avoirs sur commandes clients.

Certaines fonctionnalités sont figées dans certaines fonctions.

• FONCTIONNALITES de 01 à 49 : RESERVEES Cegid Orli
• FONCTIONNALITES de 50 à 99 : LIBRES CLIENT

Un bouton présent à droite de la liste des motifs permet de visualiser le nombre de contexte associé au motif courant. En cliquant dessus, vous accédez à la liste des contextes du motif.

 

Contexte d’utilisation des motifs

Cet onglet permet d'associer à chaque motif le(s) contexte(s) d'utilisation du motif. Cette association est faite par la saisie d'un lien entre le code motif et un code contexte.

Par défaut lors d'une première mise en place, tous les motifs déjà saisis dans la fonction TA029 seront considérés comme appartenant à tous les contextes, il faut donc saisir dans cet onglet le lien motif/contexte pour que la gestion des motifs par contexte devienne active.

Un contexte pourra contenir entre 0 et n motifs.

Un même motif pourra être associé à 1 ou n contextes.

L'association d'un ou plusieurs contextes à un motif permettra de restreindre l'utilisation de ce code motif aux seules fonctions associées aux contextes saisis. Ainsi, dans chaque fonction, les listes de valeurs seront restrictives par rapport aux seuls motifs définis pour le(s) contexte(s) de la fonction.

‎ 

les TYPES DE MOUVEMENT

TA037W01
Cette fonction permet de gérer la liste des types de mouvements utilisés dans Cegid Orli pour caractériser certaines saisies

En conservant une trace des informations en vue d'historiques, le type de mouvement permet de connaître la transaction par laquelle a été créé le mouvement donné.

Ce type de mouvement est en général associé à la saisie d'un code motif par l'utilisateur, ce qui lui permet de signaler la raison du mouvement en vue d'éventuelles recherches.

Un code groupe rassemblant un ensemble de types de mouvement peut être saisi.
‎Il permet de regrouper sous un même code plusieurs types de mouvement représentant une même action.

Cette notion est un critère de filtre présent au niveau des consultations et éditions d'historique.
‎L'utilisateur peut ainsi saisir en filtre un groupe de mouvements qui ramènera alors tous les types de mouvements associés et qui correspondent à des actions similaires faites par des fonctions différentes.

Cette table est interrogeable à titre d'information mais ne doit en aucun cas être complétée ou modifiée par l'utilisateur car certaines fonctions utilisent des codes "en dur" pour tracer les mouvements (exemple : 01 = création).

‎Les types de mouvement appartenant à cette table sont utilisés dans l'ensemble du logiciel à l'exception des modules de GESTION DES RÉSERVATIONS MATIÈRES et GESTION DES COMMANDES MATIÈRES.

‎ 

les TEXTES

Les textes peuvent être mono ou multi-lignes.

On les retrouve dans la plupart des fiches gérées par Cegid Orli :

• article
• matière
• client
• fournisseur
• …

 

TA137W01
Cette fonction permet de définir les textes à imprimer sur les documents envoyés aux clients, en langue du site et en langues prédéfinies

Un texte multi-lignes peut être référencé dans la bibliothèque TA137 à l'aide d'un code texte.

La traduction du texte original est possible dans différentes langues.

 

Un texte non référencé est dit texte libre.

Les textes référencés comme les textes libres sont traduisibles.

 

Quelques principes dans Cegid Orli :

• les textes sont associés à la notion de type liaison, dont la fonctionnalité détermine sur quels documents les textes doivent apparaître :
  • commande
  • livraison
  • facturation
  • …
    
    du fait de cette liaison, les textes d'une fiche ne sont jamais dupliqués dans les documents

     

• les textes article/matière ne sont jamais restitués dans les documents de commande / livraison / expédition / facturation.

   

• la règle de gestion TA478 référence la liste des codes texte attribués ou exclus, sur les documents de la gestion commerciale (vente) et de la gestion de production (achats), selon des critères client/commercial ou fournisseur/production

 

 

Éditions

 

TA901W01
Cette fonction permet d'éditer les données annexes de l'environnement général

 

• États possibles d'une entité
• Unités
• Types de saison
• Saisons
• Tranches
• Monnaies
• Taux de change
• Langue
• Pays
• Motifs de maintenance
• Gestion des services internes
• Plan comptable
• Sections analytiques (1^er et 2^nd axe
• Gestion des CNUF
• Gestionnaires GPAO
• Liens gestionnaires / Utilisateurs
• Plannings de fabrication
• Caractéristiques Cegid SCM
• Liens Monnaies

 

N.B. :
les traductions des intitulés traduits, seront eux, obtenu par TA950