Have no fear @Gabriel2020. I am not bailing on you. I can definitely help you finish it either way via a KNIME only approach (even if quite inefficient) next time I am in front of the computer. You can always upgrade to a more efficient Python or Java Snippet for efficiency. Just wanted to see if I could jump you to a more efficient final solution quickly.
1 Like
Thank you very much guys, I just have to thank you for everything. We are in different time zones. Once again, I’m sorry for the inconvenience.
I’m waiting.
What time zone are you in @Gabriel2020 ?
I’m in the Brazilian time zone. Here it is 07:00 PM.
But just by giving you a summary Takbb, I have a demand that needs to be sent, and a receiving capacity.
So if my volume is greater than my capacity, a BACKLOG is generated, so I need to add the BACKLOG generated from the previous day + volume to be sent, and immediately after I subtract this new “demand” with my capacity and do so for the rest of the days.
Ok, thanks. I’m just reading through and looking at the workflows and hopefully it can tick over in my head while I’m sleeping! 
I’m in UK, so I’m an hour behind much of Europe, and I suspect that many of the regular from this region are already getting their beauty sleep. I’ll have a look again when I wake up.
1 Like
Not that I don’t want to be helpful, but at this point I think it would be counterproductive to have others jump in. @takbb and @iCFO seem to be well down the path to a solution. “Too many cooks spoil the broth.”
KNIME_project - Volumetry.knwf (1.8 MB)
See if this is proofing out for you. Still not happy with the efficiency of a cascading Moving Aggregation test, but this brute force approach should be easy to dial in so you are up and running soon.
1 Like
Good morning people, everything fine?
The BACKLOG column part was resolved in the last material you sent. The problem is in the calculation of the FORECAST column (CALCULATED).
I’ll send an example, with the printout.
On 2023-10-09 it has a Forecast of 13842 and the correct BACKLOG of 3842.
However, on 2023-10-10 it has 1462 Shipping, 10,000 Receiving Capacity, 0 BACKLOG. And here comes the error, the FORECAST column should be 5304 being (BACKLOG of the day 2023-09-09 + SHIPPING 2023-10-10) and so it will be carried out for the other days.
So after the 1st row, Forecast is always current row shipping + prior row backlog? Or are there conditions where you would it would require an alternate calculation approach?
It will always be this calculation, as we zero out the negatives and organize the BACKLOG column, we can place this premise that will solve it.
1 Like
Ok. I changed it to a multi row calc (current shipping + prior backlog) and added an additional step to ensure we zero out the BACKLOG. I also moved the Forecast column outside of the BACKLOG calc loop to simplify adjustments.
KNIME_project - Volumetry.knwf (1.6 MB)
2 Likes
CONGRATULATIONS, thank you very much.
That’s exactly what I needed, we can think of a way to optimize, but that’s exactly what I needed. Thank you again, if you have any way to give back just ask.
1 Like
Glad it is working for you! I always opt for the “pay it forward” method. If we all offer some guidance when we find ourselves in a position to help another in the forum, then the community will thrive so that users of every level continue to quickly grow and solve without limits!
I can directly attribute my KNIME skill and speed back to helping on the forum. (especially when I leave my comfort zone) My professional technical skillset has exploded. There is zero chance that I would be building and integrating custom AI models to boost client productivity without my heavy forum activity.
1 Like
@iCFO Good afternoon, how are you ?
Continuing this theme, I have 2 problems that I identified here, I wanted to understand with you how it could be achieved.
1° I have some days where my HUB does not have a receiving CAP. However, I have volume to send, which would be the shipping column.
But basically, if it doesn’t have a CAP, it needs to be added for the next day and if the next day doesn’t have it either, it adds and adds for the next day. I will forward both views.
KNIME_project3.knwf (36.7 KB)
KNIME_project - Volumetry.knwf (1.9 MB)
1 Like
he did it the other way around, he must add the shipping column from the previous day which does not have a receiving column.
In the Shipping column on 2023-10-10 it should be 15800
I’m trying to understand the logic you created to perform these calculations because I’ll need it later, but I couldn’t understand it correctly, I apologize
I think it’s already late for you today, can we talk tomorrow?
That 1407 shipping qty on 23-10-10 was present in your data. The changed number was the 1407 in Receiving capacity (which was null in your original data). I thought that you were asking me to use the next day’s shipping qty in the event there was a null or empty data present in Receiving Capacity. (And in the even if multiple null in a row, pull the next day’s shipping quantity from the last spot for all of the ones above)
What calculation approach is required to fill that 1407 spot at the top of Receiving capacity? Providing numbers as well as a description would be helpful.
Edit: I do think it needs to be moved inside the loop either way to avoid pulling from another group.
Yes, it needs to be in a loop to avoid getting it from another group.
I would like to learn how to do this.
But it needs to check if the capacity is empty it takes the value to be sent and adds it to the next day, if the next day is empty it also adds it to the next day.
Every day there must be shipping and CAP, if not, must be added for the next day.
I sent you the material above and I will send you the calculation that should be done.
Hi @iCFO and @Gabriel2020 ,
I’m a bit distant from this now at #50+ posts in, but since @ICFO was asking about any simplification, I thought I’d pop in with the java snippet. That is certainly one huge effort you put in here @iCFO 
Now, I know there are other subtleties here that I haven’t got my head round, so what I have below isn’t a total solution, but in terms of simplification, the java snippet is very good for simplifying cumulative processing.
This snippet calculates the backlog according to the rules I understood at about post #3
This is only applying the rules:
(1) current backlog = Shipping Volume - Receiving Capacity + previous backlog
(2) if current backlog <0, then set current backlog to zero.
I’m wondering if that could help simplify the remainder.
What are the other rules concerning start of week etc, and did it need to take into account ORIGIN and DESTINY? Anyway here it is…
Backlog Calc with java snippet.knwf (8.9 KB)
2 Likes