Как спроектировать интеграцию кастомных процессов в УНФ 3.0.14.123?

Сейчас описать конкретную архитектуру реализации нельзя: не указано, какой именно бизнес-процесс требуется автоматизировать. В УНФ архитектура будет принципиально разной для производства, сервисных заявок, проката, проектных работ, комиссионной торговли, контроля этапов заказа, маршрутизации документов и т. д.

Для УНФ 3.0.14.123 правильный подход на этапе проектирования будет следующим.

## 1. Базовый принцип архитектуры

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

Приоритет реализации:

1. Типовые справочники, документы и регистры УНФ.
2. Типовые настройки, дополнительные реквизиты и сведения.
3. Типовые бизнес-процессы, статусы, задания и права доступа.
4. Расширение конфигурации.
5. Внешние отчеты и обработки.
6. Подписки на события.
7. Новые документы и регистры в расширении.
8. Изменение основной конфигурации только в крайнем случае.

Для УНФ желательно не изменять типовую конфигурацию напрямую. Основной объем доработок следует проектировать в расширении конфигурации. Это упростит обновление редакции 3.0 и снизит стоимость сопровождения.

## 2. Что нужно определить до проектирования

Необходимо описать не только желаемый результат, но и сам процесс:

### Организационная структура

— Какие подразделения участвуют.
— Какие склады используются.
— Кто принимает решения.
— Кто создает документы.
— Кто проверяет и утверждает документы.
— Кто отвечает за материальные ценности.
— Какие роли пользователей нужны.

### Бизнес-процесс

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

### Объекты учета

— Номенклатура.
— Характеристики.
— Серии.
— Партии.
— Склады и ячейки.
— Контрагенты.
— Договоры.
— Заказы.
— Денежные средства.
— Взаиморасчеты.
— Работы и услуги.
— Сотрудники или исполнители.

### Контроль и отчетность

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

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

## 3. Как разделять типовой функционал и доработки

Архитектурно каждый требуемый объект нужно разделить на три категории.

### Категория 1. Полностью типовой функционал

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

Например:

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

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

### Категория 2. Типовой объект с расширением

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

Примеры:

— дополнительный реквизит у заказа;
— дополнительный реквизит у номенклатуры;
— дополнительный статус;
— дополнительная проверка перед проведением;
— автоматическое заполнение полей;
— дополнительная команда;
— новая печатная форма;
— отчет на основе типовых данных;
— запрет изменения документа после определенного этапа;
— автоматическое создание связанного документа.

Такую часть обычно реализуют через:

— расширение конфигурации;
— дополнительные реквизиты и сведения;
— подписки на события;
— расширение формы;
— дополнительные отчеты и обработки;
— отдельные общие модули расширения.

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

### Категория 3. Отдельный пользовательский функционал

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

Новый документ требуется, когда:

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

Новый справочник требуется, когда:

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

Новый регистр требуется, когда:

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

## 4. Предлагаемая архитектура решения

Для большинства нестандартных процессов в УНФ можно использовать следующую структуру.

### Типовые объекты УНФ

Типовые документы остаются основанием для отражения хозяйственных операций:

— заказ;
— поступление;
— реализация;
— перемещение;
— списание;
— оплата;
— возврат;
— производство или выполнение работ, если это предусмотрено процессом.

Типовые документы отвечают за:

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

### Дополнительные реквизиты

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

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

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

Не следует использовать дополнительные реквизиты для хранения:

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

Для таких случаев нужны табличные части, отдельные документы или регистры.

### Дополнительные сведения

Дополнительные сведения подходят для информации, которая:

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

Например, параметры объекта, технические характеристики, дополнительные контактные данные, признаки интеграции.

### Статусы

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

— новая;
— в работе;
— на проверке;
— согласована;
— выполнена;
— отменена;
— закрыта.

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

### Новый документ регистрации операции

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

Например:

— заявка на выполнение работ;
— регистрация приемки;
— передача в обработку;
— подтверждение этапа;
— контроль качества;
— фиксация отклонения;
— закрытие задания.

Документ может:

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

## 5. Жизненный цикл объекта

До создания объектов нужно описать состояние каждого основного объекта.

Например:

1. Создан.
2. Проверен.
3. Принят в работу.
4. Передан исполнителю.
5. Выполняется.
6. Ожидает проверки.
7. Требует корректировки.
8. Завершен.
9. Закрыт.
10. Отменен.

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

— кто может перевести объект в это состояние;
— какие поля обязательны;
— какие документы можно создавать;
— разрешено ли редактирование;
— можно ли вернуть объект на предыдущий этап;
— требуется ли согласование;
— нужно ли фиксировать дату и пользователя;
— какие уведомления или задания создаются.

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

## 6. Где использовать подписки на события

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

Подписками можно реализовать:

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

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

Особенно осторожно следует изменять проведение, потому что от него зависят:

— остатки;
— себестоимость;
— взаиморасчеты;
— отчеты;
— резервы;
— закрытие периода.

## 7. Где использовать отдельный регистр сведений

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

Примеры:

— история статусов;
— история назначения ответственных;
— плановые даты этапов;
— соответствия внешних идентификаторов;
— параметры интеграции;
— настройки маршрута;
— лимиты;
— результаты проверок;
— связь объекта с несколькими исполнителями;
— история причин отклонения.

Регистр сведений должен иметь понятную структуру измерений и ресурсов. Не следует создавать один универсальный регистр с полями «Тип значения», «Имя свойства» и «Значение», если по этим данным потребуется регулярная отчетность. Такая модель гибкая, но значительно усложняет контроль типов, запросы и сопровождение.

## 8. Где использовать регистр накопления

Регистр накопления необходим, если требуется учитывать:

— остатки;
— резервы;
— доступное количество;
— лимиты;
— задолженность по пользовательской операции;
— количество на этапах;
— незавершенное выполнение;
— распределение ресурсов.

Например, если нужно видеть, сколько товаров находится:

— в ожидании приемки;
— на проверке;
— у исполнителя;
— на доработке;
— готово к передаче,

то простого статуса будет недостаточно. Понадобится регистр накопления либо отдельная модель учета по этапам.

## 9. Архитектура интерфейса

Для пользователей желательно проектировать не доступ ко всем объектам УНФ, а рабочие места по ролям.

Например:

### Менеджер

— создание заказа;
— контроль статуса;
— работа с клиентом;
— печать документов;
— просмотр задолженности;
— запуск согласования.

### Кладовщик

— приемка;
— отбор;
— перемещение;
— контроль остатков;
— печать складских документов;
— подтверждение фактического количества.

### Исполнитель

— список назначенных заданий;
— изменение статуса;
— ввод результата;
— указание фактических трудозатрат;
— фиксация отклонений.

### Руководитель

— контроль просроченных операций;
— показатели по этапам;
— отклонения от плана;
— отчеты по сотрудникам;
— согласование.

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

## 10. Отчеты

Отчеты нужно проектировать от управленческих вопросов, а не от таблиц базы.

Для каждого отчета определить:

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

Типовые отчеты следует использовать для:

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

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

## 11. Права доступа

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

Нужно определить:

— кто видит объект;
— кто создает;
— кто изменяет;
— кто проводит;
— кто отменяет проведение;
— кто переводит статус;
— кто видит суммы;
— кто видит себестоимость;
— кто может изменять данные задним числом;
— кто имеет доступ к пользовательским отчетам.

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

При необходимости вводятся ограничения доступа:

— по организации;
— по складу;
— по подразделению;
— по ответственному;
— по группе пользователей;
— по проекту;
— по статусу документа.

## 12. Интеграции

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

Для каждой интеграции определить:

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

В расширении следует предусмотреть отдельные регистры для внешних идентификаторов и состояния обмена. Не стоит хранить эти данные только в комментариях или произвольных дополнительных реквизитах.

## 13. Что должно быть результатом проектирования

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

1. Описание бизнес-процесса.
2. Схему этапов и переходов.
3. Матрицу «типовой функционал / доработка».
4. Перечень пользователей и ролей.
5. Перечень объектов метаданных.
6. Таблицу реквизитов и источников заполнения.
7. Описание движений и регистров.
8. Перечень отчетов.
9. Перечень печатных форм.
10. Описание прав доступа.
11. Описание интеграций.
12. План тестирования.
13. План обновления типовой конфигурации.
14. План переноса начальных данных.

Практическая таблица для проектирования может иметь такой вид:

| Требование | Типовой объект | Решение | Способ реализации |
|—|—|—|—|
| Хранить дополнительный признак | Типовой документ | Использовать типовой документ | Дополнительный реквизит |
| Контролировать этапы | Заказ | Расширить типовой объект | Статусы, проверки, история |
| Хранить несколько исполнителей | Заказ | Недостаточно реквизита | Табличная часть или отдельный регистр |
| Учитывать количество на этапах | Товар или заказ | Нужен количественный учет | Регистр накопления |
| Формировать нестандартный документ | Типового объекта нет | Создать новый объект | Документ расширения |
| Получать управленческий показатель | Несколько объектов | Нужен отдельный отчет | Дополнительный отчет |
| Автоматически создавать запись | Изменение документа | Использовать событие | Подписка на событие |
| Обмениваться с внешней системой | Документ или справочник | Нужен контроль обмена | Регистр идентификаторов и журнал обмена |

## 14. Какие данные необходимы для конкретного архитектурного решения

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

1. Чем занимается компания.
2. Какой процесс требуется автоматизировать.
3. С какого события начинается процесс.
4. Какие этапы он проходит.
5. Какие типовые документы УНФ уже используются.
6. Что именно отсутствует в типовом функционале.
7. Какие данные нужно хранить дополнительно.
8. Какие отчеты и печатные формы нужны.
9. Какие пользователи будут работать в системе.
10. Какие ограничения по правам требуются.
11. Нужен ли обмен с другими системами.
12. Есть ли уже работающая база и данные, которые нельзя потерять.

После этого архитектуру можно описать уже предметно: какие объекты УНФ оставить типовыми, какие расширить, какие добавить в расширение, какие регистры использовать, как устроить статусы, права, документы, отчеты и обмен.