The current on-hand is only relevant at the time of the calculation and those numbers are 100% fixed at the time of the calculation. You also have to have a current snapshot of the InvoiceDetails and OrderHistory. With those 3 fixed elements, then you can calculate backwards in time to any date and get those inventory levels.

Yes, I agree there will be some level of uncertainty, but it is not going to be that significant. IMO, this is what report disclaimers are for. If the client wants this information, give it to them and put a disclaimer with all the caveats on the report.

FWIW, this is why I have a function in my app to create a set of tables at the end of each fiscal year of what their inventory was. This is done for legal [tax], reporting and convenience purposes.

BTW, the terms app developer, programmer and anal retentive are redundant. < bg >

>Yes but you have to agree that it is never 100% accurate, thru the day qtys change, you have to agree with that.
>
>and my "personal" programming ethics are if it's not accurate I will not give it to the end-user, I will tell them "If you want inaccurate guesses go to someone else" and show them a timeline on paper and explain it is impossible because even if you track the time whatever time you lookup is just a guess from the (customer) inquiring party.
>
>I am just a stickler for being 100% accurate, you can ignore this and never reply if this didn't budge anyone’s thoughts towards being accurate
>
>
>I guess I am just anal retentive, and no a reply with confirmation of this fact is necessary