5.1. Примеры

Кейс 1. Счёт

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

Исходя из требований, минимальный набор приложений для решения задачи может быть таким:

1. Счета;
2. Контрагенты;
3. Назначения платежей;
4. Мои юридические лица.

Из указанных приложений два есть в системе всегда: CRM — Компании, Системные справочники — Мои юридические лица. Для начала можно использовать эти приложения, потому что на них можно ссылаться, не нарушая изоляцию.

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

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

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

• для этого будем использовать метод search();
• метод search() доступен из описания приложения;
• описание мы можем получить одним из двух способов:
  • установив флажок Global и написав конструкцию типа Global.ns._clients.app._companies.search();
  • добавив в контекст страницы/приложения/процесса переменную Компании с типом Приложение и написав конструкцию типа Context.fields._companies.app.search().

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

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

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

Кейс 2. Счета с особенными требованиями

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

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

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

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

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

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

Кейс 3. Большой проект

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

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

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