Интеграция 1С с маркетплейсами обычно появляется, когда товаров становится больше, чем можно вести руками. Модуль стоит, остатки выгружаются, заказы приходят. А через пару месяцев картина знакомая: менеджеры работают в кабинетах Ozon и Wildberries, склад в 1С, бухгалтер сверяет отчёты маркетплейсов с учётом в Excel, и цифры не бьются. Ниже разбираю, почему модуль интеграции не снимает расхождения по остаткам и деньгам и что должно быть в сверке с маркетплейсами, чтобы их ловить без сплошной ручной проверки.
Сразу о рамках. Я не программист 1С и модули интеграции не продаю. Моя работа это стыки между системами: что где правда, как системы узнают друг друга, кто замечает, что данные разошлись. Сторону 1С я проверил на тестовой базе 1С:УНФ 3.0: передал товар маркетплейсу на комиссию, провёл отчёт о продажах и сверил остатки. Реального кабинета продавца у меня нет, поэтому отчёт маркетплейса я смоделировал по описанию API Wildberries (интерфейса, через который программы обмениваются данными); где что проверено, пишу прямо. Механика отчётов взята из справки Wildberries и Ozon, позиция налоговой из разъяснения ФНС.
Что делает интеграция, а чего не делает
Модули интеграции 1С с Ozon и Wildberries устроены похоже: выгружают цены и остатки на маркетплейс, загружают заказы и отправления, ведут сборку по модели FBS, сопоставляют карточки маркетплейса с номенклатурой в 1С, передают коды маркировки.
В самой УНФ тоже есть кое-что для маркетплейсов: в отчёте комиссионера стоит команда «Загрузить из маркетплейса», а по описанию 1С она загружает отчёты Ozon через API. Кнопку я видел, но не запускал.
Это обмен данными. Он отвечает на вопрос «как передать», но не на вопрос «сходится ли». Модуль перенесёт в 1С то, что отдал маркетплейс, и выгрузит то, что лежит в 1С. Если по дороге товар застрял в возврате или удержание пришло задним числом, обмен этого не заметит. Сверка это отдельная задача. Если её никто не берёт на себя, она достаётся бухгалтеру и Excel.
Если интеграция сама пишет документы в 1С через API, есть отдельная ловушка. Её я проверил на стенде. Форма 1С при вводе подставляет ставку НДС и счета учёта сама, а запись через API этого не делает. У меня передача товара на комиссию, созданная через API, прошла. Но отчёт комиссионера на её основе не провёлся из-за пустой ставки НДС. А приход не провёлся, потому что у товара, заведённого через API, остался пустым счёт учёта.
Сверка остатков: почему 1С и маркетплейс расходятся
У товара на складе маркетплейса несколько состояний. На модели FBO товар лежит на складе маркетплейса, и площадки показывают его остаток по частям. У Wildberries это доступный остаток, резерв и товар в пути, в том числе в пути от покупателя при возврате. У Ozon кроме доступного и зарезервированного есть товар в пути, возвраты, брак и товар с истекающим сроком, который нужно продать или вывезти. В 1С же часто одна цифра «на складе маркетплейса». Сложили резерв с доступным, и запас завышен. Посчитали товар в пути как наличие, и поставки планируют по цифре, которой на витрине нет.
К тому же формат этих данных меняется. Wildberries пометил устаревшим свой метод получения остатков и перестал отдавать в нём отдельные поля для товара в пути к покупателю и от покупателя: такой товар теперь приходит строками в списке складов. Интеграция, написанная по старому формату, может тихо перестать видеть товар в пути. Так сказано в описании изменений API Wildberries; на живом кабинете я это не проверял.
Возвраты и брак идут своим путём. Возврат приходит отдельной строкой отчёта, брак возвращается на склад по своей схеме. Если под них нет документов в 1С, в остатках появляется разница, которую потом трудно объяснить.
Отмены на FBS не возвращают остаток сами. Заказ отменили после того, как остаток на маркетплейсе уменьшили. Если остаток не вернули, товар есть на складе, но на витрине его нет.
Карточки сопоставлены не так. Один товар в 1С связан с двумя карточками на маркетплейсе, или две позиции номенклатуры связаны с одной карточкой. Обмен работает, но остатки считаются не по тем позициям.
Обмен по расписанию отстаёт от продаж. Остатки выгружаются раз в какое-то время. Между выгрузками товар продают и на маркетплейсе, и в других каналах. Чем реже обмен, тем выше шанс продать то, чего уже нет.
Почему не сходятся деньги
Отчёты приходят в разном ритме. Wildberries формирует отчёт о реализации еженедельно. Ozon присылает отчёт о реализации раз в месяц, не позднее 5-го числа следующего месяца, а для поиска расхождений у него есть позаказный отчёт.
Удержания живут отдельно от продаж. В отчёте Wildberries кроме продаж и возвратов есть логистика, хранение, штрафы и корректировки прошлых периодов. Часть удержаний проходит отдельными документами, а не внутри отчёта о реализации. Поэтому сумма на счёте почти никогда не равна «продажи минус комиссия».
Корректировки приходят задним числом. Маркетплейс может пересчитать прошлый период. Если в 1С период уже закрыт по старым цифрам, расхождение переезжает в следующий и копится.
Есть и налоговая сторона. ФНС в письме от 8 мая 2024 года разъяснила: доходом продавца на УСН считается вся сумма, которую заплатил покупатель, а вознаграждение, удержанное маркетплейсом, доход не уменьшает. Считать доходом только то, что пришло на счёт, значит рисковать доначислениями. Как отражать это в учёте, вопрос к вашему бухгалтеру. Моя часть в том, чтобы расхождение было видно вовремя, а не при закрытии года.
Что должно быть в сверке с маркетплейсами, готовой или своей
Сервисы сверки маркетплейсов с 1С продаются готовыми, и для многих селлеров это правильный выбор. Собрать своё может быть нужно, если у вас несколько кабинетов или юрлиц на одной базе 1С, конфигурация 1С доработана, или данные сверки нужны в своей базе рядом с остальной аналитикой. В обоих случаях проверяйте одно и то же.
1. Определить, где какой факт главный
Остатки на своём складе в 1С. Остатки на складе маркетплейса по его данным, с разбивкой по состояниям. Начисления и удержания по отчётам маркетплейса. Пока это не решено, сверка превращается в спор двух цифр. Почему, я писал в посте про интеграцию CRM с мессенджерами и таблицами.
2. Сверять по расписанию, а не при закрытии месяца
Остатки маркетплейса можно получать через его API, а данные 1С через стандартный интерфейс OData, и сравнивать их каждый день по артикулу. У API маркетплейсов есть лимиты на частоту запросов, это надо учесть при расписании. Результат сверки это не таблица по всему ассортименту, а короткий список позиций, где разница превышает порог, с состоянием товара на стороне маркетплейса.
Главное здесь, с чем сравнивать. Покажу на примере, и сразу оговорюсь, что это иллюстрация логики, а не замер. Сторона 1С настоящая: пять разных товаров, переданных маркетплейсу на тестовой УНФ. Данные маркетплейса я придумал сам, заложив три обычные ситуации: товар едет покупателю, возврат едет на склад, одна вещь пропала. Сравнение «остаток на полках маркетплейса против 1С» показало расхождения по трём товарам из пяти, и два из них были ложными: по двум товарам часть штук ехала к покупателю и по 1С ещё числилась нашей. При этом возврат в пути такое сравнение не заметило вовсе. Правильная база: товар на полках плюс товар в пути к покупателю, а возвраты отдельно, как ожидаемое событие, после которого в 1С понадобится возврат. С такой базой осталось одно настоящее расхождение, пропавшая вещь. На реальном потоке будет грязнее: задвоенные карточки, возвраты, которые неделями числятся в пути, отчёты с задержкой. Правильная база не убирает эти случаи, а отделяет их от ложных тревог.
3. Сопоставлять каждую строку отчёта с документом
С деньгами так же: каждую строку отчёта о реализации сопоставить с документом в 1С. Удержания, для которых документа нет, попадают в очередь «разобрать» с суммой и основанием из отчёта. Разбирать короткую очередь каждую неделю проще, чем искать накопившуюся разницу в конце квартала.
4. Присылать сигнал туда, где работают люди
Отчёт о расхождениях, который лежит в папке, никто не открывает. Он должен приходить в рабочий чат тому, кто за это отвечает, и молчать, когда всё сходится. Как не утонуть в ложных тревогах, я разбирал в посте про мониторинг.
5. Держать сверку отдельно от учёта
Сверка должна читать данные, а не править их. Если она живёт рядом с 1С, а не внутри конфигурации, обновление 1С или модуля интеграции не ломает контроль, а контроль не ломает учёт. Похожий подход к стыку 1С с CRM я разбирал в посте про ошибки обмена 1С и Битрикс24.
С чего начать самому
Возьмите двадцать самых ходовых позиций и сравните остаток «у комиссионера» в 1С с остатком в кабинете маркетплейса: на полках плюс в пути к покупателю. Возвраты в пути выпишите отдельно. Потом откройте последний еженедельный отчёт Wildberries или позаказный отчёт Ozon и найдите удержания, под которые в 1С нет документа. Эти два упражнения покажут, где именно расходятся ваши данные: в остатках, в деньгах или в обоих местах.
Посчитать, сколько часов в месяц уходит на ручные сверки, можно в калькуляторе потерь, сценарий «ручные стыки систем». А если нужен взгляд со стороны, напишите мне. Созвонимся на 30 минут и посмотрим, где у вас расходятся остатки и деньги и хватит ли готового сервиса или нужно своё.
Узнали свою ситуацию?
Обмен 1С с CRM, сайтом и маркетплейсами без дублей, со сверкой остатков. Как это устроено и сколько стоит, на странице «Интеграция с 1С».
Обсудить задачу