В общем, кому интересно. Мне не давала покоя тупая проверка параметра запроса, поэтому сделал очистку фиктивной скидки в позициях корзины через обработку OnSaleBasketBeforeSaved.
|
Покуда я разобрался эта галка "Запомнить меня на этом компьютере" по непонятной причине не срабатывает в публичной части, а в админке (если авторизоваться через /bitrix/...) более-менее работает. (Не работает и в админке, если авторизуешься с галочкой на втором домене одного ядра - слетает запомненная авторизация на первом домене, но это понятно - на разных доменах разный SESSION_HASH.)
А вот почему в публичной части похоже только активирует функцию "Продлевать сессию при активности посетителя в окне браузера", хотя по идее должна работать аналогично админке. По сессиям явных отличий не увидел, но без документации сложно что-то разобрать. UPD. Проблема может быть, если шаблон авторизации не выдает куки с хэшем пароля, столкнулся с этим на ajax авторизации в решении dw. Вот здесь про это написано: |
|
|
|
|
|
Надоело ждать ТП, явно не дождусь. Короче вчера сделал костыль для печати чеков в заказах без отгрузки.
Событие OnSaleCheckPrepareData вызывается при подготовке чека. Если отсутсвует подмассив 'PRODUCTS', определяем его сами из корзины заказа.
|
|||
|
|
|
|
У нас БУС, настроенный на обмен с 1С. При поступлении онлайн-оплаты через модуль Интернет-эквайринг Тинькофф от Павла Шулаева настроена печать чеков через кассу с обработчиком "Касса 1С".
После последнего (примерно полугодового) обновления стала появляться такая ошибка: "Ошибка при создании чека: пустой список товаров в отгрузке" "Ошибка при создании чека: сумма по чеку не совпадает с общей суммой товаров" Таким образом БУС жалуется, что при создании чека, когда поступает онлайн-оплата банковской картой, не указывается отгрузка. Но на момент оплаты отгрузки для этого заказа может не существовать (так как она импортируется из 1С и обычно создается уже после оплаты). Приходится создавать чеки по появлению отгрузки. Поотслеживал событие OnSaleCheckPrepareData. Когда все нормально, передается вот такой массив:
А когда отгрузки нет, то полностью отсутствует подмассив [PRODUCTS], что и соответствует ошибке. Обратился в ТП, но уже скоро неделю, как не отвечают по этому вопросу. Появились обновления для модуля ИМ, но пока не ставил, ТП даже на их счет не спешит ответить. UPD: Обновление не помогло. Есть вариант попробовать в обработчике дописывать недостающий PRODUCTS из корзины заказа, но не факт, что заработает. По идее это должно быть в базовом фукнционале - нет реализации, но поступила полная оплата - печатаем чек на весь список товаров. Еще вариант вероятно более правильный, генерировать чек при появлении отгрузки (видимо по событию OnSaleShipmentReserved), но не понятно как правильно генерировать чек вручную (исходники не читал, а в мануалах этого нет). В общем, очень не хочется писать костыли для того, что и так должно работать (и работало). Может быть настройка какая есть? |
|||
|
|
|
|
В общем, если кому понадобится, написал такие обработчики. Пришлось разбираться с D7, опять лезть в исходники, потому, что классические обработчики уже не работают как надо. Обрабатываю события сохранения корзины и сохранения заказа (скидки за купоны в объект корзины записываются только при сохранении заказа).
Функция recalcBasketKitSets считает сумму комплектующих и сравнивает с ценой комплекта, и исправляет то или иное в пользу покупателя. Если на комплект назначена скидка, она распределяется на комплектующие. Приходится менять BASE_PRICE комплекта, поскольку в корзине (стандартном компоненте sale.basket.basket) выводится именно она, плюс похоже корзина на каждом хите норовит обновить цены товаров в соответствии с каталогом. Возможно нужно как-то пользоваться провайдерами, но в мануале про это нет, а я не ОО-архитектор.
|
|||
|
|
|
Проблема присутствует до сих пор. При выгрузке сумма заказа идет с ценой ("скидкой за опт") на комплект, но товарные позиции заказа выгружаются со своими "розничными" ценами. То есть после полного цикла обмена с 1С покупатель при прочих равных увидит возросшую сумму заказа, если комплект дешевле комплектующих. Но эта ситуация - видимо отражение того, что в заказе цены комплектующих никак не пересчитываются и так же выгружаются. По хорошему надо при обмене заказами пересчитывать их. |
|||
|
|
|
|
Всем привет!
Внедряю импорт комплектов из 1С через стандартный обмен. Данные обрабатываю обработчиками. В процессе импорта некоторые товары на этапе OnBeforeIBlockElementUpdate из простых становятся комплектами (на основании значений доп. реквизитов). Соответственно на этапе OnBeforeProductUpdate, если устанавливается количество товара, мне нужно проверять, то, что этот товар не является комплектом. Иначе вычисленное для комплекта значение наличия затирается передаваемым из 1С значением (нулем), а костылить модуль 1С (Денисюка) не хочется. Но проверять, есть ли у товара комплект (CCatalogProductSet::getAllSetsByProduct - самый быстрый способ) придется для половины товаров (на этапе импорта остатков). Думал, хранить IDшники комплектов в сессии, но сессия почему-то обновляется при каждом запросе 1С к Битриксу (тестовый обмен на ограниченном количестве товаров, занимает менее минуты). ЧЯДНТ и можно ли этого избежать? Тестирую на VMBitrix5.1, может быть в этом дело? Или дело в 1С? |
|
|
|
|
|
Столкнулся с проблемой по теме ветки, которая не имеет однозначного решения, может быть кто-нибудь подскажет, как лучше действовать.
Начну с предыстории, еще недавно стоял модуль 6.0 и БУС был соответствующей версии. Статусы заказов на сайте синхронизировались по 1С и статус "Закрыт" соответствовал статусу "F" в БУС. Но так как Закрыт может быть и отмененный заказ, у в БУС был сделан обработчик события, который вместо проведения заказа в статус "F" отменял его, если у заказа в БУС не стояли флаги оплаты и отгрузки. И все работало. В 1С заказ переходит в состояние Закрыт автоматом, или может быть закрыт менеджером сразу после получения единомоментной оплаты и отгрузки. И таким образом к очередной выгрузке (даже очень частой) заказ подходит в состоянии Закрыт со всеми оплатами и отгрузками сразу. Сейчас же при обмене БУС сначала обновляет заказ и его статус в том числе, и потом дописывает документы оплаты и отгрузки. Соответственно мой обработчик сразу отменяет заказ, после чего, понятно, оплаты и отгрузки в БУС к нему больше не подвязываются. Клиенты в недоумении, получая извещение об отмене заказа, после его оплаты. ![]() Если отключить обработчик, то в БУС возникают две проблемы, но не столь критичные:
Со стороны БУС пока не могу помыслить нормального решения, только всякие корявые с отслеживанием по регламенту готовых к закрытию/отмене заказов, но это трэшовые варианты, которые будут приводить к повторному обмену заказами без реального обновления (или и это как-то пресекать). Со стороны 1С можно попробовать сделать автозакрытие по регламенту с задержкой, чтобы заказ успел обновиться в плане оплат/отгрузок. И/или запрещать закрытие заказа вручную не выдержав определенную паузу. |
|
|
|
|
|
3-й момент. Еще неплохо бы тримировать значение ИНН и КПП контрагента при загрузке заказов - лишние пробелы частое являение. Смех в том, что стандартными средствами это нельзя сделать ни в 1С, ни в БУС (ну разве что в через обработку событий). В БУС есть регулярные выражения проверки свойств заказа, но они (пока судя по поведению) проверяют тримированные строки, а в заказ записываются исходные.
|
|
|
|
|
|
Запустил современный модуль с обновленным БУС на продакте, повылазили еще мелкие проблемы.
1. Во-первых, по оживленному обсуждению с руководством решили, что идентифицировать контрагентов нужно чисто по ИНН, поскольку КПП может поменяться (а в базе остается старый) или просто быть не заполненным при заказе (а просто так сделать его заполнение обязательным тоже нельзя из-за ИПшников, для них бы пришлось вводить еще один тип плательщика). Вероятность работы с двумя филиалами одной компании у нас оценивается как очень низкая, а возможные проблемы обмена как несущественные. Поэтому мне пришлось править модуль и добавить еще вариант идентификации "ИНН" - чисто по ИНН. В нашем случае идентификация для юр.лиц это ИНН->ВнешнийИД, для физ.лиц это ВнешнийИД->ИНН. ИНН для физ лиц нужен, так как ИПшники тоже идентифицируются по этому пути, хотя на сайте оформляются как юр.лица. 2. Второй недочет. Думаю, что ВнешнийИД должен определяться не просто по XML_ID пользователя, а с учетом ID профиля (профайла) покупателя. Точнее лучше добавить такой отдельный вариант этапа идентификации, чтобы можно было построить цепочку ИДПрофайла->ИДПользователя->ИНН для физ.лиц и ИП. Иначе пользователь с одним аккаунтом на сайте, но разными юр./физ.лицами в заказах может выгружаться в одно юр./физ. лицо в 1С, что ведет к глюкам при исправлении. Вряд ли это частая проблема, но тем не менее, она обнаружилась очень быстро и видимо обнаружится еще. Отключение многопрофильности покупателя помочь НЕ должно - можно профиль просто так исправить, или, если работает автоматическая авторизация, новые профиля создаются автоматом. UPD. К сожалению, без правки модуля Sale в последнем случае не обойтись. Хотя, через обработчики обновлять при каждом новом заказе XML_ID пользователя можно... |
|
|
|
|
|
Настраиваю (пытаюсь сделать все без правки модуля) обмен на последних весиях (в УТ и БУС).
В Б_ОбменССайтомСерверЗагрузкиДанных в функциях ПолучитьСпособДоставки и ПолучитьПеревозчика:
Поэтому загружаемый "Отпуск товара" значения реквизитов Способа доставки и Перевозчика в Реализацию не передает, хотя информацию такую содержит аналогично документу заказа. В результате Реализация не проводится, а если заполнить фиксированным значением, не проводится Заказ клиента из-за несоответствия реквизитов доставки... Вижу выход пока - заполнить значения для Реализации алгоритмически. Это косяк или как-то по другому нужно настроить? Вообще это поведение УТ неправильное, ведь если у заказа несколько реализаций, то они должны иметь возможность иметь различные способы доставки. |
|||
|
|
|
|
по непонятным причинам не срабатывало на одной машине, перенесенной с VMW на HV (и до этого уже переносившейся между хостами). Интерфейс почему-то не определялся не смотря на явное указание IP-шника.
По какой-то причине помог переход на dhcp. То есть прописал BOOTPROTO=dhcp прямо в ifcfg-ethX, после чего заработало. UPD. Причиной, судя по всему, был конфликт IPшников. |
|
|
|
|
|
Добрый день всем и Александру!
В норме все разделы выгружаются из номенклатуры 1С как есть. Но потребовалось завести пустой раздел (группа номенклатуры), который наполняется елементами по вторичной привязке (по событиям из значений реквизитов). Пустые разделы, как все знают, модулем не выгружаются. Хочется чтобы они там создавались для удобства наполнителей. Варианты, которые я предполагаю: Решить можно по простому - засунуть какой-нибудь товар в такой пустой раздел. Но это не красивое решение и юзерам объяснять надо. Решить через настройку Дерева Групп можно, но тяжело в плане наполнения и поддержки, да и XML_ID нужно будет сверять. Найти в модуле место, где идет проверка на пустоту групп и закомментить его. Может быть есть что-то более правильное и красивое решение? |
|
|
|
|
Сейчас посмотрел 7.0.0.0 - ошибка на месте. Но до этой функции, похоже редко, когда доходит. |
|||
|
|
|
|
В модуле Б_ОбменССайтомСерверЗагрузкиДанных до версии 6.5.0.1 включительно есть, насколько я понимаю, ошибка:
|
|||
|
|
|
|
Столкнулись с тем, что вдруг в тестовой базе запустилось регламентное задание на обмен с сайтом не смотря на стандартную блокировку копии. Я-то в тестовых базах всегда вручную отключаю регламентные задания и меняю адрес сайта на тестовый. Но тестовые копии делаю не только лишь я.
|
|
|
|
|
Стонота: править модуль интеграции - ужас (нужен хороший специалист), а обновлять БУС это ужас-ужас, похоже проще сделать свой подхват оплат. |
|||||
|
|
|
|
Добрый день всем и Александру! Извиняюсь за, наверное, весьма устаревший вопрос.
Правильно ли я понял, что загружать с сайта оплаты заказа (и отгрузки) можно только с 15-й версии модуля Интернет магазина, где эти сущности введены. То есть по флагам оплаты/отгрузки в загружаемом заказе модуль для 1С никаких документов (в 1С) создавать не будет? Или я что-то недонастроил? Более того, сейчас на тесте обновил версию модуля на 6.5.0.1 с 6.0.3.1 и заказы с БУСа с модулем магазина 14-й версии вообще перестали падать. Это так и должно быть, устаревшая версия? |
|
|
|
|
|
Еще проще - вставить эти определения в шаблон(ы) нужного(ых) компонента(ов). Я как-то стараюсь делать так, чтобы потом можно было поправить через UI. А это, кстати, можно удобно (для администратора) организовать через параметры шаблона компонента.
Но такие решения в то время, когда балерины большого театра бороздят просторы открытого космоса... |
|
|
|
|
|
Хочется использовать в публичной части сокращения для типов цен наравне с полными названиями. К сожалению, пользовательских полей для этих объектов не предусмотрено.
У меня вариантов:
|
|
|
|
|