IRC logs of #tryton-fr for Friday, 2011-12-09

chat.freenode.net #tryton-fr log beginning Fri Dec 9 00:00:01 CET 2011
sisalpBonjour12:23
sisalpj'ai des démandes récurrentes pour migrer d'openerp V5 ou v6.0 vers tryton12:23
cedksisalp: les systèmes sont assez différent pour qu'on ne puisse pas faire tout automatiquement12:24
cedksisalp: sauf peut-être pour un set restraint de modules12:24
sisalpl'outil idéal de migration extrairait les données d'openerp pour peupler la base tryton avec les informations de base12:24
cedksisalp: oui c'est une possibilité12:25
sisalpun ensemble restreint de modules serait tout a fait suffisant12:25
cedksisalp: du genre: partner, product ?12:25
sisalple référentiel : party/product12:26
cedksisalp: c'est faisable si on accepte de ne pas reprendre tout les infos12:26
sisalpl'historique : devis, factures, livraisons si possible12:26
cedksisalp: parce qu'il y a des champs dans OE qui n'ont pas d'équivalent dans Tryton12:26
sisalpseules les infos utiles dans tryton sont à conserver12:27
cedksisalp: sale, invoice et shipment c'est plus compliqué12:27
cedksisalp: sauf si on by-pass workflow etc.12:27
sisalpoui c'est plus compliqué. On peut aussi dégrader l'information12:27
sisalpc'est à dire que les documents repris ne sont pas liés entre eux par la logique d'openerp12:28
cedksisalp: oui on peut imaginer les inserer dans la DB (sans workflow) dans l'état done12:29
sisalpon ne reprend pas des encours d'openerp dans tryton12:29
cedksisalp: et on ne génére rien12:29
sisalpoui, c'est un historique pour ne pas en perdre la trace12:30
cedksisalp: mais est-ce que le plus simple n'est pas de faire juste reprendre le ref, les utilisateurs réencode l'encours à la main12:30
cedksisalp: et il garde OE comme historique12:30
sisalpavoir tout l'historique dans tryton, c'est pas mal12:31
sisalpmême si les champs ne sont pas liés entre eux12:31
sisalpoui, dans un premier temps il peut garder les deux systèmes12:32
cedksisalp: si tu veux avoir les liens etc. c'est une migration complete de système et je pense que ce n'est pas automatisable12:32
sisalpil n'est pas important d'avoir les liens, mais est-ce qu'on sait garder un historique en remplaçant les liens par leur valeur ?12:34
cedksisalp: tu pense qu'il y aurait un financement possible d'une tel solution via Elveos?12:34
sisalple problème d'elveos c'est que le projet commence quand il est financé.12:35
cedksisalp: en fait pour une vente par example, il faut faire les liens avec le party, l'address et les produits (produit c'est accessoire)12:35
cedksisalp: sinon c'est faisable via SQL12:37
sisalpquoi par sql ?12:37
cedksisalp: l'insersion dans la DB12:37
cedksisalp: sinon si on passe par proteus on a tout la mechanic des workflow et check en tout genre qui vont bloquer12:38
sisalpon pourrait faire deux projets elveos 1 reprise party/produits 2 reprise d'une partie historique12:41
sisalpsi la partie 1 est pas cher, le premier qui en aura besoin la financera12:41
sisalpsi la partie 2 peut s'exécuter sur un système déjà en fonctionnement, le client pourra contribuer et attendre12:42
cedksisalp: oui12:43
bechamelsisalp: tu n'a pas de réticence à suggérer l'utilisation d'elveos à un client/prospect ? c'est déjà difficile à faire comprendre à des habitués de l'open-source ..12:46
sisalpje lui vendrai, puis je financerai sur elveos12:48
sisalpce que le client ne sait pas faire, c'est évaluer si sa contribution aboutira un jour au développement12:49
cedkbechamel: je suppose que le problème c'est qu'un tel dev est rentable si c'est pour plusieur migration12:49
sisalpsi partie 1 est amortissable en une fois, c'est jouable12:50
cedksisalp: oui mais il ne faut pas oublier qu'il peut la reprendre tant que le montant n'est pas atteint12:50
sisalpd'où le besoin d'avoir un financement par un seul projet, ou bien deux projets si ils tombent juste en même temps12:51
cedksisalp: je pense qu'une fois que c'est lancé, il y a de fort chance que d'autre y participe12:52
cedksisalp: ton client peut bootstraper la proposition et se fixer un delai avant de reprendre ça participation12:53
bechamelj'imagine que bcp de monte est intéressé par l'idée12:53
cedkbechamel: oui surement en faisant un peu de pub (sur tweeter :-)12:54
sisalpoui mais mes clients découvrent tryton, si ils se décident il doivent savoir si ils peuvent migrer au 1er janvier avec leurs données12:54
cedksisalp: c'est un peu short de penser à migrer seulement 20 jours avant la date12:55
sisalpl'erp n'est plus ce qu'il était. Installer et démarrer sous tryton quand on connait openerp V5 ne demande pas des mois dans une TPE. Le client de ce matin : 2 utilisateurs12:57
sisalpfonction utilisée : gestion commerciale et facturier12:57
bechamelsisalp: et migrer en cours d'année est hors de question ?12:58
sisalpcertains vont se poser des questions sur cette fin d'année car openerp va aussi vers une migration et 6.1 n'est pas près en début d'année12:58
sisalpbechamel : si bien sûr, surtout si la compta n'est pas utilisée pour de vrai12:59
bechamelsisalp: ok12:59
sisalpbechamel : ça marche pour les TPE13:00
sisalpmais décembre/janvier et la migration V6.1 (short term version à priori) me semble favorable pour communiquer13:01
bechamelsisalp: oui, dommage que l'on soit si tard dans l'année, on ne peut rien avancer de concret13:04
cedkje suis d'accord, c'est le genre de chose qui serait bien de planifier quelque mois à l'avance13:05
cedksisalp: on peut peut-être faire un proto qui suffirait à ton client et par après le rendre générique13:06
bechamelpar contre je suis convaincu qu'un premier script de migration product/party va ammorcer la pompe et que des scripts complémentaire vont suivre pour le reste des données13:07
cedkoui surement13:14
cedksisalp: je propose que tu nous envoie les besoins et on y regarde rapidement13:14
sisalpbechamel: c'est exactement l'idée13:18
jcmcedk: je suis sur sale shipment cost weight16:37
jcmça a l'air de marcher bien16:37
jcmpar contre une fois l'unité de poids choisie dans le carrier, on ne peut plus la changer16:37
jcmest-ce volontaire ?16:37
cedkjcm: oui si tu a des lignes16:39
cedkjcm: puisque les valeurs des lignes dépendent de l'unité16:40
jcmjustement, j'ai choisi grammes puis saisi en kg (en recopiant mon tarif). Soit je rechange toute la liste, soit je corrige l'unité en kg ;-)16:46
cedkjcm: oauis mais c'est pas logique16:47
jcmpar ailleurs est-ce possible d'avoir sur la vue ventes l'affichage du total de poids ?16:47
cedkjcm: ce serait possible16:48
jcmcedk: en pratique je vais être obligé d'effacer mon transporteur et de le recréer, c'est pas très logique non plus de tout ressaisir...16:48
jcmcedk: les nombres sont bien affichés avec virgule, en français, mais pas avec séparateur de milliers (espaces). Est-ce une amélioration envisageable ? j'ouvre un bug ?16:51
jcmcedk: en fait ça ne marche pas tout à fait : le dernier prix de la liste de prix est sélectionné dans tous les cas ; je vais lire le code pour voir d'où ça peut venir16:53
cedkjcm: non, dans le client on ne met pas de séparateur de millier mais bien dans les rapports16:53
cedkjcm: la liste est une liste ouverte16:55
jcmcedk: cela veut-il dire qu'il faut rajouter du code pour sélectionner l'item de la liste dont le poids est immédiatement supérieur au poids total de la vente ?17:00
cedkjcm: je comprend pas17:03

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!