Документ на документ. Автоматическое создание связанных документов



Пример решения простой и распространенной задачи — автоматическое создание документа на основании другого документа.

Предисловие

Вы любите свое дело? Я да! Десятки, сотни или может даже тысячи (трудно уже подсчитать) решенных задач. Огромное количество человеко-часов потрачено. С опытом начинаешь использовать некоторые решения в качестве шаблонов, даже если считаешь их костылями. Просто приходится.

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

Именно о таком решении, которое может создавать сомнения в постановке задачи и качестве ее решения, мы сегодня и поговорим. А именно — об автоматическом создании документа на основании другого документа. На практике она не редкость.

Постановка задачи

Решим практическую задачу. Необходимо при проведении документа "Перемещение товаров" для ордерных складов автоматически создавать на основании документ "Расходный ордер на товары". При последующих изменения документа перемещения нужно изменять и расходный ордер. Доработка выполняется на конфигурации "Управление производственным предприятием" редакции 1.3.

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

Это не идеальное решение. Вообще, автоматическое синхронное создание документов на основании документа при проведении / записи / другом событии — это сомнительное решение в любом случае. К этому мы еще вернемся.

Общий принцип

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

На следующем листинге показан пример обработчика изменения связанного документа:

// Источник - объект документа источника, на основании которого
// должны автоматически создаваться другие документы
// СвязанныйДокумент - объект документа, создаваемого автоматически
//
// Перед выполнением дальнейшего алгоритма выполняется поиск связанного
// документа. Если документ не найден, то создается новый
//
Если Источник.Проведен Тогда
// Если источник проведен, то зависимый документ перезаполняется
// на основании источника и проводится
СвязанныйДокумент.ПометкаУдаления = Ложь;
ОбновитьЗависимыйДокумент(СвязанныйДокумент, Источник);
СвязанныйДокумент.Записать(РежимЗаписиДокумента.Проведение);
ИначеЕсли Источник.ПометкаУдаления Тогда
// Если источник помечен на удаление, то связанный документ также
// помечается на удаление. Если он был проведен, то процедура
// "УстановитьПометкуУдаления" инициирует отмену проведения документа
Если НЕ СвязанныйДокумент.ЭтоНовый() Тогда
// Если связанный документ еще не записан в базу, то
// никакие действия не выполняются
СвязанныйДокумент.УстановитьПометкуУдаления(Истина);
КонецЕсли;
Иначе // Выполняется запись документа без проведения или установки
// пометки удаления
Если СвязанныйДокумент.ЭтоНовый() Тогда
// Если связанный документ не записан в базу, то заполняем его и
// выполняем запись документа без проведения
ОбновитьЗависимыйДокумент(СвязанныйДокумент, Источник);
СвязанныйДокумент.Записать(РежимЗаписиДокумента.Запись);
ИначеЕсли СвязанныйДокумент.Проведен Тогда
// Если связанный документ был проведен, то выполняем отмену проведения
СвязанныйДокумент.Записать(РежимЗаписиДокумента.ОтменаПроведения);
Иначе
// В остальных случаях просто записываем зависимый документ
// Если была установлена пометка удаления - снимаем ее
СвязанныйДокумент.ПометкаУдаления = Ложь;
СвязанныйДокумент.Записать(РежимЗаписиДокумента.Запись);
КонецЕсли;
КонецЕсли

Комментарии достаточно подробны. Рассмотрим работу алгоритма на практической задаче, которая была озвучена выше.

Реализация

В типовой конфигурации "Управление производственным предприятием" для автосоздания документа расходного ордера товаров создадим подписку на событие "ПриЗаписиДокументаПеремещения" на событие "ПриЗаписи" со следующим обработчиком:

Процедура ПриЗаписиДокументаПеремещенияПриЗаписи(Источник, Отказ) Экспорт

// Находим подчиненный документ "Расходный ордер на товары"
Запрос = Новый Запрос;
Запрос.Текст =  "ВЫБРАТЬ
| РасходныйОрдерНаТовары.Ссылка
|ИЗ
| Документ.РасходныйОрдерНаТовары КАК РасходныйОрдерНаТовары
|ГДЕ
| РасходныйОрдерНаТовары.ДокументПередачи = &ДокументПередачи
| И РасходныйОрдерНаТовары.ВидОперации =
|  ЗНАЧЕНИЕ(Перечисление.ВидыОперацийРасходныйОрдер.Перемещение)";
Запрос.УстановитьПараметр("ДокументПередачи", Источник.Ссылка);
Выборка = Запрос.Выполнить().Выбрать();

Если Источник.ВидОперации = Перечисления.ВидыОперацийПеремещениеТоваров.ТоварыПродукцияПоОрдерам Тогда
Если Выборка.Следующий() Тогда
СвязанныйДокумент = Выборка.Ссылка.ПолучитьОбъект();
Иначе
СвязанныйДокумент      = Документы.РасходныйОрдерНаТовары.СоздатьДокумент();
СвязанныйДокумент.Дата = Источник.Дата+1;
ОбновитьНумерациюОбъектов(Метаданные.Документы.РасходныйОрдерНаТовары);
СвязанныйДокумент.УстановитьНовыйНомер();
КонецЕсли;

// должны автоматически создаваться другие документы
// СвязанныйДокумент - объект документа, создаваемого автоматически
//
// Перед выполнением дальнейшего алгоритма выполняется поиск связанного
// документа. Если документ не найден, то создается новый
//
Если Источник.Проведен Тогда
// Если источник проведен, то зависимый документ перезаполняется
// на основании источника и проводится
СвязанныйДокумент.ПометкаУдаления = Ложь;
ОбновитьРасходныйОрдер(СвязанныйДокумент, Источник);
СвязанныйДокумент.Записать(РежимЗаписиДокумента.Проведение);
ИначеЕсли Источник.ПометкаУдаления Тогда
// Если источник помечен на удаление, то связанный документ также
// помечается на удаление. Если он был проведен, то процедура
// "УстановитьПометкуУдаления" инициирует отмену проведения документа
Если НЕ СвязанныйДокумент.ЭтоНовый() Тогда
// Если связанный документ еще не записан в базу, то
// никакие действия не выполняются
СвязанныйДокумент.УстановитьПометкуУдаления(Истина);
КонецЕсли;
Иначе // Выполняется запись документа без проведения или установки
// пометки удаления
Если СвязанныйДокумент.ЭтоНовый() Тогда
// Если связанный документ не записан в базу, то заполняем его и
// выполняем запись документа без проведения
ОбновитьРасходныйОрдер(СвязанныйДокумент, Источник);
СвязанныйДокумент.Записать(РежимЗаписиДокумента.Запись);
ИначеЕсли СвязанныйДокумент.Проведен Тогда
// Если связанный документ был проведен, то выполняем отмену проведения
СвязанныйДокумент.Записать(РежимЗаписиДокумента.ОтменаПроведения);
Иначе
// В остальных случаях просто записываем зависимый документ
// Если была установлена пометка удаления - снимаем ее
СвязанныйДокумент.УстановитьПометкуУдаления(Ложь);
КонецЕсли;
КонецЕсли
Иначе
// При смене вида операции "ТоварыПродукцияПоОрдерам" помечаем на удаление
// зависимый документ расходного ордера
Если Выборка.Следующий() Тогда
СвязанныйДокумент = Выборка.Ссылка.ПолучитьОбъект();
СвязанныйДокумент.ПометкаУдаления = Ложь;
СвязанныйДокумент.Записать(РежимЗаписиДокумента.Запись);
КонецЕсли;
КонецЕсли;

КонецПроцедуры

Сама процедура заполнения зависимого расходного ордера очень проста:

Процедура ОбновитьРасходныйОрдер(ДокументРасхода, Источник)

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

КонецПроцедуры

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

На скриншоте выше результат проделанной работы.

В типовых конфигурациях

Подобные решения встречаются не только в доработанных конфигурациях, но и в типовых решения как от фирмы "1С", так и в отраслевых конфигурациях от ее партнеров.

Возьмем самую популярную из них — "Бухгалтерия предприятия 3.0" (КОРП или нет — не важно). Практическим всем знаком документ "Реализация товаров и услуг" и документ на ее основании — "Счет-фактура выданный". Так вот, при проведении реализации товаров происходит актуализация данных в счет-фактуре.

Как это происходит? В обработчике реализации "ОбработкаПроведения" в сааамом конце процедуры есть такая строчка.

УчетНДСПереопределяемый.УстановитьСостояниеСчетаФактуры(ПараметрыДействия, Отказ, НЕ УстановленСтатусДокумента);

Мы не будем рассматривать что, куда и зачем передается, лишь общий принцип. В этой процедуре выполняются общие действия для счет-фактур при проведении или отмене проведения.

// Выполняет общие для всех документов действия связанные с проведением или отменой проведения счета-фактуры.
// При отсутствии явного указания счета-фактуры выполняется её поиск по документу-основанию.
//
// Параметры:
//  ПараметрыДействия - Структура - см. НовыеПараметрыСостоянияСчетаФактуры().
//  ОбновлятьСтатусСчетаФактурыПоДокументу - признак того, что по документу-основанию не установлен статус счета-фактуры,
//                                           следовательно статус счета-фактуры должен установить сам счет-фактура.
//  Отказ        - Булево - в случае ошибки получает значение Истина при выполнении процедуры.
//
Процедура УстановитьСостояниеСчетаФактуры(ПараметрыДействия, Отказ = Ложь, ОбновлятьСтатусСчетаФактурыПоДокументу = Истина) Экспорт
// ...

В зависимости от типа изменения (изменена пометка удаления или флаг "Проведен") алгоритм актуализирует данные документа и записывает ее с соответствующим режимом записи (проведение, запись или отмена проведения).

Конечно, даже по сравнению с примером выше из УПП 1.3, это выглядит не так "страшно" и особо не должно влиять на качество работы информационной системы, но не всегда. Все-таки счет-фактура формирует движения, имеет различную логику при проведении или отмене проведения. Все это может занимать некоторое время, что увеличит длину транзакции основного документа реализации при проведении. Хорошо это или плохо — зависит от конкретной ситуации.

Это норма?

Вообще, с подобными решениями сталкивался довольно часто. Самая простая ситуация — нужно избавить пользователей от ручного ввода зависимых документов (расходных ордеров, счет-фактур, документов поступления или реализации и т.д.). Да, это может ломать логику типовых конфигураций, создавать проблемы производительности и сопровождения. Но все это неважно!

 

 Почему это может привести к проблемам с производительностью и можно ли этого избежать

Почему? Да потому что это приносит почти мгновенный эффект! "Запилил" днем, обновил вечером, а завтра все уже радуются, что у них больше времени на кофе и совещания :).

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

Заключение

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

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

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

А как такие задачи решаете Вы? Есть чем поделиться — добро пожаловать в комментарии!

Другие ссылки

23 Comments

  1. vdscom

    Добрый день.

    я тоже иногда так поступаю. и не считаю это костылем.

    в приведенном вами примере: использование цепочки взаимосвязанных документов лучше и с точки зрения разделения функционала, и с точки зрения дальнейших доработок/обновлений конфигурации, чем дублировать логику подчиненного документа в документе-основании

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

    Reply
  2. laperuz

    Сейчас в УТ 11 такое с онлайн-взаиморасчетами, только хуже. Там не 1 к 1 документы, а много ко многим. Ох и хватанули мы с этим..

    Reply
  3. recon

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

    Из плюсов такого подхода

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

    — Все процедуры контроля при проведении документа — источника отрабатывают и мы не получаем документы созданные по ошибочным документам (в процедуре при записи мы не получим отказ если не удалось провести документ и «уронем» всю транзакцию создания документа)

    — Время транзакции при проведении документа не меняется

    — Нет ошибок «В данной транзакции уже происходили ошибки» в случае ошибки создания документа отражения

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

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

    Из минусов

    — Необходим отчет для мониторинга создания документов отражения. И человек который следит в случае если что то пошло не так.

    — Необходимо в документе менять алгоритмы проверки реквизитов чтобы данных хватило на заполнение документа на основании источника

    Reply
  4. Romarius

    В Обработчике «ПриЗаписи» мы не знаем результат, проведется ли документ. И нагружаем систему созданием документа, а потом удалением. Поэтому правильней делать в обработчике проведения.

    Reply
  5. script

    Я вообще отношу такие задачи к категории «самый крайней случай».

    Потому что документ — это чья-то персональная ответственность. А если ее нет, тогда это не документ, а может быть запись в каком ни-ть регистре сведений. И записать эту запись можно при проведении основного документа, а не документа-основания.

    А если все таки это документ и чья-то ответственность, тогда и задача по вводу этого документа тоже чья-то ответственность. В этом случае создавать нужно задачу для того, кто должен этот документ ввести. А получатель должен эту задачу отработать.

    Все остальное считаю костылями и иногда очень опасными.

    Reply
  6. vdscom

    (5) Потому что документ — это чья-то персональная ответственность.

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

    то есть — применимость этого метода полностью зависит от конкретных условий поставленной задачи

    Reply
  7. script

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

    Reply
  8. vdscom

    (7)

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

    суть такого пакетного создания комплекта документов — реализовать сложный функционал «виртуального» документа путем разложения его в базисе обычных, «атомарных» документов. в данном случае как раз и применима логика примера, описанного автором этой статьи

    Reply
  9. itriot11

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

    На самом деле наша задача качественно транспортировать данные, где не особо важно откуда и куда: База -> База, Документ -> Документ или Документ -> Регистр.

    Reply
  10. HardBall

    А если Попытка…Исключение ???

    Reply
  11. insurgut

    Если речь об обычных формах, то:

    _ПодпискаНаСобытие

    +

    _ОбщийМодульДоработок

    =

    Простое обновление

    Reply
  12. sergey_garin

    Простите, но вот эти картинки на пол-экрана в стиле «модно-стильно-молодежно» немного мешают восприятию содержания. А простыню кода можно убрать подкат 🙂

    Reply
  13. YPermitin

    (12) можно 🙂

    Reply
  14. Denic_01

    в ПриЗаписи что либо делать, особо не имеет смысла т.к. действительно не известен результат проведения, да и создаваемый документ как правило зависит от результата

    Для себя выявил, что само правильно выполнять действия в событии ПослеЗаписи формы, на форме т.к. это в любом случае имеет смысл только при работе пользователя

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

    Reply
  15. GFC

    (14) Тоже считаю это одним из приемлемых вариантов и в плане производительгости, и в плане целостности данных, но есть одно НО… Ведь проведение документа может пользователь сделать и из списка, и групповой ТИПОВОЙ обработкой (при должных правах). А это в свою очередь приводило к тому, что простым смертным приходилось заррещать проведение из форм списка, форм выбора и бог знает еще откуда ))) Сколько задач — столько и оптимальных решений по шкале цена/качество

    Reply
  16. vdscom

    (15) зачем так сложно ? подписка на событие — наше все 🙂

    разумеется, не при обработке события ПослеЗаписи формы…

    Reply
  17. Brawler

    (2) С этого момента бы поподробнее узнать, что там за грабли ибо ERP поджимает новыми релизами и скоро тоже придется включать онлайн взаиморасчеты.

    Reply
  18. Denic_01

    (14)

    в форме списка всё можно отловить также и выполнить

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

    Reply
  19. Denic_01

    (15)

    всё, да не всё — если кто реально заморачивался с этим на практике, тот в курсе, что возникает вагон нюансов с транзакциями и не записанными объектами

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

    Reply
  20. vdscom

    (19) приходилось заморачиваться 🙂

    1. применялась следующая логика: все подчиненные документы имеют статус документа-основания (ПометкаУдаления,Проведен), время подчиненного документа на секунду больше предыдущего

    2. УстановитьСсылкуНового — еще как помогает

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

    Reply
  21. laperuz

    (17)

    Сейчас для онлайн-взаиморасчетов схема такая:

    При проведении любого документа, связанного с взаиморасчетами, сам документ делает движение по регистру Расчеты с клиентами(с поставщиками). В модуле набора записей отписан запрос который вычисляет изменение регистра и по изменению формируются движения по регистру расчеты с клиентами(поставщиками) по срокам. При этом регистратором по второму регистру является не сам документ, а служебный документ «Регистратор расчетов». На версии 11.4.7 было сопоставление 1 регистратор расчетов на 1 ключ аналитики учета по партнерам. Получалось, что при любом проведении документа перезаписывались движения вообще за весь период ведения учета в базе по этому контрагенту. Естественно время проведения только росло. В 11.4.8 переписали, теперь регистратор расчетов создается новый, как только в старом по данному ключу аналитики количество записей в регистре превышает 1000. Стало получше, но все равно — проводим 1 документ, а перезаписывается набор с 1000 записей. Кроме того, внутри процедуры все очень неоптимально, например есть соединение с виртуальными таблицами. В итоге после того, как я переписал запрос, он стал вместо 29 секунд выполняться 0.5:) Ну и еще у нас есть проблемы с РИБ в этой схеме — периодически расходятся регистр, в котором регистратор сам документ и регистр, в котором регистратор служебный документ.

    Reply
  22. Brawler

    (21) Рука лицо…

    По поводу производительности и как оптимизировать можно в 1С писали?

    Reply
  23. elzetto

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

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *