A Contract is a document which represents the agreement between two (or more) parties. This agreements have different clauses that are represented as contract terms.
In order to represent a contract, we must know its related party, an internal code, a external reference, the agreement date and a list of clauses which will be a text and a sequence to order them.
The contract can be in one of the following states:
I need such a function.
May I suggest also
A contract is made from a contract template
A contract has some particular conditions
A contract can be modified while already Running
A contract can be suspended and reactivated.
A contract can be automatically renewed or in deadline alert for renewal.
I also thought about it, as you normally have some types of contracts, but this can be achieved by using a draft contract as template and duplicating it. Also it can be implemented as a separate module if you have more complex templating requirements.
IIUC particular conditions → some extra term lines.
Why not using a new contract? Which kinds of modifications do you need? For example, i don’t think we should allow terms modification while running.
I thinks this can be implemented by a third party module, as we don’t talk about start/end dates of contract in base modules. BTW, normally contractas are autorenewed automatically, so I don’t know if it makes much sense to include start/end date fields
start with a subset of what contract management is in a simplified design then add features as custom
start with universal contract management concepts in a standardized design and then add specific custom behaviors.
I favour the second because first one reminds me Odoo too much, but this is an open discussion and I will listen everybody and probably the right thing to do is in-between the two options.
On the different contracts I deal with (either because I’m vendor or customer) I see many concepts that Tryton would be good at.
Examples
in telephony, when I agree on new pricing it becomes effective but I keep my contract and options.
in my insurance, I can declare a new driver of my car, it is an amendment, not a new contract.
A service provider proposed to suspend the service during my holidays
when a customer complains, I can offer him to extend the duration of the contract for free as a compensation
If we choose option 1, then probably we will have several contract modules to cover different cases.
If we could find a generic, basic way to implement generic case, then many kinds of contract management could be built over it.
For me, an important design feature is that contract lines often need to refer to other lines.
For this, I think a good design will be that the line will be just link to template line which contain the text with a simple template language that render the other line paragraph number.
Yes. Indeed I think each template line should define a list of dict keys that it uses. And on the contract, we use the all list of keys to fill a Dict field. Of course some common field will be real fields like date, company etc.
The main addition is the line templates but adding a contract template is the natural next step.
I think it should. I do not think it is a good practice to write contract clause per contract. Normally, they should be verified by lawyers.
Yes I think we could automatically enumerate paragraph. And probably it will be good to use a tree structure (with some line being titles).
How do you see the interaction with sales? add a new type of product : ‘contract’?
how to materialize its delivery to the customer and therefore billing?
Amendments to current contracts are similar as to amendments to purchase/sales [contracts].
BTW: in any case, there needs to be means to create new lines as new clauses can be contracted in any amendment.