В JIRA очень удобно реализована взаимная перелинковка задач: если линкуешь одну задачу (добавляешь связанную задачу) к другой, то у второй так же проставляется обратная ссылка.
Для основных сущностей (контакт, компания и т.п.) CRM наблюдаем следующую картину (на примере контакта показываю):
- Есть метод crm.*.fields который возвращает описания полей
- Есть метод crm.*.userfield.list который возвращает описание пользовательских полей.
В ответ на crm.*.fields для UF_* полей возвращается описание:
В нем вы видим важные параметры:
В нем мы НЕ видим:
В ответ на crm.*.userfield.list возвращается описание:
В нем мы видим важные параметры:
В нем мы НЕ видим:
Имя 2 запроса можно предположить что настройки для пользовательских полей возвращаются отдельно, однако: если обратиться к полю с типом enumeration, то в fields-запросе вернется:
Т.е. дополнительный ключ items, который показывает что можно выбрать.
Суть предложения: провести унификацию методов, чтобы crm.*.fields возвращает достаточную информацию для отображения поля.
Возвращать дополнительный ключ parameters внутри которого возвращать данные из ID поля, SETTINGS (возможно другую необходимую информацию)
- Это закрывает базовую потребность "возвращает достаточную информацию для отображения поля"
- Это не нарушает обратную совместимость (такого ключа ранее не было, а механизмы других ключей не менялись)
- Есть метод crm.*.fields который возвращает описания полей
- Есть метод crm.*.userfield.list который возвращает описание пользовательских полей.
В ответ на crm.*.fields для UF_* полей возвращается описание:
{
"UF_CRM_1603091288": {
"type": "crm",
"isRequired": false,
"isReadOnly": false,
"isImmutable": false,
"isMultiple": false,
"isDynamic": true,
"title": "UF_CRM_1603091288",
"listLabel": "Привяка к компаниям",
"formLabel": "Привяка к компаниям",
"filterLabel": "Привяка к компаниям"
}
} |
В нем вы видим важные параметры:
- Технические характеристики (обязательность, множественность, динамичность и т.п.)
- Его тип (привязка к CRM)
- Отображаемые названия
В нем мы НЕ видим:
- Параметров, которые необходимы для показа значения
В ответ на crm.*.userfield.list возвращается описание:
{
"5": {
"ID": "114",
"ENTITY_ID": "CRM_CONTACT",
"FIELD_NAME": "UF_CRM_1603091288",
"USER_TYPE_ID": "crm",
"XML_ID": null,
"SORT": "100",
"MULTIPLE": "N",
"MANDATORY": "N",
"SHOW_FILTER": "I",
"SHOW_IN_LIST": "N",
"EDIT_IN_LIST": "Y",
"IS_SEARCHABLE": "N",
"SETTINGS": {
"LEAD": "N",
"CONTACT": "N",
"COMPANY": "Y",
"DEAL": "N",
"ORDER": "N"
}
}
} |
В нем мы видим важные параметры:
- Технические характеристики (обязательность, множественность, динамичность и т.п.)
- Его тип (привязка к CRM)
- Настройки (SETTINGS)
В нем мы НЕ видим:
- Отображаемых названий
Имя 2 запроса можно предположить что настройки для пользовательских полей возвращаются отдельно, однако: если обратиться к полю с типом enumeration, то в fields-запросе вернется:
{
"UF_CRM_1603091201384": {
"type": "enumeration",
"isRequired": false,
"isReadOnly": false,
"isImmutable": false,
"isMultiple": false,
"isDynamic": true,
"items": [
{
"ID": "26",
"VALUE": "Значение 1"
},
{
"ID": "27",
"VALUE": "Значение 2"
}
],
"title": "UF_CRM_1603091201384",
"listLabel": "Список из двух значений",
"formLabel": "Список из двух значений",
"filterLabel": "Список из двух значений"
}
} |
Т.е. дополнительный ключ items, который показывает что можно выбрать.
Суть предложения: провести унификацию методов, чтобы crm.*.fields возвращает достаточную информацию для отображения поля.
Возвращать дополнительный ключ parameters внутри которого возвращать данные из ID поля, SETTINGS (возможно другую необходимую информацию)
- Это закрывает базовую потребность "возвращает достаточную информацию для отображения поля"
- Это не нарушает обратную совместимость (такого ключа ранее не было, а механизмы других ключей не менялись)
Ответил 
Антон Горбылев 14.09.2021 12:09:12
Антон Горбылев 14.09.2021 12:09:12
Выйдет в районе crm 21.1100.0
Необходимо сделать дополнительный шаг - ограничение пользователей.
Сейчас, если в системе больше 12 пользователей, то сразу после активации купона все другие пользователи не могут зайти. А посмотреть, кто на лицензии из них, кто нет - можно только после конвертации.
Сейчас, если в системе больше 12 пользователей, то сразу после активации купона все другие пользователи не могут зайти. А посмотреть, кто на лицензии из них, кто нет - можно только после конвертации.
В ядре D7 было б не плохо внедрить обработчик "OnBeforGetMap", в котором можно было б добавлять свои зависимости после формировании результата но перед его возвратом в методе getMap. Для модуля report это панацея на сегодняшнее время)
Открытый слайдер почты
1. Фильтр с ящиков по ответственному
2. Отображение писем со всех ящиков
3. Отображение ответственного
4. Быстрый доступ к созданию новых шаблонов
5. Отображение сущности
-----------------------------------------
Открытое письмо с почты
1. Быстрый доступ к шаблонам
2. Панель редактирования
3. Отображение сущности
4. Быстрое сохранение шаблона
1. Фильтр с ящиков по ответственному
2. Отображение писем со всех ящиков
3. Отображение ответственного
4. Быстрый доступ к созданию новых шаблонов
5. Отображение сущности
-----------------------------------------
Открытое письмо с почты
1. Быстрый доступ к шаблонам
2. Панель редактирования
3. Отображение сущности
4. Быстрое сохранение шаблона
RPA - тема очень актуальная, но хотелось бы больше от этого инструмента. Ниже собрал идеи и замечания по данному функционалу:
1. Предложение. Синхронизация сущности RPA с такой же функцией "Бизнес-процесс со статусами". Если честно не совсем понятно, почему вы выбрали путь создания новой функции. По моему мнению, доработка интерфейса в вид RPA, функции "Бизнес-процесс со статусами" была бы логичней т.к. этим функционалом уже многие пользуются и он во многом превосходит возможности и гибкость нового.
2. Замечание. Многие поля в RPA невозможно передать в такие же полня в Списках. Например невозможно передать при создании элемента Списка поле из RPA вида "Привязка к элементам CRM", "Привязка к элементам инф. блоков" в аналогичные поля в Списках.
3. Предложение. Добавить возможность открытия того или иного бизнес-процесса из карточки сделки, лида, компании, группы... в виде дополнительных вкладок в этих карточках, если в процессе есть соответствующие поля обозначающие такую принадлежность (так как это сделано в списках).
4. Предложение. Возможность формирования документов процессах RPA по аналогии формирования документов в CRM. Часто требуется сформировать документ по шаблону на основе данных процесса, чтобы сотрудник вывел его на печать, подписал и отправил в какие либо внешние инстанции.
5. Предложение. Объединить RPA с разделом "Бизнес-процессы" или дать возможность работы с RPA из "Бизнес-процессы". Эти разделы настолько взаимосвязаны что приходится постоянно переходить между ними, чтобы оценить ситуацию по процессу.
6. Предложение. Добавить возможность группировать поля в карточке Бизнес-процесса, так как это реализовано в CRM. Часто полей очень много и это очень неудобно выводить их в одну группу.
7. Предложение. Добавить возможность запуска бизнес-процесса в RPA автоматически из стандартного последовательного бизнес процесса.
8. Предложение. Добавить составное поле. Например: если на стадии нужно выполнить задание типа "Прописать список работ с указанием нормочасов". Сейчас нет такого поля чтобы можно было построчно добавлять по 2 значения (Строка + Число). А такие поля очень часто нужны буквально везде, не только в RPA.
1. Предложение. Синхронизация сущности RPA с такой же функцией "Бизнес-процесс со статусами". Если честно не совсем понятно, почему вы выбрали путь создания новой функции. По моему мнению, доработка интерфейса в вид RPA, функции "Бизнес-процесс со статусами" была бы логичней т.к. этим функционалом уже многие пользуются и он во многом превосходит возможности и гибкость нового.
2. Замечание. Многие поля в RPA невозможно передать в такие же полня в Списках. Например невозможно передать при создании элемента Списка поле из RPA вида "Привязка к элементам CRM", "Привязка к элементам инф. блоков" в аналогичные поля в Списках.
3. Предложение. Добавить возможность открытия того или иного бизнес-процесса из карточки сделки, лида, компании, группы... в виде дополнительных вкладок в этих карточках, если в процессе есть соответствующие поля обозначающие такую принадлежность (так как это сделано в списках).
4. Предложение. Возможность формирования документов процессах RPA по аналогии формирования документов в CRM. Часто требуется сформировать документ по шаблону на основе данных процесса, чтобы сотрудник вывел его на печать, подписал и отправил в какие либо внешние инстанции.
5. Предложение. Объединить RPA с разделом "Бизнес-процессы" или дать возможность работы с RPA из "Бизнес-процессы". Эти разделы настолько взаимосвязаны что приходится постоянно переходить между ними, чтобы оценить ситуацию по процессу.
6. Предложение. Добавить возможность группировать поля в карточке Бизнес-процесса, так как это реализовано в CRM. Часто полей очень много и это очень неудобно выводить их в одну группу.
7. Предложение. Добавить возможность запуска бизнес-процесса в RPA автоматически из стандартного последовательного бизнес процесса.
8. Предложение. Добавить составное поле. Например: если на стадии нужно выполнить задание типа "Прописать список работ с указанием нормочасов". Сейчас нет такого поля чтобы можно было построчно добавлять по 2 значения (Строка + Число). А такие поля очень часто нужны буквально везде, не только в RPA.
Роботы в задачах не связаны с пользовательскими полями в задачах. (тариф Компания, облако)
Сейчас есть возможность создать пользовательское поле в задаче(например, число). У него будет код вида "UF_AUTO_######"
Роботы не видят и не могут использовать это поле ни по названию, ни по коду.
Даже просто уведомления с использованием такого поля вывести нельзя.
Где это можно было бы применять: есть некий список, в котором фиксируются (в том числе) факты выполнения задач по проекту: начало работ по задаче, завершение, время принятия.
ИД элементов этого списка занесены в пользовательское поле в задаче.
Без роботов приходится дублировать ИД элементов в теги (что ненадежно) или работать через исходящий вебхук (там пользовательские поля видно отлично) - но это громоздко, потому что придется обмениваться данными по каждому изменению в каждой задаче.
Сейчас есть возможность создать пользовательское поле в задаче(например, число). У него будет код вида "UF_AUTO_######"
Роботы не видят и не могут использовать это поле ни по названию, ни по коду.
Даже просто уведомления с использованием такого поля вывести нельзя.
Где это можно было бы применять: есть некий список, в котором фиксируются (в том числе) факты выполнения задач по проекту: начало работ по задаче, завершение, время принятия.
ИД элементов этого списка занесены в пользовательское поле в задаче.
Без роботов приходится дублировать ИД элементов в теги (что ненадежно) или работать через исходящий вебхук (там пользовательские поля видно отлично) - но это громоздко, потому что придется обмениваться данными по каждому изменению в каждой задаче.
В редакторе бизнес-процессов в операциях "Отправить письмо" и им подобных есть поле ввода собственно сообщения. При этом HTML-код в нем понимается. Но вот сверстать там что-то возможно в принципе. И поле редактирования крошечное, и все идет кашей plain-text.
То есть задача отредактировать красивый шаблон письма превращается в проблему. Ее можно решить, редактируя в каком-то IDE, а потом скопировать сюда. Но если надо внести изменения - весь кардебалет начинается снова.
Настоятельная просьба - сделайте человеческий редактор, типа TinyMCE или чего-то вроде.
P.S. А также давно ожидающая заявка на возможность использовать в бизнес-процессах шаблоны писем!
То есть задача отредактировать красивый шаблон письма превращается в проблему. Ее можно решить, редактируя в каком-то IDE, а потом скопировать сюда. Но если надо внести изменения - весь кардебалет начинается снова.
Настоятельная просьба - сделайте человеческий редактор, типа TinyMCE или чего-то вроде.
P.S. А также давно ожидающая заявка на возможность использовать в бизнес-процессах шаблоны писем!
Нужно иметь возможность отправлять сообщение в ОЛ в мессенджер, который можно выбрать по условию. Сейчас по умолчанию сообщения в ОЛ улетают в тот мессенджер, который в находится в нижней строчке списка карточки клиента. На скрине ниже - это будет телеграм
Очень нужно иметь возможность писать в мессенджер клиенту из мобильного приложения - открывать диалог.
Кейс.
На СТО приходит клиент (ранее с клиентом уже было общение через ОЛ - viber), сдает авто на ремонт. В ходе ремонта клиенту нужно отправить фото состояния агрегатов/частей, которые необходимо заменить. Это делает мастер, который 95% времени находится в ремзоне. Сейчас начать диалог в мессенджере с клиентом можно только на рабочем месте на ПК и уже после этого диалог ОЛ становится доступным и в мобильном приложении.
Сюда же подойдет любой кейс, в котором сотрудникам, которые работают на выездах/удаленно, нужно держать связь с клиентами, которые используют мессенджеры.
Кейс.
На СТО приходит клиент (ранее с клиентом уже было общение через ОЛ - viber), сдает авто на ремонт. В ходе ремонта клиенту нужно отправить фото состояния агрегатов/частей, которые необходимо заменить. Это делает мастер, который 95% времени находится в ремзоне. Сейчас начать диалог в мессенджере с клиентом можно только на рабочем месте на ПК и уже после этого диалог ОЛ становится доступным и в мобильном приложении.
Сюда же подойдет любой кейс, в котором сотрудникам, которые работают на выездах/удаленно, нужно держать связь с клиентами, которые используют мессенджеры.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
