- La version Cegid Orli doit être à jour avec la dernière matrice corrective (disponible sur CegidLife)
- Le partage automatique de données entre les mondes Linux et Windows peut ne pas fonctionner si serveur base de donnée différent du serveur applicatif, ou si antivirus trop restrictif.
Sérialisation pour module PROD-BI
À installer hors connexions utilisateurs.
Installation JP201 et JP202 par le consultant
clients Saas
Le module BI étant automatiquement activé chez les clients Saas, les tables JP201 et JP202 sont générées par défaut à l’installation.
clients OnPrem
Pour un client avec le module MOD-BI, l’installation d’une nouvelle clé de séria est nécessaire à l’acquisition de ce module, cette installation devant générer les données JP201 et JP202 ; si tel n’est pas le cas, l’envoi d’un hotfix par la R&D sera nécessaire (base d’exemple : P22060901), avec PROD-BI, et contenir :
Type objet= PROD
Nom objet= BI
Quels sont les contacts chez le client ?
Pour les connexions (TeamViewer)
Pour le service informatique
Planning prévisionnel (installation, dates, …) ?
Quel est le consultant Cegid intervenant côté BI ?
Pour avoir les informations d'installation de la BI
Définir avec le consultant BI si les échanges doivent se faire avec des fichiers zippés
et avec AzureStorage (Obligatoire pour les clients Saas)
Pour accéder au dossier partagé de dépôt des fichiers :
Serveur : xxx.xxx.xxx.xxx)
Dossier :
D:\vtNextDW\DB_OW\BatchRepositoryIn
User de connexion windows : xxxxxx + Mot de passe : xxxxxxx
Pour accéder au portail de reporting et aux rapports systèmes :
Adresse :
http://xxxxxxxxxxxxxxxx/reports
User de connexion : xxxxxxx + Mot de passe: xxxxx
Qu’est-ce qui a déjà été fait ?
Récupération du paramétrage BI pour les répertoires :
Paramétrage par défaut :
Le répertoire de dépôt des fichiers sera : \\ServerName\BatchRepositoryIn
Sur le serveur Windows ce dossier sera : D:\vtNextDW\DB_OW\BatchRepositoryIn
Attention (vérifier si on voit le répertoire partagé côté serveur BI) :
Possible que xxx\vtNextDW\DB_OW\BatchRepositoryIn
soit directement xxx\BatchRepositoryIn
Pour les clients Saas :
Compte AzureStorage
Créer le fichier de test du partage CIFS côté BI dans le répertoire :
BatchRepositoryIn
Nom de fichier : fichier_test_cifs.txt
XC500W01 bloque si le fichier n'est pas vu sous $ODIS/PXC_BI
Accès UNIX via putty
(Si CIFS MAIS À PROSCRIRE)
Pour créer le répertoire PXC_BI et le partage CIFS
Partage de fichiers du répertoire PXC_BI
(Si CIFS MAIS À PROSCRIRE)
Récupérer :
Nom de la VM de la BI ou de la machine pour alimenter "domain"
Ex : imp-ap-010
SI le ping de la machine ne ramène rien : /etc/hosts/ rajouter IP de la machine
Vérifier :
vers=3.0 dans le cas d'un partage effectué sur un Windows Server 2012 et supérieur et sur Windows 8 et supérieur
vers=2.1 dans le cas d'un partage effectué sur un Windows Server 2008R2 et sur Windows 7
Installation de l'utilitaire cifs-utils
Cet utilitaire apporte la capacité à se connecter à un partage Windows depuis un serveur Linux.
Exécuter la commande ci-dessous dans tous les cas : s'il est déjà installé, la commande le dira et ne fera rien de plus …
sudo yum install cifs-utils -y
Création du fichier $HOME/.smbcred_BI
Ce fichier caché contient les informations de connexion au partage Windows
Attention garder l'indentation, ligne par ligne
Exécuter les commandes suivantes :
echo "username=<Login_Serveur_Windows>
password=<Password_Serveur_Windows>
domain=<Domaine_du_Login>" > $HOME/.smbcred_BI
chmod 640 $HOME/.smbcred_BI
exemple :
echo "username=ORLIWEB
password=XXXXX
domain=imp-ap-010" > $HOME/.smbcred_BI
chmod 640 $HOME/.smbcred_BI
La notion <Domaine_du_Login> ne correspond pas au domaine dans lequel est intégré le serveur Windows.
Il s'agit du domaine dans lequel le login utilisé (paramètre username) a été créé :
- Dans le cas d'un utilisateur créé localement sur le serveur Windows, la valeur sera donc le nom du serveur
- Dans le cas d'un utilisateur créé dans le domaine AD, la valeur sera donc le nom du domaine
Dans l'exemple donné ci-dessous, le serveur fait partie du domaine CEGIDALPHA mais le compte "orliweb" est un compte
créé localement sur le serveur
exemple :
Création du répertoire utilisé sur le serveur Linux pour monter le partage Windows
Sur le serveur Linux, le répertoire dans lequel va être monté le partage Windows doit être créé avant le montage, avec les droits adaptés.
Exécuter les commandes suivantes :
mkdir <Répertoire_utilisé_pour_monter_le_Partage>
chmod 777 <Répertoire_utilisé_pour_monter_le_Partage>
Exemple
Paramétrage du montage automatique du partage au démarrage du serveur Linux
Cette opération est effectué en ajoutant une ligne dans le fichier de configuration /etc/fstab.
Ceci permet également de monter ou démonter simplement le partage "à la demande" avec les commandes mount / umount
sans avoir à saisir autre chose que le nom du point de montage (et pas tous les paramètres)
Exécuter les commandes suivantes :
sudo -s
echo "//<Serveur_Windows>/<Partage_BI> <Point_de_Montage_du_Partage> cifs vers=<3.0_ou_2.1_Cf_Remarque>,credentials=/home/orli/.smbcred_BI,dir_mode=0777,file_mode=0777,uid=oracle,gid=dba 0 0" >> /etc/fstab
exit
exemple :
sudo -s
echo "//
imp-ap-010/BatchRepositoryIn /data1/orli/spool/odi/sortie/OREX1/PXC_BI cifs vers=3.0,credentials=/home/orli/.smbcred_BI,dir_mode=0777,file_mode=0777,uid=oracle,gid=dba 0 0" >> /etc/fstab
exit
Remarques
- vers=3.0 dans le cas d'un partage effectué sur un Windows Server 2012 et supérieur et sur Windows 8 et supérieur
- vers=2.1 dans le cas d'un partage effectué sur un Windows Server 2008R2 et sur Windows 7
Ne pas utiliser de variable Cegid Orli (exemple : $ODIS) pour définir le répertoire de montage du partage mais le nom complet du répertoire
Montage manuel du partage sans avoir à redémarrer le serveur
Cette étape permet de monter manuellement le partage pour qu'il soit accessible sans avoir à attendre un reboot du serveur Linux.
Exécuter la commande suivante :
exemple :
sudo mount /data1/orli/spool/odi/sortie/OREX1/PXC_BI
df -h
Vérification du partage
df –h
permet de connaitre les partages validés sur le répertoire en-cours.
who –b
permet de connaitre la date du dernier démarrage du serveur
Lancement AS500 qui regroupe tous les contrôles effectués ci-dessous
Vérifier HIST_BP_CLI_ENT_SUP et HIST_BP_CLI_ENT
Supprimer les BP HIST_BP_CLI_ENT_SUP qui sortent avec ce SQL.
SELECT A.NUM_BP FROM HIST_BP_CLI_ENT_SUP A, HIST_BP_CLI_ENT B
WHERE A.NUM_BP = B.NUM_BP
SELECT A.NUM_BP FROM HIST_BP_CLI_ENT_SUP A, BP_CLI_ENT B
WHERE A.NUM_BP = B.NUM_BP
Si option MAJ_HIST_BP non positionnée, alimenter la table HIST_BP_CLI_ENT_SUP avec :
Alimentation de HIST_BP_CLI_ENT_SUP afin de déclencher le TRG et permettre l'envoi des
Suppressions de BP. Date = mise en place de la BI.
Penser à activer l'option pour les futures suppressions.
insert into HIST_BP_CLI_ENT_SUP (NUM_BP,NUM_CDE,NUM_BE,DAT_CRE)
select a.ref_mvt,a.ref_mvt,a.ref_mvt,sysdate
from prod_his a
where a.dat_mvt > to_date('01092015','DDMMYYYY')
and a.typ_mvt in ('703','704','705')
and a.ref_mvt not like '.%'
and a.ref_mvt is not null
and not exists (select null from bp_cli_ent b where b.num_bp = a.ref_mvt)
and not exists (select null from hist_bp_cli_ent c where c.num_bp = a.ref_mvt)
and not exists (select null from hist_bp_cli_ent_sup d where d.num_bp = a.ref_mvt)
group by a.ref_mvt
Vérifier HIST_FAC_LIGN
SELECT * FROM HIST_FAC_LIGN
WHERE CODE_LIEU_ORIG IS NOT NULL AND CODE_MAGP_ORIG IS NULL;
Vérifier PROD_HIS
update PROD_HIS
set DAT_MVT_REEL = DAT_MVT
where DAT_MVT_REEL IS NULL
==> 0 enregs UPD
Vérifier lien ART_TEC/ART_COM
SELECT sais,code_art_tec from ART_TEC where (SAIS,CODE_ART_TEC) not in
(SELECT SAIS,CODE_ART_COM FROM ART_COM);
Vérifier Doublons ART_TEC_POID_VOL
SELECT SAIS||CODE_ART_TEC||CODE_COLM,COUNT(*)
FROM ART_TEC_POID_VOL
GROUP BY SAIS||CODE_ART_TEC||CODE_COLM HAVING COUNT(*)>1;
Vérification des taux de change manquants :
select code_mon from COD_TAR
where code_mon not in (select code_mon from taux_change where code_mon_taux = 'EUR')
and code_tari in (select code_tari from prix_vent)
group by code_mon
order by 1
Lancement AS601 (Contrôle des liens perdus)
JOURNAL
NUMERO DE DEMANDE: 226510 DE: LE: xx/xx/xx PAGE: 1
* PréContrôle LIENS
********************************
TA213...................... [CATEG_LIBR/CODE_CAT_LIBR] > ......... ( 013 ) [HIST_FAC_LIBR_LIGN/CODE_CAT_LIBR]=8 delete HIST_FAC_LIBR_LIGN where CODE_CAT_LIBR='013';
SELECT sais,code_art_tec from ART_TEC where (SAIS,CODE_ART_TEC) not in (SELECT SAIS,CODE_ART_COM FROM ART_COM);
Lancement AS602 (Contrôle de doublons) : OK
Lancer select de supplier_receipt(1) pour compter les doublons :
select a.num_mvt,a.typ_mvt,a.nom_user,a.dat_mvt from prod_his a, typmvt c
where c.fctn in ('140','141','142') and a.typ_mvt = c.code_typ_mvt
and exists (select null from prod_his b, typmvt d
where a.num_mvt = b.num_mvt and d.code_typ_mvt = c.code_typ_mvt
and d.fctn in ('140','141','142')
and a.code_lieu = b.code_lieu and a.code_magp = b.code_magp
and a.num_of = b.num_of and a.ref_mvt = b.ref_mvt
and a.dat_mvt_reel = b.dat_mvt_reel
and a.typ_mvt != b.typ_mvt) order by 4 desc
N.B. :
bug PR031 qui génère des tuples dans PRIX_VENT
Mêmes infos (même dat_cre à la seconde) à part le NUM_DEM
select count(*) from prix_vent a where exists (select null from prix_vent b
where a.sais = b.sais and a.code_art_com = b.code_art_com
and nvl(a.code_colm,'!') = nvl(b.code_colm,'!')
and a.code_per_tar = b.code_per_tar
and a.code_tari = b.Code_tari
and nvl(a.num_dem,0) != nvl(b.num_dem,0))
Tuples dans PRIX_REV
select * from prix_rev a where exists (select null from prix_rev b
where a.sais = b.sais and a.code_art_tec = b.code_art_tec and nvl(a.code_colm,'!') = nvl(b.code_colm,'!') and nvl(a.code_soc,'!') = nvl(b.code_soc,'!')
and a.code_per_tar = b.code_per_tar and a.code_mon_tenu = b.code_mon_tenu and nvl(a.TYP_REPA_PRIC,'!') = nvl(b.TYP_REPA_PRIC,'!') and nvl(a.TYP_REPA_PRIF,'!') = nvl(b.TYP_REPA_PRIF,'!') and a.rowid != b.rowid )
Contrôle de dates du type 01/01/0216
Contrôle réalisé par AS500
Lancer le test_date.sql (présent sous $SQL)
qui liste, dans un fichier test_dat.lst les dates < 01011700;
Ce SQL contient tous les champs date de Cegid Orli (à juillet 2016).
Il sera à réactualiser régulièrement. Pour cela lancer le SQL ci-dessous qui génère la liste des selects (présent dans svn TRUNK).
Ce SQL est généré en fonction du MCD actif au moment de sa génération.
SQL_GEN_BI_TESTE_DATES.sql
Données à re-créer dans les TA.
Actions "SQL" si impossible via les fonctions.
Lancement depuis Cegid Orli via XC500
2 modes de travail : INITIALISATION et SUIVI
Lancement du Mode INIT :
Le but est d’envoyer toutes les données de base et des faits à la BI lors d’une mise en place ou d’un INIT à réeffectuer après une perte de cohérence entre les données Cegid Orli et BI.
Lors de cette phase, il faut que la planification du mode SUIVI soit désactivé.
Il faut lancer une succession de XC500, dans l’ordre indiqué ci-dessous :
1 : Données de base :
- N° Ordre entité < 253 000
- Sans Date
2 : Produits pour factures libres :
- N° Ordre entité = 300 000
- Sans Date
3 : Tous les produits :
- N° Ordre entité = 300 000
- Avec Date > à la date de la 1ère création d’un article
(SELECT MIN(DAT_CRE) FROM PROD_COM).
Selon la volumétrie, il peut être utile de lancer les XC500 par intervalle de date4 : Les regroupements commerciaux :
- N° Ordre entité = 310 000
- Sans Date
5 : Les Bons de chargements :
- N° Ordre entité = 900 000
- Sans Date
6 : Les Faits :
- N° Ordre entité > 1 000 000
- Avec Date par intervalle : Il faut partir de la 1ère date des faits à envoyer et lancer les XC500 par intervalles selon le temps de chaque traitement :
- Exemple : il faut envoyer depuis le 01/01/2020 :
- On fait un 1er lancement du 01/01/2020 au 31/01/2020
- S’il est rapide, on peut lancer le suivant du 01/02/2020 au 30/04/2020 et ainsi de suite
7 : Le Stock en-cours :
- N° Ordre entité = 2 200 000
- Sans Date
Lancement du Mode SUIVI :
Le but est d’envoyer toutes les données modifiées dans Cegid Orli.
Il faut créer un filtre qu’il faudra lancer TOUS les jours d’activité (JP532)
Voir avec le consultant BI à quelle heure le déclencher : il faut que ce soit 1 à 2 heure avant l’import automatique dans la BI et en dehors de l’activité dans Cegid Orli.
Le mode SUIVI doit bien être lancé et planifié quand le mode INIT est complétement fini.
ORA-20001: Erreur Conversion entre Monnaies GBP EUR 121115 15H (1)
- Remplir TA100
Faire un TRUNCATE de PXC_DATA et TO_DO
Filtres XC500 pour mode suivi + planifier JP532
- Mode "suivi" (2) + planification JP532 (création en utilisant filtre de XC500 + voir file dans JP531)
- Pour l’init faire un JP025 avec les filtres de XC500. Faire un envoi par mail pour avoir le suivi en étant déconnecté.
Liste des tables Cegid Orli
(count à traiter depuis dernier envoi)
Enregistrements de PXC_REC à traiter depuis dernier envoi :
select nomfic,count(*) from pxc_rec where 1= 1 and dat_rec > (select to_date(val_opt,'DDMMRR HH24:MI:SS') from pxc_part_opt where nom_opt = 'LAST_TODO') group by nomfic order by 2/
Stockage des PXC_REC (fonctionnement)
Ex: TRG Sur LIV_FAC_LIGN on stock des ORLTYP_COL car 3 entités suivent cette table
Chacune stocke des champs différents :
NUM_FACT pour SALES
NUM_BP pour CUSTOMER_DELIVERY
SAIS_ART + CODE_ART_COM + CODE_COLM pour CURRENT_STOCK
ORLTYP_TAB_COL(
ORLTYP_COL('NUM_BP', '264852', NULL, NULL),
ORLTYP_COL('SAIS_ART', '16P', NULL, NULL),
ORLTYP_COL('CODE_ART_COM', 'EC0051-16P006A', NULL, NULL),
ORLTYP_COL('NUM_FACT', '.', NULL, NULL),
ORLTYP_COL('CODE_COLM', '23EC', NULL, NULL))
2 entités sont envoyées en suppression
CUSTOMER_DELIVERY(3) = suppression des livraisons (LI011).
Il faut mettre la valeur à 1 dans l’option MAJ_HIST_BP :
PURCHASE(1) = suppression des factures/avoirs fournisseur (CF001)
Envoi des suppressions :
Sur les « Facts » il n'y as pas d'annule remplace ; le mode INIT permet juste de lever les contrôles d'intégrité afin d’envoyer de gros volume en plusieurs fois.
Options
- MAJ_HIST_BP=1
- PR022 / PR021
MOD_TAR_SI_LCDE
ACCE_REPER_CDE
ACCE_PRIX_SPEC
+ Critères de répercussion cde sur PR021.
Il faut obliger la répercussion sur commandes et mise en prix spéciaux si on veut pouvoir avoir les bons prix à l'avenir en cas de « renvoi » des commandes et factures.
Le connecteur envoi en priorité les prix spéciaux pour les commandes et facture. Si les créations /Modifications de prix de vente n’ont pas été répercutées sur les commandes avec mise en prix spéciaux, il est possible que l’ors de l’initialisation de la BI, le connecteur trouve un nouveau prix (dans PR022) pour la même période de tarif et donc applique ce dernier.
- LA001W01/SUPPR_LIGNE=2 pour empêcher la suppression physique d’OF.
Celui-ci pourrait avoir été envoyé à la BI entre sa création et sa suppression.
Si recherche d’une information directement dans les archives sans passer par le rapport :
- Dans le dossier « D:\vtNextDw\DataArchiveLoad » du serveur BI
- 1 dossier par import (nom du dossier avec date heure)
- Le zip est géré avec 7zip, plusieurs fichiers possibles si gros volume, tous les fichiers avec extension « .001 » « .002 » etc…
- 7 zip est installé sur le serveur BI
- Mot de passe pour dézipper les fichiers archives de la BI : Ext3rn1lSource
La génération des fichiers Cegid Orli vers BI nécessite un stockage Azure Storage, avec :
- Un compte Azure Storage accessible via Microsoft Azure Storage explorer :
- Compte de stockage
exemple :
bidevorli
- Blob Container
exemple :
dbowin
- Compte de stockage
- Un répertoire externe (JP015) :
| Mode transfert | Nom physique externe | Répertoire externe | Utilisateur |
|
Azure Storage |
=Compte de stockage |
=Blob Container |
=Compte de stockage |
- Le référencement de ce répertoire externe pour le partenaire BI (JP201)
- Le lancement du XC500 doit se faire avec :
- Génération des fichiers = ‘0’ ‘Répertoire externe du partenaire’
- Sur la page de routage, il ne faut pas choisir l’extraction vers un répertoire MAIS plutôt à l’écran. Le répertoire cible est celui du JP201 et plus celui indiqué ici.