Форум

Апну сюда.

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

А вид ограничителей, возможно зависит от настроек PHP.

[B]3-й момент.[/B] Еще неплохо бы тримировать значение ИНН и КПП контрагента при загрузке заказов - лишние пробелы частое являение. Смех в том, что стандартными средствами это нельзя сделать ни в 1С, ни в БУС (ну разве что в через обработку событий). В БУС есть регулярные выражения проверки свойств заказа, но они (пока судя по поведению) проверяют тримированные строки, а в заказ записываются исходные.

Запустил современный модуль с обновленным БУС на продакте, повылазили еще мелкие проблемы.

[B]1. Во-первых,[/B] по оживленному обсуждению с руководством решили, что идентифицировать контрагентов нужно чисто по ИНН, поскольку КПП может поменяться (а в базе остается старый) или просто быть не заполненным при заказе (а просто так сделать его заполнение обязательным тоже нельзя из-за ИПшников, для них бы пришлось вводить еще один тип плательщика). Вероятность работы с двумя филиалами одной компании у нас оценивается как очень низкая, а возможные проблемы обмена как несущественные.

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

[B]2. Второй недочет.[/B] Думаю, что ВнешнийИД должен определяться не просто по XML_ID пользователя, а с учетом ID профиля (профайла) покупателя. Точнее лучше добавить такой отдельный вариант этапа идентификации, чтобы можно было построить цепочку ИДПрофайла->ИДПользователя->ИНН для физ.лиц и ИП.

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

UPD. К сожалению, без правки модуля Sale в последнем случае не обойтись. Хотя, через обработчики обновлять при каждом новом заказе XML_ID пользователя можно...

И еще ПолучитьПеревозчика явно не до конца переделанная из ПолучитьСпособДоставки:

[CODE]Если НайденныйСтатус <> Неопределено тогда
Результат = НайденныйСтатус.Служба;
КонецЕсли;[/CODE]

[CODE]Иначе
Результат = Документ.[U]СпособДоставки[/U];[/CODE]

Настраиваю (пытаюсь сделать все без правки модуля) обмен на последних весиях (в УТ и БУС).

В [I]Б_ОбменССайтомСерверЗагрузкиДанных[/I] в функциях [B][I]ПолучитьСпособДоставки[/I][/B] и [B][I]ПолучитьПеревозчика[/I][/B]:

[CODE]Если ДокументXML.ХозОперация = "Заказ товара" тогда...[/CODE]

Поэтому загружаемый "Отпуск товара" значения реквизитов [B]Способа доставки[/B] и [B]Перевозчика[/B] в [I]Реализацию[/I] не передает, хотя информацию такую содержит аналогично документу заказа. В результате [I]Реализация[/I] не проводится, а если заполнить фиксированным значением, не проводится [I]Заказ клиента[/I] из-за несоответствия реквизитов доставки...

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

[URL=https://dev.1c-bitrix.ru/support/forum/messages/forum32/topic71467/message384723/#message384723]Решение резюмированное Тимуром[/URL] по непонятным причинам не срабатывало на одной машине, перенесенной с VMW на HV (и до этого уже переносившейся между хостами). Интерфейс почему-то не определялся не смотря на явное указание IP-шника.

По какой-то причине помог переход на dhcp. То есть прописал [I]BOOTPROTO=dhcp[/I] прямо в [I]ifcfg-ethX[/I], после чего заработало.

UPD. Причиной, судя по всему, был конфликт IPшников.

Добрый день всем и Александру!

В норме все разделы выгружаются из номенклатуры 1С как есть. Но потребовалось завести пустой раздел (группа номенклатуры), который наполняется елементами по вторичной привязке (по событиям из значений реквизитов). Пустые разделы, как все знают, модулем не выгружаются. Хочется чтобы они там создавались для удобства наполнителей.

Варианты, которые я предполагаю:

Решить можно по простому - засунуть какой-нибудь товар в такой пустой раздел. Но это не красивое решение и юзерам объяснять надо.
Решить через настройку Дерева Групп можно, но тяжело в плане наполнения и поддержки, да и XML_ID нужно будет сверять.
Найти в модуле место, где идет проверка на пустоту групп и закомментить его.

Может быть есть что-то более правильное и красивое решение?

[QUOTE]Александр Денисюк написал:
вродь поправлено уже[/QUOTE]

Сейчас посмотрел 7.0.0.0 - ошибка на месте. Но до этой функции, похоже редко, когда доходит.

В модуле [I]Б_ОбменССайтомСерверЗагрузкиДанных[/I] до версии 6.5.0.1 включительно есть, насколько я понимаю, ошибка:[CODE]Функция ПолучитьСоглашение(ПараметрыОбмена, ЮрФизЛицо,ДокументXML)
   
   Если ЮрФизЛицо = Перечисления.ЮрФизЛицо.ФизЛицо И ЗначениеЗаполнено(ПараметрыОбмена.КонтрагентФизлицо) тогда    
       Возврат ПараметрыОбмена.КонтрагентФизлицо;    
   КонецЕсли;
   
   лСоглашение = Справочники.СоглашенияСКлиентами.ПустаяСсылка();
   
   Возврат лСоглашение;
   
КонецФункции[/CODE]Явно вместо [I]КонтрагентФизлицо[/I] должно быть [I]СоглашениеКонтрагентаФизлицо[/I].

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