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

Код:
[CODE]Процедура ИзменитьСтатусыЗаказовНаОснованииПоступленияБДС(ОбъектПоступлениеБДС) Экспорт
   Для Каждого РасшифровкаПлатежа Из ОбъектПоступлениеБДС.РасшифровкаПлатежа Цикл
       Попытка
           Заказ = РасшифровкаПлатежа.Заказ.ПолучитьОбъект();
           Если Заказ.Статус = Перечисления.СтатусыЗаказовКлиентов.Согласован Или
                Заказ.Статус = Перечисления.СтатусыЗаказовКлиентов.КОбеспечению Тогда
               Заказ.Статус = Перечисления.СтатусыЗаказовКлиентов.КОтгрузке;
               Для Каждого СтрокаТовар Из Заказ.Товары Цикл
                   СтрокаТовар.ДатаОтгрузки = ТекущаяДата();
               КонецЦикла;
           КонецЕсли;
           Попытка
               Заказ.Записать(РежимЗаписиДокумента.Проведение);
           Исключение
           КонецПопытки;
       Исключение
       КонецПопытки;
   КонецЦикла;
КонецПроцедуры[/CODE]

делать в событии ПриЗаписи

Создал процедуру "ПриЗаписи(Отказ)", поместил вызов процедуры "ИзменитьСтатусыЗаказовНаОснованииПоступленияБДС(ОбъектПоступлениеБДС)" в неё, но результат тот же.

(0) Консерваторию менять надо

Порой меня поражает насколько "бывалые" пользователи форума любят бесполезно нафлудить, подразумевая свою высокую осведомленность и одновременно полную неосведомленность автора в обсуждаемой теме. Кстати, как тут в ответе сослаться на другой ответ? (Типа "(3)" )

(3) - Подскажите, пожалуйста, если знаете, как реализовать.

Кто-нибудь? Очень хочется решить эту задачу до следующей недели. Я уверен что тут какая-то принципиальная ошибка. Я не учился программированию на 1С, так что могу не знать каких-то нюансов или даже основ. Можно конечно делать проверки вручную, и вызывать метод "Записать" только если ошибок точно не будет, но это получится как-то громоздко.

(4) >> Порой меня поражает ...

И меня тоже.

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

Это как бы давно известный факт.

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

+ к (7):

Как вариант - хранить всю эту ересь про статусы заказов и даты отгрузки не в документе Заказ, а в регистре сведений.

(0) Никак. Народ бает, что попытка/исключение реализовано в виде неявной транзакции. Так что исключение гарантированно откатывает все вышестоящие транзакции.

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

зачем заказы перепроводить?

подписка спасет любителя извратов...

(13) Хммм... на какое событие?

Спасибо за ответы! Попробую реализовать задачу иначе. (11) Заказы перепроводить чтобы проверялись условия оплаты и прочее, и статус менялся только если его можно поменять. Нужно сделать что-то вроде автоматизации статусов, чтобы их меняла программа при соответствующих событиях (в основном это оплата), а не люди.

2(15) еще раз - зачем перепроводить целый документ если нужно только поменять статусы, то есть изменить что - какой-то РС?

Вот неужели когда тебе задают вопрос "Зачем ты одел шубу" ты начинаешь рассказывать что это хорошее вложение денег, она удобная, и так далее, вместо того чтобы сказать "чтобы согреться когда на улице холодно"?

(12) Я сисадмин в небольшой организации %) Мне платят всего 180р в час.

(15) Я пошёл простым путём. Склад по статусам может определить, с какими заказами работать. Поэтому я решил сделать, чтобы статусы менялись автоматически, чтобы избавить людей от ненужной работы. Я не знаю как поменять статус и потом сохранить документ, не используя метод "Записать", который проводит документ.

2(18) нет, вы пошли неправильным, неналазящим на голову здоровым людям и системе путем... Надо было просто озвучить конечную цель и вам бы подсказали...

19)

(19) А теперь подскажут? Задача - чтобы статусы заказов менялись на 'к обеспечению' или 'к отгрузке' автоматически при проведении поступления безналичных дс, в  зависимости от выполнения условий оплаты.

2(21) какой регистр меняется после вашего кода в случае все-таки успешного перепроведения заказа?

(22) Регистр? У меня меня меняются реквизиты "статус" у заказов. потом склад смотрит заказы, через форму списка заказов, где и видят статусы.

(22) конфигурация на основе УТ 11.0.5.4

(17) А что сисадмин в 1Се делает?
Сварщики, сисадмины - все хотят вкусить запретного плода.

(17) Я очень бедный... я год не был в бане... я старый... меня девушки не любят... Я сисадмин в небольшой организации %) Мне платят всего 180р в час...

зы: извините, не удержался...

(26) :D а по теме что-нибудь?
(25) Я делаю "всё" :) что связано с компами

(27) по теме тебе уже все сказали - вложенные транзакции не поддерживаются...

2(23) в коде у тебя меняется вообще дата...
а раз проводить не нужно то записывай без режима проведения:
Заказ.ОбменДанными.Загрузка = Истина;
Заказ.Записать(РежимЗаписиДокумента.Запись);


таким образом ошибка может возникнуть только в одном исключительном случае - если этот же Заказ записывается или заблокирован кем-то другим

(0) Нужен РН .

(30) Не обязательно. Можно РС.
А лучше к документу свойство настроить, его и в отчете видно, и поменять легко..

(29) ну так транзакция все-равно откатится...

(29) Меняется Заказ.Статус, а СтрокаТовар.ДатаОтгрузки устанавливается для того чтобы не было ошибки проведения (нельзя ставить статус "К отгрузке", если не заполнены даты отгрузки - документ не проведётся). Если записывать без проведения, то наверно не будут выполняться проверки, которые выполняются при проведении? А мне они нужны. Мне нужно чтобы программа попробовала поменять статус, но не сделала этого если какие-то условия не выполняются. Единственная причина, по которой я использую проведение - именно запуск всех проверок.
(31) Я уже давно умер
(28) Это я понял, значит видимо буду делать без вложенных транзакций, придется отдельную кнопку повесить в форму документа для вызова этой процедуры.
(32) Свойство документа? Тут вопрос принципиального удобства использования статусов - они уже есть, они для этого и сделаны ведь, и для разных статусов уже написан код всяческих проверок, который не хотелось бы дублировать или экспортировать. Пойду почитаю про свойства документа. Однако совершенно не хочется вводить отдельную систему статусов в довесок к существующей, это как-то странно - дублировать функционал стандартной конфигурации другим способом.

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

(34) Пример: бухгалтер вводит поступление БДС. Какая-то часть заказа оплачивается (не 100%). Нужно, чтобы программа, незаметно для бухгалтера (которому на заказы всё равно) проверила, достаточно ли оплачено по заказу, чтобы перевести его обработку в логистику (статус "к обеспечению") или чтобы начать его отгружать ("к отгрузке") и если "да" то поменяла бы статус на соответствующий. Бухгалтер только жмёт "провести и закрыть" в своём поступлении БДС, потому что всё остальное можно сделать кодом, не заставляя бухгалтера проверять вручную условия оплаты по заказу и проставлять или не проставлять соответствующий статус. Ключевой пункт "если да" - вот зачем мне проверки, которые выполняются при проведении. Там проверяется оплата, дата отгрузки и всё остальное. Будет неправильно, если какой-нибудь недозаполненный заказ перевелся в "к отгрузке", потому что склад потом будет иметь проблемы с этой отгрузкой.

мы сделали справочник "Статусы" и реквизит "Статус" в документах и все, зачем это гемор с кодом.

Для юзера все должно быть наглядно, очевидно и аццке жостко.

Инструментарий БП слишком сложен для многих реальных бизнес-процессов и нагружать им юзера похабно

(36) я бы в регламенты эту проверку перенес...

(29) "таким образом ошибка может возникнуть только в одном исключительном случае - если этот же Заказ записывается или заблокирован кем-то другим"

Есть метод Заблокирован(), если его проверять тогда ошибки не возникнет

(34) "Это я понял, значит видимо буду делать без вложенных транзакций, придется отдельную кнопку повесить в форму документа для вызова этой процедуры."

Не надо, если меняешь реквизит делай это через Записать() без всяких проведений и никаких ошибюок не возникнет.

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

(40) Это уже вопрос логики автора, которой он может управлять по своему усмотрению

(38) Думал об этом, наверно будет лучше всего. Не создавал ещё ни разу собственных регламентных заданий, поэтому не знаю как это делать. Щас поковыряю, разберусь наверно =)
(40) Конечно, если заказ уже "к отгрузке" или "к обеспечению", то я его проводить заново не буду, я его вообще пропущу. А вот "согласованные" придется проводить, чтобы проверки запускать.
(37) Вы имеете ввиду что можно задействовать БП, чтобы не писать код? БП для меня тема нераскрытая, поэтому я до понедельника наверно не успею эту штуку освоить. И с БП ведь придется всю фирму переучивать работе.

(32) РС нельзя схлопнуть.

(43) Что значит "схлопнуть"?

(42) думаю вам и до осени БП - не освоить, лучьше свою статустную простую подсистему сделать.

Не трать время на БП, пусть разработчики типовых ваяют)

Итого - сделал регламентное задание, которое каждые полчаса проверяет ПБДС за последние 60 минут и прогоняет по указанным в них заказам нужные проверки и, если нужно, меняет статусы и перепроводит. Всем спасибо за подсказки и пояснения! По-моему, получилось вполне оптимально.

(42) На самом деле это сделано реквизитом в документе совсем не случайно, так сделано потому, что очень часто достоверно сказать оплачен заказ или нет нельзя. Скажем у покупателя было несколько оплат а учет ведется по основновному договору то оплаты можно будет определить только по ФИФО или среднему, что не всегда соответствует действительности. Можно конечно заказы всегда однозначно привязывать к оплатам, но тогда, может взвыть Ваша бухгалтерия, посему я бы посоветовал не мудрствовать лукаво, а оставить все как есть, если же очень хочется сделать нечто подобное, то ввести периодический регистр сведений с измерениями: Организация, контрагент, Заказ и ресурсом Статус, но, опять таки как будет автоматом рассчитываться закрытие некоторого заказа не очень представляю

(47) закрываться заказ будет по последнему платежу в статусе "Оплачено", который "закроет" сумму по всему заказу

(47) Бухгалтерии вообще статусы не нужны. У нас бухгалтерия в УТ только разносит оплату и больше ничего не делает. Основная работа у них в БП, куда производится выгрузка. А склад всегда использует статусы - если нужно отгрузить, ставит "К отгрузке", если программа не даёт - звонят менеджеру и говорят что так и так - условия не выполнены - либо меняйте условия либо не отгружаем. Автомат я делаю для того чтобы "если нужно отгрузить" происходило в том числе автоматически. Сейчас у нас менеджер звонит на склад и говорит "отгружайте пожалуйста, клиент оплатил". Эту работу можно автоматизировать. Договора у нас никак на проверку оплаты не влияют.

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

(49) Еще раз прочитай (50)

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

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

(50) Вам нужно рабочее место и роль "Обработка платежей", пользователь этой роли будет делать сопоставление(связь) платежей с заказами(договорами). Это сопоставление должно иметь авто/ручные/аналитические режимы

Или еще вариант, два заказа - ранний на большую сумму и поздний на малую - клиент закрывает оплату по второй сумме (малой), а у тебя эта проплата скинется на первый заказ не зккрывая и первый заказ и второй...

(54) читай (53) - без статусов и рабочего места по обработке платежей от клиен-банков такое решить только в коде НЕ реально. мы год ломали голову пока пришли к простым и логичным решениям

(50) Бухгалтер при вводе ПБДС подвязывает сумму и к договору и к заказу, т.к. когда клиент платит, он указывает в платёжке, какой заказ он оплачивает. У нас так, по крайней мере. Моя автоматизация проверяет свежие ПБДС. Не совсем понимаю как договор может помешать в этой схеме автоматически поменять статус заказу.
(51) Как я мог прочитать (50), если мой ответ был раньше? :D

(53) Это не мне нужно, это ТС нужно, я и говорю, что данный процесс не сильно поддается алгоритмизации, точнее его нельзя сделать автономным без вмешательства человека, поэтому и не стоит делать регламентных заданий, должно быть нечто вроде обработки которую запскает менеджер и только менеджер решает по какому заказу прошла проплата, единственное что стоит сделать для упрощения - это дать возможность выбирать менеджеру сразу группу заказов в которых по нажатию некой кнопки "Изменить статус" менять статус групповым образом...

естественно без участия человека тут никакой регламент не спасет. Пример навскидку, "так все по фиг - по этому договру немедленно сделать оплату эээ на ээээ NNN, потом разберемся")