Закупки · бонусы поставщиков
Ретроспективный бонус поставщика: сколько рассчитано, признано и реально получено
Закупщик видит достигнутый порог и ожидает бонус, но поставщик может признать другую базу, а возврат изменит расчёт. Чтобы не принять предварительную сумму за деньги, нужно отдельно вести подходящие документы, расчёт, согласованное требование и его фактическое урегулирование.
Решение начинается с основания, а не с процента
Ретроспективный бонус выплачивается или засчитывается по условиям накопленного результата. Он не обязан уменьшать цену каждой исходной закупочной строки сразу. Руководителю нужно знать, какие документы дают основание для расчёта, какую сумму уже проверили и что ещё должен подтвердить поставщик.
Microsoft описывает соглашение о vendor rebate отдельно от создания, расчёта и утверждения требований. В новом механизме Rebate management также отдельно задаются база, период, стадия документа и включение кредитовых корректировок. Это показывает, почему одной записи «бонус 3%» недостаточно. Microsoft Learn: условия бонуса.
Юридические права, бухгалтерское отражение и налоговые последствия определяются подтверждёнными условиями и ответственными специалистами. Ни вычисленная сумма, ни название статуса не дают автоматического разрешения уменьшить платёж поставщику или исправить закрытый документ.
Сохраните пять раздельных состояний
Сначала идёт eligibility: какие строки действительно подходят по поставщику, SKU, организации, дате, единице и условиям. Затем расчётная сумма на конкретном срезе. Далее — проверенное и утверждённое внутри компании требование к поставщику.
Внешнее признание или полученный кредитовый документ — следующий самостоятельный факт. Последний этап — фактическое урегулирование: подтверждённый денежный перевод, согласованный зачёт или иной предусмотренный способ. Одну сумму нельзя одновременно посчитать полностью ожидаемой и уже полученной.
Документация Microsoft различает состояния rebate claims и обработку, результатом которой может стать vendor credit note. Поэтому техническое «обработано» не следует переводить в «деньги уже поступили», пока соответствующее событие не подтверждено. Microsoft Learn: жизненный цикл vendor rebates.
Учебные условия: один период и один порог
Все числа и договорённости вымышлены. За выбранный месяц компания получает 3% от всей подходящей базы закупок, если её итог не меньше 100 000. При базе ниже 100 000 бонус равен нулю. Налоги и доставка исключены, используется стоимость товара после обычных скидок, но до этого бонуса.
Базой служат подтверждённые закупочные счета. Связанные credit notes по возвратам уменьшают базу того же расчётного периода согласно принятым условиям. Простая заявка на возврат или физическая отправка поставщику пока не заменяет предусмотренный документ. Валюта одна, курсовых изменений нет.
Такие правила выбраны для примера. Другой договор может использовать полученное количество, оплаченные счета, иной период или другой порядок возвратов. Microsoft прямо выделяет эти настройки как отдельные условия расчёта; их нельзя угадывать по прошлой выплате.
Как возврат меняет предварительную сумму
Подходят два счёта: 60 000 и 45 000. База равна 105 000, предварительный бонус — 105 000 × 3% = 3150. Период ещё не закрыт, поэтому сумма остаётся расчётной: она не подтверждает окончательного требования и не является поступлением денег.
Далее принят связанный кредитовый документ на возврат 10 000, относящийся к той же базе. Она уменьшается до 95 000. Порог больше не выполнен, новый расчёт равен нулю. Изменение предварительной суммы — минус 3150.
Вычесть только 10 000 × 3% = 300 и оставить 2850 было бы ошибкой по нашим условиям: право расчёта всей суммы зависит от порога. При этом исходные счета не переписываются. В регистре сохраняются два подходящих документа, отдельная корректировка и новая версия результата.
Затем приходит ещё один подходящий счёт на 8000. База становится 95 000 + 8000 = 103 000, бонус — 3090. Переходы 3150 → 0 → 3090 объясняются изменением состава документов. Это не три независимых бонуса, которые можно сложить.
От расчёта к требованию и признанному кредиту
После завершения периода ответственный проверил реестр и утвердил требование на 3090. Оно передано поставщику с перечнем оснований и версией условий. Утверждение внутри компании не означает автоматического согласия другой стороны.
Поставщик подтвердил 3000 и оформил соответствующий credit note. Разница 3090 − 3000 = 90 остаётся спорной. По ней нужны причина, ответственный и срок разбора. Не считайте всю сумму 3090 признанной только потому, что получен документ почти на такую же величину.
До использования credit note подтверждённое денежное урегулирование равно нулю. Затем уполномоченный сотрудник оформил предусмотренный условиями зачёт 2000; его исполнение подтверждено. Остаток признанного кредита равен 1000.
Теперь исходное утверждённое требование раскрывается так: 3090 = 2000 фактически зачтено + 1000 признано, но ещё не использовано + 90 не признано поставщиком. Нельзя одновременно показать ожидаемые 3090, кредит 3000 и зачёт 2000 как три независимых экономических выгоды.
Поздний возврат не разрешает переписать закрытые документы
Предположим, позднее подтверждён ещё один документ на 2000. Ответственный установил, что по условиям он относится к прежнему периоду. Пересчитанная база — 101 000, сумма по формуле — 3030. Она на 60 меньше прежних 3090.
Это новый расчёт и основание предложить корректировку требования. Он не аннулирует автоматически уже оформленный кредит 3000 и подтверждённый зачёт 2000. Сохраните исходную версию, поздний документ и решение о разрешённом способе урегулирования.
Если уполномоченные стороны подтвердят уменьшение только ещё спорной части, предлагаемая структура станет 3030 = 2000 зачтено + 1000 признанного неиспользованного кредита + 30 оставшегося требования. Пока такого решения нет, действующее состояние документов и новая расчётная оценка показываются рядом, с открытым расхождением 60.
Если позднее изменение снова опустит базу ниже порога, последствия для уже признанного или использованного бонуса нужно разобрать по условиям отдельно. Не превращайте арифметику в самостоятельную команду вернуть деньги, списать кредит или изменить налоговый документ.
Какие данные нужны в реестре
Сохраните поставщика и получателя бонуса, период, версию соглашения, критерии SKU и стадии документов, базу до/после скидок, валюту и правила корректировок. Каждая включённая строка имеет устойчивый идентификатор и сумму участия. Исключённая строка сохраняет причину, чтобы другой сотрудник мог воспроизвести результат.
Для требования нужны номер версии, срез базы, рассчитанная и утверждённая суммы, дата отправки, ответ поставщика, кредитовые документы и события урегулирования. У частичного признания показывайте непокрытый остаток. Исправленный файл поставщика сначала сопоставляют с прежним, а не добавляют как второй кредит.
Отдельно определите, кто вправе менять eligibility и кто подтверждает settlement. Новая дата загрузки старого счёта не должна переносить его в другой бонусный период. Неполученные документы помечаются как неопределённость, а не заменяются нулём ради окончательного отчёта.
Приёмочный чек-лист
- База 105 000 раскрывается до двух подходящих счетов.
- Возвратный документ 10 000 меняет расчёт с 3150 до нуля.
- Новый счёт 8000 даёт 103 000 базы и 3090 расчётного бонуса.
- Внутреннее утверждение отделено от признанных поставщиком 3000.
- Частичный зачёт 2000 оставляет признанный кредит 1000 и спорные 90.
- Поздняя корректировка создаёт новую оценку 3030, сохраняя прежние документы.
- Повтор загрузки не дублирует базу, кредит или урегулирование.
- Итог не выдаётся за деньги до подтверждённого события расчётов.
В поставщиках, закупках и финансах SABSUS проверьте хранение оснований и связей. Поддержку отдельного rebate-регистра, формул и обработки credit notes подтвердите в конфигурации; готовый механизм здесь не предполагается.
Частые вопросы
Достигнутый порог означает, что бонус уже получен?
Нет. Нужны проверка периода, требование, признание и отдельное событие урегулирования.
Возврат всегда уменьшает бонус на свой процент?
Нет. При условном пороге он может изменить применимость всей суммы. Используйте подтверждённую функцию расчёта.
Можно исправить старый credit note после нового расчёта?
Не автоматически. Сохраните расхождение и применяйте согласованный разрешённый процесс корректировки.