Как проводятся документы в типовых конфигурациях от 1С

24.07.19

Разработка - Механизмы типовых конфигураций

В свое время, когда только начинал шаги в 1С и изучал, как проводятся документы в конфигурациях на платформе 1С по книге "Разработка управляемого интерфейса" (Хрусталева Е.Ю.), и там были представлены примеры совсем далекие от того, как сейчас проводятся документы в современных конфигурациях от 1С.

В свое время, когда только начинал шаги в 1С и изучал, как проводятся документы в конфигурациях на платформе 1С по книге "Разработка управляемого интерфейса" (Хрусталева Е.Ю.), и там были представлены примеры совсем далекие от того, как сейчас проводятся документы в современных конфигурациях от 1С.

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
...
    // регистр ЗаказыКлиентов Расход
    Движения.ЗаказыКлиентов.Записывать = Истина;
    Для Каждого ТекСтрокаТовары Из Товары Цикл
        Движение = Движения.ЗаказыКлиентов.Добавить();
        Движение.ВидДвижения = ВидДвиженияНакопления.Расход;
        Движение.Период = Дата;
        Движение.ЗаказКлиента = ТекСтрокаТовары.ЗаказКлиента;
        Движение.Номенклатура = ТекСтрокаТовары.Номенклатура;
        Движение.Характеристика = ТекСтрокаТовары.Характеристика;
        Движение.КодСтроки = ТекСтрокаТовары.КодСтроки;
        Движение.Склад = ТекСтрокаТовары.Склад;
        Движение.Серия = ТекСтрокаТовары.Серия;
        Движение.Заказано = ТекСтрокаТовары.Количество;
        Движение.КОформлению = ТекСтрокаТовары.Количество;
        Движение.Сумма = ТекСтрокаТовары.Сумма;
    КонецЦикла;
...
КонецПроцедуры

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

Совсем вкратце он выглядит примерно так:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
...
    Документы.РеализацияТоваровУслуг.ИнициализироватьДанныеДокумента(Ссылка, ДополнительныеСвойства); // тут мы инициализируем таблицы для регистров
...
    ЗаказыСервер.ОтразитьЗаказыКлиентов(ДополнительныеСвойства, Движения, Отказ); // так выполняем запись
...
    ПроведениеСерверУТ.ВыполнитьКонтрольРезультатовПроведения(ЭтотОбъект, Отказ); // тут выполняется контроль
...
КонецПроцедуры

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

Свойства проведения документа.

Во-первых документы должны быть со следующими настройками режима проведения:

Режим проведения обязательно должен быть "Разрешить", а оперативное проведение чаще всего "Запретить". Удаление движения: "Не удалять автоматически" означает, что в "Обработке удаления" документа будут описаны процедуры, в которых явно будет прописано удаление движений при отмене проведения.

Схема проведения в событии "Обработка проведения".

Давайте для примера возьмем документ РегистрацияТранспортныхСредств (В ЕРП И УТ он должен быть). Не будем разбирать на примере документа РеализацияТоваровУслуг или других основных документах, т.к. они достаточно нагружены различными процедурами, которые будут отвлекать от нашей схемы проведения документа.

Сама обработка проведения нашего документа выглядит так:

 

К самой схеме проведения относятся процедуры:

1. ИнициализироватьДополнительныеСвойстваДляПроведения;
2. ИнициализироватьДанныеДокумента;
3. ПодготовитьНаборыЗаписейКРегистрацииДвижений;
4. ЗагрузитьТаблицыДвижений;
5. ЗаписатьНаборыЗаписей;
6. ОчиститьДополнительныеСвойстваДляПроведения;

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

Остальные процедуры:
1. РеестрДокументов.ЗаписатьДанныеДокумента;
2. ДокументыПоОС.ЗаписатьДанныеДокумента;
3. СформироватьЗаписиРегистровЗаданий;
Не относятся к схеме и могут отсутствовать в других документах. К примеру РеестрДокументов.ЗаписатьДанныеДокумента (1) используется для хранения реквизитов документов и быстрого доступа к ним, чтобы не обращаться к реквизитам самого документа (к которому у пользователей, к примеру не может быть доступа по RLS, или если и есть то эти права достаточно "тяжело" отрабатывают для SQL сервера). В результате запрос с использованием этого РС отрабатывает быстрее.

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

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

1.

Эта процедура инициализирует общие структуры, используемые для проведения документа.
Изменяется свойство ДокументОбъекта ДополнительныеСвойства в которое помещаются свойства:

"ТаблицыДляДвижений" - в него будут записываться таблицы, которые будут загружаться в регистр сведений (о чем речь пойдет далее);
"ДляПроведения" - будут содержаться свойства и реквизиты документы, используемые для проведения: "СтрукутраВременныеТаблицы" - записывается МенеджерВременныхТаблиц, записывается "Режим проведения" - режим проведения нашего документа, "МетаданныеДокумента" - метаданные документа и "Ссылка" - ссылка на текущий документ;

Теперь мы инициализировали данные, которые сможем использовать для проведения.

2.

Эта процедура одна из самых основных.

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

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

В конце этой процедуры перебираются все колонки РезультатаЗапроса и устанавливаются параметры в Запрос. Наши будущие таблицы движений, которые будут помещены в свойство "ТаблицыДляДвижений", будут использовать эти параметры.

В Функции ЗначенияПараметровПроцедения устанавливаются параметры в Запрос, которые берутся не из реквизитов

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

По параметрам этих процедур видно, что они одинаковые. И выполняют одинаковую цель - добавляют в тексты запросов для каждого из регистров, по которым будут сформированы движения, которые будут отражены в регистрах.
Названия у них, как правило: "ТекстЗапроса" + "Таблица" + ИмяРегистра, где ИмяРегистра - имя регистра, движения которого будут формироваться этим запросом.

На мой взгляд первые 2 процедуры отступают от общепринятого стандарта формирования таких процедур, и там явно не хватет "ТекстЗапросаТаблица".

Разберем одну из такий процедур (функций):

Вначале проверяется, требуется ли таблица для движений (если в ТекстыЗапроса был ранее добавлен текст по этому регистру, то проверка вернет Ложь - значит не требуется. А далее добавляется текст запроса для текущего регистра в ТекстыЗапроса. В данной процедуре (функции) выбираются параметры, которые мы инициализировали в процедуре ЗаполнитьПараметрыИнициализации. Чаще всего в этих запросах берутся данные из ТЧ из которых формируются движения по номенклатуре, характеристике, количестве и т.д., реже из шапки документов (как в данном случае).

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

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

(Имена псевдонимов в Тексте запроса и Имена Измерений(Ресурсов, Реквизитов) регистров должны совпадать.

(Имена псевдонимов в Тексте запроса и Имена Измерений(Ресурсов, Реквизитов) регистров должны совпадать.

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

 

3.

Данная процедура, как следует из ее описания выполняет 2 основных функции:
1. Очищает наборы записей от старых записей (в настоящее время все менее актуальна, т.к. чаще работают на тонких клиентах, а не на толстых);

2. Взводит флаг записи у регистров, по которым есть ТаблицыДляДвижений с количеством записей более 0. По сути смысл процедуры в строке Объект.Движения[ИмяРегистра].Записывать = Истина.

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

4.

Загружаются Таблицы для движений из свойства "ТаблицыДляДвижений". По сути самая главная строчка - это Движения[ИмяРегистра].Загрузить(Таблица.Значение). Обратите внимание, что разработчики решили повторно взвести флаг Записывать = Истина, хотя его уже установили на 3 этапе схемы проведения. Все таблицы для проведения должны начинаться с слова "Таблица".

В данном случае загружаются таблицы в цикле, хотя могут также встречаться сразу несколько однотипных процедур с именами "Отразить" + ИмяРегистра, где ИмяРегистра - имя регистра, по которому отражаются движения.

5.

В процедуре ЗаписатьНаборыДанных Записываются движения (строка Объект.Движения.Записать()) и копируются параметры для выполнения регистрации движений (к примеру для использования их в контролях, Объект.Движения.ТоварыОрганизаций.ДополнительныеСвойства.Вставить("РассчитыватьИзменения", Истина)).

6.

Завершающая техническая процедура в которой по факту происходит закрытие МенеджераВременныхТаблиц.

Схема проведения в событии "Обработка  удаления проведения".

Схема удаления проведения похожа на обычную схему проведения, только в ней основных процедур не 6 (процедур в обработке проведения "Отразить" + ИмяРегистра (3) может быть несколько), а 4 необходимых только для удаления движений. Тут вызываются процедуры только общего модуля ПроведениеСерверУТ. Если сравнивать с обработкой проведения, то в обработке удаления проведения будут использоваться процедуры 1-3-5-6, ИнициализироватьДанныеДокумента(2) и ОтразитьДвиженияДокумента(4) отсутствуют.

Схема проверки Контролей при проведении документов.

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

Схема контроля при проведении:

1. СформироватьСписокРегистровДляКонтроля;
2. ВыполнитьКонтрольРезультатовПроведения;

1.

В процедуре видно, что если РежимЗаписи документа = Проведение, то добавляется 2 регистра, по которым будет проходить контроль. В Дополнительные свойства "ДляПроведения" вставляется свойство "РегистрыДляПроведения" с массивом регистров для контроля.

2.

Процедура ВыполнитьКонтрольРезультатовПроведения выполняет контроли по различным регистрам конфигурации.

Тут следует обратить внимание на процедуру ЕстьИзмененияВТаблице, в ней определяется по флагу, есть ли изменения в таблице регистра, если есть, то контроль будет выполняться. Есть ли изменения по данному регистру определяется в самом регистре в модуле набора записей в процедурах ПередЗаписью и ПриЗаписи. ПередЗаписью берутся данные, которые были до, а ПриЗаписи как правило через ОБЪЕДЕНИТЬ ВСЕ берется разница движений, и если разница между движениями есть, то взводится флаг ДвижениеСвободныеОстаткиИзменение, который и проверяется.

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

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

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

См. также

СКД Механизмы типовых конфигураций Запросы Программист Платформа 1С v8.3 1С:Зарплата и кадры государственного учреждения 3 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

Работая с типовыми отчетами в конфигурациях «Зарплата и управление персоналом, редакция 3», «Зарплата и кадры государственного учреждения, редакция 3» и подобных, в схемах компоновки данных можно встретить конструкции запросов, которые обращаются к некоторым виртуальным таблицам.

20.08.2024    1802    PROSTO-1C    0    

18

Механизмы типовых конфигураций Программист Платформа 1С v8.3 1С:Комплексная автоматизация 2.х Россия Бесплатно (free)

Эта ошибка была обнаружена мной в типовой конфигурации 1С:Комплексная автоматизация 2 (2.5.16.115), БСП версия 3.1.9.302. Возникает она после того, как вы добавляете в расширение бизнес-процесс или задачу, выполняете обновление идентификаторов метаданных расширений, но ошибка при записи любого элемента справочника "Профили групп доступа" всё равно остаётся.

01.07.2024    1818    Vidz    0    

11

Механизмы типовых конфигураций Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Очень часто в написании кода требуется обращаться к предопределённым значениям. Если идёт обращение к типовым предопределённым значениям, то проблем не возникает.

24.06.2024    1127    olja-ljaaa    0    

3

Механизмы типовых конфигураций Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Проблемы при создании ресурсной спецификации. Связь настроек спецификации и настроек структуры заказа в ЕРП 2.5.

06.05.2024    1232    It-digit    1    

2

Механизмы типовых конфигураций Ценообразование, анализ цен Программист Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 Россия Абонемент ($m)

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

1 стартмани

11.04.2024    1086    tango    5    

3
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. GROOVY 2510 24.07.19 23:58 Сейчас в теме
Там как бы много авторов https://its.1c.ru/db/pubmanagedui
А так выглядят материалы для типографии:
https://drive.google.com/drive/folders/0B2f7eow3JbLZcVhZOWtNN2ZUOHFydjVRM2s5MmxLZ­w?usp=sharing
:)
Liss111; user774630; VooDOOPRo; creatermc; pbabincev; EMelihoff; sm.artem; +7 2 Ответить
5. skv_79 378 25.07.19 09:13 Сейчас в теме
(1) Да, авторов много, но Хрусталева шла первой в моей редацкии, поэтому запомнилось :). Да, согласен, это моя первая статья и наверно она очень далека от типографских стандартов.
2. bulpi 217 25.07.19 08:43 Сейчас в теме
Автор,
англоязычные люди не зря придумали аббревиатуру ИМХО.
конечно намного лучше и правильнее использовать типовой подход "Проведения документов" при выполнении процедуры проведения.

Вот тут вместо "конечно" напрашивается "ИМХО". Я бы плюс поставил, полезная статья. Но безапелляционно утверждать, что этот БРЕД БРЕДЯЦКИЙ (ИМХО, конечно) - это образец для подражания - .... слов нет.
1giga; Serega-artem; IsTiMa; rovenko.n; philya; +5 2 Ответить
6. skv_79 378 25.07.19 09:16 Сейчас в теме
(2) Вся эта статься - ИМХО, мое видение как это работает в типовых.
inspam; Трактор; +2 Ответить
3. DoctorRoza 25.07.19 08:50 Сейчас в теме
Ну такое нужно знать, как Отче Наш.
4. Aftee 25.07.19 09:09 Сейчас в теме
Увидев заголовок статьи, радостно подумал, что наконец-то смогу приблизится к пониманию алгоритмов проведения документов в ЗУП 3.1. Увы... Схема проведения - возможно, но остальное... Либо разбираемый пример в статье слишком простой (как большинство разбираемых примеров, так уж завелось), и в других документах дела обстоят "немного иначе", либо зависит от конфигурации (хотелось бы думать, что второе).
Summer_13; philya; begemot; acanta; +4 Ответить
7. skv_79 378 25.07.19 09:18 Сейчас в теме
(4) С ЗУП дела не имел, поэтому не могу сказать как там проводятся, эта статья для ЕРП и УТ. И для нее взяты самые простые документы в конфигурации, т.к. статья написана для ознакомления (читать начинающего работать с типовыми конфигурациями) со схемой проведения.
24. philya 77 31.07.19 10:11 Сейчас в теме
(7) как-как... ЗУП прекрасна. Глубина стека вызовов уровней в 10-15. Множественные вызовы функций из одной строки, которые просто вызывают следующую функцию. Запросы в 100 килобайт текста. Несколько почти одинаковых запросов по списку сотрудников.

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

Вспоминаем ЗУП 7.7, которая с меньшим числом свистелок, но фантастической скоростью считала ту же самую зарплату и плачем. )
Nik_Name; 2ncom; 1giga; cdrw3; Liss111; Serega-artem; m_aster; zoikins; o.nikolaev; 4erv; AnryMc; Дмитрий74Чел; IsTiMa; pavel_pss; VAAngelov; Power_0N; erplab; DJ_Codebase; WellMaster; Yashazz; rintik; maxopik2; Cерый; vlad3190; akimych; Silenser; +26 Ответить
28. CMK0001 02.08.19 12:53 Сейчас в теме
38. rname 04.04.23 16:07 Сейчас в теме
(24)
Вспоминаем ЗУП 7.7, которая с меньшим числом свистелок, но фантастической скоростью считала ту же самую зарплату

Кхм, ЗиК 7.7 с расчетом в процедуре глобального модуля на 70К строк, с несколькими проходами в цикле по каждому сотруднику???
Я знал организацию, где расчет в ЗиК одного месяца занимал четверть суток на параллельной базе. Потом результат перегоняли в рабочую..
8. PLAstic 296 25.07.19 10:03 Сейчас в теме
(4) Пример вполне классический для УТ11. Поверхностно рассмотрен механизм контролей, в остальном достаточно для понимания.
20. Бубузяка 62 28.07.19 13:21 Сейчас в теме
(4)
либо зависит от конфигурации

В БП несколько по другому, но, в целом, подход такой же. Через МВТ набираются таблицы значений.
9. PLAstic 296 25.07.19 10:05 Сейчас в теме
Я бы рекомендовал:
1) Вернуть шрифт в стандартный для статей. Мне показалось, он мелкий и пришлось увеличивать до 120% масштаб.
2) В картинках убрать чёрный курсив и выделить имена процедур красной рамкой. Очень плохо читается.
3) Загрузить текст в ворд и исправить орфографию и пунктуацию.

В остальном нормальная статья. Добавил себе, буду новичкам скидывать.
WellMaster; AlbinaAAA; Summer_13; Darklight; cleaner_it; +5 Ответить
10. DBOdin_Lab 115 25.07.19 10:07 Сейчас в теме
Знать это все хорошо и правильно.
Но давайте взглянем на эту технику проведения под иным углом.
Мы все хотим быстрого проведения. Самые большие задержки возникают от обращений к базе данных. А теперь давайте посчитаем, сколько запросов к базе данных выполняется в процессе проведения (не считая записи результирующих движений):
1. Чтение реквизитов шапки документов;
2. Чтение табличных частей;
3. Запись временных таблиц (не зря же используется МенеджерВременныхТаблиц);
4. Чтение из временных таблиц;

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

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

А вы что думаете?
Yashazz; philya; +2 1 Ответить
11. dhurricane 25.07.19 10:21 Сейчас в теме
(10)
или почти все
Мне кажется, что как раз из-за того, что очень часто обращения к БД не избежать, получение реквизитов выполняется всегда запросом.

можно избежать просто проверив модифицированность объекта
Продолжите, пожалуйста, свою мысль. Как именно избежать? Что предполагается делать после проверки?
12. DBOdin_Lab 115 25.07.19 11:05 Сейчас в теме
(11)
Продолжите, пожалуйста, свою мысль. Как именно избежать? Что предполагается делать после проверки?


В обработке проведения нужно проверить модифицированность объекта, и если она Истина, то вызвать исключение с описанием ошибки.
Дальше программисту нужно устранить в ПриЗаписи и в подписках изменение объекта.
13. dhurricane 25.07.19 12:03 Сейчас в теме
(12) Думаю, что ситуация, когда объект модифицируется в обработчиках "ПриЗаписи" или "ОбработкаПроведения", является нештатной, и скорее всего это осознанный шаг, на который пошел разработчик. Следовательно и исключение бросать бессмысленно - разработчик его просто "отключит".

Полагаю, тут удобство именно в том, что далеко не все есть в табличных частях и реквизитах, и часто требуется запросом получить дополнительную информацию. Плюс есть возможность используя один и тот же программный интерфейс отразить движения документа без его перезаписи, т.е. без получения объекта, используя одну ссылку.
15. DBOdin_Lab 115 25.07.19 13:10 Сейчас в теме
(13)
Плюс есть возможность используя один и тот же программный интерфейс отразить движения документа без его перезаписи, т.е. без получения объекта, используя одну ссылку.


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

Как бы мне хотелось увидеть когда-нибудь групповое перепроведение без записи!
21. Бубузяка 62 28.07.19 13:27 Сейчас в теме
(15) Если перепроведение подразумевает только "толкание" регистров, то документ записывать не надо. Вызываем в модуле менеджера "ПодготовитьПараметрыПроведения" и получаем набор таблиц необходимых для подготовки вспомогательных данных и формирования движений. Далее вызываем методы модуля менеджера документа или программный интерфейс общих модулей. Таким образом можно "двинуть" только те регистры, что требуются.
o.nikolaev; +1 Ответить
14. baracuda 2 25.07.19 12:46 Сейчас в теме
годно, только много букв. надеюсь осилю этот текст
16. triviumfan 97 25.07.19 20:55 Сейчас в теме
Была похожая тема: https://infostart.ru/public/1026226/
И ещё одна, не могу найти.
17. json 3352 26.07.19 07:59 Сейчас в теме
18. pasha_2001 26.07.19 16:42 Сейчас в теме
Вопрос в тему: В процедурах ТекстОтраженияВРеглУчете() где идет выборка для проводок часто можно видеть в запросе ЗНАЧЕНИЕ(Справочник.Валюты.ПустаяСсылка) КАК ВалютаДт, ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.ПустаяСсылка) КАК СчетДт,
Каким образом и где подбираются корректные значения в данные строки?
19. Rashid80 32 28.07.19 09:51 Сейчас в теме
А потом 1с поменяет эти правила (разумеется в типовых документах она все исправит)... И ваши корректные проведения вдруг окажутся некорректными. Пока это не объявлено как интерфейс или api - это риск.
Периодически натыкаюсь что экспортные процедуры общих модулей поменяли перечень параметров или стали не экспортными
user1436515; LomayaZakat; user1455734; o.nikolaev; 4erv; AnryMc; sevushka; DJ_Codebase; Chai Nic; Summer_13; philya; Darklight; +12 Ответить
25. philya 77 31.07.19 10:15 Сейчас в теме
(19) Еще бывает, что их просто удаляют. Поэтому стараюсь не ленится и вытаскивать код из общих модулей во внешние обработки целиком - потом возвращать работоспособность проще.
user1455734; 4erv; Rashid80; +3 Ответить
29. Summer_13 07.08.19 15:03 Сейчас в теме
22. Бубузяка 62 28.07.19 13:39 Сейчас в теме
Считаю, что это полезная статья.
Она для тех, кто только начинает поддержку и сопровождение типовых конфигураций или решил закончить со свободным творчеством.
1. Если писать в стиле, принятом в типовом решении, тогда ваши последователи легко освоят ваше творчество.
2. У 1С есть ресурсы на исследование и оптимизацию процессов, связанных с изменением данных в транзакции, у меня таких ресурсов нет. Поэтому я следую стандартам разработки и повторяю приемы поставщика.

Про риски. После обновления должно выполняться минимальное тестирование. Хотя бы на открытие форм и проведение документов. Этот процесс снизит риск лишиться работы.
33. Yashazz 4793 25.12.19 17:44 Сейчас в теме
(22) Если писать втрое проще прямо в модуле объекта и прямо нужные движения, то освоят ещё легче. А 1С очередной раз наворотила адскую хрень и когда их собственные спецы окончательно в ней запутаются, очередной раз устроит всем на "радость" полный рефакторинг.

И это автор ещё не касался генерации проводок БУ/НУ в ЕРП и КА, которые вообще вынесены в фоновку и неописуемо "прекрасны" при попытке их менять и отлаживать.
1giga; cdrw3; Serega-artem; user1455734; o.nikolaev; 4erv; nik2500; +7 Ответить
23. Darklight 33 30.07.19 13:44 Сейчас в теме
За статью спасибо. Но, сам механизм, конечной. бредовый. Нет, идея правильная - разделять настройки, требования, сбор данных, действия и контроль на отдельные блоки это здравая идея. Но то, как архитектурно это построено и как реализован - это кошмар. Куча лишнего кода, нерациональное использование памяти, куча циклов, повторяющиеся условия, разбросанные по куче модулей алгоритмы - это бред. И даже унификация это бреда внутри одного документа страдает. И что-то я не увидел секции наложения управляемых блокировок (ну там где остатки не контроллируются постфактум)

На мой взгляд - описание проведения должно быть более декларативным, по чётко-выделенным секциям, желательно в особой текстовой (XML?) схеме, cодержащей:

1. Требования к получению настроек (общих (обычно функциональные опции), организации (учетная политика), документа (внутренние опции и режимы))
2. Требования к получению источников данных (таблицы и поля),и их блокировки
3. Описание алгоритмов преобразования источников в движения (обычно построчные - т.е. принимающие строку к обработке)
4. Требования к источникам данных (дополнительные фильтры, настроенные исходя из текущий настроек п.1)
5. Описание ожидаемых выходных данных - наборов движений
6. Описание схемы обработки данных: ветвления условий (если таковы есть для конкретных данных) и связанные с ними алгоритмы обработки
7. Описание текстов шаблонов возможных ошибок (если общие не годятся)
8. Требования контроля данных
9. Описание алгоритмов постобработки (если требуются)

Так вот, эти секции схемы должны заполняться операциями, зарегистрированными по документу, т.е. документ может совершать целый набор разных операций (как совершенно отличных, зависящих от режима), так и связанных (выполняемых вместе/последовательно).
Каждая операция должна должна иметь своё заполнение каждой вышеназванной секции - повторяющиеся требования - сворачиваются, требования с разными условиями - объединяются (а условия будут наложены уже при обработке), источники данных объединяются (я имею в виду, в первую очередь, объединение полей, но таблицы тоже могут объединяться через "ОБЪЕДЕНИТЬ ВСЕ" при наличии сложных условий "ИЛИ" - это уже задача внутреннего оптимизатора генератора финальной схемы, который, правда, должен операться на возможные хинты, оставленные архитектором схемы)

Ну и в итоге - на основе финальной схемы (кстати, учитывающей и операции и модификации, расположенные в расширениях) должна произойти кодогенерация алгоритма выполнения проведения документа, по заданному шаблону (для разных событий модуля документа - свои блоки кодогенерации, с расстановкой управляемых блокировок).
Правда, финальных схем может быть и несколько - если у документа есть несколько различных режимов поведения или схемы сильно отличаются в зависимости от учетной политики - тогда у документа должна быть небольшая доп секция условий ветвления - для выбора нужной схемы (вернее сгенерированного алгоритма, ей соотествующего) в начале проведения.
Так же, по хорошему, при кодогенерации должны быть получены все значения функциональных опций - должны быть проверены все ветки условий, на них основанные - всё что "ЛОЖЬ" - должно быть выброшено из кодогенерации, и соответственно - выброшено из обработки алгоритмами (например, не используемые поля таблиц). Если знаения опций различны для разных организаций - то генерируются раздельные схемы для каждой организации (ну, либо опция должна иметь пометку проверки только в рантайм).

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

Вот такое моё виденье того, как должно выглядеть современное проведение документов. Основаное на предварительно выполненных этапах:
1. Регистрация операций
2. Декларирование схемы (для каждой операции, и получение финальной схемы)
3. Кодогегенерация алгоритмов проведения (но основе финальной схемы или набора финальных схем)
4. Выполнение оптимизированного алгоритма, с минимальным числом циклов и обращений к базе данных

То есть - что-то типа ещё более продвинутой компоновки данных, но для проведения! Где исхначально есть несколько схем, которые перед кодогенерацией (не только запросов, но и алгоритмов обрабтки) ещё и объединяются в единую схему, с оптимизацией и выкидыванием лишнего.

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

P.P.S.
И само собой, должен быть какой-то автоматизированный мастер-конструктор, позволяющий визуально (хотя поддержка макро-скрипта тоже не помешала бы) настраивать секции схемы для каждой операции (независимо, хотя сама опрация может имеить прописанные зависимости от другой операции, и элементы, наследуемые из неё, при этом может их расширять)
1giga; user1455734; Yashazz; EMelihoff; Chai Nic; philya; +6 Ответить
26. skv_79 378 31.07.19 18:16 Сейчас в теме
(23)Интересная мысль про новую "Схему СКД" для проведения документов. Но вот мне кажется 1С сейчас сконцентрированы на другом: расширения, EDT. Про движения, наверно, вспомнят еще не скоро... Скажем так, сейчас в 1С развиваются те технологии, монетизация который достаточно высока. А обычном программисте, который пишет там свои движения, никто особо и не думает :)
27. Darklight 33 01.08.19 10:30 Сейчас в теме
(26)Не согласен с тем, что компания 1С сейчас не думает о программистах. Как раз со времён выхода 1С: Предприятие 8.3 очень даже думает. Не так много, как хотелось бы (вот, язык - вообще не развивается), но тут во много всё ограничивается консервативным настроем руководства (а может и ведущих архитекторов) компании, на то как должна развиваться платформа, в т.ч. в части конфигурирования, и внешнего вида для пользователей (и тут переход на УФ и управляемое приложение уже был гигантским скачком, надо заметить - что фактически этот скачок пока так и не завершён - и его можно смело считать не особо успешным).

А то, о чём я написал в (23) возможно только во одном из сценариев (или одном, плавно перетекающим в другой):

1. Представление совершенно нового продукта с иной архитектурой - а-ка 1С: Предприятие 9 - крайне маловероятный сценарий на ближайшие десятилетия

2. Создание расширения (плагина) для IDE EDT (хм... кстати, не только для EDT - такой плагин можно было бы создать для многих редакторов, поддерживающих редактирование 1С, например для Visual Studio Code - но в них в таком плагине нет большого смысла, без других плагинов, которые есть в составе EDT) – которое (расширение IDE) могло бы управлять новыми видами элементов проекта - генерируя классические выходные метаданные для загрузки в платформу (и в конфигуратор; без поддержки оных самим конфигуратором) - сценарий интересный, но трудно представить что кто-то за него возьмётся в ближайшие лет десять, по крайней мере, пока EDT не станет популярнее, чем конфигуратор (и не будет ему ни в чём ступать, по крайней мере при разработке управляемых приложений, ну разве что в скорости EDT наверняка всегда будет медленнее, классического конфигуратора)

3. Создание внешнего препроцессора для конфигурации (для классического конфигуратора, или для EDT - это не важно), который на основе, скажем, XML схем будет их объединять, совершать кодогенерацию и встраивать результат в целевую конфигурацию (через загрузку файлов) - этот сценарий проще 2-го, такой препроцессор сделать не очень сложно, но, хорошо бы ещё иметь визуальный редактор для XML схем - в принципе это всё можно налабать на 1С, а для препроцессора хорошо подойдёт OneScript движок). Другое дело, что таким решением пользоваться будет менее удобно (чем встроенным в IDE) - как минимум возникает две конфигурации (хотя можно и одной обойтись - тут много вариантов как это всё организовать), одна из которых будет являться исходником, а вторая - целевой после генерирования – либо рабочей, либо тестовой, либо посредником между ними. Но вряд ли это будет популярное решение из-за его извращённости

4. Ограничится только библиотечным фреймворком внутри конфигурации. Этот вариант сильно урезан по возможностям, в первую очередь по оптимизации, но основные принципы ( по крайней мере для алгоритмов проведения) предложенного мной решения вполне реализуемы просто ручным разнесением алгоритмов по заданным секциям модулей, и соблюдением определённых правил (API) такого фреймворка. Это сценарий, близкий к тому, что сейчас делается в типовых конфигурация 1С, просто подразумевает более продвинутую структуру чётких правил и требований по их соблюдению. И главное - ориентированность на модульность исходных данных и то, что их "фабричное" состояние не является финальным, и конченый потребитель может их расширять и модифицировать в широком диапазоне, не изменяя напрямую код поставщика. Тут очень хорошо подойдёт парадигма аспектно-ориентированного программирования (ну или хотя бы применение стратегии DI - Внедрение зависимостей) - чего так не хватает конфигурациям 1С (ну а если бы стратегию АОО поддерживал язык платформы 1С, как, например, нативно поддерживает язык Eiffel или AspectJ (многие другие языки поддерживают хотя бы DI через библиотеки), было бы вообще очень круто).
Тут так же хорошо бы иметь какой-то визуальный генератор хотя бы начального шаблона - правил - который проще было бы уже потом соблюдать.
Эта стратегия не сложна - и вполне реализуем уже в этом десятилетии

5. Комбинированный вариант 3. и 4. Здесь препроцессор встроен в рантайм. То есть - настройка схемы осуществляется в XML (ну или ином формате, это не важно, в виде макетов), которые сохраняются в конфигурации (алгоритмы так же сохраняются в конфигурации но в общих модулях, в схеме - только ссылки на них), а при проведении документа - схема XML "интерпретируется" на лету так же на лету происходит некоторая кодогенерация (в основном запросов, ну и некоторых коллекций) и через оператор "Выполнить" осуществляется запуск нужных алгоритмов в нужной последовательности в универсальном алгоритме обработки проведения, с применением стратегии DI - Внедрение зависимостей, с помощью которой в алгоритмы передаются некоторые сгенерированные части кода и данных.
Этот вариант очень хорош для тестирования, и несильно требовательного к производительности "продакшена" - а ну а для релизов в рабочие базу - лучше автоматически конвертировать-таки конфигурации, например, через вариант 3.
Это тоже не шибко сложный вариант, но он один из самых ограниченных по возможностям. Его можно сделать где-то за год, а базовые рабочие реализации получить за пару тройку месяцев

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

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


P.S.
Ну а вообще, говоря о сборке документов из операций, я имел в виду не только проведение. Но и формирование печатных форм, авто сборку интерфейсов форм, да и, вообще, сборку всего объекта метаданного (включаемая элементы хранения данных и прав доступа к ним). То есть предложенное мной решение - это прямая дорого к стратегии модульных конфигураций, имеющих принципиальное отличие структуры редактируемой конфигурации от конфигурации ИБ (конфигурация ИБ должна генерироваться путём сборки редактируемой конфигурации из множества отдельных составляющих, с отключением неиспользуемых элементов и блоков кода, и применением автогенерации, как алгоритмов, так и даже элементов метаданных; а в идеале ещё и с выполнением макроскриптов преобразований существующих метаданных и выражений кода и генерации новых по заданным шаблонам, параметрам, значениям функциональных опций, и анализу метаданных конфигурации).
Это всё возможно только в стратегия 1. и 2. (ну в 3. тоже возможно, но эта стратегия всё-таки подразумевает применение более простого препроцессора - так что в ней это всё только с ограничениями - а иначе - лучше переходить к стратегии 2.)

P.P.S.
Но да, это всё слишком круто для нынешнего платформы 1С Предприятие 8 - и компания 1С на это вряд ли решится в ближайшие десятилетия - они и так неплохо зарабатывают. Вот когда они нащупают пути расширения бизнеса - особенно в другие странны, тогда они, возможно, будут разрабатывать новый продукт - а-ля 1С: Предприятие 9, который изначально будут закладывать так, чтобы ему было чем потягаться с западными конкурентами. Вот там, возможно, и развернётся борьба за притязательного клиента, где нужно будет завлекать оригинальными фишками и не пасовать перед фишками, уже доступными в конкурирующих продуктах. Вот тогда, уже может и спадёт пелена консерватизма... Ну это уже не при братьях Нуралиевых случится...
Доживём?
Yashazz; AnryMc; +2 Ответить
35. Yashazz 4793 25.12.19 17:49 Сейчас в теме
(27) Люто плюсую. Плюс стопицот просто.
36. AnryMc 848 11.10.21 16:57 Сейчас в теме
(35)
(27) Люто плюсую.


Не вижу...
37. Yashazz 4793 11.10.21 17:05 Сейчас в теме
(36) чё-то видать глюкануло тогда. Сейчас плюсанул, есть плюс.
34. Yashazz 4793 25.12.19 17:47 Сейчас в теме
(23) Вот да. Мне тоже порой кажется, что некоторые фрагменты, найденные мучительными исканиями в ходе переделок БСП, надо бы методически унифицировать и воткнуть в платформу. В идеале некая 1С 9.0 вообще должна иметь промежуточный "слой" кода и абстракций, идеологически подобный нынешним предопределённым, которые есть как средства платформы, но можно менять. И контроль доступа, включая РЛС, и предполагаемые блокировки и дедлоки хотелось бы мониторить средствами платформы.
30. Summer_13 07.08.19 15:08 Сейчас в теме
Возможно я плохо смотрю,но не могу найти примера именно формирования таблицы движений из какой-то табличной части.Мне вот это более интересно.
31. skv_79 378 07.08.19 15:13 Сейчас в теме
(30) п.2 схемы проведения:
По параметрам этих процедур видно, что они одинаковые. И выполняют одинаковую цель - добавляют в тексты запросов для каждого из регистров, по которым будут сформированы движения, которые будут отражены в регистрах.
Названия у них, как правило: "ТекстЗапроса" + "Таблица" + ИмяРегистра, где ИмяРегистра - имя регистра, движения которого будут формироваться этим запросом.
32. Cyberhawk 135 02.09.19 17:08 Сейчас в теме
В Дополнительные свойства "ДляПроведения" вставляется свойство "РегистрыДляПроведения"
Походу опечатка
Оставьте свое сообщение