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

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

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

Да и уйдут.

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

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

В БУС ничего не развивается по реальным потребностям бизнеса, зато в Б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С уже давно поддерживает что этот параметр может быть иметь типы записи.

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

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

Еще красивее будет в регистр ОстаткиНаСайте добавить реквизит регистр ВыгрузкаИстина (к примеру).

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

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

Более того!! В подписке на регистрацию. регистра БУС_ТаблицаПроверкиОбъектовНаВыгрузкуВРежимеРеальногоВремени­

можно будет запрос приложить запрос сравнения. Т.е. проверяем - а изменился ли остаток между регистрами Распределение + Остатки на сайте.
И если нет тогда не делаем запись!
Это избавит множественные записи в регистр изменений в случае беспорядочных перепроведений или проведений которые не меняют остатки. А значит существенно снизит нагрузку на систему - будет меньше записей в регистр, меньше позиций попадет в обмен.

А значит ускорит и оптимизирует систему значительно!!!! Так что как ни крути добавление регистра ОстаткиНаСайте несет только пользу.

Это будет сказка! Убиваем все проблемы, получаем контроль регистрации, меньше дерганья регистров, существенное ускорение обмена. Т.к. теперь на всех шагах система не будет ничего делать если остатки в базе и между сайтом не изменились!! Красота!

Почему не ложится? Реалтайм это вы называете то что подписка на записях регистра? Которая делает записи в БУС_ТаблицаПроверкиОбъектовНаВыгрузкуВРежимеРеальногоВремени­ ?

Ну так вы к этой схеме можете оставить и этот регистр и подписку. НО в чем будет плюс! И кстати очень хороший. Как раз контрольный.
Тогда из этого регистр в сравнительный запрос обмена отправится отбор по объектам. И если там не обнаружится изменений то некоторые позиции выпадут.

Т.е. по факту эта схема добавит контроль в результате беспорядочных записей в БУС_ТаблицаПроверкиОбъектовНаВыгрузкуВРежимеРеальногоВремени­ , которые могли не вызвать изменения остатков.

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

Так что вполне себе и эта схема уладывается по реалтайму.

Актуализироваться она будет после загрузки на сайт. Т.е после выполнения обмена. Дозаписываем в регистр то что выгрузили.

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

Запросом сравнения получем разницу - отправляем в обмен. Снова дозаписываем после успешной загрузки на сайте. Вот как.

На примере, у меня на 150 000 позиций на все сравнение уходят секунды.

ТекстЗапроса =
"ВЫБРАТЬ
| ТаблицаМегапрайс.Номенклатура КАК Номенклатура,
| ТаблицаМегапрайс.Характеристика КАК Характеристика,
| СУММА(ТаблицаМегапрайс.МегапрайсКоличество) КАК МегапрайсКоличество,
| СУММА(ТаблицаМегапрайс.ВНаличииОстаток) КАК ВНаличииОстаток
|ИЗ
| (ВЫБРАТЬ
| РаспределениеЗапасов.Номенклатура КАК Номенклатура,
| РаспределениеЗапасов.Характеристика КАК Характеристика,
| 0 КАК МегапрайсКоличество,
| СУММА(РаспределениеЗапасов.ВНаличии) КАК ВНаличииОстаток
| ИЗ
| РегистрСведений.РаспределениеЗапасов КАК РаспределениеЗапасов
| ГДЕ
| РаспределениеЗапасов.Склад = &ВиртуальныйСклад
| И РаспределениеЗапасов.Состояние = ЗНАЧЕНИЕ(Перечисление.РаспределениеЗапасовСостояния.ОстатокНаСкладе)
|
| СГРУППИРОВАТЬ ПО
| РаспределениеЗапасов.Номенклатура,
| РаспределениеЗапасов.Характеристика
|
| ОБЪЕДИНИТЬ ВСЕ
|
| ВЫБРАТЬ
| ЦеныНоменклатурыСрезПоследних.Номенклатура,
| ЦеныНоменклатурыСрезПоследних.ХарактеристикаНоменклатуры,
| СУММА(ЦеныНоменклатурыСрезПоследних.Количество),
| 0
| ИЗ
| РегистрСведений.мегапрайсЦеныНоменклатурыПоставщиков КАК ЦеныНоменклатурыСрезПоследних
| ГДЕ
| ЦеныНоменклатурыСрезПоследних.ПрайсПартнера.ВиртуальныйСклад = &ВиртуальныйСклад
| И НЕ ЦеныНоменклатурыСрезПоследних.Номенклатура = &ПустаяСсылка
|
| СГРУППИРОВАТЬ ПО
| ЦеныНоменклатурыСрезПоследних.Номенклатура,
| ЦеныНоменклатурыСрезПоследних.ХарактеристикаНоменклатуры) КАК ТаблицаМегапрайс
|
|СГРУППИРОВАТЬ ПО
| ТаблицаМегапрайс.Номенклатура,
| ТаблицаМегапрайс.Характеристика
|
|ИМЕЮЩИЕ
| СУММА(ТаблицаМегапрайс.МегапрайсКоличество) <> СУММА(ТаблицаМегапрайс.ВНаличииОстаток)";

Нет. Еще раз нет. Вообще не трогаем документы.

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

Эти отличия выгружаем и записываем после обмена. Т.е. запись регистра вообще всегда делается после обмена.
В нем мы храним слепок выгрузки.

Я такое же использую при загрузке. У меня есть загруженный регистр, когда поступают новые данные - я сравниваю что мне передали с тем что уже в базе. Получаю изменения и их записываю. Логично ведь?

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

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

Кстати почему остатки я считаю нужно выделить.

Обмен Битрикс на 6000 позиций 10 минут.
Я ради эксперимента написал обрабокту - выгрузка остатков. С УИДами, складами, остатками. на 6000 позиций. С передачей на сайт.

Это заняло ровно 2 секунды. Загрузка на сайте через CSV 30 секунд.

Разница в 20 раз!

Я вот специально создал сайт и базу - все тестовое. И сейчас занимаюсь проверкой нагрузки. Могу дать доступ. Результаты с обменом совсем не важные.

6 000 позиций. Обмен с сайтом 10 минут. И это только остатки вашим способом. Если например загружать 6 000 позиций в оприходование. Его проведение в два раза больше обычного с вашей регистрацией.  

Фактически эти 6000 идут в регистр изменений (ваш). А при выгрузке еще будет целый запрос ко всем остаткам по этим же 6000 позициям... Т.е. уже а запросе два регистра. И еще там третий будет с УИДами...
Спрашивается зачем это все? Как я писал выше регистр "Остатки на сайте" этот вопрос бы решил в миг.

Вот сложно это тут писать. ПРоще было бы вживую поговорить. Схему нарисовать.

У ВАС

1) Запись в регистр всех и вся движений. без разбора. Даже групповое перепроведение вызовет записи. И даже прост ов документе что то захотят исправить - комментарий дописать и перепровести - все будет колбасится в регистр. А это постоянные не нужные выгрузки. У вас там по сути контроль на уровне ноль сейчас.
Огромнейшее количество беспорядочных фиксацией изменений и с ними и выгрузки.
2) При запуске обмена вы к этому регистру присоединяете остатки и УИДЫ.
3) Очищаете регистр.

Т.е . на лицо видно что идет постоянная работа с регистром. Что до выгрузки, что после выгрузки..

Что будет, если регистр "Остатки на САЙТЕ"

1) вообще никакой движухи ни по одному стандартному движению от слова совсем.
2) При запуске обмена - запрос к остаткам на складах и остаткам на сайте. Ставим условие ИМЕЮЩИЕ КолСклады <> КолСайт.
Все это - выгрузка на сайт.
После успешной выгрузки - записываем в регистр Остатки на сайте - то что выгрузили. Получили равные регистры.


Далее юзер настраивает задание. Это задание получает запрос к друм регистрам с опять тем же условием. Просто получает разницу. И вот вам то что нужно выгружать...

Вместо 10-20 кратный записей того что происходит у вас, будет 1 раз запись идти. Причем никак не смешанная с типовой, с проведением документов, блокировками, транзакциями которые вызывают типовые документы.

Разница есть?

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

Почему?

Потому что как раз остатки меняются оперативно максимально много раз в компаниях. Одни продают по складов, но большая часть интернет-магазинов кстати это компании торгующий под заказ. Они вообще не имеют складов. Источником информации являются загрузки прайс-листов с остатками. У меня есть клиенты которые грузят 50-100 прайсов поставщиков. С десятками тысяч позиций. Т.е. уже даже без регистрации понятно что изменений вагон и тележка!


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

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

Я бы еще добавил процедуры с параметрами в которые можно передавать конкретный массив товаров.

А вот то что сейчас происходит - а у вас в регистры пишутся данные. Причем я посмотрел даже не наборами.... циклы по 1 строке товара....

По сути я предлагаю это решение, кардинально отличающегося от вашего, по той причине что огромная масса клиентов не имеют своих складов. Те кто делают интернет-магазины получают наличие товаров из внешних источников. И получают их массово. Сразу на тысячи. десятки тысяч товаров.

Для того чтобы им задействовать обмен нужно пройти все регистры что вы понаделали. У вас там даже нет чтобы массово набор записей записывался. Полностью все циклично по 1 строке с товаром.

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

Мое предложение такое. И это новый подход, в отличие от того что у вас десять лет не меняется. даже с выходном новых версий.

1) Убрать целиком то что сейчас у вас творится с регистрацией изменений по остаткам. По сути вы при изменении регистра остатков - начинаете еще делать записи в один свой регистр. Причем в новой версии - вы даже не смотрите статусы которые есть у новых регистров - все считаете изменением, хотя там по факту звериная доля движений вообще не отвечает за изменение остатков.

2) Убрать остатки целиком из вашего регистра слежения. И убрать весь код БУС_ПередЗаписью, который делает двойную запись в регистр БУС.

3) Создать регистр Остатки на сайте. При запуске регл задания (должно быть отдельное на остатки) делать запрос по двум регистрам - остатки на сайте и Распределение товаров (с нужными фильтрами, отвечающими за свободные остатки). Все что разница (по количеству, с этим условием разницей будут и товары и характеристики, склады) - и есть то что необходимо выгрузить на сайт в виде файла по изменениям остатков.

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

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


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

В тот же регистр одновременно в нем хранить УИДЫ, для того чтобы избежать еще соединений. Повторюсь очень много пользователей имеют большие каталоги.

У меня вопрос. Резонный. Зачем нужен еще один регистр хранения УИД.... Совсем печально....
Если в базе 100 000 товаров, а многие клиенты имеют больше 20 000.... То это все дело совсем печальное.

В старом модуле был общий реквизит. Сейчас в расширении новом для УТ11 его убрали.. и создали регистр.

И вообще посмотрел код и модули Битрикса... что то совсем все печально. 100 товаров в базе с сайтом обменивается 10-25 секунд. Сайт у меня на отличном хостинге, а база на компе i9 12900K. Интернет - оптоволокно.

Представить себе не могу когда в базе 20 000 товаров.

Для выгрузки обязательным условием регистрация изменения. Например регистр Распределение запасов. При изменении записей - идет запись в регистр БУС. Т.е. еще одна таблица. При  обмене очистка из регистра БУС.... Короче куча регистров, куча движений. Записи сплошные, очистки и прочее.

У меня из 200 клиентов, половина грузит каждый день прайсы в базу с остатками по 20-50 тысяч строк, есть 150 000 строк. Там остатки. Все их грузят "как свои". Все это должно выгружаться на сайт. Чтобы оно выгружалось - нужно загружать "как стандартные". А там еще ваш регистр...
Измнений остатков дофига...

Вы даже в регистре Распределения запасов не следите что именно там меняется. Потому что там 10 статусов, туда попадает вся движуха - заказы клиентов, всякое обособленное обеспечение, и все прочее. Хотя за свободные остатки вообще один из 10 статусов отвечает. У вас там вообще никакого контроля - все подряд как изменение идет.

Все это превращается просто в монстра.

Вы не думали о том что проще в 1С не мучать регистр изменений - и постоянно его записывать, перезаписывать, удалять и прочее....

А сделать один единственный регистр назвать его Остатки на сайте (и кстати сюда же добавить УИДЫ). Тем самым сократив два регистра в один. Убрать бесконечные двойные записи.
И при запросе обмена просто синхронизировать его с свободными остатками, поставив условие сравнения количеств. Т.е. получим только изменения. И вот эти изменения отправлять и в регистре изменять (ОДИН РАЗ, вместо того что у вас там происходит множество раз).

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

Написал собственную выгрузку из 1С, которая отправляет CSV на сайт.

В разделе Импорт настроил этот файл. CRON  установил, но не устраивает что он запустится по своему времени.

Вопрос - как из 1С после заливки файла вызвать выполнение импорта со стороны сайта.

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

Тема уже не актуальная. С выходом новых конфигураций УТ 11.5 / КА 2.5 и ЕРП.
Там большие изменения.

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

Я тут тему заводил

https://dev.1c-bitrix.ru/community/forums/forum26/topic144088/

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

Я просмотрел новый модуль, правда установил модуль от КА на УТ 11.5.
Очень жду именно для 11.5 так как уже люди ее ставят, многие обновились, а новые клиенты 1С (те которые только начинают использовать 1С) уже тоже ее сразу ставят.
Либо подтвердите что модуль от КА подходит в том числе для УТ. Я думаю что модуль обмена даже для тестовой УТ пора делать.

Да увидел что вы задействовали новый регистр.

Есть замечания.

1) План обмена - макет СхемаВыгрузкиТоваров - вы добавили в запрос регистр РаспределениеЗапасов, но берется ресурс Наличие, нужно Свободно.
2) План обмена - макет СхемаВыгрузкиОбщейИнформации- не изменили запрос, там по прежнему ТоварыНаСкладах.
3) Общий модуль Б_ОбменССайтомСерверВыгрузкаДанных в тексте запроса встречается также регистр ТоварыНаСкладах,
но далее есть обьединение с РаспределениеЗапасов
и на мой взгляд вы там переборщили с текстом запроса. Вы взяли все расчетные данные регистра, хотя там можно было проще взять чисто свободный остаток.

И в итоговом результате запроса почему то

| СУММА(Таблица.ВНаличии) КАК ВНаличии,
| СУММА(Таблица.ВРезерве) КАК ВРезерве
|ПОМЕСТИТЬ ВремДанныеПоОстаткам

Не увидел свободного остатка.

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


Отдельное спасибо также за регистрацию записей в плане обмена с отслеживанием по регистру сведений.

Это перечисление вместе с новым регистром в новых версиях УТ 11.5 КА 2.5 и новой ERP