vmag,

я же выше описал обычные ситуации, которые такой упрощенной БД без отражения хозяйственных операций не решаются.
Неужели клиент не может оказаться от трех бракованных кепок из пяти, да еще и заявить, что остаток предоплаты за эти кепки должен примениться к футболками из другого заказа?
Но при этом общепринятый в таких случаях механизм отражения всех хозяйственных операций по расчетам с заказчиками в одной таблице эту проблему замечательно решает. Но усложняет разработку на порядок.

И где после этого оставшиеся три кепки, потраченные на них материалы и время?
При таком подходе Вас обворуют сразу, оформляя заказы только на половину количества и ложа половину денег себе в карман.

vmag,

про X5 не надо мне рассказывать. Эта корректировка будет отражена в БД, так же, как и код администратора, ее санкционировавшего.

Я не утверждаю, что все ситуации нельзя будет в итоге предусмотреть. Я утверждаю, что в итоге это все равно приведет к учету хозяйственных операций, а не только текущего состояния заказов и оплат.
И у меня есть все основания полагать, что ТС не отдает себе отчет в объеме работ, которые ему потребуется выполнить для того, чтобы результат его труда имел хоть какое-то практическое применение.
Так же я утверждаю, что прежде чем проектировать БД, желательно, пусть даже на бумажке и без UML, но прописать все автоматизируемые бизнес-процессы. Внимательно и вдумчиво.