| chat.freenode.net #tryton-fr log beginning Tue May 29 00:00:02 CEST 2012 | ||
| 2012-05-29 07:50 -!- sampac(~spaccoud@def92-7-82-231-203-127.fbx.proxad.net) has left #tryton-fr | ||
| 2012-05-29 10:31 -!- rom1(~romain@LPuteaux-156-14-101-69.w80-12.abo.wanadoo.fr) has left #tryton-fr | ||
| 2012-05-29 10:31 <rom1> bonjour | ||
| 2012-05-29 10:32 <rom1> je ne vois rien dans tryton pour gérer les personnes physiques, c'est normal? | ||
| 2012-05-29 10:32 <rom1> je cherche mal ? | ||
| 2012-05-29 10:33 <bechamel> rom1: salut | ||
| 2012-05-29 10:33 <nicoe> rom1: pourquoi ne pas utiliser un party comme les autres ? | ||
| 2012-05-29 10:33 <bechamel> rom1: a prioiri, il faut utiliser partu (tiers en français) | ||
| 2012-05-29 10:33 <rom1> oui c'est ce que je me dis | ||
| 2012-05-29 10:34 <rom1> mais comment on stocke des infos propres à une personne physique | ||
| 2012-05-29 10:34 <rom1> ? | ||
| 2012-05-29 10:34 <rom1> type date de naissance | ||
| 2012-05-29 10:34 <rom1> n° de secu | ||
| 2012-05-29 10:34 <rom1> j'enrichie la table party? | ||
| 2012-05-29 10:34 <bechamel> rom1: oui | ||
| 2012-05-29 10:34 <rom1> je fais un inherits de party? | ||
| 2012-05-29 10:35 <rom1> mais si au final j'ai une dizaine de champs lié à la personne physique et 1 dizaine de champ lié à la personne morale, cela me fait une vingtaine de champ avec que la moitié de renseigné | ||
| 2012-05-29 10:35 <rom1> c pas idéal comme modélisation | ||
| 2012-05-29 10:36 <bechamel> rom1: oui, j'imagine que ça peut être très similaire au model employee | ||
| 2012-05-29 10:36 <bechamel> employee est défini dans le module company | ||
| 2012-05-29 10:37 <nicoe> je pense qu'employee est un inherits de party (et à priori c'est aussi ce que je ferais pour une personne physique) | ||
| 2012-05-29 10:37 <bechamel> rom1: c'est le but du inherits: il crée une seconde table, qui est jointe automatiquement à la table "de base" quand on l'accède | ||
| 2012-05-29 10:38 <rom1> oui c'est là dessus que j'étais partie | ||
| 2012-05-29 10:39 <rom1> mais en fait comme j'ajoute également des "roles" sur mes parties | ||
| 2012-05-29 10:39 <rom1> genre "client", "fournisseur de service", ... | ||
| 2012-05-29 10:39 <rom1> j'utilise déjà les inherits pour ça et je trouve que ça colle bien | ||
| 2012-05-29 10:40 <rom1> mais du coup d'avoir des inherits pour les roles et en plus deux inherits pour personne moral et personne physique, sachant qu'il est forcément l'un ou l'autre, ça me gène un peu | ||
| 2012-05-29 10:41 <bechamel> rom1: en fait on a tjs eu comme idée de modéliser ce genre de relation avec un table de relation, plutot que d'avoir un "etat" sur le party | ||
| 2012-05-29 10:41 <bechamel> la table de relation serai un m2m de party vers party et nomerai chaque extrémité (client de, fournisseur de) | ||
| 2012-05-29 10:42 <bechamel> du coup on peut modéliser le role qu'a un party par rapport à soit-même, mais aussi les relation des party entre eux | ||
| 2012-05-29 10:44 <bechamel> pour les personne physique, ce serait parent-enfant, collègue, etc. Pour les morales ça peut aussi être filliale-maison mère, etc | ||
| 2012-05-29 10:46 <rom1> ça répond à des cas, mais je ne sais pas si ça résoud tout | ||
| 2012-05-29 10:47 <rom1> si du fait d'un rôle d'une personne morale, je dois stocker une information, cette information n'est pas liée à une autre party | ||
| 2012-05-29 10:47 <rom1> donc le inherits me va bien | ||
| 2012-05-29 10:48 <rom1> plutot que le many2Many | ||
| 2012-05-29 10:51 <rom1> en fait j'ai plutôt l'impression qu'il faut avoir les deux | ||
| 2012-05-29 10:54 <bechamel> rom1: c'est difficile à dire sans connaitre les role et la manière dont ils sont utilisés :) | ||
| 2012-05-29 10:55 <rom1> les liens inherits pour enrichir les informations selon les métiers et le many2many pour les relations entre les entités | ||
| 2012-05-29 10:56 <rom1> je sais pas comment ça marche en belgique, mais en france pour faire des prelevements, tout organisme doit avoir un NNE (numéro national d'emetteur) | ||
| 2012-05-29 10:57 <rom1> donc à partir du moment où une party (personne morale) émet de bandes de prelevements, il faut pouvoir stocker ce NNE qui est transmis dans le flux bancaire | ||
| 2012-05-29 10:57 <rom1> ce n'est pas ttes les parties qui ont ce numéro, mais seulement qui ont un certain rôle | ||
| 2012-05-29 10:58 <rom1> donc là le inherits me va bien | ||
| 2012-05-29 10:59 <rom1> (même un Many2One vers le party serait suffisant mais j'ai l'impression que l'inherits n'est qu'un enrobage de ce many2One pour simplifier le codage par la suite) | ||
| 2012-05-29 10:59 <rom1> bref, on s'éloigne un peu de la question de départ | ||
| 2012-05-29 10:59 <rom1> :) | ||
| 2012-05-29 11:00 <rom1> je ne suis pas sur exactement de la modélisation des personnes morales/personnes physiques | ||
| 2012-05-29 11:00 <rom1> enrichissement de la table party, vs inherits | ||
| 2012-05-29 11:03 <bechamel> rom1: a priori je dirais inherits | ||
| 2012-05-29 11:04 <rom1> c le nombre de champ qui fait la différence? | ||
| 2012-05-29 11:04 <rom1> et pourquoi pas un champ référence depuis le party? | ||
| 2012-05-29 11:06 <bechamel> rom1: c'est plus une question d'utilisation que de nombrede champ, a priori on ne mixe pas les personne morales et physique, ce sont quasi deux modele différent | ||
| 2012-05-29 11:07 <bechamel> et il se fait qu'ils ont certains champs en commun et party sert de base | ||
| 2012-05-29 11:07 <rom1> c juste dommage qu'il y ait des champs uniquement personne morale sur party (type n° de TVA) :) | ||
| 2012-05-29 11:09 <bechamel> rom1: les indépendants peuvent avoir des numéro de tva, de plus on peu tjs le cacher dans la vue des personnes physiques | ||
| 2012-05-29 11:09 <nicoe> rom1: une personne physique peut avoir un numéro de TVA (architecte par exemple) | ||
| 2012-05-29 11:10 <rom1> je suis pas sur à 100% mais je ne pense pas que ce soit possible | ||
| 2012-05-29 11:10 <rom1> un indépendant est une personne morale | ||
| 2012-05-29 11:10 <rom1> son métier est différent de la personne physique | ||
| 2012-05-29 11:11 <rom1> après je ne parle pas d'affichage, mais plutôt du stockage en base, cela fait des champs inutiles en base | ||
| 2012-05-29 13:59 <jcavallo> Bonjour, | ||
| 2012-05-29 13:59 <jcavallo> j'ai cette erreur (qui n'apparaissait pas avant) lors de la mise à jour d'un module : | ||
| 2012-05-29 14:00 <jcavallo> sqlite3.InterfaceError: Error binding parameter 2 - probably unsupported type. | ||
| 2012-05-29 14:00 <jcavallo> Cela est-il déjà arrivé à quelqu'un ? | ||
| 2012-05-29 14:02 <jcavallo> (Pour information, la requête : INSERT INTO ir_model_field (model, name, field_description, ttype, relation, help, module) VALUES (?, ?, ?, ?, ?, ?, ?)) | ||
| 2012-05-29 14:02 <jcavallo> (les paramètres : (112, 'status', [('Active', 'Active'), ('Refused', 'Refused')], 'selection', '', '', u'insurance_contract')) | ||
| 2012-05-29 14:04 <bechamel> jcavallo: la valeur " [('Active', 'Active'), ..." est plus que douteuse | ||
| 2012-05-29 14:05 <jcavallo> bechamel : Il s'agit des valeurs possibles d'un champ sélection | ||
| 2012-05-29 14:05 <bechamel> jcavallo: surement un keyword manquant dans la définission du champ insurance_contract | ||
| 2012-05-29 14:05 <jcavallo> bechamel : Ce qui me surprend est que je suis certain que cela a déjà fonctionné | ||
| 2012-05-29 14:06 <jcavallo> bechamel : insurance_contract est le nom du module | ||
| 2012-05-29 14:06 <bechamel> jcavallo: en effet | ||
| 2012-05-29 14:07 <bechamel> jcavallo: c'est le champ statut donc | ||
| 2012-05-29 14:07 <jcavallo> bechamel : l'erreur est sur cette ligne trytond/trytond/backend/sqlite/database.py", line 300 | ||
| 2012-05-29 14:09 <jcavallo> bechamel : c'est le nom du champ (status = field.Selection(...) | ||
| 2012-05-29 14:09 <bechamel> jcavallo: oui c'est au moment ou la colonne qui correspond au champ en question est insérée dans la table | ||
| 2012-05-29 14:09 <nicoe> jcavallo: tu passes une liste à une requête SQL c'est pas normal, non ? | ||
| 2012-05-29 14:10 <bechamel> jcavallo: quelle est la définision exacte de status ? | ||
| 2012-05-29 14:10 <jcavallo> nicoe : Ca me paraît surprenant également, mais il s'agit d'une requête générée automatiquement par l'update de la base | ||
| 2012-05-29 14:10 <jcavallo> bechamel : status = fields.Selection('Status', OPTIONSTATUS) | ||
| 2012-05-29 14:11 <jcavallo> OPTIONSTATUS = [ | ||
| 2012-05-29 14:11 <jcavallo> ('Active', 'Active'), | ||
| 2012-05-29 14:11 <jcavallo> ('Refused', 'Refused') | ||
| 2012-05-29 14:11 <jcavallo> ] | ||
| 2012-05-29 14:12 <bechamel> jcavallo: essaye avec status = fields.Selection(OPTIONSTATUS, 'Status') | ||
| 2012-05-29 14:12 <jcavallo> @all : je viens de voir ça, je suis désolé de vous avoir dérangé :( | ||
| 2012-05-29 14:12 <bechamel> jcavallo: pas de soucis |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!