Ребята, не изобретайте велосипед. Структура, в которой нормально отражаются подобные операции, была разработана еще за два тысячелетия до возникновения реляционной теории. И называется она "бухгалтерский учет". В нем есть такой принцип "двойной записи". Это означает, что любое движение ресурсов должно отражаться сразу на двух счетах (на двух регистрах учета) - на источнике и на приемнике.
Для учета подобных операций должен существовать регистр (бухгалтерский счет) взаиморасчетов, на котором отслеживается дебиторская/кредиторская задолженность всех контрагентов. На счете учета товаров учитывается движение товаров , а на счете взаиморасчетов - обязательств и задолженности . Есть еще счета учета денежных средств (50 - в кассе, 51 - в банке), которые корреспондируются со счетами взаиморасчетов. При такой структуре возможно:
- заводить отгрузку с множеством частичных оплат
- заводить оплату с множеством частичных отгрузок
- заводить множество отгрузок с множеством оплат (с переходящими хвостами по задолженности)

Бухучет в изначальном варианте возник во времена Архимеда (а есть сведения, что еще раньше - найдены записи, в которых велся учет расходов при строительстве Египедских пирамид). А вот метод двойной записи был изобретен, действительно, позже. И это было изобретение не просто века, а тысячелетия! Не до конца понимая ее значение, можно махать на нее рукой и пытаться вернуться к методу одинарной записи. Забывая, что именно метод двойной записи в совокупности с собственным набором аналитических признаков на каждой стороне проводки[/b позволял зафиксировать любые операции, даже те, о возможности появления которых заранее не было известно. Эта структура наиболее систематизирована и наиболее универсальна. В том примере, который тут выше приводился, в частности, очень дальновидно учтена возможность оплаты одной поставки несколькими способами и несколькими частичными оплатами. Но противоположная возможность (одна оплата по нескольким поставкам) не менее успешно забыта. Эта оплошность (и многие другие) вылезут наружу в тех редких исключительных ситуациях, про которые вам забыл рассказать заказчик. И первая же подобная ситуация поставит приложение и ее пользователей в тупик. А после того, как ошибка будет осознана и переварена вам придется пересматривать всю структуру таблиц. Я же вас не пугаю, а пытаюсь предупредить о тех подводных камнях, которые пока над водой не видны.
Правда говорят, что на чужих ошибках никто учиться никогда не будет. Он сначала должен наделать собственных и по их результатам уже сделать опять же собственные выводы...