Payment plan after regular intervals should take MA deployment planning into account
V
Vanessa Rudolph
The automatic invoice planning after regular intervals (that's what you're talking about) certainly plans more for the monthly reductions of more extensive services than for the monthly reductions of services with a lower order amount.
See screenshot “Example 1"
But what is actually not taken into account is the planning of the workload. Currently, the algorithm only looks at the time periods and order amounts, but not how which employee is deployed and when.
Photo Viewer
View photos in a modal
Arne Semmler
Merged in a post:
Payment plan according to costs possible?
l
le Coutre, Luca
Is it possible to set the payment plan in such a way that it tries to cover the costs incurred per service through regular invoicing (and thus a suggestion for performance level)?
J
Jan Holländer
Arne Semmler Allow me to bring up the post here again. Somehow I didn't see the topic anymore last week, but I think it could also improve liquidity planning.
In this post by Luca, who asks a similar question (https://feedback.projo.berlin/feature-requests/p/zahlplan-nach-kosten-moglich), I had just thought about how it pays off and I have the following quick suggestion - perhaps as a starting point:
[Sum of shares of planned expenses]/[sum of expenses] = [Proportion of planned expenses in the period]
then
[Proportion of planned expenses in the period] * [Unbilled Contract Amount] = [Expected Invoice Amount]
Arne Semmler
Jan Holländer Hi Jan, yes, we've only touched on that with Ü100, but the point is still present to me - even though it is not the main aspect of revising liquidity planning, as it concerns the question of input data from the input side, but at this point it is already necessary to check whether (which is currently my observation) other aspects (such as consideration of “on demand” services) have a greater influence on the accuracy of Have a forecast - at least when viewed across the entire office
The effects of the aspect you have emphasized here are particularly great when a vast majority of an office's turnover takes place over a longer period of time in just a few contracts with very few parallel services.
J
Jan Holländer
Dear Arne Arne Semmler, from our point of view, it is about estimating on a project-by-project basis whether the data is plausible in order to then be able to make a meaningful forecast about the entire office.
In this context, it feels more plausible if the cost side basically coincides with the predicted/required revenue side (you can then also derive an expected increase in performance from this, which would also be beneficial in terms of controlling). And this “feeling”, when 100% data integrity cannot be represented even structurally, is absolutely important in order to be able to subjectively evaluate the resilience of the data. I agree with you, of course, that the front page must be correct. But even here, and I'm speaking for our office, we have, as you describe it, “few” projects that run over a long period of time, with highly varying team sizes. Even though a contract here should include many partial services, these are usually commissioned together with the main service. We therefore do not calculate with probabilities of occurrence, but pessimistically - only contracted and retrieved services are included in liquidity planning. Accordingly, I would like to continue to promote this feature because I am convinced that it is a useful option for us and also for many others that you should be able to choose from as a contract.
Isabel
le Coutre, Luca Thank you for your request. In order to be able to better classify your feature request, it would be great if you describe your problem a bit more specifically. How far would you like to set the payment plan so that the costs incurred per service are covered by invoicing? What exactly is the problem that you want to solve? Thank you very much
l
le Coutre, Luca
Isabel Currently, you can only distribute the order amount automatically linearly, i.e. simply divide the order amount by time period = payment plan. However, this is usually unrealistic and leads to a payment plan with unrealistic figures in the future. You could of course create the payment plan manually - but that contradicts my understanding of “automation.” So it would be great if you could “automate” the payment plan in a different way. One suggestion here would be billing according to costs incurred - the average costs then extrapolated into the future with the corresponding level of benefits which then theoretically covers these costs.
J
Jan Holländer
le Coutre, Luca and Isabel In our opinion, a payment plan that relates to deployment planning would make sense.
So something like this:
[Sum of shares of planned expenses]/[sum of expenses] = [Proportion of planned expenses in the period]
then
[Proportion of planned expenses in the period] * [Unbilled Contract Amount] = [Expected Invoice Amount]
J
Jan Holländer
le Coutre, Luca and Isabel I'll link another comparable point here - maybe you can also combine the two, because they are quite similar concerns:
P
Patric Eckstein
A payment plan based on deployment planning would be extremely important for us.
We are of the opinion that the data required for this has already been created in Projo. The red line in the graphic can be seen in the respective project controlling.
J
Jan Holländer
This function would be important both for creating payment plans and for liquidity planning.
In our opinion, another option is required to create payment plans:
• Payment plan based on deployment planning