Александр Денисюк, можете пояснить какая логика создания договоров при обмене Б24>БП? Обменялись счетами - на стороне 1с у счета поле договора значится Договор - WEB, но само поле заблокировано Сам договор при этом не создался. При поступлении оплаты от клиента нельзя привязать оплату к счету, поскольку 1с сначала требует указать договор, а его нет и поле залочено.
Напомните пожалуйста, сихронизация с БП поддерживает только один реквизит в карточке Компании? Если нужно выставить счет этому же клиенту но на другие реквизиты - создавать отдельную Компанию?
Александр, я вроде подробно все расписываю, в предыдущем посте так и пишу
Цитата
В список изменений попадает сам счет на оплату, и банковский реквизит.
Реквизит регистрируется к изменению. Тут проблем нет. Проблемы происходят на этапе обмена и в том, что лог не детализирует факт выгрузки\невыгрузки. Он на любых данных у вас пишет что выгрузка произошла. Хотя по факту может быть и нет. Запросы REST тоже не формируются (по банковским реквизитам), а по счету формируются.
Согласны, это не нормально - говорить что все выгрузилось, но по факту не выгружать?
Реальная ситуация: Включаем галкой синхронизацию только счетов. Пока что cписок изменений пуст. Берем счет на оплату, которым ранее уже обменивались, редактируем на стороне 1с, например крайний срок оплаты, и добавляем у нашей Организации новый банковский р\с.
В список изменений попадает сам счет на оплату, и банковский реквизит.
Запускаем синк изменений - в логе красота! Формируем. выгражаем, счет, реквизит, все круто! Написано русским же языком "Завершение выгрузки обьектов с типом Банковский реквизит"
Смотрим в Б24 - счет синхронизировался, а банковский реквизит нет, смотрим на стороне 1С - идентификатора у реквизита не появилось. В логах ошибок нет, список изменений пуст, неотправленных пакетов - ноль.
И это заметьте при включеном режиме отладки. Что я должен исправить? Хоть бы в лог об этом пукнул хотя бы, было бы понятно. А так тупо реквизит не выгружает и говорит что выгрузил. сидишь и гадаешь - почему не выгрузилось ничего.
Александр Денисюк, помогите разобраться, кейс только выгрузки из 1с, БП:
1. Правильно я понимаю что основные настройки синхронизации влияют на все виды синхронизации (ручная, реалтайм, расписание, по кнопке "открыть в Б24")?
1.1. Если выключена синхронизации счетов или сам обьект не попадает в отборы, то по кнопке открыть в Б24 счет не выгрузится?
1.2. Если синхронизация включена для счета, но выключена для номеклатуры, то номенклатура из счета выгрузится, так как является зависимым документом?
2. Правильно я понимаю что кнопка "открыть в Б24" - записывает текущий обьект в "зарегистрированые изменения" + запускает синхронизацию с типом "синхронизация по кнопке открыть в б24", при этом по факту выгружается весь список зарегистрированных изменений на данным момент, а не только обьект который мы хотим открыть?
3. Сейчас каждая синхронизация впустую нагружает портал и 1С, пытаясь каждый раз выгрузить из 1С Контакты, которые не нужны в Б24 и часто имеют некачественные данные. Я пытаюсь исключить их из синхронизации, но не получается. Очень прошу вас добавить галку отключения обмена контактными лицами. Зачем создается дополнительная нагрузка на REST и проблемы во внедрениях, если эти данные чаще всего тупо не нужны? В моей практике клиенты воспринимают это как излишний мусор и доп-работу по чистке всего этого. А бухгалтера в БП работают с цифрами - им вообще что там у контрагента в БП за контактные лица.
3. Можно ли научить модуль работать в режиме единичной синхронизации документа, чтобы можно было принудительно выгрузить любой обьект через кнопку - открыть в б24, при этом независимо от глобальных настроек, и не выгружалось все что накопилось в режиме изменений - а только этот документ?
Это просто отличный и удобный кейс для обмена документами "по требованию".
Спасибо.
Александр Денисюк, мы передаём из стандартного поля в стандартное, но почему то игнорируете типы полей... пользователь в любом случае там пишет текст но он не знает что в 1с не поддерживается форматирование, бухгалтер видит в счете белиберду. Странная позиция, особенно если учесть что для пользователя полезная нагрузка в поле это именно текст. никто не знает что оно там под капотом html. Какой смысл пытаться в plain передать html не очищая и ломая полезный смысл по дороге. Не знаю. вы сами говорите корму надо html - выведут в форму допреквизит нужного типа. А так только чтобы проблемы дополнительные создаются) потом удивляются почему там мусор какой то а не комментарии
1. На стороне Б24 в Счете, поля комментарий и комментарий менеджера - с форматированием. На стороне БП 3.0 plaintext. Если чуть-чуть не то вставить в поле - в 1с прилетят теги. Хорошо бы очищать это дело по дороге..
2. Поля комментариев перепутаны местами. "Комментарий" счета Б24 прилетает в реквизит "пользовательский комментарий". "Комментарий менеджера" прилетает в просто "Комментарий"
Согласитесь, по смыслу адекватно было бы Комментарий > Комментарий Комментарий менеджера > Пользовательский комментарий. А лучше реквизит тоже переименовать в "комментарий менеджера". Зачем множить сущности?
И так в модуле полно вещей которые непонятным языком описаны, без полдня экспериментов не поймешь как работает.
Вот например название полей удаления - загадка для любого кто не умеет читать мысли. Обрабатывать в 1С, это что? Под обработкой можно что угодно понимать. Человек может подумать - Вот я счет в 1С удалил - нужно это обработать и отправить в Б24. Значит ставлю обрабатывать в 1С!
Другой человек скажет - я удалил в Б24, теперь нужно обработать счет в 1С и удалить его там! Ведь фактически в Б24 только триггер сработал, а обработать счет надо на стороне 1с. Значит ставлю галку обрабатывать в 1С! А оно не работает...
А на самом деле - хорошая документация решает...
По русски было бы так и написать. -"Помечать на удаление в 1с если удален в Б24. -"Удалять в Б24 если помечен на удаление в 1с"
Длинно, зато понятно.
Уверен что вы знаете как оно на самом деле работает и можете описать на форуме, но хорошо когда просто читаешь доку и делаешь, а не дергать занятых людей банальными вопросами...
Александр Денисюк, 1. использовалось только сопоставление контрагентов - сопоставил 5 штук. 2. Технически не первая. В первый раз синхронизация не пошла потому что была ошибка вида "Невозможно выполнить синхронизацию, включите в базе использование доп.реквизитов". Там была сразу ошибка ничего не успело обменяться толком. После этого я отключил синхронизацию пользовательских полей, но уже пошли ошибки обмена которые я выше описал. Возможно в логике не учитывается этот сценарий.
Александр Денисюк, это первая синхронизация, выгрузка пользовательских полей вообще отключена. Решение ещё настолько сырое что даже при чистом первоначальном обмене выдаёт ошибки? А вариант багов в модуле не рассматривается?)
1С:Предприятие 8.3 (8.3.16.1063) БП 3.0 (3.0.75.109) Последний модуль.
2. Пошла первая синхронизация, полезли ошибки с полем контакта. 3. Выгрузились несколько контактных лиц в контакты б24, совершенно в бесполезном виде. Можно это как то отключить? С контактами в 1с никто не работает но они в базу попадают при заполнении по инн, а потом летят в битрикс.
Получить результат и обработать можно только через приложения, например есть у itsolution называется что то там REST вроде бесплатное
[Вопрос] Как создать приложение для Битрикс24, которое выводит мои css стили и js-код на страницах сделок и контактов?, Как расширить действие приложения на "стандартные" страницы битрикса?
Зачем такие сложности. Создайте "левый" список, со счетчиком, при создании сделки создавайте элемент списка, вытягивайте значение счетчика, пишите в сделку
Было бы неплохо провести мозговой штурм, потому что такая проблема действительно существует - надо работать со сделкой, но стадию не трогать. Первая мысль естественно уже озвучена - проверять по бп и откатывать обратно. Но, кто работал в поле понимает что такое решение не выдерживает никакой критики, и в бою оно внедряемо только на очень простых порталах, когда других БП нет.
В обычных ситуациях на каждые стадии у сделок висят свои бп или роботы. Вот это передергивание туда сюда вызовет перезапуск этих бп, независимо от текущей стадии. Короче внедрение вот этой защиты вынудит переписать вообще все бп до каких то невероятных монструозных конструкций.
