Артем Шипулин (Все сообщения пользователя)

В УТ 11 это поле "Соглашение"

https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=131&LESSON_ID=10199

Цитата
Соглашение - отбор по выгружаемым соглашениям товаров, и, соответственно, ценам товаров. Соглашения выгружаются только типовые с признаком Доступно внешним пользователям и незаполненным реквизитом Сегмент партнеров;

В настройках узла обмена в форме условий отбора надо указать отбор по типу цены, в котором указать только одно значение с типом сравнения "Равно"

Цитата
Ошибка импорта метаданных.В редакции Малый Бизнес нет возможности иметь более одного типа цены. Настройте выгрузку из 1С или перейдите на другую редакцию БУС.

Собственно вот ошибка

Выложите лог обмена.

Т.к. кеш формируется в том числе и на основе параметров компонента, то используйте ID города, полученный через модуль определения города, в качестве кастомного параметра компонента catalog.element в файле element.php комплексного компонента catalog.

Цитата
Евгений Макаров написал: Цитата Артем Шипулин  написал: Как минимум надо так: Код     global     $arrFilter  ;   $arrFilter   =   array  (  "ACTIVE"   =>   "Y"  ,   "PROPERTY_ACCOUNT"   =>   "Y"  );   Не работает!

Не обратил внимание, что фильтр по списковому свойству, тогда у 2 варианта:
Если у свойства несколько значений и нужен фильтр по значению конкретного значения, то:

Код
$arrFilter   =   array  ("ACTIVE"   =>   "Y"  ,   "PROPERTY_ACCOUNT_VALUE"   =>   "Конкретное текстовое значение");

Если значение у свойства одно, то можно так, как сделали вы:

Код
$arrFilter   =   array  (  "ACTIVE"   =>   "Y"  ,   "!PROPERTY_ACCOUNT"   =>   false  );

Как минимум надо так:

Код
global $arrFilter; $arrFilter = array("ACTIVE" => "Y", "PROPERTY_ACCOUNT" => "Y");

Код этой ошибки выдается при несоответствии сумм к оплате, пришедшей от кассы и взятой из документа оплаты.

Вот часть кода (/bitrix/modules/sale/handlers/paysystem/yandex/handler.php) в модуле "Интернет-магазин" версии 16.5.7, отвечающего за проверку сумм и формирование кода ошибки, в случае их несоответствия.

Код
if ($this->isCorrectSum($payment, $request)) {    $data['CODE'] = 0; } else {    $data['CODE'] = 100;    $errorMessage = 'Incorrect payment sum';    $result->addError(new Error($errorMessage));    PaySystem\ErrorLog::add(array(       'ACTION' => 'checkOrderResponse',       'MESSAGE' => $errorMessage    )); }

Код
private function isCorrectSum(Payment $payment, Request $request) {    $sum = $request->get('orderSumAmount');    $paymentSum = $this->getBusinessValue($payment, 'PAYMENT_SHOULD_PAY');    return PriceMaths::roundByFormatCurrency($paymentSum, $payment->getField('CURRENCY')) == PriceMaths::roundByFormatCurrency($sum, $payment->getField('CURRENCY')); }

Цитата
Евгений Александрович написал: Надеюсь это правильное решение =)

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

Цитата
Евгений Александрович написал: Что делал: Контент>Инфоблоки>Типы инфоблоков>Каталоги>Свойства для поля Доп. изображения добавил в "Типы загружаемых файлов" svg.

Это для свойства "До.изображения" ЭЛЕМЕНТОВ инфоблока, но на левой части вашего скрина видно, что вы пытаетесь добавить svg в поле РАЗДЕЛА инфоблока.

В вашем случае возможен только вариант использования пользовательских полей http://dev.1c-bitrix.ru/user_help/settings/settings/userfield_edit.php

В общем проще через soap обмениваться данными по заказам, чем пытаться завести этот функционал в модуле обмена.

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

Кто-нибудь нашел решение данной проблеме?

P.S. Пробовал вариант, когда стоимость комплекта = стоимость всех его комплектующих, а после создал скидку на этот комплект, но при обмене итог абсолютно такой же.

В общем, как я понял, единственный вариант - кастомизация модуля обмена.

Всем привет.

1. На сайте есть 2 эквайринговых способа оплаты - через PayPal и через карты Visa/MasterCard.
2. На стороне 1С созданы 2 договора эквайринга для каждой из оплат, и проставлены в настройках узла обмена в таблице способов оплат, загруженных с сайта http://prnt.sc/cyat0k и в таблице настройки загружаемых документов следующая картина http://prnt.sc/ct86g8
3. В процессе обмена документами в логе есть следующая ошибка:

Не заполнено значение реквизита "Вид оплаты"!
В документе выбран вид оплаты неверного типа

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

С реализациями все понятно - в модуле обмена не ставим соответствующий чекбокс, а вот с оплатами не ясно

Приветствую.

Вводные данные:

1. УТ 10.3 с модулем обмена 6.0.3.4
2. БУС "Бизнес" со всеми последними стабильными обновлениями
3. Способы оплаты на сайте:
   3.a PayPal
   3.b Visa/MasterCard (эквайринг от ВТБ24)
   3.c Оплата картой курьеру
  3.d Наличный расчет
  3.e Банковская квитанция
  3.f Счет

Необходимы следующие схемы создания и обмена документами:

I. Заказ с оплатой PayPal или Visa/MasterCard
   I.a Заказ был оплачен до ближайшего обмена с 1С, то в ней создаются только документы заказ покупателя и оплата
   I.b Заказ не был оплачен до ближайшего обмена с 1С, то в ней создается только документ заказ покупателя, а документ оплаты создается только после того обмена, непосредственно до которого он будет оплачен на сайте.
  I.c Реализация создается всегда на стороне 1С и при ближайшем обмене ее данные обновляются у соответствующей отгрузки на сайте.

II. Заказ с остальными типами оплаты
  I.a В ближайший обмен с 1С, в ней создается только документ заказ покупателя
  I.b Оплата создается всегда на стороне 1С и при ближайшем обмене ее данные обновляются у соответствующей оплаты на сайте.
  I.c Реализация создается всегда на стороне 1С и при ближайшем обмене ее данные обновляются у соответствующей отгрузки на сайте.

Может кто-то уже реализовывал такие схемы и может поделиться своим опытом насколько это реализуемо в рамках имеющегося функционала модуля обмена и БУСа, а если без допиливания невозможно, то возможно сможет дать советы по реализации?

А вы остальные поля в профиле обмена заполнили?

А вы создавали новый заказ после того, как прописали данные в профиле обмена?
В том плане, что проверять передачу контрагента имеет смысл на тех заказах, которые еще на выгружались в 1с-ку

У вас заполнены поля "Полное наименование" и "ФИО агента" (для обоих типов плательщика) на странице /bitrix/admin/1c_admin.php?lang=ru поля на вкладке "Профили обмена"?

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

1С:Предприятие 8.3 (8.3.8.1784)
Управление торговлей, редакция 10.3 (10.3.37.4)
Модуль обмена 6.0.3.1
Битрикс - "Малый бизнес" со всеми стабильными обновлениями

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

Дерево групп создано, номенклатура создана, а вот тип цены и соответственно документ установки цен в разрезе характеристики (SKU) не создаются, импорт запускал несколько - итог одинаковый.

Цитата
VKuser24387635 написал: Всем привет! Есть УТ 11.2 и интернет магазин битрикс. на сайте уже есть товары. в УТ тоже есть товары, между собой базы никак не синхронизированы. Можно ли сопоставить товары, не заменяя их?

А есть ли какой-то признак у товаров на сайте и в 1С, который бы однозначно их сопоставил?

Цитата
Александр Денисюк написал: Цена на характеристику выгрузится только тогда, когда она установлена для этой характеристики.

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

При регистрации через компонент main.registrer для непосредственного создания нового пользователя используется метод http://dev.1c-bitrix.ru/api_help/main/reference/cuser/add.php в котором НЕ делается отправка писем по шаблону USER_INFO.



Шаблон USER_INFO используется:



1. При создании/редактировании пользователя через админку с установленным параметром "Оповестить пользователя"

2. В компоненте main.profile

3. При восстановлении/изменении пароля

4. В методе CUser::SimpleRegister



В вашей ситуации есть несколько вариантов решения:



1. Для системного типа почтового шаблона NEW_USER добавить еще один почтовый шаблон с нужным текстом и в качестве значения "Кому" указать #EMAIL#

2. Добавить обработчик для одного из событий http://dev.1c-bitrix.ru/api_help/main/events/onafteruseradd.php или http://dev.1c-bitrix.ru/api_help/main/events/onafteruserregister.php в котором делать вызов метода CEvent::Send с шаблоном USER_INFO

Присоедняюсь к данному вопросу