Несколько плательщиков: согласованные пределы и непокрытый остаток

Начните с подтверждённых оснований распределения

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

Эти условия должны быть уже согласованы уполномоченными сторонами. Запись организации в CRM, адрес бухгалтера или участие в общей группе компаний не создают обязательства оплатить чужую часть. Материал описывает управленческий процесс, а не устанавливает действительность соглашений или право взыскания.

Иерархия B2B-клиента помогает сохранить правильную площадку и расчётную сторону заказа. Здесь задача другая: одна допустимая к начислению сумма распределяется между несколькими подтверждёнными сторонами. Если модель допускает только одного плательщика в заголовке, два значения в этом поле не заменят распределение строк.

Разделите готовность, распределение и оплату

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

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

Не используйте себестоимость вместо распределяемой суммы, если условия относятся к цене услуги. Внутренние расходы, предъявляемая цена и согласованный предел финансирования могут различаться. Название «доля клиента» должно сопровождаться указанием базы расчёта.

Выберите порядок использования пределов

Приоритетный порядок сначала использует разрешённый остаток первой стороны, затем второй. Процентное распределение делит сумму между несколькими сторонами одновременно. Можно сочетать правила, но их последовательность и поведение при достижении предела нужно определить заранее.

Microsoft описывает для проектных контрактов несколько funding sources, приоритеты, проценты, limits и отдельное размещение нераспределённых сумм. Это документация Dynamics 365 Finance/Project Operations для manufacturing-based scenarios. Её нельзя переносить на Project Operations Core или любую другую конфигурацию. Microsoft: Project contracts.

Для каждой новой строки сохраняйте результат применения правила. Сотрудник должен объяснить, почему именно эта сторона получила остаток. Если подходящее правило отсутствует, назначьте разбор, а не выбирайте плательщика по последнему использованному документу.

Учебный пример: три стороны и две суммы

Все организации, условия и суммы вымышлены. Рассматривается одна валюта, без налогов и комиссий. Допустимые к начислению суммы распределяются последовательно: сначала A в пределах 5 000, затем B в пределах 4 000, затем C в пределах 1 000. Пределы относятся ко всей этой договорённости и не возобновляются после оплаты.

Первая сумма равна 4 000. Она полностью относится к A. После фиксации распределения свободны A — 1 000, B — 4 000, C — 1 000. Уже занятая часть A сохраняется независимо от того, успел ли сотрудник сформировать соответствующий документ.

Следующая сумма равна 6 000. Расчёт использует оставшиеся 1 000 у A, затем 4 000 у B и последние 1 000 у C. Проверка строки: 1 000 + 4 000 + 1 000 = 6 000.

За обе строки получается 10 000: A — 5 000, B — 4 000, C — 1 000. Сумма исходных начислений и сумма распределённых частей совпадают. В отчёте нельзя сложить их как независимые факты и получить 20 000.

Теперь отдельно рассмотрим вариант, где C вообще не согласован. Первые две стороны покрывают только 9 000 общей суммы. Последняя 1 000 остаётся непокрытым исключением с ответственным за решение. Она не становится автоматически долгом B, площадки обслуживания или сотрудника, подготовившего заказ.

Почему поступившая оплата не освобождает предел

Допустим, A полностью оплатил свои 5 000. Его открытая сумма к погашению уменьшилась, но по условиям примера общий предел участия уже использован. Новая строка на 300 не получает ещё 300 от A только потому, что старый счёт закрыт.

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

В Microsoft funding limit ограничивает выставляемую сумму; Committed amount и Spent amount отражают разные стадии её использования. Эти поля не следует читать как «оплачено» и «не оплачено». Microsoft: project funding limits.

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

Сохраняйте исходную строку и её части

У каждой распределённой части храните ссылку на исходное начисление, плательщика, сумму, валюту и применённое правило. Дополнительно нужны предел, занятая до операции сумма, использованный остаток и время фиксации. Это позволяет повторить расчёт без устного объяснения автора.

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

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

Изменения требуют адресной проверки

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

Изменение предела либо исключение плательщика требует списка затронутых ещё открытых сумм. Ранее предъявленные части не следует массово переносить по сегодняшнему правилу. Сохраните исходное распределение и разрешённую связанную корректировку.

Особенно внимательно проверяйте продуктовые ограничения. Microsoft отдельно указывает, что funding allocation rules не поддерживают описанный сценарий item requirements и не делят posting по этим правилам. Денежный пример статьи не обещает такой же механизм для любых складских строк. Microsoft: multiple funding sources and item requirements.

Приёмочный чек-лист

1. Каждая сторона имеет подтверждённую область и предел участия.
2. После первых 4 000 у A остаётся ровно 1 000.
3. Вторая строка 6 000 распределена как 1 000, 4 000 и 1 000.
4. Исходные суммы дают 10 000; части также дают 10 000 без удвоения.
5. Без согласованного C остаток 1 000 остаётся явным исключением.
6. Оплата A не возобновляет его исчерпанный предел.
7. Незавершённые распределения учитываются по принятой политике до новых обещаний.
8. Повтор и отмена документа не создают лишнюю долю или необоснованно свободный предел.
9. Изменения сохраняют исходные части и проверенное основание корректировки.

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

Частые вопросы

Можно добавить второго плательщика только в PDF?

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

Оплата освобождает максимальную долю стороны?

В учебной политике нет: предел относится к общей сумме участия. Возобновляемое ограничение требует другого явно согласованного правила.

Кто оплачивает превышение последнего предела?

Это нужно отдельно установить. Пока подтверждённого источника нет, превышение остаётся открытым вопросом, а не автоматически назначенным долгом.

Источники

• Microsoft: Project contracts.
• Microsoft: Project funding limits.
• Microsoft: Multiple funding sources and item requirements.

Проверено 9 октября 2026 года. Последовательность A/B/C и пределы являются учебными условиями.