Модули интеграции для Битрикс24

Добрый день!
Похоже что все типы источников компаний/контактов настроены как компании. Нужно смотреть настройку настройкой "Источники компаний/контактов от типов контрагентов". Различие «физлицо = контакт» задаётся только через настройкой "Источники компаний/контактов от типов контрагентов". Если настройка не корректная (всё = «Компания»), то:
1. физлица + ЮЛ + ИП уходят как компании;
2. в контактную выгрузку подмешиваются пользовательские поля контрагентов-компаний → UF компаний в контактах.

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

Поддерживаю, такая проблема есть, и это именно пробел.

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

Ещё вопрос, как можно на стороне коробочного Б24 запускать обработчик на API не через агента, а в момент окончания синхронизации Коннектора?

Добрый день!
Настроена синхронизация 1С УТ и Битрикс24 через штатный коннектор. Складской учет отключен.

Первый вопрос. Непонятно как работает предопределенный алгоритм "Склад" в заказе клиента при синхронизации? Есть значение склада в типовом соглашении. При изменении на стороне 1С пользователем склада в заказе, и последующем изменении данных в сделке на стороне Б24 (например, в таймлайне появляется телефонный звонок), склад опять меняется на предыдущее значение.

Второй вопрос, как подставляется банковский счет организации. В УТ несколько счетов.
При создании Заказа в 1С из Сделки Б24 при синхронизации и последующей попытке его перепровести, пишет ошибку "Банковский счет не указан". Решается перевыбором организации. Как работает этот предопределенный алгоритм "Банковский счет компании"

Спасибо!

Спасибо большое за подробный ответ!
По банковскому счету, в УТ нет основного счета по умолчанию как настраиваемой опции, поэтому, видимо, и есть проблема. Мне как раз интересно, как в этом случае работает предопределенный алгоритм. Потому что ошибка возникает не с каждым заказом.

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

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

Добрый день!

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

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

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

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

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

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

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

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