Как сохранить данные при отмене транзакции. #788049

ГОСПОДА! Проводится документ. В модуле проведения выполняются вычисления. В зависимости от полученных значений формируется отказ проведения. Требуется сохранить полученные значения вычислений после завершения проведения. Запись независимого регистра из модуля проведения - не работает. Прошу подсказать. Спасибо

рассчитывай это до транзакции

еще можно в журнал регистрации записать

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

Стартани фоновое, в которое передашь нужные данные.

Транзакция - она подвержена болезни ACID...

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

Не надо проводить документ. Сделайте нужные вам вычисления без проведения документа.

а почему надо сохранять результат вычисления? и почему нельзя эти вычисления сделать до проведения?

ну, в нормальном состоянии люди такой дурью не должны баловаться...

категорически согласен с

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

Ты того... Больше такое не принимай... А то тебя штырит совершенно не по-детски...

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

Это какая-то неправильная конфа. )))) Но суть не в этом. Личное ИМХО, с точки зрения банальной бытовой логики, система работает абсолютно корректно. Но даже если не так, то 1С не поддерживает вложенных транзакций. То есть если на любом уровне вложенности произошло явное или неявное исключение, то отменяется вся транзакция. И в большинстве случаев это правильно. >> при проведении одного дока ... создается другой док Вот это вообще жесть >> делать перед проведением первого - геморойно Геморройно у вас уже случилось. осталось сделать теперь правильно.

чего только не придумают, лишь бы дороги не строить..

Ну переделывать работающую конфу на которой куча  народа работает - ради этой мелочевки смысла нет. Надо обойтись по минимуму. А вообще - согласен конфа - кривовато написана.

хватит мучать народ. давай "камингаут" - расскажи подробнее. вдруг что и предложат, если будут знать детали..

Может, как было сказано ранее, нужно до транзакции рассчитывать? Например, добавить поле, таблицу, страницу или еще какую-то херь и её заполнять по воле пользователя?

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

Автора не интересует правильное решение. Ему нужна заплата на конкретную ситуацию.

"нужна заплата" - наверное, торопиться зарплату к новому году получить)

Ну прикладных терминах это выглядит так : На производстве вываливается из станка изделие и его выпуск оформляется в виде отчета производства за смену. Отчет записывается и пытается провестись при этом по спецификациям определяется перечень материалов и полуфабрикатов которые должны были бы списаться со склада. На основании этого перечня внутри транзакции проведения создается требование-накладная и она тоже пытается провестись. В случае если остатков материалов на складе хватет то все чикипоки проводится. Если нет - то отказ. Все доки создаются но остаются не проведенными. Люди хотят знать каких именно материалов не хватает и сколько не хватает.

Щас ручками пеытаются перрепровести каждую ТН и смотрят на что она ругается. Но это не удобно т.к. доков много и в них много строк.

А надо по всей совокупности на начало дня остатки на складах корректировать

упп?

ес ит ыз

"требование накладная" - упп.. а через обеспечение потребностей не вариант посмотреть достаточность материалов?

Тут замороченая схема разузлования с основными и запасными спецификациями и разнообразными аналогами. От обеспечнения потребностей давно отказались. Хотят просто отказаться от ручного перепроведения ТН и получать по факту чего не хватает

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

тогда, не мучайте(сь) - посмотрите как в  ERP, и аналогично сделайте..

достойно)...

В минус проводить запрещено.

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

1. выполняем расчёт потребностей по спецификациям. 3. проводим. 4. если ок - проводим ОПзС. 5. Иначе - материмся по системе громкого оповещения предприятия.

+ 6. если 5 не помогло, бьем морды и опять 5.

пиши в журналрегистрации

Ну это уж на крайняк

Его ж потом еще и чистить надо

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

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

пусть будет проведен, а сигналом пусть будет задание: "Разберись и почини" с предметом "отчет производства". Иначе вы не видите реального объема производства.

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

Надо просто им ускорить работу

Схема "в лоб" и скорее всего не работающая :) (не особо думая) Из станка что-то вываливается --> оформляется заказ на производство, где материалы автоматом заполняются по спецификации и резервируются(!). Этот документ всегда проводится (ибо по сути свой, он декларативный). Далее на основании этого документа легко обработкой заполнять и требования, и отчеты. НО: перед этим желательно заполнить перемещение на удовлетворение потребностей (резерв-остатки). Всё автоматизируется одной кнопкой "Сделать всё!" в одной обработке.

Эээ... вообще-то, для цеха с автоматическими линиями, так и сделано: оперативно отчеты о выпуске (без материалов): требование-накладная, распределение материалов и отчет мастера в конце смены.

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

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

можешь читать массив регламентоМ

Эээ... нестандартный подход к системе резервирования позволяет "регистрировать" отсутствие материалов в кладовых цехов без формирования отрицательных остатков ещё на этапе планирования (формирования заказов на производство) (офф) Книжки на полочке - это хорошо. Но недостаточно. Особенно когда тебе начальники (а их много над тобой) в унисон хором говорят: "А нам нада так!"(цы)

Во ! Это мы щас проверим.

+100 самое правильное решение... есть еще одно решение: делаем обработку "Выпуск детали ХХХ" в ней заполняем весь алгоритм из отчета за смену, повторям ТЧ и прочее.... по кнопке "провести" открываем транзакцию и шлепаем отчет за смену и все остальные детали... в случае отката - откатываем всю транзакцию при этом все сообщения будут доступны для пользователя...

PS: осталось только разобраться по поводу чего в автор прокричал "Эврика!"(с) :)

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