Форум

Добрый день.

Может кто-то разбирался более подробно с обменом и подскажет возможность реализации?

Надо, чтобы в рамках одного сеанса обмена с 1с, событие [B]OnSuccessCatalogImport1C[/B], обработалось только один первый раз, остальные обрабатывать не надо.

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

Была мысль сделать на событии [B][COLOR=#00a650]OnCompleteCatalogImport1C[/COLOR][/B], но оно поддерживается, судя по описанию, только модулями от 6.5.0.0 и выше, не подходит.

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

Буду признателен за комментарии.

[QUOTE]Александр Денисюк написал:
Теперь в конце выгрузки товаров из 1С - отсылается запрос сайту, что обмен товарами завершен. В свою очередь доработано событие OnCompleteCatalogImport1C, позволяющее повесить обработчик, после загрузки всех товаров и информации по ним. [/QUOTE]
Добрый день!
КАК добавить эту отсылку в модуль 6.0.3.4  для КА?

[QUOTE]Дмитрий Чебыкин написал:
Подтверждаю проблему.[/QUOTE]
Уже не подтверждаю.
Проблема оказалась в перегрузе сервера  не заблокированным поисковым ботом, а по времени совпало с обновлением торгового каталога, вот я и решил что проблема в БУС.

[QUOTE]Александр Денисюк написал:
Или может у вас флаг уникальной версии товара был снят, а после обновления модуля, по каким то причинам установился..[/QUOTE]
Можно по-подробнее про этот момент и про кнопку "Настройка версионности" - что означает простановка чекбоксов там (сейчас все пустые).
Модуль 6.0.3.4, не обновляю я его, много доработано в 1с в нем, чтобы он стал нормально работать. И на нем загрузка стала медленнее.
6.5++  и выше не ставил никогда. Проблема не в 1с, движок БУС стал медленнее переваривать.

Подтверждаю проблему.
Время выгрузки увеличилось в 2-3 раза. Версия модуля для 1с - 6.0.3.4
Менять допиленный 6.0.3.4 на версии 7++ нет желания.
Что-то поменяли на стороне сайта скорее всего (в модуле торговый каталог например), что обмен номенклатурой стал в разы длиннее и затратнее по ресурсам.

[QUOTE]Дмитрий Чебыкин написал:
[QUOTE] b7music написал:
DETAIL_PICTURE битрикс берет из локального каталога, по дефолту. [/QUOTE]
Скорее взять то ее можно хоть откуда, только сохранит он картинку для элемента инфоблока в локальной файловой системе по своим правилам, а в базе данных для DETAIL_PICTURE запишет  путь к этой картинке относительно корня сайта.[/QUOTE]
Небольшое дополнение к  теме.

Есть возможность хранить картинки для всего сайта или для отдельных модулей, например для модуля инфоблоков, на удаленном сервере, когда используются  Облачные хранилища (стандартный функционал Битрикс, кроме Первого сайта).  В админке и в публичной части, ссылки будут на облачное хранилище. В таблице b_file видимых изменений нет при этом, т.е. также прописывается относительный путь внутри upload. А картинки отдаются с облака. На облаке "зеркалится" папка upload c подкаталогами.

Подключил в качестве эксперимента Selectel как облачное хранилище, перенес 4 гига картинок туда, стоимость хранения, по сравнению с Таймвебом просто смешная.

Ну и не совсем понятно, как влияет на СЕО, когда сайт работает по https, а картинки с товарами отдаются с другого домена  и по http.

[URL=https://dev.1c-bitrix.ru/api_d7/bitrix/sale/events/order_special.php]https://dev.1c-bitrix.ru/api_d7/bitrix/sale/events/order_special.php[/URL]

OnSaleOrderCanceled

[QUOTE]Александр Денисюк написал:
Насколько я знаю, нигде не афишировалось, что одна интеграция может поддерживать сразу пачку сайтов.[/QUOTE]
Модуль допускает создание неограниченного количества настроек обмена. Проверки и блокировки на то, что идет запрос к разным сайтам -  нет. В явном виде нигде не указывается о проблеме "одинаковых ИД" у заказов. Это "косяк".
Синхронизация заказов "в лоб" по ИД  - это уровень архитектуры для студента 3 курса, изучающих информатику факультативно.[QUOTE]Александр Денисюк написал:
Спорить не вижу смысла[/QUOTE]
Это не спор. Тут спорить не о чем, я прав на все 100.
Вы же не спорите с тем что 2+2 = 4 в классическом понимании этого выражения.

[QUOTE]Александр Денисюк написал:
если бы вы знали все нюансы.[/QUOTE]
Опять 25. Вот если бы в БУС  знали все нюансы как люди работают в реальных условиях, не было бы проблем.  Как я понимаю, во вселенной Битрикс - всегда только один сайт, только одна конфигурация 1с и обмениваются документами они только друг с другом. Наличие других информационных систем, с которыми бы могла обмениваться 1с, не предполагается.[QUOTE]Александр Денисюк написал:
О проблеме известно, когда дойдет очередь - поправим. Есть более серьезные доработки, которые просят многие.[/QUOTE]
Я ж не против, дорабатывайте. Отдаю вам должное в том, что не сдаетесь даже под железобетонными аргументами и находите время отвечать на вопросы. Господина Волошина тоже приглашайте на чтения этой ветки, поскольку все проблемы обмена с 1с ногами растут из архитектуры, закладываемой в БУС. А 1с как среда, в которой можно что-то запрограммировать, так как тебе надо - по сравнению с БУС - небо и земля, если правильно использовать.
[QUOTE]Александр Денисюк написал:
Причем и сейчас можно обойти проблему[/QUOTE]
Да можно, можно. +100000 к нумерации заказа добавить (рецепты есть в открытом доступе), чтоб у клиента в глазах от цифр рябило, а владелец магазина получал реальное количество заказов из этого шестизнака путем пересчета.

[QUOTE]Александр Денисюк написал:
Макс длина = 40 символам. Длина сайта, в теории, может больше 40 символов
[/QUOTE]
Александр, я удивляюсь с вас, как вы воспринимаете написанное. Причем тут длина сайта, имя сайта было предложено в качестве первоначального варианта, и потом доразвито в процессе обсуждения до уникального случайного b_guid, сгенерировать случайные 40 символов хотя бы в 16-ричной системе - уж наверное сообразят программисты на стороне Битрикса. [QUOTE]Александр Денисюк написал:
А потом будете писать, модуль не работает, куча настроек. Проходили уже. Нужно наоборот отказываться от лишних флажков и тд.  Посмотрим, может что и придумаем..[/QUOTE]
Вы передергиваете. Вся возможная "не работа" модуля связана только с подходом -  "что и как передаем в 1с из БУС и обратно". Вы защищали архитектуру Отгрузок и Оплат, я вам сказал, что у удачной архитектуры не будет кучи настроек. Если архитектура неудачна, появляются заплатки, костыли и донавески к логике, которые выливаются в кучи настроек и галочек. В этом случае от флажков никуда не денешься. Состыковывать заказы по ИД - пример неудачной архитектуры. Ее и предлагается заменить, сделали бы изначально правильно -  не пришлось бы дорабатывать.

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

А b_guid сделать не так уж и сложно и это рабочий вариант.

[QUOTE]Александр Денисюк написал:
2) По commerce ML есть формат, где длина кода определенной длины. С вашим форматом длина может быть больше
[/QUOTE]
Непонятный аргумент. 1c как-то пишет эти guid в commerce ML, а БУС почему-то не сможет. Я b_guid от руки набросал, показать что это случайное уникальное число для разных заказов.[QUOTE]Александр Денисюк написал:
1) Проблема не с новыми интеграциями, а со старыми. Если сделать по вашему, то нужно делать совместимость о старыми, а там все сложно.
[/QUOTE]
Александр, это не столько "по-моему", сколько идеологически правильно.

Нет проблемы со старыми интеграциями. Галку в настройки "Использовать для обмена заказами поле b_guid" (на стороне БУС и на стороне 1с - т.е. две настройки), старые пользователи так и будут по ИД, остальные по b_guid.

Подчеркиваю ,что b_guid ДОБАВЛЯЕТСЯ, как поле в таблицу MYSQL b_sale_order и как тег в файл обмена заказов - надо добавить в проверку условие типа IF ($USE_BGUID) и подсовывать в имеющийся механизм нужное значение. Но это никак не  "переписывать весь обмен".

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

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