Последние несколько месяцев имел множество задач, вызванных различными нюансами работы хозяйствующего субъекта с тем, кого принято называть «маркетплейсом» или «электронной торговой площадкой». По результатам разгребания этой «Авгиевой конюшни» выводы сделались нерадостные. Если принять методологические решения 1С, как цепь, то раздел «Маркетплейсы» я сочту одним из самых слабых «звеньев». Сразу оговорюсь, что сама 1С не во всём виновата) Теперь по порядку. Произносим «Маркетплейс» и в голове сразу ассоциации с цветами и символикой конкретных брендов. Знакомые неоновые буковки, которые висят почти на каждом подъезде. Плотная непрекращающаяся реклама «дожимает» ассоциации прямо в подкорку мозга. И вот уже родилось впечатление что текущий набор «маркетплейсов» уже «навсегда». Видимо, именно такой психологический импринтинг породил вот такое построение интерфейса:
Ничего не напрягает в интерфейсе? Привыкли?) Всё же в порядке, все знакомые «буковки» на виду? Ладно, не буду мучить. Озвучу предположение, что в стране произошёл экономический бум и появилось еще полтора десятка тех, кого называют «маркетплейс». В таком интерфейсе как и куда их добавлять? Лично у меня одной из задач было добавление интеграции с таким «маркетплейсом», как «МагнитМаркет». И куда же надо было девать этого нового контрагента? Хорошо, добавил подменю под названием «прочие маркетплейсы» и уже в него вставил раздел «МагнитМаркет». На мой взгляд так себе, выход. Очередная «костыле-заплата», но куда ж деваться-то было...
В этом месте можно немного остановиться и вспомнить постоянные споры о неких, якобы, преимуществах тех или иных платформ (языков) перед 1С, что есть программисты «настоящие» и «ненастоящие». На мой взгляд пример организации интерфейса работы с маркетплейсами в 1С демонстрирует, что нет никакой разницы в языках, когда речь идёт о «базовых инстинктах» в программировании, применительно к любому языку. Что я имею ввиду. У некоторых народов Южной Америки, «застрявших» в пещерном уровне цивилизации, арифметики ещё нет. В их мировоззрении после понимания «единицы» идёт термин «много». Улыбает, но именно таким подходом приходится регулярно пользоваться при алгоритмизации, когда надо сразу решать — объект гарантированно уникален или нет. Если нет, то в построении алгоритма сразу надо иметь ввиду множество, да ещё с неограниченным размером. Разработчик интерфейса «Маркетплейсы» решил, что в этом «курятнике» все насесты уже распределены и новых имён уже не должно появиться. Новых претендентов будут сбивать прямо на взлёте?) Зачем же так вестись на конъюнктуру и «бетонировать» в коде обычную сиюминутность. Повторюсь, «МагнитМаркет» вот уже появился. А такой гигант электронного рынка, как «Все Инструменты», почему-то сразу проигнорен в конструкции 1С. Стесняюсь спросить — почему? Ниже попробую изложить свои резоны и причины.
Надо начать с самого слова «маркетплейс». Я неслучайно забираю его в кавычки. По простой причине, как в анекдоте про «Вовочку», «...опа есть, а слова — нет». Нормативного толкования слова «маркетплейс» нет, от слова — совсем. Обывательский термин, слово из просторечия, определение из профессионального «арго» для некоторого набора профессий — не более. А что есть? Есть, как и всегда, нормативная база, опираться на которую никак не войдёт в привычку у многих моих коллег, увы. Как мы определяем, чем может заниматься хозяйствующий субъект? А это обязательно стоит сделать на этапе заключения договора с любым контрагентом. Критерий проверки — набор кодов ОКВЭД (классификатор видов экономической деятельности), который имеет каждый хозяйствующий субъект. Для тех предприятий, которые выбрали своей деятельностью, в том числе, торговлю «вне магазина» (через интернет, почту или телевидение), отводится группа ОКВЭД «47.91», где отдельными подпунктами описаны конкретные виды (формы) взаимодействия продавца и покупателя через электронные или иные дистанционные формы коммуникации. В этом месте очень порекомендую найти в Интернете расшифровку этой группы кодов и попытаться запомнить изложенные в расшифровке формулировки, хотя бы на время чтения статьи (если собираетесь её дочитывать). Нет никаких ограничений для любого хозяйствующего субъекта, чтобы иметь такой набор кодов ОКВЭД в своём «пакете». Вывод: тех, кого мы обиходно кличем «маркетплейсами», может быть больше одного, это значит, любое количество. Если осознать этот факт, то как-то сразу «отмирает» необходимость в таком объекте конфигурации, как перечисление «Маркетплейсы», где «отлиты в бронзе» конкретные обиходные наименования, знакомые всем по рекламе. Это само по себе несуразно, т. к. названия торговых марок напрочь не соответствуют наименованиям хозяйствующих субъектов, числящихся под этими вывесками. Содержать в учёте какие-то виртуальные образы, требующие ассоциаций по памяти, так бухгалтерия это не Хогвардс.
Если отбросить собственно, сам технологический способ осуществления продаж (способ доставки товара до покупателя), то в чём же ещё отличие такой торговли от любой другой, где продавец, в лице своего персонала, и покупатель встречаются очно? Простой ответ — ничем. Вышеупомянутые коды ОКВЭД не вносят сами по себе никаких изменений в действующее законодательство и никак его не расширяют. Так чем же занимаются пресловутые «маркетплейсы», применительно к виду сделки? Пришло время вспоминать расшифровки кодов ОКВЭД, где все пункты группы начинаются словами «Торговля розничная». Розничная и никак иначе! Допустим, хозяйствующий субъект что-то производит (или закупает), а продавать решил дистанционно. Это будет торговлей, причём, розничной. А если коммерсант (предприятие) решило торговать не своим, а чьим-то? Для этого существует статья 990 ГК РФ. Называется статья «Договор комиссии» и входит она в раздел IV («Дополнительные виды обязательств») части второй упомянутого кодекса. На этом варианты заканчиваются. Что бы не пытались придумать в договорах между хозяйствующими субъектами, стороны останутся в пределах, описанных в законодательстве. И сколько бы коммерсант не шептал свои желания «чур, у нас нет розничной комиссионной торговли», это не поможет отменить квалификацию ФХЖ, сделанную специалистами ФНС, например. Это касается известного «маркетплейса», который предлагает некий особенный вид договора, при котором создаётся виртуальный «обобщенный покупатель», из-за чего в коде 1С именно этому маркетплейсу посвящается отдельная обработка, разительно отличающаяся от алгоритмов обработки остальных задействованных в конфигурации «маркетплейсов». И да, я точно знаю организации, которые «хапнули проблем» с таким способом (попыткой) использовать в реальном учёте виртуальные миражи и пузыри. Имя «маркетплейса» всуе упоминать не будем по этическим причинам. На программистах не лежит ответственность за отчетность и налогообложение, эту проблему оставим юристам и менеджменту предприятий.
Возвращаясь к вопросу: «А как бы я вёл учёт работы с маркетплейсами?», я ответил бы: «Особенно? Никак!» В интерфейсе 1С и так уже есть документы, позволяющие передать товар комитенту на комиссию, вводить регулярные отчёты по проведённым продажам. На тезис: «Но это же маркетплейсы!» ответ ещё короче: «Ну и что?». Если хозяйствующий субъект передал одинаковый товар двум своим контрагентам, один из которых продаёт полученный товар, как комитент, но очно, а второй контрагент делает то же самое, но через дистанционный способ торговли, то для учёта у комиссионера вообще нет никакой разницы в отражении этих операций. Комиссионера вообще не волнует способ того, как его товар нашёл покупателя, применительно к задачам учёта. Так надо ли что-то отдельное городить? Я сторонник изречения Оккамы, который уже очень давно всячески предостерегал нас от создания лишних сущностей.
На этом мои условные «претензии» к коллегам-разрабочикам компании 1С заканчиваются и носят они характер профессионального спора, не более.
А теперь о том, что уже никак не зависит от разработчиков 1С и адресуется собственно гигантам электронного рынка. К ним вопросы больше и они очень грустные. Интерфейс 1С, посвященный маркетплейсам, решает вопросы электронного взаимодействия с электронными кабинетами, существующими на ресурсах электронных торговых площадок. Пресловутая «интеграция» или «загрузки-выгрузки». И то, как это реализовано, меня просто вымораживает. До такой степени, что однажды написал небольшой текст в адрес одного из «топовых маркетплейсов», в надежде, что до коллег дойдёт мой посыл, но обратной связи так и не возникло. Ещё раз скажу, в самой 1С сделано так, как сделано потому, что иного изделия из предлагаемого «сырья» просто не могло возникнуть. Итак...
Оглашаю вводные условия, допустим следующее. Я — сотрудник бухгалтерии крупной (ну, о-очень!) организации, которая работает со всеми упомянутыми в конфигурации маркетплейсами. Менеджеры зашли в личные кабинеты торговых площадок и накидали мне несколько файлов для импорта. Я приступаю к загрузке этих файлов. Вспоминаем интерфейс, в нём можно выбрать множество (более одного) файлов и программа приступает к попытке их загрузки. С чего начинается попытка? С опознания - чей это файл и что содержит. Вот в этом месте начинается невообразимое с точки зрения логики, алгоритмизации и зачатков здравого смысла. В общем модуле «ЭлектронноеВзаимодействиеБП» есть две функции, отвечающие за идентификацию того, что с большой натяжкой совы на глобус можно назвать «вид документа». С «натяжкой» потому, что никакие виды не формализованы, нигде и никак. Условная «раздача мастей». Итак, что делают эти функции, конкретно? Одна из них ("ОпределитьВидДокументаПоИмениТаблицы(ИмяТаблицы)") пытается установить «вид документа» по (минуточку!) наименованию закладки в листе книги Excell. Апофеоз точности и однозначности! Если завтра появится три-пять организаций, которые назовут закладки в файле Excell одинаково, то система опознавания видов импорта просто в тупик встанет. Ладно, функция не сработала. В дело включается следующая (последняя!) функция ("ОпределитьВидДокумента(ТаблицаДанных)"). Которая (ещё раз, минуточку!!) читает весь табличный документ (любого размера!!) по столбцам и строкам для того, чтобы (вот тут две минуточки!) найти знакомые слова, присущие только этому конкретному «маркетплейсу». Я сначала поверить не мог, что подобный «эвристический анализатор» всерьёз используется в ответственном процессе. Но быстро понял, что я, сам, ничего другого тоже не написал бы. Таков "исходный материал", поступающий в импорт. Представьте, что муниципальный ЗАГС делал бы записи в книгах актов на основании надписей на заборах, типа "Вова людит Машу"? Не надо улыбаться, опознание вида документа, по совпадающим произвольным словосочетаниям по методике и подходам абсолютно аналогичен приведённому примеру.
И опять возвращаемся к спорам о "настоящих или ненастоящих программистах", принадлежащих разным платформам. И в чём разница? Подход, вроде бы напрашивается одинаковый. Если существует импорт файлов с неограниченным заранее размером этих файлов, то всю идентифицирующую информацию надо иметь в первых байтах файла, чтобы не шарить по всему "телу", которое может быть в сотни мегабайт (вдруг!) Всё-таки, разница (настоящих и ненастоящих) набегает не в платформах, а в базовых представлениях конкретного программиста. Просто ИТ-болезнь какая-то, почти всегда пишется код под "здесь и сейчас", под быструю диктовку конкретного заказчика. А что произойдёт через месяц и у другого заказчика? А через месяц мы будем переписывать. Каждая рыбка Гуппи умеет видеть перспективу и планировать процессы в размере длины своей памяти, не более. Круг замыкается на констатации "нам очень не хватает программистов!". С таким подходом их очень долго будет "не хватать").
Попробую посмотреть на процесс интеграции со стороны самого "маркетплейса". Прежде всего вопрос - А зачем так концентрироваться на пресловутом Excell? Да, визуальное представление информации удобно и привычно... для неболшого объема информации. Какой-нибудь ИП, работающий с электронной площадкой, вполне удовлетворён, рассматривая две-три строчки своих "обменов". Да ему вручную "переколотить" эту информацию никакого труда не составит! А что предлагает "маркетплейс" для крупных (очень крупных) контрагентов, объем обменов с которыми, составляет тысячи (иногда - многие!) строк. В этот момент уже совершенно не важно, какой красивый заголовок создан в файле обмена, как красиво прописаны значки процентов в поле "Ставка НДС" и прочие оформительские приблуды. Нужна быстрая и предсказуемая интеграция, а не ребус-квест, как это было совсем недавно, когда один "маркетплейс" в файле импорта всего лишь изменил заголовок одной из колонок. Соответственно, этих данных получать не удавалось, геморрой возник из "ничего", а оно того стоило? Хочется спросить коллег из "плейсов": "Вы что-то слышали о XML, JSON? Не? Попробуйте! Вам может понравиться. Принимающей импорт стороне точно "зашло" бы. А пока вся информация импорта считывается исключительно в символьном представлении с последующей попыткой преобразования значения в нужный тип. Что там на курсах 1С говорят про избыточное применение конструкции "Попытка-Исключение"? А-а! "Это - другое...")
Огромное количество содержания курсов, семинаров, программ обучения, просто профессионального общения программистов, базируется на почти аксиоме "мы сначала встречаемся с бизнесом и он рассказывает нам - что делать". Я вершиной квалификации ИТ-команд назвал бы способность разработчиков сначала создать продукт, а потом предлагать его заказчику. Самонадеяно? В абсолюте - да) Но, если серьёзно, то для создания фундаменталных алгоритмов для работы с теми же "маркетплейсами" точно можно обойтись без тесного общения с бизнесом. Надо уметь (учиться!) работать с нормативной документацией. А там, где не хватает нормативов, учиться их создавать самим и делать общеупотребимыми. Это я сейчс говорю про протоколы обменов, например. Ни один бизнес никогда вам таких протоколов не опишет, он просто не должен уметь это делать. А что сделает бизнес? Он впихнёт программистов в ту парадигму, к которой привык сам, т.к. другим инструментарием просто не владеет: "Наши девочки привыкли к Excell, вот вы нам все в нём и сделайте!" И программисты, привыкшие писать "под диктовку", послушно иполняют. Вот такой результат и имеем в итоге. Достаточно кратного увеличения количества "маркетплейсов" (в два-три раза, хотя бы), чтобы текущая конструкция интеграции стала ещё более громоздкой и несуразной, сложной в обслуживании и доработке. Когда разработчик должен водить пальчиком по табличному файлу и искать фразы и тексты, присущие конкретному документу конкретного "маркетплейса". Будет время, прочитайте в Интернете описание термина "Пантофельная почта". Это очень похоже.
Что можно было бы сделать? Можно кому-то стать модератором. Той же компании 1С или Инфостарту, а может кто-то из "маркетплейсов" напряжётся. Создать протокол обмена через стандартный общеприменимый протокол, условно, XML. Выложить в доступность структуру импорта, приложить файл XSD схемы. Хорошая идея вполне приживётся и распространится без всякого принуждения. Более того, этот обмен не только "маркетплейсам" пригоден. Как уже написано выше, это просто комиссионная торговля и подобный стандарт обмена радостно использовали бы все комитенты, независимо от способа и технологии своей торговли.
Я уже не жду от профессиональных законодателей создания таких механизмов, там давно разучились создавать подобное. В июле этого года родили некий Федеральный Закон № 289-ФЗ от 31.07.2025 "Об отдельных вопросах регулирования платформенной экономики". Сам факт создания закона "об отдельных вопросах" говорит о "мастерстве" законотворцев). Закон создан после массовых публичных конфликтов владельцев ПВЗ, контрагентов с одним из "маркетплейсов". В такой ситуации качественные законы вряд ли получатся, а уж ожидать подзаконных актов в виде рекомендуемых протоколов обмена - это за гранью мечты)
Вступайте в нашу телеграмм-группу Инфостарт