Version imprimable
Bonjour
La version 7.3 de DIVALTO est basée sur SQL (MS SQLserver).
Des procédures d'importations par excel existent dans le logiciel mais certaines sont assez lourdes et d'autres manquent.
Quelqu'un aurait il une expérience d'importation de données directement en SQL dans une base DIVALTO ? sachant qu'il y a évidemment des règles de cohérence à suivre...
merci
Cdlt.
Re bonjour Old_Chap,
comme vous le savez ;) je n'ai aucune expérience Divalto mais je connais SQL server.
La première chose à vérifier c'est si DIVALTO rajoute une information (une clé unique par exemple) entre la table SQL et la table utilisable dans DIVALTO.
La deuxième chose c'est l'évolution (split, ajout de champ...) des tables qui doit être documentée.
Ensuite vous pouvez utiliser l'outil SSIS avec SQL server à condition d'avoir une licence Visual Studio, il est très facile d'utilisation car une fois la connexion ODBC réalisée sur votre ancienne BDD il suffit de faire des clics de souris pour créer le flux d'import dans votre nouvelle bdd. Bien sur il y a d'autres ETL mais je n'ai pas eu l'occasion de m'en servir.
D'ailleurs comment sont réalisés les procédures actuelles DIVALTO ? Ce n'est quand même pas des macros Excel ?
Cdt
Castorameur
merci de votre réponse.
Actuellement, la base de données de DIVALTO ne présente pas de contraintes, ni de trigger.
donc les contrôles de cohérence se font dans le code du logiciel lui même.
les importations de données par Excel se font par lien direct OLE vers le tableau Excel ouvert avec contrôle de cohérence et rapport en cas d'erreur.
c'est bien fait mais assez lourd.
DIVALTO ne communique pas sur un import direct dans la base SQL.
cdlt.
S
[QUOTE]Actuellement, la base de données de DIVALTO ne présente pas de contraintes, ni de trigger./QUOTE]
Je vous rassure ce n'est jamais le cas quelques soit les erp, ce qui permet de facilement passer d'un serveur de bdd à un autre sans problème.
La logique métier et les contraintes sont toujours développé dans des outils propre à l'ERP.
Sinon une fois la feuille Excel ouverte, vous lancez un traitement dans DIVALTO qui réalise l'import et le contrôle, c'est cela ?
En fait un import direct dans la base sans contrôle peut faire planter l'ERP à l'ouverture d'un écran.
Mais si vous réalisez vos controles avant d'ouvrir l'ERP en prod, c'est une démarche envisageable.
cdt
s.
Nouvelle sur le forum, je poste quand même une réponse, avec un temps de retard, certes...
Avec l'arrivée de SQL Server, l'idée d'attaquer directement la base Divalto en SQL est extrêmement tentante, néanmoins, cette technique est à éviter au maximum.
Les programmes Divalto d'import de données (qui s'appuient sur Excel notamment) permettent de garantir:
- l'intégrité fonctionnelle de la base, via une batterie de contrôles sur les données chargées
- l'intégrité technique, notamment vis-à-vis des clés étrangères qui ne sont pas implémentées sous forme de contraintes dans la base de données
- la performance de la base: la base de l'ERP contient un certain nombre de colonnes additionnelles techniques remplies par les traitement d'import et nécessaires pour des performances optimales
En bref, sur une table purement spécifique pourquoi pas faire un peu de SQL, pour le reste, c'est à éviter, voire à proscrire totalement pour le cas du moteur de pièces commerciales.
Dans tous les cas, rien n'est figé au niveau des programmes de chargement de données: on peut les surcharger, pour ajouter de nouveaux contrôles notamment, ou en créer de nouveaux.
Voilà, j'espère que ça répond à votre question...
BonjourCitation:
Envoyé par Ebsilon
Merci pour votre réponse.
Je comprends bien les risques d'importer directement dans les tables en SQL.
Néanmoins, les outils proposés par DIVALTO ne sont pas complets.
Par exemple, je n'ai pas trouvé de quoi importer dans les "affaires" dans DIVALTO.
Or j'aurais besoin de reprendre des données du logiciel actuel pour les importer dans cette table Affaires (PRJAP) , qui est une table importante.
D'autres modules (DAV) proposent des outils d'importation de pièces, mais pas le module CRM.
Ce n'est pas très homogène.
D'autre part, l"écosystème" DIVALTO me parait très fermé : pas de forum, pas ou peu d'échange entre intégrateur, pas de communication de DIVALTO vers les clients finaux... A l'heure de l'open source, c'est assez décevant.
Cdlt
Avant de vous répondre plus spécifiquement sur la partie Divalto, je me permets de vous livrer mon expérience générale sur la partie reprise de données liée à un projet ERP.
Bien souvent, l'intégrateur est peu impliqué dans ce sous-projet, notamment car il n'a pas la maîtrise du système existant et a donc une valeur ajoutée toute relative quant à la définition des règles métiers de reprise. Ca me semble toutefois hyper important de le responsabiliser également dans cette phase: si vous menez le chantier avec une trop grande indépendance, vous risquez des échanges interminables après la bascule pour déterminer qui de la donnée ou du programme est responsable de tel ou tel dysfonctionnement constaté.
En dehors de ces questions de responsabilité et pour revenir plus concrètement au cas Divalto, il est possible de créer des surcharges pour charger les tables pour lesquelles le standard ne propose pas d'outil. Si vous êtes à l'aise avec l'AGL, vous pouvez procéder par analogie avec un programme d'import existant, sinon, le mieux est de se rapprocher de votre intégrateur pour un transfert de compétence sur le sujet ou la réalisation d'un petit développement visant à combler le manque constaté.
D'une manière plus générale, Divalto fonctionne en mode de distribution indirect et, à ce titre, s'appuie fortement sur ses intégrateurs pour accompagner les clients finaux dans les différentes problématiques rencontrées, mais également pour remonter les remarques de ces derniers dans une optique d'amélioration du produit. D'où l'importance d'une bonne collaboration avec votre intégrateur, ce qui n'est pas toujours simple, j'en conviens!
Pour ce qui est des forums et autres moyens de communication type 2.0, c'est vrai que ce n'est pas très courant à ce jour mais je ne saurai vous dire s'il s'agit d'une volonté de l'éditeur ou tout simplement une question de maturité du produit sur le marché. Dans tous les cas, nous sommes sur un ERP propriétaire, l'idée d'échanges similaires à ceux que l'on retrouve sur une communauté open source est donc à écarter d'emblée!
En fait, j'en suis à chercher une solution par moi-même justement parce que l’intégrateur me fait défaut.
Chaque demande pour combler un manque évident de l'ERP donne lieu à un devis HDP :mouarf:
Je travaille avec un autre produit métier autour d'une base oracle, et l'éditeur à compris depuis longtemps qu'échanger avec ses clients (ceux qui sont intéressés), lui facilite les choses.
Etre obligé de demander des développements pour chaque table principale d'un ERP, c'est un peu for de café (What Else ?)
Maintenant, je suis bien conscient des problèmes de responsabilités que cela peut engendrer.
A plus.
BonjourCitation:
Envoyé par Ebsilon
pour faire suite à ce sujet:
je regarde ce matin dans les sources livrées avec le logiciel et je ne trouve pas de programme d'import/export:
exemple: programme gtppimpexp.dhop, le gtppimpexp.dhsp n'est pas livré.
donc difficile de procéder par analogie ;)
cdlt
Effectivement le programme que vous citez n'est pas disponible dans les sources fournies par l'éditeur, peut-être que votre intégrateur peut se les procurer?
Sinon, je ne suis pas développeur, mais il me semble que vous trouverez de la matière de certains sous-projets gt_outil *, à voir...
Bonjour Old_Chap,
Nous nous permettons de réagir à votre message du 29/12 quant à votre question sur les imports des affaires dans Divalto. Vous pouvez, après validation de votre intégrateur, charger cette table via les outils de SQL server à partir d’un fichier à plat, par exemple.
Quant à votre observation, nous sommes navrés que notre écosystème vous semble fermé. Nous mettons au service de nos intégrateurs de nombreux outils afin de les accompagner ainsi que des actions pour souder notre réseau de partenaires (rencontres, webconférences…) . Et il en est de même avec nos clients utilisateurs. Nous leurs adressons des communications régulières par le biais de nos newsletters et de nos emails. Depuis 2012, Divalto organise son Divalto Tour et invite l’ensemble de ses utilisateurs pour mieux échanger autour de nos produits.
Nous restons à leur disposition avec le soutien de nos intégrateurs qui connaissent les spécificités des dossiers de nos clients.
La satisfaction de nos utilisateurs est primordiale pour Divalto. C’est pourquoi nous vous invitons à nous recontacter à l’adresse communication(a)divalto.fr afin de vous mettre en relation avec l’un de nos experts.
Bonjour
Je réponds un peu tardivement à votre réponse,désolé.
Merci pour cette adresse mail que je vais donc utiliser.Citation:
Envoyé par divalto
Cordialement.
bonjour a tous,
je suis GHASSEN KCHAOU, ingénieur mécanique, nouveau participant ici et j'occupe le poste d'un responsable GMAO dans une industrie.
On a ERP DIVALTO, je veux faire tourner le module GRM convenablement
je veux quelqu'un qui peut m'aider et m'informé.
merci beaucoup
Bonjour,Citation:
Envoyé par GHASSEN KCHAOU
Je suis intégrateur Divalto depuis quelques années.
Pour démarrer un module en particulier, il y a une souvent une phase d'analyse et d'adéquation en amont.
Si vous le désirez on pourrait en parler en mp ?
Pour répondre, éventuellement, à la question première, on peut écrire directement dans la base SQL. Mais il faut quand même connaitre l'ensemble des contraintes référentielles.
Pour ma part, à chaque projet Divalto que j'ai démarré, nous avons réécrit de petit module d'import spécifique. Ceci sont écrit en Diva et peuvent récupérer des datas via un canal ODBC.
Cordialement
Pascal
Bonjour,
En tant que nouvel intégrateur, je ne peux vous conseiller qu'une chose : demandez à votre intégrateur (ou votre service informatique si vous l'avez formé au SDK) d'écrire un module d'import.
Ce qui est lent avec les imports Divalto, c'est la connection OLE avec Excel.
Mais si on passe par un fichier plat (CSV par exemple, voir à pas fixe pour plus de performances) on peut avoir d'excellentes performances (plusieurs milliers de fiches client en quelques minutes).
Ce type d'import, si en amont vous avez bien préparé le terrain (identification des données à importer avec matching exact écran par écran), ça peut se faire en quelques heures.
Attention quand même à ne pas vouloir aller trop vite : il faudra toujours mettre en place (à la main dans le code du programme) les contrôles de cohérence.
Par exemple, si vous intégrez des clients sans indiquer de compte de vente, ça va marcher... sauf qu'il sera impossible d'ouvrir la fiche du client ensuite !
BonjourCitation:
Envoyé par StringBuilder
Merci pour cette réponse.
effectivement depuis je me suis formé au SDK et je développe mes imports.
J'en profite pour signaler que je souhaiterais monter un club utilisateur DIVALTO : toute bonne volonté est bienvenue.
Cdlt
Je viens de découvrir qu'il y avait une section (assez déserte, certes) Divalto sur ce forum.
Je vais donc venir régulièrement maintenant :)
Mais pas en tant qu'utilisateur :D