Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Divalto Discussion :

DIVALTO V7.3 : importation de données en SQL


Sujet :

Divalto

  1. #1
    Membre régulier
    DIVALTO V7.3 : importation de données en SQL
    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.

  2. #2
    Membre éprouvé
    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

  3. #3
    Membre régulier
    DIVALTO V7.3 : importation de données en SQL
    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

  4. #4
    Membre éprouvé
    quoteActuellement, 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.

  5. #5
    Futur Membre du Club
    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...

  6. #6
    Membre régulier
    DIVALTO 7.3 : import de données
    Citation Envoyé par Ebsilon Voir le message
    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...
    Bonjour

    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

  7. #7
    Futur Membre du Club
    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!

  8. #8
    Membre régulier
    DIVALTO 7.3 : import de données
    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
    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.

  9. #9
    Membre régulier
    Citation Envoyé par Ebsilon Voir le message

    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é.

    !
    Bonjour

    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

  10. #10
    Futur Membre du Club
    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...

  11. #11
    Membre à l'essai
    Suite au message du 29/12
    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.

  12. #12
    Membre régulier
    Import direct dans tables AFFAIRES
    Bonjour

    Je réponds un peu tardivement à votre réponse,désolé.

    Citation Envoyé par divalto Voir le message
    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.

    >> Justement, mon intégrateur refuse de valider cette démarche sans l'accord de l'éditeur (donc DIVALTO) : on tourne un peu en rond , non ?


    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.

    >>Je reçois bien vos newsletters, mais elles ne traitent que de sujet commerciaux (ce n'est pas péjoratif, mais ce n'est pas ce qui m'intéresse).


    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.
    Merci pour cette adresse mail que je vais donc utiliser.

    Cordialement.

  13. #13
    Candidat au Club
    Demande information sur module GRM DIVALTO 7.2 (fonctionelle)
    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

  14. #14
    Candidat au Club
    Bonjour
    Citation Envoyé par GHASSEN KCHAOU Voir le message
    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,

    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

  15. #15
    Expert éminent
    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 !
    On ne jouit bien que de ce qu’on partage.

  16. #16
    Membre régulier
    DIVALTO :: import
    Citation Envoyé par StringBuilder Voir le message
    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 !
    Bonjour
    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

  17. #17
    Expert éminent
    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
    On ne jouit bien que de ce qu’on partage.

###raw>template_hook.ano_emploi###