Monthly Raw Materials is Highly Inaccurate

Apparently the picture tag requires the curly braces...

Thank you for the work you have done to document all this.

What you are saying is that the line with "Raw materials used" should show 10760 (instead of 7413).
This is the number you computed.

The computation was checked many times in the past and I am quite sure it is OK.
The cost as shown on the page (&413), is also subtracted from the value of raw materials.
If this amount is lawer by 3B per month than the amount that should be subtracted, then the value of raw materials should increase in time and become absurdly high.
it does not.
please check the raw materials number. we could learn from it.
I will have someone look into it. it will take some time.

There are many factors you can not compute accurately.
There are time differences between the trade and the recording of the market price. I am not sure when it is done.

also that last price paid is not necessarily t

I believe the calculation works fine - or nearly so - for supplies that are no bought immediately. This problem seems to only occur for immediately bought products. With the crazy shortages, this becomes a lot more apparent.

Perhaps there is a max() or min() call that doesn't take into account the extra cost of an immediate order? Similar to the trade strategies page, where there is a hidden limit? I'm just guessing.

Also, the supplies never reflect the real cost. Here's the same corporation.

immediate purchases always carry an extra cost.

Of course, and that cost is reflected in the "Last Price Paid"

Last Price Paid is not the same as average Price Paid or the particular price paid for the resource used in the current month.

If you buy 5 amounts at 10
later you buy 5 amounts at 20
last price paid will state 20
but the price paid for 5+5 is not 20 per 1. Its on average 15 per 1.

Fair point, but in this situation they're always being bought with immediate orders, so the price is almost always the same.

This is not true.

There are many fluctuations all the time and the end price for the month does not reflect the price during trading.

the transactions are executed against whatever is matched against them.
many times there is no perfect fit and the trading process must make a fit.

this happens on the real market too but the spread in the real world is much smaller. Many orders here are at market price and can cause larger fluctuations.

You can check the transactions log. I did not do that for some time but I remember that when this was tested we had major surprises and it was hard to follow.

The price during trading is not recorded anywhere. it is in memory and used until one side of the queue runs out of steam.
then the price is stored. Later, another round of trading starts with that stored price, with new queues. this happens 6 or 7 times during each game month. The entire month run takes 40 to 80 min

There are no fluctuations with these goods because they don't exist. I'm talking about stuff like Long Range Radar Planes, where the supply is 400 and the demand is 30000 right now.
Immediate orders create "backorders" where the object doesn't exist now but the market is indebted to its creation. When I create an immediate order for a quality 120 product that is never has any stock, like LRRP or Stealth Bombers or anything like that, then it will always be backordered. So it will always have the same price: base_price * 120% qaulity * 200% immediate surcharge. That's how it is (though maybe the 200% is wrong, I can't remember exactly)