И тут начинается гимморой с соблюдением нормативных требований.
Потому что пока есть только заказ, по нему может быть только предоплата.
Потом на основании заказа будет формироваться акт/накладная. Причем не обязательно на весь заказ. И не обязательно один акт/накладная.
Сопоставлением предоплаты или ее части, либо прямой оплатой по акту/накладной будете закрывать кредиторскую задолженность.
Ну а если клиент отказался от заказа или только его части по предусмотренным договором причинам, предоплату или ее часть нужно уметь возвращать. А акт/накладную при этом корректировать кредитовым авизо. Потому что нужен аудиторский след. Хотя бы, чтобы собственные сотрудники не воровали.
Потом выяснится, что у оплат есть график платежей, который должен соблюдаться клиентом. А у изделий - сроки их изготовления, неустойки при несоблюдении сроков и даже гарантийные обязательства. Причем гарантия может быть на разный срок, в зависимости от договора.
Почему пишу акт/накладная? Потому что в заказе может быть, например, услуга доставки, упаковки, погрузки, расширенной гарантии и т.п.

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

Serguei,

да потому что ему, прежде чем этим заниматься, нужно сначала изучить знатную пачку ПБУ и связанных с ними нормативных документов. Тогда он сможет уже оценить объем работ. А так просто видно, что ТС даже не представляет, как далеко его текущее видение проблемы, от реальных потребностей бизнеса, которому все хозяйственные операции нужно отражать не только в операционном, но и в бухгалтерском учете.

vmag,

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

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

vmag,

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

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