Contributors mailing list archives
Re: Contract without analyticby
I agree with Pedro.
What is the problem with having Analytic Accounts implicit to Contracts?
AFAICS at worst you could ignore them. At best they can become useful in the future.
And from your description, you will use Account anyway.
So I miss the point.
Citando Pedro M. Baeza (Tecnativa) <firstname.lastname@example.org>:
Regards.I don't see the point on having other set of modules. If you don't want analytic, just don't use it as the analytic behind contracts is transparent. If you use analytic for another thing, just split your accounts and make the corresponding filters, but it's also not a problem.For me, -1 for having a duplicated functionality on OCA.
2017-07-07 18:53 GMT+02:00 Frederik Kramer <email@example.com>:Dear Alexis, interesting plan. I was recently reviewing the OCA contract code, because i had a similar expectation / requirement of the meaning of "contract". But if i got your proposal right and the code right your proposal is an initial requirement of the legal "contract" whereas the current implementation just "templates" the price / quantity metrics effectively replicating an Odoo enterprise feature ? We at initOS need contracts in both ways and even have an extended requirements with regard to the "legal" perspective. We need the "contract" to be of the either the type "frame contract" or "individual contract" containing agreements on "terms" which are in turn basically hierarchical text components and certain price / quantity conditions (similar to the existing implementation) negotiated between partners and than "individual contracts" that are derived from those "frame contracts" (while retaining their relation). These individual contracts may than have a link to "projects" to whom they belong and further detail the "legal terms" as well as the price / quantity metrics. So i would prefer strengthen the whole "contract" notion / understanding since i think this "legal terms" requirement you put in and we are also interested is a core part of "contracts" if you think for instance on supplier networks. But to be honest even SAP uses the term in various ways across different modules MM -> https://help.sap.com/saphelp_
erp60_sp/helpdata/en/03/SRM -> https://help.sap.com/saphelp_ 7fb65334e6b54ce100 00000a174cb4/frameset.htm srm701/helpdata/en/08/Real Estate Management -> https://help.sap.com/viewer/ aa2f4bf30740aa939bc2 934aff1ac6/frameset.htm? current_toc=/en/21/ 5cdd74ec5f40368d26b2b5e2e7a0 24/plain.htm&show_children= true 8283ab99b2f540c18afbe5cbb34501or if somebody is interested in getting the whole grasp of SAP's use of the "contract" term https://help.sap.com/viewer/ e3/7.57.14/en -US/ 6dd7895360b93d58e10000000a174c b4.html search?q=contractmanagement&language=en- US&state=PRODUCTION&format= standard,html,pdf,others so we might also differentiate by be agreeing that a "contract" is simply to fuzzy to stand for itself and rather speak of project contract (this is probably mostly what we have in mind) employment contract (in HR) supply contract service contract (i.e frame containing SLAs) What do you think Kind regards Frederik P.S.: At some point the OCA or Odoo S.A. or both should really consider building a kind of taxonomy on terms otherwise we will be ending up in a mess like SAP ;-) P.P.S.: Have a marvelous weekend out there Am Freitag, den 07.07.2017, 13:53 +0000 schrieb Alexis de Lattre: > Dear OCA friends, > > At Akretion, we are thinking about developping a small set of modules > to introduce a notion that could be called either : > - "contract" > - or "commercial agreement" > - or "blanket order" > > In the rest of this email, I'll call this notion a "contract". > > The minimum that we need for the "contract" object : > - name > - number / ref > - partner_id > - signature_date > - state > - One2many to account.invoice > - One2many to sale.order (if sale module is installed) > > When a contract is configured on a sale order, it is copied to the > generated customer invoice. > > We need it for several projects. It would replace the module > sale_covenant which is in this OCA PR of my collegue David Beal : htt > ps://github.com/OCA/sale- workflow/pull/432stock (at least for v8) > > In which OCA project would we host this ? OCA/contrat would be a good > candidate, but it would be very strange to have a new set of module > that propose a completely different approach than the current modules > available in that branch. So maybe we need a new repo ? > > Thanks in advance for your feedback, > -- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH An der Eisenbahn 1 21224 Rosengarten Phone: +49 4105 56156-12 Fax: +49 4105 56156-10 Mobil: +49 179 3901819 Email: frederik.kramer@initos.> > We also need it to fully support e-invoicing for the French > administration (Chorus portal https://chorus-pro.gouv.fr/), because > e-invoices for the French administration need the reference of the > public contract number. So it would replace the object > "public.market" introduced by the module l10n_fr_chorus_account > (pending PR : https://github.com/OCA/l10n- france/pull/103/files#diff-> c1d7816feebf1b3fed9608f9a4f3b6 1cR9) > > In Odoo, there is already a notion of contract, but a contract is an > analytic account, and we don't want that. Because we want to be able > to use these contracts without using analytic, or we want to use > analytic for something completely different. > > Do you know an OCA module that already implement this ? > > If not, we were thinking about developping a new set of modules to > implement it. For the naming, we hesitate between : > - contract_no_analytic (my own preference) > - blanket_order > > We would have a full set of modules : > - contract_no_analytic_base > - contract_no_analytic_sale > - contract_no_analytic_sale_ comWeb: www.initos.com Geschäftsführung: Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke Sitz der Gesellschaft: Rosengarten – Klecken Amtsgericht Tostedt, HRB 205226 Steuer-Nr: 15/200/53247 USt-IdNr.: DE815580155
Post to: mailto:firstname.lastname@example.org