Yes, but it is passing the capacity value not the shipping value
should be receiving + BACKLOG = FORECAST
KNIME_project - Volumetry.knwf (637.4 KB)
I added a BACKLOG negative calculation that I believe is what you are aiming at.
Basically if the BACKLOG adjustment is negative enough to bring the prior backlog below zero then it sets it at zero, otherwise if the BACKLOG adjustment is negative then it subtracts that amount from the prior, otherwise it calculates as normal.
I also dropped back in your original data as well (since I had something to proof back to) and adjusted it for each scenario.
Perfect, finished.
Now I’m just going to include one rule engine, because where it’s 0 it needs to give me the shipping value.
Thank you very much, I don’t know how to thank you. Anything I can help you with, let me know.
1 Like
We unfortunately had a problem, as in this print I sent you the value to be sent is greater than the capacity but the backlog appears as 0.
Do you know what it could be??
It is because it is occurring on the 1st day of the week. I believe that I built a zero into day one. Let me take a look.
Okay, I’ll wait.
Apparently it would be in the column expression, but I couldn’t identify it because it isn’t calculating the remainder.
KNIME_project - Volumetry.knwf (756.7 KB)
I added a test for when Shipping Capacity was greater than Receiving Capacity on the 1st day of the week.
Check that the Forecast on the 1st day of the week shows how you would expect it to in that instance as well. Right now it is just equal to Shipping Volume.
It still remains, I don’t know why.
Apparently it is not doing the calculation in the column expressions that create the BACKLOG column, for all terms.
It is calculating using a cumulative balance approach. It doesn’t currently do a hard reset on a Moving Aggregation when the BACKLOG hits zero. It is basically applying against the accumulated deficit. Let me see if I can do a hard reset running calc approach…
I think I understand, but I don’t know if I can explain it to you.
But I’ll try, We perform the calculation using Shipping volume - Receiving capacity Correct?
And if you have a backlog, add it and then subtract it again. The error is precisely in this calculation, if you analyze the case in the print below, the values match. However, on 10-13-2023 I have a low volume compared to the capacity and it does not generate a backlog, the balance is positive. how he is taking this number and redoing the subtraction and calculating the negative.
I believe perhaps that the error is in the node that adds the backlog column, it should not be added in total, but according to each line.
good, exactly that. I wrote a long text but you managed to understand.
It requires a cumulative aggregation to work without moving to a pure code approach, but I built in a Moving Aggregator reset point whenever the BACKLOG column hits zero.
KNIME_project - Volumetry.knwf (810.4 KB)
Edit: Hold on. That failed your initial results test…
1 Like
Apparently the backlog problem has been resolved, now he needs to do the same sum again for the Forecast being the BACKLOG from the previous day + shippimint. Same thing you managed to do but will need to be done again.
Were you able to check this forecast issue?
I’m trying a solution here, but it only calculates for some.
I am going to have to think on this one. Since a week can have multiple points where the calculation should reset, the way I am building now would require a series of multiple Moving Aggregation tests (each dependent on the prior results) in order to define those Moving Aggregation break points. Then it would need another looped Moving Aggregation to actually apply the cumulative calculations. It would certainly be the least efficient workflow that I have ever devised. 
@takbb - Any ideas on a better approach to this. I have followed this path too long (on a bit of a sleep deficit) and I know there must be an easier approach to this…
1 Like
I’m sorry for the inconvenience, but I really appreciate your help so far. This action here is very important for the company, in any case I will continue, as soon as I have a solution, can you help me.
I really need your help.
1 Like
@ScottF @ArjenEX @rfeigel @mlauber71 Can you help me with this point?
@iCFO , I’ll certainly take a look tomorrow.
@Gabriel2020 I’m just about to head to bed myself, and I haven’t read the full detail yet, plus I’m going to need to look at the flows so far to get an idea where this is headed.
Generally once it feels like it’s got too complex for moving aggregations, and needs cumulative calcs, that’s a point I’d start looking at a code solution with Java snippet but I couldn’t say with certainty that this is what is required at the moment, and I need to be properly awake to digest it.
1 Like