Евгений Шекин (Все сообщения пользователя)

По хорошему вообще на сайте не нужно хранить ни остатки ни цены. И может даже не картинки. А идентификатор товара в 1С. Название, описание - так сказать чтобы товар этот найти.

Далее все должно сугубо срабатывать из запросов к 1С онлайн. Зашел в карточку - произошел реалтайм получения данных из 1с.
Открыл страницу с десятком товаров - запрос к 1с по этим позициям.

А тут своя какая то автономная база и бесконечные обмены.  

Просто сложилось ощущение. Что обмен просто опирается на информацию на сайте. Хотя фактически основа это 1С. Как истинная картина остатков на момент заказа.

Ну оно и понятно.... потому что с текущей схемой обмена... и его невероятно медленной работе - трудно что то иное.
Эта вся схема полностью устарела и не отвечает действительности....

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

На текущий момент должен быть чуть ли не реалтайм, максимально функциональный и связанный. И рассчитанный на то что с учетом современных реалий - когда вся логистика дошла до уровня что подавляющее большинство работает под заказ и торгует со склада поставщика. А значит массово грузят десятками тысяч остатки поставщиков. Все это должно отрабатывать за секунды. И неоднократно в день даже.

Я изучал загрузку заказов - он вообще не смотрит остатки в базе. И не смотрит в принципе ничего.  например в УТ11 - там свободные, есть заказы поставщикам которые заказаны. Множество различных статусов. Это все не учитывается.

Также еще изучаем способы обхода самого обмена.

Потому что в 1С загрузить прайс в 20 000 товаров с ценами и остатками - выходит по времени 20 секунд.
Обмен выгружает все это 30 минут! На таком смешном объеме данных.

В общем мы отказались от схемы

Загрузка картинок в 1С - Выгрузка картинок на сайт.

Мало того что 1С их скачивала 1 час, а выгрузка почти 4 часа!

Написали программу для самого Битрикс. Которая проверяет товары и сама скачивает картинки по ссылкам.

Для этого в 1С вместо картинок загружаем текстом ссылки и епереквидываем вместе с номенклатурой на сайт в виде скрытого свойства.

Скрипт автоматически проверяет товары и свойства и скачивает, устанавливает детальные и анонс картинки, а также заполняет галерею.

Как итог вместо 6 часов с 1С и обменом, 15 000 картинок на сайте заполнились за 13 минут.

Ну надо как то. Бизнес уже годами этого ждет. Пока еще такой остался.... если и его не останется то интернет-торговля окончательно вымрет в пользу маркетплейсов, которые очевидно используют технологичные решения.
Единственный вздох который может помочь бизнесу - это начать что то пересматривать.

У меня большая просьба к разработчикам. Создать базу. Я могу вам накидать десятки или сотни реальных файлов.

И проведите весь цикл. И делайте его каждый день.
Как эт делают ежедневно сотни или тысячи клиентов. А не делайте тесты на 100 товарах. И даже не 500. И вы увидите какой это ужас. Как все медленно работает.

Нету сейчас фирм у которых 500 товаров на сайте. Иначе им и Битрикс не нужен был.  

Просто хочу напомнить одну вещь. Сейчас 2026 год. Электронная коммерция. Все поставщики обмениваются прайсами. Это десятки и сотни тысяч строк.

У меня из 300 клиентов нет ни одного кто бы руками заводил что то в 1С. У всех прайсы, каталоги. Грузят массово. Это значит что в обьемы попадают большие данные. И цены и остатки. И каталоги большие. Есть и с картинками немало.

После изучения обмена у меня сложилось мнение что весь он написан из расчета 20 летней давности. Все рассчитано на ручной ввод и что изменений происходит мизер. Но это не так.

Те же самые картинки. Расчитано на физические файлы. Люди вынуждены их качать, набивать базу 1С. Выгрузку делать физических файлов. Хотя сейчас это ссылки. Они даже в 1С никому особо не нужны. Все это делают исключительно для сайта.

Так почему нельзя просто на сайт передать свойство с текстовыми ссылками, пусть сам Битрикс видя это подгружает картинку в товар по внешней ссылке.  

И еще я вчера сделал полный цикл от А до Я  . в связке 1С + Битрикс
https://dev.1c-bitrix.ru/community/forums/forum26/topic164222/

И получил катастрофические результаты. Я создал базу, полноценный каталог с ценами, остатками, картинками. И получил ситуацию что 90 процентов времени из 6 часов ушло на картинки....

4 часа происходил обмен. Это в 4 раза больше чем в саму 1С они попали (хотя по факту в саму 1С они загружались 3 минуты).

Из всей выгрузки 70 процентов логи показывали что в 1С делается выборка. Т.е. в районе 3 часов просто формировались запросы. И всего то на 20к товаров.

Друзья! Проблема с регистрацией регистров сведений в новой версии не решена.

Напомню в 1С появились методы (параметры) записи в регистры сведений с параметром РежимЗаписи. Изменение, Слияние, Добавление, Удаление.

Модуль Битрикса использует Булево в параметрах. Из за его ошибка!

Глобальный модуль БУС_РегистрацияИзмененийВызовСервера.

Процедура ЗарегистрироватьИзменения(Источник, Замещение = Ложь) Экспорт

Сразу могу сказать. Что на мой взгляд это конечно ужас. Что в 2026 году обмен работает так медленно. И что из за каких то картинок все это превратилось из 5 минут. в 7 часов....


В 1С причем (если без картинок) уходит несколько минут.


Главный вопрос в этом все один. Зачем и почему до сих пор людям нужно загружать картинки в 1С чтобы потом их выгружать на сайт. и меть такие тормозища.... Кстати даже без картинок 20 000 выгрузка цен и остатков - 30 минут это много.

На каждый пакет выгрузки в 500 элементов который длился 3-4 минуты 70 процентов времени что то там обмен думал над созданием пакета.

Главный момент. Если у нас есть ссылки (текст ссылок). То почему в Битриксе нет возможности что если мы с товаром при обмене передали ссылки, чтобы он сам взял и скачал эти картинки и назначил. Это сразу целиком удалит громадную и невероятную по масштабам проблематику.

• База 1С Управление торговлей с установленным Мегапрайсом. Настройка с сайтом заняла ориентировочно 30 минут.
  
• Прайс размером 20 000 товаров. 60 колонок, в нем есть цены, остатки, картинки.
  
• Настройка прайса заняла 5 минут. Указал базовые поля - группу, артикул, наименование, цены, остатки, картинки. Дополнительно сгенерировал описание из первых 15 колонок.
  
• Чтение и подгрузка синхронизированного прайса заняло 20 секунд. Но номенклатуры нет в базе.
  
• Создание номенклатуры в 1С заняло 10 минут.
  
• Загрузка картинок - самое сложное. Каждая картинка ссылка. Это 20 000 ссылок. Загрузка картинок делится в два этапа. Сначала они все скачиваются на диск. Заняло 1 час из за огромного количества ссылок (забыл включить многопоточность).
  
• После скачивания - загрузка картинок в саму 1С с привязкой к товарам - 3 минуты.
  
• Повторно подгрузил прайс чтобы проверить синхронизацию всего прайса. 20 секунд.
  
• Загрузка цен и остатков в 1С - 2 секунды!
  
• ГОТОВО. Все действия для 1С полностью выполнены. В ней полный каталог, цены, остатки, картинки прайса в 20 000 товаров (округлил). 99 процентов времени заняло первичное создание номенклатуры + скачка картинок + загрузка их в 1С.
  
• Запуск и полная выгрузка на сайт. Выгрузка будет полной (так как первичная) и выгружаться будет все. Товары, картинки.
  
• Модуль выгрузки выводил мне окно процесса выгрузки, в котором я увидел что выгрузка происходит пакетами по 500 строк, каждый пакет 3-4 минуты. Ориентировочное время 2 часа. Это значит что полная выгрузка 20 000 товаров с картинками, ценами и остатками из 1С займет в районе 120 минут. В процессе выгрузки товарами пачками уже стали появляться на сайте.
  
• Выгрузка завершена. Полное время выгрузки 3 часа 30 минут.
  
• Повторная выгрузка. Было проведено изменение цен у всех 20 000 товаров и подгружены снова остатки. Выгрузка-загрузка произошла за 30 минут.
  
• PS  Я не сразу заметил, так как прайс особо не изучал. В нем есть количество товаров без остатков, которые можно было пропустить. И в обмене я не задал условие фильтра. Поэтому в загрузку и выгрузку попало абсолютно все. Но моя задача была откатать весь объем. А уже все остальное - дело утонченных настроек.
  
• По ссылке демо-сайта вы увидите результаты обмена в полном виде.
  

Итоги

• Самой большой проблемой оказались картинки. На них ушло 99 процентов всего времени! Полная загрузка прайса в 1С, с ценами и остатками занимается секунды. На втором месте - полное создание номенклатуры. И невероятно большое время - картинки. В них вся соль. Посмотрев на эту ситуацию ко мне пришла идея, которую пока озвучивать не буду. Но если она реализуется (возможно с помощью ИИ) это создаст прорыв в этой задаче!
  
• Произвел эксклюзивную демонстрацию выгрузки виртуальных остатков поставщиков, которые были загружены в 1С без использования документов и штатной базы 1С. Использовался функционал Мегапрайс + модифицированный модуль обмена.
  

Чувствую себя идиотом. Второй час не могу настроить склад и цену для выгрузки в Малый бизнес. Цену вроде настроил. Обмен не ругается. На сайт не выгружает.

Склад настроил - не выгружает.

8 лет прошло а проблема все таже. Только уже новый обмен и 1С. И ничего не разобраться. В документации ноль по этому поводу.

Там абсолютно ничего не контролируется. Нет контроля изменений. Ничего.

Просто любая запись по регистру какая бы она не была - совершает регистрацию в таблицу изменений и соответственно в пакет выгрузки.

И еще вечный косяк. Ужасный просто.

Модуль обмена отслеживает опять таки по подписке записи регистра Доступность товаров, ранее это был регистр Распределение товаров.

Это регистры которые полностью отвечают зы выгружаемые остатки. И модуль обмена пихает в пакет выгрузки абсолютно все записи, даже не проверяя изменилось там что или нет. Просто любое проведение по этому регистру - моментально ставит в выгрузку абсолютно все.



И вообще я посмотрел что там творится - это просто катастрофически не оптимизированный код. Он там такие ужасные выборки делает при этот отслеживании что просто в 100 раз замедляет работу всей штатной программы.

Не отслеживается абсолютно ничего точно. Просто напалмом шарашит. Я вам поясню - основные пользователи 1С + Битрикс, компании которые ежедневно к себе в базу тащат десятки и сотни прайсов с десятками тысяч товаров. Проценяют, загоняют остатки в базе.

Но дело в том что при любых раскладах там нет 100 процентных изменений всего. Да могут меняться цены на части позиций, меняться остатки. Но не на все.

Простая ситуация. Компания обновляет остатки по данным поставщика на 10000 товаров. Они делают это в 1С через приход.
Как делают? Снимают с проведения прошлый приход, делают новый.

В данном случае модуль обмена ДВАЖДЫ совершит регистрацию для выгрузки на сайт. Один раз при снятии документа на 10000 товаров, второй раз поставит эти же 10000 товаров в регистрацию обмена.

При этом там вообще может быть что остатки изменились всего на 100 строк.

Я уже вам предлагал - что текущая структура обмена Битрикс с 1С катастрофически не доработана.  Отслеживание через подписки "Перед записью" - совершенно не правильный подход.

Просьба исправить баг в новом обмене.

При записи дополнительных свойств и сведений. В модули битрикс стоит подписка на отслеживание изменений в регистрах сведений.

Так вот там в параметрах стоит РежимЗаписи, который у вас все время сравнивается с Истиной или Ложью.

Но дело в том что 1С уже давно поддерживает что этот параметр может быть иметь типы записи.

Изменение, слияние, замещение, удаление.

Обмен не учитывает это и использует лишь старые типы Истина и Ложь. Из за этого выдаются ошибки расширением обмена.

Хотя скорее всего. Надо уволить руководителей отделов. Или поменять собственника. На более рвущегося к тому чтобы что то развивать.

Странные сообщения конечно. Не нравится - уходите. Прелесно такое читать))

Да и уйдут.

На фоне еще кризиса эффект усилится. Если компания ставит крест, и даже такие сообщения являются нормой - не нравится, никто не держит. Ну так оно и произойдет.

Место того чтобы наоборот наверстывать и что то делать, да лучше ж ничего не делать)

В БУС ничего не развивается по реальным потребностям бизнеса, зато в Б24 наделали никому не нужных конструкторов сайтов и лендингов.

На админку нашли кучу средств - полностью переписать весь интерфейс. На админку!

У Битрикса каждый год (почти) запускается массовая реклама с заголовками "полет в космос" и так далее.. Супер новая версия.

СЕйчас вот уже 26 версия!! Помню с 15 версии каждый год анонсировали супер новую версию, красивые баннеры! Заголовки с какими то новейшими возможностями, приглашение на участие в мероприятии...

Маркетинг полным ходом! А потом оказывается что 20-21-22-26 версия.... изменений ноль.  Ну отключите тогда рекламу и выпуск новых версий. А то так до 150 версии ноль изменений, зато маркетинг хлопает в ладоши.

И да деньги на маркетинг судя по всем выделяются огроменные. На это они есть.

Поговорим?

Я правильно понимаю что сейчас при загрузке с сайта заказов в 1С обмен от слова совсем не просматривает в 1С ничего - есть ли остатки на складе (а может даже и не только на складе заказа), есть ли заказы поставщику в пути. И никакого автодействия в зависимости от этого не совершает от слова совсем.

Особенно если компания имеет смешанную торговлю - часть со склада, часть под заказ. Многие компании виртуально грузят остатки поставщиков в свои базы (делают виртуальные склады и приходы) лишь бы на сайт выгружать эти остатки под видом что этот товар можно продать (заказать).

При этом с этих виртуальных складов в 1С естественно нельзя ничего делать, нужно чтобы склад подменялся при загрузке. Чтобы проводился анализ и правильно автоматическое событие - резерв, обеспечить, отменить....

К этому еще бы добавил что модуль обмена желает лучшего. Если каждый день грузить на 50 000 (а есть и 300 000) товаров каталог - остатки поставщиков, цены записывать. То там модуль обмена без какого либо контроля изменений ставил все на выгрузку при любой записи регистра доступные остатки (ранее это был распределение запасов).  Люди в ужасе когда у них в 1С документы эти проводятся часами, обмены тоже часами идут.

Там абсолютно ничего не контролируется. Нет контроля изменений. Ничего.

Просто любая запись по регистру какая бы она не была - совершает регистрацию в таблицу изменений и соответственно в пакет выгрузки.

И еще вечный косяк. Ужасный просто.

Модуль обмена отслеживает опять таки по подписке записи регистра Доступность товаров, ранее это был регистр Распределение товаров.

Это регистры которые полностью отвечают зы выгружаемые остатки. И модуль обмена пихает в пакет выгрузки абсолютно все записи, даже не проверяя изменилось там что или нет. Просто любое проведение по этому регистру - моментально ставит в выгрузку абсолютно все.



И вообще я посмотрел что там творится - это просто катастрофически не оптимизированный код. Он там такие ужасные выборки делает при этот отслеживании что просто в 100 раз замедляет работу всей штатной программы.

Не отслеживается абсолютно ничего точно. Просто напалмом шарашит. Я вам поясню - основные пользователи 1С + Битрикс, компании которые ежедневно к себе в базу тащат десятки и сотни прайсов с десятками тысяч товаров. Проценяют, загоняют остатки в базе.

Но дело в том что при любых раскладах там нет 100 процентных изменений всего. Да могут меняться цены на части позиций, меняться остатки. Но не на все.

Простая ситуация. Компания обновляет остатки по данным поставщика на 10000 товаров. Они делают это в 1С через приход.
Как делают? Снимают с проведения прошлый приход, делают новый.

В данном случае модуль обмена ДВАЖДЫ совершит регистрацию для выгрузки на сайт. Один раз при снятии документа на 10000 товаров, второй раз поставит эти же 10000 товаров в регистрацию обмена.

При этом там вообще может быть что остатки изменились всего на 100 строк.

Я уже вам предлагал - что текущая структура обмена Битрикс с 1С катастрофически не доработана.  Отслеживание через подписки "Перед записью" - совершенно не правильный подход.

Просьба исправить баг в новом обмене.

При записи дополнительных свойств и сведений. В модули битрикс стоит подписка на отслеживание изменений в регистрах сведений.

Так вот там в параметрах стоит РежимЗаписи, который у вас все время сравнивается с Истиной или Ложью.

Но дело в том что 1С уже давно поддерживает что этот параметр может быть иметь типы записи.

Изменение, слияние, замещение, удаление.

Обмен не учитывает это и использует лишь старые типы Истина и Ложь. Из за этого выдаются ошибки расширением обмена.