>Hi Sir,
>
>The purchasing manager wanted me to break it down by components. So when a customer orders the assembly then she can just run this application and it will give her what can be build at this point and how many components to order for the next build. With the TotalOnHand, it will tell how many in stock of each component; and the NetQty is the remaining stock after the assembly is built. QtyPer is the number of each component needed to build the assembly.
>
>Currently, I have a function called What-If. The purchasing manager wanted to go on the Sales Order level to add to this. This will ask for a parent part number and quantity of the assembly to be built. This will generate the Bill of Material of the particular assembly and it will show per component what we have in the warehouse. It will calculate if we are capable of building the specified quantity or we need to order more of the components that is showing negative NetQty. This is where the TotalOnHand and NetQty per component come into place.
>
>The purpose of this application is to predict/see at the current situation if the production is capable of building the specified quantity and it will also show how much per component we need to buy.

All clear, I've done that in a few environments (custom furniture, aluminum framing, electric motors, jewelry, restaurant). They look differently, but the principle is the same.

And the requirements you have are all OK except in where they want the info. It may well work the way they want it as long as you don't have

1) too many sales orders unresolved at the same time
2) too many assemblies with same base components on the same sales order

In the first case (1), each sales order behaves as if there are no other sales orders, i.e. it calculates only total stock vs quantities needed for itself, regardless of other SOs which may compete for the same components at the same time. This may be OK if you have just a few at a time. If this grows, trouble.

Example: Customer A orders qty of 10 of Widget #1, for which you have enough components for 12. Customer B orders 8 of these. The first S.O. shows you still have enough for 2 more, the second shows you got enough for 4 more - but if you'd want to satisfy both, you're actually 6 short. You may want to add a field in your stock, called "reserved" or something like that, which would keep the qty required for the pending S.Os, and subtract that from QuantityOnHand. Then when you run the 2nd S.O. it would show you only got enough for 2, so you're 6 short. The trouble with this is that it requires maintenance - you have to resolve the pending status of the S.O. sooner or later. If it's cancelled, decrease this Reserved qty (i.e. it'll show as OnHand now), or if it gets a manufacturing order, decrease this reserved qty AND qtyOnHand for what manufacturing actually used.

In the latter case (2), various assemblies in the same SO compete with each other for the same parts. You can circumvent this by not showing the totals required immediately after each assembly, but as a separate subreport, i.e. as a recap of base components in the end. There you show the totals per base component, and the competing quantities are shown as total.

Example: you have a S.O. for 3 of Widget A and 3 of Widget B. Both widgets require 10 of #33 screws. You have only 50 such screws. If you show quantities needed for Widget A, it will show you need 30, got 50, cool. So will it show that you need 30 for widget B, you got 50, cool again. But you really need 60, so you're 10 short. If you show them as a total in the end, you'll show you need 60 of #33 screws, got 50, we're 10 short.