Companies have agreements with parties on which conditions apply to their comercial operations with the company. For example is common to have an agreement on which payment term use for customer invoices. This conditions can depend on a lot of criteria, for example:
The party country
The country where the goods are delivered
The warehouse from where the goods are picked.
So we need a flexible way to define this conditions and more important allow third party modules to add more criteria and fields on conditions.
Proposal
A new party.comercial_conditon model which will have a name and all the comercial conditions:
Account (For receivable and Payable)
Customer Tax Rule
Payment Term
Sale Price List (Only for sales)
Credit Limit Amount (Only for sales)
Note: Each module should add each on comercial condition.
A a new party.comercial_condition.rule model that will be a MatchMixin to specify the match rules with the conditions.
The match rule should have the following fields:
Sequence
Company
Party
Kind (Sale/Purchase)
Condition to be used.
As order is important in company and party fields, we should show first the records which have not null values for this fields, then the ones which have a null value for party and finally the ones that have both fields as null.
From the party form we should be able to edit its commercial conditions, and from the company form we should be able to edit the default conditions for the company (where party is null)
Discussion
How to limit comercial conditions only available for sale or purchase? We should add the kind also on the comercial condition and hide non applicable fields depending on the kind?
I do not see how your design will be more flexible than the current design which is per party.
With a rule system, it is always complicate to have exceptions and to be sure of which value will be used for a particular case.
Also your proposal consider that all those properties are linked together but I doubt about that. For example, the payment term is not linked at all with the tax rule.
But I think the issue is not clearly identified. Maybe what you try to express is that you would like to have a way to update one of those property on a sets of party (which match a criteria). And a second need would be to have a way to compute default values depending on the information on the party.
For example we allow to define different conditions for the same supplier depending on the type of the goods which are purchased. So with the rule system we can define it in the same structure only adding a new field on the rule conditions.
I don’t think they are linked together as for me all the fields on condition are optional. So if you leave them blank you can unlink them.
On an first phase I though about adding all the fields as direct fields of the rule, but I think this will prevent grouping some fields which may be Interesting For example:
Goup the payment_term, the payment_type and the bank_account used. I
Group the credit limit with the payment term used. With the proposal you can also define which combination of both conditions are available to negotiate with the customer.
Updating a set of parties it’s easy possible with the current API, only it is needed to define a wizard.
And yes, this commercial conditions will be only used as default values based on the information on the party as it’s done.
One important improvement is to define default values (on the company, on the warehouse, based on the goods type, etc.) and define only the especial conditions on the party form.
I do not see how this could work because those properties, we are talking, are used on the document header.[quote=“pokoli, post:5, topic:192”]
I don’t think they are linked together as for me all the fields on condition are optional. So if you leave them blank you can unlink them.
[/quote]
So this makes thing even more difficult to understand. I’m pretty sure the average user will not be able to know which condition will apply for a specific party.
I never understood the payment_type. For me, it is a non-feature.
I do not agree. This is two different things which must not be linked.
Then I do not think it is possible to have a clean and simple solution for this feature.
For me, it is customization as each company will have its specific work-flow etc.
But indeed, I have already thought that we should have a kind of mini-work-flow on the party to allow validation of some specific information like the accounting, the sale etc. And this mini-work-flow will prevent the usage of the party in some places.
I do not see what condition you are talking about. As I said what is on the party is used at header level.
By adding a field on the document header which indicates the type of goods than can be sold and then restricts the lines.
Got it.
But this is another feature.
I’m talking about defining the default payment term used for all parties that does not have any payment term defined. This can be defined, for example, at company level.