The source for the first load is the second load. The source for the second load is the inline table. The first load is called a "preceding load". You can stack as many of these as you want, and it's a common way of getting around the restriction that a field must be created before you can refer to it. So you create the field in one load, and you refer to it in the preceding load. In my experience, this is significantly faster than trying to left join the same information after the table has already been built. Preceding loads don't seem to be well documented, but I assume they're used in examples in the reference manual, and they're certainly used in examples on the forum. I've also noticed the restriction that combining a preceding load with a crosstable load just doesn't work, so we can't say that a preceding load universally loads from the output of the load below it, even if that's the basic behavior. It's possible that's just a bug in the product, though.
In my case, I used a preceding load to refer to field "Cumulative" in the preceding load. I could have done it all in one load by repeating the rangesum(Amount,peek('Cumulative')) part of the expression a couple times, but I prefer to not write the same code in multiple places where I have a reasonable alternative. You can see how jykang was forced into repeating his NumSum(Amount,Peek('Sum_Amount')) since he only used a single load statement. It's not really a big deal either way for an expression this simple, particularly since you can visually stack one on top of the other to make it very clear that if one changes, so should the other. I do it both ways, whichever seems cleaner to me for the specific case.
Any reference I made to peek() was in reference to my or jykang's code. I was not referring to your code.
Looking at your code, your idea certainly seems sound, though I think I see a couple simple bugs. Testing it out now. Yeah, your code works fine with a few trivial modifications. When using peek(), records are numbered starting with 0, so you need to address that in some way, such as by looping from 0 to the number of rows - 1. You need 0.99 instead of 0.09. And you should drop ProductsTemp at some point. And of course it doesn't handle that borderline case of splitting the discount across the 40 amount, but you probably weren't trying to do so. As far as suggestions, I'd just suggest that you don't need a loop in this case, that there is a simpler solution.
I almost never use loops, or at least not explicit loops like that. I do use a few while loops, but I feel like those fit more cleanly into the load structure. I'm not saying that there's anything wrong with explicit loops when they're called for, just that there may often be a simpler alternative.
You might also try some performance testing if you find what seems to be an alternative to one of your loops. I can't remember performance testing it myself, but my guess is that the explicit loop is slower than some alternatives. On the other hand, I think I recall making the same prediction about while loops, and performance testing showing that I was wrong, that they are extremely fast. I like to think that I'm right more often than wrong with my performance predictions, but I'm wrong very, very often. Testing is always called for when performance is critical.
One reason I don't typically like loops is that for large amounts of data, they can overwhelm the logfile. In this case, though, we're not going to have to loop through many records before exiting the loop, and seeing the loop details in the log may actually be quite useful for debugging. So in this specific case, I'd consider that an advantage of your approach.
