IRC logs of #tryton-fr for Tuesday, 2012-05-29

chat.freenode.net #tryton-fr log beginning Tue May 29 00:00:02 CEST 2012
-!- sampac(~spaccoud@def92-7-82-231-203-127.fbx.proxad.net) has left #tryton-fr07:50
-!- rom1(~romain@LPuteaux-156-14-101-69.w80-12.abo.wanadoo.fr) has left #tryton-fr10:31
rom1bonjour10:31
rom1je ne vois rien dans tryton pour gérer les personnes physiques, c'est normal?10:32
rom1je cherche mal ?10:32
bechamelrom1: salut10:33
nicoerom1: pourquoi ne pas utiliser un party comme les autres ?10:33
bechamelrom1: a prioiri, il faut utiliser partu (tiers en français)10:33
rom1oui c'est ce que je me dis10:33
rom1mais comment on stocke des infos propres à une personne physique10:34
rom1?10:34
rom1type date de naissance10:34
rom1n° de secu10:34
rom1j'enrichie la table party?10:34
bechamelrom1: oui10:34
rom1je fais un inherits de party?10:34
rom1mais 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é10:35
rom1c pas idéal comme modélisation10:35
bechamelrom1: oui, j'imagine que ça peut être très similaire au model employee10:36
bechamelemployee est défini  dans le module company10:36
nicoeje pense qu'employee est un inherits de party (et à priori c'est aussi ce que je ferais pour une personne physique)10:37
bechamelrom1: c'est le but du inherits: il crée une seconde table, qui est jointe automatiquement à la table "de base" quand on l'accède10:37
rom1oui c'est là dessus que j'étais partie10:38
rom1mais en fait comme j'ajoute également des "roles" sur mes parties10:39
rom1genre "client", "fournisseur de service", ...10:39
rom1j'utilise déjà les inherits pour ça et je trouve que ça colle bien10:39
rom1mais 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 peu10:40
bechamelrom1: 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 party10:41
bechamella table de relation serai un m2m de party vers party et nomerai chaque extrémité (client de, fournisseur de)10:41
bechameldu coup on peut modéliser le role qu'a un party par rapport à soit-même, mais aussi les relation des party entre eux10:42
bechamelpour les personne physique, ce serait parent-enfant, collègue, etc. Pour les morales ça peut aussi être filliale-maison mère, etc10:44
rom1ça répond à des cas, mais je ne sais pas si ça résoud tout10:46
rom1si du fait d'un rôle d'une personne morale, je dois stocker une information, cette information n'est pas liée à une autre party10:47
rom1donc le inherits me va bien10:47
rom1plutot que le many2Many10:48
rom1en fait j'ai plutôt l'impression qu'il faut avoir les deux10:51
bechamelrom1: c'est difficile à dire sans connaitre les role et la manière dont ils sont utilisés :)10:54
rom1les liens inherits pour enrichir les informations selon les métiers et le many2many pour les relations entre les entités10:55
rom1je 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)10:56
rom1donc à 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 bancaire10:57
rom1ce n'est pas ttes les parties qui ont ce numéro, mais seulement qui ont un certain rôle10:57
rom1donc là le inherits me va bien10:58
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)10:59
rom1bref, on s'éloigne un peu de la question de départ10:59
rom1:)10:59
rom1je ne suis pas sur exactement de la modélisation des personnes morales/personnes physiques11:00
rom1enrichissement de la table party, vs inherits11:00
bechamelrom1: a priori je dirais inherits11:03
rom1c le nombre de champ qui fait la différence?11:04
rom1et pourquoi pas un champ référence depuis le party?11:04
bechamelrom1: 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érent11:06
bechamelet il se fait qu'ils ont certains champs en commun et party sert de base11:07
rom1c juste dommage qu'il y ait des champs uniquement personne morale sur party (type n° de TVA) :)11:07
bechamelrom1: les indépendants peuvent avoir des numéro de tva, de plus on peu tjs le cacher dans la vue des personnes physiques11:09
nicoerom1: une personne physique peut avoir un numéro de TVA (architecte par exemple)11:09
rom1je suis pas sur à 100% mais je ne pense pas que ce soit possible11:10
rom1un indépendant est une personne morale11:10
rom1son métier est différent de la personne physique11:10
rom1après je ne parle pas d'affichage, mais plutôt du stockage en base, cela fait des champs inutiles en base11:11
jcavalloBonjour,13:59
jcavalloj'ai cette erreur (qui n'apparaissait pas avant) lors de la mise à jour d'un module :13:59
jcavallosqlite3.InterfaceError: Error binding parameter 2 - probably unsupported type.14:00
jcavalloCela est-il déjà arrivé à quelqu'un ?14:00
jcavallo(Pour information, la requête : INSERT INTO ir_model_field (model, name, field_description, ttype, relation, help, module) VALUES (?, ?, ?, ?, ?, ?, ?))14:02
jcavallo(les paramètres : (112, 'status', [('Active', 'Active'), ('Refused', 'Refused')], 'selection', '', '', u'insurance_contract'))14:02
bechameljcavallo: la valeur " [('Active', 'Active'), ..." est plus que douteuse14:04
jcavallobechamel : Il s'agit des valeurs possibles d'un champ sélection14:05
bechameljcavallo: surement un keyword manquant dans la définission du champ insurance_contract14:05
jcavallobechamel : Ce qui me surprend est que je suis certain que cela a déjà fonctionné14:05
jcavallobechamel : insurance_contract est le nom du module14:06
bechameljcavallo: en effet14:06
bechameljcavallo: c'est le champ statut donc14:07
jcavallobechamel : l'erreur est sur cette ligne trytond/trytond/backend/sqlite/database.py", line 30014:07
jcavallobechamel : c'est le nom du champ (status = field.Selection(...)14:09
bechameljcavallo: oui c'est au moment ou la colonne qui correspond au champ en question est insérée dans la table14:09
nicoejcavallo: tu passes une liste à une requête SQL c'est pas normal, non ?14:09
bechameljcavallo: quelle est la définision exacte de status ?14:10
jcavallonicoe : Ca me paraît surprenant également, mais il s'agit d'une requête générée automatiquement par l'update de la base14:10
jcavallobechamel :     status = fields.Selection('Status', OPTIONSTATUS)14:10
jcavalloOPTIONSTATUS = [14:11
jcavallo                    ('Active', 'Active'),14:11
jcavallo                    ('Refused', 'Refused')14:11
jcavallo                ]14:11
bechameljcavallo: essaye avec status = fields.Selection(OPTIONSTATUS, 'Status')14:12
jcavallo@all : je viens de voir ça, je suis désolé de vous avoir dérangé :(14:12
bechameljcavallo: pas de soucis14:12

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