Форум

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

[QUOTE]Алексей Сипаев написал:
Спасибо и предполагал,что рассказывать не стоило, ибо понимания не будет, потому что это важно только мне[/QUOTE]
Пожалуйста... подумал, что по каким-то причинам, вы хотите убрать информацию в ИД, потому что тогда она доступна для просмотра внутри 1с только по "спецправам", а остальное вам не надо, чтобы приходило в 1с в "явном" виде. Тогда да, тут скорее специфичная задача, чем кейс общего применения.

[QUOTE]Александр Денисюк написал:
не будем досконально  настраивать кейсы, т.к. это долго[/QUOTE]
Александр, не вижу пользы от таких вебинаров. Гораздо лучше pdf файл  с четко разделенными "кейсами" и скриншотами настроек для каждого кейса и конфигураций 1с. А если вы снова будете на ходу тестировать только на УТ в режиме "галопом по европам", как это было с 6.5.0.0, то сто лет такой вебинар не нужен.

Писал ранее тут же в ветке [URL=https://dev.1c-bitrix.ru/community/forums/messages/forum26/topic65679/message473265/#message473265]ссылка[/URL] :

Скрытый текст

От Битрикс хотелось бы увидеть не вебинар в стиле "в 2014 году мы отменим интернет и будет только битрикс24". Нужны типовые сценарии применения настроек обмена в 1с и в БУС для разных ситуаций. ........ [COLOR=#555c69]Когда есть сценарии настроек для разных вариантов взаимодействия 1с -БУС, становится понятно, что авторы продукта проработали свое решение, а не с потолка взяли. А когда только кино, то становится понятно совсем другое. [/COLOR]

[QUOTE]Александр Денисюк написал:
т.к. это долго[/QUOTE]
Можно мы вам тоже будем не сразу деньги за лицензию перечислять, поскольку зарабатывать их приходится долго?

Более того, если "это долго" (речь идет о простановке галочек!!!) - то у вас однозначно ошибка в архитектуре решения (не обмена, а самого БУС), повторяться не буду, вот мой [URL=https://dev.1c-bitrix.ru/community/forums/messages/forum26/topic65679/message482999/#message482999]пост[/URL] по этому поводу.
Дополню его тем, что сейчас у вас вместо нормальной связки "Интернет-магазин - учетная система", получается плохо работающая "Публикация документов из учетной системы на веб-сайте". Но по большому счету, проблема не в обмене с 1с, а в "оплаченных оплатах" и "отгруженных отгрузках". Надеюсь у вас не появится что-то вроде "обмененного обмена" или еще какой лингвистической находки.

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

Все равно непонятно, к чему залезать в формат файла обмена, если вам нужна информация о тех данных, которые содержатся в профиле пользователя. Можно эти данные выгружать отдельно и импортировать в 1с в какой-либо справочник.  "Много информации"??? - я думаю добавление в тег ИД каких-то дополнительных данных, особо не уменьшит передаваемую информацию. Да и зачем собственно "расширять" этот тег, если в профилях обмена можно задать самому дополнительные свойства к выгружаемым в 1с заказам, в которых выгрузить все то, что вы хотите добавить в ИД. Короче, не смог уловить цели, зачем расширять содержимое ИД, если это можно выгрузить отдельным свойством к заказу? В чем профит?

Сам тег ИД похоже формируется в функции ExportContragents , в файле \bitrix\modules\sale\general\export.php в строке примерно 1820

Скрытый текст
<<?=CSaleExport::getTagName("SALE_EXPORT_ID")?>><?=htmlspecialcharsbx(substr($arOrder["USER_ID"]."#".$arProp["USER"]["LOGIN"]."#".$arProp["USER"]["LAST_NAME"]." ".$arProp["USER"]["NAME"]." ".$arProp["USER"]["SECOND_NAME"], 0, 80))?></<?=CSaleExport::getTagName("SALE_EXPORT_ID")?>> <?endif;?><?

Можете подправить файл, перед строкой формирования тега определив по $arOrder["USER_ID"] нужные вам данные из пользовательских и изменив содержимое тега.

А при обновлениях иметь ввиду, что файл будет переписываться, придется переносить дополнения.

Да, теперь понял, в ИД  - информация  из данных о пользователе. Ну это надо лезть в исходники экспорта заказов, посмотрю, а вам для какой цели такие изменения, если не секрет?

Сходу могу предположить, что настраивается это в профилях обмена на стороне БУС.
ВнутреннийИдентификаторПользователя будет всегда, а остальное настраивается.
[URL=https://i.imgur.com/lUMrlLl.png][IMG WIDTH=350 HEIGHT=162]https://i.imgur.com/lUMrlLl.png[/IMG][/URL]

[QUOTE]Минаев Дмитрий написал:
Заменить руководителя направления "Интеграция с 1С" в компании 1С-Битрикс[/QUOTE]
Оригинальное использование сайта идей!

Если быть справедливым, то еще и того, кто решил привнести в Битрикс [B]Оплаты и Отгрузки, [/B]бездумно скопировав эти сущности из одной очень широко известной в узких кругах CMS для интернет-магазинов (Magento), да еще с таким несуразным переводом и логикой применения.

Логичнее все же было назвать [B]Способы оплаты [/B](в контексте возможности принимать платежи через различные каналы, в том числе и одновременно через разные системы оплаты в рамках одного заказа) и [B]Отправления[/B] (именно в контексте логистики, а не документов реализации в учетной системе).

Ну и должна быть у заказа [B]третья сущность[/B] - [B]Платежный баланс, в котором должны отражаться фактически выполненые платежи, [/B]вот в него то и можно было выгружать документы фактических оплат из учетной системы (1с), учитывая их в балансе по своим правилам (например, это может быть способ учета комиссии, или если клиент оплатил в офисе сразу несколько заказов - одним приходником и т.п.). А в самом заказе, предлагаемые [B]Способы оплаты [/B]должны учитывать текущий [B]Платежный баланс [/B]по данному заказу. В том плане, чтобы нельзя было оплатить больше, чем того требует [B]Платежный баланс.
[/B]Таким образом - Способ оплаты - это сущность, которая ВСЕГДА НЕ ОПЛАЧЕНА, поскольку это лишь способ перевода недостающей суммы для сведения Платежного баланса заказа к состоянию "Заказ оплачен полностью".
Поступившие платежи - это поступившие платежи, а не "Оплаченная Оплата", как придумали разработчики БУС. [B]
[/B]
Ну и если уж так хочется показывать покупателю какие-то документы прям какие они есть в  1C и нагружать обмен еще и этой информацией (привет Александру Денисюку и неизвестному автору Оплат и Отгрузок) , то должна быть [B]четвертая сущность[/B] - [B]Дополнительная информация, [/B]в нее можно грузить все остальное, что придет в голову - документы реализации, документы оплаты, информацию из каких-то справочников, фотографии груза перед отправкой, и прочее.
И не надо смешивать понятия Отправления (покупателя интересует как к нему доставляется его груз, т.е.реквизиты груза - ТК, трекер для отслеживания, на какого получателя отправлен и т.п.) и документ Реализация в 1с.

Но для этого надо думать и серьезнее относится к тому, что делаешь, и желательно до выпуска в паблик решений[B].[/B] И не считать покупателей БУС идиотами, а разработчиков продукта этакими небожителями. Вы берете немаленькие деньги за свой продукт и при этом не только не в состоянии самостоятельно продумать архитектуру решения, но еще и скопировать нормально у систем-аналогов не можете. А сейчас создаете темы "Кейсы применения 1с и БУС". Хотя совсем незадолго до этого на вопрос - "а вы вообще тестировали вашу логику обмена?" был ответ из разряда "все отлично, и по плану, и те у кого все отлично с обменом не пишут на форумах"....детский сад.

Вобщем, пока в БУС есть вот эти [B]два шедевра программистской и лингвистической мысли - "Оплата - Оплачена" и "Отгрузка - Отгружена"[/B] - никакие примеры кейсов и создаваемые по этим кейсам костыли проблему не решат.

[QUOTE]CCatalogProduct::Update($ID,$ProductFields)
[/QUOTE]
для события OnAfterIBlockElementUpdate возможно правильнее внутри обработчика вот так вызывать

CCatalogProduct::Update([B]$arFields['ID'[/B][B]][/B],$ProductFields)

Вот еще один [URL=https://dev.1c-bitrix.ru/community/webdev/user/17090/blog/12425/]кейс[/URL], в котором к тому же объясняется, почему не работают события при изменениях элемента через админку. Буду знать благодаря автору и вашей теме. Если верить автору кейса о работоспособности, то вам можно присмотреться к его обработчику, только изменив логику на изменение-задание веса, а не цены.

А затронутая автором кейса тема зацикливания обработчиков событий хорошо раскрыта в этой [URL=https://dev.1c-bitrix.ru/community/blogs/vws/looping-event-handlers.php]статье[/URL].

[QUOTE]Юрий Крохмаль написал:
CCatalogProduct::Update возвращает true, но вес все-равно не меняется блин[/QUOTE]
[QUOTE]Юрий Крохмаль написал:
CCatalogProduct::Update($ID,$ProductFields);[/QUOTE]
В лог вынесите $ID и $ProductFields, может в $ProductFields пустое значение, а событие отрабатывает на самом деле.

Ну а просто в скрипте срабатывает или нет?
[CODE]if (CModule::IncludeModule("catalog")){
 
$arFields = array('WEIGHT' => 111);
 
CCatalogProduct::Update(11, $arFields);
}[/CODE]