Возвраты: 5 статусов, чек-лист приёмки, 5 решений по каждой позиции

Возврат как полноценный документ

В AIERP возврат — это не «вычеркнули из чека» и не «открепили позицию от заказа». Это отдельный документ, привязанный к заказу и к набору позиций возврата, с собственным номером, статусом, причиной, суммами и временными метками одобрения, приёмки, обработки и возврата денег. Это даёт юридическую дисциплину и аудит: видно, кто, когда, что и почему вернул, и что с этим товаром происходило дальше.

Структура: номер (уникальный, формат «ВВ-ГГГГММДД-XXXX»), заказ (с каскадным удалением — связь с исходным заказом), статус, причина (с обнулением при удалении причины), свободный комментарий (текст для произвольной причины), причина отклонения (текст), склад (для возврата товаров), четвёрка сотрудников (кто создал, одобрил, принял, обработал), общая сумма, возвращённая сумма, четыре временные метки (одобрение, приёмка, обработка, возврат денег), стандартные временные метки и мягкое удаление. 9 индексов по ключевым полям.

Связи: заказ, позиции возврата, причина, склад, четыре связи с сотрудниками (создал/одобрил/принял/обработал), комментарии, платежи. Это превращает возврат в самостоятельный финансовый и логистический объект: к нему пишутся комментарии на каждом шаге, к нему прикрепляются платёжные операции (через возврат денег).

5 статусов жизненного цикла и 8 у позиции

Статус возврата — пять значений: На рассмотрении (по умолчанию при создании), Одобрен (приёмка разрешена), Отклонён (финальный), Принят (приёмка завершена, появился в феврале 2026 миграцией), Обработан (все решения по позициям приняты). Каждый шаг защищён проверками: «можно одобрить/отклонить» — только из «На рассмотрении», «можно принять» — из «Одобрен», «можно обработать» — из «Принят», «можно возвращать деньги» — из «Одобрен»/«Принят»/«Обработан» при наличии остатка.

Статус позиции возврата — восемь значений, отражающих физическую судьбу единицы товара: Ожидает обработки, Принят на приёмке, Возвращён на склад, В ремонте, Возвращён клиенту (например, после отказа на экспертизе), Ожидает возврата денег, Перенесён в новый заказ, Отклонён. Каждый статус — результат конкретного действия (приёмки или решения), не «случайной правки».

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

Одобрение → Приёмка → Решение → Обработан: пайплайн в сервисах

Каждый шаг — отдельный обработчик, и каждый делает одну вещь. Одобрение проверяет «можно одобрить» (статус — «На рассмотрении»), ставит сотрудника, дату одобрения, опционально склад (куда вернуть товары), и пишет в комментариях «Возврат одобрен. Ожидается приёмка товаров.». Отклонение требует причину (валидация на пустоту), ставит статус «Отклонён» с теми же сотрудником и датой, и пишет «Возврат отклонён. Причина: …».

Приёмка проходит по данным позиций (массив с идентификатором позиции возврата плюс чек-лист) и для каждой позиции обновляет: в упаковке / есть следы использования / внешний вид в порядке (да/нет/не задано), описание дефектов и примечания (текст), дата приёмки и кто принял. Ставит позиции статус «Принят». После цикла обновляет сам возврат: статус «Принят», кто принял, дата приёмки. Финальный комментарий: «Товары приняты. Приёмка завершена.».

Решение по позиции обрабатывает каждую позицию отдельно. «Вернуть на склад» требует склада и вызывает возврат на склад. «В сервис» заполняет шестёрку полей сервиса (название, адрес, телефон, e-mail, номер обращения, описание) и ставит статус «В ремонте». «Вернуть клиенту» и «Вернуть деньги» просто меняют статус позиции (соответственно). «Новый заказ» требует заказа и ставит статус «Перенесён в заказ» и привязку к заказу.

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

Возврат денег: связь с платежами

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

Алгоритм возврата: 1) находим возврат, 2) проверяем «можно ли возвращать» (статус — «Одобрен»/«Принят»/«Обработан» и возвращённая сумма меньше общей), 3) определяем сумму (передана = используем, нет = остаток = общая − возвращённая), 4) валидируем границы (>0, ≤ доступная), 5) берём платежи заказа, у которых стоит «принят», не стоит «отменён» и нет родительского (оригинальные оплаты, не возвраты), 6) фильтруем через «можно возвращать», 7) на первую подходящую вызываем возврат суммы, 8) если успех — обновляем возвращённую сумму и дату возврата.

Это даёт частичные возвраты «в любую сторону»: клиент вернул 3 позиции из 5, мы возвращаем по 3-м, остаток продолжает «висеть» как обязательство. Через неделю клиент возвращает ещё одну — возврат по ней, возвращённая сумма растёт. Когда возвращённая = общая, проверка возможности возврата возвращает «нельзя», кнопка дизейблится. Никакого «двойного возврата».

Действие «можно ли возвращать» — вспомогательное, для интерфейса. Возвращает «можно ли возвращать, сообщение, доступная сумма». Если оригинальных платежей нет (всё отменено или старая база без полных данных) — «нельзя» с понятным сообщением. Интерфейс рисует кнопку «Вернуть деньги» в дизейбле с подсказкой, пользователю не нужно «пробовать и получить ошибку».

Возврат на склад: единица = одна запись

Это место, где AIERP отличается от типовых ERP. В обычной системе при возврате 5 шт. товара на склад создаётся одна запись с количеством 5. В AIERP — пять отдельных записей с количеством 1 каждая, и каждая знает свою историю прихода: исходный заказ (откуда пришла), исходная заявка поставщику (по какой), «зачёркнутая»/закупочная/закупочная скидка, физический адрес (ряд, стеллаж, полка, ячейка).

Реализация: в цикле по количеству, на каждой итерации создаётся запись. Данные собираются из позиции возврата (товар, цена) и позиции заказа («зачёркнутая», закупочная, закупочная с расходами, закупочная скидка, физическое положение). Привязка к заявке поставщику восстанавливается из исходной заявки позиции. К позиции возврата прикрепляется идентификатор последней созданной записи — для трассировки «возврат на склад → конкретная единица».

Зачем так. Сценарий 1: маркетплейс или розница торгует серийным товаром (электроника, бытовая техника). Каждая единица — отдельный серийник. Возврат — это «вернулась именно та, что продали», а не «5 каких-то». Сценарий 2: возврат бракованного товара поставщику. Берём именно те единицы, что вернул клиент (а не «5 любых со склада»), и они идут к поставщику со своей привязкой — поставщик видит свою же поставку. Сценарий 3: аналитика «оборачиваемость возвратного товара» — отдельная метрика, недоступная при «общих» остатках.

Склад определяется в порядке: склад из возврата (если указан при одобрении) → магазин получателя из заказа (куда заказ ехал). Если не определён — ошибка «Не указан склад для возврата товаров». Статус «в наличии» проставляется автоматически. Комментарий: «Товар №X из возврата №Y возвращён на склад №Z (N шт)» — для аудита.

Чек-лист приёмки, фото, причины: дисциплина экспертизы

Главная боль «бытовых» возвратов — споры о состоянии товара. В AIERP это закрыто чек-листом и фотодокументацией прямо в самой системе. Миграция февраля 2026 добавила в позиции возврата пять полей чек-листа: в упаковке (да/нет/не задано), есть следы использования (да/нет/не задано), внешний вид в порядке (да/нет/не задано), описание дефектов (текст), примечания (текст), плюс дата приёмки и кто принял. Индексы — на решение и дату приёмки для отчётов «принято за период».

Приёмка принимает массив данных с этими полями и сохраняет их прямо в позиции возврата. Интерфейс приёмки — это форма с 3 чекбоксами (упаковка / следы / внешний вид) и 2 текстовыми полями (дефекты / примечания). Параллельно загружаются фото — отдельная таблица с миграцией февраля 2026, у позиции есть связь «много фото».

Справочник причин содержит 6 встроенных значений (Брак / дефект товара, Не тот товар, Повреждён при доставке, Покупатель передумал, Не соответствует описанию, Другая причина). На возврате — причина (с обнулением при удалении причины) и свободный комментарий (для уточнения, особенно при «Другая»). Это даёт аналитику качества: фильтр поддерживает параметр «причина», статистика возвращает агрегаты, через связь позиции возврата с позицией заказа можно посчитать «какие поставщики чаще всего дают брак».

Право на работу с возвратами разделено на три уровня: создание (менеджеры/кассиры), редактирование (одобрение/приёмка/решение/возврат денег — руководители), просмотр (чтение). Назначаются стандартным образом. Раздел в админке называется «Возвраты». Никакого «универсального суперюзера» — даже руководители делают все шаги через пайплайн, не правят базу напрямую.

Действия в интерфейсе, фильтры, статистика, кэш и журнал

Действия: список с фильтром (фильтр возвратов), статистика (агрегаты), счётчики по статусам, список статусов (карта), «возвраты по заказу», карточка одного возврата. Стандартные действия: создать, изменить, удалить. Одобрить, отклонить, вернуть деньги, принять. Проверка возможности возврата денег. Решение по позиции. Загрузка/просмотр/удаление фото позиции. Справочник причин с действием «все причины».

Фильтр: 10 параметров. Идентификатор, заказ (число), статус (строка или массив), склад, причина, кто создал, кто одобрил, диапазон дат создания, поиск — двойной по номеру возврата и через связь по номеру заказа. Это покрывает все типовые сценарии без выгрузок.

Защита: редактирование и удаление возвращают ошибку «Нельзя редактировать/удалить обработанный возврат», если статус не «На рассмотрении». Это критично для аудита — после одобрения возврат становится «выписанным документом», который меняется только через дисциплинированные операции, а не через прямое редактирование полей. Отклонение требует непустую причину. Приёмка требует «можно ли принять» (статус — «Одобрен»). Каждый шаг защищён.

Кэш: списки кэшируются, после каждого изменения сбрасываются. Мягкое удаление у возврата и позиции — удалённые мягко скрываются, восстановление возможно. Журнал: после каждого действия (одобрение/отклонение/приёмка/решение/возврат денег) пишется комментарий с сотрудником и временем. Внутреннюю «бумажную тропинку» по любому возврату можно поднять одной выборкой комментариев.