Всем привет!
Пытаемся в процедуре проведения "на лету" сделать отметки в документе:

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

Делает вид, что изменения сохранились, на "Записать" не ругается, но записи не происходит.
Документ в момент выполнения этого кода не заблокирован (ФОбъект.Заблокирован() возвращает Ложь).

Выходит, что нельзя записывать проводящийся документ?

За это ФОбъект = Ссылка.ПолучитьОбъект(); в обработке проведения положен пожизненный эцих.

(1) Вариантов обхода никаких?

(2) ошибки не надо обходить, их надо исправлять

(3) Обхода ситуации в целом, имею в виду.
В момент проведения выполняется проверка в другой системе, и её результаты хотелось бы хранить в табличной части, которая проверяется. Вынести проверку из проведения сложно из-за необходимой очерёдности задействованных процедур.
Ежу понятно, что можно сделать например регистр, в который пихать сведения. Но очень не хочется заводить целый регистр.

Код конечно кривой и лучше это сделать в процедуре ПередЗаписью
ЕМНИП ИМХо не надо его получать и записывать, просто перебирайте строки и пишите туда данные

(4) "В момент проведения выполняется проверка в другой системе"

А за это в эцих вкручивают ржавые шурупы...

(4) скорее всего не сработало Если, а записалось нормально. Проверьте отладчиком, попадает на строку эту?

(5) спасибо за идею. Увы, в Проведении при прямом обращении к документу тоже не сохраняет:

Для Каждого СтрокаКодаОбъекта Из ЭтотОбъект.ШтрихкодыУпаковок Цикл
  Если СтрокаКодаОбъекта.ШтрихкодУпаковки = НужныйШтрихкод Тогда
    СтрокаКодаОбъекта.ДатаПроверкиПередачиЧестныйЗнак = ТекущаяДата();
  КонецЕсли;
КонецЦикла;

В "ПередЗаписью" закинул в "Если РежимЗаписи = РежимЗаписиДокумента.Проведение", отладчик проходит, в конфигураторе значения меняются, а записи нет.
Пошёл искать, не переинициализируются ли где-то после данные документа.

(7) Увы, "Если" срабатывает, в отладке данные меняются, а в сам документ не записываются.

(6) А что не так, позвольте спросить? :) Но, чур, аргументированно.

(8) Аргументированно? Обращение к внешнему ресурсу в транзакции, когда время доступа к этому ресурсу нерегламентированно, вызывает ожидание этой самой транзакции. А если другая система будет 10 минут отвечать? Транзакция так 10 минут и будет висеть? А потом будет висеть разработчик такого решения...

(9) Здесь позвольте поспорить. Время ожидания ответа на http запрос штатно по умолчанию всегда ограничивается, обычно ставят в 10 секунд. Нет ответа = Отказ в проведении.
В условиях, когда бизнес-процессы должны быть жёстко сихнронизированы, зависимость проведения от ответа второй системы логична.
Если просто описать процесс: мы не можем продать товар клиенту, если он ещё нами не выкуплен с ОТХ. Выкупать с ОТХ до реализации невыгодно - нет гарантии продажи. Делать менеджеру кнопку "выкупить товар" - моветон, это лет ...цать назад делали. Делать выкуп после проведения - невозможно, на момент регистрации чека ККМ на основе реализации в ОФД товар должен быть выкуплен.
Так что Бизнес-процесс подключается именно там, где должен быть - в момент единственной процедуры, осуществляемой менеджером вручную. В случае сбоев менеджер сможет корректно отреагировать.

(8) Интересно было бы посмотреть код, который вы написали в ПередЗаписью.
Может вы там снова какую-нибудь несусветную ересь пишете с получением объекта через Ссылка.ПолучитьОбъект().

В обработке проведения никакие данные менять нельзя. Все изменения объекта должны происходить в ПередЗаписью и/или подписках на это событие.

(10) Если речь идёт об интерактивной работе пользователя, то и делайте свои проверки интерактивно при работе с формой, а не в транзакции. И вовсе не обязательно делать менеджеру отдельную кнопку.

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

В случае сбоев проведение должно произойти?
Предположу, что, скорее всего, нет. Если я прав, то фраза "изнес-процесс подключается именно там, где должен быть" явно ошибочна.
Проверка, что выкуп прошел без сбоев, должна быть завершена ещё до проведения.

OFF. дополнительные 10 секунд на транзакцию проведения?... Какой эцих с гвоздями? Тут только транклюкирование на месте, без суда и следствия.

PS Всё сказанное - разумеется ИМХО. Т.к. реальная картина может отличаться от того что написал автор ветки ;)))

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

(0) При необходимости совершения отметок в документе в момент его проведения, эти отметки нужно выносить в регистр сведений. Или в процедуру ПередЗаписью (11).
(10) я поддержу коллегу из (9) и предложу вариант готовить покупку вне документа, например в обработке типа ПродажаСВыкупомОТХ, по схеме: 1. Купили (с обращением к внешней системе); 2. Оформили документ продажи с чеком ККМ.

(11) "Тут только транклюкирование на месте, без суда и следствия."
Заметь, я уже заменил гвозди на шурупы. Ржавые... ))

(11)(12) При всём уважении к ветеранам форума. Где же вы прочли, что транзакция будет висеть 10 секунд в фразе о том, что время ожидания ответа ограничено 10 секундами? :D А командирские часы, на которых написано "предельная глубина погружения 5 метров", тоже только под водой будете эксплуатировать? :D

(15) По опыту - если говорят, что ожидание 10 секунд максимум, то она, блЪ, и будет ждать все 10 секунд.

(15) сделайте уже свою кнопку и удалите с формы типовой Ок. шаблон потом обратно срастётся
(16) ты предлагаешь получить деньги только за работу, но не за доделку и переделку)

(15) всё-таки выкиньте ФОбъект этот. пишите просто

Записать(РежимЗаписиДокумента.Запись);

а то получается, вы 2 раза документ записываете, сначала ФОбъект, а потом сам объект, и ФОбъект затирается.

(18) Я, кажется, понял, почему в "ПередЗаписью" тоже не записывается. На тестирование взял документ, в котором в конце в результате проверки на наличие происходит Отказ = Истина, и возможно происходит откат транзакции.

ФОбъект убрал.

(15) >> Где же вы прочли, что транзакция будет висеть 10 секунд.

В (10). Ты сам написал.
И вовсе не обязательно, что она всегда будет висеть 10 секнд. Достаточно, чтобы в один прекрасный день ваш http-сервис перестал отвечать на запросы (пусть даже по не зависящей от вас причине), и весь отдел разработки за ваше творчество повесят на первом же столбе за остановку отгрузки.

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

(20) Это ж "Честный знак" - если завис их http сервер, то мы перед продажей клиенту не можем выкупить товар с ОТХ, а если мы не можем выкупить товар с ОТХ, то никакой продажи клиенту быть не должно. Штраф.

(21) Вот именно!
Так какого хрена вообще начинается проведение, если http-сервис завис?
Выкуп (или хотя бы проверка возможности его осуществления) должен происходить ДО проведения реализации, а не в момент её проведения.
Это две разные хозяйственные операции - выкуп и реализация выкупленного. Хоть и связанные межу собой.

(21) Сначала делайте документ "Выкуп с ОТХ", потом - документ продажи. Два разных документа.