Проектирование новой конфигурации «с нуля» — это сложный процесс, который требует не только знания программного кода, но и понимания архитектурных принципов платформы 1С:Предприятие. Для начинающего разработчика крайне важно выстроить четкую последовательность действий, чтобы избежать переделок в будущем. В рамках данной статьи мы разберем методику декомпозиции задачи, опираясь на практический опыт и стандарты разработки.
Разберем типичную ошибку новичков: попытку сразу создавать регистры и справочники. Прежде чем открывать Конфигуратор, мы должны понять бизнес-процесс. Проанализируем ситуацию: если мы не знаем, как движется товар или как фиксируется оплата, мы не сможем правильно выбрать тип регистра. Поэтому первым шагом всегда является описание бизнес-процессов.
Рассмотрим применение формата User Stories (Пользовательских историй). Попробуем сформулировать требования в виде: «Я, как менеджер по продажам, хочу зарезервировать товар на складе, чтобы его не продал другой сотрудник». Из этой фразы мы сразу видим:
Когда бизнес-требования ясны, перейдем к определению объектов метаданных. Рассмотрим основные вопросы, которые следует задать при проектировании:
1. Что именно мы учитываем?
Выясним, какие ресурсы являются ключевыми: взаиморасчеты, товары, денежные средства. Для этого в 1С чаще всего используются РегистрыНакопления. Если же нам нужно хранить информацию о ценах, курсах валют или состояниях объектов (например, «Статус заявки»), мы выберем РегистрыСведений.
2. Разрезы учета (Измерения vs Ресурсы)
Проанализируем структуру регистров. Посмотрим на правило:
Измерение — это то, «в разрезе чего» мы считаем (Контрагент, Склад, Номенклатура). По измерениям система строит индексы, поэтому их порядок важен для производительности.
Ресурс — это числовой показатель (Количество, Сумма, СуммаНДС).
Реквизит — вспомогательная информация (Комментарий, Содержание), которая не влияет на итоги, но полезна в отчетах по движениям.
3. Справочники и Перечисления
Разберем разницу в их использовании. Если список значений жестко задан разработчиком (например, «Вид операции: Приход/Расход»), используем Перечисления. Если пользователь должен сам добавлять элементы (например, «Список магазинов»), используем Справочники. Не забудем про иерархию и владельцев: например, «Договоры» должны принадлежать конкретному «Контрагенту».
Рассмотрим, как операции будут регистрироваться в базе. Основным инструментом здесь выступают Документы. При проектировании документа важно определить:
Выясним важный технический момент: транзакционная целостность. При написании алгоритма проведения документа (процедура ОбработкаПроведения) проверка остатков должна происходить внутри транзакции. Рассмотрим пример логики:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
// 1. Записываем движения в режиме "не удалять старые"
Движения.ОстаткиТоваров.Записывать = Истина;
Движения.Записать();
// 2. Блокируем данные, чтобы другие пользователи не изменили остатки
Блокировка = Новый БлокировкаДанных;
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ОстаткиТоваров");
// ... настройка параметров блокировки ...
Блокировка.Заблокировать();
// 3. Выполняем запрос к остаткам и проверяем, не ушли ли в минус
// Если остатка недостаточно, устанавливаем Отказ = Истина
КонецПроцедуры
Проанализируем, как пользователи будут получать информацию. Современный стандарт 1С требует использования Системы компоновки данных (СКД). Нам не нужно писать код для формирования таблиц — достаточно спроектировать правильный запрос к виртуальным таблицам регистров (Остатки, Обороты, ОстаткиИОбороты).
Посмотрим на важную деталь: если при создании отчета на СКД вам приходится писать слишком сложные соединения или вложенные запросы, это верный признак того, что структура регистров спроектирована неверно. Хорошая архитектура метаданных делает создание отчетов тривиальной задачей.
Даже если мы создаем небольшую конфигурацию, не стоит изобретать велосипед. Разберем преимущества использования Библиотеки стандартных подсистем (БСП). Рекомендуем внедрять как минимум следующие подсистемы:
Для того чтобы «падаван» научился проектировать самостоятельно, мы рекомендуем следовать методологии «от простого к сложному». Попробуем реализовать три классических кейса оперативного учета:
Рассмотрим финальный совет: всегда соблюдайте стандарты именования. Имена объектов должны быть в единственном числе (Справочник.Номенклатура, а не Справочник.Товары), а программный код должен быть самодокументированным. Это залог того, что через месяц вы сами сможете разобраться в собственном проекте.