This is good point. Basically the program is reflection of how I understand things should be done and it’s based on observation of many diverse businesses.
When I’ve implemented the original Qty to deliver and Qty to receive columns, I had no understanding of what I’m doing. Back then, Sales Orders and Purchase Orders were just document generators with no tracking of anything. So the old Qty to deliver and Qty to receive columns were just the first idea I had.
New Qty to deliver and Qty to receive columns are result of finally understanding how it should have been done in the first place.
Obviously, these new columns will need to settle in and stand test of time but so far, I haven’t noticed anything that would surprise me. This makes me confident that this is the correct solution and it won’t be different in 7 years.
I agree. But generally speaking, even badly designed accounting software looks fine with small amount of transactions.
Bad design becomes obvious once you have hundreds of transactions instead of just four. What if your balance does not come to zero? Where do you even start looking for the discrepancy?
This is why changes are most painful to businesses with lower transaction volume. It doesn’t seem like I’m solving any issues because there doesn’t appear to be any issue in the first place. But for businesses with larger transaction volume, Qty to deliver became meaningless figure because it was simply always inaccurate and figuring out why was not worth the effort. So the new columns are solving this issue by making it “worth the effort” because the effort is lower.
Anyway, I’ll keep those obsolete columns around for the time being. They do not cause any issues by being there.