[RFC] product_contract: Allow for the sales of contracts about contract

[pedrobaeza]

Well, being strict, it's called "Inheritance by delegation". Here is a good definition: https://www.odoo.com/es_ES/forum/ayuda-1/question/delegation-inheritance-in-odoo-v8-when-is-it-useful-84890

[pedrobaeza]

In the description, I see purchase in one side, and sale in other. What exactly do you want?

[lasley]

Basically I just want a way to sell a contract, sorry for the bad wording.

I need a customer to be able to purchase one product through sales processes that would then create a live contract based on the template assigned in the product. The first invoice will be generated by normal sales, and the subsequent ones via the contract invoice lines.

Example:

• Customer purchases Odoo instance
  • Customer is immediately billed Odoo startup fee rate (determined in product)
  • Subsequent billing is based on recurring invoice lines in contract

[pedrobaeza]

My idea of this is to have a new module that adds at product level a check "Create automatically a contract" (similar to the current one "Create automatically a task"), that makes visible a field to select a template contract (with the other module you have made the RFC), or directly an existing contract (we can add a feature to mark a contract as a template, invalidating in the invoice generator role - I prefer this way as we save several new models -).

When a sales order with this product is created, then the template contract is duplicated, the customer is assigned in the copy, and the next invoice date is set for the next period starting on the order date.

What do you think?

[lasley]

Sweet your plan pretty much aligns with what I was thinking too.

Regarding the marking of a contract as template, I added that functionality in #42 via changes outlined in #42 (comment). I debated as to whether or not to use the same model, but landed on a new one because it will allow for the integration of logic such as deltas for use as dates when filling in the actual contract.

[pedrobaeza]

OK, I see. Well, I like the idea of reusing code via inheritance, although there are physically 2 tables in the DB.

[lasley]

Yeah this is true, and technically there would be some data duplication between contract templates and the real contracts.

I feel that a contract template does not meet the definition of an analytic account though. They will never be billed or reported on in their form, but would contain a bunch of logic for doing so.

On a similar note, I plan to add some other logic into the templates that would be unrelated to an analytic account. An example of some of the logic I am thinking are things like the existing markers, but for the templates:

• Add the customer name into the analytic account name
• First contract invoice date is +X days from contract create date

I felt like that was all a decent reason to provide the isolation and allow the data dup.

[lasley]

Maybe a polymorphic inherits makes more sense? Still two tables, but no dup

[pedrobaeza]

OK, I think this approach is also good.

[pedrobaeza]

That doesn't serve, because you can modify certain things in the contract after assigning the template, and with delegated inheritance (that's the chosen name for this 😉), you will change the template, not the contract.

[lasley]

you will change the template, not the contract.

Ahh yeah good point, that could cause some major issues!

delegated inheritance

Good to know thanks. Weird that the given name conflicts with the all other languages' definition of delegate inheritance, which includes methods as part of the definition. Polymorphic is usually only properties, so you'd think that'd be the name! Oh well 😕

[lasley]

Closing to track in PR #49