Покупець повернув товар: як не загубити зв’язок між оплатою та поверненням

Проблема виникає там, де кожен бачить свою частину історії. Склад працює з товаром, менеджер із замовленням, банк із рухом грошей. Щоб зібрати ці частини, магазину потрібен стійкий зв’язок між записами. Розглянемо, як його організувати на навчальному прикладі. Усі номери, дати та суми нижче умовні.

Одне замовлення, дві оплати, один повернений товар

Магазин продав за замовленням № 1048 рюкзак за 2 400 грн і сумку за 1 200 грн. Загальна вартість товарів становить 3 600 грн. Покупець сплатив 1 000 грн передоплати 28 вересня, а 2 600 грн доплатив 30 вересня. 2 жовтня він звернувся щодо повернення сумки. 5 жовтня магазин отримав товар, а 6 жовтня підтвердив виконане повернення 1 200 грн.

Для простоти в цьому прикладі немає доставки, комісій і знижок. У реальному замовленні їх потрібно відображати окремо, якщо вони впливають на суми.

У системі мають залишитися обидві оплати: P-01 на 1 000 грн і P-02 на 2 600 грн. Повернення R-01 на 1 200 грн отримує власний запис і зв’язок із замовленням № 1048 та конкретною товарною позицією. Якщо провайдер прив’язує повернення до певної платіжної операції, зберігається й цей ідентифікатор. У нашому прикладі це P-02.

Тепер можна перевірити просту арифметику: 1 000 + 2 600 − 1 200 = 2 400 грн. Це залишок отриманих коштів за цим замовленням після повернення. Для висновку про податковий дохід такої арифметики недостатньо: потрібні правила відповідного режиму оподаткування й документи. Тут ми розбираємо саме організацію операційних даних.

Чому недостатньо знайти таку саму суму

У магазині можуть бути десятки оплат по 1 200 грн. Однакові суми та близькі дати допомагають запропонувати збіг, проте не доводять його. Ще менше допомагає ім’я покупця, якщо він робив кілька замовлень або платив з іншого рахунку.

Основою зв’язку краще зробити номер замовлення та ідентифікатори платежів із банку чи платіжного сервісу. Коли джерел кілька, поруч із номером операції варто зберігати її джерело: однаковий внутрішній номер може трапитися в різних системах.

Якщо точний зв’язок не встановлено, запис має залишатися серед неперевірених. Це незручніше за автоматичну зелену позначку, зате не приховує питання. Відповідальний працівник може зіставити деталі, додати пояснення й підтвердити зв’язок. Згодом буде видно, хто саме це зробив і на підставі чого.

Збережіть історію, а не лише нову суму

Найкоротший шлях виглядає спокусливо: замінити в замовленні 3 600 на 2 400 грн і рухатися далі. Але тоді зникає відповідь, чому покупець спочатку заплатив більше. Ще гірше, якщо поруч залишається окреме повернення на 1 200 грн: наступний звіт може відняти його вдруге.

Зручніше зберігати початкові події й будувати підсумок із них. Оплата залишається оплатою, повернення має власну дату, суму й статус. Зміна складу замовлення також повинна мати історію: яка позиція повернулася, у якій кількості, за якою фактичною ціною.

Для кожного повернення достатньо почати з кількох полів:

• номер замовлення та повернена позиція;
• сума, валюта й дата операції;
• ідентифікатор повернення та його джерело;
• пов’язаний платіж або розподіл між платежами;
• статус і підтвердження виконання;
• відповідальний працівник та пояснення ручних змін.

Кількість полів сама по собі нічого не гарантує. Важливо, щоб інша людина могла відновити подію без повідомлення "запитай Олену, вона пам’ятає«.

Товар на складі та гроші в покупця мають різні статуси

У нашому прикладі між зверненням покупця і виконаним поверненням коштів минуло кілька днів. Одна позначка «повернено» стирає цю різницю. Для складу вона може означати прийняту сумку, для менеджера закрите звернення, а для власника нібито завершений рух грошей.

Тому стан товару й стан платежу краще вести окремо. Наприклад: товар отримано, повернення коштів створено, виконання очікується. Після підтвердження від банку або платіжного провайдера змінюється саме платіжний статус. Якщо операція завершилася помилкою, випадок залишається відкритим, навіть коли товар уже лежить на полиці.

Це дає корисний щоденний список: товар прийняли, але гроші ще не повернули; гроші повернули, але зв’язок із замовленням не підтвердили; операцію відхилено і потрібна дія працівника.

Що робити з частинами й повторним завантаженням

Часткове повернення потребує точності до товарної позиції. Якщо покупець придбав три однакові речі й повернув одну, важливі кількість та її фактична вартість у цьому замовленні. Поточна ціна в каталозі могла вже змінитися.

Кілька оплат додають ще один рівень. Якщо повернення складається з двох операцій по 600 грн, кожна має свій ідентифікатор і статус. Разом вони утворюють 1 200 грн лише після перевірки. Якщо одна виконана, а інша ще очікується, підсумок виконаних повернень поки становить 600 грн.

Окрема пастка виникає під час імпорту. Працівник уже завантажив виписку за тиждень, а потім завантажив за весь місяць. R-01 з’являється в обох файлах. Система повинна розпізнати ту саму операцію за стійким ключем джерела, а не створити друге повернення. Якщо такого ключа немає, можливий дубль варто винести на перевірку. Видаляти всі однакові суми небезпечно: два справжні повернення також можуть збігатися за сумою.

Межа кварталу не повинна розривати історію

Оплати за замовленням № 1048 відбулися у вересні, а повернення коштів у жовтні. Якщо звіт показує лише жовтневі операції, він приховає початок історії. Користувач побачить мінус 1 200 грн без зрозумілого пояснення.

Тому із запису повернення має відкриватися початкова оплата, навіть якщо вона поза обраним періодом. Самі дати подій потрібно зберігати фактичними. Перенесення жовтневого списання у вересень заради красивого підсумку зіпсує звірку з банком.

Щоб не збирати ці дані в останній момент, заплануйте звірку повернень до найближчого строку звітності. Орієнтиром може бути податковий календар для ФОП, якщо зазначений у ньому профіль відповідає вашим умовам роботи

На закритті періоду корисно окремо переглянути повернення, пов’язані з давнішими замовленнями, незавершені операції та ручні виправлення. Так бухгалтер або власник отримає повну історію для подальшого визначення належного відображення у звітності. Цей операційний перегляд не замінює податкових правил, але дає дані, без яких їх складно правильно застосувати.

Перевірка, яку можна зробити на одному замовленні

Візьміть завершений випадок повернення й попросіть колегу, який його не обробляв, знайти відповіді на п’ять запитань. Що купили? Як оплатили? Що саме повернули? Яку суму фактично отримав назад покупець за підтвердженням платіжного сервісу? Які дії ще залишилися відкритими?

Якщо для цього доводиться збирати людей у чаті, варто допрацювати зв’язки між записами. Добре організована історія дозволяє розібратися в події навіть тоді, коли менеджер у відпустці, місяць уже закритий, а покупець звернувся повторно. Саме така перевірюваність допомагає магазину працювати спокійніше, коли замовлень стає більше.

Автор: Антон Ляховський, засновник MYFOP UA