IRC logs of #tryton-fr for Thursday, 2017-05-18

chat.freenode.net #tryton-fr log beginning Thu May 18 00:03:01 CEST 2017
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr01:09
-!- semarie(~semarie@unaffiliated/semarie) has joined #tryton-fr01:26
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr08:04
-!- mrichez(~smuxi@mail.saluc.com) has joined #tryton-fr09:02
-!- fabix(~chatmovil@qena.raceme.org) has joined #tryton-fr09:49
fabixbonjour09:49
fabixactuellement, notre système de facturation est basé sur openerp 6.0 ; on va étudier le remplacement de ce dernier par qqch de plus récent09:51
fabixbcp de traitements sont effectués via des pl/sql09:52
fabixpeut-on continuer à utiliser de telles procédures avec tryton ?09:54
fabixou faut-il recoder les traitement en pur python ?09:54
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr10:02
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr10:02
cedkÉvidement maintenir du code pl/sql dans la DB est assez fastidieux10:05
fabixnotre facturation brasse des quantités énormes de données10:06
fabixy a pas mal de jointures et de très nombreuses lignes10:06
fabixc'est un traitement batch ; on fait pas client par client10:07
cedkfabix: OK mais je ne vois pas très bien le sense de la question10:07
cedkest-ce une demande d'autorisation?10:08
fabixest-ce qu'on peut continuer à utiliser des pl/sql ou c'est pas possible ?10:08
fabixla procédure génère des tuples10:08
fabixet ça met à jour des compteurs et autres données10:09
fabixje ne sais pas si c'est vraiment propre un tel mode de fonctionnement10:09
cedkfabix: il n'y a que les personnes qui ont écrit ce code qui puisse répondre10:10
fabixils l'ont écrit pour openerp10:10
cedkfabix: "propre"?10:10
fabixinsérer/modifier des données directement dans pg, sans passer par l'orm10:11
fabixpar ex: INSERT INTO consommation (create_uid, create_date, write_uid, write_date, code_acces_transmis, code_acces_id, no_session, no_sequence, date_consommation, heure_consommation, date_parution, code_banque_transmis, banque_id, document_id, format_id, document_format_id, statut_soumis_a_souscription, service_id, contrat_ligne_id, contrat_id, ligne_service_cle_echange, ligne_service_id, quantity, sous_compte, code_application_transmis, application_id,10:13
cedkfabix: c'est sûr que ça peut poser des problèmes si c'est mal fait10:15
fabixc'est pour savoir si on peut éventuellement transposer ce qui a été fait vers tryton ou s'il faut tout reprendre from scratch10:15
fabixon pourrait aussi continuer sur Odoo mais j'aime pas bcp ce que c'est devenu10:17
cedkfabix: j'ai pas de réponse magique :-(10:18
fabixest-ce possible au moins d'exécuter des procédures pl/sql ou est-ce que l'usage de python-sql l'interdit ?10:19
-!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr10:23
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr10:26
sisalpfabix: python-sql ne bloque pas des fonctions postgresql.11:45
sisalpfabix: Si vous avez fait ce code vous mêmes, essayer de la transposer au nouveau modèle de données11:45
sisalpfabix: si votre code contournait simplement des limitations d'openerp, peut-être faut il le revisiter pour Tryton qui n'a pas les mêmes limitations.11:47
fabixon a fait appel à un presta qui avait codé notre précédent système de facturation avec les outils oracle11:48
fabixils ont gardé la même logique qd ils ont refait le système sous openerp11:49
sisalpfabix: Il y a fort à parier alors qu'une reconsidération globale sera bénéfique. Au pire, sans effet.11:50
-!- winter_(4c46eb94@gateway/web/freenode/ip.76.70.235.148) has joined #tryton-fr15:53
-!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr15:56
-!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr15:56
winter_bonjour, y a-t-il quelqu'un qui saurait comment creer de nouveaux produits en continu? scenario: import de donnees d'un configurateur externe, chaque commande comporte de nouveaux produits qui devront etre crees dans tryton16:10
cedkwinter_: il faut écrire un script soit avec proteus soit via wizard16:15
winter_merci. y a-t-il une facon preferable de faire ceci? en fait, les produits seraient trop nombreux pour qu'ils puissent etre geres. la situation est comme suit: quantite limitee de types de produits mais quantite illimitee de couleurs (interieur/exterieur) par produit16:20
winter_y a-t-il une facon concise d'obtenir des produits configurables avec variantes mais que chaque variante soit listee comme tel dans les modules appropries comme la production?16:21
-!- thaneor(~ldlc6@179.26.110.118) has joined #tryton-fr16:21
cedkwinter_: tous les produits sont des variantes d'un modèle16:22
winter_je comprends mais mon environnement exige essentiellement des variantes de produits pour chaque commande qui doivent cesser d'exister une fois la commande complete (sinon il y en aura une quantite trop massive)16:25
winter_ainsi une commande pourrait comprendre Produit1-Rouge-Bleu mais aussi Produit1-Bleu-Rouge - comment les differencier d'un point de vue de production?16:25
winter_sans creer des produits permanents16:25
winter_je me demandais s'il existait deja une solution ou un modele elegant pour cela16:27
cedkwinter_: je comprends pas. Quoi qu'il soit créer ça doit rester dans la DB pour l'historique16:31
cedkwinter_: donc je ne vois pas pourquoi ne pas créer des variantes16:31
winter_principalement parce que les produits sont composes de nombreux elements qui eux aussi ont le meme probleme: SousComposante1-Bleu-rouge, SousComposante1-Rouge-Bleu, donc il y aurait plusieurs centaines de milliers de variantes tres rapidement16:34
winter_peut-etre n'y a-t-il pas d'autre facon16:34
cedkwinter_: ne pas stocker cette information16:35
winter_elle est necessaire pour la production... lorsque la commande est creee, les variantes de produits et les variantes de leurs sous-composantes doivent etre generees et gerees par tryton par la suite16:37
winter_peut-etre qu'il n'y a pas d'alternative a creer ces millions de variantes. je me demande si cela va poser un probleme pour la base de donnees16:39
cedkwinter_: donc il n'y a pas de probleme16:40
cedkwinter_: ça dépendra de la quantité et de la machine16:40
cedkwinter_: mais j'ai l'impression que ce n'est pas de la production standardisé et donc il ne faut pas utiliser le module de production ni de stock16:41
winter_la machine est excellente mais il s'agit veritablement de millions de variantes.16:41
cedksi tout est crée pour chaque "ordre", il n'y a rien à plannifier ni a anticiper16:42
winter_exact, tout est sur mesure. si je genere les variantes au fur et a mesure que j'importe les commandes du configurateur externe, il serait possible d'utiliser le module standard de production, non?16:42
cedkwinter_: je ne met pas en doute la machine, juste que c'est une question de capacité16:42
cedkwinter_: standard != spécifique16:42
cedkpour moi, ce n'est pas de la production standardisé puisque tout est different à chaque ordre16:43
winter_exact. ce qui varie a chaque commande c'est la couleur interieure et la couleur exterieure. il faut commander les composantes avec la bonne couleur16:44
winter_l'ideal serait de stocker l'information dans la commande unique elle-meme sans creer de variantes "officielles"16:50
cedkwinter_: ça changerai quoi?16:51
winter_au lieu d'avoir des millions d'objects "variantes" il n'y aurait que 2 champs strings par produit et par composante, par commande16:52
cedkwinter_: je vois pas vraiment de différence16:54
cedkwinter_: en plus si c'est juste sur la vente, c'est que ça sert pas à grand chose16:54
winter_je me disais que je pourrais generer le BOM et les achats en python16:55
winter_c'est pour la taille de la base de donnees et la performance - avoir une table "variantes" avec des millions d'entrees pourrait etre une source de problemes...et si quelqu'un ouvrait l'onglet "variantes" la requete serait massive16:56
winter_ce genre de probleme16:56
cedkwinter_: je vois pas où est le problème16:57
cedkwinter_: surtout que c'est le même pour la vente16:57
winter_peut-etre. je ne suis pas tres familier avec la structure de donnees tryton, la difference est peut-etre minime...16:58
cedkwinter_: ça n'a rien avoir avec Tryton16:58
winter_seulement s'il est vrai qu'une variante et toute sa description occupe le meme espace qu'un champ string, non?17:00
winter_et que les requetes dans l'interface de l'utilisateur sont telles qu'une requete accedant ces millions de variantes est exclue (ou efficace)17:02
winter_il y aurait 100 personnes accedant a tryton simultanement...17:03
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr17:21
-!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr18:22
-!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr18:25
-!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr18:36
-!- thaneor1(~ldlc6@179.26.16.43) has joined #tryton-fr21:14
-!- semarie(~semarie@unaffiliated/semarie) has joined #tryton-fr22:01

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