El 28/10/13 16:56, Jordi Esteve ha escrit:
On 28/10/13 10:19, Axel Braun wrote:
I miss some seeparation between the contract (the main document where
you define the terms and condiftions of the contract) and a contract
signature of the contract with a party.
Not sure I understand what you mean....
I agree that it is convenient separate between:
* The contract (contract service or periodical service): Where you
define the terms and conditions.
And also the duration of the contract (one year, three years, etc.)
* The contract signature (agreement): Where you relate a periodical
service with a party and logs its history: starting/ending dates,
renewals, ...
Yes that is exactly what I mean.
I also miss the time management of the duration of the contract. For
example: when it is the contract signed, which duration has, and which
is the final date of the contract. I don't know if it's necessary to
allow to define autrenewal of contracts (maybe that should be
defined on
a separate module)
Definitely a contract should have a start date.
Maybe a workflow also? Draft, In progress, done, canceled
Question is if you use a fixed end date (e.g. with warning), or an
open end
date.
I think I would go for the first one - even if you extend a contract
it is
usually andled as a 'new' contract (different terms and conditions
may apply,
see Telecommunications).
Could be both cases:
If the conditions doesn't change, you can renewal the same contract
agreement.
If the conditions change, you create a new contract agreement.
Thanks for all the detailed information of all contract types, but IMHO
a tryton module for managing contracts should be simple, and all
contract type's must be implemented in custom modules. So a review must
be done to extract all the general information from all contract types.
I think each contract type could be a separate module
Yes, but if there is a common base, like the definition of contract
services and contract agreements, it could go in a common base module.
I think that a common base is a list of products and quantities that are
involved in the contract.
Should we add billing method on contract management? Like there is on
the sale process, and allow to add new invoicing method by overriding
modules. What do you think?
For MasterContract, that could be implemented in a tree structure,
where
all the child contracts has all the terms and conditions defined on
their parents. What do you think?
You mean that the child initially inherits the conditions, and they
may get
changed on the child level?
Yes, that what i meant.
Yes, this could be a good solution.
How can I get access to editing the wiki? I will like to provide some
details about hte models involved in the implementation and also link
the wiki page to this discusion.
--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk
