Есть некий простой кейс: клиенты выполняют оплаты за некоторую услугу, деньги копятся, потом более крупными платёжками перечисляются поставщику услуги.

До сего дня всё было хорошо - были некие входящие документы "платежи клиентов", и некие исходящие - "платежные поручения поставщику".

Входящие документы проводились как кредит счёта поставщика, исходящие - как дебет, все проводки упорядочены по времени.
Всех устраивала простая оборотно сальдовая ведомость за нужный период. Баланс сходится и хорошо.

Но возникло новое требование - поставщики теперь хотят знать "какие именно входящие документы" (или даже их часть!) вошли в тот или иной "исходящий документ". А клиенты "какая часть их платежа в какую именно платёжку поставщика вошла".

Т.е. понадобилось как-то связывать входящие платежные поручения с исходящими. Причем заплатить клиент может 100 тыс, а поставщику мы сегодня перечислим из них 50 тыс, и завтра еще 50 тыс. И наоборот, может заплатить десяток клиентов, а мы это всё перечислим одной платёжкой поставщику.

Получается надо как-то теперь для каждого входящего документа хранить еще и неперечисленный остаток что-ли?
А формирование исходящей платёжки теперь - не просто "перечислил 50 тыс и провел это как дебет счета поставщика", а должен быть некий нетривиальный процесс поиска еще неперечисленных остатков по входящим документам и включение этих остатков в формируемое платежное поручение.

Лажу по всяким бухгалтерским форумам - что-то нигде не нахожу схему, в которой надо исходящие потоки как-то увязывать с входящими. Такое вообще существует в природе?

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

Есть ли стандартные шаблоны для такого учёта и на каком этапе формируется такая связь между входом и выходом?

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

Смущает только ожидаемые тормоза в момент формирования очередного платежного поручения.
Если делать что-то типа FIFO, то в этот момент надо как-то оперативно найти "самый старый платеж клиента, который покрыт не на полную сумму", не перелопачивая абсолютно все оплаты за весь период работы базы.

Мде, походу апетиты растут, на ходу еще одно требование материализовалось.

Платежные поручения поставщику могут быть "авансом", т.е. изначально без привязки к платежам клиентов.

Соответственно все последующие оплаты клиентов должны "втыкаться" в это платежное поручение :)
Т.е. схема с покрытиями еще и в обратную сторону работать должна. Но в случае с промежуточной таблицей-связкой вроде этот момент тоже реализуем.

Это нереально, оплат за день может десять тысяч быть (это фактические данные уже), они сливаются в одну-две платежки поставщику.