> >>> 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

Hmmm...in theory a contract can origin from a sales opportunity, and it should 
have a clear status - draft, active, expired, cancelled. It should be possible 
to use an expired/cancelled contract as blueprint for a new one (contract was 
cancelled but customer comes back)

> >>> 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?

Not sure what the impact of the billing method is. Mostly those cntracts have 
an automatic, periodically billing of the services received in between - is 
that what you mean? Does tryton currently allow periodic billing? (Dont know)

> 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.

You managed in between :-)

One general remark on blueprints: Suggestion is to first describe the 
functional need resp. description, then technical design and discussion. What 
do you think?

Cheers/Ax 

Reply via email to