Учет в пункте выдачи ломается в трёх местах: неясно, чей товар на полке, кто платит за хранение и как считать доход при невыкупе. Автоматизация на n8n сверяет заказы маркетплейса, ПВЗ и CRM по одному ключу. Она блокирует двойной учет дохода при повторной продаже.
Что входит в учет в пункте выдачи и где он ломается
Представьте утро бухгалтера (пример условный). В отчёте маркетплейса 40 заказов в статусе «выдан», в CRM у продавца 38, а на складе ПВЗ не хватает двух коробок. Три системы называют одно и то же событие по-разному, и никто не знает, какой цифре верить.
Учет в пункте выдачи состоит из четырёх потоков. Первый — движение товара: приёмка, хранение, выдача, возврат. Второй — деньги: оплата покупателем, удержания, выплата продавцу. Третий — статусы заказов. Четвёртый — документы для налоговой и бухгалтерии.
Ломается учет на стыках. Статус «выкуплен» приходит в одну систему раньше, чем в другую. Невыкупленный заказ возвращается на склад и уходит новому покупателю, а старая запись о доходе остаётся. Хранение тарифицируется по дням, но в CRM такого поля нет.
Поэтому сначала нужна общая модель данных, а уже потом автоматизация. Если вы только собираете базовый учет, начните с материала Учет в интернет-магазине: настройка и автоматизация. После него вы поймёте, какие поля заказа нужны в каждой системе, и сможете перейти к схеме ниже.
Чей товар лежит в ПВЗ: собственность, баланс продавца и налоги
Первый вопрос аудита звучит так: на чьём балансе товар в момент, когда он лежит в пункте выдачи? Ответ зависит от схемы работы. Пункт может быть агентом маркетплейса, самостоятельным перевозчиком или местом хранения по договору.
В типовой схеме право собственности остаётся у продавца до момента передачи покупателю. ПВЗ только хранит и выдаёт. Значит, товар числится на балансе продавца как товар в пути или на ответственном хранении, а у пункта выдачи он забалансовый.
Доход возникает не при отгрузке в пункт, а при передаче покупателю. До выдачи вы показываете запас, после выдачи — реализацию. Если бухгалтер признаёт доход по статусу «отгружен в ПВЗ», невыкуп превращается в завышенную выручку и лишний налог.
Точные нормы и даты изменений для ПВЗ проверяйте в первоисточнике: в письмах ФНС, в оферте маркетплейса и у своего бухгалтера. Подтверждённых дат вступления в силу у нас нет, поэтому мы их не называем. Как маркетплейсы передают данные в ФНС, читайте в статье Ozon формирует отчёты для ФНС: что делать продавцам.
Практичное правило для автоматизации: храните в CRM не один статус, а два поля. Первое показывает, где физически товар. Второе показывает, признан ли доход. Эти поля меняются независимо.
Хранение, невыкуп и повторная продажа: как не учесть доход дважды
Хранение в пункте выдачи бесплатно только в пределах срока, заданного договором. После него кто-то платит: покупатель, продавец или маркетплейс. В учёте это отдельная статья расходов, а не часть комиссии. Если её смешать с логистикой, вы не увидите, сколько стоит невыкуп.
Теперь о базе дохода. Покупатель платит одну цену, продавец получает другую. Разницу составляют комиссия, логистика и скидки площадки.
Разберём условный пример. Покупатель заплатил 1000 ₽, удержания составили 150 ₽, продавцу пришло 850 ₽. База дохода может равняться 1000 ₽ или 850 ₽ в зависимости от договора и позиции налогового органа. Это решает бухгалтер, а не скрипт.
Невыкуп создаёт ловушку. Заказ вернулся на склад пункта, его купил другой человек. Если система сохранила доход по первой продаже и добавила доход по второй, вы посчитали один товар дважды.
Статусы и действия сведены в таблице.
| Статус заказа | Что происходит с товаром | Действие в учёте |
|---|---|---|
| Выдан покупателю | Товар у покупателя | Признать доход один раз |
| Невыкуп, возврат на склад | Товар вернулся к продавцу | Сторнировать доход, если он был |
| Повторная продажа | Товар ушёл новому покупателю | Создать новый заказ с новым ключом |
Главный вывод: у каждой продажи свой ключ, а возврат всегда закрывает предыдущую запись прежде, чем откроется новая.
Как собрать на n8n сверку маркетплейсов, ПВЗ и CRM
Схема строится вокруг n8n как центрального узла. Он забирает заказы из API маркетплейсов, статусы из системы пункта выдачи и записи из CRM, затем сводит их в одну таблицу сверки. Подробности о переходе с зарубежных сервисов есть в материале Альтернатива Zapier для России: переход на n8n.
Рабочий сценарий состоит из пяти шагов:
- Запуск по расписанию, например раз в 15 минут (пример, интервал подберите сами), плюс вебхук на смену статуса.
- Выгрузка заказов и статусов из трёх источников в единый формат.
- Склейка по составному ключу: площадка, номер заказа, номер попытки продажи.
- Проверка правил: доход признаётся только при статусе «выдан», а при возврате запись сторнируется.
- Запись в базу и уведомление ответственному о расхождениях.
Составной ключ с номером попытки защищает от двойного учета. Повторная продажа получает попытку 2, и система видит, что попытка 1 закрыта возвратом. Если закрытия нет, n8n не пускает доход дальше и отправляет сообщение в рабочий чат.
В отчёте сверки вы видите каждое расхождение отдельной строкой: заказ, источник, какой статус не совпал. Утренний пример с 40 и 38 заказами превращается в список из двух позиций, которые можно разобрать за минуты.
Старую схему учета оставьте работать параллельно до первой успешной сверки. Так вы сравните цифры и не потеряете данные при переходе.
Расхождения не исправляются автоматически молча. Сценарий пишет журнал изменений, чтобы бухгалтер видел, кто и когда поменял статус.
Остатки в распределенной сети точек: как сохранить контроль
Когда товар лежит в сотнях пунктов выдачи в разных городах, ручная сверка невозможна. Продавец не знает, в какой точке застряла партия, а маркетплейс показывает остатки только на своих складах. Контроль строится на другом принципе: вы учитываете не точки, а заказы в движении.
Каждая единица товара получает статус и срок. Например, «в пункте, хранение до даты X». Сценарий n8n раз в сутки собирает заказы, у которых срок хранения подходит к концу, и составляет список на возврат или продление.
Три правила помогают не потерять товар:
- Ведите остаток по заказам, а не по пунктам: так видно, где лежит каждая единица.
- Выделяйте зону риска: заказы без движения дольше половины срока хранения.
- Сверяйте возвраты с приёмкой на своём складе, а не только с отчётом маркетплейса.
О том, как держать остатки едиными между площадками, читайте в статье Автоматическая синхронизация остатков Ozon: как настроить. Если остаток на сайте не совпадает с остатком на площадке, покупатель оформит заказ на товар, которого нет.
Чек-лист: как подготовить учет и не заплатить за бездействие
Бездействие стоит конкретных денег. Завышенная выручка из-за невыкупа ведёт к лишнему налогу. Незаписанные расходы на хранение искажают прибыль. Расхождения между отчётом площадки и вашей отчётностью приводят к вопросам налоговой, доначислениям и штрафам. Кассовый разрыв возникает, когда деньги за невыкупленный товар числятся доходом, а их нет на счёте.
Чек-лист держится на одной дате. Возьмите дату из официального документа и считайте от неё назад. Ниже ответственные и сроки относительно этой даты.
- За 60 дней: бухгалтер проверяет договоры и фиксирует, чей товар в ПВЗ и какая база дохода (ответственный: бухгалтер).
- За 45 дней: аналитик описывает статусы заказов и поля CRM (ответственный: руководитель учёта).
- За 30 дней: автоматизатор собирает сценарий сверки в n8n и запускает параллельно со старым учётом (ответственный: технический специалист).
- За 14 дней: команда разбирает расхождения и правит правила (ответственные: бухгалтер и автоматизатор).
- В день вступления: переключение на новую схему и ежедневный контроль журнала в первую неделю.
Сроки в днях здесь предложены как рабочий ориентир, а не как норма закона. Подставьте свои после изучения официальных документов.
Частые вопросы
Какие изменения в налоговом и бухгалтерском учете затрагивают ПВЗ и когда они вступают в силу?
Затрагиваются три области: признание дохода по сделкам через пункты выдачи, отчётность маркетплейсов перед налоговой и учёт расходов на хранение. Подтверждённых дат у нас нет, поэтому не опирайтесь на пересказы. Берите дату из официального письма ФНС или из уведомления площадки и согласуйте её со своим бухгалтером.
Кто оплачивает хранение товара в пункте выдачи и как это отражается в учете?
Кто платит, определяет договор: в одних схемах это покупатель после льготного срока, в других продавец или маркетплейс. В учёте расходы на хранение показывайте отдельной статьёй, не смешивая с логистикой и комиссией. Тогда вы видите реальную цену невыкупа по каждому товару.
Как не посчитать доход дважды при повторной продаже невыкупленного заказа?
Давайте каждой попытке продажи свой ключ: площадка, номер заказа, номер попытки. При возврате сторнируйте доход первой попытки, и только после этого признавайте доход второй. Сценарий n8n проверяет это правило перед записью в учёт и сообщает о незакрытых возвратах.
Почему база дохода может отличаться от суммы, которую получает продавец?
Покупатель платит полную цену, а продавцу приходит сумма за вычетом комиссии, логистики и скидок площадки. В условном примере 1000 ₽ минус 150 ₽ удержаний дают 850 ₽ выплаты. Какая из цифр служит базой дохода, зависит от договора и позиции налогового органа, поэтому подтвердите её у бухгалтера.
Что делать дальше
Если нужно свести маркетплейсы, ПВЗ и CRM в одну сверку, начните с описания своих статусов и полей. Для этого можно пройти аудит и миграцию процессов на n8n: по его итогам у вас будет описанная схема сверки ваших заказов.
