Нужно создать документ на основании, при изменении реквизита документа основания. Какую процедуру задействовать?
---
Не очень понял, в чём проблема?
У вас подписка на событие "обработкаПроведения" для документа Заказ, где вы должны создать новый документ "Реализация" при определенных условиях. Я правильно понял?

На всякий случай, если у Вас совсем нет опыта:
1) Для вызова процедуры или функции из другого модуля она должна быть объявлена как экспортная.
т.е. в конце объявления процедуры/функции должно быть написано зарезервированное слово "Экспорт".
Для функции:

```1c
    Функция ЗаполнитьДокументНаОснованииЗаказаКлиента(Источник) Экспорт
    ...
    Возврат Результат;
    КонецФункции
```

Аналогично и для процедуры (в отличии от функции, процедура ничего не возвращает):

```1c
    Процедура ЗаполнитьДокументНаОснованииЗаказаКлиента(Источник) Экспорт
    ...
    КонецПроцедуры
```

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

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

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

Как правило, один модуль на какое-либо событие (ОбработкаПроведения, ПередЗаписью и т.д.) используется для множества объектов одного типа, поэтому я и добавил проверку на тип ...Если ТипЗначенияИсточника = Тип("ДокументОбъект.Заказ")... Если в дальнейшем в эту подписку подключат ещё какой-то документ, то у Вас не будет генерироваться ошибка.

Если же ЗаполнитьДокументНаОснованииЗаказаКлиента НЕ в модуле объекта документа "Реализация", а в модуле менеджера, то вызов будет происходить немного по другому, что-то типа:

```1c
    НоваяРеализация = Документы.Реализация.ЗаполнитьДокументНаОснованииЗаказаКлиента(Источник);
    НоваяРеализация.Записать();
```

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

```1c
    Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)

    Если ЭтотОбъект.ТвойРекизит <> Ссылка.ТвойРекизит
    // Какой-то код
    КонецЕсли;
    КонецПроцедуры
```
---
Сообщение было скрыто модератором.
---
Вопрос был "Как?" про первый документ. Вопрос "Зачем?" подразумевает серьёзную проработку кейса целиком и сам процесс кодинга тут займет процентов 10-15 от всей работы.
---
Первичный документ это заказ, документ, созданный на основании реализация.
---
Сообщение было скрыто модератором.
---
Документ записывается в транзакции так что все откатит
---
Сообщение было скрыто модератором.
---
Поставьте проверку значения ссылки "документа основания" при проведении в модулеОбъекта и если значения не равны, то можете создавать новый. Как раз если документ будет меняться программно, полюбому должен записываться(проводиться). Все остальное (с формы или по кнопке) - не ваш вариант как я понял. Поэтому я бы сделал так.
---
А если в процессе проведения возникнет Отказ?
---
Процедуру проверки "документа основая" ставите только после того как проудут все проверки процедуры проведения. В самом конце. Или после проведения. Как как инициация события проведения.
---
Как быть, если Отказ возникнет в расширении обработки проведения или в подписке события ПриПроведении?
---
Вариант один. Делать после всех возможных проведений и отказав. Как только по документу перестают отрабатывать процедуры и подписки. Все можно проверять. Это может быть и подписка и регламентное. Смотря какая цель у вас. Может вам и док то до конца проводить не нужно, а смотреть когда в принице меняется док основания и в этот момент проверять, и не ждать проведения основного документа.
---
Как только по документу перестают отрабатывать процедуры и подписки. Как ты узнаешь - все подписки с расширениями отработали или еще нет? И в каком месте ты это узнаешь?
Смотря какая цель у вас. У меня вообще нет никакой цели, у меня есть только путь.
---
Узнать легко.
Включаете тайминг(замер времени).
Проводите свой документ и смотрите что еще отработало. Регламентные конечно так не увидеть. Но в модуле при записи в конце процедуры это самый верный путь. Будет ошибка значит не дойдет. Будут изменения, все равно через этот модуль пройдут.
---
Включаете тайминг(замер времени). Проводите свой документ и смотрите что еще отработало. Ты реально предлагаешь использовать отладчик в пользовательском режиме???
Но в модуле при записи в конце процедуры это самый верный путь. Вот! ПриЗаписи, как минимум!!! А не в ОбработкеПроведения!
Хотя, обработчик ПриЗаписи находится в транзакции, и внутри него тоже можно установить Отказ для основного документа. И обработчик при записи тоже может иметь расширения и подписки (последовательность работы которых никто не знает).

Иногда лучше жевать, чем говорить.
---
Для ненагруженной базы и если надо сделать быстро:
Можно выставить флаг в ДополнительныеСвойства объекта. В ПередЗаписью объекта. Что-то типа:

```1c
    Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
    Если ЭтотОбъект.ТвойРеквизит <> Ссылка.ТвойРеквизит
    ЭтотОбъект.ДополнительныеСвойства.Вставить("ТребуетсяСозданиеРеализации", Истина);
    КонецЕсли;
    КонецПроцедуры
```

Затем, в самом конце обработки проведения:

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

    КонецПроцедуры
```
---
Но это не очень правильно. Желательно разделить, например, через регистр сведений.

Т.е. в своем заказе, при необходимости, делаете запись в РегистрСведений, что требуется создание нового документа.
А регламентным заданием обрабатываете этот регистр сведений, создавая реализации, или фиксируя ошибки, почему не удалось создать реализацию.
---
Именно так. Или интерактивно спрашивать у пользователя, или автоматом через регламент (чтобы и при программном изменении документов этот регистр пополнялся и обрабатывался).
---
Ну и где вознаграждение за ответ?
Или мы неправильно насоветовали?
---
вознаграждение в 17 копеек... Я автору - не позорьтесь, здесь и так помогут...
---
Решил избавиться от остатков.
(26)Не было возможности зайти на сайт.
---
Начал делать эту доработку через расширение. Так как реквизит, который изменяется , это доп сведения документа, то в форме документа отловить момент изменения не удается. Сделал подписку на событие ОбработкаПроведения, с общим модулем, в котором отслеживаю изменение доп реквизита. С этим проблем нет.
В документе Реализация есть функция

```1c
    НовРеализация.ЗаполнитьДокументНаОснованииЗаказаКлиента(Источник)
```

Можно ли эту функцию добавить в общий модуль подписки на событие и как?
---
Не очень понял, в чём проблема?
У вас подписка на событие "обработкаПроведения" для документа Заказ, где вы должны создать новый документ "Реализация" при определенных условиях. Я правильно понял?

На всякий случай, если у Вас совсем нет опыта:
1) Для вызова процедуры или функции из другого модуля она должна быть объявлена как экспортная.
т.е. в конце объявления процедуры/функции должно быть написано зарезервированное слово "Экспорт".
Для функции:

```1c
    Функция ЗаполнитьДокументНаОснованииЗаказаКлиента(Источник) Экспорт
    ...
    Возврат Результат;
    КонецФункции
```

Аналогично и для процедуры (в отличии от функции, процедура ничего не возвращает):

```1c
    Процедура ЗаполнитьДокументНаОснованииЗаказаКлиента(Источник) Экспорт
    ...
    КонецПроцедуры
```

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

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

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

Как правило, один модуль на какое-либо событие (ОбработкаПроведения, ПередЗаписью и т.д.) используется для множества объектов одного типа, поэтому я и добавил проверку на тип ...Если ТипЗначенияИсточника = Тип("ДокументОбъект.Заказ")... Если в дальнейшем в эту подписку подключат ещё какой-то документ, то у Вас не будет генерироваться ошибка.

Если же ЗаполнитьДокументНаОснованииЗаказаКлиента НЕ в модуле объекта документа "Реализация", а в модуле менеджера, то вызов будет происходить немного по другому, что-то типа:

```1c
    НоваяРеализация = Документы.Реализация.ЗаполнитьДокументНаОснованииЗаказаКлиента(Источник);
    НоваяРеализация.Записать();
```

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

А затем промежуточные данные обрабатываете регламентным заданием. Опять, же, если записей требуется обрабатывать много, то можно сделать Рег.задание-оркестратор, которое запускает одновременно несколько фоновых потоков обработки. Но тут надо предусмотреть параллельность, чтобы не было ошибок блокировки одного объекта разными фоновыми заданиями.

Как пример для этой темы, справочник "ЗаданиеНаСозданиеРеализации" с реквизитами "Заказ", "Обработано", "КоличествоПопыток", "ДатаСоздания" и ТЧ "Логи" (Дата, описание). Можно и реквизит добавить "Реализация".

1) При проведении Заказа тупо делается новый элемент справочника записав только реквизит "Заказ". Это быстро.
2) РегЗадание-оркестратор делает выборку всех, где "Обработано" = ЛОЖЬ и "КоличествоПопыток" <= РегламентноеКоличествоПопыток, с группировкой по "Заказ". Делает Массив, Создает фоновое с передачей ссылки на "Заказ", пишет его в массив. Массив растет, пока выборка не закончится, или не будет достигнут лимит количества параллельных потоков. И пошел цикл, проверяющий массив фоновых, пока все фоновые не закончат выполнение работы и не кончится выборка. Как только фоновое закончило работу, оркестратор тут же запускает новое фоновое с передачей ему нового заказа с выборки и сует ссылку на фоновое в этот освободившейся элемент массива, если фоновое задание работает больше регламентного, то оркестратор считает, что зависло и убивает фоновое и тут же запускает новое со следующим "Заказ" из выборки. Практика показала, что лучше для таких рег.заданий сделать справочник настроек, где и указывать КоличествоПопыток обработки сообщения, КоличествоПотоков и пр. Тогда, количеством параллельных потоков можно будет управлять прямо на ходу (Типа было 2, выставил 12 и очередь быстро рассосалась, потом вернул 2)

3) Каждое фоновое делает выборку по "Заказ", и обрабатывает их. (Например, м.б. только одна "Реализация" на один "Заказ", но записей может быть в справочнике несколько) . Вот фоновое проверяет, если "Реализация" уже есть, то всем записям выставляет "Обработано " = ИСТИНА, и КоличествоПопыток = КоличествоПопыток + 1; в ТЧ пишет, мол Реализация уже есть и завершает свою работу. Если реализации нет, то в первый элемент справочника пишет КоличествоПопыток=КоличествоПопыток+1 в ТЧ лога пишет "Создаю реализацию", при успехе, пишет "обработано" = Истина, "Реализация" = ссылка на созданный документ. В остальных "Обработано " = ИСТИНА, и КоличествоПопыток =КоличествоПопыток+1; в ТЧ пишет, мол Реализация уже есть и завершает свою работу.

4) И должно быть резЗадание, которое чистит промежуточный (или несколько, ) справочник, например 3 дня, для тех, где "Обработано " = ИСТИНА и 10 дней, где "Обработано" = Ложь И "КоличествоПопыток" >=РегламентноеКоличествоПопыток. Там по логам можно будет разобраться, где и почему отвалилось.

Как-то так, вкратце.
---
С параллельностью тоже надо аккуратно. Как-то делал параллельную интеграцию с внешним порталом. Выставил 10 потоков - примерное время окончания - много часов. Выставил 40, нормально. Но потом сообразил пообщаться с админом серверов. Оказалось, что обычная нагрузка и дополнительных 40 потоков интеграции грузанули кластер из 5 нод под 90%. Он даже запаниковал слегка, типа недавно нарастили мощность кластера, а тут вроде как опять надо финансирование просить. Но в итоге разобрались.
---
То есть создавать справочник, ссылка которого не будет использоваться НИГДЕ, и у которого со временем закончится нумерация???
---
С проблемой окончания нумерации в промежуточном справочнике на практике пока не сталкивался.

Там в ТЧ логи. На практике так мне оказалось удобнее всего. Только чистить его надо. Всегда там будут данные за последние пару недель, дольше смысла хранить нету.

Пробовали и РС и логи в безразмерном поле дозаписывать.
Логи делают и другими средствами, например куда-нибудь в Кибану кидать. Но оно мне не очень удобно показалось.

Так-то обычно нужно понять проблему, зашел в 1с да посмотрел. Не надо лазить по другим продуктам, там то доступ надо просить, то вебморда переехала.
---
Зачем вообще использовать ссылочные сущности? Обычный РС. Один регламент создает документы раз в пять минут, другой регламент раз в день удаляет обработанные записи недельной давности (чтобы не плодить миллионы записей). И не надо лохматить бабушку.
---
Да ради бога, храните в РС. Тут на вкус и цвет, так сказать.
---
Кстати, регламент-оркестратор можно выставить на запуск 1 раз в секунду. Он пока работает, новый экземпляр не запустится. И получается такая непрерывная работа. Оркестратор запустился, за несколько минут очередь обработал, завершился и тут же заново стартанул для обработки нового пакета данных. Ну это если данные массово льются. Тут из практики смотреть надо. Вполне может быть, что для некоторых случаев и раз в 5 минут - слишком часто.
---
Все бы хорошо, но с регла некоторые вещи в ЕРП не сделаешь т.к. они делаются только из формы... и передают данные в объект через доп свойства переданные туда на форме... а потом эти доп свойства идут в след документ. (Кроме ЕРП нигде такой херни не встречал), да можно это долго и упорно скопировать к человеческому виду... но потом обновление и опять по новой... ненавижу документы которые на 1/3 генерируются почему-то на форме
---
ненавижу документы которые на 1/3 генерируются почему-то на форме так и не генерируй...
---
Это к фирме 1С а не ко мне для примера данного можно вспомнить хотя бы счет-фактуры и 1С:Бухгалтерия то как там генерируются при проведении счет-фактуры
---
Вроде все получилось.
 Осталось установить структуру подчиненности в созданном документе. Пока не получается.
---
А как пытался?
---
Если правильно помню, оно в типовых само выстраивалось по значению в реквизите "Основание".
Но это не точно... :)
---
Это точно "не точно". В ERP и в УТ выстраивается по специальному объекту - Критерий отбора "Структура подчиненности"
---
Ты правда идешь на 7-м месте в форумном рейтинге?
Вот такое оно - Сообщество...
---
Мы на ты?
---
Кто это - вы?