>This question is more about how inventory is handled in actual practice - not about how to program it in a specific language.
>
>Items may be available in larger and smaller groups. To give an example, a shop may sell a kg. of a certain type of screws, but it may also sell individual screws. Of course, this is just an example. The shop may decide to sell screws only one package at a time - but there may still be a similar situation in the case of other products.
>
>How is this handled for the sale, and updating the inventory, in the computer system? I would imagine that there would have to be a special process where the user must register the "unpacking" of a package, converting, e.g., one kg. of screws into 150 individual screws - or whatever the average number determined for this kind of screw. Then, 1 unit (1 kg. in this case) of one item (the package) would have to be discounted from the inventory, while on the other hand, 150 units (individual screws) would have to be added to another inventory item.
>
>This is the general idea I have, but I have never seen it done in practice, and would be grateful for any advice on how this is usually managed.

I've encountered this problem in several places, and solution varied.

One was to know which items are sold from the package. They would be marked as such and the app would recalculate the inventory into packages. This is how it worked for a bar - the cognac would go by 0.03 or 0.05 liter glasses, but the inventory would state there should be four whole bottles and 0.35 in an open bottle.

Another one was to keep double quantities: the user could enter boxes/bags/bottles/bundles and the system would recalculate the number of pieces inside. They'd enter 5 bags and there would be 5 (bags) in the package quantity, and 125 (kg) in the quantity column. The reason for this was to track the total of the same product in different packages - so they'd always know how many kilos of it went out, no matter in what package.

The third model I had was the small inventory in a workshop - paint, lacquer, nails, nuts, bolts etc. These were actually inventoried about once a year or ad hoc; meanwhile they were allotted to each workorder as a percentage of total cost but not as quantities. This percentage was an empiric guesstimate, and I actually had to write some code to compare this guesstimate with the actual consumption after an ad hoc inventory, and enter the correction. Also, report on it.

In your case, looks like case 2 - according to that model, you'd store individual screws, but they would enter either the number of boxes sold or number of screws sold. You actually don't care how many boxes are there, you count screws. You may recalculate the number of boxes periodically, depending on your requirements. Or you may even complicate things and say box item #200021 contains 150 of screws item #200020, and box item #200035 contains 500 of them - so you can have a total of screw #200020 sold from/in either type of package. Which would then make the inventory report a slight nightmare, specially if you have the same screws as loose too.