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

Токен на портале под администратором получали? Настройки выгружаются? В журнале взаимодействий нет ошибок?

Признак «основной счёт» между Битрикс24 и 1С не передаётся ни в одну сторону. Если счёт помечен основным в Битрикс24, при загрузке в 1С этот признак не приходит — счёт создаётся как обычный, а основной в 1С определяется внутри (по последнему загруженному). Именно поэтому счёт «не прощелкивается» как основной, и при следующей синхронизации основной в 1С меняется.

Добрый день! Да в 5.0.0.11 пофиксили

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

Механизм такой: при каждой синхронизации банковские счета контрагента загружаются из Битрикс24 в 1С в том порядке, в котором портал их отдаёт, и без признака «основной» (этот признак по API не передаётся — как вы верно заметили). При этом в 1С основным автоматически назначается счёт, обработанный последним.

Пока порядок счетов на портале не меняется, основным стабильно остаётся один и тот же счёт — поэтому вариант «оба счёта сразу, основной выбран» работает. Но когда вы перещёлкиваете основной счёт в Битриксе, портал переупорядочивает список реквизитов, и при следующей синхронизации последним в списке оказывается уже другой счёт — он и становится основным в 1С. Отсюда и «уезжание» основного счёта в этих шагах.

Обратитесь пожалуйста в тех поддержку

Посмотрите еще в журнале ошибок и в журнале регистрации может там есть ошибки.

Про формулировку «последовательность выгрузки меняется» уточню эта фраза относилась к конфигурациям, где у владельца банковских счетов есть специальный служебный реквизит «основной счёт», и обмен мог автоматически назначить его — но только если основной счёт ещё не был задан. В типовом решении для КА у контрагента такого служебного реквизита, который обмен перезаписывал бы, нет. Поэтому «порядок загрузки счетов» на основной счёт в 1С не влияет. Мой предыдущий ответ был излишне общим — для вашего случая эта оговорка не действует.

В КА/УТ нет реквизита «основной банковский счёт», который загрузка могла бы переписывать. Поэтому при добавлении нового счёта в Битрикс и последующей синхронизации этот счёт создаётся в 1С как обычный.

Реквизита «основной банковский счёт» есть в конфигурациях 1С БП и УНФ. Там логика такая - если загружается новый банковский счет из Б24 в 1С, только тогда меняется основной банковский счет (то есть последний добавленный всегда считается основным). Если новых банковских счетов не создается, то основной не меняется.

Релиз 5.0.0.11 опубликован!

По вопросу банковских счетов: коротко: это ожидаемое поведение — 1С не сбивает основной счёт. Причина в том, как устроен обмен:
Со стороны Битрикс24 к каждому контрагенту может быть привязано несколько банковских счетов, но сам механизм API не передаёт признак «какой из них основной» — в данных обмена приходит только номер счёта, БИК, банк, валюта и признак активности. Признак основного счёта, который проставляется в 1С, из Битрикс24 в принципе не приходит.

Поэтому при каждом обмене действует следующий порядок:

1. Счета, которые уже существуют по номеру, находятся и обновляются.
   
2. Новые счета создаются.
   
3. Если у владельца (контрагента/компании) основной счёт ранее не был задан — он автоматически назначается на первый обработанный счёт при загрузке.
   

То есть 1С не «переключает» основной счёт на произвольный другой: если основной счёт уже выбран в 1С, обмен его сохраняет. Счёт меняется на «последний привязанный» только в ситуации, когда основной счёт в 1С ещё не был выделен либо когда последовательность загрузки счетов меняется — тогда первым загруженным становится другой счёт, и именно он автоматически принимается как основной.

Добрый день! Обе эти ошибки уже исправлены в релизе 5.0.0.11. Только он завис на публикации. Сегодня должен опубликоваться.

Добрый день!

Разобрал ваш феномен — подозрение верное: дело именно в незавершённой двусторонней связке, и причинный механизм такой.

По связке заказа и «http-ссылки Дела в таймлайне каждый раз заново». Связка «сделка ↔ заказ» держится на идентификаторе: в заказ 1С пишется внешний код сделки, а в сделку — ссылка на заказ (Дело). Кнопка «создать заказ в сделке» (интеграция сервисов) создаёт заказ в 1С напрямую, минуя обмен по стадиям — поэтому заказ появляется даже при «н.з.». Но поскольку для этой сделки обмен по стадиям у вас запрещён, обратная часть привязки (запись ID заказа в сделку и постановка заказа к обратной выгрузке из 1С) не завершается. Отсюда два симптома, которые вы видите:

• при каждом сохранении/проведении заказа коннектор «не узнаёт» его в сделке и пытается привязать заново → в таймлайне каждый раз появляется ещё одно Дело;
  
• обратная выгрузка заказ→сделка идёт по стадии, а стадия под «н.з.» → изменения (включая стадии) из 1С не передаются.
  

Чтобы двусторонняя связка была полноценной, сделку нужно один раз прогнать штатным обменом без «н.з.» на её текущей стадии — тогда связка зафиксируется и дальше обновления пойдут штатно. Либо, если ручное создание принципиально, оформить так, чтобы на стадиях, где заказ уже создан, «н.з.» не стояло (только «не обновлять» для существующих), иначе обратная выгрузка закрыта.

По парадоксу «не обновлять + н.з. на 1-й стадии → заказ не создаётся». Это не ошибка, а особенности трактовки: «н.з.» на стадии означает не только «не обновлять», но и «не создавать» заказ для сделок этой стадии. Поэтому, чтобы заказ создавался на 1-й стадии, на ней «н.з.» ставить нельзя. А защиту от перезаписи уже существующих заказов даёт отдельная настройка «не обновлять для существующих заказов» — она с созданием на 1-й стадии не конфликтует.

Итого по вашим трём инструментам:

• «н.з.» на стадии — жёсткий стоп обмена по стадии (и на создание, и на обновление); блокирует обратную выгрузку.
  
• «не обновлять для существующих» — защищает уже созданные заказы от перезаписи, но создание на стадиях без «н.з.» продолжается.
  
• отбор по значению поля — гибкий «ручной замок» на время правок.
  

Под каждую задачу лучше подходит свой инструмент, и «н.з.» на 1-й стадии одновременно с целью «создавать заказ на 1-й стадии» несовместим — их нужно развести.

Сегодня будет выпущен релиз 5.0.0.11, успели закинуть в релиз, поменяли "Справочник_Партнеры"  на  "Справочник_Партнеры_Общие", будет теперь отображаться.

Добрый день!
Проверил начиная с релиза 4.4.0.3 до текущего логика по доп реквизитам не менялась. Вы с более старого обновлялись?
Еще уточните - в каком наборе лежат те 7 доп.реквизитов Партнера? (Похоже на "Справочник_Партнеры_Общие"), а программа смотрит тут - "Справочник_Партнеры".

Добрый день! Спасибо за информацию, сейчас оперативно исправим

Эту ошибку знаем, сегодня скорее всего новую версию выпустим.

Добрый день! Попробуйте переустановить модуль, вроде 20-го августа эту ошибку исправляли (переопубликовывали версию (5.0.0.9) 21-го августа).

Добрый день! Да, оба ваших способа — рабочие, они полностью останавливают загрузку заказа с портала в 1С, но они не объединяют данные и не убирают первопричину. Надёжнее — свой алгоритм перед записью (хук до записи), который не даёт перезаписывать заказ, редактируемый в 1С. Если нужен именно «ручной замок на сделку» как орг. решение — берите отбор по значению поля; «н.з.» по статусу — тоже ок, но менее гибко.

Отдельной настройки в самом банковском счёте нет — но «основной» счёт в УТ всё-таки есть, только задаётся он у самой Организации (реквизит «Основной банковский счет» в карточке организации), и именно его ищет алгоритм. Вот объяснение, почему «не с каждым заказом»:
Счёт подберётся, если подходящих под организацию+валюту+направление ровно один, либо у организации заполнен «Основной банковский счет».
Счёт не подберётся (→ пусто → при проведении «Банковский счет не указан»), когда подходящих счетов несколько и основной не задан, либо форма оплаты/направление отсекает все счета.
Коннектор реагирует на любое изменение сделки на портале (событие onCrmDealUpdate). Звонок или письмо в таймлайне обновляют дату/поля сделки → событие срабатывает → идёт обмен.
При обмене коннектор читает существующий «Заказ клиента», заново заполняет его по алгоритму и перезаписывает.
Если в этот момент пользователь 1С открыл тот же заказ и набивает товары — возникает конфликт: либо платформа выдаёт «объект изменён», либо коннектор своей записью перезатирает то, что пользователь ещё не сохранил.
Это встроенное поведение штатного коннектора. Бороться можно несколькими способами:
А. Настройками коннектора (без доработок):В настройках синхронизации сделок/заказов включить «не обновлять» для уже существующих заказов,
Б. Организационно/процессно. Не давать пользователям 1С править заказы, которые синхронизируются с Битрикс24, «вживую» в моменты активного обмена — либо согласовать, что «владельцем» заказа является портал, а правки в 1С делаются в те периоды, когда обмен приостановлен.
В. Доработать модуль. Над проверкой «объект изменён» мы тоже думаем, может в дальнейшем оптимизируем этот процесс, пока думаем как лучше.

Добрый день!
По складу: обновление сделки в Битрикс24 (в т.ч. добавление активности в таймлайн) перезаписывает Заказ клиента целиком, восстанавливая склад из соглашения — ручное значение на стороне 1С сбрасывается. Поле «Склад» заполняется так:

1. Сначала коннектор берёт склад из заказа на портале (из резервов/остатков каждой позиции, reservations → storeId).
   
2. Если склада нет (а у вас складской учёт отключён — значит он там пуст), то берётся уже существующее значение склада в самом заказе 1С — то, что вы поставили руками. Оно сохраняется.
   
3. Если же склад сопоставлен в настройках синхронизации товаров — берётся он и перезаписывает значение документа.
   

Что делать: в настройке синхронизации по сущности «Сделка/Заказ» поменять заполнение реквизита «Склад» с предопределённого алгоритма на «Свой алгоритм» (или, если нужен склад строго из соглашения, закрепить в своём алгоритме правило «не трогать склад, если он уже заполнен в 1С»). Это делается 1С-программистом в расширении.

По банковскому счёту: заказ из сделки заполняется основным счётом организации; ошибка возникает из-за того, что основной счёт не выделен однозначно / не настроен маппинг счетов.

Предопределённый алгоритм «Банковский счет» для УТ: коннектор сам счёт не выбирает — он просто просит типовой механизм УТ «дай основной счёт по умолчанию».
Ошибка «Банковский счет не указан» появляется, когда типовая функция УТ не находит основной счёт для этой организации/формы оплаты: у организации несколько счетов, но ни один не выделен как основной (нет флага «использовать по умолчанию»), либо не тот счёт для выбранной формы оплаты/валюты. Тогда на заказ, созданный из сделки, счёт не записывается — и при проведении контроль это ловит. «Лечится перевыбором организации», потому что при перевыборе типовой механизм заново запускает заполнение и находит нужный основной счёт.
Что делать:

• выделить у организации основной банковский счёт (флаг по умолчанию);
  
• настроить сопоставление/маппинг банковских счетов в коннекторе (организация ↔ счёт);
  
• проверить, что счёт подходит под форму оплаты/валюту соглашения.
  

Добрый день! Мы свои тестовые базы обновили до 11.6.1.53, на этом релизе работает, думаю на 11.5.27.79  тоже должно.

Добрый день! https://1c.1c-bitrix.ru/intranet/download.php
Готовим адаптацию под старую платформу 8.3 много запросов уже об этом.

Добрый день! На вкладке цену нужно обязательно указать цену. Вероятно на сайте остались старые цены и из-за этого ошибка "малый бизнес не может быть больше одной цены". Проверьте по пунктам:

1. Откройте настройку обмена товаров в 1С→ вкладка «Цены» и убедитесь, что там отмечено ровно одно значение — «Розница» (снимите все остальные, если они есть).
   
2. Зайдите на сайте → Магазин → Настройки → Типы цен, удалите все лишние типы цен, оставьте ровно один, название которого совпадает с передаваемым из 1С (Розница).
   
3. После «полного» обмена (лучше с принудительным полным обновлением каталога) проверьте журнал ошибок обмена и, если настроен вынос лога, сгенерированный prices.xml / прайс-лист — там должно быть видно, какие типы цен реально уходят.
   
4. Если прайс один, но ошибка остаётся — проверьте, не задано ли на товаре несколько видов цен (или характеристик/упаковок), которые размножают тег <Цена>.
   

Добрый день. Принял, уберем пробелы.

Добрый день! Планируем в ближайшее время перестать обновлять модуль 4.4, новые доработки будут только в 5.0.

Добрый день. Не решена еще. Из 1С передается число, число выглядит так 3 150, это не пробел это представление числа. Со стороны 1С выгружается корректно.