Тема,собственно.

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

(0) да, написать нормально код.

в сервис параметры воткнуть галочки, наслаждаться, кушать печенки

(1) Нарушить авторские права предлагаете? Воткнуть транзакцию на уровне плаформы?
(2) Прошу прощение за вопрос: А какая галочка на это влияет?

(3) на закладке Оперативный учет.

там их не много

одна из них, при проведении, сдвигает время документа и ставит ТА на него

при проведении после ТА заменять врекмя на текущее?

в результате, ТА всегда там, где надо

(7) я не помню ужо,  клюшки забросил :)

можно клюшки отнять у человека, но нельзя человека отнять у клюшек © Почти

(10)Не всегда гвозди стоит забивать паровым молотом, бывает достаточно и молотка.

(6) У всех стоит галка "при проведении после ТА заменять время на текущее". При этом 4 пользователя(запускают автоматизирующую обработку) в параллели с ещё 6 другими(ручная работа) в основном получают адекватные ответы системы на запросы, а один из 4 периодически натыкается на 1SSystem на сервере, что проявляется двумя видами:полный отказ в проведении документов(Чуть ни каждый день, с учётом 3-х часовой ежедневной загрузки данных УРБД), и отказ в расчёте итогов после ТА(раз в месяц - два). Так что как то так.

(12)из-за уриба может некорректно ТА вставать, на сколько я помню

(12) это у тебя происходит при работе 10 пользователей?

(13) Этого я не знал. Большое спасибо.

(14) всего 24 пользователя,+ 6 технических аккаунтов.

а не проще ли запихать ТА на месяц-два вперед?

(17) Это выход, да. Спасибо.

(17) (18) За такие советы убивать нужно.

(19) в некоторых случаях это пригодно. При наличии излишних вычислительных мощностей. Можно и потерпеть отход от стандарта. У нас и так 1С++ крутится, база на SQL.

(20) Вопрос не с стандарте, вопрос в падении скорости проведения документов в 5 раз.

(21) не гони волну - на нестандартных базах, когда "отборку товара" закидывают в конец месяца или планы выпуска на три месяца вперед, ещё никто не умирал,
а перевод ТА раз в месяц - обычная практика

(22) Обычная практика у рукожопых.

(23) для "умников": если ТА на конец месяца поставлена, он твоего торможения на скулевой базе ни одним органом не прочухает

(24) Для тех, у кого рация на бронепоезде - любой документ начинает при проведении выполнять временный расчет итогов вместо того, чтобы получать готовые итоги на ТА. Производительность проведения при этом падает минимум в 5 раз. И в 5 раз растет время блокировки базы.

(25) Это плохо. Но никак не лучше, когда вместо проведения документа юзер получает строку о невозможности получения итогов. Это 7.7, господа....

Хотел написать "всёже лучше, чем "

(26) ыыыы, под стол ... временный расчет с какой точки?
и в чем разница если док проводится задним числом?
и как заметить эту пресловутую разницу в 5 раз ?
ну я не настолько могуч, чтобы отличить 0,02 сек от 0,1 ...

(28) Джинн прав, но: лучше получить проведение, чем никому ненужные строки о невозможности. И да, при 40 активных пользователях, уже придётся переходить на серверного робота-проводильщика.

(29) да не спорю, но в общую таблицу итогов ложится и будет менятся всего одна строка - на конец месяца,
а вот для перехода на серверного робота-проводильщика ты упаришся создавать ситуацию ...
из опыта: на более 100Г-базе при активных 25 юзверях

+(30) а вот с закидом на 3 месяца - чутка почуствовали торможение, но не умерли)

(29) ой сори, ТА ставь на 1 число след.месяца и проверь, чтобы периодичность в регистрах была "месяц":
нет заморочек со постоянными сдвигами ТА - тоже занимает время,
не нужен быдлокод на сравнение КонДаты с ТА в отчетах и не нужен тот же перерасчет итогов в них

(28) Коллега, не городите херню. Этим Вы только свою бестолковость показываете.

(29) Лучше найти причину и устранить ее, чем городить костыли.

(33) о да, вы каквсегда правы, коллега)
(29) ну да можно и гири пилить ... если время есть)

(34) Буду рад заменить Dll-ну на другую, которая процесс проведения с переносом ТА будет делать в одной транзакции. Ссылочку на скачивание дадите, коллеги?

(36) Нельзя делать транзакцию внутри транзакции. Кроме того перенос ТА неотрывен от проведения документа. Нет никакого "промежутка времени". Вы ищете черную кошку в темной комнате. Дело не в этом. Дело в том, что какая-то зараза пишет документ на на ТА, а в "будущем времени". В сети, через РИБ или еще как.

(37)... Данную версию наш комитет тоже скурпулёзно отработает и соберёт авторов. Спасибо.

(36) да передвинь уже точку ТА руками - проще будет,
держу пари, что Джин не сталкивался с ситуацией когда один документ открывается двумя пользователями одновременно
, типа это невозможно, но факт - фактом, тогда клинит даже скулевую БД - вот ощутишь всю прелесть "передвижной" ТА

Всем спасибо, поеду на диван пить кофе. И вам всем того же желаю, мягкой и тёплой киски.

(39) Нет, не сталкивался. Хотя на 7.7 лет 10 отработал и достаточно "плотными" базами.

Может это здесь работает, тогда пофиг галочки у ползователя?
ПроводитьПослеТА(<?>,);
Синтаксис:
ПроводитьПослеТА(<ФлагДляНеПров>,<ФлагДляПров>)
Назначение:
Установить режим проведения документа после ТА. Возвращает текущее значение режима перепроведения документа в зависимости от проведенности.
Параметры:
<ФлагДляНеПров> - режим проведения документа после ТА. Число: -1 (минус единица) - проводить документ всегда задним числом; 0 - при проведении запрашивать режим проведения документа; 1 - проводить документ в реальном потоке времени, т.е. при проведении время документа автоматически устанавливается на время после ТА.
<ФлагДляПров> - режим перепроведения документа после ТА. Числовое выражение: -1 (минус единица) - проводить документ всегда задним числом; 1 - проводить документ в потоке.
Замечание:
Метод доступен только в Модуле формы документа и работает с документом доступным в локальном контексте.