Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: OCA Contract Repository
by
MoaHub, Graeme Gellatly
Hi,
We have nearly completed an extensive contract project integrating contract/project/accounting/sale/purchase/schedules/field service. All in it is about 30k lines replacing 100k lines of prior custom code for a janitorial organisation.
Random assortment of Notes.
Supplier Contracts - used in order to communicate back to back service agreements for certain services on customer contracts. Suspensions, modifications etc. But in truth, we did that because we could.
Contract Name - maybe an onchange, but some concerns with computing. The case here is that the name is an internal reference/common name used widely in online and offline conversation.
Contract States - added, computed based on modifications.
Margins - added in style of sale_margin module.
Sale Commissions Management.
Point in time revenue - can view contract (or list of contracts) value based on state at given date in future or past (contract has auto pricing so value can differ, also modifications)
Portal Views - we completely rewrote in the style of sale order and added signatures.
Modifications - Underrated, undeveloped feature IMO. We added extensively to record approvals, signatures and manage line and contract state. Different types of modifications trigger different actions/activities/communications.
Contract Lines - distinction between regular recurring items (e.g. Window Cleaning) and As Required items (toilet paper, fridge clean out).
Grouping and defaults is kind of provided if you use contract templates.
I personally don't see the link between an agreement and contract. I never worked out why they are in the same repo. A contract IS an agreement, and while I accept that an agreement is not always a contract, in practice, in business it is.
When evaluating this project, we tried first with agreement, but didn't do as needed. With contract states, a draft state is not yet sent, pending is awaiting signature, open, suspended, rejected, terminated all self explanatory. Really all else we did was add terms text to contracts and it largely covered the agreement parts off that were needed.
Bits we need to tidy up, contract has a kind of all or nothing approach to line based vs contract based billing. In practice we find it is the lines that drive what is billed, start dates, stop dates and contracts that drive when it is billed. Also, there is no nice proration in the invoicing function. But it seems very accessible so we should have that written next week.
There is a lot of work we can extract and share, and lots of things I haven't added here.
On Sat, Feb 25, 2023 at 11:56 AM Nicolas Rodriguez Sande <notifications@odoo-community.org> wrote:
I don't know any cases of "supplier"contracts either... The logic for me states that a supplier contract is managed by the supplier. I don't see benefit in making recurring supplier invoices since supplier invoices are loaded in the system in other workflows. At least from what I saw, I never saw "supplier contracts" in any system.On Fri, Feb 24, 2023 at 2:02 PM Raphaël Reverdy <notifications@odoo-community.org> wrote:Hi,Does anyone have a real use case with a supplier contract ?I have the feeling supporting this use case adds a lot of complexity on the contract module.Good idea to refactor / split this contract module.Regards,Le jeu. 23 févr. 2023 à 01:53, Nicolas Rodriguez Sande <notifications@odoo-community.org> a écrit :Hello! Thanks for your response Denis. I Just go back from vacation so I think next week I will start working on contract module.> In fact, the state is managed on line level, see https://github.com/OCA/contract/blob/14.0/contract/models/contract_line.py#L94Okay so, if state is managed in line level, will it make sense to make a computed contract level state that is based on line state? Because I think that for the user, they will expect contract to have a state, even some lines have different states we can make some logic to compute a state based on all lines states. Something like:States: “active”, “canceled”, “closed” can be computed based on lines. “Active” can be the contract state when at least one line is active, “Canceled” when all lines are canceled and “closed” when all lines closed. If we have mixed situations like some lines canceled and some active, we can still show active.This will allow the user to easily filter contracts without having to enter each contract to see lines. Or maybe we have to make a contract lines view.Next week I will be with this project and open some PRs to see what people think, also make the view improvements that will make sure life easier.And yes, base_conteact was just an idea but the point is to have more smaller and maintainable modules that plug-in functionalities, that’s always the easiest way to have a user-specific implementation without having a lot of functionalities that won’t be user by all users. Will try to open the issue next week to discuss this and also review the link between agreements and contracts PR.Please if another people have more ideas/problems/suggestions to contract module, feel free to reply this thread.Regards and good week for all of you!El El mié, 15 de feb. de 2023 a la(s) 06:17, Roussel, Denis <notifications@odoo-community.org> escribió:> - Contract objects don’t have states. It appears to me that in some versions states existed but is a functionality that was dropped and some point. I strongly think that a module like this must have states.In fact, the state is managed on line level, see https://github.com/OCA/contract/blob/14.0/contract/models/contract_line.py#L94> I think the name of the contract should be computed, or at least use a sequence. I don’t see the point of the name to be manually edited. Having a computed one will help with search and filtering.Indeed, this can be improved.> - There is not grouping entity of contract objects. Meaning we don't have an easy way to group contracts by category or an hicherarchical structure. I think this is useful for usability and to set default parameters.Maybe adding a 'contract.category' model could be great (in another module ?). But, for the time being, this can be done through contract tags. See: https://github.com/OCA/contract/blob/14.0/contract/models/contract.py#L110> - There is not link between contracts and agreement modules. My common sense dict that a contract should be created from an agreement, meaning that an agreement is a legal contract and when approved and signed, it creates a contract record which defines invoicing schedule. If not, i really don't see any use for agreements if they are not linked. Maybe this can be solved with a new module.This is still tested in a draft PR: https://github.com/OCA/contract/pull/649 You can review it and make suggestions.> - I think all codebase should be refactored and maybe split the contract module to have one base_contract with basic functionality for simple cases and then other modules to plug-in more functionality.This module has indeed a big history, refactored on 12.0 version I think. Since, some improvements have been done (refactoring on recurrency computations by Pedro see: https://github.com/OCA/contract/pull/533/commits/cd086ddbb4a9b85ccfcac288e53fb93e716d9446)Indeed, I think it has now a very complex implementation that makes user understanding (and debugging) difficult.We could make an issue on the github repository to help gathering ideas and focus discussion there than on this mailing list. But I agree that we could split some logic in separate modules (with meaningful names - if we could avoid base_contract).I hope this answered your questions.Regards,On Fri, Feb 10, 2023 at 5:57 PM Nicolas Rodriguez Sande <notifications@odoo-community.org> wrote:Hello, I’m writing to know your opinion about the contract repository. I started to use the modules in the repository and noted that the module versions of contract module differ a lot between odoo versions.
I have to do some implementations regarding that modules so I’m going to start making PRs to that repo and try to improve the modules starting in version 14.0 and then port it to the others.I want to have your opinions on things you can tell me about what is missing in the modules and so I can organize my roadmap. Also, I don’t know if there are currently active PSC of the module, if not or you want me to join the team I will be interested, because I need to improve the modules and if that can help the development of the repo, count with me.From what I saw, I see the following issues to solve, please if you know another issues or want to make an opinion of changes you would like to see in the module please comment me here:- Contract objects don’t have states. It appears to me that in some versions states existed but is a functionality that was dropped and some point. I strongly think that a module like this must have states.- I think the name of the contract should be computed, or at least use a sequence. I don’t see the point of the name to be manually edited. Having a computed one will help with search and filtering.- There is not grouping entity of contract objects. Meaning we don't have an easy way to group contracts by category or an hicherarchical structure. I think this is useful for usability and to set default parameters.- There is not link between contracts and agreement modules. My common sense dict that a contract should be created from an agreement, meaning that an agreement is a legal contract and when approved and signed, it creates a contract record which defines invoicing schedule. If not, i really don't see any use for agreements if they are not linked. Maybe this can be solved with a new module.- Contract views are awful and need to be improved to favor user usability and comprehension of the module mechanics and uses. This is one of the first changes i want to introduce.- Contract reports and portal views need to be improved. Currently the contract report is not so much developed. Also could be a good idea to allow to see agreements from portal contracts.- I think all codebase should be refactored and maybe split the contract module to have one base_contract with basic functionality for simple cases and then other modules to plug-in more functionality.If you have more opinions and things you want to see in a roadmap, please tell me here and i can maybe add it to my next PRs. Also if you have opinions of how the module should work will be great for when we refactor it.Regards and i want for your thoughts._______________________________________________
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
--Raphaël ReverdyMobile +33 6 38 02 03 93Fixe +33 4 82 53 84 60_______________________________________________
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
Reference
-
OCA Contract Repository
byNimarosaDev, Nicolas Rodriguez Sande- 10/02/2023 17:51:11 - 0-
-
-
Re: OCA Contract Repository
byClosingAp Open Source Integrators Europe, LDA, Daniel Reis- 24/02/2023 21:32:47 - 0 -
-
-
-
