В этом грехопадении, именуемом "интеграция 1С с маркетплесами", можно придумать любую причину, например: "Я занимаюсь настойкой интеграций маркетплейсами по приговору суда" или "Меня прокляла цыганка", "Я нагрубил Деду Морозу", "Не уступил место бабушке в метро" и т.п.
Во времена СССР проштрафившегося партработника "бросали на сельское хозяйство" и это было фатально ,т.к. либо засуха, либо заморозки.
Так и не понял, в чём провинился именно я, когда каторга напротив "шлюзов в маркетплейсы" стала моим регулярным приговором. И это при том, что ничем, кроме задач учёта заниматься мне не приходится! Испытываю регулярное восхищение, как из простейшей процедуры неизвестные мне коллеги "с той стороны шлюзов" умудряются создать удивительнейший квест, который требует оживлённых ерзаний по таблицам документов. На примере основных, заявленных в штатной версии 1С-ных программ, маркетплейсов, постараюсь раскрыть несколько ключевых тем, которые "триггерят" особенно часто и неприятно, итак:
Мои замечания касаются исключительно задач учёта по результатам работы с маркетплейсами. Мерчандайзинг и прочие маркетологические прихваты и фенечки проходят мимо меня.
1. Чего фатально не хватает в данных, выгружаемых с маркетплейсов в целях учёта? Привязки события к реальному факту хозяйственной жизни (ФХЖ). Напоминаю, именно по этому ФХЖ и формируется то, что мы называем первичным документом, который и является источником ведения учёта. Как это выглядит у маркетплейсов (они так много списывают друг у друга, что заявлю - у всех!)) ). Они засовывают в свои таблицы очень много информации, в которой теряется та самая - которая реально нужна. Допустим, организация отгрузила в адрес маркетплейса товар для будущих реализаций некий набор товара. У этого события есть только одна дата и номер документа. Что приходится видеть в данных, получаемых из "интеграций"? Есть дата "Заказа" товара клиентом на маркетплейсе и есть дата фактического прибытия (оприходования) товара на маркетплейсе. Для целей учета у продавца вообще не интересно ни то, ни другое! Товар, условно, отгрузили в декабре 2025 с НДС 20%. Маркетплейс, зевая и потягиваясь после праздников, зачем-то ставит в известность, что его склад получил это 03.01.2026, соответственно, НДС в этой дате уже был 22%. И какой документ будет создаваться?
Единственно разумная организация выгружаемой с маркетплейса информации может иметь только вид "дерева", где "вершиной" является договор продавца и маркетплейса, в рамках этого договора за указанный период может существовать любое количество документов отгрузки с конкретной датой и номером! И каждый документ отгрузки породит свою ветку продаж отгруженных товаров или возвратов непроданных, а каждая продажа может порождать ветку товаров, возвращенных уже после продажи. При этом будет дополнительное разделение этих операций по виду сделки, если разные виды сделки допускаются в пределах одного договора. Я говорю о продаже в розницу и продаже юридическим лицам. Сложно разве? Вместо этого маркетплейс вываливает в обмен многоколоночную таблицу с ворохом дат, по которым можно строить только один алгоритм. Такой и реализован в штатных версиях 1С. Он описывается как "за указанный период у каждого маркетплейса может существововать только один документ определенного вида", например "Отчет о продажах комиссионера". И начинается мучительная привязка возврата товара к периоду в котором он отгружался и не менее мучительному поиску документа в том периоде. И не дай Процессор, чтобы кто-то нечаянно время в этом документе не поменял - он (документ) уже не найдётся! Что мешает на стороне маркетплейса прявязывать факты хозяйственной жизни (ФХЖ маркетплейса) к номерам и датам документа. Этот номер и дата станет реквизитами документа-основания в создаваемом уже на стороне продавца документа учёта. Именно по номеру и дате исходного документа потом можно и нужно производить все поиски для выстраивания дерева данных "Отгрузки-продажи-возвраты". В таком режиме работы можно выгружать данные за любой период и не будет никакого приговора "Один месяц - один документ!" У такого приговора есть неприятное проявление. Яндекс ранее, а недавно и ОЗОН придумали разделить потоки товаров. По понятным техническим причинам крупногабаритная техника (со спецификой тяжёлого товарооборота) выделены в отдельные пункты приёмки - условно, "склады" маркетплейсов. Допускаю, что небольшие контрагенты маркетплейсов этого не заметили. А в крупной конторе, где работают через оба склада знаете как работает принцип "один документ в один период"? Догадались уже, наверное) Каждая следующая загрузка (интеграция) затирает документы предыдущей. Ведь логика железная, один период - один документ. В Яндексе я вынужден был сделать разделение на склады, используя реквизиты самих документов 1С. Теперь в загрузках Яндекса приходится ещё имитировать внутренние перемещения между складами продавца. Но так хоть работает. А в интеграции ОЗОН используется документ "Отчет о продажах", там вообще нет реквизита "Склад". Спасаемся так. Документ первой загрузки меняет дату, после чего его следующая загрузка не обнаруживает и не затирает, создавая уже новый документ) Зато можно забыть вернут дату в исходное состояние и этот же документ не будет найден при загрузке возвратов, бухгалтер должен быть начеку! А что, есть задача дрессировать учётный персонал и поддерживать его в тонусе? Это, типа, "цели автоматизации"?
Далее. Лингвистические способности сограждан восхищают. Родные россиянцы так "обанглосаксонились", что на матюги перестали обижаться, видимо уже не понимая сказанного в их адрес. Смотришь в данные выгрузки и видишь формулировки "B2B" - умиляешься... Ничего, что я тут с вами "по-английски" разговариваю?) А теперь от милоты вернёмся к учёту. Есть понятие вида сделки, который моментально адресует нас к классификатору видов экономической деятельности. Нет у нас такого события, выражаемого абсолютно идиотской фразой "продажа бизнесу". Если кто найдёт такое - киньте ссылку. Бизнес (через подотчётное лицо) может осуществить покупку в рознице. Частное лицо может осуществить покупку по ГПХ у хозяйствующего субъекта. Новость для кого-то? Уважаемые маркетплейсы, не пишите этих идиотских чужеземных выражений в том, что предлагаете в качестве выгрузки для своих контрагентов. Если при сделке была выписана счет-фактура, то это уже не комиссионная розничная продажа (47.91 по ОКВЭД), а "Торговля оптовая за вознаграждение или на договорной основе" (46.1 по ОКВЭД) Что мешает подставлять в выгрузку данные, которые хоть идентифицировать можно с чем-то понятным и нормативно установленным (это я про коды ОКВЭД). На маркетплейсе ОЗОН недавно произошло грандиозное "событие". Интеграция через API начала выдавать содержимое в формате "JSON" Уже была мысль - отпраздновать такое выдающееся происшествие) Ведь раньше по интеграции API прилетал тот же самый файл EXCEL. Радость была недолгой. Использование более совершенного инструментария никак не вызвало переосмысления самого информационного наполнения. Собственно, из содержимого "JSON" выстраивается по итогу примерно та же грустная таблица (с кучей ненужного и фатальным отсутствием необходимого!), что и была в EXCEL. Более того, при загрузке отчета о продажах и возвратах в ОЗОН содержимое "JSON" формирует самую общую таблицу продаж и возвратов. Затем следует второе обращение по API, которое выдаёт... файл EXCEL, содержащий отдельные сведения по продаже юридическим лицам. И из общей таблицы продаж надо как-то вычитать данные продаж именно юрлицам!! У меня просто кончились слова... приличные. Эта извращённая технология так и не заработала. Сначала загрузили продажи юрлицам, а потом в следующей интеграции неожиданно поняли, что однажды проданное этим юридическим лицам уже "продалось еще раз" в общем отчёте. По итогу моя немаленькая контора плюнула на API, вернулась к каноничной православной загрузке из файлов EXCEL, в которых я хоть имел возможность (дописал код в расширении) отделить розничные продажи от продаж юридическим лицам.
Дальше описывать этот позор уже необязательно, написанного хватит. У меня мало претензий к нашему любимому вендору, он вынужден работать с тем материалом, который ему невольно навязывается. А ещё символично то, что на HH.ру появились вакансии программиста 1С с конкретной специализацией "по маркетплейсам". Можно тушить свет...
Маркетплейсы, что вы творите??
Вступайте в нашу телеграмм-группу Инфостарт
