Универсальная CRM/ERM система BGCRM 2.5

Загрузите архив bgcrm_<version>_<build>.zip.

Извлеките каталог BGCRM из него его в требуемый каталог установки. (например /opt).

Извлеките файл bgcrm.sql в каталог /tmp.

Выполните создание БД:

mysql --default-character-set=utf8 -uroot < /tmp/bgcrm.sql

При доступе к БД с другим логином - паролем, либо если база расположена на другой машине - скорректируйте команду.

Перейдите в каталог BGCRM и сделайте файлы исполняемыми:

chmod 744 *.sh

При необходимости поправьте в bgcrm.properties логин и пароль подключения к БД, сервер БД и имя. Также там можно изменить HTTP порт и порт управления.

Установите в setenv.sh путь к Java, например:

JAVA_HOME=/opt/java/jre                                                                                                                                                                                                                                     
                                                                                                                                                                                                                                                            
if [ -z "$JAVA_HOME" ]; then
  echo "The JAVA_HOME environment variable is not defined"
  echo "This environment variable is needed to run this program"
  exit 1
fi

Для запуска/останова сервера используйте crm_start.sh/crm_stop.sh. crm_status.sh - просмотр статуса запущенного сервера.

После запуска проверьте log/bgcrm.log и в log/bgcrm.out на наличие ошибок (Exception).

По умолчанию CRM доступна по адресу: http://<HOST>:9088

При создании БД в системе присутствует единственный пользователь admin, пароль - admin.

Для обновления вызовите команду:

./installer.sh update

Плагины дополняют функционал ядра, позволяя максимально гибко сконфигурировать систему под нужды конкретной организации-пользователя.

В данный момент доступны плагины: Document (генерация документов), BGBilling (интеграция с системой BGBilling), Report (разработка отчётов). Все плагины в данный момент включены в общую сборку. Для отключения функций плагина необходимо удалить XML файл описания из каталога BGCRM/plugin.

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

В системе доступны интерфейсы:

Для перехода в другой интерфейс можно поправить URL в адресной строке браузера либо использовать ссылку в правом нижнем углу экрана.

Интерфейс пользователя:

Интерфейс администратора представляет из себя набор редакторов, собранный в иерархию вкладок. Описание редакторов производится в документации по мере разбора настраиваемых подсистем.

Очень большое количество редко меняющихся настроек поведения системы вынесено в конфигурации. Конфигурация - это текстовый блок, состоящих из записей вида: <ключ>=<значение>. На одной строке может быть только одна такая запись, символ # в начале строки означает комментарий.

Конфигурации вводятся либо в текстовых .properties - файлах (опции подключения к БД, базовые настройки), либо в редакторах конфигурации, сохраняясь в базе данных.

# определение значения
howYou=how you
# использование подстановки
some.kind.of.config.record=Thats {@howYou} should use macro!

object.1.id=1
object.1.title=Title1
object.2.id=2
object.2.title=Title2

index=1
object.{@index}.id=1
object.{@index}.title=Title1
object.{@inc:index}.id=2
object.{@index}.title=Title2

key=1
key+=,2
key+=,3

# дата рожд., с.-н. пасп., д.в. пасп., кем выд. пасп, адрес проп., тел. гор, тел. сот, адрес(а) усл., перс. данные
bgbilling:creator.importParameters=73,74,75,76,77,78,14,12,115
# ИНН, КПП, ФИО руководителя, полное название, должность рук.-ля, E-Mail(ы)
bgbilling:creator.importParameters+=,248,249, 252, 428, 429, 15

Основная конфигурация BGCRM определяет большинство параметров функционирования ядра и плагинов.

В основную конфигурацию попадают параметры, определённые в файле bgcrm.properties, далее загружается конфигурация указанная в интерфейсе администратора.

Одномоментно может быть активна только одна конфигурация выделенная признаком Активный. Для создания конфигурации - кнопка Создать. Изменении конфигурации применяется "на лету", перезапуск системы не требуется.

В конфигурации указываются параметры ядра и подключённых плагинов. Для ядра доступны следующие параметры:

# формат адресного параметра, доступны переменные: index, сity, area, quarter, street, house, flat, room, pod, floor, comment 
address.format=(${city})(, ${street})(, д. ${house})(, кв. ${flat})( ${room})
#
# шаблон описания контрагента для поиска 
# в нём можно указать параметры контрагента подстановками вида (param:<code>); например: (${param:73} г.р.)(, ${param:12})
#customer.reference.pattern=
#
# минимальная длина подстроки в поиске контрагента
searchCustomerTitleMinSubstringLength=2
#
# форматирование параметра типа "phone", общий формат одного номера
param.phone.format=(${number})( [${comment}]);
# форматирование поля ${number} внутри каждого номера, в зависимости от формата
param.phone.format.number=+X XXX XXX-XX-XX
param.phone.format.number.f10=+X XXX-XXX-XX-XX
param.phone.format.number.f13=+X (XXX) XXX-XX-XX
param.phone.format.number.f14=+X (XXXX) XX-XX-XX
param.phone.format.number.f15=+X (XXXXX) X-XX-XX
# количество полей в параметре типа "телефон"
param.phone.item.count=4
# префикс по-умолчанию для параметра типа "телефон"
param.phone.default.prefix=3472
# ускорение ввода номеров - подстановка 7 в код страны
param.phone.part.1.default=7
# переход в третье поле при введение во втором кода российского мобильного, без удаление последнего символа
param.phone.part.2.jumpRegexp.1.regexp=^9\d{2}
param.phone.part.2.jumpRegexp.1.moveLastChars=0
# переход в третье поле с переносом последнего введённого во втором поле при наборе во втором поле 3472
param.phone.part.2.jumpRegexp.2.regexp=^3472
param.phone.part.2.jumpRegexp.2.moveLastChars=1
#
# при пробросе запросов на сервер с помощью Proxy сервера - имя HTTP заголовка, в котором передаётся адрес клиента
#header.name.remote.addr=X-Real-IP
#
# роли, в которых контрагент может быть привязан к процессу, роли должны начинаться с customer, например: customer:Контрагент;customerSogl:Согласователь
processCustomerLinkRoles=customer:Контрагент
# 
# проверка прав доступа пользователей, 1 - включить 
user.permission.check=0
#
# роли групп в процессах, добавляются через точку с запятой в виде <id>:<title> 
processGroupRoles=0:Выполнение
#
# параметры EMail 
mail.smtp.host=
mail.smtp.user=
mail.smtp.pswd=
#
# динамический код 
dynamic.src.dir=dyn
dynamic.src.encoding=UTF-8
# перечень через запятую динамических или обычных классов, реализующих интерфейс java.lang.Runnable, запускаемых при старте сервера
#runOnStart=
# перечень через запятую динамических или обычных классов, объекты которых создаются при старте сервера, при перекомпиляции динамических классов создание объектов производится повторно
#createOnStart=
#
# планировщик, запуск - 1  
scheduler.start=0

Записи параметров плагинов начинаются с префикса <plugin>:, например bgbilling:. Возможно включение в одну конфигурации другой, для этого во включающей конфигурации размещается инструкция include.<configId>=1, где <configId> - код включаемой на данной позиции конфигурации.

Редактирование учётных записей пользователей системы и их прав доступа осуществляется на вкладке Пользователи интерфейса администратора.

3.3.1. Наборы прав

Наборы прав определяют разрешаемые пользователю интерфейсы и действия в них. Интерфейсы определяются через роли.

Роли указываются через пробел, допустимые значения: user, admin, usermob. Роли всех установленных пользователю наборов прав объединяются. В дереве действий указываются разрешённые набору действия.

Подробно о логике работы системы ограничений см. далее, в описании редактора пользователей.

Замечание

Проверка прав доступа включается переменной конфигурации.

3.3.2. Группы

Группы пользователей обозначают подразделения в организации и выступают группами решения для подсистемы процессов.

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

Подробно о логике работы системы ограничений см. далее, в описании редактора пользователей.

Группы выстроены в иерархию, что позволяет учитывать службы, отделы и другие структурные единицы организации.

3.3.3. Пользователи

В свойствах пользователя указывается одна или несколько групп с указанием периода, наборы прав, имя пользователя, его логин и пароль. Пользователи выступают исполнителями для подсистемы процессов.

Параметры пользователя определяются в редакторе параметров.

Группы пользователя определяют вхождение пользователя в подразделения либо как классифицирующий признак.

Результирующие права пользователя, параметры его конфигурации и разрешённые очереди процессов определяются описанным ниже образом. Сложение списка обозначает добавление в конец списка новых элементов.

1. Действующий список групп (ДСГ) - упорядоченный список = список групп в алфавитном порядке (как отображаются в списке групп), из них оставлены только действующие в настоящий момент у пользователя.

2. Действующий список наборов прав (ДСНП) - упорядоченный список = списки всех наборов прав групп ДСГ + список наборов прав пользователя.

3. Действующая конфигурация (ДК) - строка = конфигурации всех наборов прав из ДСНП + конфигурации всех групп из ДСГ (конфигурация каждой группы составлена из конфигурации всех его предков + конфигурация группы) + конфигурация пользователя. Переменная более поздно добавленная в конфигурацию переопределит более раннюю.

4. Очереди процессов = список очередей процессов, из которых оставлены очереди указанные в пользователе либо в одной из групп ДСГ.

5. Разрешения = разрешения из наборов прав ДСНП + разрешения из пользователя.

6. Роли - набор = роли всех наборов прав ДСНП + роли из пользователя.

В действующую конфигурацию пользователя дополнительно добавляются переменные:

ctxUserId=<код пользователя в БД>
ctxUserGroupIds=<коды групп пользователя через запятую>
ctxUserPermsetIds=<коды наборов прав пользователя через запятую>

Схема довольно сложна, однако позволяет очень гибко настраивать права пользователей.

Редактор разрешённых действий в наборе прав и пользователе представляет из себя дерево действий следующего вида:

Установка галочки на узле дерева резрешает действия. У некоторых действий есть дополнительная конфигурация (в квадратных скобках на снимке экрана ранее), задающая дополнительные ограничения. В данную конфигурацию допускается подставлять переменные из действующей конфигурации пользователя. Подстановка осуществляется макросом {@<paramName>}, где<paramName> - параметр из конфигурации. Например: groupSet={@smGroup}. Так, на приведённым выше снимке пользователю разрешают просматривать список пользователя только входящих в те же группы, что и он сам. Используется подставновка системной переменной из действующей конфигурации пользователя.

В зависимости от разрешённых действий и их конфигураций в интерфейсе, отображаемом пользователю, могут скрываться либо отображаться различные элементы.

Для отключения проверки прав в действующей конфигурации пользователя должна присутствовать опция: dontCheckPermission=1.

Для большинства сущностей в системе возможно определение настраиваемых параметров. Редактирование перечня параметров осуществляется на вкладке Параметры интерфейса администратора. Выбор сущности, для которой определяются параметры, производится в выпадающем списке. Список сущностей может расширяться при установке плагинов.

Редактор параметра выглядит следующим образом. Для всех типов кроме спискового (отличия будут рассмотрены далее) его вид идентичен.

Таблица параметров сущности выглядит подобным образом. Порядок записи в таблице определяется числовым полем Порядок параметра.

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

Ключи конфигурации параметра различаются для типов параметров, общие для всех типов необязательные значения:

# коды параметров сущности, которые должны быть заполнены перед установкой данного параметра
requireBeforeFillParamIds=<codes>
# коды параметров сущности, которые должны быть пустыми перед установкой данного параметра
requireBeforeEmptyParamIds=<codes>
# теги параметра через запятую - тегированный параметр можно просматривать или править 
# только явно разрешив тег в настройке прав на изменение параметра либо просмотр параметров
tags=<tags>
# редактор параметра недоступен (параметр загружается посредством API к БД либо HTTP API)
readonly=1 

Где:

3.4.3. Параметр типа "text"

Однострочная строка до 250 символов.

В конфигурации параметра могут быть указаны следующие необязательные параметры:

saveOn=<saveOn>

Где:

<saveOn> - режим сохранения, может быть "focusLost" (потеря фокуса полем) либо "enter" (нажатие клавиши "Enter"), по-умолчанию режим "enter".

В конфигурации параметра могут быть указаны одна или несколько конструкций вида:

regexp.<n>.title=<title> 
regexp.<n>.regexp=<regexp>

Где:

<n> - число, порядковый номер регулярного выражения;

<title> - наименование шаблона;

<regexp> - Java регулярное выражение, описывающее шаблон.

При наличии в конфигурации текстового параметра подобных конструкций вводимая строка будет проверяться на совпадение хотя бы с одним из шаблонов, например:

regexp.1.title=<город без г.>,<улица без ул.>,<дом без д.>
regexp.1.regexp=[а-яА-Я\s\-]+,[\dа-яА-Я\s\-]+,\s*[\dа-яА-Я/]+
regexp.2.title=<город без г.>,<улица без ул.>,<дом без д.>,<номер квартиры> 
regexp.2.regexp=[а-яА-Я\s\-]+,[\dа-яА-Я\s\-]+,\s*[\dа-яА-Я/]+,*\s*\d+
regexp.3.title=<город без г.>,<улица без ул.>,<дом без д.>,<номер квартиры>, <номер комнаты>
regexp.3.regexp=[а-яА-Я\s\-]+,[\dа-яА-Я\s\-]+,\s*[\dа-яА-Я/]+,*\s*\d+,\s*\d+

В данном случае параметр контрагента адрес по прописке проверяется на соответствие одному из шаблонов. Содержание шаблонов легко понять из атрибутов title.

В таблице параметр выглядит следующим образом.

3.4.4. Параметр типа "blob"

Большая многострочная строка до 65000 символов.

В конфигурации параметра могут быть указаны следующие необязательные параметры:

rows=<rows>
saveOn=<saveOn>

Где:

<rows> - количество отображаемых в редакторе строк, по-умолчанию 4;

<saveOn> - режим сохранения, может быть "focusLost" (потеря фокуса полем) либо "enter" (нажатие кнопки под полем), по-умолчанию режим "enter".

В таблице параметр выглядит следующим образом.

3.4.5. Параметр типа "list"

Параметр с выбираемыми из набора значениями. Значения могут быть определены как конфигурации параметра так и во внешнем справочнике, на который ссылается параметр. Для некоторых значений можно добавить возможность или установить обязательное требование указания комментария.

В конфигурации параметра могут быть указаны следующие необязательные параметры:

# мультивыбор
multiple=1
# сохранение сразу после выбора значения, без нажатия кнопки Ок (только для параметра с одним выбором) 
saveOn=select
#
allowCommentValues=<allowCommentValues>
needCommentValues=<needCommentValues>
#
directory=<dirName>
availableValues=<values>
availableValuesInnerJoinFilter=<joinTable>;<joinColumn>;<joinFilter>

Где:

<dirName> - справочник, из которого берутся значения, может быть "address_city" для городов, если справочника нет - значения указываются в самом параметре;

<values> - допустимые коды значений через запятую;

<allowCommentValues> - перечень значений для которых допустимо указание комментария, возможно указание диапазонов, например: 1-3,7,9-14

<needCommentValues> - перечень значений для которых обязателен комментарий, указывается аналогично <allowCommentValues>;

<joinTable> - имя таблицы, с которой осуществляется фильтрующая операция SQL INNER JOIN справочной таблицы;

<joinColumn> - колонка таблицы, по которой проводится JOIN столбца id справочной таблицы;

<joinFilter> - дополнительное условие INNER JOIN.

Пример конфигурации параметра, в котором доступны контрагенты, входящие в группу с кодом 3.

multiple=1
directory=customer
availableValuesInnerJoinFilter=customer_group;customer_id;group_id IN (3) 

Пример параметра с одним значением. Конфигурация - как выглядит в таблице и редактирование.

Пример параметра с несколькими значениями (мультивыбор). Конфигурация - как выглядит в таблице и редактирование.

3.4.6. Параметр типа "date"

Дата: год - месяц - день.

В конфигурации параметра могут быть указаны следующие необязательные параметры:

# возможность смены месяца
changeMonth=true
# возможность смены года
changeYear=true
yearRange=<yearRange>
# возможность редактирования поля с клавиатуры
editable=1
saveOn=<saveOn>
# при редактировании поля отправка классу-обработчику изменений параметра события ru.bgcrm.event.DateChangingEvent, позволяющего раскрашивать даты различными цветами и сопровождать примечаниями 
#sendColorMapRequest=1

Где:

<yearRange> - диапазон отображаемых лет в выпадающем списке годов, могут быть значения от текущего года (-10:+30) либо значения от текущей выбранной даты (c:-10:c+30), по-умолчанию с-10:с+10;

<saveOn> - режим сохранения, может быть "focusLost" (потеря фокуса полем) либо "enter" (нажатие клавиши "Enter"), по-умолчанию режим "enter"; актуально только при editable=1.

В таблице параметр и его редактор выглядят следующим образом.

3.4.7. Параметр типа "datetime"

Дата + время различной точности.

В конфигурации параметра могут быть указаны следующие необязательные параметры:

type=<type>
stepHour=<stepHour>
stepMinute=<stepMinute>
#
# при редактировании поля отправка классу-обработчику изменений параметра события ru.bgcrm.event.DateChangingEvent, позволяющего раскрашивать даты различными цветами и сопровождать примечаниями 
#sendColorMapRequest=1

Где:

<type> - может принимать значения ymdh, ymdhm, ymdhms в зависимости от требуемой точности поля;

<stepHour> - шаг в выборе часов;

<stepMinute> - шаг в выборе минут.

Пример параметра. Конфигурация, как выглядит в таблице и редактирование.

3.4.8. Параметр типа "address"

Адресный, ссылающийся на дом в справочнике адресов.

В конфигурации параметра могут быть указаны следующие необязательные параметры:

# несколько адресов в параметре
multiple=1

Как выглядит в таблице и редактирование.

Доступен контекстный поиск по подстроке улицы и дому. Несмотря на приведённый пример использовать подобный параметр для адреса прописки не следует, т.к. он требует наличия в справочнике домов записей обо всех домах, используемых в значениях параметров.

Замечание

Формат строки отображаемой в таблице задаётся в конфигурации.

3.4.9. Параметр типа "phone"

Один или несколько телефонов с комментариями.

В конфигурации параметра ничего не указывается.

Как выглядит в таблице и редактирование.

Замечание

Формат строки отображаемой в таблице задаётся в конфигурации.

3.4.10. Параметр типа "email"

Один или несколько EMail адресов либо только адресов доменов с комментариями.

В конфигурации параметра могут быть указаны следующие необязательные параметры:

# несколько EMail в параметре
multiple=1

Как выглядит в таблице и редактирование.

3.4.11. Параметр типа "file"

Один или несколько файлов.

В конфигурации параметра могут быть указаны следующие необязательные параметры:

# несколько файлов в параметре
multiple=1

В таблице параметр выглядит следующим образом.

Подсистема планировщика позволяет выполнять периодический запуск определённых задач. Для запуска задачи в конфигурацию сервера добавляются записи вида:

scheduler.task.<id>.class=<class_name>
scheduler.task.<id>.minutes=<minutes>
scheduler.task.<id>.minutes=<minutes>
# необязательные параметры
scheduler.task.<id>.hours=<hours>
scheduler.task.<id>.dw=<dw>

Где:

Планировщик ежеменутно проверяет задачи и выполняет те из них, чьи ограничения по времени отвечают указанным в конфигурации условиям.

В планировщике может быть запущен любой объект Java-класса, реализующий интерфейс java.lang.Runnable. Класс может быть статическим либо динамическим. Для разового запуска вы можете использовать запуск класса.

Контрагент - физическое лицо либо организация, с которым взаимодействует пользователь BGCRM.

Карточки открытых контрагентов отображаются в буфере Контрагенты. Для создания нового контрагента перейдите в буфер и нажмите Создать. Также кнопка создания доступна в оснастке поиска.

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

На вкладке Параметры редактируются параметры контрагента. На вкладке Процессы отображаются привязанные к контрагенту процессы и возможно создание привязанного процесса (список типов процессов можно ограничить в конфигурации действия).

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

Остальные параметры назначаются с помощью системы параметров для разных типов процессов.

Каждый процесс обслуживается одним или несколькими подразделениями (группами). При этом группа выступает в процессе в той или иной роли. По-умолчанию в системе определена одна роль с кодом 0 - "Выполнение" процесса. Список ролей может быть дополнен в конфигурации. Примерами ролей могут быть: "Инициация", "Продажа", "Согласование" и т.п. У каждой роли должен быть свой уникальный код.

Статус определяет текущее состояние процесса. Позиция статуса определяет порядок его в списке статусов.

Типы процессов представляют из себя дерево.

При редактирование типа может быть указано его название и признак наследования либо не наследования свойств от родительского типа.

В свойствах типа указываются следующие параметры:

Далее описываются параметры конфигурации типа процесса, поддержанные ядром. Параметры, поддерживаемые различными плагинами, описываются в разделах документации соответствующих плагинов.

В конфигурации типа процесса может быть указано:

# код параметра - категории, который должен быть указан перед переводом процесса в конечный статус
categoryParamId=<param_code>
# требование заполненности параметров перед установкой статуса, одна или несколько записей вида
requireFillParamIdsBeforeStatusSet.<status_to_code>=<param_codes>
# при создании процесса занесение в исполнители создавшего пользователя
setExecutor=current
# скрытие в редакторе процесса смены исполнителей
hideExecutors=1
# скрытие в редакторе процесса смены приоритета
hidePrioprity=1
# скрытие в редакторе процесса просмотра сообщений
hideMessages=1
# скрытие в редакторе процесса кнопки полного изменения описания
hideDescriptionChange=1
# скрытие в редакторе процесса кнопки добавления в описание процесса
hideDescriptionAdd=1
# сокрытие (0) либо отображение 1 (на вкладке), 2 (в левой части карточки процесса) в процессе привязок
processShowLinks=1
# сокрытие (0) либо отображение 1 (на вкладке) сообщений, связанных с процессом
processShowMessages=1
# требования указания обязательного комментария при переводы в статусы
requireChangeCommentStatusIds=<status_ids>
# сокрытие параметров в том или ином статусе, одна или несколько записей вида
hideParamIdsInStatus.<status_code>=<param_codes>
# параметры, редактор для которых скрыт в данном типе процесса (заполняются программно)
readonlyParamIds=<param_codes>
# шаблон текста при добавлении в описание процесса текста кнопкой "Добавить"
descriptionAddPattern=\n[${time} ${user}]\n\t${text}
# JSP шаблон для отображения карточки процесса вместо стандартного /WEB-INF/jspf/user/process/process/process.jsp, выполняйте рекомендации
#processCardJsp=/WEB-INF/jspf/user/process/process/custom/process_jur/zayavka.jsp

Где:

executorRestriction.<n>.groupId=<groupId>
executorRestriction.<n>.maxCount=<maxCount>

5.5.2. Настройка связки процессов между собой

Процесс может ссылаться на другой процесс следующими способами:

Ссылается - простая ссылка одного процесса на другой;

Порождён - указание, что ссылаемый процесс создан из данного процесса;

Зависит - процесс не может быть закрыт пока не закрыты все процессы на которые он ссылается данным способом.

Параметры в конфигурации типа процесса:

processShowProcessLinks=1 - отображение в карточке процесса вкладки со связями процесса с другими процессами;

processCreateLinkModeSelect=1 - привязка к процессу произвольных открытых процессов (цифра 3 на снимке далее).

Рассмотрим отображаемые на снимке экрана области В таблице 1 отображаются процессы, которые ссылаются на текущий процесс. В таблице 2 - те процессы, на которые ссылается текущий процесс.

Замечание

Кнопки удаления связей должны быть включены специальной опцией в конфигурации действия "Удаление привязки".

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

Выпадающий список 4 - позволяет создать процесс и привязать к данному процессу. Содержимое списка определяется записями в конфигурации типа процесса вида:

processCreateLink.<n>.title=<title>
processCreateLink.<n>.processTypeId=<typeId>
processCreateLink.<n>.linkType=<linkType>
# необязательные параметры
#processCreateLink.<n>.checkExpression=<expression>
#processCreateLink.<n>.copyParams=<copyRules>
# копирование привязок
#processCreateLink.<n>.copyLinks=1

Где:

<n> - порядковый номер записи;

<title> - наименование для списка;

<linkType> - тип связи: "processLink" - ссылается, "processMade" - порождён, "processDepend" - зависит;

<typeId> - код типа создаваемого процесса;

<expression> - JEXL выражение, позволяющее показывать пункт списка в зависимости от условий;

<copyRules> - через запятую коды копирующихся с текущего на создаваемый параметров, либо пары <from>:<to> - кодов однотипных параметров с какого на какой необходимо копировать.

В JEXL процессор передаются объекты:

processParam - объект класса ru.bgcrm.dao.expression.ParamValueFunction - параметры процесса.

Пример конфигурации. Создаётся ссылаемый процесс с кодом типа 9244, запись отображается в списке только если значение параметра с кодом 227 равно 1.

processShowProcessLinks=1
processCreateLink.1.title=Авария
processCreateLink.1.processTypeId=9244
# processLink - ссылается, processMade - порождён
processCreateLink.1.linkType=processLink
#processCreateLink.1.checkExpression=processParam: getParamValue(227) == 1
#processCreateLink.1.copyParams=48,46,150,151
processCreateLink.1.copyLinks=1

create.in.objectTypes=<типы объектов через запятую>
create.in.copyParams=перечень пар <с параметра>:<на параметр>, разделённых точкой с запятой
# открывать (1) либо не открывать (0) вкладку с созданным привязанным процессом
create.in.<тип объекта>.openCreated=1

create.in.objectTypes=customer
create.in.copyParams=1:3;5:6

5.5.4. Описание процесса

Макрос описаний процесса позволяет сгенерировать текст для заголовка вкладки процесса или для перечня процессов.

Для генерации описаний в конфигурацию типа процесса добавляются записи вида:

processReference.<n>.objectTypes=<objectTypes>
processReference.<n>.stringExpression=<macros>

Где:

<n> - порядковый номер записи;

<objectTypes> - области, где используется данный макрос через запятую, перечень областей см. далее;

<macros> - JEXL выражение, передаваемые объекты см. далее.

Перечень областей:

customer - вкладка Процессы контрагента;

processCard - заголовок вкладки процесса;

linkedProcessList - список процессов к которым привязан данный процесс;

linkProcessList - список процессов, привязанных к данному.

В JEXL процессор передаются объекты:

process - объект класса ru.bgcrm.model.process.Process - процесс;

processParam - объект класса ru.bgcrm.dao.expression.ParamValueFunction - параметры процесса.

processLink - объект класса ru.bgcrm.dao.expression.ProcessLinkFunction для работы с привязками процесса.

Кроме того доступны переменные устанавливаемые в ru.bgcrm.servlet.filter.SetRequestParamsFilter.

Пример конфигурации для генерации описания списке процессов контрагента из адреса и перечня услуг и на вкладке процесса из наименования контрагента и адреса:

processReference.1.objectTypes=customer
processReference.1.stringExpression=u.toString( processParam.addressValues( 90, 'fromStreet' ) ) + " : " + u.toString( processParam.listValueTitles( 238 ) )
processReference.2.objectTypes=processCard
processReference.2.stringExpression="Запрос док. ОИО: " + u.escapeXml( u.toString( processLink:linkTitles( "customer" ) ) ) + "<br/>" + u.escapeXml( u.toString( processParam:addressValues( 90, 'fromStreet' ) )  ) + "&nbsp;"

Как выглядит в интерфейсе.

onProcessEvent.<n>.commands=<commands>
onProcessEvent.<n>.events=<events>
onProcessEvent.<n>.eventsExclude=<eventsExclude>
# необязательные параметры
onProcessEvent.<n>.ifExpression=<ifExpression>
onProcessEvent.<n>.checkExpression=<expression>
onProcessEvent.<n>.checkErrorMessage=<message>

changeControl.1.checkExpression=process:getStatusId() !~ [9, 13, 36,39] or 8 =~ user:getGroupIds()
changeControl.1.checkErrorMessage=В этом статусе разрешена правка только сотрудникам КС
changeControl.2.checkExpression=process:getStatusId() != 9 or user:getId()  =~ process:getExecutorIds() or 33 =~ user:getPermsetIds()
changeControl.2.checkErrorMessage=В этом статусе разрешена правка только исполнителем процесса либо администратором КС
changeControl.3.checkExpression=empty process:getCloseTime()
changeControl.3.checkErrorMessage=Запрещена правка закрытого процесса

onProcessEvent.1.events=createdAsLink
onProcessEvent.1.commands=addExecutors:{@ctxUserId};setStatus:40

onProcessEvent.1.events=messageAdded
onProcessEvent.1.ifExpression=process:getStatusId() != 3
onProcessEvent.1.commands=setStatus:3

Карточка процесса открывается в буфере Процессы и позволяет редактировать свойства уже созданного процесса.

В левой области расположены основные свойства процесса и ссылки для их редактирования. Далее настроенные для процесса параметры.

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

Система сообщений позволяет организовать обмен различными типами сообщений с привязкой их к процессам. В данный момент поддержаны только сообщения типа EMail.

Типы сообщения настраиваются в конфигурации, одна или несколько записей вида:

messageType.<id>.title=<title>
messageType.<id>.class=<class_name>

Где:

Остальные параметры различаются для разных видов сообщений.

messageType.<id>.email=<email>
messageType.<id>.host=<host>
messageType.<id>.login=<login>
messageType.<id>.pswd=<pswd>
messageType.<id>.folderIn=<inFolder>
messageType.<id>.folderProcessed=<processedFolder>
messageType.<id>.folderSkipped=<skippedFolder>
messageType.<id>.folderSent=<sentFolder>
# необязательные параметры
messageType.<id>.folderInProcessLinked=<inProcessedFolder>

messageType.1.title=billing@bitel.ru
messageType.1.class=ru.bgcrm.dao.message.MessageTypeEmail
messageType.1.email=billing@bitel.ru
messageType.1.host=imap.ufamail.ru
messageType.1.login=billing@bitel.ru
messageType.1.pswd=*****
messageType.1.folderIn=INBOX.CRM
messageType.1.folderInProcessLinked=INBOX
messageType.1.folderProcessed=INBOX.CRM_PROCESSED
messageType.1.folderSkipped=INBOX.CRM_SKIPPED
messageType.1.folderSent=INBOX.CRM_SENT

Получение новых сообщений и отправку созданных в BGCRM осуществляет класс ru.bgcrm.worker.MessageExchange, настройте его запуск в планировщике.

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

Открытое сообщение:

При обработке сообщение должно быть помечено как обработанное и быть привязанным к существующему процессу (необходимо указать его код) либо к вновь созданному. При создании процесса система ищет по адресу отправителя сообщения контрагентов, которые могут быть соотнесены с процессом. Для EMail поиск производится по параметру типа EMail по точному совпадению либо указанному в контрагенте домену.

Созданному процессу возможно сразу установить группу решения, исполнителя, параметры.

Отображение вкладки сообщений должно быть настроено в конфигурации типа процесса.

Для создания сообщения в рамках процесса используйте кнопку Создать, для ответа на сообщение - кнопку A рядом с каждым сообщением. Ответы на сообщения автоматически будут разнесены в процесс. Пометку процессов с новыми сообщениями можно реализовать переключением статуса процесса по событию поступления сообщения.

Организация работ - общее название раздела системы, предназначенного для организации учета рабочего времени. Основной рабочий элемент - График Дежурств.

Виды работ - это описание типов деятельности по отношению к той или иной группе пользователей (чем именно они занимаются и какое время на это тратится).

Каждый вид работы содежрит название, цвет (для визуального отличия в Смене или на Графике Дежурств) и правила.

Кажде правило содержит: Процессы (один или несколько), Услуги (одна или несколько), Продолжительность.

Где:

Для настройки списка Услуги необходимо создать списковый параметр процесса, пример:

Далее, необходимо в конфигруции указать значение параметра callboard.serviceListId равное id спискового параметра Услуги. Для примера выше:

#id параметра Услуги
callboard.serviceListId = 63

Допускается создание вида работы без правил (пустой тип).

Смена - это перечень видов работ, с указанием временного промежутка, отведенного на тот или иной тип работы.

При определенном количестве контрагентов стандартная СУБД MySQL не всегда должным образом может справляться с нагрузкой, вызываемой поиском контрагентов, что может приводить к увеличению времени обработки запросов. Для повышения скорости и разгрузке основной базы при поиске контагента по ФИО, адресу, году рождения и другим параметрам существует возможность интеграции BGCRM с системой полнотекстового поиска Sphinx.

Из репозиториев необходимо установить дистрибутив Sphinx версии не ниже 2.0.6. В конфигурационном файле, который находится обычно (зависит от дистрибутива) в /etc/sphinx/sphinx.conf описываем конфигурацию:

# название индекса
index customer 
{
        # real-time тип индекса
        type            = rt               
        # путь хранения             
        path            = /var/local/sphinx/customer    
        morphology      = stem_ru
        min_word_len    = 1
        charset_type    = utf-8
        enable_star     = 1
        #min_prefix_len = 2
        #min_infix_len  = 2

        # атрибутиы индекса
        # id
        rt_field        = index                         
        # ФИО или название организации
        rt_attr_string  = title                      
        # полная строка описание контрагента с параметрами, по которой осуществляется поиск   
        rt_attr_string  = reference                  
}

searchd
{
        # слушаем порт 9306, тип совместимый с mysql
        listen          = 9306:mysql41
        # логи сервера                  
        log             = /var/log/sphinx/sphinx.log
        # лог запросов    
        query_log       = /var/log/sphinx/query.log     
        binlog_path     = /var/log/sphinx/
        pid_file        = /var/run/sphinx/sphinx.pid
        read_timeout    = 5
        max_children    = 30
        # максимальное количество выводимы совпадений
        max_matches     = 5000                          
        workers         = threads
}

Запуск осуществляется стандартным для *nix систем образом:

# /etc/init.d/searchd start

После запуска можно удостовериться, что демон действительно запущен:

# netstat -nlptu
...

tcp 0 0 0.0.0.0:9306:* LISTEN 27095/searchd

Так как тип выбирали совместимый с MySQL, то мы можем подключиться к серверу Sphinx стандартным клиентом для MySQL:

# mysql -h 127.0.0.1 -P 9306

Для интеграции со Sphinx в Конфигурации нужно настроить следующие пункты:

# включить поиск в кэше
sphinx.enable=<flag>
# URL/IP на котором находится сервер sphinx
sphinx.url=<url>
# номер порта, прослушиваемый sphinx
sphinx.port=<port>
# максимальное время в секундах, через которое измененный контрагент будет перекэширован
sphinx.cacheTimeout=<seconds>
# максимальное количество контрагентов, которое может быть отправлено в кэш за один раз
sphinx.cacheLimit=<count>
# список параметров контрагента, по которым ведется поиск в кэше
sphinx.customerParamIds=<paramIds>

Где:

<flag> - 1, если поиск необходимо включить, любое другое значение отключает поиск

<url> - URL, либо IP-адрес хоста, на котором настроен Sphinx

<port> - номер порта сервера Sphinx

<seconds> - максимальное время в секундах, через которое измененный контрагент будет перекэширован

<count> - максимальное количество контрагентов, которое может быть отправлено в кэш за один раз

<paramIds> - id параметров контрагента, указанные через запятую

Пример конфигурации:

sphinx.enable=1
sphinx.url=127.0.0.1
sphinx.port=9306
sphinx.cacheTimeout=300
sphinx.cacheLimit=500
sphinx.customerParamIds=73,12,248

Также наобходимо настроить задачу в планировщике, которая периодически отправляет в кэш контрагентов, у которых изменялись параметры:

scheduler.task.<number>.class=<className>
scheduler.task.<number>.minutes=<minutes>

Пример:

scheduler.task.4.class=ru.bgcrm.dyn.sphinx.SphinxCache
scheduler.task.4.minutes=5,10,15,20,25,30,35,40,45,50,55,60

После этого в графическом интерфейсе появится поле, которое использует при поиске кэш:

Система BGCRM является в первую очередь платформой, поэтому значительный эффект от её применения достигается путём реализации различного рода расширений под спицифику пользователя. Вы можете пропустить данный раздел целиком при первичном знакомстве с системой.

Динамический код - это Java файлы, которые можно изменять и подгружать без перезапуска приложения. С его помощью можно обрабатывать различные события в системе. Файлы с классами динамического кода располагаются в по-умолчанию каталоге dyn. Динамические классы рекомендуется создавать в пакете ru.bgcrm.dyn.<дальнейшая иерархия пакетов>.

Для написания динамического кода возможно использование как простого текстового редактора, так и полноценные IDE для Java разработки. Методология при этом аналогична примяемой для разработки в BGBilling.

Компиляция динамического кода осуществляется на вкладке Динамический код интерфейса администратора. Можно скомпилировать только все классы сразу. При успешной компиляции динамический код применяется также целиком.

Создаваемые динамические классы - обработчики событий должны расширять абстрактный класс ru.bgcrm.event.listener.DynamicEventListener. Информацию по типам событий можно получить из API документации к системе в формате JavaDoc.

<crmUrl>/admin/dynamic.do?action=runDynamicClass&class=<className>&param1=value&param2=..

Пользовательские JSP страницы располагайте в каталогах WEB-INF/jspf/.../custom/.., это гарантирует вас от перетирания названия каталога штатными шаблонами.

Например: "/WEB-INF/jspf/user/process/process/custom/process_jur/zayavka.jsp".

Все запросы на изменение данных в возвращают результат в JSON формате. Запросы выборки данных возвращают результат в HTML формате, однако возможно получение данных и в JSON формате, путём добавления в запрос параметра responseType=json.

Для прозрачной авторизации запроса сторонней системы логин и пароль пользователя могут быть переданы в запросе в HTTP параметрах запроса j_username и j_password соответственно. Параметр authToSession=0 в запросе указывает на хранение отсутствие необходимости в HTTP сессии. Настоятельно рекомендуется использовать его при запросах внешних систем, т.к. предотвращение создания HTTP сессий экономит память BGCRM.

Пример запроса на получение данных во внешнюю систему в JSON формате (выборка по очереди процессов):

http://ncrm.core.ufanet.ru/user/process.do?action=queueShow&id=4&dateStatusStatus=10&status=10&status=9&status=13&currentUserMode=&group=7&sort=0&j_username=shamil&j_password=*****&responseType=json&authToSession=0

При изучении формата запросов и ответов возможно использование FireBug или иного инструмент разработчика в браузере с возможность просмотра запросов, в данный момент описания формата запросов нет. Т.е. получение протокола взаимодействия доступно только путём мониторинга вида запросов, отправляемых браузером при работе пользователя в BGCRM.

Для запуска любого класса, статического или динамического в контексте сервера BGCRM вызовите:

./crm.sh "runclass <class_name>"

Где <class_name> - полное имя класса с пакетом. Класс должен реализовывать интерфейс java.lang.Runnable.

Запуск в контексте сервера обозначает, что класс будет выполнен в рамках отдельного потока процесса сервера, получив доступ к соединению с БД, конфигурациям и другим объектам контекста. Результаты работы можно выводить в логи.

Для периодического выполнения класса необходимо использовать планировщик.

Для добавления биллингов в конфигурации сервера добавляют конструкции вида:

bgbilling:server.<n>.id=<id>
bgbilling:server.<n>.title=<title>
bgbilling:server.<n>.url=<url>
bgbilling:server.<n>.version=<version>
bgbilling:server.<n>.customerIdParam=<paramId>

Где:

Например:

bgbilling:server.1.id=bitel
bgbilling:server.1.title=BiTel
bgbilling:server.1.url=http://billing.office.bitel.ru/executer
bgbilling:server.1.version=5.2
bgbilling:server.1.customerIdParam=100

Дополнительно для каждого сервера могут быть указаны необязательные параметры:

bgbilling.<n>.contract_pattern.<pat_num>.title_pattern=<pattern>
bgbilling.<n>.crm.problem.status.list=<status_list>
bgbilling.<n>.copyParamMapping=<mapping>

Где:

В параметре <mapping> могут быть определены разделённые точкой с запятой значения вида <cust_id>:<billing_id>.

Где:

Например:

bgbilling:server.11.copyParamMapping=15:9;72:46;73:5;74:51;75:68;76:69;77:56;78:7;14:8;12:6;109:48;110:50;114:12;115[1,2]:25[4,3];customerTitle:1

Обращение к биллингу осуществляется с использованием логина и пароля пользователя BGCRM. Возможна установка отличного логина и пароля в конфигурации пользователя:

bgbilling:login=<login>
bgbilling:password=<pswd>

Для системы BGBilling обращения плагина выглядят так же как и обращения обычного пользователя биллинга, аналогично действуют ограничения прав.

Единый договор - это привязанный к адресу номер-префикс, с которым создаются договора услуг на данном адресе. Договора услуг могут быть созданы в различных биллиингах. Номер договора услуги начинается с номера единого договора и заканчивается кодом услуги. Номер единого договора начинается с префикса области, далее следует порядковый номер.

Для включения функционала единого договора в конфигурации сервера необходимо добавить:

# код параметра контрагента с адресами услуг, параметр должен поддерживать множественное значение
bgbilling:commonContract.customerAddressParamId=<customerParamId>
# код параметра "Адрес" единого договора, параметр необходимо создать в редакторе параметров
bgbilling:commonContract.addressParamId=<commonContractParamId>
# соотношение областей городам
bgbilling:commonContract.cityAreaIds=<city_areas>
# формат номера единого договора, состоит из кода области и  порядкового номера в области
bgbilling:commonContract.titleFormat=(${area:00})(${number:000000})
# формат номера сервисного договора в биллинге, разрешено изменять только длину кода типа (:00)
bgbilling:commonContract.serviceContractTitleFormat=(${common})(${type:00})

Где:

Пример:

bgbilling:commonContract.customerAddressParamId=12
bgbilling:commonContract.addressParamId=93
bgbilling:commonContract.titleFormat=(${area:00})(${number:000000})
bgbilling:commonContract.serviceContractTitleFormat=(${common})(${type:00})
bgbilling:commonContract.cityAreaIds=37:51;1:72

Единые договора создаются в карточке контрагента.

Это договоры, которые могут быть созданы в привязке к контрагенту в его карточке. Договоры услуг могут быть как связаны с единым договором, там и создаваться независимо от него, при этом нумерацию осуществляет биллинг. Для добавления договора услуги в конфигурации указываются одна или несколько записей вида:

bgbilling:contractType.<n>.title=<title>
bgbilling:contractType.<n>.billing=<billing_id>
bgbilling:contractType.<n>.patternId=<pattern_id>
bgbilling:contractType.<n>.tariffList=<tariff_list>
# указывается только при использовании единых договоров
# необязательно - код области ЕД, договор данного типа можно создавать только для ЕД в данной области
bgbilling:contractType.<n>.commonContractAreaCode=<area_code>
bgbilling:contractType.<n>.serviceCode=<service_code>

Где:

Общее описание алгоритма импорта:

Для настройки импорта контрагентов из базы договов биллинга добавьте в конфигурацию правила импорта:

bgbilling:creator.confirmParameters=<confirm_params>
bgbilling:creator.searchParameters=<search_params>
bgbilling:creator.titleDistance=<title_dist>
bgbilling:creator.importParameters=<import_params>

Где:

Далее одно или несколько правил определения группы контрагента из номера договора:

bgbilling:creator.parameterGroupRule.<id>.paramGroupId=<param_group>
# необязательный параметр, если шаблона нет - то группа выставляется всем контрагентам
bgbilling:creator.parameterGroupRule.<id>.contractTitlePattern=<title_pattern>

Где:

И для каждого из серверов биллинга записи:

#
bgbilling:creator.server.<id>.billingId=<billing_id>
bgbilling:creator.server.<id>.user=<user>
bgbilling:creator.server.<id>.pswd=<pswd>
bgbilling:creator.server.<id>.paramMapping=<mapping>
bgbilling:creator.server.<id>.pageSize=<page_size>
#

Где:

При импорте поддерживаются параметры договоров и, соответственно, контрагентов типа: "дата", "текст", "адрес", "телефон", "список". Параметры дата и текст перетирают значение параметра в договора, адрес, телефон и список - дополняют.

Пример конфигурации импорта контрагентов:

# загрузчик контрагентов
# дата рожд, адреса  услуг, сот. телефон(ы), паспорт с.-н.
bgbilling:creator.confirmParameters=73,12,14,74
# поиск по с.-н. паспорта, адресам услуг, сот. телефонам
bgbilling:creator.searchParameters=74,12,14
# расстояние по Левинштейну
bgbilling:creator.titleDistance=2
# кодовая фр., дата рожд., с.-н. пасп., д.в. пасп., кем выд. пасп, адрес проп., тел. гор, тел. сот, адрес(а) усл.
bgbilling:creator.importParameters=72,73,74,75,76,77,78,14,12
#
# группа параметров контрагента
bgbilling:creator.parameterGroupRule.1.paramGroupId=3
#
bgbilling:creator.server.1.billingId=ds
bgbilling:creator.server.1.user=bgcrm
bgbilling:creator.server.1.pswd=bgcrmv2
bgbilling:creator.server.1.paramMapping=72:456;73:386;74:457;75:458;76:459;77:460;78:401;14:399;12:42;46:378;115[1,2]:421[14575,14576]
bgbilling:creator.server.1.pageSize=10
#
bgbilling:creator.server.2.billingId=tks
bgbilling:creator.server.2.user=bgcrm
bgbilling:creator.server.2.pswd=bgcrmv2
bgbilling:creator.server.2.paramMapping=72:95;73:51;74:96;75:97;76:98;77:99;78:59;14:60;12:9,80,83
bgbilling:creator.server.2.pageSize=10

Импорт контрагента можно инициировать вручную в карточке договора, либо настроить в планировщике.

scheduler.task.1.class=ru.bgcrm.plugin.bgbilling.creator.CustomerCreator
scheduler.task.1.minutes=2,12,22,32,42,52

В конфигурацию типа процесса возможна установка следующих параметров.

Для автоматического добавления групп решения процесса по названию либо биллингу привязанного договора одна или несколько правил вида:

bgbilling:processLinkedContract.<n>.groupIds=<groupIds>
bgbilling:processLinkedContract.<n>.titleRegexp=<titleRegexp>
bgbilling:processLinkedContract.<n>.billingIds=<billingIds>   

Где:

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

create.in.objectTypes=<типы объектов через запятую>

Для вкладки документов карточки единого договора в конфигурации типов документов указывать scope=bgbilling-commonContract, для документов карточки договора scope=bgbilling-contract.

<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 xmlns:xs="http://www.w3.org/2001/XMLSchema" 
 xmlns:bgcrm="http://bgcrm.ru/saxon-extension"
 xmlns:bgcrm-math="http://bgcrm.ru/saxon-extension-math"
 xmlns:t="http://bgcrm.ru/template" 
 exclude-result-prefixes="bgcrm bgcrm-math t"
 version="2.0">
...
<xsl:template match="/event">
 <data>
   <xsl:variable name="commonContract" select="bgcrm:bgbilling-commonContract(@objectId)" />
...
<xsl:variable name="ktvContractId" select="$customer/data/links/customer_link[@object_title=$ktvContractNumber]/@object_id" />
<xsl:variable name="contractCard" select="bgcrm:bgbilling-contractCard( 'tks', 'bgcrm:XXXXXX', $ktvContractId )" />
...