В общем тема такая
Есть развивающаяся самописка
Хочу забубенить в неё такое гипер-свойство, чтобы от результатов проведения в документе менялись некоторые реквизиты типа Булево
ну типа "Проведен по разделу учета НДС", "Отгрузка произошла до упора" и т.д. для быстрого отбора родимых в журналах, запросах и прочих хозяйственных визуализациях
Думал, подавать документ в общий модуль, проводить и проставлять реквизиты в режиме Загрузка. А транзакцию целесообразно ставить в этом случае, или есть какие другие варианты

делай это в ПередЗаписью

(0) храни супер-гипер-нано-свойства в РС

(1) а если обработка проведения не сработает, события процедуры ПередЗаписью откатятся?

(2) это утяжелит запросы в динамических списках

(3) проверь )

(4) Ага, а перезаписывать документ - это конечно нормально...

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

(5) проверил. действительно откатывается

(4) не приниципиально

а я и не знал

я так проблема в том, что логика проведения тяжеловесна и узнать, что свойство надо установить можно только ПОСЛЕ проведения, вот это интересная задача

(9) да просто реквизит документа он логичней, проще и естественней
а вот чтобы узнать кое-чё родное, делать левое соединение к регистру с параметрами..

(11) ну а чо. вот например, статус отрузки заказа
я щас в динамическом списке делаю соедениние с регистром
а куда как проще проставлять реквизит "СтатусОтгрузки"

(11) что там интересного? подписка на проведение... все движения при проведении доступны в рамках данной транзакции. ставь там свойство своё

(13) лентяй чтоль? соединение ему лень делать)

(14) угу и потом будет вызываться обработка ПередЗаписью и ПриЗаписью опять (если конечно хранить в таблице документа)

(14) гениально

(16) обрабатывать в условии как щас делается если загрузка, то гуляйте, вася

(16) а вообще можно не в таблице документа

(18) это неверная затычка, скажем так костыль для устранения ошибок архитектуры

(20) согласен в принципе

(19) то есть все таки (2)? я победил ))

(16) этот случай вобще не по метолологии 1с, есно хранить в регистре)
З.ы. эт ещё фигня, франчи тут внедряют, дак в обработке проведения такой код набыдлокодили:
ЭтотОбъект.Записать();
Вот что гениально

(22) да дело не в победе, а в результатах
просто реально влом делать соединения
я не думаю, что это нарушает концепцию мироздания
для состояния регистров существуют какие-то базовые взаимные отношения, которые могут иметь интерфейс быстрого доступа
надо просто верно в платформе обработчики подобрать

(23) ну так сама 1с так делает! замечал много раз, как звёздочка в заголовке документа мерцает

(25) нет, 1с так не делает. моргание звёздочки тут не причем

по идее нужно так
1. запись редактируемых реквизитов документа
2. обработка проведения (в это же транзакции запись нередактируемых реквизитов документа)
3. профит

(26) моргание звёздочки это прямое указание на запись документа, насколько я понимаю

(28) вернее, на изменение записанного

(27) платформа так не может, всмысле придётся быдлокодить как в (23), не есть гуд.
(28) нет... хз почему маргает, но точно не из-за записи. в типовых нет Записать() ни при проведении, нигде короче. Перед записью часто меняются, но никак не уже записанные

(30) извини, ты не прав. в ЗУПе такое точно есть

там вообще идёт циклическое проведение документа

я просто к тому, что быдлокод свойствен и 1су

(31) возможно, но 1 случай - не показатель того что так и надо. в УПП я не видел нигде такого (подсистему ЗУПа не смотрел правда), сути это не меняет - это не по феншую

в некоторых случаях быдлокод оправдан, в твоём - нет) храни в регистре да не ленись соединения ставить

(34) да, феншуй тут жестко сосет

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

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

(37) ну как, есть запись, а есть проведение. проведение без записи не возможно. как не связаны?

(39) ну как-раз таки реквизит типа булево Проведен хранится в документа, хотя обработка проведения не изменяет самого документа
ладно, не суть важно

(38) да, так и делается. В реквизиты обязательно добавлять то что влияет на логику проведения

буду воевать с платформой

(41) кто так делает, я таких не знаю )

(43) это методология ЕМНИП

всмысле что коментарий и т.д в регистр - маразм конечно, а то что надо менять - логично

Довелось тут такое же делать, оказалось в ОбработкеПроведения просто пишешь
ОбменДанными.Загрузка=Истина;
Записать();
ОбменДанными.Загрузка=Ложь;

Все нормально пашет. Хотя если бы эту фигню делал я - сделал бы по другому. Всю подготовку сделал бы перед запись, данные запихал в ДополнительныеСвойства и в ОбработкеПроведения использовал бы их.