При работе в 1С:Управление торговлей 10.3 часто возникает задача реализации гибкого графика оплат для одного ЗаказПоставщику. Типовой функционал конфигурации не всегда покрывает сложные договорные отношения, где оплата разбита на несколько этапов с разными сроками и суммами. Давайте вместе проанализируем, какие архитектурные подходы существуют для решения этой задачи, оценим их влияние на базу данных и выберем оптимальный вариант.
Самый очевидный и часто используемый способ — расширение структуры метаданных самого документа. Мы можем добавить табличную часть, например, с именем ГрафикПлатежей непосредственно в ЗаказПоставщику.
Преимущества:
ДокументОбъект при программной обработке.Нюансы реализации:
Многие опасаются, что добавление табличной части приведет к «раздуванию» базы данных. Важно понимать, что пустая табличная часть сама по себе не занимает значимого места. Она добавляет новую таблицу в структуре базы данных SQL, которая по умолчанию имеет минимальный объем (занимает одну страницу данных). Рост размера базы будет происходить только пропорционально количеству записей, которые вы будете вносить в эти таблицы в ходе реальной работы. В современных условиях это влияние пренебрежимо мало.
Если вы хотите избежать изменения типовых объектов, чтобы упростить обновление конфигурации в будущем, лучшим решением будет использование РегистрСведений. Создадим непериодический независимый регистр.
Архитектура регистра:
ЗаказПоставщику (тип ДокументСсылка.ЗаказПоставщику).НомерЭтапа (тип Число).ДатаПлатежа (Дата), СуммаПлатежа (Число), ПроцентОплаты (Число).Почему это удобно:
Использование регистра позволяет строить отчеты по планированию денежных средств значительно быстрее. Вам не нужно обращаться к табличным частям документов, которые могут находиться в разных местах конфигурации. Запросы к регистрам в 1С работают очень эффективно и легко индексируются.
Давайте проанализируем, что выбрать в конкретной ситуации. Если вы планируете активно использовать данные о графике в отчетах (например, «Платежный календарь»), РегистрСведений будет архитектурно более правильным решением.
Если же задача стоит в максимально простой реализации для текущего пользователя, чтобы он мог заполнить график прямо в интерфейсе ЗаказПоставщику, смело добавляйте ТабличнуюЧасть. Приведем пример, как можно программно обратиться к такой табличной части:
// Пример перебора этапов в табличной части
Для Каждого СтрокаГрафика Из Объект.ГрафикПлатежей Цикл
Сообщить("Дата: " + СтрокаГрафика.ДатаПлатежа + ", Сумма: " + СтрокаГрафика.СуммаПлатежа);
КонецЦикла;
При внесении изменений в метаданные, будь то добавление табличной части или создание регистра, помните о правилах поддержки конфигурации. При использовании ТабличнойЧасти в типовом документе, при каждом обновлении конфигурации через Конфигуратор (сравнение/объединение), вам потребуется внимательно контролировать состояние документа, чтобы изменения не затерлись типовыми обновлениями от 1С.
Подводя итог, можно сказать, что оба метода имеют право на жизнь. Страхи по поводу роста размера базы данных при добавлении новых объектов — необоснованны для современных серверов. Выбирайте тот путь, который кажется вам более логичным для вашей системы учета: Табличная часть для оперативного управления внутри заказа или Регистр сведений для глубокой аналитики и планирования денежных потоков всей компании.