Незавершенная транзакция #544729

Создам заново. Интересует, каким образом это оптимальнее сделать. Есть документы, которые двигают остатки по регистру накопления ОстаткиТоваровНаСкладах. Данные об остатках надо отправлять в Веб через HttpСоединение. Чтобы при обработке проведения не было ожиданий выгрузки в Веб, мало ли сервер недоступен и т.п.. чтобы операции были независимы данные в веб сливают регламентным заданием, которая считывает данные из вспомогательного регистра сведений, независимого непериодического с 2 измерениями: Номенклатура и GUID(произвольный, на момент записи строки в регистр). Второй измерение добавлено для того, чтобы спокойно проводились документы, даже если их табличные части пересекаются по номенклатуре. Данный промежуточный регистр заполняется в подписке на событие ОбработкаПроведения документов, двигающих остатки. Проблема: Возникают ситуации, когда регламентное задание читает данный промежуточный регистр, расчитывает остатки по регистру накоплений, а в нем еще не зафиксировалась транзакция по движению регистра накопления. Соответственно отправляются остатки без учета движений документа, транзакции которого еще не зафиксированы. После этого промежуточный регистр очищается (считанный набор записей), и остатки по документу, транзакции движений которого были не зафиксированы не отправляются. Подскажите, какую выбрать реализацию, чтобы обойти данную ситуацию.

Пятница? Весна? Уже никто не работает? :)

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

Регистр сведений - чтобы отфильтровать, остатки по какой номенклатуре отправлять. Ресурсов нет. Документы делают движения по регистрам накопления ОстаткиТоваров. В момент отправки могут существовать документы, номенклатура из которых отмечена для выгрузки остатков по ней, но системная транзакция по записи этих движений еще не завершена.

Т.е. регистр существует для контроля номенклатуры, по которой изменились остатки?

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

шаманские методы предлагать?

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

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

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

планы обмена с авторегистрацией

или без авторегистрации

например при записи набора записей регистра регистрировать на служебный узел номенклатуру

А не повторится ошибка, что в узле плана обмена номенклатура уже будет записана, а транзакция по движениям еще не зафиксирована.

нет

а вообще - какого оно у тебя читает "грязные№ данные?

регистр сведений независимый, в подписке на событие пишутся записи... и они уже доступны для запроса из обработчика регламентного задания. Отсюда и "грязное" чтение.

>Чем поможет чтение данного регистра в транзакции? не данного регистра, а регистра остатков...

Чтение регистра в транзакции получит данные как раз без завершенных транзакций, что сейчас и происходит..

серьезно? а мужики-то не знают...

Я не прав? После такого чтения и отработки регламентного задания прочтенный набор записей регистра очищается, соответственно остатки по такой номенклатуре не обновляются.

Напоминает соседнюю тему с крестиками-ноликами. Автор создает себе надуманную проблему, а затем ее ожесточенно решает. а) Надо периодически отправлять остатки? Читаем периодически остатки и отправляем. б) Надо периодически отправлять изменения остатков? - Первый раз - Читаем остатки, заносим в регистр "ОтправленныеОстатки", отправляем. - Каждый следующий - читаем остатки, сверяем изменения с сохраненными в регистре, измененные отправляем и фиксируем новые значения в регистрах. Не надо ничего городить в обработке проведения.

А что означает цветная полоска под ником? :)

30 тысяч товаров. 1200 накладных в день. В минуту несколько накладных. Сверка не уронит базу то? Про полоску не знаю.

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

вообще - планы обмена рулят

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

А у большинства длиннее, чем у меня оО [полоска]

Ща попробую.. Давно только планы обмена не щупал. Хочется универсальности. Задним числом могут поправить, и тогда в пролете опять.

Может от стажа на форуме зависит?

Не уронит. Попробуй выполнить запрос типа ВЫБРАТЬ Если будет дольше нескольких секунд, стоит задуматься о более сложном решении. Регистр ПереданныеОстатки с измерением Номенклатура и ресурсом Количество.

Номенклатура, характеристика, серия, качество и складов порядка 30... Думаю все-таки в сторону плана обмена.