В свое время, когда только начинал шаги в 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.
Процедура ВыполнитьКонтрольРезультатовПроведения выполняет контроли по различным регистрам конфигурации.
Тут следует обратить внимание на процедуру ЕстьИзмененияВТаблице, в ней определяется по флагу, есть ли изменения в таблице регистра, если есть, то контроль будет выполняться. Есть ли изменения по данному регистру определяется в самом регистре в модуле набора записей в процедурах ПередЗаписью и ПриЗаписи. ПередЗаписью берутся данные, которые были до, а ПриЗаписи как правило через ОБЪЕДЕНИТЬ ВСЕ берется разница движений, и если разница между движениями есть, то взводится флаг ДвижениеСвободныеОстаткиИзменение, который и проверяется.
Далее добавляются запросы контроллей в один большой пакет запросов, а также в МассивКонтролей добавляются контроли, по которым будут проводится контроли.
В конце процедуры выполняется ПакетЗапросов, и если в есть не пустые результаты запроса из массива результатов, то из МассивКонтролей берется ИмяКонтроля и далее в много условном операторе Если ИначеЕсли … КонецЕсли для каждого контроля выполняется своя процедура отработки сообщений об ошибках.
Надеюсь в этой статье мне удалось немного упростить ознакомление с типовой схемой проведения для тех, кто только встретился с этим механизмом.
Там как бы много авторовhttps://its.1c.ru/db/pubmanagedui
https://drive.google.com/drive/folders/0B2f7eow3JbLZcVhZOWtNN2ZUOHFydjVRM2s5MmxLZ w?usp=sharing
А так выглядят материалы для типографии:
🙂
Автор,
англоязычные люди не зря придумали аббревиатуру ИМХО.
Вот тут вместо «конечно» напрашивается «ИМХО». Я бы плюс поставил, полезная статья. Но безапелляционно утверждать, что этот БРЕД БРЕДЯЦКИЙ (ИМХО, конечно) — это образец для подражания — …. слов нет.
Ну такое нужно знать, как Отче Наш.
Увидев заголовок статьи, радостно подумал, что наконец-то смогу приблизится к пониманию алгоритмов проведения документов в ЗУП 3.1. Увы… Схема проведения — возможно, но остальное… Либо разбираемый пример в статье слишком простой (как большинство разбираемых примеров, так уж завелось), и в других документах дела обстоят «немного иначе», либо зависит от конфигурации (хотелось бы думать, что второе).
(1) Да, авторов много, но Хрусталева шла первой в моей редацкии, поэтому запомнилось :). Да, согласен, это моя первая статья и наверно она очень далека от типографских стандартов.
(2) Вся эта статься — ИМХО, мое видение как это работает в типовых.
(4) С ЗУП дела не имел, поэтому не могу сказать как там проводятся, эта статья для ЕРП и УТ. И для нее взяты самые простые документы в конфигурации, т.к. статья написана для ознакомления (читать начинающего работать с типовыми конфигурациями) со схемой проведения.
(4) Пример вполне классический для УТ11. Поверхностно рассмотрен механизм контролей, в остальном достаточно для понимания.
Я бы рекомендовал:
1) Вернуть шрифт в стандартный для статей. Мне показалось, он мелкий и пришлось увеличивать до 120% масштаб.
2) В картинках убрать чёрный курсив и выделить имена процедур красной рамкой. Очень плохо читается.
3) Загрузить текст в ворд и исправить орфографию и пунктуацию.
В остальном нормальная статья. Добавил себе, буду новичкам скидывать.
Знать это все хорошо и правильно.
Но давайте взглянем на эту технику проведения под иным углом.
Мы все хотим быстрого проведения. Самые большие задержки возникают от обращений к базе данных. А теперь давайте посчитаем, сколько запросов к базе данных выполняется в процессе проведения (не считая записи результирующих движений):
1. Чтение реквизитов шапки документов;
2. Чтение табличных частей;
3. Запись временных таблиц (не зря же используется МенеджерВременныхТаблиц);
4. Чтение из временных таблиц;
Но если подумать, то все (или почти все) нужные нам данные уже есть в объекте. Можно заполнить движения без дополнительных обращений к базе.
1С, как я думаю, хочет обезопасить проведение от данных, измененных по сравнению с записанными в базу. Но этого можно избежать просто проверив модифицированность объекта в обработке проведения.
А вы что думаете?
(10)
Мне кажется, что как раз из-за того, что очень часто обращения к БД не избежать, получение реквизитов выполняется всегда запросом.
Продолжите, пожалуйста, свою мысль. Как именно избежать? Что предполагается делать после проверки?
(11)
В обработке проведения нужно проверить модифицированность объекта, и если она Истина, то вызвать исключение с описанием ошибки.
Дальше программисту нужно устранить в ПриЗаписи и в подписках изменение объекта.
(12) Думаю, что ситуация, когда объект модифицируется в обработчиках «ПриЗаписи» или «ОбработкаПроведения», является нештатной, и скорее всего это осознанный шаг, на который пошел разработчик. Следовательно и исключение бросать бессмысленно — разработчик его просто «отключит».
Полагаю, тут удобство именно в том, что далеко не все есть в табличных частях и реквизитах, и часто требуется запросом получить дополнительную информацию. Плюс есть возможность используя один и тот же программный интерфейс отразить движения документа без его перезаписи, т.е. без получения объекта, используя одну ссылку.
годно, только много букв. надеюсь осилю этот текст
(13)
Соглашусь, что это может быть востребовано в групповом перепроведении документов.
Но к сожалению, в типовой Бухгалтерии такого решения нет, там всегда выполняется запись документа.
А запись документа — это самый тяжелый запрос к базе.
Как бы мне хотелось увидеть когда-нибудь групповое перепроведение без записи!
Была похожая тема:https://infostart.ru/public/1026226/
И ещё одна, не могу найти.
(16) может этаhttps://infostart.ru/public/552536/ ?
Вопрос в тему: В процедурах ТекстОтраженияВРеглУчете() где идет выборка для проводок часто можно видеть в запросе ЗНАЧЕНИЕ(Справочник.Валюты.ПустаяСсылка) КАК ВалютаДт, ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.ПустаяСсылка) КАК СчетДт,
Каким образом и где подбираются корректные значения в данные строки?
А потом 1с поменяет эти правила (разумеется в типовых документах она все исправит)… И ваши корректные проведения вдруг окажутся некорректными. Пока это не объявлено как интерфейс или api — это риск.
Периодически натыкаюсь что экспортные процедуры общих модулей поменяли перечень параметров или стали не экспортными
(4)
В БП несколько по другому, но, в целом, подход такой же. Через МВТ набираются таблицы значений.
(15) Если перепроведение подразумевает только «толкание» регистров, то документ записывать не надо. Вызываем в модуле менеджера «ПодготовитьПараметрыПроведения» и получаем набор таблиц необходимых для подготовки вспомогательных данных и формирования движений. Далее вызываем методы модуля менеджера документа или программный интерфейс общих модулей. Таким образом можно «двинуть» только те регистры, что требуются.
Считаю, что это полезная статья.
Она для тех, кто только начинает поддержку и сопровождение типовых конфигураций или решил закончить со свободным творчеством.
1. Если писать в стиле, принятом в типовом решении, тогда ваши последователи легко освоят ваше творчество.
2. У 1С есть ресурсы на исследование и оптимизацию процессов, связанных с изменением данных в транзакции, у меня таких ресурсов нет. Поэтому я следую стандартам разработки и повторяю приемы поставщика.
Про риски. После обновления должно выполняться минимальное тестирование. Хотя бы на открытие форм и проведение документов. Этот процесс снизит риск лишиться работы.
(7) как-как… ЗУП прекрасна. Глубина стека вызовов уровней в 10-15. Множественные вызовы функций из одной строки, которые просто вызывают следующую функцию. Запросы в 100 килобайт текста. Несколько почти одинаковых запросов по списку сотрудников.
И вишенкой на торте где-то в конце списка настроек галочка «оптимизированный расчет зарплаты» с комментарием «выключите, если зарплата считается неправильно», которая после обновления оказывается установленной.
Вспоминаем ЗУП 7.7, которая с меньшим числом свистелок, но фантастической скоростью считала ту же самую зарплату и плачем. )
(19) Еще бывает, что их просто удаляют. Поэтому стараюсь не ленится и вытаскивать код из общих модулей во внешние обработки целиком — потом возвращать работоспособность проще.
(23)Интересная мысль про новую «Схему СКД» для проведения документов. Но вот мне кажется 1С сейчас сконцентрированы на другом: расширения, EDT. Про движения, наверно, вспомнят еще не скоро… Скажем так, сейчас в 1С развиваются те технологии, монетизация который достаточно высока. А обычном программисте, который пишет там свои движения, никто особо и не думает 🙂
(24) Как с языка снял )
(19)+++
Возможно я плохо смотрю,но не могу найти примера именно формирования таблицы движений из какой-то табличной части.Мне вот это более интересно.
(30) п.2 схемы проведения:
Названия у них, как правило: «ТекстЗапроса» + «Таблица» + ИмяРегистра, где ИмяРегистра — имя регистра, движения которого будут формироваться этим запросом.
Походу опечатка