Покупатель вернул товар: как не потерять связь между оплатой и возвратом

Проблема возникает там, где каждый видит только свою часть истории. Склад работает с товаром, менеджер — с заказами, банк — с денежными потоками. Чтобы объединить эти части, магазину нужна надежная связь между записями. Рассмотрим, как это организовать на учебном примере. Все номера, даты и суммы ниже приведены условно.

Один заказ, две оплаты, один возвращенный товар

Магазин продал по заказу № 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 грн. Это остаток полученных средств по данному заказу после возврата. Для вывода о налоговом доходе такой арифметики недостаточно: нужны правила соответствующего режима налогообложения и документы. Здесь мы разбираем именно организацию операционных данных.

Почему недостаточно найти такую же сумму

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

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

Если точная связь не установлена, запись должна оставаться среди непроверенных. Это менее удобно, чем автоматическая «зеленая» отметка, зато не скрывает вопросов. Ответственный сотрудник может сопоставить детали, добавить пояснения и подтвердить связь. Впоследствии будет видно, кто именно это сделал и на каком основании.

Сохраните историю, а не только новую сумму

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

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

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

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

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

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

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

Поэтому статус товара и статус платежа лучше вести отдельно. Например: товар получен, заявка на возврат средств создана, ожидается выполнение. После подтверждения от банка или платежного провайдера меняется именно платежный статус. Если операция завершилась ошибкой, заявка остается открытой, даже когда товар уже лежит на полке.

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

Что делать с частями и повторной загрузкой

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

Несколько платежей добавляют ещё один уровень сложности. Если возврат состоит из двух операций по 600 грн, каждая из них имеет свой идентификатор и статус. Вместе они составляют 1 200 грн только после проверки. Если одна операция выполнена, а другая ещё ожидается, итог выполненных возвратов пока составляет 600 грн.

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

Предел квартала не должен разрывать историю

Оплаты по заказу №1048 произошли в сентябре, а возврат средств в октябре. Если отчет показывает только октябрьские операции, то он скроет начало истории. Пользователь увидит минус 1 200 грн без вразумительного объяснения.

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

Чтобы не собирать данные в последний момент, запланируйте сверку возвратов до ближайшего срока отчетности. Ориентиром может быть налоговый календарь для ФЛП, если указанный в нем профиль соответствует вашим условиям работы

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

Проверка, которую можно сделать по одному заказу

Возьмите завершенный случай возврата и попросите коллегу, который его не обрабатывал, найти ответы на пять вопросов. Что купили? Как оплатили? Что именно вернули? Какую сумму фактически получил назад покупатель за подтверждением платежного сервиса? Какие действия еще остались открытыми?

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

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