AUT-0461· Фінанси
Перерахунок комісії продавця після повернення чи скасування продажу
Повернення, кредит-ноту або скасування продажу пов’язують із початковою комісією та перераховують її за затвердженим планом винагороди.
Чернетка · Оцінка потребує перевірки
01 / Проблема
Продаж уже нарахував комісію, але пізніше клієнту повернули частину суми або кредитували рахунок. Без зв’язку з первинною комісією компанія може повторно нарахувати винагороду, зменшити її не за тим правилом або безпідставно утримати суму з уже виплаченої зарплати.
02 / Результат
Кожна зміна продажу має перевірений зв’язок із первинною комісією, сумою перерахунку, правилом плану й затвердженим обліковим результатом.
03 / Процес
ТригерПісля нарахування комісії в обліку проведено повернення, часткове скасування продажу або кредит-ноту.
Отримати проведену подію повернення чи кредитування з ідентифікаторами клієнта, документа, рядка продажу, суми й дати.
Зіставити її з первинним замовленням, рахунком та рядками комісії; неповний або неоднозначний зв’язок передати на ручну звірку.
Визначити початковий план винагороди, правило нарахування, продавця, період і статус виплати на дату первинного продажу.
Перерахувати тільки частину комісії, на яку впливає проведена подія; часткове повернення не скасовує всю комісію автоматично.
Перевірити попередні коригування за унікальним ID події, щоб повторна доставка повідомлення не створила друге списання.
Показати джерельні документи, початкове нарахування, від’ємну або іншу коригувальну суму та правило розрахунку менеджеру й фінансисту.
Після затвердження передати коригування в систему комісій або розрахунку винагород і повторно прочитати збережений результат.
Якщо первинна комісія вже виплачена, створити окремий випадок для погодженого майбутнього розрахунку; не утримувати гроші із зарплати без перевіреної політики та правової підстави.
04 / Реалізація2 варіанти
Приклад · Подієве зіставлення та передача коригування
Система отримала кредит-ноту 200 USD, знайшла рядок продажу й продавця, застосувала правило чинного плану, створила коригування комісії та не повторила його після повторної доставки події.
Спосіб реалізації
- Читати проведені повернення, кредит-ноти, рядки продажу, продавця та збережені комісії.
- Версіонувати таблицю правил із датами чинності й обмежувати суму первинною комісією.
- Записувати коригування після погодження, перечитувати результат і зберігати ID транзакції.
Що потрібно для реалізації
- Збережено стабільні посилання між поверненням або кредит-нотою, первинним продажем і розрахованою комісією.
- План винагороди визначає обробку часткових повернень, дати чинності правил і коригувань після виплати.
- Відомо, хто погоджує суму та як передати коригування до системи комісій або payroll.
- Підтверджені API або стабільний експорт, документація планів комісії та тестовий контур.
Обмеження
- Різні плани визначають момент і суму зміни комісії по-різному; приклади Oracle та NetSuite не є правилом для кожного клієнта.
- Кредит-нота не завжди означає фактичне повернення грошей клієнту; умови виплати комісії потрібно перевіряти окремо.
- Картка не визначає законність відрахувань із заробітної плати. Такі дії потребують окремої перевірки політики й місцевих вимог.
- Години попередні; якість зіставлення даних, кількість планів винагород і статус попередніх виплат уточнюють під час аудиту.
- Утримання вже виплаченої комісії не автоматизується без окремо затвердженої політики й перевірки права.
Що потрібно уточнити (2)
- Чи потрібно коригувати комісію кільком продавцям або сплітам одного продажу?
Вкажіть правило розподілу початкової комісії та власника кожної частини.
- Чи можуть повернення стосуватися комісії, яку вже виплатили?
Потрібні погоджені правила обліку відповідальності й спосіб коригування майбутньої винагороди.