Hi, I was wondering if there are some ideas to update the list price of multiple subscriptions at once. For example, I will like to update the price of a subscription service of a running subscription to 20% more.
I have a lot of subscriptions, so I thought i can achieve it with a wizard, but I was wondering if this could not be something that tryton core will want to have.
I think it may be good to have a standard mechanism to define how price of long running subscription should evolve over time. Usually such evolution is well defined when the subscription contract is made. The design should be simple but easy to extend to support different constraints.
In Spain normally contract prices are updated based on a Price Increase Percentage which is published by the authorities. So when the percentage is published all the active contracts unit price are increased by this percentage.
@lukio which mechanism do you use on your country?
In Belgium, I think, it is only controlled by the authorities for house rental. It is based on an table which describe the maximum percentage increase allowed. The description is done by comparing two coefficients the one from the start of the contract and the one at the anniversary of the contract.
So for me, we must have a very flexible method which can use external data etc.
So probably we should add a new selection field on Subscription to indicate the Price Update Method and have a method on lines to update the unit price based on the mechanism.
Then adding a wizard to select the Price Update Method, which will search for all the active subscriptions that have this method and call the method to update the values. This Wizard can ask for aditional parameters and pass it them to the methods that do the computation.
Base module can implement a “Percentage” update method that asks for a percentage and increases the line’s unit_price by this percentage.
For me, it must be more complex than a selection. It should be a object a little bit like “payment term”.
I do not think it should be done with a wizard. The subscription when generating new lines should check if the price must be updated or not following the new object rules.
I do not think the user must fill any extra parameter. The subscription is a contract and the update of the price should be completely defined prior to the starting and can only be changed by amendment (going to draft).
What kind of information should have such method? It is clear that it should have a name, but what else? Should we have a type to indicate the kind of methods?
For example, following our use case we may have a One2Many table to indicate the % increase for each date. Something like:
Then on each subscription when the date is reached the unit price of the line is updated.
Also I’m not sure how we should update the supscription unit_price:
A type which define different kind of computation.
It is not clear if it is accumulated increase?
I think we must not modify existing fields but store the new prices per date of change.
+1
How would be that? I like how @pokoli describe the model proposed. You could know the percent of variation that should be apply.
I agree with @ced. We should have a way to know the historial of the prices of the subscription.
Actually, I never heard of such an indexed contract in my lifetime in B2C, whereas there are some in B2B. So we should be aware that in many cases no long-time, contract based price development can be expected; but often prices will be subject to market conditions.
So what about one of these more pragmatic approaches:
A fully automated solution, operating in the background, IMHO can cause too much of unexpected behaviour, because there are so many different cases out there.