J'utilise openerp version 4.2.x sur plusieurs activités (compta, domaine forestier, domaine médical, domaine para-médical, imprimerie), et je ne me suis pas heurté à un problème de 'modélisation'.
il y a surtout (mais c'est juste mon humble avis) une manière de fonctionner et il faut se plier à cette manière de fonctionner pour travailler comme il faut.
Par exemple, et c'est un point important qui a soulevé la réflexion : la permanence de l'info et les 'points de sauvegardes'. Par exemple j'ai une société à l'adresse X, elle change et va à l'adresse Y -> toutes les rééditions de factures se trouvent à l'adresse Y. Donc, il faut un 'point de sauvegarde' pour trouver les factures encore à la bonne adresse (x).
2 méthodes pour y arriver as is (non pas Aziz !) :
1 - attacher le pdf de la facture à l'objet openerp (soit manuellement, soit par script)
2 - Enregistrer la nouvelle adresse comme une adresse de contact supplémentaire, toutes les factures avec l'ancienne adresse restent valides car l'adresse existe déja.
Maintenant je ne suis pas un 'spécialiste' des erp, je travaille plus sur la 'modélisation des flux d'information' (c'est chié non ?), et donc je n'ai probablement pas été confronté aux problèmes de modélisation, mais dans toutes mes problématiques, j'ai toujours trouvé un moyen 'openrep' de travailler, même s'il faut faire d'autres objets ou d'autres modèles ou d'autres rapports.
Maintenant je trouve dommage de changer la version de license ->gplv3 qui va empécher un échange de code avec openerp en gplv2 (même si je comprends la problématique avec le soucis des applications web-services).
Openerp sortira bientôt en V5 et openObject arrive, n'est-ce pas peut-être une réponse à ce que vous ne trouviez pas ?
Ne pouvait-on penser qu'il existait un moyen de permettre cette 'mega-surcharge' en modifiant le code du trunk sans être obligé de forker (même si je dois admettre que fabien et son équipe _semblent_ être un peu distants avec les non-partenaires-payants (ce qui est leur entière liberté avouons le.)
[^] # Re: Si j'ai bien compris
Posté par hervé Couvelard . En réponse à la dépêche Tryton version 1.0.0. Évalué à 2.
il y a surtout (mais c'est juste mon humble avis) une manière de fonctionner et il faut se plier à cette manière de fonctionner pour travailler comme il faut.
Par exemple, et c'est un point important qui a soulevé la réflexion : la permanence de l'info et les 'points de sauvegardes'. Par exemple j'ai une société à l'adresse X, elle change et va à l'adresse Y -> toutes les rééditions de factures se trouvent à l'adresse Y. Donc, il faut un 'point de sauvegarde' pour trouver les factures encore à la bonne adresse (x).
2 méthodes pour y arriver as is (non pas Aziz !) :
1 - attacher le pdf de la facture à l'objet openerp (soit manuellement, soit par script)
2 - Enregistrer la nouvelle adresse comme une adresse de contact supplémentaire, toutes les factures avec l'ancienne adresse restent valides car l'adresse existe déja.
Maintenant je ne suis pas un 'spécialiste' des erp, je travaille plus sur la 'modélisation des flux d'information' (c'est chié non ?), et donc je n'ai probablement pas été confronté aux problèmes de modélisation, mais dans toutes mes problématiques, j'ai toujours trouvé un moyen 'openrep' de travailler, même s'il faut faire d'autres objets ou d'autres modèles ou d'autres rapports.
Maintenant je trouve dommage de changer la version de license ->gplv3 qui va empécher un échange de code avec openerp en gplv2 (même si je comprends la problématique avec le soucis des applications web-services).
Openerp sortira bientôt en V5 et openObject arrive, n'est-ce pas peut-être une réponse à ce que vous ne trouviez pas ?
Ne pouvait-on penser qu'il existait un moyen de permettre cette 'mega-surcharge' en modifiant le code du trunk sans être obligé de forker (même si je dois admettre que fabien et son équipe _semblent_ être un peu distants avec les non-partenaires-payants (ce qui est leur entière liberté avouons le.)