Contributors mailing list archives

contributors@odoo-community.org

Re: Contract without analytic

by
Tecnativa. S. L., Pedro M. Baeza
- 12/07/2017 08:18:31
My vision is to split on v11 current contract in 2:

- contract, with the base object where you can depend on for sales, purchase, whatever agreements/contracts you develop.
- contract_recurring_invoicing, that adds the current check for adding recurring invoicing (and expand it also for suppliers). The rest of the modules can use a similar approach that marking a check shows in the UI the features for that part. If any of these features requires to carry analytics, you will already have it!

For v10, just ignore also the "recurring invoice" mark, but the rest it's the same.

The advantage of this approach is that you can have in the same object all the required things. For example, you pay a membership fee that gets you access to discount in several purchases. You fill one contract with recurring purchase invoicing (for the fee), and a purchase agreement with the pricelist or the method you select for representing the discounts.

Regards.

2017-07-12 10:08 GMT+02:00 Daniel Reis <dgreis@sapo.pt>:

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.

--
Regards
Daniel


Citando Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com>:

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.
 
Regards.
 
2017-07-07 18:53 GMT+02:00 Frederik Kramer <frederik.kramer@initos.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/7fb65334e6b54ce100 00000a174cb4/frameset.htm SRM -> https://help.sap.com/saphelp_srm701/helpdata/en/08/aa2f4bf30740aa939bc2 934aff1ac6/frameset.htm?current_toc=/en/21/5cdd74ec5f40368d26b2b5e2e7a0 24/plain.htm&show_children=true Real Estate Management -> https://help.sap.com/viewer/8283ab99b2f540c18afbe5cbb34501e3/7.57.14/en -US/6dd7895360b93d58e10000000a174cb4.html or if somebody is interested in getting the whole grasp of SAP's use of the "contract" term https://help.sap.com/viewer/search?q=contract management&language=en- US&state=PRODUCTION&format=sta
ndard,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/432
> > 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- > c1d7816feebf1b3fed9608f9a4f3b61cR9) > > 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_
stock (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.com Web:   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

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe


 

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe