Корпоративные системы 1С: Эффективные архитектурные решения

Ролевая модель

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

Доступ к данным

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

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

Как результат без этого подхода инцидентов много, а пользы нет.

Использование командами ИР портативный вне зависимости от типа форм

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

Способов применения этого инструмента бессчетное количество:

• Анализ данных и соотнесение их через редактор объекта.
• Консоли кода, запросов, отчетов, компоновки.
• Редакторы констант, объектов данных.
• Массовая обработка объектов
• Поиск дублей
• Просмотр структуры хранения БД
• Анализ ролей, запуск под пользователем без сброса пароля
• Запуск рег. заданий и просмотр их результатов
• отладка запросов и СКД через вызов ирОбщий.От(Запрос)
• и многое другое.

 ВнешниеОбработки.Создать("\\ПутьКПапкеИРПортативный\ирПортативный.epf", Ложь).ирОбщий.От(Запрос)

Вынос вызовов проведения в общий модуль

Часто бывает что необходимо скорректировать движения, например, по управленческому учету (проставить/заменить аналитику) для этого в классическом решении нужно перепроводить документ в закрытом периоде. Период в больших ERP системах никто не откроет, корректировать через КЗР (корректировку записей регистра) не лучшее решение.

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

Создание универсального web-сервиса получения данных из каждой 1С конфигурации

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

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

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

Использовать механизм рассылки отчетов БСП и выгрузки их в сетевые папки

В 1С БСП есть механизм рассылки отчетов. Его следует применять к имеющимся в конфигурации отчетам. Все запросы пользователей по выгрузке данных в Excel следует реализовывать с помощью данного механизма. При этом отчеты размножать не следует нужно расширять универсальные механизмы, такие как универсальный отчет.

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

Вызов универсального отчета БСП с установленными отборами и настройками для просмотра проблемных мест при проведении документа по регистрам

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

Примеры: корректные остатки по позициям документа в регистрах по логике системы, закладываемой аналитиком, должны быть или не < 0 или не > 0. Это можно легко проверять при проведении, что обычно и делается. Пользователю в классическом варианте выдают сообщение о некорректности данных в результате проведения, например недостаточно остатка для проведения по строкам/позициям документа.

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

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

Делаем вызов проверки остатков, обрабатываем, проблемные ссылки заносим в структуру, ее проверяем на заполненность. Если заполнена — формируем универсальный отчет с необходимыми отборами, по необходимым измерениям с нужными срезами: Оборот, Конечный остаток и т.п. за весь период по момент времени документа.

Правило проверки уникальности в периодических регистрах сведений

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

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

Почему это важно именно для периодических регистров сведений?

1. Регистры сведений часто хранят состояние на дату (штатное расписание, назначения, ставки), а не остатки (как регистры накопления).
2. Бизнес-логика уникальности в них чаще привязана к дате, а не к секунде.
3. Регистры накопления (остатки) требуют точной последовательности, а регистры сведений — актуальности на день.

Исключение (когда так делать нельзя)

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

• Не принудительно ставить документу НачалоДня() при импорте.
• Либо использовать другой механизм контроля (уникальность по составу ключа).

Последствия для архитектуры

1. Мы разделяем подходы к проверке: для регистров накопления — точный момент времени, для периодических регистров сведений с датовой уникальностью — проверка по интервалу дня.
2. Это слегка тяжелее для сервера (нужно сканировать интервал, а не точечный срез), но гарантирует целостность данных.
3. При код-ревью обращать внимание на то, какой регистр проверяется и какова бизнес-логика его уникальности.

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

Решение: Для проверки уникальности записей в периодических регистрах сведений (где период — дата) всегда использовать конец дня проверяемой даты, либо явный интервал «МЕЖДУ НачалоДня И КонецДня». Это гарантирует, что проверка увидит все записи, сделанные за текущие сутки, независимо от времени регистратора.

Исключение: Данный подход не применяется для регистров накопления (остатков) и строго хронологических последовательностей, где важен точный порядок документов.