| chat.freenode.net #tryton-fr log beginning Thu May 18 00:03:01 CEST 2017 | ||
| 2017-05-18 01:09 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | ||
| 2017-05-18 01:26 -!- semarie(~semarie@unaffiliated/semarie) has joined #tryton-fr | ||
| 2017-05-18 08:04 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | ||
| 2017-05-18 09:02 -!- mrichez(~smuxi@mail.saluc.com) has joined #tryton-fr | ||
| 2017-05-18 09:49 -!- fabix(~chatmovil@qena.raceme.org) has joined #tryton-fr | ||
| 2017-05-18 09:49 <fabix> bonjour | ||
| 2017-05-18 09:51 <fabix> actuellement, notre système de facturation est basé sur openerp 6.0 ; on va étudier le remplacement de ce dernier par qqch de plus récent | ||
| 2017-05-18 09:52 <fabix> bcp de traitements sont effectués via des pl/sql | ||
| 2017-05-18 09:54 <fabix> peut-on continuer à utiliser de telles procédures avec tryton ? | ||
| 2017-05-18 09:54 <fabix> ou faut-il recoder les traitement en pur python ? | ||
| 2017-05-18 10:02 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | ||
| 2017-05-18 10:02 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | ||
| 2017-05-18 10:05 <cedk> Évidement maintenir du code pl/sql dans la DB est assez fastidieux | ||
| 2017-05-18 10:06 <fabix> notre facturation brasse des quantités énormes de données | ||
| 2017-05-18 10:06 <fabix> y a pas mal de jointures et de très nombreuses lignes | ||
| 2017-05-18 10:07 <fabix> c'est un traitement batch ; on fait pas client par client | ||
| 2017-05-18 10:07 <cedk> fabix: OK mais je ne vois pas très bien le sense de la question | ||
| 2017-05-18 10:08 <cedk> est-ce une demande d'autorisation? | ||
| 2017-05-18 10:08 <fabix> est-ce qu'on peut continuer à utiliser des pl/sql ou c'est pas possible ? | ||
| 2017-05-18 10:08 <fabix> la procédure génère des tuples | ||
| 2017-05-18 10:09 <fabix> et ça met à jour des compteurs et autres données | ||
| 2017-05-18 10:09 <fabix> je ne sais pas si c'est vraiment propre un tel mode de fonctionnement | ||
| 2017-05-18 10:10 <cedk> fabix: il n'y a que les personnes qui ont écrit ce code qui puisse répondre | ||
| 2017-05-18 10:10 <fabix> ils l'ont écrit pour openerp | ||
| 2017-05-18 10:10 <cedk> fabix: "propre"? | ||
| 2017-05-18 10:11 <fabix> insérer/modifier des données directement dans pg, sans passer par l'orm | ||
| 2017-05-18 10:13 <fabix> par 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, | ||
| 2017-05-18 10:15 <cedk> fabix: c'est sûr que ça peut poser des problèmes si c'est mal fait | ||
| 2017-05-18 10:15 <fabix> c'est pour savoir si on peut éventuellement transposer ce qui a été fait vers tryton ou s'il faut tout reprendre from scratch | ||
| 2017-05-18 10:17 <fabix> on pourrait aussi continuer sur Odoo mais j'aime pas bcp ce que c'est devenu | ||
| 2017-05-18 10:18 <cedk> fabix: j'ai pas de réponse magique :-( | ||
| 2017-05-18 10:19 <fabix> est-ce possible au moins d'exécuter des procédures pl/sql ou est-ce que l'usage de python-sql l'interdit ? | ||
| 2017-05-18 10:23 -!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr | ||
| 2017-05-18 10:26 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | ||
| 2017-05-18 11:45 <sisalp> fabix: python-sql ne bloque pas des fonctions postgresql. | ||
| 2017-05-18 11:45 <sisalp> fabix: Si vous avez fait ce code vous mêmes, essayer de la transposer au nouveau modèle de données | ||
| 2017-05-18 11:47 <sisalp> fabix: 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. | ||
| 2017-05-18 11:48 <fabix> on a fait appel à un presta qui avait codé notre précédent système de facturation avec les outils oracle | ||
| 2017-05-18 11:49 <fabix> ils ont gardé la même logique qd ils ont refait le système sous openerp | ||
| 2017-05-18 11:50 <sisalp> fabix: Il y a fort à parier alors qu'une reconsidération globale sera bénéfique. Au pire, sans effet. | ||
| 2017-05-18 15:53 -!- winter_(4c46eb94@gateway/web/freenode/ip.76.70.235.148) has joined #tryton-fr | ||
| 2017-05-18 15:56 -!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr | ||
| 2017-05-18 15:56 -!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr | ||
| 2017-05-18 16:10 <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 tryton | ||
| 2017-05-18 16:15 <cedk> winter_: il faut écrire un script soit avec proteus soit via wizard | ||
| 2017-05-18 16:20 <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 produit | ||
| 2017-05-18 16:21 <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? | ||
| 2017-05-18 16:21 -!- thaneor(~ldlc6@179.26.110.118) has joined #tryton-fr | ||
| 2017-05-18 16:22 <cedk> winter_: tous les produits sont des variantes d'un modèle | ||
| 2017-05-18 16:25 <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) | ||
| 2017-05-18 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? | ||
| 2017-05-18 16:25 <winter_> sans creer des produits permanents | ||
| 2017-05-18 16:27 <winter_> je me demandais s'il existait deja une solution ou un modele elegant pour cela | ||
| 2017-05-18 16:31 <cedk> winter_: je comprends pas. Quoi qu'il soit créer ça doit rester dans la DB pour l'historique | ||
| 2017-05-18 16:31 <cedk> winter_: donc je ne vois pas pourquoi ne pas créer des variantes | ||
| 2017-05-18 16:34 <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 rapidement | ||
| 2017-05-18 16:34 <winter_> peut-etre n'y a-t-il pas d'autre facon | ||
| 2017-05-18 16:35 <cedk> winter_: ne pas stocker cette information | ||
| 2017-05-18 16:37 <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 suite | ||
| 2017-05-18 16:39 <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 donnees | ||
| 2017-05-18 16:40 <cedk> winter_: donc il n'y a pas de probleme | ||
| 2017-05-18 16:40 <cedk> winter_: ça dépendra de la quantité et de la machine | ||
| 2017-05-18 16:41 <cedk> winter_: 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 stock | ||
| 2017-05-18 16:41 <winter_> la machine est excellente mais il s'agit veritablement de millions de variantes. | ||
| 2017-05-18 16:42 <cedk> si tout est crée pour chaque "ordre", il n'y a rien à plannifier ni a anticiper | ||
| 2017-05-18 16: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? | ||
| 2017-05-18 16:42 <cedk> winter_: je ne met pas en doute la machine, juste que c'est une question de capacité | ||
| 2017-05-18 16:42 <cedk> winter_: standard != spécifique | ||
| 2017-05-18 16:43 <cedk> pour moi, ce n'est pas de la production standardisé puisque tout est different à chaque ordre | ||
| 2017-05-18 16:44 <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 couleur | ||
| 2017-05-18 16:50 <winter_> l'ideal serait de stocker l'information dans la commande unique elle-meme sans creer de variantes "officielles" | ||
| 2017-05-18 16:51 <cedk> winter_: ça changerai quoi? | ||
| 2017-05-18 16:52 <winter_> au lieu d'avoir des millions d'objects "variantes" il n'y aurait que 2 champs strings par produit et par composante, par commande | ||
| 2017-05-18 16:54 <cedk> winter_: je vois pas vraiment de différence | ||
| 2017-05-18 16:54 <cedk> winter_: en plus si c'est juste sur la vente, c'est que ça sert pas à grand chose | ||
| 2017-05-18 16:55 <winter_> je me disais que je pourrais generer le BOM et les achats en python | ||
| 2017-05-18 16:56 <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 massive | ||
| 2017-05-18 16:56 <winter_> ce genre de probleme | ||
| 2017-05-18 16:57 <cedk> winter_: je vois pas où est le problème | ||
| 2017-05-18 16:57 <cedk> winter_: surtout que c'est le même pour la vente | ||
| 2017-05-18 16:58 <winter_> peut-etre. je ne suis pas tres familier avec la structure de donnees tryton, la difference est peut-etre minime... | ||
| 2017-05-18 16:58 <cedk> winter_: ça n'a rien avoir avec Tryton | ||
| 2017-05-18 17:00 <winter_> seulement s'il est vrai qu'une variante et toute sa description occupe le meme espace qu'un champ string, non? | ||
| 2017-05-18 17:02 <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) | ||
| 2017-05-18 17:03 <winter_> il y aurait 100 personnes accedant a tryton simultanement... | ||
| 2017-05-18 17:21 -!- cedk(~ced@gentoo/developer/cedk) has joined #tryton-fr | ||
| 2017-05-18 18:22 -!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr | ||
| 2017-05-18 18:25 -!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr | ||
| 2017-05-18 18:36 -!- nicoe(~nicoe@host-85-201-184-151.dynamic.voo.be) has joined #tryton-fr | ||
| 2017-05-18 21:14 -!- thaneor1(~ldlc6@179.26.16.43) has joined #tryton-fr | ||
| 2017-05-18 22:01 -!- semarie(~semarie@unaffiliated/semarie) has joined #tryton-fr |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!