ОПИСАНИЕ

ФУНКЦИОНАЛЬНЫХ ХАРАКТЕРИСТИК ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ


“Отраслевое решение в Synergy CRM 2.0 для управления процессом производства (Synergy CRM v. 2.0)”

СОДЕРЖАНИЕ


ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ И ОБОЗНАЧЕНИЙ
ВВЕДЕНИЕ
1.1Описание архитектуры существующей системыSynergy CRM
1.2Доработка архитектуры системы SynergyCRM
1.3Архитектура коробочной версии системыSynergy CRM
1.4 Архитектурные паттерны и решения, которые будут использованы в ходе разработки приложения SynergyCRM для ОС Android
1.5 Архитектурные паттерны и решения, которые будут использованы в ходе разработки приложения Synergy CRM для ОС iOS
2Доработка модуля Склад, а именно разработка операций приемки, разгрузки, размещения и хранения, формирования отправок, выдачи, отборки, комплектования, списания, инвентаризации, оприходования, списания
2.1Цель и задачи доработки модуля Склад
2.2Описание функционала доработанных операций
2.3Описание разработки доработанных операций
2.4Особенности расчетов и реализаций основных операций модуля «Склад»
3Интеграция системы Synergy CRM с сервисом отслеживания грузоперевозок
4 Разработка специализированного отраслевого шаблона документа «Смета» в модуле Документооборот
4.1Цели и задачи разработки шаблона документа «Смета»
4.2 Описание разработки CRUD методов для создания шаблона документа «Смета»
5Разработка 1С-коннектора
5.1Цели и задачи разработки 1С-коннектора
5.2Разработка алгоритмов и выбор средств для реализации 1С-коннектора
5.3Разработка API документации
5.4Разработка 1С скриптов
6 Разработка мобильного приложения под Android: рефакторинг кода, переработка макета приложения, определение лучшего стека технологий и разработка приложения, тестирование,
раскатка приложения на торговых площадках
7Разработка модуля интерактивного онбординга по системе SynergyCRM
7.1Цели и задачи разработка модуля интерактивного онбординга
7.2Модуль управления обучением «Знакомство»
7.3Модуль управления обучением «Рабочий стол»
7.4Модуль управления обучением «Раздел Компании»
8Разработка BPMN-конструктора автоматизаций
8.1Цели и задачи разработки BPMN-конструктора автоматизаций
8.2Разработка и реализация BPMN-конструктора автоматизаций
9Разработка модуля Согласования
9.1Цели и задачи разработки модуля Согласование
9.2Разработка и реализация модуля Согласование
10Разработка модуля Проекты
10.1 Цели и задачи разработки модуля Проекты
10.2 Разработка и реализация модуля Проекты
11Разработка мобильного приложения под iOS
12Разработка коробочной версии системыSynergy CRM

ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

●Agile методология – подход к управлению проектами, предполагающий разбивку проекта на этапы, а также непрерывное сотрудничество и совершенствование; в рамках этого подхода команды следуют циклу планирования, выполнения и оценки
●Elasticsearch – поисковая система, основанная на библиотеке Lucene;предоставляет распределенную полнотекстовую поисковую систему с поддержкой нескольких пользователей с веб-интерфейсом HTTP и документами JSON без схем.
●CustomView – способ инкапсуляции части UI; позволяет вынести интерфейс в отдельный блок и использовать его снова
●Haml – язык разметки для упрощенного создания HTML
●Javascript – мультипарадигменный язык программирования; поддерживает объектно- ориентированный, императивный и функциональный стили; является реализацией спецификации ECMAScript (стандарт ECMA-262 [1, 2])
●Kafka – гибрид распределенной базы данных и брокера сообщений с возможностью горизонтального масштабирования; Kafka собирает у приложений данные, хранит их в своем распределенном хранилище, группируя по топикам, и отдаёт компонентам приложения по подписке; сообщения хранятся на различных узлах-брокерах, что обеспечивает высокую доступность и отказоустойчивость
●Kanban – это методология Agile, которая помогает командам непрерывно поставлять результаты; Kanban-команды организуют свою работу на доске Kanban с помощью карточек, столбцов, лимитов незавершенной работы, конкретных обязательств и точек поставки
●Postgres – система управления базой данных
●PostgreSQL – свободная объектно-реляционная СУБД
●Redis – это нереляционная резидентная СУБД, хранящая данные в виде пар «ключ-значение»
●Relog – международная компания, разрабатывающая облачные сервисы для оптимизации транспортной логистики; разработанные продукты данной компании позволяют существенно сократить транспортные расходы и управлять даже самой сложной логистикой
●Ruby – динамический, рефлективный, интерпретируемый высокоуровневый язык программирования, обладает независимой от операционной системы реализацией многопоточности, сильной динамической типизацией, сборщиком мусора и многими другими возможностями
●Ruby on Rails – фреймворк, написанный на языке программирования Ruby, реализует архитектурный шаблон Model-View-Controller для веб-приложений, а также обеспечивает их интеграцию с веб-сервером и сервером баз данных; является открытым программным обеспечением и распространяется под лицензией MIT
●Scrum – agile-методика, с помощью которой команды могут структурировать работу посредством коротких циклов разработки, называемых спринтами; Scrum-команды обязуются поставлять результат в конце каждого спринта и внедряют практики и структуру команды, которые помогают им достичь этой периодичности
●Sequence diagrams – UML-диаграмма, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл объекта (создание-деятельность-уничтожение некой сущности) и взаимодействие акторов (действующих лиц) информационной системы в рамках прецедента
●WebSocket – протокол связи поверх TCP-соединения, предназначенный для обмена сообщениями между браузером и веб-сервером, используя постоянное соединение
●Автоматизация – скрипт внутренней системы, позволяющий автоматизировать действия пользователей
●Вебхук – это программный код, с помощью которого отслеживают изменения на одном сайте и передают данные об этом на другой
●Диаграмма Ганта – инструмент управления проектами, иллюстрирующий то, как выполняется запланированная работа с течением времени; обычно состоит из двух частей: в левой части приведен список заданий, а в правой– временная шкала с полосами, которые изображают работу; включает даты начала и завершения заданий, контрольные точки, зависимости между заданиями и исполнителей
●Доска (Рабочий стол) – сущностьSynergy CRM
●Задача – поставленная цель, которую стремятся достигнуть или вопрос, требующий решения на основании определенных знаний и размышления.
●Интеграция – синхронизированное функционирование сайта и других специализированных программ на уровне бизнес-взаимодействия корпоративных ресурсов с локальными информационными системами, при котором изменения в одном звене общей системы влияют на другие

●Каркас приложения – иерархия контекстных данных приложения, расположение различных страниц и потоков UX
●Микросервис – средство организации приложения с помощью нескольких независимых однофункциональных протоколов или сервисов
●Монолит – приложение, состоящее из одной большой кодовой базы, которая включает в себя все компоненты: код фронтенда, код бэкенда и файлы конфигурации
●Проект – временное предприятие, направленное на создание уникального продукта, услуги или результата
●Спринт – короткий временной интервал, в течение которого Scrum-команда выполняет заданный объем работы
●Сценарий автоматизации – создаваемый в Synergy CRM сценарий, позволяющий автоматизировать бизнес-процесс
●Сущность – объект Synergy CRM наделенный различными свойствами (к примеру: заявка, задача, и др.)
●Фреймворк – программная платформа, определяющая структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта
●Чарты Helm (Helm Charts) – пакеты Helm, состоящие из файлов и шаблонов YAML, которые преобразуются в файлы манифеста Kubernetes; могут повторно использоваться кем угодно и в любой среде, что уменьшает сложность и количество дубликатов; предназначены для автоматического развертывания копий приложения в k8s
ПЕРЕЧЕНЬ СОКРАЩЕНИЙ И ОБОЗНАЧЕНИЙ
●API (Application Programming Interface) – описание способов взаимодействия одной компьютерной программы с другими
●API-ключ –ключи шифрования для аутентификации пользователя в системе, по аналогии логина и пароля
●BPMN (Business ProcessModel and Notation) – система условных обозначений (нотация) и их описания в XML для моделирования бизнес-процессов
●DI (Dependency Injection) – внедрение зависимости
●FTP (File TransferProtocol) – протокол передачи файлов по сети
●GUI (Graphical User Interface) – графический интерфейс пользователя
●JSON (JavaScript ObjectNotation) – текстовый формат обмена данными
●HFS (HTTP File Server)) – свободно распространяемое программное обеспечение, позволяющее очень быстро организовать файловый веб-сервер в ОС Windows
●HTML (Hyper Text Transfer Protocol) – язык гипертекстовой разметки
●HTTP (Hyper Text Transfer Protocol) – протокол сетевого уровня передачи гипертекста
●CRM (Customer Relationship Management) – Система управления взаимоотношениями с клиентами, прикладное программное обеспечение для организаций, предназначенное для автоматизации стратегий взаимодействия с заказчиками (клиентами)
●CRUD (Create Read Update Delete)– стандартные API методы (создание сущностей, чтение данных, обновление данных и удаление данных)
●CSS (Cascading Style Sheets) – каскадные таблицы стилей;
●KMM (Kotlin Multiplatform Mobile) – средства разработки ПО, предназначенные для упрощения разработки кроссплатформенных приложений для мобильных устройств
●MinIO – объектное хранилище с открытым кодом, совместимое с Amazon S3 API
●MIT (Massachusetts Institute of Technology) – Массачусетский технологический институт
●MVP (Minimum ViableProduct) – Минимально жизнеспособный продукт
●MVVM (Model, View и ViewModel) – Шаблон проектирования
●PVC (Persistent Volume Claim) – Хранилище данных в Kubernetes
●REST (REpresentational State Transfer) – архитектурный стиль взаимодействия компонентов распределенного приложения в сети
●k8s (Kubernetes) – открытое программное обеспечение для оркестровки контейнеризированных приложений; осуществляет автоматическое развёртывание, масштабирование и координацию приложений в условиях кластера
●TCP (Transmission ControlProtocol) – протокол управления передачей
●TDD (Test-Driven Development) – техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам
●TPL – расширение файла, файл с расширением .tpl представляет собой файл шаблона, созданный и используемый файловым сервером HTTP (HFS), который представляет собой прикладную программу для обмена файлами для отправки и получения файлов по веб-технологии HTTP вместо протокола FTP. Он используется для динамического построения HTML страниц на основе информации о шаблоне, которая определена как имеющая настройки с аналогичным макетом, стилем и сценариями.
●UML (Unified ModelingLanguage) – унифицированный язык моделирования
●UX (User Experience) – впечатление пользователя от работы с интерфейсом; определяет может ли пользователь достичь цели и на сколько просто или сложно это сделать
●XML (eXtensible Markup Language) – расширяемый язык разметки
●YAML (Yet AnotherMarkup Language) – дружественный формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования
●БД – локальная база данных для хранения объектов
●ИС – информационная система
●ОС – операционная система
●ПО – программное обеспечение
●СУБД – система управления базами данных

●ТМЦ – товарно-материальная ценность

ВВЕДЕНИЕ

Разработка современных CRM-систем (Customer Relationship Management) направлена на создание системы взаимоотношений бизнеса с клиентами с целью увеличения продажи и прибыль и заключается в выборе правильной стратегии по систематизации данных, автоматизации рутинных операций, координирования работы сотрудников, легкой и удобной идентификации клиентов, оптимизацию процессов компании. Актуальность выполнения данной работы обусловлена низкой степенью цифровизации промышленных предприятий; отсутствием решений для автоматизации промышленности, которые можно было бы внедрять с нулевым вовлечением разработчиков и высококвалифицированных программистов; отсутствием отраслевых решений, учитывающих потребности производственных предприятий; отсутствием CRM-систем, которые могут бесшовно интегрироваться с учетными системами и складскими программами.

В настоящий момент ведутся активные исследования в области развития и совершенствования CRM- систем. Так, в статье [3] рассмотрены принципы построения CRM-стратегии, позволяющие построить и укрепить связи с клиентом (в том числе обеспечить его безопасность во взаимоотношениях с компанией), благодаря чему компания может рассчитывать на непрерывные продажи. Перечислены и описаны примерные инструменты, используемые в CRM (такие как: колл-центр, контакт-центр, управление ключевыми клиентами). Предпринята попытка оценить экономическую эффективность внедрения философии CRM на предприятии на основе SWOT-анализа. Работа [4] рассматривает теоретические основы управления взаимоотношениями с клиентами. При этом связь с эффективностью маркетинга рассматривается с нескольких точек зрения. Растущая тенденция ориентации на клиентов в сочетании с информатизацией бизнеса становится важнейшим аспектом конкурентоспособности современных предприятий, независимо от их размера[5]. Внедрение новых технологий малыми предприятиями позволяет им быстро развиваться и расти. В статье [5] представлен целостный взгляд на потребности использования CRM-систем для малого бизнеса. В настоящее время компании все больше внимания уделяют построению, развитию и эффективному управлению взаимоотношениями со своими клиентами [6]. Одной из причин повышенного внимания к качеству удовлетворенности клиентов стало изменение конкурентной среды в 1990-х годах и влияние развития информационных технологий. Появление Интернета усилилось повсеместной конкуренцией. Одним из наиболее эффективных способов отличиться от конкурентов является идеальное понимание отдельных клиентов и их потребностей, индивидуальный подход и отличный уровень обслуживания [6]. В работе [7] представлена структура, описывающая процесс внедренияCRM-системы в небольшую компанию. При этом процесс внедрения описывает 3 этапа: обсуждение проблемы, внедрение и управление изменениями. В работе [8] проведен анализ на основе внедрения информационных систем (ИС), реинжиниринга бизнес-процессов и исследования в области управления взаимоотношениями с целью определения перечня конкретных мер, которые способствуют успешной реализации системных проектов управления взаимоотношениями с клиентами с использованием CRM-систем. Предложения, сделанные в работе [8] дают для ученых стимул дальнейшего исследования по выяснению формулы успешного внедрения CRM-системы. В работе [9] предложена классификация CRM-систем на технические, технологические и организационные. По полноте функций технологические системы управления разделены на полные и частные. В статье отмечены проблемы внедрения CRM-систем в России [9]. Статья [10] посвящена исследованию сущности CRM-технологий как инструмента оптимизации применения принципов маркетинга взаимоотношений с клиентами. В статье проведен анализ, на основании которого выявлены основные преимущества использования CRM- технологий для бизнеса компании [10].

Проведенный анализ литературных источников показывает актуальность исследований в области разработки и внедрения CRM-систем. Исследование проводится на основе CRM-системы Synergy CRM [11].
С учетом указанных предпосылок осуществлено проектирование и реализация архитектуры в целях улучшения существующего программного решения Synergy CRM.
С этой целью произведена доработка модуля Склад, который позволяет управлять товарно-материальным ценностями (ТМЦ) и отслеживать текущее количество товаров на складе. Архитектура модуля позволяет производить интеграцию с другими компонентами системы, что делает его основным элементом управления ТМЦ в CRM. При доработке модуля Склад учтены все основные функциональные возможности, а именно: осуществление операций приемки, разгрузки, размещения и хранения, формирования отправок, выдачи, отборки, комплектования, списания, инвентаризации, оприходования, списания.

Архитектура доработанной системы Synergy CRM предусматривает коннектор для интеграции с системой 1С. Наличие коннектора значительно упрощает работу с системой 1С и позволяет легко обмениваться

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

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

Основным требованием к разработке модуля Проекты является предоставление пользователю списка проектов, доступных сотруднику, в виде таблицы, возможности создания новых проектов и добавления в них сотрудников, а также реализация Agile методологии (Scrum,Kanban).
С целью предоставить пользователям инструмент автоматизации согласования документов с возможностью гибкой настройки маршрутов согласования и организации прозрачного процесса было решено разработать модуль Документооборот, однако впоследствии он был переименован в модуль Согласование, сохраняя все свои функциональные свойства. Функции данного модуля позволяют настраивать сценарии согласования для всех шаблонов документов, выбирать сотрудников на этапах согласования или группу исполнителей; давать возможность писать комментарии при отказе или подтверждении; предоставлять возможность смотреть маршрут согласования и статусы согласования на каждом этапе, а также автоматически назначать задачи на ответственных по этапам согласования.

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

Для создания возможности выстраивать автоматизированные процессы внутри системы Synergy CRM, используя понятный визуальный редактор процессов, было принято решение спроектировать и реализовать возможность создания новых сценариев автоматизации при помощи конструктора BPMN. Такое решение позволяет сделать настройку интерактивной и наглядной, чтобы можно было отслеживать все свои бизнес процессы на схеме. Также это позволяет автоматизировать большое количество аспектов бизнес-процессов.

С целью создания разноплановых возможностей для клиентов и расширения целевого рынка продукта для системы SynergyCRM реализована возможность использования разработанного сервиса как в виде коробочного решения, так и в виде мобильного приложения под операционные системы (ОС) IOS и Android.

Результатом разработки является расширение функциональности и доступности системы Synergy CRM путем включения дополнительного функционала программного продукта “Отраслевое решение в Synergy CRM 2.0 для управления процессом производства (Synergy CRM v. 2.0)”. Доработанная CRM-система с отраслевым решением для производственного сектора позволит клиентам улучшить управление своим бизнесом и повысить производительность. Это позволит пользователям Synergy CRM более удобно и просто управлять своими бизнес-процессами, работать с приложением системы Synergy CRM или ее коробочной версией в любом месте и в любое время, взаимодействовать над своими задачами и проектами на практически любом устройстве.

1 ПРОЕКТИРОВАНИЕАРХИТЕКТУРЫ ПРОГРАММНЫХ РЕШЕНИЙ


1.1 Описание архитектуры существующей системы SynergyCRMСовременная CRM-система – это цифровая платформа, которая помогает выстроить работу между клиентами и предприятиями. Synergy CRM представляет собой CRM-систему для автоматизации продаж и систематизации данных компании о клиентах и сделках. Система состоит из нескольких блоков, в том числе имеется блок для управления отделом продаж: коммуникация с клиентами, ведения базы, документооборот, автоматизации процессов и других направлений. SynergyCRM рассчитана на использование как в малых, средних, так и в крупных организациях.


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

Архитектура системы Synergy CRM до доработки представлена на рисунке 1.1. Ядро Synergy CRM через внутреннюю логику кода (путем вызова методов, функций или процедур) взаимодействует с основными внутренними модулями системы. К внутренним модулям системы Synergy CRM относятся: модуль сегменты, модуль контакты, модуль почта, модуль задачи, модуль рабочий стол, модуль склад-операции, модуль продукты, модуль финансы, модуль журнал записей, модуль сотрудники, модуль файлы, модуль звонки, модуль сделки, интеграционный модуль, модуль аналитика, модуль документы, модуль файлы, модуль заявки, модуль настроек, модуль договоры, модуль авторизации, модуль компании, модуль осмотры, модуль недвижимость, модуль аналитика. Данные модули не оказывают влияние на выполняемую доработку, описание работы каждого модуля можно найти по ссылке[11].

Ядро Synergy CRM посредством API взаимодействия и использования очередей Kafka (в зависимости от решаемой задачи) взаимодействует с различными микросервисами. Рассмотрим каждый из них более подробно.

Модуль как микросервис телефония. При интеграции системыSynergy CRM и любой телефонии, пользователь может звонить и принимать звонки из любого раздела CRM-системы, просматривать историю общения с клиентом, прослушивать записи звонков и анализировать работу сотрудников. Интеграция предоставляет следующие возможности пользователю:
●фиксировать все звонки в системе SynergyCRM;
●звонить в один клик из карточки клиента;
●принимать входящие звонки в системеSynergy CRM;
●сохранять историю входящих и исходящих звонков в карточке клиента;
●всплывающее окно с информацией о клиенте при исходящем звонке;
●оставить результат звонка во всплывающей карточке с информацией о клиенте;
●вести запись разговора с клиентом из системы SynergyCRM;
●прослушивать записи разговоров;
●настроить аналитику по совершенным звонкам;
●аналитика по отвеченным и отклоненным звонкам;
●выстроить аналитику по длительности общения с клиентом;
●автоматическая постановка задач по звонку;
●автоматическая изменение данных сделки по звонку.
Модуль как микросервис Чаты. Система Synergy CRM интегрируется с соцсетями и мессенджерами с помощью сервиса chat2desk. Chat2Desk собирает и передаёт в CRM сообщения из всех популярных каналов связи.
Модуль как микросервис конвертер вебхуков. Представляет собой служебный микросервис, который используется для интеграции систем, обмен с которыми построен на вебхуках. Пользователям данный сервис недоступен.
Модуль как микросервис Админка. Является служебным сервисом техподдержки разработчиков. Через данный модуль осуществляется управление подписками и доступом к функционалу. Пользователям данный сервис недоступен.

Модуль как микросервис загрузчик файлов. Система Synergy CRM предоставляет возможность один раз создать шаблон документа и потом использовать его многократно. Прикрепляя шаблон к сделкам, пользователь получает готовый документ с уже заполненными данными на основании данных сделки и объекта. Шаблон документов создается с помощью удобного конструктора. Генерация документа для пользователя происходит в одно нажатие соответствующей кнопки. В системе Synergy CRM можно создавать шаблоны для документов, sms- и email-сообщений. Шаблоны документов доступны из карточек объектов, шаблоны sms-сообщений доступны из модуля sms-рассылки, а почтовые шаблоны – только при отправке писем.

Модуль как микросервис API. Система Synergy CRM позволяет осуществлять интеграцию с различными дополнительными сервисами, путем использования API взаимодействия. Всего интегрировано более 30 различных сервисов. Полное описание списка интегрированных сервисов приведено по ссылке [11] в разделе «Интеграция с полезными сервисами». Также по ссылке [11] доступен раздел для разработчиков, в котором описаны разработанные функции API, предназначенные для интеграции системы Synergy CRM с другими внешними сервисами.

Модуль как микросервис Локейшн. Позволяет по номеру телефона в звонке определять местонахождение абонента, а также определить его текущий часовой пояс.
Модуль как микросервис Конвертер. Позволяет из HTML шаблона генерировать готовые печатные документы в формате pdf или docx.

Модуль сервис мобильное приложение Android. Осуществляет взаимодействие пользователя с основными модулями системы Synergy CRM через мобильное приложение для ОС Android.

1.2 Доработка архитектуры системы Synergy CRM
Целью проведенной работы являлась доработка архитектуры системы Synergy CRM для расширения ее функциональных возможностей.

В результате доработки в системе появилось шесть дополнительных модулей Synergy CRM. Кроме того, разработаны новые и доработаны существующие внешние микросервисы. Доработанная версия архитектуры системы Synergy CRM представлена на рисунке 1.2. Рассмотрим подробнее изменения, внесенные в новую архитектуру системы.

Модуль Склад. Существующий модуль, в который вводится новый функционал. Добавлены возможности по осуществлению операций приемки, разгрузки, размещения и хранения, формирования отправок, выдачи, отборки, комплектования, списания, инвентаризации, оприходования, списания ТМЦ. Более подробно разработка модуля Склад рассмотрена в разделе 2 настоящего отчета.

Модуль отслеживания грузоперевозок. Позволяет пользователю отслеживать перемещение товара на всех этапах транспортировки. Более подробно разработка модуля отслеживания грузоперевозок рассмотрена в разделе3 настоящего отчета.

Модуль шаблона Excel(шаблон документа Смета).Предназначен для создания шаблона документа
«Смета» на основе технологии Excel. Реализует следующие функциональные возможности: редактирование составных элементов, позволяет использовать данные из справочника материалов/продуктов, проверяет наличие на складе и количество доступных продуктов товаров, позволяет создать и применить необходимую формулу для расчета промежуточных и итогового результата, формирует документ по шаблону организации со всеми расчетами. Более подробно разработка модуля шаблона Excel (шаблона документа Смета) рассмотрена в разделе4 настоящего отчета.

Модуль интерактивный онбординг. Представляет собой интерактивную систему обучения пользователя приложения Synergy CRM в формате последовательных этапов и шагов, выполняя которые им приобретается опыт взаимодействия с основными разделами и сущностями приложения для эффективной работы в Synergy CRM. Более подробно разработка модуля интерактивного онбординга рассмотрена в разделе7 настоящего отчета.

Модуль BPMN-конструктор автоматизаций. Предоставляет возможность выстраивать автоматизированные процессы внутри системы Synergy CRM, используя понятный визуальный редактор процессов, было принято решение спроектировать и реализовать возможность создания новых сценариев автоматизации при помощи конструктора BPMN. Такое решение позволяет сделать настройку интерактивной и наглядной, чтобы можно было отслеживать все свои бизнес процессы на схеме. Также это позволяет автоматизировать большое количество аспектов бизнес-процессов. Более подробно разработка модуля BPMN-конструктора автоматизаций рассмотрена в разделе8 настоящего отчета.

Модуль Согласование. Позволяет настраивать сценарии согласования для всех шаблонов документов, выбирать сотрудников на этапах согласования или группу исполнителей; предоставляет возможность писать комментарии при отказе или подтверждении согласования. Предоставляет возможность смотреть маршрут согласования и статусы согласования на каждом этапе, а также автоматически назначать задачи на ответственных по этапам согласования. Более подробно разработка модуля Согласование рассмотрена в разделе 9 настоящего отчета.

Модуль Проекты. Новый разрабатываемый модуль. Предоставляет пользователю список проектов, доступных сотруднику в виде таблицы. Предоставляет возможность создания новых проектов и добавления в них сотрудников. Имеет функционал по реализации Agile методологии (Scrum, Kanban). Более подробно разработка модуля Проекты рассмотрена в разделе10 настоящего отчета.
Модуль как микросервис 1С-коннектор. Реализует коннектор для интеграции с системой 1С, что ускоряет обработку данных и позволяет быстро получать актуальную информацию. Более подробно разработка модуля 1С-коннектор рассмотрена в разделе 5 настоящего отчета.
Модуль как микросервис шаблонов Excel. Предназначен для формирования шаблонных документов с возможностью автоматизированного заполнения данными в формате таблиц (Excel). Более подробно разработка данного микросервиса рассмотрена в разделе 4 настоящего отчета.
Коробочная версия. Представляет собой версию программного обеспечения системы SynergyCRM, которая подразумевает самостоятельную инсталляцию и настройку пользователем. Более подробно архитектура коробочной версии решения рассмотрена в разделе1.3 настоящего отчета, а детали разработки приведены в разделе 12.

Модуль сервис мобильное приложение Android. Существующий модуль, в который вводится новый функционал. Осуществляет взаимодействие пользователя с основными модулями системы Synergy CRM через мобильное приложение для ОС Android.Разработан функционал для доработанных и вновь разработанных модулей. Более подробно архитектурные паттерны и решения для мобильного приложения на основе ОС Android рассмотрены в разделе 1.4 настоящего отчета, а детали разработки приведены в разделе 6.

Модуль сервис мобильное приложение iOS. Осуществляет взаимодействие пользователя с основными модулями системыSynergy CRM через мобильное приложение для ОС iOS. Более подробно архитектурные паттерны и решения для мобильного приложения на основе ОС iOS рассмотрены в разделе

1.5 настоящего отчета, а детали разработки приведены в разделе 11.

1.3 Архитектура коробочной версии системы SynergyCRM
Коробочная версия решения представляет собой программное обеспечение, которое подразумевает самостоятельную инсталляцию и настройку пользователем. Для создания коробочной версии системы Synergy CRM предлагается использовать пакет Helm Chart, который является популярным пакетным менеджером для Kubernetes. Helm Chart представляет собой коллекцию файлов, которые определяют необходимую информацию для создания экземпляра Kubernetes приложения. СтруктураHelm Chart включает в себя файл Chart.yaml, который содержит метаинформацию о чарте; файлы templates/, которые представляют собой файлы шаблонови используются для создания Kubernetes-манифестов; файл values.yaml, которыйсодержит значения по умолчанию, предназначенные для заполнения файлов шаблонов во время развертывания чарта (эти значения можно переопределить, передав другие значения при установке чарта).

Чарты Helm предназначены для упаковки и распределения Kubernetes приложений. Они помогают в автоматизации установки и обслуживания приложений в Kubernetes, а также обеспечивают возможность версионирования и обратной совместимости. На основе данного принятого шаблона разработан чарт для приложения Synergy CRM, который имеет отдельные директории с описанными выше файлами под каждый ключевой сервиси инфраструктурные модули.
1.4 Архитектурные паттерны и решения, которые будут использованы в ходе разработки приложения Synergy CRM для ОС Android
В рамках проекта выполнена доработка функционала и разработка новых возможностей, таких как сканер штрих-кода, который позволяет более удобно проводить операции по складу и предоставляет удобное расширение возможностей веб версии.
Разработка нового функционала произведена в среде разработки Android Studio на основе мультиплатформы Kotlin Multiplatform. Разработано множество новых экранов и компонентов, необходимых для улучшения пользовательского опыта, нового функционала с использованием последних наработок и рекомендаций Google. Учтены современные подходы к дизайну интерфейса, такие как использование светлой и темной темы.

Для разработки приложения и реализации поставленной задачи, использованы следующие подходы и рекомендованные библиотеки Android-разработки.
Шаблон проектирования MVVM представляет собой модульную архитектуру приложения, которая разделяет приложение на три компонента: Model, View и ViewModel. Model содержит бизнес-логику приложения, View отображает пользовательский интерфейс, а ViewModel управляет состоянием View и Model. Это позволяет избежать проблем, связанных с циклической зависимостью и ухудшением производительности.

Библиотека Dagger Hilt используется для внедрения зависимостей, позволяет реализовать подход Dependency Injection(DI), что позволяет существенно уменьшить количество кода и улучшить его читаемость. Следуя принципам DI, закладывается основа для хорошей архитектуры приложения, лучшей повторяемости кода и простоты тестирования.

Фреймворк Jetpack Navigation будет использован для удобной навигации в приложении, а также для обеспечения согласованного и предсказуемого взаимодействия с пользователем на основе установленного набора принципов. Фреймворк Jetpack Navigation делает навигацию легкой и интуитивно понятной для пользователей, предоставляя эффективный и гибкий API для управления фрагментами и активностями.
Для хранения данных приложение использует базу данных Room. Данная технология предоставляет удобный API для работы с базами данных SQLite.Хранение данных в базе данных позволяет пользователям сохранять, редактировать и просматривать данные, такие как информация о профиле пользователя, список задач и т.д. БД также обеспечивает быстрый и удобный доступ к данными повышает эффективность работы приложения.

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

В качестве высокоуровневого интерфейса для работы с REST-сервисами должны быть использованы библиотеки Retrofit и Moshi, что позволит легко интегрировать их в приложение. Библиотека Moshi используется для парсинга JSON-данных в объекты данных. Она предоставляет высокую производительность и легковесность по сравнению с другими библиотеками. Одним из ключевых этапов является взаимодействие с сервером по API (с использованием стандартной библиотеки Retrofit) для получения и отправки данных с последующим хранением в базе данных (при этом Room предоставляет удобную обертку для работы с базой данных SQLite) и оптимизации работы приложения.

Все экраны для просмотра, редактирования, создания объектов реализованы с помощью использования компонента RecyclerView библиотеки androidx для отображения списка атрибутов. Атрибуты представлены, как CustomView соответствующие той информации, которую они содержат. Например, для отображения текста используется компонентTextInputEditText с контейнером TextInputLayout. CustomView поддерживают взаимодействие с пользователем, в зависимости от типа. Для отрисовки экрана на основе полученной информации от сервера по запросу за объектом, составляется набор вью на основе типа поля атрибута.

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

1.5 Архитектурные паттерны и решения, которые будут использованы в ходе разработки приложения Synergy CRM для ОС iOS
В рамках проекта выполнена доработка функционала и разработку новых возможностей, в том числе с ориентацией на использование для ОС iOS. Разработка нового функционала произведена в среде разработки Android Studio на основе мультиплатформы Kotlin Multiplatform Mobile. Kotlin Multiplatform Mobile представляет собой средство разработки ПО и предназначено для упрощения разработки кроссплатформенных приложений для мобильных устройств. Важным является тот факт, что можно использовать общий код в программах для iOS и Android и писать код, специфичный для каждой из платформ, только там, где это необходимо. Например, при реализации нативного UI или при работес API, которые ограничены конкретной платформой. Поэтому логика модулей, реализованная для платформы Android, аналогичным образом использована в ОС iOS. Разработано множествоновых экранов и компонентов, необходимых для улучшения пользовательского опыта, нового функционала с использованием последних наработок и рекомендаций Google. Учтены современные подходы к дизайну интерфейса, такие как использование светлойи темной темы.

Основным языком разработки модуля для ОС iOS является Kotlin для бизнес-логики и SwiftUI для отрисовки экранов приложения. Для разработки приложения и реализации поставленной задачи, использованы следующие подходы и рекомендованные библиотеки.
В качествеархитектурного паттерна использован шаблон проектирования MVI (Model-View-Intent), который входит в семейство паттернов Unidirectional Data Flow. В свою очередьпаттерн Unidirectional Data Flow представляет собой подход к проектированию системы,в котором всё представляется в виде однонаправленного потока действий и управления состоянием.

Библиотека Koin предназначена для выполнения инъекцийзависимостей на основе конструкторов, внедрения зависимостей и выполнения ленивой (отложенной) инициализации. Она также поддерживает области видимости для управления жизненным циклом объектов в приложении. Koin является легкой и незаметной библиотекой, котораяне требует использования аннотаций или кодогенерации. Он предоставляет простыеи интуитивно понятныеAPI для определения модулей и разрешения зависимостей. Koin может быть использована с различными фреймворками и библиотеками в экосистеме Kotlin.Основные преимущества использования библиотеки Koin включают простоту и удобство использования, отсутствие необходимости в большом количестве настройки и возможность легкого тестирования зависимостей в изоляции.

Хранение данных осуществляется с использованием БД Room. Это позволяет пользователям сохранять, редактировать и просматривать данные, такие как информация о профиле пользователя, список задач и т.д. БД также обеспечивает быстрый и удобный доступ к данным и повышает эффективность работы приложения.
Для генерациитипобезопасных Kotlin API из SQL-операторов используется плагин SQLdelight. Он проверяет схему, операторы и миграции во время компиляции и предоставляет такие возможности IDE, как автодополнение и рефакторинг, которыеупрощают написание и поддержку SQL.

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

Одним из ключевыхэтапов является взаимодействие с сервером по API для получения и отправки данныхс последующим хранением в базе данных и оптимизации работы приложения. Для этого используется фреймворк сетевоговзаимодействия Ktor.
Все экраны для просмотра, редактирования, создания объектов реализованы с помощью использования компонента LazyVStackбиблиотеки SwiftUI для отображения списка атрибутов.
2 Модуль Склад
1.1 Цель и задачи доработки модуля Склад
Цель разработки модуля - автоматизация складского учета, а именно разработка складских операций в модуле «Склад», таких как операция приемки, разгрузки, размещения и хранения, формирования отправок, выдачи, отбора, комплектования, списания, инвентаризации, оприходования, списания. Также целью является разработка API для взаимодействия со складом через сторонние приложения.
Исходя из поставленной цели можно выделитьследующие подзадачи:
●автоматизация операции «Разгрузка транспорта»;
●автоматизация операции «Приемкатовара»;
●автоматизация операции «Размещение и хранение»;
●автоматизация операции «Формирование отправок»;
●автоматизация операции «Выдачагрузов»;
●операция «Отборка товаровиз мест хранения»;
●операция «Комплектование и упаковка товара»;
●автоматизация операции «Перемещение ТМЦ»;
●автоматизация операции «СписанияТМЦ»;
●автоматизация операции «Инвентаризация»;
●автоматизация операции «Оприходование излишков»;
●автоматизация операции «Списание недостачи».
В результате разработки нового функционала, в CRM-системе у пользователя появилась возможность создавать новые складские операции, проводить инвентаризацию, а также функционал API для работы из сторонних приложений, например, с использованием мобильного приложения. Описание сути основных выполняемых операций приведено в таблице 2.1.
2.2 Описание функционала доработанных операций
В настоящем разделе описан функционал, доступный пользователю в результате разработки модуля Склад:
Операция / справочник / раздел

Операция «Разгрузка транспорта»



Операция «Приемка товара»




Операция «Размещение и хранение»

Операция «Формирование отправок»


Операция «Выдача грузов»


Операция «Отборка товаров из мест хранения»

Операция «Комплектация и упаковка товара»

Операция «Перемещение ТМЦ»

Операция «Списания ТМЦ»

Операция «Списание недостачи»

Операция «Оприходование излишков»



Операция «Инвентаризация»

Описание


В данной операции указываются ТМЦ, которые должны быть поставлены в обозримом будущем на склад, на основании данной операции можем делать приемку ТМЦ.

Приемка ТМЦ на склад. В случае, если операция выполняется на основании операции «разгрузка транспорта», то после проведения, будет отмечено какие ТМЦ не поступили и ожидаемое количество с реально поступившим.

Размещение ТМЦ после приемки на месте хранения.

Формирование отправки. После проведения операции, формируется позиция в месте комплектации.

Выдача груза производится с места хранения и после выдачи, ТМЦ списывается с остатков.

Перемещение ТМЦ между местами хранения.

Перемещение ТМЦ на место комплектования с места хранения.

Перемещение ТМЦ между складами.

Списание ТМЦ.

Списание ТМЦ на основании проведенной инвентаризации.

Оприходование, выполняется на основании проведенной инвентаризации, по итогам остаток ТМЦ увеличивается до фактического, согласно инвентаризации

Инвентаризация ТМЦ, сравнение ожидаемого остатка с фактическим.
Ход создания и проведения операции «Разгрузка автотранспорта» заключается в следующем. Пользователь через меню создания операции, создает операцию «Разгрузка автотранспорта», добавляет информацию о транспорте, а также позиции, которые должны быть поставлены данным транспортом. После проведения операции, она будет доступна в списке операций разгрузки, на основании которых можно создать операцию «Приемка».

Ход создания и проведения операции «Приемка товара» заключается в следующем. Пользователь через меню создания операции, создает операцию «Приемка товара», указывается склад, на который идет приемка. Если приемка выполняется на основании операции «разгрузка транспорта», то так же указывает операцию разгрузки. После создания операции, пользователь добавляет в операцию позиции, которые поступили с указанием их фактического количества. После проведения операции выполняется фоновая задача, в данной задаче поступившие ТМЦ попадают на остаток на складе. Если операция «Приемка товара» была создана на основании операции «Разгрузка автотранспорта», то после проведения, в окне операции указывается ожидаемое количество поступившего ТМЦ и реальное, на основании этой информации можно понять, пришли ли все ТМЦ в необходимом количестве или нет.

Ход создания и проведения операции «Размещение и хранение» ТМЦ заключается в следующем. В отдельном разделе склада, которое называется «Места хранения», пользователь может создать место хранения ТМЦ и разместить ТМЦ на хранение из нераспределенных остатков.

Ход создания и проведения операции «Формирование отправок» заключается в следующем. Пользователь через меню создания операции, создает операцию «Формирование отправок», указывает склад, с которого будет выбран ТМЦ, указывает место комплектации, где будет собираться ТМЦ для формирования отправок, после проведения операции, указанное количество ТМЦ снимается с места хранения и
«кладется» на указанное в операции место комплектации.
Ход создания и проведения операции «Выдача грузов» заключается в следующем. Пользователь через меню создания операции, создает операцию «Выдача грузов», указывает место хранения, с которого

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

Ход создания и проведения операции «Отборка товаров из мест хранения» заключается в следующем. Пользователь через меню создания операции, создает операцию «Отборка товаров из мест хранения», выбирает склад, указывает место хранения, с которого выбирается ТМЦ и на которое должно переместиться ТМЦ. После проведения операции, указанное количество ТМЦ снимается с места хранения и на целевом месте хранения создается позиция с указанным количеством ТМЦ, либо указанное количество ТМЦ добавляется в существующую позицию ТМЦ на целевом месте хранения.

Ход создания и проведения операции «Комплектация и упаковка товара» заключается в следующем. Пользователь через меню создания операции, создает операцию «Комплектация и упаковка товара», указывает склад, с которого будет выбран ТМЦ, указывает место комплектации, где будет собираться ТМЦ для формирования отправок. После проведения операции, указанное количество ТМЦ снимается с места хранения и «кладется» на указанное в операции место комплектации.

Ход создания и проведения операции «Перемещение ТМЦ» заключается в следующем. Пользователь через меню создания операции, создает операцию «Перемещение ТМЦ», указывает склад, с которого будет выбран ТМЦ, указывает склад, на который необходимо переместить ТМЦ. После проведения операции, указанное количество ТМЦ снимается с остатков одного склада и на такое же количество увеличиваются остатки на другом складе.

Ход создания и проведения операции «Списания ТМЦ» заключается в следующем. Пользователь через меню создания операции, создает операцию «Списания ТМЦ», указывает склад, с которого будет списано ТМЦ, при необходимости списать с места хранения или места комплектации, указывает данные значения. Если не указано место хранения или место комплектации, то возможно списание только не распределенных ТМЦ. После проведения ТМЦ списывается с остатков склада, а также с места комплектации или места хранения, если они были выбраны при создании операции.

Ход создания и проведения операции «Списание недостачи» заключается в следующем. Пользователь через меню создания операции, создает операцию «Списание недостачи», указывает склад, с которого будет списано ТМЦ, при необходимости списать с места хранения или места комплектации, указывает данные значения, так же необходимо указать проведенную операцию инвентаризации. Если не указано место хранения или место комплектации, то возможно списание только не распределенных ТМЦ. Операция инвентаризации служит фильтром для возможной отборки ТМЦ для списания. После проведения ТМЦ списывается с остатков склада, а также с места комплектации или места хранения, если они были выбраны при создании операции.

Ход создания и проведения операции «Оприходование излишков» заключается в следующем. Пользователь через меню создания операции создает операцию «Оприходование излишков», указывает склад, на который будет выполнено оприходование и операцию инвентаризации, на основании которой будет выполнено оприходование. После проведения операции, остаток ТМЦ на складе увеличивается на излишек в инвентаризации.

Ход создания и проведения операции «Инвентаризация». Пользователь в разделе «Инвентаризация» создает инвентаризацию и проводит её либо по выбранным позициям из списка ТМЦ, либо по всем. После проведения в окне операции отображается информация о наличии ТМЦ не распределенных, на местах хранения и местах комплектации. В случае, если ожидаемое количество не сходится с реальным, это отмечается в позиции в окне операции.
2.3 Описание разработки доработанных операций
Создание и проведение операций по складу является необходимой операцией для многих для организаций, так как учет ТМЦ является важной частью успешного ведения бизнеса. Также учет ТМЦ возможен для внутреннего пользования, например, при инвентаризации компьютерного оборудования или любого другого оборудования.
В процессе исследования, для обеспечения функционирования операций в соответствии с таблицей 2.1, были выявлены сущности, представленные в таблице 2.2.
Для решения текущей задачи модуль «Склад» разработан на основе существующей CRM-системы SynergyCRM, описанной в разделе 1. Данная CRM-система написана на языке Ruby, с использованием фреймворка Ruby on Rails. Данный фреймворк реализует паттернMVC (Model-View-Controller), а также позволяет довольно быстро разрабатывать новый функционал и расширять имеющийся. Для хранения информации о товарах в модуле «Склад» используются модели, представленные в таблице 2.3.

Связь сущностей из таблицы 2.2 и моделей из таблицы 2.3. наглядно отображена на рисунке 2.1 в виде ER- диаграммы модуля «Склад». На основе базовой ER-диаграммы модуля «Склад» из рисунка2.1 рассмотрим подробно принцип работы для операций «Инвентаризация», «Комплектация и упаковка», «Добавление товара на место хранения» и «Списание ТМЦ». Данные операции являются базовыми для разрабатываемого модуля «Склад». При разработке остальных операций в модуле «Склад» приняты принципы обработки запрос-ответов, рассмотренных для указанных четырех операций.

Сущность


Store

StoreOperation

StorePosition

Products

ProductByStore

StoreStorage

StoreStorageProduct

StoreComplectation

StoreComplectationProduct

StoreInventory

StoreInventoryPosition

Users

Accounts

Описание


Склад

Складская операция

Позиция в складской операции

ТМЦ

Таблица, хранящая информацию об остатках ТМЦ на складе

Место хранения

Позиция ТМЦ на месте хранения

Место комплектации

Позиция ТМЦ в месте комплектации

Инвентаризация

Позиция ТМЦ в инвентаризации

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

Компании
Диаграммаработы операции «Инвентаризация» приведена на рисунке 2.2. Пользователь отправляет запрос store_inventories CRM-системе на создание инвентаризации. CRM-система через запрос в БД возвращает пользователю сообщение с информацией о созданной Инвентаризации. Пользователь отправляет запрос GET/products на получение спискатоваров, доступных для «Инвентаризации». CRM-система через запрос в БД возвращает пользователю сообщение с информацией о списке доступныхТМЦ. Пользователь отправляет запрос store_inventory_positions с указанием позицийтоваров, для которыхнеобходимо выполнить Инвентаризацию. По умолчанию инвентаризация проводится по всему списку ТМЦ. CRM- система через запрос в БД возвращает пользователю сообщение с информацией о том, что указанные позицииприняты к «Инвентаризации». Пользователь в любой необходимый ему момент времениотправляет запрос store_inventories/{id}/execute на проведение «Инвентаризации».

п/п


1





2






3



4



5





№ п/п


6


7

Модель


Product




ProductByStore





StoreStorage


StoreComplectation


StoreComplectation Product




Модель

Store

StoreStorageProduct
Таблица в СУБД


products




products_by_stores





store_storages


store_complectations


store_complectation_products




Таблица в СУБД

stores

store_storage_products
Краткое описание


Модель товара, хранит в себе информацию о фактическом остатке, доступном остатке на всех складах

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

Модель места хранения на складе

Модель места комплектации на складе

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

Краткое описание

Модель склада

Связующая модель между продуктом и местом хранения на складе, содержит в себе количество товара на месте хранения. Данное количество не может быть больше, чем доступный остаток
CRM-система через запрос в БД возвращает пользователю сообщение с информацией о наличии ТМЦ не распределенных, на местах хранения и местахкомплектации.

Диаграмма работы операции «Комплектация и упаковка» приведена на рисунке 2.3. Пользователь отправляет запрос store_operations CRM-системе на создание операции по комплектации и упаковке. CRM-система через запрос в БД возвращает пользователю сообщение с информацией об инициализации работы операции.
Пользователь отправляет запрос GET/store_operations/{id} для получения информации о доступных ТМЦ на местах хранения склада. CRM-система через запрос в БД возвращает пользователю сообщение с информацией о списке доступных ТМЦ. Пользователь отправляет запрос store_positions с указанием склада, с которого будет выбран ТМЦ, места комплектации, где будет собираться ТМЦ для формирования отправок. CRM-система через запрос в БД возвращает пользователю сообщение с информацией о том, что указанные позиции добавлены в операцию. Пользователь в любой необходимый ему момент времени отправляет запрос store_operation/{id}/execute на проведение операции. CRM-система через запрос в БД снимает указанное количество ТМЦ с места хранения и «перекладывает» на указанное в операции место комплектации, после чего возвращает пользователю соответствующее сообщение.

Диаграмма работы операции «Размещение и хранение» приведена на рисунке 2.4. Пользователь отправляет запрос store_storages/{id} CRM-системе на получение информации о месте хранения. CRM- система через запрос в БД возвращает пользователю сообщение с запрашиваемой информацией.

Пользователь отправляет запрос GET/store_storages/{id} для получения информации о нераспределенных ТМЦ. CRM-система через запрос в БД возвращает пользователю сообщение с запрашиваемой информацией. Пользователь отправляет запрос store_storage_products с указанием склада и нераспределенных ТМЦ. CRM-система через запрос в БД обрабатывает данные, после чего возвращает ответ пользователю.

Диаграмма работы операции «Списание ТМЦ» приведена на рисунке 2.5. Пользователь отправляет запрос store_operations CRM-системе на создание операции.CRM-система через запрос в БД возвращает пользователю сообщение об инициализации операции.
Пользователь отправляет запрос GET/store_operations/{id} для получения информации о доступных ТМЦ для списания. CRM-система через запрос в БД возвращает пользователю сообщение с запрашиваемой информацией. Пользователь отправляет запрос store_positions с указанием позиции товара, который необходимо списать. CRM-система через запрос в БД обрабатывает данные, после чего возвращает ответ пользователю. Пользователь отправляет запрос store_operations/{id}/execute с запросом на выполнение операции списания. CRM-система через запрос в БД обрабатывает данные, после чего возвращает ответ пользователю.
2.4 Особенности расчетов и реализаций основных операций модуля «Склад»

Рассмотрим основные особенности расчетов и реализаций основных операций модуля «Склад». Расчет ТМЦ для размещения на месте хранения, реализован по следующей формуле:

Дн = Дтмц –Кмх – Кмк,

где
Дн – это количество не распределенного ТМЦ;
Дтмц – доступное количество ТМЦ на остатках склада;
Кмх – количество данного ТМЦ на местах хранения склада;
Кмк – количество данного ТМЦ на местах комплектации склада.
Для хранения товара пользователь должен зайти в раздел «Места хранения», выбрать необходимое место хранения, добавить товар из нераспределенных остатков. Используется следующая формула вычисления нераспределенного остатка по товару:

Тн = Тс – Тмх – Тмк,


где
Тн – количество нераспределенного товара;
Тс – доступный остаток товара на складе(модель ProductByStore);
Тмх – количество товара на месте хранения(модель StoreStorageProduct);
Тмк – количество товара на месте комплектации (модель StoreComplectationProduct).

В программной реализации доступное количество ТМЦ для размещения на месте хранения ищется с использованием метода «available_for_storage».
Для операции «Оприходование излишков» идет выборка ТМЦ на основании инвентаризации, указанной в операции и выбираются только те ТМЦ, ожидаемое количество которых больше фактических. В программной реализации для этой цели используется метод выборки «products_from_inventory».
Программный код метода «products_from_inventory» принимает два аргумента: object и collection. Метод возвращает новую коллекцию товаров, основанную на значенииcollection, считанных со склада, содержащихся на известном store_inventory_id.

Запрос «collecrion.select» выбирает все столбцы из таблицы products, а также рассчитывает доступное количество товаров путем вычитания реально проданных товаров real_quantity из общего количества товаров quantity.Результат сохраняется в переменную available_for_enter c помощьюcoalesce.

Запрос «.joins» в строке 4 прикрепляет таблицуstore_inventory_positions к сущностиproducts и присоединяет таблицы по полю product_id.
Запрос «.joins» в строке 5 прикрепляет таблицу store_inventories к сущности store_inventory_positions и присоединяет таблицы по полю store_inventory_id.
Запрос «.group» группирует по идентификатору id объекта products,идентификатору id объектаstore_inventories, количеству товаров на складе и реально проданным товарам.
Запрос «.having» возвращает только те строки, где значение store_inventory_id соответствует значению object.store_inventory_id.
Запрос «.where» возвращает только те строки, где количество товара, доступного для продажи, больше нуля.

Операция «collection» возвращает измененную коллекцию товаров.
Метод «products_from_inventory» выбирает только те товары, которые доступны для продажи со склада с определенным идентификатором store_inventory_id. Он использует сущности products, store_inventories и store_inventory_positions для доступа к данным о количестве товаров в наличии, выполненных продажах и доступных для продажи. К функциональности SQL, проведенной в этом методе, можно обратиться как исполнению SQL-запроса к базе данных с некоторой логикой отбора данных.

Для операции «Списание ТМЦ» выбор доступного ТМЦ зависит от указанных при создании операции связей с местом хранения, местом комплектации, инвентаризации. При списании ТМЦ, в зависимости от того, откуда списывается товар (нераспределенные товары, с места хранения или места комплектации), в моделяхProduct и ProductByStore уменьшается фактический остаток и доступный на количество из позиции, соответственно при списании с места хранения или места комплектации, также уменьшается количество товара на позициях (модели StoreStorageProduct и StoreComplectationProduct). В программной реализации описания операции «Списание ТМЦ» используется метод «products_for_write_off».

Для операции «Приемка товара» пользователь указывает позиции товара с указанием количества, стоимости, единицы измерения и т. п. При этом пользователь выбирает товар либо из привязанных к аккаунту из модели Product, либо создает новый товар. В результате выполнения операции происходит следующее. В модели Productкаждого товара увеличивается фактический остаток и доступный остаток на то количество, которое указано в позиции. Так как приемка товара идет на конкретный склад, то в модели ProductByStore каждого товара из операции так же увеличивается фактический и доступный остаток на количество из позиции товара в операции.

Для операций «Формирование отправок», «Выдача грузов», «Отборка из мест хранения»,
«Комплектование и упаковка товара» выборка ТМЦ производится из места хранения. В программной реализации для этой цели используется метод «products_on_storage», представленный на рисунке А.2. Для остальных операций выбираются ТМЦ, созданные из-под аккаунта пользователя, поэтому используется запрос вида: Product.where(account_id: user.account_id).

При проведении инвентаризации, подсчет ТМЦ выполняется по позиционно и записывается в поле result позиции. В программной реализации подсчет ТМЦ при инвентаризации осуществляется с использованием метода«ExecuteInventory».

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

Проверка работоспособности разработанного и реализованного функционала показала, что при проведении и отмене проведения операций достигается ожидаемый результат. Данный факт подтверждается успешно пройденными тестами. Разработанное API для модуля «Склад» позволяет работать из сторонних приложений. Для исключения возможных ошибок, поступающие данные валидируются. Например, для валидации при создании позиции в операции «Списание ТМЦ» используется функция «validate_write_off».

Функция «validate_write_off» проверяет параметры записи/транзакции записи со склада на возможность списания. Она принимает объект record в качестве аргумента, который представляет запись или транзакцию о списании товара со склада. Функция используется для валидации перед сохранением в базу данных. Если количество товара на складе недостаточно для списания, то данные не сохраняются, а к записи добавляется соответствующая ошибка.

Функция «available_quantity_for_position» является вспомогательной функцией, которая определяет количество товара на складе, доступное для списания. Это количество проверяется на достаточность для запланированного списания в транзакции.
Первый блок проверяет, "доступно ли достаточное количество товара для списания". Если количество товара на складе для данного продукта не найдено, или если число доступных товаров равно нулю, код создает новую ошибку в записи о том, что данного продукта не существует на складе.
Второй блок проверяет, достаточно ли товара на складе для запланированного списания. Если количество запланированного товара больше, чем количество доступного товара на складе, функция создает новую ошибку в записи, что товара на складе недостаточно для выполнения запланированной транзакции.
Если ошибок в записи не было добавлено и количество запланированного товара не превышает количество доступного для списания товара, запись сохраняется в базу данных без каких-либо проблем.
Следует отметить, что вместо создания отдельной операции «Списание недостачи», было принято решение расширить задачу «Списание ТМЦ», добавив дополнительный пункт выбора «на основании инвентаризации».

Таким образом, разработанный модуль обеспечивает следующие функции: своевременное отражение, учет и планирование складских остатков; инвентаризация; формирование резервов.
3 Интеграция системы SynergyCRM с сервисом отслеживания грузоперевозок
Целью создания модуля «Отслеживание грузоперевозок» является предоставление пользователю сервиса для учета времени курьеров, отслеживания грузоперевозок, получения заказов и ведения данных по курьерам и транспортным средствам, ведения анализа по заказам и распределения заказов по курьерам. Для достижения поставленной цели осуществляется интеграция CRM-системы Synergy CRM с логистическим сервисом Relog посредством использования специального API-клиента для передачи данных между внутренней системой и сервисомлогистики Relog.

При осуществлении интеграции сервисом логистики Relog используются следующие функциональные возможности:
●создание сделки в сервисе Relog;
●обновление сделки в сервисе Relog;
●получение информации о сделке из сервиса Relog;
●получение информации об исполнителя;
●автоматизации для отправки данных о сделке при перемещении ее в «работу»;
●уведомления об успешном создании сделки в сервисе Relog или об ошибке, а также уведомление об успешном завершении доставки по сделке.
Сервис разработан таким образом, что пользователь может самостоятельно осуществить интеграцию с помощью специального API-ключа. Перед началом работы с логистическим сервисом Relog, необходимо зарегистрироваться в нем по адресу https://getrelog.com/

После успешной регистрации необходимо получитьAPI-ключ. Для этого необходимо после осуществления логирования в приложение, нажать на шестеренку в правом верхнем углу, выбрать в открывшемся меню пункт «Параметры». В всплывающем окне, необходимо выбрать пункт «Интеграция» нажать на кнопку «Сгенерировать API ключ» в блоке «API интеграция» и скопировать
«ПЕРСОНАЛЬНЫЙ API КЛЮЧ», как показано на рисунке 3.1.
Когда API-ключ получен, клиент создает интеграцию в «Настройках» в пункте «Доставка» указывая имеющийся API-ключ. Также можно указать время обновления данных в минутах, по умолчанию время обновления данных составляет 1 (одну) минуту, как показано на рисунке 3.2.
После создания интеграции для каждого клиента создается автоматизация для управления отправкой сделок в систему логистики Relog при перемещении сделки из статуса «Новая» в статус «В работе», так же создается автоматизация для контроля обновлений в системе логистики Relog, которая отвечает за обновление данных во внутренней системе при изменении статуса, исполнителя или других параметров, так же отвечает за завершение сделки при выполнении исполнителем доставки.
В момент создания интеграции, для пользователя создается кастомная категория «Relog»,в данной категории создаются кастомные поля:
●номер заказа;
●клиент;
●продукты;
●филиал погрузки (адрес, координаты);
●филиал разгрузки (адрес, координаты);
●время на выполнение заказа;
●дата доставки c...;
●дата доставки по...;
●время обслуживания (на погрузку, на разгрузку);
●вес груза;
●исполнитель;
●номер маршрутного листа;
●транспорт;
●статус заказа;
●отслеживание.
Для пользователя дополнительно создается кастомная категория «Relog», в которой создаются кастомные поля: Исполняемый заказ номер, Назначенное транспортное средство.
Далее пользователь имеет возможность перейти к созданию сделки. Открыв окно создания сделки, пользователю необходимо установить видимые поля из кастомной категории «Relog», заполнить данные поля. Обязательными к заполнению являются следующие поля: номер заказа; клиент; филиал погрузки (адрес, координаты); филиал разгрузки(адрес, координаты); дата доставки c.. и по…
Если вместе со сделкой передается «Продукт», то у продукта должно быть заполненным поле «Артикул». Поля, которые не нужно заполнять(заполняются автоматически при обновлении статуса из логистического сервиса Relog). К автоматически заполняемым полям относятся: исполнитель; номер маршрутного листа; транспорт; статус заказа; отслеживание.
При заполнении сделки, для ее отправки в логистический сервис Relog, необходимо учитывать, что даты не должны находиться в прошлом, а «Дата доставки по» должна быть больше «Дата доставки с».
Когда сделка создана и ее данные заполнены, то карточку сделки можно переместить в следующий статус («В работе»). Если все было заполнено верно, то в уведомлениях появится запись об успешной отправке сделки в Relog. Если была допущена ошибка, то в уведомлениях будет сообщение с ошибкой. Для повторной отправки необходимо вернуть сделку в начальное положение, исправить ошибки и передвинуть в следующую колонку. Если сделка уже была отправлена в логистический сервис Relog, то изменения, применяемые в сделке, не отобразятся на отправленной сделке, находящейся в логистическом сервисе Relog.
После того, как сделка была отправлена в логистический сервис Relog, необходимо перейти в данный сервис, проверить корректность переданной информации, назначить исполнителя.
Для назначения исполнителя в логистическом сервисе Relog необходимо нажать на карандаш (рисунок 3.3), в правом верхнем углу карточки необходимой сделки. Карточки расположены в левой части экрана. Кнопки появятся при наведении на карточку сделки. Если карточки с необходимой сделкой не отображены, то в таком случае нужно выбрать даты отображения. Это делается в фильтре по датам в левой части экрана, под поиском, все действия для распределения исполнителей происходят на вкладке
«входящие»
Когда успешно установлены все параметры, в том числе «Исполнитель», он же «Водитель», сделка автоматически переведется в раздел «Активные» (рисунок 3.4). Ее можно будет наблюдать в одноименной вкладке, далее ей будет управлять Водитель.
При переводе сделки в логистическом сервисе Relog, будет обновлена информация по сделке во внутренней системе. В разделе «Статус» будет отображено наименование активного статуса в логистическом сервисеRelog. В разделе «Отслеживание» появится ссылка для клиента, по которой можно будет наблюдать передвижение водителя и статистику по водителю. В разделе «Номер маршрутного листа» будет указан номер внутри логистического сервиса Relog. В разделе «Исполнитель» будет указан Водитель, назначенный в логистическом сервисе Relog. Если данного водителя нет во внутренней системе, он будет создан и назначен на сделку во внутренней системе на основе данных, переданных из логистического сервиса.
Также будут частично заполнены необязательные поля, если для них имеются значения по умолчанию, определенные в логистическом сервисе Relog.
При выполнении водителем заказа (сделка, переданная пользователем из внутренней CRM-системы в логистический сервисRelog) или его отмены, во внутренней CRM-системе будет обновлен статус и на его основе сделка будет перемещена в статус «Завершенная». Данный функционал достигается с помощью автоматизированных скриптов, установленных во время создания интеграции.
Необходимо учитывать, что обновление выполняется с задержкой. Минимальное время задержки устанавливается по умолчанию в 1 (одну) минуту и может быть откорректировано в настройках интеграции.
После завершения сделки (доставки исполнителем заказа) в логистическом сервисе Relog и обновления статуса во внутренней CRM-системе, отработает автоматизация. Пользователь получит оповещение о завершении сделки. Оповещение можно будет посмотреть в правом верхнем углу, в выдвигающемся меню, в пункте «Непрочитанные оповещения». Также при завершении сделки происходит оповещение пользователя с помощью всплывающего окна в правом нижнем углу.
4 Разработка специализированного отраслевого шаблона документа «Смета» в модуле Документооборот
4.1 Цели и задачи разработки шаблона документа «Смета»
Цель разработки данного функционала - решение задачи производственных компаний и смежных отраслей в формировании шаблонных документов с возможностью автоматизированного заполнения данными в формате таблиц(Excel). В системеSynergy CRM уже реализована возможность генерации DOC шаблонов, но они не поддерживают ячейки, формулы, горизонтальный формат документа и возможность работать с другими возможностями, которые предоставляет формат Excel. Таким образом реализована задача разработки микросервиса Excel-шаблонов, который в первую очередь будет использоваться для создания шаблона документа «Смета».

При разработке и создании шаблона документа «Смета» реализованы следующие функциональные возможности:
●в смете должна быть возможность редактировать составные элементы;
●смета должна использовать данные из справочника материалов/продуктов;
●смета должна проверять наличие на складе и количество доступных продуктов товаров;
●в смете должна быть возможность создать и применить необходимую формулу для расчета промежуточных и итогового результата;
●должен формироваться документ по шаблону организации со всеми расчетами. Для реализации сервиса выполнены следующие задачи:
●произвести исследование библиотек на стороне FrontEndдля Excel;
●создать MVP (Minimum Viable Product);
●подключить необходимые библиотеки;
●подключить WebSocket для обновления данные в режиме реального времени;
●подключить базу данных Postgres;
●добавить CRUD-решения для выполнения основных операций с сервисом;
●добавить формулы, работу с текстом и колонками;
●согласовать работу библиотеки и архитектуры между собой;
●добавить брокеры (kafka)для обмена сообщениями между CRM и микросервисом;
●использовать фреймворк Hanamiдля быстрой реализации Rails задач;
●разработать и реализовать отдельный сервис с общением по (REST) и добавлением Consumer для взаимодействия с CRM-системой.
Использованы следующие подходы к разработке сервиса. При разработке сервиса использован подход slice из фреймворка Hanami, который включает в себя технологию dependency injection и dry-rb. Это позволяет использовать кусочки (slice) сервисов в будущим для других проектов. Использован DRY-monad для стандартизированного подхода ответа функций Успеха или Провала. Использован gem alba для моментальной сериализации и десериализации данных между серверами через общение REST.Добавление DRY-Type позволяет осуществлять валидацию данных от сервера и проверки его в будущем. Создано тестовое окружение для сервиса. В качестве инфраструктуры использованы Redis для кэширования данных, ActionCable для взаимодействия сервера и клиента через протокол WebSocket, а также LiteCabel для WebSocket.

При разработке и реализации сервиса использовано железнодорожно-ориентированного программирование. Железнодорожно-ориентированное программирование в Ruby – это шаблон проектирования, который помогает справляться с ошибками в разработанных приложениях. Вместо того чтобы полагаться на исключения, данные и функции проектируются определенным образом. Поскольку приложения, по сути, представляют собой комбинацию шагов, то используются следующие правила. Существует тип Result, который может быть либо Success, либо Failure. Successи Failure – это практически контейнеры с различными данными. Шаги принимают Result и возвращают Result. Как только шаг Result Failure, дальнейшее выполнение действий останавливается.
4.2 Описание разработки CRUD методов для создания шаблона документа «Смета»
Для работы сервиса были разработаны CRUD методы, которые выполняют основные функции приложения. К этим методам относятся генерация шаблона, сохранение данных, создание документа и другие важные функции. Основные разработанные методы представлены в таблице 4.1.
Описание разработанных методов представлено в виде диаграмм последовательностей, описывающих технический процесс выполнения методов. Диаграммы представлены на рисунках4.1 – 4.5. Также разработана диаграмма последовательности для метода XlsxConsumer для генерации данных на основе переменных шаблонов Документов CRM (рисунок 4.6).

Метод

/api/v1/workbooks/create
/api/v1/workbooks/rename
/api/v1/workbooks/clone
/api/v1/workbooks/generate
/api/v1/workbooks/copy

Описание

Создание нового шаблона
Редактирование/изменение названия
Дублирование шаблона
Генерация документа по шаблону
Копирование документа

В результате выполненного исследования и разработки был разработан и реализован микросервис Excel- шаблонов, который в первую очередь предназначен для использования с целью создания шаблона документа «Смета». Внедренный микросервис Excel-шаблонов обеспечивает рабочее пространство со всеми соответствующими возможностями редактирования и создания документа (рисунок Б.1). В сервисе реализована возможность использования всех стандартных формул (рисунок Б.2). Доступен функционал по изменению размеров колонок и строк, объединению ячеек и проведение прочих манипуляций с ячейками (рисунокБ.3). Доступно взаимодействие с листами книги и между ними (рисунокБ.4). Доступно взаимодействие с текстом (изменение размера, шрифта, цвета, положения), колонками(изменение размера, цвета, положения, перемещения), сортировкой и фильтрами(рисунок Б.5). Кроме того, разработан функционал, который позволяет наполнить шаблон документа переменными (полями) из CRM- системы. Когда генерируется документ, он автоматически заполниться данными из системы как показано на рисунке Б.6.
5 Разработка 1С-коннектора
5.1 Цели и задачи разработки 1С-коннектора
Цель заключается в разработке микросервиса, предоставляющего API доступ к системе Synergy CRM для программного обеспечения 1C. Использование такого API для системы SynergyCRM позволяет создавать, редактировать и управлять данными в системе через пользовательское приложение. Благодаря этомумногие клиенты (компании) могут интегрировать свои 1С-приложения с системой Synergy CRM для управления данными бухгалтерии. Например, если бухгалтерия оформит закрывающие документы по сделке в системе 1С, то это сразу отобразится в CRM-системе, с которой работает отдел продаж. Это позволит избежать ошибок, связанных с ручным копированием информации, а также позволит улучшить взаимодействие между подразделениями компании.

Ввиду особенностей языка программирования 1С (наименование сущностей, обработка ответов и другие), разработка API для интеграции системы 1С и развития ее взаимодействия с существующей системой Synergy CRM представляет собой трудоемкую задачу. Решением является создание микросервиса (прослойки) между 1С приложением и API CRM-системы, который сможет принимать запросы и отдавать ответы в 1C в удобном специальном формате, с целью упрощения интеграции 1С приложений с Synergy CRM.

Для достижения поставленной цели реализованы следующие задачи.

●Разработать архитектуру микросервиса “1C-Connector” с внутренней структурой “back-end”, включающей определение эндпойнтов (маршрутов) взаимодействия микросервиса с 1С; определение взаимодействия с CRM API; определение контроллеров.
●Разработать основной функционал (бизнес-логики) согласно требованиям.
●Определить сервисы и операции, выполняющие бизнес-логику
●Реализовать связи сущностей с сущностью “организация” в CRM, в том числе реализовать добавление связей между таблицами в CRM БД, создание миграций; выполнить изменение GUI, добавив возможность установки организации для сущностей.
●Произвести тестирование.
●Создать API документации для микросервиса “1C-Connector”.
Для интеграции 1С и CRM-системы использованы следующие сущности в CRM-системе, соответствующие сущности в 1С:
●contacts (контактные лица, сотрудники, физические лица);
●companies (контрагенты, партнеры);
●company-bank-details (банковские реквизиты контрагентов);
●deals (заказы клиентов);
●deal-stages (статусы заказов клиентов);
●products (номенклатура);
●product-categories (группы номенклатуры);
●entity-products (табличная часть заказа клиента);
●stores (склады);
●invoices (счета клиентов);
●account-bank-details (банковские реквизиты организации);
●org-details (организации);
●invoice-positions (табличная часть счета клиента);
●invoice-payments (ПКО, поступление на расчетный счет, взаимозачет);
●users (пользователи).

5.2 Разработка алгоритмов и выбор средств для реализации 1С-коннектора
Микросервис «1C-Connector» представляет собой прослойку (прокси)между 1С-приложением и API CRM- системы, обеспечивающую ретрансляцию запросов, ответови модификацию их форматов. Взаимодействие выполняется в соответствии со схемой, представленной на рисунке 5.1.
Для того, чтобы микросервис являлся “легковесным” прокси приложением, он разработан как “API-only” приложение без предоставления HTML страниц, без взаимодействия с СУБД и без возможности отправки писем клиентам. С этой целью был выбран фреймворк «Ruby on Rails» версии 6.1.7.2. Он позволяет создавать легковесное “API-only” приложение и предоставляет обширный встроенный функционал, необходимый для реализации задачи. Разработка осуществляется в среде VisualStudio Code на языке Ruby версии 3.2.1.

Для создания “API-only” приложения необходимо использовать команду:

$ rails new connector-1c --skip-active-record --skip-action-mailer --skip-action-mailbox --skip-test --api


Опции команды:
--skip-active-record: пропустить файлы ActiveRecord, т.к. нет взаимодействия с СУБД;
--skip-action-mailer: пропустить файлы Action Mailer;
--skip-action-mailbox: пропустить гем Action Mailbox;
--skip-test: пропустить файлы тестов, вместо них используется rspec;
--api: настроить приложение так, чтобы оно запускалось с более ограниченным, чем обычно, набором промежуточного программного обеспечения, но достаточным для APIприложения.
Форматы запросов и ответов к CRM API должны соответствовать спецификации JSON API v1.0. Поэтому микросервис “1C-Connector” также должен соответствовать этой спецификации.
С целью минимизировать изменения на стороне 1С-приложений, интерфейс взаимодействия с микросервисом аналогичен CRM API, т.е. формат всех url эндпойнтов должен оставаться неизменным. Меняться будет только доменное имя. Поэтому в микросервисе определены все контроллеры и маршруты с теми же именами, что и в CRM API как показано в примере в приложении В на рисунке В.1.
Определение в микросервисе тех же имен, что и в CRM API в соответствии с рисунком В.1 позволит создать API эндпойнты, приведенные в таблице 5.1.
Для отправки и обработки HTTP-запросов к CRM API было предложено использовать популярный гем “HTTParty”, позволяющий отправлять HTTP-запросы и инспектировать результаты (ответы). Вызовы CRM API реализованы в сервис-объектах (ServiceObject). Они наследуют функционал от базового сервиса
«CrmApiService», представленного на рисунке В.2.

Каждый дочерний сервис должен реализовать конкретный тип HTTP запроса, GET, PUT, PATCH или DELETE. Например, на рисунке В.3 представлен сервис «CrmApiGetService».

GET

POST

GET

PATCH

DELETE

/api/v1/entity-products(.:format)
/api/v1/entity-products(.:format)
/api/v1/entity-products/:id(.:format)
/api/v1/entity-products/:id(.:format)
/api/v1/entity-products/:id(.:format)
Такой подход решает несколько проблем:

●код контроллеров и моделей не будет разрастаться при усложнении логики. Если сервис сам становится перегруженным, его можно разбить на несколько других сервисов;
●каждая сущность ответственна за свою собственную задачу;
●исходный код сервиса легко использовать повторно и покрывать автоматическими тестами;
●таким же образом внутри сервисов можно скрыть обращение к внешним API и SDK, чтобы их сложности не мешали концентрироваться на реализации бизнес-логики.
Согласно вышеописанным требованиям, преобразование формата данных заключается в следующем:
●для всех ответов на запросы списков(GET) оставить только заполненные (в которых установлено значение) поля "attributes";
●исключить раздел "relationships" для всех ответов;
●для всех идентификаторов полей и именований сущностей заменить символ"-" на "_".

Логика преобразований помещена в сервис-объекты, которые наследуют базовый сервис «DataTransform» (рисунок В.4). Базовый сервис «DataTransform» инициализирует переменную body, представляющую собой Hash объект – данные, полученные в HTTP ответе от CRM API в формате Json, которые

преобразуются в Hash. Здесь же определен единственный метод «transform()», который в свою очередь вызывает переданный блок для одного Hash объекта или для массива Hash объектов (например, когда возвращается список объектов на GETзапрос).

Сервисы «TransformRequest» и «TransformResponse», которые являются наследниками «DataTransform», передают в «transform()» выполняемые блоки, соответствующие необходимым модификациям.
Сервис «TransformRequest» вызывается для HTTP запросовPOST, PUT, PATCH, которые содержат данные в теле запроса. Алгоритм работы сервиса «TransformRequest» представлен на рисунке 5.2 и состоит из следующих шагов:
Шаг 1. Проверка, если это HTTP POST, PUT или PATCH запрос. Если нет, то запрос отправляется в CRM без изменений.

Шаг 2. Замена символа "_" на "-" для всех идентификаторов полей и именований сущностей. Шаг 3. Замена символа "_" на "-" в значении полей ‘type’.
Шаг 4. Отправка запроса с измененными данными в CRM.
Сервис «TransformRequest» заменяет символ "_" на "-" для всех идентификаторов полей и именований сущностей. Система 1С хранит атрибуты с “_” и так же передает их в HTTP запросах. Чтобы эти данные были успешно обработаны CRM API, «1C-Connector» преобразует их в исходный формат как показано на рисункеВ.5.

Алгоритм работы сервиса«TransformResponse» представлен на рисунке 5.3 и состоит из следующих шагов.
Шаг 1. Проверка кода ответа от CRM. Если неуспешный, то ответ отправляется в 1C без изменений.
Шаг 2. Удаление раздела ‘relationships’.
Шаг 3. Удаление атрибутов с пустыми значениями в разделе ‘attributes’.
Шаг 4. Замена символа "-" на "_" в значении полей ‘type’.
Шаг 5. Замена символа"-" на "_" для всех идентификаторов полей.
Шаг 6. Отправка ответа с измененными данными в 1C.
Сервис «TransformResponse» заменяет символ "-" на "_" для всех идентификаторов полей и именований сущностей в данных, полученных от CRM, а также исключает раздел "relationships" и пустые атрибуты согласно требованиям как показано на рисунке В.6.
С целью добавления ссылки на “организацию” (org-detail) необходимо создать файлы-миграции в CRM БД для следующих сущностей:
●contacts (контактные лица, сотрудники, физические лица)
●companies (контрагенты, партнеры)
●deals (заказы клиентов)
●products (номенклатура)
Пример файла миграции для таблицы “contacts” представлен на рисунке В.7.
В результате этого упомянутые выше сущности будут иметь параметр “org_detail_id” в соответствующих таблицах. Этот параметр является внешним ключом, ссылающимся на первичный ключ “id” таблицы “org_details”.
Соответствующие изменения были выполнены для GUI, чтобы предоставить возможность выбора организации для сущности. Пример изменения GUI представлен на рисунке В.8.
Как и для других сущностей, данные организации для конкретного объекта можно получить через параметр “include” в url запроса: GET http://localhost:3000/api/v1/deals/2?include=org-detail Пример ответа, который будет получен на такой запрос представлен на рисунке В.9.
Также возможна фильтрация сущностей по “org-detail-id”: GET http://localhost:3005/api/v1/deals?filter[org-detail-id]=4
5.3 Разработка API документации
API документация необходима клиентам как справочник для быстрого получения информации по доступным форматам, ключам и другим параметрам, которые могут быть использованы в HTTP запросах. С этой целью API документация должна быть разработана в виде веб-приложения, доступного клиентам через Интернет.
Есть несколько способов собрать документацию: написать код вручную в HTML или использовать инструменты, помогающие автоматически генерировать документацию API из исходного кода, например Doxygenи API Blueprint.
В данной работе предложено использовать утилиту Slate. Slate позволяет писать документацию по API вручную, используя уценку, которую затем он упаковывает как предварительно стилизованный статический HTML-сайт. В итоге разработки будет получен следующий результат:
●одностраничный статический сайт с документацией на основе JS;
●настраиваемый трехколонный макет;
●поиск по странице;
●примеры кода с вкладками;
●подсветка синтаксиса.

5.4 Разработка 1С скриптов
Для документации по 1С-коннектору были специально разработаны универсальные 1С скрипты. Скрипты позволяют совершать выгрузку и загрузку табличных данных и из CRM в 1С и также наоборот. Выгружать и загружать документы и работать с основными функциями. Были разработаны следующие скрипты.
Основные скрипты для:
●получения заголовков;
●парсинга JSON пакета из результата http-запроса;
●получения первого значения идентификатора объекта по строке адреса ресурса;
●отправки запроса в CRM.

Скрипты получения документов 1С, которые получают(обновляют или создают)сделку:
●по структуре данных;
●по идентификатору CRM;
●с заданной даты модификации и числом страниц. Скрипты для отправки документов 1С:
●строки табличной части заказа (спецификация);
●заказа (сделки) из ссылки 1С с идентификатором Ид в его реквизите;
●оплаты по заказу из ссылки 1С с идентификатором Ид в его реквизите;
●счета по заказу из ссылки 1С с идентификатором Ид в его реквизите.

Скрипты для получения (обновления или создания) данных в 1С из CRM (справочники):
●контакта по структуре данных;
●контрагента (партнера) по структуре данных. Скрипт для отправки данных (справочники) из 1С в CRM:
●контакта из объекта1С с идентификатором Ид в его реквизите;
●контрагента (клиента) из объекта 1С с идентификатором Ид в его реквизите и Массивом его контактов;
●категории продуктов (в иерархии) из объекта 1С с идентификатором Ид в его реквизите4
●единиц измерений из объекта 1С с идентификатором Ид в его реквизите;
●продуктов (номенклатуры) из объекта 1С с идентификатором Ид в его реквизите.
Благодаря этим и другим скриптам клиенты смогут быстро разработать интеграцию своих 1С-систем и Synergy CRM. Основные разработанные скрипты приведены в Приложении Б.
Таким образом, разработанный модуль обеспечивает функцию, согласно пункту 4.1.1 технического задания: интеграция с 1С.
Разработанная API документация представлена в виде веб-приложения, доступного клиентам по ссылке [12].
6 Разработка мобильного приложения под Android: рефакторинг кода, переработка макета приложения, определение лучшего стека технологий и разработка приложения, тестирование, раскатка приложения на торговых площадках

Цель разработки приложения Synergy CRM заключается в предоставлении пользователям мобильной платформы Android с возможностью удобного доступа к основным функциям и возможностям, которые доступны в веб-версии приложения. С помощью приложения пользователи смогут быстро и удобно просматривать, создавать, изменять и удалять сущности, такие как контакты, компании, задачи, сделки и многое другое.

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

Разработанное мобильное приложение позволит пользователям Synergy CRM более удобно и просто управлять своими бизнес-процессами и повысить доступность приложения. Ниже будет приведено описание этапов разработки приложения, технические особенности и возможности для пользователей.
Архитектурные паттерны и решения, которые необходимо использовать в ходе разработки приложения Synergy CRM для ОС Android были детально рассмотрены в разделе 1.4. Результаты тестирования выполненной разработки для ОС Android представлено в пунктах 14 и 15 настоящего Отчета.

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

Экран Авторизации предназначен для запроса у пользователя логина и пароля для доступа к функционалу приложения (рисунок Г.1). На экране Авторизации пользователь должен ввести свой логин и пароль в специальные поля. При нажатии на кнопку "Войти" приложение отправляет запрос на сервер для проверки данных. Сервер проводит проверку логина и пароля и отправляет ответ в форматеJSON.

В случае, если данные были введены неверно, на экране Авторизации появляется сообщение об ошибке. Пользователь должен ввести корректные данные для продолжения работы с приложением. Если данные были введены правильно, пользователь перенаправляется на главный экран приложения.
Контроль и проверка данных на экране Авторизации является очень важным процессом, так как он обеспечивает безопасность и конфиденциальность пользовательских данных. Надежная система авторизации помогает предотвратить возможность несанкционированного доступа к информации, хранящейся в приложении.
Экран реализован в полном объеме в соответствии с ТЗ, весь доступный функционал проверен и работает.
Экран Меню вызывается на любом экране при нажатии на иконку меню, расположенную в нижней левой части элемента навигационное меню (рисунок Г.2).
Экран Меню является одним из самых важных элементов в приложении. В настройках приложения есть пункт «Основное меню», он поможет пользователю настроить расположение пунктов меню и скрыть неиспользуемые (рисунокГ.3).
Скрытие пунктов функция экрана Меню, которая позволяет убрать те пункты меню, которые пользователь не использует. Например, если пользователю не нужен пункт "Платежи", он может скрыть его и увидеть только нужные пункты меню. Это дает возможность сделать экран меню более удобным и простым для использования (рисунокГ.4).

Синхронизация с веб-версией на старте приложения позволяет пользователям иметь доступ к своим настройкам и данным, сохраненным на сервере. Это удобно для тех, кто часто переключается между мобильной и веб-версиями и привык уже к настройкам меню.
При разработке был использован стандартный компонент NavigationView библиотеки androidx для отображения боковой навигации и информационного хедера с информацией о пользователе. Для навигации использует Jetpack Navigation.
Экран Меню является одним из самых важных элементов приложения. Настройка расположения меню, скрытие пунктов и синхронизация с веб-версией – это три ключевые функции, которые помогают сделать экран Меню более удобным и приятным в использовании.
Функционал меню реализован в полном объеме, весь доступный функционал проверен и работает.
Экран Поиск позволяет пользователям искать определенные объекты из списка всех доступных объектов. Этот экран предоставляет пользователям простой и эффективный способ найти нужный им объект зная только название, экономя их время и усилия (рисунок Г.5).
На экране отображается строка поиска, в которую пользователи могут ввести ключевые слова, относящиеся к искомому объекту. Затем приложение отправляет запрос на сервер с поисковым запросом и в случае успешного поиска приложение получает ответ с найденными объектами, отображая только релевантные результаты распределенными по категориям, к которым относятся объекты (рисунок Г.6).

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

Экран Чаты позволяет просматривать и управлять всеми чатами в одном месте, облегчает отслеживание сообщений(рисунок Г.7).

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

Получение уведомлений реализовано с помощью Firebase cloud messaging, рекомендованной sdk, которая является в отличии от аналогов полностью бесплатной. После того как пользователь прошел авторизацию, на сервер Synergy CRM отправляется информация о токене, полученном при запросе по api Firebase для конкретного устройства. Это нужно для уникальности и идентификации пользователя в среде Firebaseдля получения пользователя уведомления.

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

На экране также можно искать конкретные чаты и управлять настройками, добавлять описание к чату. При необходимости доступно редактирование уже отправленного сообщения.
Экран Чаты – это удобный и эффективный способ управления всеми вашими разговорами в одном месте, не переключаясь в другие приложения для коммуникаций.
Экран Контакты – раздел, содержащий список контактов или другими словами физических лиц, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок Г.8).

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

Каждый контакт в списке содержит подробные данные об отдельном субъекте, включая его имя, должность, компанию, контактную информацию (например, номер телефона и адрес электронной почты). Кроме того, вы можете просмотреть связанные с контактом объекты, такие как задачи, встречи и сделки (рисунок Г.10).
На экране просмотра списка легко добавлять новые контакты, редактировать существующие или удалять контакты, которые больше не актуальны. Также можно создавать пользовательские поля для хранения дополнительной информации о контактах, например, об их отрасли или местонахождении.
Экран Уведомления предназначен для отображения всех уведомлений, которые вы получаете из приложения, включая напоминания о встречах и уведомления о просроченных задачах(рисунок Г.11).
Уведомления кроме экрана, так же дублируются нотификаций в информационной панели вашего телефона. Отслеживая эти уведомления, вы можете быть уверены, что никогда не пропустите важный срок или встречу.

Для получений пушей используется Firebase cloud messaging. При нажатии на нотификацию пользователь может перейти для просмотра объекта, о котором пришла информация.
При открытии экрана информация получается с сервера Synergy CRM, о всех уведомлениях, которые произошли за время с последнего запроса.
Экран организован удобным образом: самые последние уведомления отображаются в верхней части. Вы можете прокрутить список, чтобы просмотреть все уведомления, или применить фильтр уведомлений, чтобы просматривать только определенные типы уведомлений, например, «Вас назначили ответственным» (рисунок Г.12).

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

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

Экран Уведомления обеспечивает централизованное хранение всех уведомлений и позволяет настроить параметры в соответствии с вашими потребностями (рисунок Г.13).
Экраны отображения объектов. Экраны являются типовыми, далее представлено краткое описание по каждому экрану.
Все экраны отображения объектов реализованы по одной схеме: отправка запроса на сервер v1/тип сущности; парсинг ответа; сохранение в бд; отображение на экране.
Экран Компании представляет собой раздел, содержащий список компаний или другими словами юридических лиц, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунокГ.14).
Экран Компании в Synergy CRM является мощным инструментом для управления деловыми отношениями с другими организациями. Этот экран содержит раздел, в котором отображается список всех компаний, созданных вами в веб-версии приложения. Список организован в алфавитном порядке.
Каждая компания в списке содержит подробные данные об организации, включая ее название, отрасль, контактную информацию (например, номер телефона и адрес электронной почты), а также любые примечания или комментарии, которые вы добавили. Кроме того, пользователь может просмотреть связанные с компанией объекты, такие как контакты, задачи, встречи и сделки.
Экран Сделки содержит список сделок, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях(рисунок Г.15).

Экран Сделки позволяет пользователю просмотреть список всех сделок (рисунокГ.16). В случае, если пользователь является управляющим, то он может просматривать все сделки своих подчиненных.

В экране Сделки есть удобный инструмент для управления сделками, позволяющий переключить вид на
«Доску» с разделением сделок по категориям (рисунок Г.17). Имеется возможность перетаскивать сделки между категориями (рисунок Г.18). После открытия сделки можно посмотреть детальную информацию о сделке, а также присутствует возможность удобно изменить статус, не переключаясь с доски (рисункиГ.19 и Г.20).
Экран Заявки представляет собой раздел, содержащий список заявок, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок Г.21).
Экран, на котором пользователь может просмотреть список всех своих заявок, а также в случае управляющих все заявки своих подчиненных. Есть возможность переключить вид на «Доску» с разделением заявок по категориям. Имеется возможность перетаскивать заявки между категориями.
После открытия заявки можно посмотреть детальную информацию (рисунок Г.22), а также присутствует возможность удобно изменить статус, не переключаясь с доски(рисунки Г.23 и Г.24).
Экран Задачи содержит список задач, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунокГ.25).
Экран, на котором пользователь может просмотреть список всех своих задач, а также в случае управляющих все задачи своих подчиненных. Есть возможность переключить вид на «Доску» с разделением задач по категориям. Имеется возможность перетаскивать задачи между категориями.

После открытия задачи можно посмотреть детальную информацию (рисунок Г.26), а также присутствует возможность удобно изменить статус или отправить в архив, не переключаясь с доски (рисунокГ.27).
Экран Счета содержит список счетов, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунокГ.28).

Экран Счета позволяет пользователю просмотреть список всех своих счетов, создать счет или отредактировать существующий (рисунок Г.29).

Экран Платежи содержит список платежей, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях(рисунок Г.30).

Экран Платежи содержит функции, связанные с просмотром соисполнителей (рисунок Г.31). Также имеется функционал по отслеживанию оплаты, отслеживанию статуса платежа, внесению изменений и использованию других функций, сопутствующих финансовым документам (рисунок Г.32).

Экран Сотрудники содержит список сотрудников, созданных в веб-версии SynergyCRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностей (рисунокГ.33). Для пользователя с ролью Управляющий имеется возможность настройки прав сотрудника прямо из приложения.
Экран Продукты содержит список продуктов, созданных в веб-версии Synergy CRM (рисунок Г.34), а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок Г.35). Доступна возможность редактировать и создавать новые сущности.
Экран Документы содержит список документов, созданных в веб-версии SynergyCRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок Г.36). С возможностью редактировать и создавать новые сущности. Обеспечивает удобный доступ к существующей документации созданной в веб-версии Synergy CRM (рисунокГ.37). По функционалу схож с экраном Файлы.

Экран Файлы содержит список файлов, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунокГ.38).
Предназначен для работы и управления файлами, возможностью скачать файл или поделиться с помощью известных мессенджеров или почтовых клиентов, а также вывести на печать документ.
Экран Звонки обеспечивает возможность просматривать историю совершенных звонков, информацию, такую как длительность, номера исходящих и входящих, а также прослушать при необходимости запись разговора.
Экран Склад представляет собой раздел, в котором можно осуществлять складские операции (рисунок Г.39) и управлять номенклатурой и ее вложенностью в сделки (рисункиГ.40 – Г.44).
Экран Сканер штрих-кодов предоставляет функционал, позволяющий проводить складские операции, сканируя штрихкод приложением.
Предоставляет функции, связанные с управлением складскими запасами: создание операций перемещения, списания, отгрузки, заказа покупателя, оприходования, приемки и заказа поставщику и созданием мест хранения.
Реализован двумя экранами: экран Операции; экран Места хранения.

Экран Сканер штрих-кодов дает возможность добавить позиции к операции через выбор нужной позиции с использованием сканера штрих-кода (рисунок Г.45). Сканер использует библиотеку машинного зрения MLKit для распознавания кода, а также Camera View для вывода изображения с камеры в приложении.
Работа над функциональными возможностями склада еще ведется, разрабатываются новые разделы, которые уже реализованы в веб-версии SynergyCRM.
Экран Договоры содержит информацию о текущих и прошлых договорах с возможностью просмотра связи договора, например, с контактом, компанией, заявкой и других (рисунки Г.46 – Г.48).
Экран Проекты позволяет пользователю просмотреть список всех своих проектов, а также в случае, если пользователь находится в статусе Управляющий, просмотреть все проекты своих подчиненных. Этот экран имеет простой и понятный дизайн, который помогает быстро ориентироваться в списке проектов (рисунокГ.49).

В верхней части экрана находится шапка, которая предоставляет доступ к другим важным функциям приложения. Ниже находится список проектов, отображаемый в виде карточек. Каждая карточка содержит краткое описание проекта (рисунок Г.50).

Пользователь может просмотреть детальную информацию о проекте, нажав на соответствующую карточку. При долгом нажатии каждой карточки есть некоторые дополнительные функции, такие как архивирование или удаление проекта.
Экран Проекты также предоставляет возможность пользователям создавать новые проекты и добавлять в них задачи. Для этого на экране есть кнопка с плюсом (рисунок Г.51).
В целом, экран Проекты в приложении является очень полезным инструментом для организации и управления проектами. Его простой и понятный интерфейс помогает пользователю быстро находить нужную информацию и легко управлять своими проектами.
Также обеспечивает удобные инструменты для управления проектами, возможность переключить вид на
«Доску» с разделением проектов по категориям. Имеется возможность перетаскивать проекты между категориями (рисунокГ.52).
После открытия проекта пользователь может посмотреть детальную информацию о проекте, а также посмотреть список задач, соответствующих проекту, разделенный по категориям задач. Присутствует возможность удобно завершить или отложить задачу, не переключаясь с доски(рисунок Г.53).
Экран Настроек прав. Предоставляет доступ к настройкам различных параметров и уровням доступа. Данный функционал доступен пользователям с ролью «Администратор» (рисунки Г.54 – Г.55).
Конфигурация настроек прав запрашивается приложением на старте с сервера, что учесть изменения произошедшие в веб версии, пока приложением не пользовались и обновляет прошлые настройки прав.
Экран Справочники предоставляет доступ к настройке, созданию и удалению основных справочников, которых соответствуют реализованным объектам мобильного приложения (рисунки Г.56 – Г.57).

Также предусмотрена возможность смены языка (рисунокГ.58) и выбора темы оформления (рисункиГ.59
– Г.60), что дает пользователям свободу выбора в настройке приложения в соответствии с их личными предпочтениями.
Экран Сортировка представляет собой функцию приложения, которая позволяет пользователям сортировать объекты в списке по атрибутам, соответствующим конкретному объекту (рисунок Г.61). На этом экране отображаются все доступные варианты сортировки, такие как алфавитный порядок, дата создания или индекс. Экран Сортировка предоставляет пользователям возможность организовать список объектов на основе своих предпочтений, облегчая поиск и доступ к конкретным объектам.

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

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

Экран Параметры атрибутов позволяет пользователям настраивать атрибуты выбранного объекта. На этом экране отображаются все доступные атрибуты объекта, такие как создатель, ответственный или тип (рисунокГ.62). Экран Параметры атрибутов предоставляет пользователям возможность изменять атрибуты объекта в соответствии со своими предпочтениями.
Экран Настройки атрибутов расположен на экране просмотра объекта и доступен через меню объекта, во всплывающем диалоговом окне пункт «Настроить поля».

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

Экран Настройки атрибутов является важной функцией для приложения, которая позволяет пользователям эффективно изменять и настраивать объекты.
Экран Создание объекта позволяет пользователю может создать новую сущность путем нажатия на кнопку «Создать». Для каждой сущности доступны для заполнения определенные поля, некоторые из которых могут быть настроены как обязательные в веб-версии SynergyCRM (рисунок Г.63).
Список видимых полей может быть настроен пользователем при нажатии на иконку «Троеточие» в верхней правой части экрана и выборе пункта «Видимость полей». В появившемся модальном окне пользователь определяет какие поля должны отображаться в форме создания сущности.
Для создания сущности пользователь заполняет необходимые поля и нажимает на кнопку «Создать», расположенную в нижней части экрана. Если не заполнены обязательные поля, то они подсвечиваются красным цветом и в верхней части экрана появляется уведомление с текстом «Не заполнены обязательные поля».
Кнопка «Создать» является одной из самых важных функций в приложении, позволяющей пользователям создавать новые объекты или записи. Основная задача данного функционала заключается в облегчении и ускорении процесса создания нового объекта (рисунок Г.64).

Кнопка «Создать» легко доступна для пользователя. Она расположена на главной странице приложения, в меню и на панели инструментов при просмотре списка объектов. Кнопка «Создать» имеет различные функции в зависимости от контекста: например, на экране «Контакты», взаимодействие с кнопкой перенаправит пользователя на экран создания «Контакта» (рисунокГ.65).

При взаимодействии с кнопкой в навигационной панели, пользователю покажется стандартное диалоговое окно выбора, содержащая список всех объектов доступных для создания(рисунок Г.66).
Основная функция кнопки «Создать» состоит в открытии формы для создания нового объекта. Эта форма может содержать различные поля для заполнения, такие как название, описание, дата, местоположение и т.д. В зависимости от типа объекта, форма может содержать различные поля и опции, свойственные выбранному объекту. Также при создании объекта реализована проверка обязательных полей для заполнения, в случае если поле не заполнено, то на экране появится аллерт реализованный с помощью стандартного компонента Android Snackbar, который подскажет пользователю, какое поле необходимо заполнить.

Кнопка «Создать» имеет определенную функцию, такую как сохранение объекта в базу данных и отправка его на сервер. В меню настроек приложения имеется возможность настройки списка доступных объектов для создания, есть функция скрытия пункта из списка, а также изменить расположение пунктов в списке (рисункиГ.67 – 68).
В целом, функциональность кнопки «Создать» интуитивно понятна и удобна для пользователя, что позволяет ускорить процесс создания новых объектов и делает использование приложения более эффективным.
Функционал разработан в соответствие с ТЗ, с внесением корректировок по отображению уведомления. Показ уведомления перенесен в нижнюю область приложения, для сохранения единого стиля оформления информационных сообщений.

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

Экран Активность является важной информационной функцией для приложения, позволяющей пользователям с ролью «Управляющий» отслеживать изменения и контролировать «Менеджеров» с течением времени.

Экраны Архив и Корзина позволяют пользователям просматривать и восстанавливать ранее удаленные элементы. Вывод на экран списка объектов реализован с помощью отправки на сервер запроса с применением фильтра, по которому формируется ответ, содержащий только сущности, которые отправлены в Архив (рисунок Г.69) или в Корзину (рисунокГ.70).
На экранах Архив или Корзина пользователи могут просмотреть список всех удаленных объектов. Они могут выбрать конкретный элемент, чтобы просмотреть его подробную информацию и восстановить его, если это необходимо.
Для удаления или отправки в архив, на экране просмотра объекта реализовано дополнительное меню, с использованием стандартного окна диалога BottomSheetDialogFragment ОС Android. После выбора действия с объектов, пользователю необходимо подтвердить свое намерение, что благоприятно сказывается на пользовательском опыте и предотвращает случайное действие над объектом.

Экраны Архив и Корзина являются важным компонентами приложения, которые позволяют пользователям управлять своими объектами. Эти экраны являются неотъемлемой частью приложения и обеспечивают удобство и эффективность использования.

Функционал экранов реализован в полном объеме в соответствии с ТЗ, весь доступный функционал проверен и работает.
В результате работы было разработано и реализовано удобное и функциональное приложение, которое позволяет пользователям эффективно управлять своими задачами и проектами, а также быстро получать доступ к необходимой информации и документации.
Таким образом, разработанный модуль обеспечивает функции, согласно пункту 4.1.1 технического задания: интеграция с интернет-магазинами, доступ через мобильное приложение; соответствует входным воздействиям в пункте 4.1.3 технического задания в полном объеме, соответствует выходным реакциям в пункте4.1.4 технического задания в полном объеме.
1Разработка модуля интерактивного онбординга по системеSynergy CRM
7.1 Цели и задачи разработка модуля интерактивного онбординга
Целью данной части проекта является разработка интерактивной системы обучения пользователя для приложения Synergy CRM в формате последовательных этапов и шагов, выполняя которые пользователь приобретает опыт взаимодействия с основными разделами и сущностями приложения для эффективной работы в Synergy CRM.
В Synergy CRM имеются различные разделы для эффективного управления бизнесом такие как: рабочий стол, компании, контакты, сделки, заявки, задачи, документы, договоры, финансы, настройки, и другие.
Для самостоятельного и оперативного ознакомления со структурой приложения, получения реального опыта взаимодействия с основными разделами и создания различных сущностей в приложении, требовалось обеспечить наглядность, удобство и информативность для новых пользователей Synergy CRM.
Для достижения этих целей был произведен опрос опытных пользователей и собран перечень основных пожеланий, возникающих на начальных этапах использования приложения. Проанализировав все собранные данные, выявлены следующие потребности. Во-первых, необходима общая информация по каждому разделу с иллюстрациями и возможностью в любое время повторно изучить информацию о разделе. Во-вторых, необходима интерактивная демонстрация работы с разделом «Рабочий стол», как с одним из основным рабочих инструментов, где консолидируется общая информация для работы каждого конкретного пользователя (аналитические отчеты, карточки с различными сущностями, которые возможно настроить под конкретные задачи пользователя). В-третьих, необходим функционал последовательных шагов по взаимодействию с одним из разделов приложения Synergy CRM (так как все разделы приложения разработаны по единообразной визуальной и функциональной структуре, то достаточно показать пользователю взаимодействие с любым из разделов).
Так как работа с системой проводится в режиме реального времени, было принято решение использовать в качестве основы мультипарадигменный язык программирования JavaScript, как наиболее подходящий инструмент в рамках задачи по созданию функционала интерактивного обучения пользователя в связке с CSS и Ruby on Rails.
На первом этапе необходимо разработать backend, включающий в себя контроллер управления взаимодействия пользователя с приложением и сущности в базе данных.
На втором этапе необходимо разработать frontend, включающий в себя визуализации с применением шаблонизатора Haml.
Необходимо разработать три обучающих модуля, отвечающих за управление поведением приложения в зависимости от действий пользователя при прохождении обучения: обучающий модуль Знакомство («Basic onboarding»); содержит общую информацию с иллюстрациями по каждому из основных разделов Synergy CRM; обучающий модуль Рабочий стол («Indiboard onboarding»); содержит пошаговую инструкцию; раздел «Компании» («Companies onboarding»); содержит пошаговую инструкцию.
7.2 Модуль управления обучением «Знакомство»
В рамках работы над проектом с целью создания модуля интерактивного онбординга по системе Synergy CRM был разработан и реализован модуль управления обучением «Знакомство». Основные рисунки с примерами работы модуля приведены в приложении Д. Основные значимые функции, реализованные для модуля управления обучением «Знакомство» приведены в Приложении Е. Рассмотрим назначение и особенности реализованных функций.

Функция currentSection() определяет по текущему шагу обучения какую секцию (элемент) необходимо найти на странице и сфокусировать на нём внимание пользователя, выделив от всего остального контента на текущей веб-странице. Так как функционал класса базового обучения разработан в универсальном формате, то используются специфические свойства в зависимости от которых применяется то или иное решение по фокусировке элемента на странице.

Функция initNavMenuConfigSection() определяет и раскрывает секцию скрытого навигационного меню для отображения пользователю во время прохождения обучения.
Функция initTopRightMenuSection() подготавливает дополнительное меню в правом верхнем углу веб-страницы или возвращает иконку дополнительного меню для фокусировки пользователя.
Функция initDefaultSection подготавливает видимую секцию горизонтального меню для фокусировки пользователю в зависимости от текущего шага обучения.
Функция initSettingsSection() подготавливает секцию настроек и возвращает элемент веб-страницы на который необходимо сфокусироваться пользователю.
Функция initVisibleBasicSection() подготавливает и возвращает текущую секцию из скрытого подменю горизонтального меню для фокусировки пользователю.
Функция initSubmenuBasicSection(). У некоторых визуально скрытых секций горизонтального меню существует собственно дополнительное скрытое меню, которое следует демонстрировать пользователю для наглядности работы с приложением, за этот функционал отвечает Функция initSubmenuBasicSection().
Функция changeDisplayProperty() является вспомогательной. Она отображает или скрывает от пользователя секции в зависимости от сценария на текущем шаге обучения.
Функция closeTopRightMenu() закрывает дополнительное меню в верхней правой части веб-страницы в случае если шаг обучения не подразумевает работу с данной секцией или требуется обновить контент внутри меню в текущий момент.
Функция closeSettings() закрывает секцию настроек, когда шаг не подразумевает её отображение или необходима перезагрузка контента меню настроек.
Функция loadSettings() подготавливает контент к отображению на веб-странице.
Функция loadTopRightMenuItems() подготавливает элементы внутри дополнительного меню в верхней правой части веб-страницы к отображению секции текущего шага обучения пользователя.
Рассмотрим пример работы модуля управления обучением «Знакомство», реализованного на основе разработанных функций. Основные рисунки приведены в приложении Д. На рисункеД.1 приведен пример, в котором система выделяет выбранный раздел в верхней части экрана в горизонтальном списке, а также показывает главный экран, в левой части которого расположен прокручиваемый вертикальный список всех основных разделов приложения. В правой части экрана анимация работы и общая информация о разделе. Интересующий раздел системы можно выбрать как с помощью вертикального списка в левой части экрана, так и нажав кнопку «Далее» в правом нижнем углу экрана.
На рисунке Д.2 приведен пример для раздела «Задачи». Видно, что секция в верхнем горизонтальном списке веб-страницы, на которой фокусируется внимание пользователя, изменилась на соответствующую текущему шагу обучения, а также обновился контент внутри модального окна. На рисунке Д.3 приведен пример отображения раздела «Компании». Секция фокусировки так же изменилась, контент обновлен в соответствии с текущим шагом обучения.
7.3 Модуль управления обучением «Рабочий стол»

В рамках работы над проектом с целью создания модуля интерактивного онбординга по системе Synergy CRM был разработан и реализован модуль управления обучением «Рабочий стол». Основные значимые функции, реализованные для модуля управления обучением «Рабочий стол» приведены в Приложении Е. Рассмотрим назначение и особенности реализованных функций.
Функция currentSection() определяет по текущему шагу обучения какую секцию (элемент) необходимо найти на странице и сфокусировать на нём внимание пользователя, выделив от остального контента на текущей веб-странице.
Функция selectorBy() является вспомогательной и работает как хранилище всех секций обучения с возможностью определения текущей секции по названию ключа.
Функция prepareStep() подготавливает текущий шаг, очищает предыдущие результаты отображения и запускает специальную интервальную функцию которая отслеживает загрузку контента веб-страницы и помогает модулю работать с полностью загруженной веб-страницей.
Функция initStep() инициирует и определяет на основании текущего шага прохождения обучения пользователем, секцию фокусировки, подготовку всплывающих подсказок и необходимых событий которые должны происходить в процессе взаимодействия с подсказками и целевыми элементами на веб- странице.
Функция initStepEvents() является методом, который шаг за шагом выполняет различные задачи или инициализирует соответствующие события, основанные на значении свойства «this.step» объекта. В начале функции некоторые значения выбираются с помощью метода «this.selectorBy()», и параметры инициализируются со стандартными значениями. Далее, в зависимости от значения «this.step», функция возвращаемте различные реализации:
●если «this.step» равен 1, функция инициирует кнопку плюса с помощью метода
«this.initPlusButton()».
●если «this.step» равен 2, параметры обновляются и вызывается метод «this.initLinkButton()».
●если «this.step» равен 3, запускается некоторая функция интервала с помощью
«this.intervalFunction()».
●если «this.step» равен 4, параметры обновляются, вызывается метод«this.initLinkButton()», а также происходит перенаправление к отчёту.
●если «this.step» равен 5, происходит модификация URL и вызывает функцию
«this.initSettingsWheel()».
●если «this.step» равен 6, параметры обновляются, дополнительные события добавляются через клик на«clickableTrigger» и устанавливаются значения в localStorage.
●если «this.step» равен 7, параметры обновляются и добавляются взаимодействия с кнопкой"next".
●если «this.step» равен 8, содержание webui обновляется и вызывается функция
«this.initSettingsWheel()».
●если «this.step» равен 9, параметры обновляются и кнопка становится кликабельной.
●если «this.step» равен 10, параметры обновляются и производится GET-запрос на сервер.
●если «this.step» равен 11, параметры обновляются и производится еще один GET-запрос на сервер.

В этом контексте, «this.params» является объектом, содержащим различные параметры для обновления или инициализации различных объектов или функций. Обновления «this.params» включают значенияcloseable, targetButton, update,webuiOffsetLeft и т.д., в зависимости от значения «this.step». Множество вспомогательных функций используется для взаимодействия с DOM-элементами или выполнения асинхронных операций, таких как «this.selectorBy()», «this.intervalFunction()», «this.updateStep()», «this.initLinkButton()» и т.д.
Функция newIndiboardStep() инициирует работу с шагом по добавлению новой доски (рабочего стола). Очищает результаты отображения контента предыдущего шага, добавляет необходимые CSS стили к элементам текущего шага подготавливает форму к отправке и работает с ограничением действий пользователя при прохождении обучения с целью соблюдения пошаговой структуры.
Функция dragAndDropIndiboardStep() инициирует работу с шагом о возможности вертикального перемещения досок в модальном окне в левой части веб-страницы с целью изменения текущей области видимости.
Функция webuiPopoverWithButton() служит для подготовки всплывающей подсказки с обновленным контентом и кнопками в зависимости от текущего шага прохождения обучения.

Функция initIndiboards() осуществляет подготовку контента веб-страницы Рабочий стол.
Функция redirectToReport() осуществляет демонстрацию созданного отчета на рабочем столе, а также инициирует событие последующего перехода в реестр аналитики, при нажатии на название отчета, где демонстрируется подробное отображение созданного отчета.
Функция initSettingsWheel() инициирует события для работы с настройками.
Функция prepareCreatedReport() подготавливает контент к следующему шагу после создания аналитического отчёта на рабочем столе.
Функция showCreatedReport() инициирует перезагрузку контента рабочего стола и запускает скрипт подготовки созданного аналитического отчета к отображению на рабочем столе и фокусировке пользователя на нём.
Функция initPlusButton() подготавливает контент к шагу о добавлении новых виджетов (карточек) на рабочий стол.
Функция initLinkButton() подготавливает кнопки во всплывающем меню для возможности взаимодействия с ними пользователю.
Функция initReportForm() подготавливает всплывающие подсказки, форму заполнения нового отчета на рабочий стол, контроль последовательности действий пользователя для корректного прохождения обучения, отправляет данные на сервер и инициирует запуск следующего шага.
Рассмотрим пример работы модуля управления обучением «Рабочий стол», реализованного на основе разработанных функций.
На первом шаге система выделяет кнопку на экране на которую необходимо нажать пользователю для совершения действия. Каждое новое действие сопровождается информацией о результате действий пользователя (рисунок Д.4).
В результате выполненного действия раскрывается список различных вариантов виджетов. На рисунке Д.5 показан шаг 2 по выбору виджета Отчет. На рисунке Д.6 выполняется первый этап шага 3 по заполнению формы виджета. Пользователь выбирает вариант отчёта. Кнопка сохранить в данном случае неактивна, так как не заполнены обязательные поля. На рисунке Д.7 показан второй этап шага 3 по заполнению формы виджета. Пользователь заполняет название отчёта. Кнопка сохранить в данном случае неактивна, так как не заполнены обязательные поля. На рисунке Д.8 показан третий этап шага 3 по заполнению формы виджета, заключающийся в выборе периода отчета. На рисунке Д.9 показан четвертый этап шага 3 по заполнению формы виджета, заключающийся в выборе вида отчета (Диаграмма / Таблица). На рисунке Д.10 показан пятый этап шага 3 по заполнению формы виджета, заключающийся в выборе цвета шапки виджета. На рисунке Д.11 выполняется четвертый шаг по добавлению виджета на рабочий стол. Система автоматически прокручивает страницу рабочего стола вниз и показывает место нахождения виджета. На рисунке Д.12 продемонстрирован переход в аналитический отчёт на шаге 4. После нажатия на название отчета, система открывает страницу выбранного отчета на 4 секунды и возвращается на рабочий стол для прохождения следующего этапа обучения. На рисунке Д.13 продемонстрирован пятый шаг по обновлению состояния. На рисунке Д.14 продемонстрирован шестой шаг с процессом пересчета(обновления) досок.

На рисункеД.15 продемонстрирован седьмой шаг, на котором задается временная блокировка повторного обновления досок. На рисунке Д.16 продемонстрирован восьмой шаг по просмотру доступных досок пользователю. На рисунке Д.17 продемонстрирован девятый шаг, на котором выполняется настройка и просмотр доступных досок. На рисунке Д.18 продемонстрирован десятый шаг по добавлению новой доски (рабочего стола).При заполнении формы доски пользователю предлагается заполнить название и сохранить новую доску (рисунокД.19). На рисункеД.20 продемонстрирован одиннадцатый шаг в котором выполняется изменение последовательности отображения досок.
7.4 Модуль управления обучением «Раздел Компании»

В рамках работы над проектом с целью создания модуля интерактивного онбординга по системе Synergy CRM был разработан и реализован модуль управления обучением «Раздел Компании». Основные значимые функции, реализованные для модуля управления обучением «Раздел Компании» приведены в Приложении Е. Рассмотрим назначение и особенности реализованных функций.
Функция prepareStep() подготавливает отображение текущей области в соответствии с шагом обучения.
Функция initStep() подготавливает текущий шаг в зависимости от готовности веб-страницы.
Функция initStepEvents() запускает скрипты в зависимости от текущего шага.
Функция initPageHeading() устанавливает положение выделяемой области заголовка таблицы и каждого последующего целевого элемента обучения.
Функция initSectionLink() выделяет ссылку на раздел “Компании” и запускающая скрипт шага.
Функция initCompanyAddButton() выделяет кнопку добавления новой компании и управляет загрузкой модального окна с формой заполнения параметров компании.
Функция showOrCreateWebuiPopover() управляет созданием или перезагрузкой всплывающих подсказок.
Функция showCreatedEntity() отвечает за демонстрацию созданной сущности Компании.
Функция showCompanyInfo() отвечает за демонстрацию информации о компании в модальном окне.
Функция showCreatedEntity() отвечает за демонстрацию действий с карточкой компании.
Функция showCardActions() отвечает за демонстрацию вкладок в карточке компании.
Функция showRequisites() отвечает за демонстрацию формы заполнения реквизитов компании.
Функция showCardActions() отвечает за демонстрацию области редактирования реквизитов.
Функция banksTab() отвечает за демонстрацию вкладки «Банковские реквизиты».
Функция showBanks() отвечает за демонстрацию формы «Банковские реквизиты».
Функция editBanks() отвечает за редактирование формы 2Банковские реквизиты».
Функция showTasksAndComments() отвечает за демонстрацию вкладки задач и комментариев в карточке компании.
Функция openTasksAndComments() отвечает за демонстрацию области задач и комментариев в карточке компании.
Функция showActivities() отвечает за демонстрацию области активностей по компании и относящимися к ней сущностями.
Рассмотрим пример работы модуля управления обучением «Раздел Компании», реализованного на основе разработанных функций. На рисунке Д.21 продемонстрирован первый шаг в котором система выделяет раздел Компании в верхней части экрана в горизонтальном списке для дальнейшего перехода в раздел и продолжения прохождения обучения. На рисунке Д.22 показан второй шаг по демонстрации элементов управления таблицей в разделе Компании. На рисунке Д.23 показан третий шаг по демонстрации местонахождения вспомогательных таблиц Архив и Корзина. На рисунке Д.24 показан четвертый шаг по демонстрации кнопки добавления новой компании. На рисунке Д.25 показан пятый шаг по демонстрации режима отображения реестра компаний в виде таблицы или карты. На рисунке Д.26 показан шестой шаг по демонстрации информации о создании и настройке пользовательских фильтров для вывода результатов в таблице. На рисунке Д.27 показан седьмой шаг по демонстрации информации об отображении фильтров в таблице. На рисунке Д.28 показан восьмой шаг по демонстрации строки поиска информации по таблице. На рисунке Д.29 показан девятый шаг по экспорту компаний из таблицы в xlsx или csv файл. На рисунке Д.30 показан десятый шаг по импортированию компаний из внешнего xlsx или csv файла. На рисунке Д.31 показан одиннадцатый шаг по настройке параметров таблицы. На рисунке Д.32 показан двенадцатый шаг по добавлению новой компании. На рисунке Д.33 показано заполнение параметров компании в рамках Шагов 13 - 15. Последовательно заполняются поля ИНН, название и телефон. На рисунке Д.34 показан шестнадцатый шаг по демонстрации информации о созданной компании. На рисунке Д.35 показан семнадцатый шаг по демонстрации элементов управления компанией. На рисунке Д.36 показан восемнадцатый шаг по демонстрации отображения связанных с текущей компанией сущностей. На рисунке Д.37 показан девятнадцатый шаг по работе с реквизитами компании из карточки объекта. На рисунке Д.38 показан двадцатый шаг по демонстрации области заполнения реквизитов компании. На рисункеД.39 показан шаг 21 по переходу во вкладку Банки. На рисунке Д.40 показан шаг 22 по добавлению нового банковского счета. На рисунке Д.41 показан шаг 23 по заполнению БИК банка. На рисунке Д.42 показан шаг 24 по работе демонстрации области добавления активностей по компании с реквизитами компании из карточки объекта. На рисунке Д.43 показан шаг 25 по демонстрации выбора соответствующей активности области заполнения реквизитов компании. На рисунке Д.44 показан шаг 26 по демонстрации области отображения активностей по компании.
8 Разработка BPMN-конструктора автоматизаций
8.1 Цели и задачи разработки BPMN-конструктора автоматизаций

Цель разработки данного модуля заключается в реализации возможности создания новых сценариев автоматизации при помощи конструктора BPMN. Это позволит выстроить автоматизированные процессы внутри Synergy CRM используя понятный визуальный редактор процессов. Такое решение позволяет сделать настройку интерактивной и наглядной, чтобы можно было отслеживать все свои бизнес процессы на схеме.Также это позволяет автоматизировать большое количество аспектов бизнес-процессов.

В Synergy CRM есть отдельный модуль «Автоматизация». Данный модуль предназначен для создания сценариев, которые позволяют автоматизировать некий бизнес-процесс, например: создавать контакт после входящего телефонного звонка с неизвестного номера.
В монолите Synergy CRM создание сценария реализовано при помощи форм и асинхронных запросов к бэкенду приложения.
Сам процесс создания сценария можно разделить на четыре этапа:
●выбор сущности, при взаимодействии с которой будет отрабатывать автоматизация;
●выбор действия, которое произошло с сущностью;
●выбор условия(опционально);
●выбор действий, которые будут произведены при выполнении первых трех пунктов.

В монолите Synergy CRM для каждого условия, каждого действия реализованы свои представления, которые подгружаются в форму асинхронным запросом. Наличие полей у условий и действий различается. Используются:
●Javascript библиотека «bpmn-js»;
●Javascript библиотека «bpmn-js-properties-panel»;
●Javascript библиотека «xml-js»;
●Ruby библиотека «ox»;
●фреймворк Ruby on Rails.
Проанализировав создание сценариев автоматизации, было принято решение для отдельных элементов создания сценария выбрать следующие фигуры:
●сущность представлять фигурой квадрат;
●действие над сущностью представлять фигурой прямоугольник;
●условие представлять фигурой овал;
●действие представлять фигурой треугольник;
●соединяющие элемент между действием над сущностью и действием автоматизации представлять фигурой ромб;
●соединяющий элемент между фигурами представлять фигурой стрелка.
Для возможности создания сценария при помощи конструктора BPMN, была выбрана библиотека с открытым исходным кодом bpmn-js. Данная библиотека состоит из различных модулей, которые можно переписывать под свои задачи.
8.2 Разработка и реализация BPMN-конструктора автоматизаций

Прежде чем приступить к разработке и реализации функций, была спроектирована диаграмма потоков данных, описывающая работу BPMN-конструктора автоматизаций (рисунок 8.1).
В рамках работы был разработан и реализован модуль BPMN-конструктора автоматизаций. Основные значимые функции, реализованные для модуля BPMN-конструктора автоматизаций приведены в Приложении Ж. Рассмотрим назначение и особенности реализованных функций.

Пример функции инициализации доски конструктора приведен в приложении Ж. В данном примере начальный шаблон сценария в виде BPMN поступает с сервера приложения в виде xml файла, который считывается модулем bpmn-js, отвечающим за отрисовку. В представленном примере инициализации доски конструктора (приложение Ж) выполняется асинхронный запрос по url, который содержится в атрибуте контейнера. После получения ответа необходимо инициализировать «моделлер» bpmn-js для отрисовки схемы.

Первый передаваемый атрибут container – это контейнер на странице html, где будет инициализирован контейнер схемы. Атрибут propertiesPanel отвечает за контейнер, где будет инициализирована панель свойств объектов схемы. АтрибутadditionalModules отвечает за расширение для «кастомного моделлера». Атрибут moddleExtensions отвечает за расширение типов для конструктора (подключается файл в формате json, где описываются атрибуты и их типы). Пример содержания файла с атрибутами конструктора приведен в приложении Ж. В данном примере описана «фигура» AutomatizationObject, которая наследуется от bpmn:Task. Для нее определено свойство class_name, которое содержит в себе текстовое значение.

За отрисовку фигур отвечает модуль, который расширяет функционал стандартного модуля BaseRenderer. Модуль отрисовки фигур приведена в приложении Ж. Это JavaScript код, написанный с помощью ES6 синтаксиса, предназначенный для кастомизации отображения BPMN диаграммы с помощью bpmn-js, библиотеки на основе diagram-js. Класс CustomRenderer экспортируется в качестве модуля. Он наследуется от BaseRenderer (базового класса для рендеринга элементов диаграммы) и включает пользовательские методы для отрисовки различных типов BPMN элементов, таких как задачи (tasks) и события (events). Модуль отрисовки фигур использует следующие функции:

●Функция canRender(element) определяет, должен ли этот рендерер отображать заданный элемент. Элементы, которые этот рендерер отображает, включают в себя различные BPMN события и кастомные типы.
●Функция drawShape(parentNode, element) отрисовывает заданный элемент. Здесь заданный элемент может быть кастомным, а также BPMN StartEvent или EndEvent. В зависимости от типа элемента, он рисуется на родительском узле с помощью соответствующих функций рисования.
●Функция getShapePath(shape) возвращает путь кривой для данной формы. Если форма является определенной кастомной формой, используется кастомная функция getActionPath. В противном случае вызывается getShapePath от bpmnRenderer.
●Функции вспомогательного рисования, такие как drawRect, drawCircle, drawRombus, drawEllipse, drawTrapezoid, drawTriangle, addTextOnShape и getActionPath. Каждая из этих функций использует набор функций из библиотеки tiny-svgдля создания и стилизации SVG элементов.
●Функция CustomRenderer.$inject = ['eventBus', 'bpmnRenderer'] используется для внедрения зависимостей в конструктор класса. Это означает, что CustomRenderer зависит от служб eventBus и bpmnRenderer, который является базовым рендерером BPMN-js.
В зависимости от типа элемента, который передается на отрисовку, указывается его параметры высоты, ширины и другие.
Указывать атрибуты для элементов конструктора можно через панель свойств, которая предоставляется библиотекой bpmn-js-properties-panel. Данная библиотека довольно гибкая в настройке, что позволяет задавать собственные поля в зависимости от выбранного объекта на доске. Пример подключения собственных панелей к панели свойств приведен в приложении Ж. Это модуль, который модифицирует панель свойств в BPMN редакторе. В начале кода происходит импорт нескольких модулей, которые соответствуют различным типам свойств (EntityProps, EntityActionProps, ConditionProps, ActionProps и ProcessProps). В коде создается функция-конструктор CustomPropertiesPanel, которая принимает пять параметров: панель свойств, словарь для перевода, реестр элементов, фабрику элементов и моделирование. Внутри функции-конструктора определяется метод getGroups, который возвращает функцию, принимающую группы свойств, модифицирует их, удаляя два элемента из группы general и добавляя новую группу, если текущий элемент является c:AutomatizationObject. Затем происходит регистрация функции в панели свойств с низким приоритетом (500). Внутри этого модуля также определена дополнительная функция createEntityGroup, которая создает словарь со свойствами новой группы.

Пример «отрисовки» полей на панели свойств приведен в приложении Ж. В этом коде JavaScript/React используется для создания компонента, который представляет собой выпадающий список или "select". Используются импортированные модули: html из «htm/preact», SelectEntry и isSelectEntryEdited из
«@bpmn-io/properties-panel», useService из «bpmn-js-properties-panel», и три helper функции из
«bpmn_helper.js». Также импортируется массив ENTITIES, который содержит список возможных сущностей. Операция «export default function»возвращает массив объектов с набором свойств:id, element, elementRegistry, component, isEdited. ClassName представляет собой функциональный компонент React. В начале функции, используется служба «useService» для получения доступа к сервисам modeling,translate и debounceInput. Методы getValue, setValue, getTextForAnnotation и removeConditions используются для изменения состояния и обновления значения element. Метод getOptions возвращает массив для опций выпадающего списка, каждый объект включает параметры label и value.

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

Так как bpmn-js работает только с форматомxml, то для корректного сохранения сценария из схемы, было принято решения воспользоваться библиотекой xml-js, которая позволяет конвертировать xml в json. Пример функции конвертации данных сущности и действия с сущностью приведен в приложении Ж. Это JavaScript код, который принимает один аргумент, объект, из которого функция пытается извлечь атрибуты, соответствующие определенным сценариям. Внутри функции getScenarioAttributes определены три константы:

●SCENARIO_SHAPES представляет собой массив строк, каждая из которых представляет определенный тип сценария или форма данных для анализа.
●SCENARIOS_AVAILABLE_ATTRIBUTES представляет собой объект, который отображает каждый тип сценария, указанный в SCENARIO_SHAPES, на массив его доступных атрибутов.

●EXCEPTION_FIELDS представляет собой объект, который используется для категоризации некоторых атрибутов сценариев по отдельности.

Функция конвертации данных также создает пустой объект scAttributes, который будет заполнен атрибутами из входного объекта, соответствующими сценариям, определенным в SCENARIO_SHAPES. Затем, перебирая каждый тип сценария в SCENARIO_SHAPES, функция пытается найти и добавить соответствующие атрибуты из входного объекта в scAttributes. Если атрибут существует и занесен в исключения (EXCEPTION_FIELDS), он добавляется в scAttributes как часть сущности product_class. Если атрибут el равен значению manual_required_fields, то значение этого атрибута из входящего объекта преобразуется в массив, разделяя каждый элемент по запятой, и затем добавляется в сущность scAttributes. В противном случае, значение атрибута просто копируется в сущностьscAttributes. После прохода по всем сценариям функция возвращает сущностьscAttributes.

Для редактирования существующего сценария в конструкторе, необходимо с сервера приложения отдавать данные в виде xml файла, который мог бы считать «моделлер» библиотеки bpmn-js. Для генерации xml используется библиотека «ox». Пример базового класса для генерации фигуры с атрибутами приведен в приложении Ж. Код на языке Ruby определяет модуль ScenariOS, в котором содержится модуль Shape. Внутри модуля Shape определен класс Base, который представляет базовую форму или модель для различных "форм" или "сценариев", с которыми программа может работать. В этом классе определены следующие атрибуты:

●x, y описывают координаты базовой формы;
●prev_shape указывает на предыдущую форму;
●connections представляет собой список связей с другими формами.
В методе initialize эти атрибуты инициализируются из переданных опций. Метод to_xml определяет структуру XML, которая будет использоваться для записи информации о форме. Он состоит из двух блоков: process_block и plane_block. Методы id, description, process_block объявлены, но не реализованы в этом базовом классе. Такой подход часто используется в объектно-ориентированном программировании для создания абстрактных классов или интерфейсов. Методы width и height возвращают '0'. В методах incomming_coordinates и outgoing_coordinates возвращаются координаты для определенного направления, в зависимости от направления, переданного функции. Приватный метод plane_block генерирует XML представление формы. Приватный метод coordinates создает XML элемент, содержащий координаты и размеры текущего класса или формы.

Код класса для генерации фигуры объекта приведен в приложении Ж. Этот код представляет собой модуль Ruby с классомAutomatizationObject, который является подклассом Base. Код класса для генерации фигуры объекта использует следующие методы:
● Метод initialize(options) инициализирует экземпляр класса. Он принимает хэш options, из которого берет class_name.
●Методы id, x, y, height,width. Это геттеры, которые возвращают значение соответствующего атрибута объекта или вычисляют его, если оно еще не было установлено.
●Метод name. Этот метод позволяет получить локализованное имя объекта в соответствии с его class_name.
●Метод to_json(*_args) преобразовывает объект automatization в JSON-формат, включая его тип, координаты (х, у), ширину, высоту и некие дополнительные атрибуты из process_block.
●Метод process_block. Приватный метод, который создает объект элементаOx, устанавливает его id и class_name, и если есть подключения, добавляет их к этому элементу.
Ввиду того, что для отдельных действий в случае работы автоматизации реализовывалось отдельное представление, то для каждого действия делался отдельный класс для заполнения атрибутов. Пример базового класса для заполнения атрибутов приведен в приложении Ж. Этот код представляет собой модуль Ruby,под названием ScenariOS, в котором определен подмодуль Converter, содержащий класс Base. Класс Base инициализируется с объектом callback. При вызове метода call, он заполняет @result атрибутами из callback.options, преобразуя их значения с помощью метода convert_value. Код класса для заполнения атрибутов использует следующие методы:

●Метод initialize(callback). Инициализирует класс с объектомcallback, который ожидается что будет иметь метод options.
●Метод call. Заполняет result значениями из callback.options.
●Методы bool_values, exceptions, date_values. Возвращают конкретные значения, которые используются для определения как обрабатывать определённые атрибуты при преобразовании.

●Метод convert_value(attribute, value).Преобразует значение в зависимости от его типа. Если атрибут указан в bool_values, его значение преобразуется в строку true или false. Если атрибут перечислен в date_values, преобразуется в объект DateTime. Если значение является массивом, то оно объединяется в строку через запятую.
●Методы fill_options и fill_options_attributes. Эти методы перебирают опции и соответствующие атрибуты, вызывая set_attribute для каждой пары.
●Метод set_attribute(key, value). Устанавливает атрибут для результата, преобразуя значение с помощью convert_value.

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

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

9 Разработка модуля Согласования
9.1 Цели и задачи разработки модуля Согласование

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

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

В рамках работы был разработан и реализован модуль Согласование. Основные значимые классы, реализованные для модуля Согласования приведены в Приложении Е. Рассмотрим назначение и особенности реализованных функций.
Основной код, который реализует настройку маршрута согласования представлен в приложении Е в виде класса настройки маршрута Согласования. Основная задача этого класса – обеспечить работоспособность формы, связанной с процессом создания маршрута (имя класса AcceptanceRouteForm). Рассмотрим особенности кода данного класса. В классе определен конструктор, который инициирует основную форму интерфейса и инициализирует обработчики событий. В классе имеются методы для инициализации специфических функций, таких как перетаскивание элементов в выпадающем списке initSelectWithDrag, инициализация вспомогательных функций initHelpers, обработка различных условий conditionHandler, switchCallbackCondition, обновление ширины выпадающего списка recalcSelectWidth и другие. В определенных функциях используются AJAX-запросы к серверу (на адрес '/settings/acceptance_routes/build_stage') для получения данных и дальнейшего их использования. Методы типа conditionHandler определяют функциональность кнопок назад и добавить, а также функциональность удаления блоков. В целом данная реализация отвечает за логику веб страницы с формой создания маршрута согласования.
Контроллер определения поведения и действий Согласования приведен в приложении Е. Контроллеры в Rails используются для обработки веб-запросов и возвращения веб-ответов.

Рассмотрим основные методы данного контроллера:
●Метод select_route. Получает доступные маршруты для текущего пользователя и рендерит их в модальное окно.
●Метод assign_route. Находит выбранный маршрут и создает процесс с этим маршрутом.
●Методы start_route, restart_route, delete_route запускают, перезапускают и удаляют маршрут, соответственно.
●Методы decision, make_decision рендерят модальное окно для принятия решения и применяют принятое решение к процессу, соответственно.
●Метод widget_status возвращает JSON с информацией о статусе процесса и связанных компонентах.
●Метод history возвращает историю некоего процесса.
●Метод authorize_by_entity используется как предфильтр, который авторизует пользователя и загружает связанные с ним сущности перед обработкой других действий. Методы контроллера используют объекты, такие как Acceptance::Route, Acceptance::Process, Acceptance::ProcessOperations и Acceptance::ProcessHelper, которые являются моделями или сервисами и реализуют бизнес-логику приложения.

Контроллер маршрута согласования представлен в приложении Е. В этом контроллере класс AcceptanceRoutesController отвечает за следующие основные операции:
●i00ndex: список всех маршрутов согласования. Это может быть фильтровано по категории, в противном случае вернутся маршруты без категории.
●show: отображение конкретного маршрута согласования.
●new и create: создание нового маршрута согласования. Категорию и класс можно установить через параметры.
●update: обновление существующего маршрута согласования.
●destroy: удаление маршрута согласования.
●toggle_activity: включение или выключение маршрута согласования.
●build_stage: создание нового этапа согласования для маршрута согласования.
Рассмотрим пример работы модуля Согласования, реализованного на основе вышеописанных классов. Основные рисунки с примером работы разработанного модуля приведены в приложении З. Маршруты согласования создаются в разделе настроек в документах, в подразделе маршруты. Их можно разбить на категории. При создании нового маршрута необходимо указать название указать условия передачи на доработку и повторного запуска согласования документов, это можно сделать автоматизированным. Далее необходимо указать тип задачи которая будет автоматически устанавливаться при создании. Есть возможность установить шаблон для автоматической генерации номера документа в рамках согласования. Далее необходимо устанавливать этапы. Пример работы с модулем Согласование приведен на рисункеЗ.1.

Этапы согласования можно настраивать в любом количестве и указывать необходимую последовательность, также есть возможность настройки параллельного согласования документа. В рамках установки этапа согласования можно назначить конкретного пользователя системы, а также можно выбрать группу сотрудников (отдел) или должность, также есть возможность запустить параллельно согласования у всей группы сотрудников. Например, если в группе «Юристы» три сотрудника и установить, что согласовать должны все пользователи группы, то пока все не согласуют этап не будет изменен на следующий (рисунок З.2).

После создания маршрута, он становится доступен для запуска. Для этого в интерфейсе сгенерированного документа есть кнопка «Назначить маршрут»(рисунок З.3).
Далее необходимо выбрать маршрут из списка доступных и запустить согласование (рисунок З.4). Когда маршрут запущен, начинает отображаться этапность согласования, текущий статус, ответственный. Также,

если вы являетесь ответственным за согласование документа, то отображается две кнопки «Принять» и «Отклонить» (рисунокЗ.5).

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

При наступлении этапа согласования, на котором пользователь является ответственным, ему приходит задача с дедлайном и описанием. Также в задаче вложен документ, который необходимо согласовать. Документ можно открыть и ознакомиться с ним, внести комментарии, изменения, скачать или распечатать, а также перейти к процессу согласования документа из задачи (рисунок З.7).
В любой момент, пользователь, который является заявителем, может посмотреть полностью весь маршрут согласования с основной информацией: текущим этапом согласования, пройденным маршрутом и статусами, а также может перезапустить согласование. Также пользователь может отслеживать историю активности и добавлять других пользователей на ознакомление к документу (рисунокЗ.8).

Таким образом, разработанный модуль обеспечивает функцию, согласно пункту 4.1.1 технического задания: автоматизация согласования различных операций с ответственными лицами.
10 Разработка модуля Проекты
10.1 Цели и задачи разработки модуля Проекты

Цель работы в рамках данной задачи заключается в разработке модуля Проекты, который будет отвечать следующим основным требованиям. Страница Проекты должна содержать список проектов, доступных сотруднику, в виде таблицы.Пользователь должен иметь возможность созданияновых проектов и добавления в них сотрудников. Страница Проекты должна иметь функционал для реализации Agile методологии (Scrum, Kanban), в том числе должны быть реализованы следующие функции:

●Основная страница проекта представляет собой набор таблиц Scrum-спринтов, в которых отражены задачи данного спринта. Задачи без спринтов отображаются в Backlog таблице.
●Имеется возможность создания/добавления задач внутри Scrum-таблиц, перемещения задач между таблицами.
●Внутри проекта можно создавать свои Scrum/Kanban доски для работы с задачами.
●Имеется возможность конфигурации этапов проекта для задач.
●Имеется возможность конфигурации видимости полей задачи этапов для каждой доски.
●Имеется возможность использования диаграммы Ганта.
Часто для достижения целей необходимо решать не одну, а множество задач. Тогда возникает необходимость управления несколькими задачами, анализа ресурсов, аналитики и других методологий для получения конечного результата. Для этого актуальным становится ведение проектов. Проект – это способ группировки задач, объединенных по каким-то общим логическим принципам. Проект предоставляет инструменты разграничения доступа, применяющиеся ко всем задачам проекта, а также инструменты быстрого доступа к задачам проекта, истории работы с проектом, анализу ресурсов и другие инструменты эффективной работы.

Таким образом с целью сделать более эффективным управление задачами и реализацию проектов, в Synergy CRM была поставлена задача разработать модуль Проекты. Для ведения проектов должна быть представлена полноценная и информативная картина о всех задачах проекта.

10.2Разработка и реализация модуля Проекты

В рамках исследования были выделены основные сущности (объекты), взаимодействующие между собой и настраиваемые для пользователей. Эти сущности представляют собой таблицы в БД Postgress:
projects – основная таблица, содержащая списки проектов. Основные атрибуты: имя проекта, дата создания и окончания проекта, кол-во задач и сотрудников, участвующих в проекте, видимость проекта для сотрудников;
project_categories – категории проектов. Например, проекты, связанные с разработкой функциональности для интеграции с Bitrix, можно выделить в отдельную категорию Bitrix projects;
project_stages - этапы задач в проекте. Например, «открыто», «на обсуждении», «в работе»,
«тестирование», «закрыто»;
projects_users – список сотрудников-участников проекта;
project_boards – Agile доски типа Scrum или Kanban. Имеется возможность настроить видимость для всех участников проекта или только для выбранных;
project_board_users – список сотрудников, у кого есть доступ к конкретным agile доскам;
agile_sprints – agile спринты с атрибутами: дата начала и конца спринта, статус (открыт, закрыт, активный).
В задачах соответственно добавлены связи с проектами, agile спринтами и этапами задач в проектах. Схема связей таблиц представлена на рисунке 10.1.

Для таблиц, представленных на рисунке 10.1 в коде разрабатываемого ПО были определены соответственно классы этих сущностей так, как показано в приложении И на рисунке И.1.
Можно выделить следующие основные операции жизненного цикла и управления проектами: создание, завершение и архивация проекта; управление задачами в проекте; настройка этапов проекта; управление agile досками типа Scrum и Kanban; управление спринтами; отображение задач в виде диаграммы Ганта.

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

При нажатии в меню на Проекты пользователю откроется список доступных для него проектов (рисунок И.2). Для создания нового проекта нужно нажать значок «+» и выбрать «Проект». Появится окно для ввода данных. Чтобы не создавать каждый раз однотипный проект с нуля, можно создать шаблон проекта. Для этого в меню надо выбрать «+» -> «Шаблон» и в поле «Шаблон на основе» указать уже созданный проект и сохранить его. Теперь этот шаблон будет всегда под рукой и в следующий раз при создании нового проекта можно воспользоваться им. Программа автоматически перенесет в новый проект все задачи, ответственных сотрудников, а также отсчитает новый дедлайн.

Если проект на данный момент стал не актуален и должен быть отложен, его можно переместить в архив. Для этого необходимо отметить галочкой проект и нажать «В архив» в появившемся меню (рисунок И.3). Для просмотра всех проектов, находящихся в архиве, нужно нажать «Все проекты» и выбрать «Архив» (рисунокИ.4). Для восстановления проекта из архива в меню будет доступно действие «Восстановить».

Завершить проект и отменить проект можно на основной странице проекта в меню настроек. Там же доступны настройки для видимости колонок (рисунокИ.5).

Основной экран проекта представляет собой набор таблицScrum-спринтов, в которых отображены задачи данного спринта. Задачи, которые еще не назначили в спринты, отображаются в Backlogтаблице. В самом верху расположен активный спринт, внизу страницы – Backlog. В шапке каждого спринта отображается его название, даты начала и окончания, количество задач, а также указывается активный спринт (рисунок И.6).

В меню, над всеми спринтам, доступны действия по созданию спринта и задачи, переход на список проектов, доски, группы задач или на диаграмму Ганта. Также доступна фильтрация задач по атрибутам и поиск (рисунок И.7). Такое же основное меню проекта присутствует на всех его страницах. Для удобства и более быстрого распределения задач между спринтами, на основном экране реализован Drag&Drop механизм, позволяющий перемещать задачи между таблицами/спринтами. Кнопка «+ Добавить задачу» под каждым спринтом позволяет добавить существующую задачу в проект и данный спринт, или можно создать новую задачу, которая также будет сразу же добавлена в данный спринт. Редактирование и удаление спринта возможно через иконку «Настройки» (рисунок И.8).

В проекте может быть только один активный спринт. Для этого контроля в модели “AgileSprint” определена валидация (рисунок И.9). Также определены валидации на уникальность имени спринта в проекте и на корректность дат начала и окончания спринта (рисунок И.10).
Задачи могут быть объединены в группы по каким-либо признакам. Например, в группу «Закупка строительных материалов» могут быть объединены такие задачи, как «Закупка шпаклевки», «Закупка цемента», «Закупка клея», «Закупка краски». Страница с группами задач доступна через иконку «Доски» -> «Группы задач» (рисунок И.11). Здесь можно добавлять новые группы, создавать новые задачи и перемещать их между группами.
Создание доски доступно через иконку «Доски» -> «Новая доска». Откроется модальное окно, где нужно заполнить название, тип доски, добавить участников и определить видимость этой доски для всех сотрудников или только для выбранных участников (рисунок И.12). Список всех доступных пользователю досок отображается при клике на иконку «Доски». После создания, а также при клике на существующую доску, открывается страница данной доски, которая представляет собой карточки задач, распределенные по этапам проекта.

На доске типа Kanban будут присутствовать все задачи проекта согласно фильтрам, если они настроены в меню проекта. На доске типа Scrum отображаются задачи только активного спринта (рисунокИ.13).

Этапы для каждого проекта настраиваются индивидуально. По умолчанию всегда создаются два этапа «Открыто» и «Выполнено». Это зарезервированные этапы, которые нельзя изменять и удалять. Новые этапы добавляются между ними. Новые этапы, их порядок и цвет отображения могут быть заданы через основные настройки «Проекты» -> «Этапы» (рисунок И.14)
Каждая доска может быть настроена индивидуально. Через иконку «Настройки» в правом верхнем углу доступна конфигурация видимости этапов на доске, видимости полей в карточках задач. А также возможно редактировать параметры доски и завершать активный спринт (рисунок И.15). Пользователь может создать неограниченное количество досок с разным набором доступных этапов и полей задач, а также доступом для других пользователей.
Графическое представление данных значительно облегчает возможность их восприятия и анализа. Именно с этой целью в модуль была добавлена диаграмма Ганта, с помощью которой возможно выполнить планирование проектов. Диаграммой Ганта называется популярный тип столбчатых диаграмм, использующийся для иллюстрации плана или графика работ по какому-либо проекту путем изображения задач в виде отрезков на временной шкале.

В Synergy CRM в основном меню проекта доступна иконка «Диаграмма Ганта» для перехода на страницу с диаграммой (рисунок И.16). Диаграмма Ганта была реализована на основе библиотеки Highcharts. Highcharts – это библиотека для создания чартов, написанная на JavaScript. Библиотека позволяет легко добавлять интерактивные, анимированные графики на сайт или в веб-приложение. Чарты поддерживают большое количество диаграмм линейных, круговых, колоночных, рассеивающих и многих других типов, включая диаграмму Ганта. В Synergy CRM данная библиотека уже используется для построения графиков в разделе аналитики. Выбор был сделан также с учетом следующих особенностей библиотеки:

●чарты работают на чистом JS и не требуют каких-либо плагинов или Flash;
●вывод чартов довольно прост;
●есть увеличение отдельных областей;
●поддержка скинов /тем оформлений;
●поддержка tooltip с выводом информации;
●в большинстве типов чартов есть поддержка date-time X-оси;
●размер библиотеки ~18кб;
●возможность локализации.

Разработанный код шаблона формирования диаграммы Ганта представлен в приложении И. Это JavaScript код, в котором используется библиотека у Highcharts Gantt для создания диаграммы Ганта. Первоначально происходит инициализация переменных dateFormat, defined и isObject из Highcharts. Затем добавляются data-remote и data-card-modal в разрешенные атрибуты Highcharts.AST. Создается диаграмма Ганта с помощьюHighcharts.ganttChart функции. Устанавливаются языковые настройки lang, в которых определены названия кнопок для загрузки диаграммы в различные форматы и заголовок контекстной кнопки. Значение credits установлено на false, это означает что кредитные заметки Highcharts не будут отображаться на диаграмме. Заголовок диаграммы text установлен пустой. Устанавливаются настройки оси Y, позволяющие использовать HTML в ярлыкахlabels. Устанавливаются настройкиnavigator и scrollbar, которые добавляют возможность прокрутки диаграммы. Устанавливаются настройки выбора диапазона дат rangeSelector. Настраивается доступность для пользователей с ограниченными возможностями через объект accessibility. В series вставляется сериализованные данные для отображения на диаграмме. Объект tooltip определяет, как формируется всплывающая подсказка при наведении на элемент диаграммы. Здесь используется функция-форматер, которая возвращает HTML-строку с подробной информацией о каждой задаче.

Есть строки кода, которые начинаются с '<%= %>'.Это специальный синтаксис, который используется для встраивания Ruby кода в HTML или JavaScript. В этом JavaScript коде, Ruby заменяет`<%= chart_id %>`,
`<%= t('analytic.reports.save_as', kind: 'JPEG') %>`, `<%= t('analytic.reports.save_as', kind: 'PDF') %>`, `<%= t('analytic.reports.save_as', kind: 'PNG') %>`,`<%= t('analytic.reports.save_as', kind: 'SVG') %>`,`<%= t('analytic.reports.print') %>`, `<%= t('analytic.reports.context_button') %>` и `<%= raw Oj.dump(series) %>` на соответствующие значения перед передачей JavaScript клиенту.

В левой части диаграммы располагаются ответственные и список задач под ними. Правую часть окна занимает диаграмма, на которой показана взаимосвязь исполнения задач и временной шкалы. Вверху диаграммы есть возможность масштабирования по периоду времени и установки дат начала и окончания периода вручную. Внизу расположен движок, позволяющий выбрать интересующий период времени более быстро (рисунокИ.17). Предусмотрена возможность выбора спринта, задачи которого должны отобразиться на диаграмме (рисунокИ.18). По умолчанию отображаются все задачи проекта. При наведении на столбик задачи появляется tooltip с информацией о статусе и датах начала и завершения работы над задачей (рисунок И.19). В верхнем правом углу диаграммы предусмотрено меню с выбором формата сохранения диаграммы и возможностью ее распечатать (рисунок И.20).
11 Разработка мобильного приложения под iOS

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

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

Целью данного отчета является представление процесса разработки мобильного приложения для операционной системы iOS, ознакомить с инструментами разработки, подходами, методологиями и этапами тестирования, как оно проводится и какие инструменты используются для этого. Разработанное мобильное приложение позволит пользователям SynergyCRM более удобно и просто управлять своими

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

Архитектурные паттерны и решения, которые необходимо использовать в ходе разработки приложения Synergy CRM для ОС iOS были детально рассмотрены в разделе 1.5. Результаты тестирования выполненной разработки для ОС Android представлено в пунктах 14 и 15 настоящего Отчета.

Ниже рассмотрим результаты выполненной разработки с описанием доступных функциональных возможностей. Все иллюстрации разработанных окон приведены в приложении К.
Экран Авторизации предназначен для запроса у пользователя логина и пароля для доступа к функционалу приложения (рисунок К.1). На выбор пользователю предложено два способа авторизации: первый - по ранее полученному логину и паролю, второй - по Face ID.
Авторизация по Face ID, использующая технологию распознавания лица, имеет следующие преимущества:

●Безопасность: Face ID предоставляет более высокий уровень безопасности по сравнению с другими методами аутентификации, такими как ПИН-коды или отпечатки пальцев. Технология распознавания лица позволяет идентифицировать пользователя по уникальным физическим чертам лица, что делает его сложнее подделать или обойти.
●Удобство использования: Авторизация по Face ID обеспечивает более быстрый и удобный способ доступа к приложению. Для аутентификации пользователя требуется всего лишь лицевое распознавание, что делает процесс более естественным и интуитивным.
●Бесконтактность: Аутентификация по Face ID не требует физического контакта с устройством, так как происходит считывание лица через встроенную камеру.
●Инновационность: Авторизация по Face ID является новейшей и инновационной технологией, что может улучшить восприятие и репутацию приложения как современного и передового.
Таким образом, использование авторизации по Face ID в мобильном приложении CRM позволяет повысить безопасность, удобство использования, гибкость и инновационность приложения, что в итоге положительно сказывается на опыте пользователя и его восприятии приложения.

На экране Авторизации пользователь должен ввести свой логин и пароль (или воспользоваться входом по Face ID) в специальные поля. При нажатии на кнопку «Войти» приложение отправляет запрос на сервер для проверки данных. Сервер проводит проверку логина и пароля и отправляет ответ в форматеJSON.

В случае, если данные были введены неверно, на экране Авторизации появляется сообщение об ошибке. Пользователь должен ввести корректные данные для продолжения работы с приложением. Если данные были введены правильно, пользователь перенаправляется на главный экран приложения.
Контроль и проверка данных на экране Авторизации является очень важным процессом, так как он обеспечивает безопасность и конфиденциальность пользовательских данных. Надежная система авторизации поможет предотвратить возможность несанкционированного доступа к информации, хранящейся в приложении.
Экран реализован в полном объеме в соответствии с ТЗ, весь доступный функционал проверен и работает.
Экран Поиск позволяет пользователям искать определенные объекты из списка всех доступных объектов. Этот экран предоставляет пользователям простой и эффективный способ найти нужный им объект зная только название, экономя их время и усилия (рисунок К.2).
На экране отображается строка поиска, в которую пользователи могут ввести ключевые слова, относящиеся к искомому объекту. Затем приложение отправляет запрос на сервер с поисковым запросом и в случае успешного поиска приложение получает ответ с найденными объектами, отображая только релевантные результаты распределенными по категориям, к которым относятся объекты.

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

Экран Меню. Данное окно вызывается на любом экране при нажатии на иконку меню, расположенную в нижней правой части элемента навигационное меню. Экран Меню является одним из самых важных элементов в приложении (рисунокК.3).

Синхронизация с веб-версией на старте приложения позволяет пользователям иметь доступ к своим настройкам и данным, сохраненным на сервере. Это удобно для тех, кто часто переключается между мобильной и веб-версиями и привык уже к настройкам меню.
Для реализации использован стандартный компонент sheet библиотеки SwiftUIдля отображения навигации и информационного хедера, с информацией об авторизованном пользователе.
Экран Меню является одним из самых важных элементов приложения. Настройка расположения меню, скрытие пунктов и синхронизация с веб-версией – это три ключевые функции, которые помогают сделать экран Меню более удобным и приятным в использовании.
Функционал меню реализован в полном объеме, весь доступный функционал проверен и работает.

Нереализованным остается синхронизация расположения пунктов меню с веб-версией, т.к. количество экранов в данный момент отличается.
Экран Контакты представляет собой раздел, содержащий список контактов или другими словами физических лиц, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунокК.4).
Экран Контакты – это инструмент для управления деловыми контактами. Экран содержит раздел, в котором отображается список всех контактов, созданных в веб-версии приложения или в мобильном приложении. Список организован в алфавитном порядке и может быть отсортирован по различным критериям, таким как имя, компания или дата добавления (рисунок К.5).
Каждый контакт в списке содержит подробные данные об отдельном субъекте, включая его имя, должность, компанию, контактную информацию (например, номер телефона и адрес электронной почты). Кроме того, вы можете просмотреть связанные с контактом объекты, такие как задачи, встречи и сделки (рисунок К.6).

На экране просмотра списка легко добавлять новые контакты, редактировать существующие или удалять контакты, которые больше не актуальны. Вы также можете создавать пользовательские поля для хранения дополнительной информации о контактах, например, об их отрасли или местонахождении.
Экран Уведомления. На этом экране отображаются все уведомления, которые вы получаете из приложения, включая напоминания о встречах и уведомления о просроченных задачах (рисунок К.7). Уведомления кроме экрана, так же дублируются нотификаций в информационной панели вашего телефона. Отслеживая эти уведомления, вы можете быть уверены, что никогда не пропустите важный срок или встречу.
В реализации для получений пушей используется Firebase cloud messaging. При нажатии на нотификацию пользователь может перейти для просмотра объекта, о котором пришла информация. При открытии экрана информация получается с сервера Synergy CRM, о всех уведомлениях, которые произошли за время с последнего запроса.

Экран организован удобным образом: самые последние уведомления отображаются в верхней части. Можно прокрутить список, чтобы просмотреть все уведомления, или применить фильтр уведомлений, чтобы просматривать только определенные типы уведомлений, например, «Вас назначили ответственным» (рисунок К.8).
Одной из самых полезных функций экрана Уведомления является возможность перейти к просмотру объекта, к которому относится уведомление, например, когда вас назначают ответственным по задаче (рисунок К.9).
Экран Уведомления представляет собой важный информационный инструмент, с помощью которого пользователь всегда будет в курсе назначенных встреч и задач, что позволит ему не пропустить важный срок или встречу. Он обеспечивает централизованное хранение всех уведомлений и позволяет настроить параметры в соответствии с вашими потребностями.

Экран Настройки. На этом экране реализовано возможность выбрать часовой пояс для удобного отображения данных, а также сменить тему оформления (рисунок К.10).

Экраны отображения объектов. Экраны являются типовыми, далее представлено краткое описание по каждому экрану.

Все экраны отображения объектов реализованы по одной схеме:
●отправка запроса на сервер v1/тип сущности;
●парсинг ответа;
●сохранение в бд;
●отображение на экране.
Экран Компании представляет собой раздел, содержащий список компаний или другими словами юридических лиц, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунокК.11).
Экран Компании в Synergy CRM является мощным инструментом для управления деловыми отношениями с другими организациями. Этот экран содержит раздел, в котором отображается список всех компаний, созданных вами в веб-версии приложения. Список организован в алфавитном порядке.
Каждая компания в списке содержит подробные данные об организации, включая ее название, отрасль, контактную информацию (например, номер телефона и адрес электронной почты), а также любые примечания или комментарии, которые вы добавили (рисунок К.12). Кроме того, пользователь может просмотреть связанные с компанией объекты, такие как контакты, задачи, встречи и сделки.
Экран Заявки представляет собой раздел, содержащий список заявок, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунокК.13).

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

Экран Сделки содержит список сделок, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок К.14).
Экран Сделки позволяет пользователю просмотреть список всех сделок (рисунок К.15). В случае, если пользователь является управляющим, то он может просматривать все сделки своих подчиненных.
В экране Сделки есть удобный инструмент для управления сделками, позволяющий переключить вид на
«Доску» с разделением сделок по категориям. Для это необходимо выбрать интересующую «Воронку» (рисунок К.16). После открытия сделки можно посмотреть детальную информацию о сделке (рисунок К.17), а также присутствует возможность удобно изменить статус, не переключаясь с доски.
Экран Задачи содержит список задач, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок К.18).
Экран, на котором пользователь может просмотреть список всех своих задач, а также в случае управляющих все задачи своих подчиненных.
Экран Счета содержит список счетов, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок К.19).
Экран Счета позволяет пользователю просмотреть список всех своих счетов, создать счет или отредактировать существующий.
Экран Платежи содержит список платежей, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок К.20).
Экран Платежи содержит функции, связанные с просмотром оплаты, статуса платежа, внесению изменений и использованию других функций, сопутствующих финансовым документам (рисунокК.21).
Экран Продукты содержит список продуктов, созданных в веб-версии Synergy CRM (рисунок К.22), а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях. Доступна возможность редактировать и создавать новые сущности.

Экран Сотрудники содержит список сотрудников, созданных в веб-версии SynergyCRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностей (рисунок К.23). На экране списка есть возможность применить фильтр и посмотреть сотрудников по группам пользователей. Для пользователя с ролью Управляющий имеется возможность настройки прав сотрудника прямо из приложения.

Экран Документы содержит список документов, созданных в веб-версии SynergyCRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунок К.24). С возможностью редактировать и создавать новые сущности. Обеспечивает удобный доступ к существующей документации созданной в веб-версии Synergy CRM. По функционалу схож с экраном Файлы.

Экран Файлы содержит список файлов, созданных в веб-версии Synergy CRM, а также подробные данные о каждой отдельной сущности из данного раздела и связанных с ней сущностях (рисунки К.25 – К.26).

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

Экран Звонки обеспечивает возможность просматривать историю совершенных звонков, информацию, такую как длительность, номера исходящих и входящих, а также прослушать при необходимости запись разговора (рисункиК.27).

Экран Настроек прав. Предоставляет доступ к настройкам различных параметров и уровням доступа. Данный функционал доступен пользователям с ролью «Администратор» (рисунокК.28).
Конфигурация настроек прав запрашивается приложением на старте с сервера, что учесть изменения произошедшие в веб версии, пока приложением не пользовались и обновляет прошлые настройки прав.
Экран Параметры атрибутов позволяет пользователям настраивать атрибуты выбранного объекта. На этом экране отображаются все доступные атрибуты объекта, такие как создатель, ответственный или тип (рисунки К.29 – К.31). Экран Параметры атрибутов предоставляет пользователям возможность изменять атрибуты объекта в соответствии со своими предпочтениями.
По кнопке «Синхронизировать с веб-версией» применяются настройки полей веб-версии Synergy CRM. Также есть функционал скрыть неиспользуемые поля для удобного просмотра. При необходимости можно установить удобный порядок выводимых полей.
Экран Настройки атрибутов расположен на экране просмотра объекта и доступен через меню объекта, во всплывающем диалоговом окне пункт «Настроить поля».
Список содержит все атрибуты, которые относятся к определенному объекту и меняется от его выбора. Все атрибуты соответствуют ответу полученного с сервера, при запросе за получением информации о объекте.

Экран Настройки атрибутов является важной функцией для приложения, которая позволяет пользователям эффективно изменять и настраивать объекты.

Экран Сортировка представляет собой функцию приложения, которая позволяет пользователям сортировать объекты в списке по атрибутам, соответствующим конкретному объекту (рисунок К.32). На этом экране отображаются все доступные варианты сортировки, такие как алфавитный порядок, дата создания или индекс. Экран Сортировка предоставляет пользователям возможность организовать список объектов на основе своих предпочтений, облегчая поиск и доступ к конкретным объектам.

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

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

Экран Активность позволяет пользователям просматривать активность над объектом. Вкладка активности объекта реализована отправкой запросов на сервер, содержащий id объекта, для идентификации и получения результата, отображенного в виде списка (рисунокК.33).
Экран Активность расположен на странице просмотра объекта, через отдельную вкладку и предоставлять четкую и краткую информацию о каждом виде деятельности.
На этом экране отображаются все действия, совершенные над объектом, сгруппированными по дате, такие как обновления, создания, назначения и другие. Экран Активность предоставляет пользователям полную историю жизненного цикла объекта, что облегчает отслеживание изменений и контроль прогресса.
Экран Активность является важной информационной функцией для приложения, позволяющей пользователям с ролью «Управляющий» отслеживать изменения и контролировать «Менеджеров» с течением времени.
Экран Фильтры является важной функцией приложения, которая позволяет пользователям создать, применить или редактировать фильтр. Вкладка фильтры объекта реализована отправкой запросов на сервер, содержащий тип объекта, для идентификации и получения результата, отображенного в виде списка. Экран Фильтры расположен на экране просмотра объектов в верхнем правом углу с соответствующей иконкой(рисунок К.34).

Экран Настройка карточек объекта. Имеется возможность настройки карточек объекта посредством выбора полей, соответствующих данному объекту и отправки запроса на сервер с выбранными полями и получением списка с соответствующими атрибутами.
Кнопка настройки отображаемых атрибутов находится в правом верхнем углу экрана списка объектов с пиктограммой «Шестеренки». По нажатию будет предложен список доступных атрибутов для вывода на карточке объекта. Количество выбранных полей ограниченно 5, при выборе большего количество отобразится предупреждение об ограничении (рисунокК.35 – рисунок К.38).
Экран Создание объекта позволяет пользователю может создать новую сущность путем нажатия на кнопку «Создать». Для каждой сущности доступны для заполнения определенные поля, некоторые из которых могут быть настроены как обязательные в веб-версии SynergyCRM (рисунок К.39).

Список видимых полей может быть настроен пользователем при нажатии на иконку «Троеточие» в верхней правой части экрана и выборе пункта «Видимость полей». В появившемся модальном окне пользователь определяет какие поля должны отображаться в форме создания сущности.

Для создания сущности пользователь заполняет необходимые поля и нажимает на кнопку «Создать», расположенную в нижней части экрана. Если не заполнены обязательные поля, то они подсвечиваются красным цветом и в верхней части экрана появляется уведомление с текстом «Не заполнены обязательные поля».
Кнопка «Создать» является одной из самых важных функций в приложении, позволяющей пользователям создавать новые объекты или записи. Основная задача данного функционала заключается в облегчении и ускорении процесса создания нового объекта.
Кнопка «Создать» легко доступна для пользователя. Она расположена на главной странице приложения, в меню и на панели инструментов при просмотре списка объектов. Кнопка «Создать» имеет различные функции в зависимости от контекста: например, на экране «Контакты», взаимодействие с кнопкой перенаправит пользователя на экран создания «Контакта» (рисунок К.40).

При взаимодействии с кнопкой в навигационной панели, пользователю покажется стандартное диалоговое окно выбора, содержащая список всех объектов доступных для создания.
Для экрана создания объекта «Контакты» предусмотрен сканер визиток. Кнопка сканирования расположена в верхнем правом углу экрана, с пиктограммой «Сканирования». По нажатию открывается камера и при наведении сканер автоматически распознает визитку и предлагает просмотреть скан визитки(рисунок К.41). При необходимости можно сделать новый скан. После подтверждения пользователем результата сканирования, данные автоматически заполнятся в соответствующие поля.

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

Основная функция кнопки «Создать» состоит в открытии формы для создания нового объекта. Эта форма может содержать различные поля для заполнения, такие как название, описание, дата, местоположение и т.д. В зависимости от типа объекта, форма может содержать различные поля и опции, свойственные выбранному объекту. Также при создании объекта реализована проверка обязательных полей для заполнения, в случае если поле не заполнено, то на экране появится аллерт, который подскажет пользователю, какое поле необходимо заполнить.

Кнопка «Создать» имеет определенную функцию, такую как сохранение объекта в базу данных и отправка его на сервер.
В целом, функциональность кнопки «Создать» интуитивно понятна и удобна для пользователя, что позволяет ускорить процесс создания новых объектов и делает использование приложения более эффективным.

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

Экраны Архив и Корзина позволяют пользователям просматривать и восстанавливать ранее удаленные элементы.
Вывод на экран списка объектов реализован с помощью отправки на сервер запроса с применением фильтра, по которому формируется ответ, содержащий только сущности, которые отправлены в Архив (рисунок К.42) или в Корзину (рисунокК.43).
На экранах Архив или Корзина пользователи могут просмотреть список всех удаленных объектов. Они могут выбрать конкретный элемент, чтобы просмотреть его подробную информацию и восстановить его, если это необходимо.
Для удаления или отправки в архив, на экране просмотра объекта реализовано дополнительное меню, с использованием стандартного окна диалога ОС iOS. После выбора действия с объектов, пользователю необходимо подтвердить свое намерение, что благоприятно сказывается на пользовательском опыте и предотвращает случайное действие над объектом.

Экраны Архив и Корзина являются важным компонентами приложения, которые позволяют пользователям управлять своими объектами. Эти экраны являются неотъемлемой частью приложения и обеспечивают удобство и эффективность использования.

Функционал экранов реализован в полном объеме в соответствии с ТЗ, весь доступный функционал проверен и работает.
При разработке атрибуты экранов были представлены как CustomView в соответствии с то й информацией, которую они должны содержать
(рисунок 11.1).
Код, приведенный на рисунке 11.1, содержит код структуры представления на языке Swift для фреймворка SwiftUI. Он использует EnvironmentObject для доступа к общему состоянию приложения (appState) и Data Binding для связывания поля ввода поиска (searchData). Рассмотрим основные элементы, используемые в коде:

●Элемент «@EnvironmentObject var appState: AppStateWrapper». Маркер свойства, позволяющий декодировать и использовать объект shared SwiftUIс состоянием приложения.
●Элемент «@Binding var searchData: String». Маркер свойства, создающий двустороннюю связь с строковым значением, в данном случае используемым для ввода данных в строку поиска.
●Элемент «var body: some View». Обязательное свойство для всех представлений SwiftUI, которое возвращает некоторое представление. В данном случае он создает компоновку с изображением и текстовым полем, расположенными горизонтально рядом друг с другом.
Представление поля поиска сделано с помощью формы, которая включает в себя иконку поиска и текстовое поле. Размер, отступы и цвет изображения задаются вручную. Текстовое поле связано с переменной searchData, которая обновляется при изменении текстового поля. Шрифт, цвет текста поля задаются вручную. Все это обернуто в фоновый прямоугольник с закругленными углами, цвет которого может быть установлен вручную или задан по умолчанию.

Кастомные вью поддерживают взаимодействие с пользователем, в зависимости от типа. Например, для выбора «Ответственного» пользователю предлагается выбрать из списка пользователей. Список пользователь содержит ответ с сервера по запросу v1/users Кастомные вью позволяют применять один стиль ко всем экранам.
Для отрисовки экрана на основе полученной информации от сервера по запросу за объектом, такой как атрибуты составляется набор вью на основе типа поля атрибута.
В результате работы было разработано и реализовано удобное и функциональное приложение, которое позволяет пользователям эффективно управлять своими задачами и проектами, а также быстро получать доступ к необходимой информации и документации. Дополнительный функциональные возможности разработанного приложения для ОС iOS представлены на рисунках К.44 – К.60.

Также приложение может работать в оффлайн режиме, когда нет подключения к сети. Это позволяет пользователям использовать приложение, например, для создания новых задач или вносить новые данные в приложение, даже если не подключиться к интернету.
Таким образом, разработанный модуль обеспечивает функцию, согласно пункту 4.1.1 технического задания: доступ через мобильное приложение; соответствует входным воздействиям в пункте 4.1.3 технического задания в полном объеме, соответствует выходным реакциям в пункте 4.1.4 технического задания в полном объеме.
12 Разработка коробочной версии системы SynergyCRM

Целью разработки серверной коробочной версии Synergy CRM является создание возможности для клиентов и расширение целевого рынка продукта за счет разработки шаблонного алгоритма развертывания продукта на серверах заказчика. Такая технология позволяет развернуть на сервере компании продукт, обеспечив требуемую безопасность и изолированность данных, является отличным решением от изначальной saas модели.

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

Рассмотрим особенности реализованной архитектуры детально.

Для реализации коробочной версии системы Synergy CRM используется пакет Helm Chart. Это пакет, которым управляет Helm, популярным пакетный менеджер для Kubernetes. Helm Chart представляет собой коллекцию файлов, которые определяют необходимую информацию для создания экземпляра Kubernetes приложения. Структура Helm Chart включает в себя следующие файлы:

●файл Chart.yaml: содержит метаинформацию о чарте;
●файлы templates/: в этой папке находятся файлы шаблонов, на основе этих файлов Helm создает Kubernetes манифесты;
●файл values.yaml: содержит значения по умолчанию, которые подставляются в файлы шаблонов во время развертывания чарта; эти значения можно переопределить, передав другие значения при установке чарта.
Чарты Helm предназначены для упаковки и распределения Kubernetes приложений. Они помогают в автоматизации установки и обслуживания приложений в Kubernetes, а также обеспечивают возможность версионирования и обратной совместимости.
На основе данного принятого шаблона был разработан чарт для приложения Synergy CRM, который имеет отдельные директории с описанными выше файлами под каждый ключевой сервис и инфраструктурные модули.

Основные структуры для сервисных чартов, вспомогательных манифестов, манифестов под дополнительные инфраструктурные сервисы (инфраструктурные чарты)представлены в приложении Л.

В качестве примера рассмотрим структуру чарта для микросервиса Synergy CRM «adminka». Данный чарт предназначен для управления базой данных всех аккаунтов через UI. Структура состоит из основного чарта, переменных и нескольких шаблонов«templates». Разберем каждый из них.

Основной чарт Chart.yaml представляет собой файл манифеста для Helm chart. Helm является инструментом для управления пакетами в Kubernetes, а chart в Helm представляет собой набор файлов, описывающих набор связанных ресурсовKubernetes. Разберем детально каждую выполняемую операцию:
●Строка 1, операция «apiVersion: v2». Означает версию API Helm chart. «v2» является текущей версией для Helm 3.
●Строка 2, операция «name: adminka». Указывает имя Helm chart. Это имя используется при установке чарта в Kubernetes с использованием Helm.
●Строки 3 и 4, операции «version: 0.0.1» и «appVersion: 0.0.1» означают версию самого Helm chart и версию приложения, передвигаемого этим chart соответственно. Версии следуют семантике версионирования.
●Строка 5,операция «description:adminka for SynergyCRM». Описание Helm chart. В данном случае указывается, что чарт предназначен для установки и управления компонентом «adminka» системы
«Synergy CRM».
●Строка 6, операция «type: application». Указывает тип Helm chart. В данном случае «application» означает, что данный чарт описывает приложение.
●Строка 7, операция«keywords:». Подраздел указывает на ключевые слова, связанные с Helm chart, отправляемые в виде списка. В данном случае, ключевым словом является слово «adminka».
Совокупно, файл Chart.yaml описывает сущности Kubernetes для установки и управления компонентом
«adminka» системы«Synergy CRM».
Теперь рассмотрим шаблон _helpers-adminka.tpl. Данный код является шаблоном Helm на основе системы шаблонизации Go. Этот шаблон используется для генерации различных частей конфигурации Kubernetes объектов, в частности определения меток labels, имен объектов и конфигураций томов Volumes. В первых двух блоках определяются шаблоны для создания имен для компонентов «Synergy CRM.adminka2. Поскольку имена в Kubernetes ограничены 63 символами (по спецификации DNS), имена ограничиваются до 55 символов для учета дополнительного суффикса «-adminka». В следующих блоках определяются метки labels для компонента «Synergy CRM.adminka». Метки используются в Kubernetes для идентификации и организации объектов. Определяются метки «selectorlabels», которые используются для выборки и идентификации различных групп подов или других объектов в Kubernetes. В последнем блоке определяется шаблон для генерации конфигурации томов для элемента «Synergy CRM.adminka». Тома в Kubernetes используются для предоставления хранилища для подов, функционирующих в Kubernetes. Здесь определяются три тома: один для хранения конфигурации nginx, происходящей из ConfigMap, и два других в качестве пустых директорий. Этот шаблон нужен для параметризации элементов конфигурации Kubernetes в контексте приложения «adminka» системы «Synergy CRM», чтобы облегчить их деплой в различных средах и конфигурациях.

Рассмотрим шаблон adminka-deployment.yaml. Код шаблона приведен в приложении И. Этот код представляет собой файл шаблонаHelm, который используется для создания Deployment объекта (объекта развертывания) в Kubernetes. Deployment используется для определения желаемого состояния для определенного приложения в Kubernetes, автоматически обновляя или создавая Pod'ы и ReplicaSet'ы в соответствии с этим желаемым состоянием. В шаблоне используются следующие сущности:

●Блок metadata содержит метаинформацию о данном Deployment, включая имя и пространство имен, в котором он должен быть развернут, а также метки, используемые для идентификации и организации данного Deployment. Для каждого Pod'абудет включать метки и аннотации.
●Блок spec определяет желаемое состояние для данного Deployment. Это включает в себя следующие подблоки: подблок selectorидентифицирует, какие Pod'ы относятся к этому Deployment; подблок replicas определяет, сколько Pod'ов должно быть запущено опциональный подблок strategy определяет стратегию обновления (такую как «RollingUpdate»). Определяет спецификации каждого Pod'а, включая настройки учетной записи службы, секреты для извлечения образов, селекторы узлов, толерации, аффинности и контекст безопасности.
●Блок template определяет шаблон Pod'a,который будет использоваться при создании новых Pod'ов.
В каждом из определённых Pod'ов будет один или два контейнера, в зависимости от настроек Nginx. Каждый контейнер имеет свой собственный набор настроек, таких как имя, используемый образ, политика извлечения образов, порты, контекст безопасности и команды для запуска. Используются опции по поддержке и контролю здоровья приложения, такие как livenessProbe, readinessProbe, и startupProbe. В блоке lifecycle определена команда, выполняемая после старта контейнера. Блок с инструкциями о томах и монтировании подробно описывает конфигурацию доступа к хранилищу данных и файлов.

Рассмотрим частный сценарий adminka-svc.yaml. Это частный сценарий описывает объект типа Service. Service в Kubernetes представляет собой абстракцию, определяющую бесшовный сетевой доступ до набора работающих подов (экземпляров приложения), работающих на одной и той же задаче. Если значение
«adminka.service.enabled» установлено в true, то этот код создает объект сервиса. Блок metadata определяет информацию о сервисе, включая его имя и пространство имен. В разделеlabels используется шаблонизатор Helm для добавления меток к сервису. В разделе spec указывается тип сервиса, порты для входящих соединений, какой порт должен использовать под для общения с сервисом и имя порта. Блок selector определяет, какие поды станут частью этого сервиса. Сервис перенаправит трафик на поды, которые соответствуют указанным меткам. Рассмотренный код представляет собой конфигурацию для создания сервиса, который маршрутизирует трафик к подам instances приложения «adminka», если
«adminka.service.enabled» установлено в true.
Рассмотрим реализацию манифеста config-adminka-env.yaml. Это манифест Kubernetes для объекта ConfigMap. ConfigMap позволяет хранить конфигурационные данные, которые могут быть использованы другими объектами в Kubernetes. В данной конфигурации используются следующие сущности:
●apiVersion и kind задают тип объекта;
●metadata определяет метаданные, включая имя и пространство имён объекта;
●annotations содержит аннотации для Helm Hook'ов,которые позволяют управлять порядком обновления ресурсов при установке, апгрейде или откате Helm chart'а;
●data содержит фактические конфигурационные данные, которые включают в себя окружение, настройки для Ruby on Rails (например, RAILS_LOG_TO_STDOUT, RAILS_SERVE_STATIC_FILES), настройки для Puma сервера (например, PUMA_SOCK_DIR, WEB_CONCURRENCY), настройки для подключения к базе данных (например, DATABASE_URL, CRM_DATABASE_URL) и другие параметры.

Шаблонизатор Helm используется для создания различных ConfigMaps на основе окружения (например, запись «{{- if eq .Values.environment "dev" }}» создаст ConfigMap с определенными настройками, если текущее окружение установлено как «dev»).
Рассмотрим реализацию конфигурации configmap-static-nginx.yml. Данный код создаёт конфигурации для Kubernetes ConfigMap объекта, используемого для настроек Nginx. Настройки Nginx сохраняются вместе с метаданными и другими настройками в объекте ConfigMap. Основные используемые элементы кода:

●Запись «if and (.Values.adminka.staticNginx.enabled) (not
.Values.adminka.application.initializeCommand)» проверяет настройки, переданные для Helm перед созданием ConfigMap.
●Параметры apiVersion и kind указывают, что это манифест настройки для ConfigMap.
●Блок metadata содержит информацию о ConfigMap, включая имя, пространство имен и метки.

●Блок data содержит конфигурацию nginx, представленную в виде текстового файла.
Конфигурация Nginx включает в себя настройки для производительности (worker_processes, worker_rlimit_nofile, worker_connections), логирования (access_log/error_log), поддержки HTTP gzip сжатия(gzip, gzip_http_version), настройкиHTTP прокси (proxy_http_version, proxy_cache_path), настройки сервера (listen, server_name, client_max_body_size).

Рассмотрим файл конфигурации ingress.yaml. Это файл конфигурации для объявления ресурса Ingress в Kubernetes. Ingress в Kubernetes обеспечивает управление маршрутизацией и доступом к приложениям, работающим внутри кластера Kubernetes, на уровне слоя протокола приложений (HTTP, HTTPS) во время HTTP роутинга. В данном случае в конфигурации Ingressиспользуются следующие сущности:
●metadata.name определяет имя ресурса ingress;
●metadata.namespace определяет пространство имен, в котором будет создан ingress;
●metadata.labels указывает метки, которые будут присвоены ingress'у;
●annotations указывают, что используется классаIngress nginx, то есть показывает, что за маршрутизацию отвечает nginx;
●host в секцииspec.rules определяет хост, для которого будут применяться правила; в данном случае, это domain.ru;
●http.paths.path в секции spec.rules указывает путь, по которому будет доступно приложение;
●http.paths.backend.service.name и http.paths.backend.service.port.number в секции spec.rulesуказывают на сервис и порт в Kubernetes, к которому будет направлен трафик;
●tls используется для созданияHTTPS Route;
●hosts указывает доменные имена, для которых будет применяться TLS;
●secretName указывает на имя секретаKubernetes, который содержит сертификат TLS и ключ.
Рассмотрим еще один пример. В качестве примера рассмотрим структуру чарта для инфраструктурного сервиса SynergyCRM «Elastic», который предназначен для поиска и фильтрации данных в рамках приложения. Структура состоит из основного чарта, переменной и нескольких шаблонов templates. Ниже разберем каждый из них.
Файл Chart1.yaml, описывает информацию о Helm-пакете для Kubernetes.
●Строка 1, операция «apiVersion: v2». Означает версиюAPI Helm (в этом случае2).
●Строка 2, операция «name: elastic». Это имя пакета.
●Строка 3, операция «version: 6.8.20». Версия самогоhelm-пакета.
●Строка 4, операция«appVersion: 6.8.20». Описывает версию приложения, которое развертывается с помощью этого пакета.
●Строка 5, операция «description: Elastic for Synergy CRM». Описание пакета, где указано, что это Elastic для Synergy CRM.
●Строка 6, операция«type: application». Тип пакета.
●Строка 7, операция«keywords:» с секцией в строке «- elastic».Это ключевые слова, связанные с пакетом, которые помогают в поиске пакета.

Чарт описывает, как развернуть определенное приложение или сервис в Kubernetes. В данном случае, это является частью развёртывания Elastic для Synergy CRM.

Рассмотрим фрагмент файла values.yaml, который используется в контексте конфигурации среды Kubernetes. Рассмотрим подробнее каждую строку данного фрагмента.
Строка «environment: "dev" # dev/local» определяет окружение, которое в данном случае является dev. Следует отметить, что данный параметр может быть dev или local.
Строка «domain: "domain.ru"» устанавливает доменное имя для сервисов в рамках Kubernetes кластера.

Строка «namespace: Synergy CRM-dev1» определяет пространство имен Kubernetes, в котором будет работать заданное приложение или группа сервисов. По сути, это логическое отделение кластера Kubernetes.

Строка «serviceAccount: true` и `serviceAccountName: "app-sa"» определяет Service Account,который используется приложениями для взаимодействия с API Kubernetes. Если значение serviceAccount равно true, то будет создан сервисный аккаунт с именем app-sa.

Также рассмотрим фрагмент Kubernetes YAML манифеста под названием ConfigMap.yaml. Это фрагмент манифеста, создающего ConfigMap с именем es-configmap. ConfigMapпредставляет собой объект Kubernetes, который используется для хранения и управления не конфиденциальными данными в форме пар ключ-значение. ConfigMap позволяет отделить конфигурационные аспекты приложения от образа контейнера, чтобы сделать приложение более портативным. В данном файле используются следующие сущности:

●apiVersion: v1 определяет версию Kubernetes API для создания объекта;
●kind: ConfigMap указывает, что это объектConfigMap;
●metadata содержит метаданные объекта;
●name: es-configmap определяет имя этого ConfigMap;
●namespace: {{ .Values.namespace }} содержит пространство имен, куда должен быть помещен ConfigMap. Здесь .Values.namespace является значением переменной Helm, которое будет заменено на соответствующее значение в момент установки Helm chart;
●labels: app: es-configmap определяет метки, которые помогают идентифицировать объект.

В файле есть раздел data, в котором содержится два файла конфигурации в виде строк: elasticsearch.yml и log4j2.properties. Их содержимое затем можно загружать в контейнеры приложений во время их запуска. Значение elasticsearch.yml содержит конфигурацию для Elasticsearch, включая имя кластера, настройки сети, и настройки хранения. Значение log4j2.properties определяет настройки логирования для Elasticsearch, используя log4j2, Java-библиотеку для логирования.

Рассмотрим манифест Kubernetes Service.yaml, который определяет Service (службу) для приложения Elasticsearch. В манифесте используются следующие сущности:
●apiVersion: v1 – версия API Kubernetes, которая используется для создания данного объекта;
●kind: Service – это тип ресурса, который определяется манифестом. В данном случае, создается ресурс типа Service;
●metadata: – это раздел, где указывается информация о метаданных службы Kubernetes;
●namespace: {{ .Values.namespace }} – это пространство имен, в котором будет создана служба;
●.Values.namespace – это переменная Helm chart, которая заменяется на соответствующее значение при установке Helm chart;
●name: elasticsearch – это имя службы;
●annotations – это метаданные, которые могут быть использованы для сохранения произвольных не идентифицирующих данных; в данном случае, они закомментированы;
●labels: app: elasticsearch – это метки, которые используются для идентификации службы;
●spec – это секция, где указываются характеристики службы;
●selector: – это маппинг ключ-значение, который определяет, какие Pods (поды) должна обслуживать служба;
●ports: – это порты, которые слушает служба; в данном случае, служба прослушивает порт 9200 (стандартный порт Elasticsearch для HTTP соединений);
●type: "ClusterIP"` – это тип службы, который определяет, как служба будет доступна. В данном случае, служба доступна только внутри кластера через назначенный ей IP.

Данный код создает службу Kubernetes, которая обеспечивает сетевой доступ к Elasticsearch изнутри кластера Kubernetes.

Последняя рассматриваемая конфигурация представляет собой файл StatefulSet.yaml, который используется для создания StatefulSet, называемого «elasticsearch». StatefulSet представляет собой специальное расширение Kubernetes, которое обеспечивает гарантии по упорядочению и уникальности подов (наименьших развертываемых единиц в Kubernetes). Применение этого кода приведет к созданию одного экземпляра (replicas: 1) Elasticsearch - распределенной системы поиска и анализа данных. В данном случае предусмотрены два init-контейнера. Init-контейнер с именем «init-sysctl» используется для установки специфического значения системного параметра vm.max_map_count через образ
«busybox:1.27.2». Init-контейнер с именем «dir-permissions» меняет права доступа к папке /data, владельцем которой становится пользователь с ID 1000.Основной контейнер «es-client» использует образ elasticsearch и содержит различные переменные окружения для конфигурации Elasticsearch. Контейнер с Elasticsearch ожидает наличия определенных внешних ресурсов, представленных в виде файла elasticsearch.yml, содержащего настройки Elasticsearch, и файла log4j2.properties, содержащего настройки для логгера Java. Оба файла предоставляются через механизм ConfigMap, который позволяет управлять конфигурацией софта без необходимости пересоздания образов. Также предусмотрен Persistent Volume Claim (PVC), который обеспечивает постоянное хранилище для данных Elasticsearch. Данные будут сохраняться даже при перезапуске контейнера подов или узла. Это очень важно для приложений, которые требуют некоторой долговечности или гарантии сохранности данных, к которым относится Elasticsearch. В нашем случае обеспечивается 1 гигабайт хранилища, доступного для чтения и записи.