Как победить оперативное проведение 1С, если документов больше, чем секунд? Например, вечером в 23 часа начинается вал реализаций, которые проводятся оперативно. Проводится по 2 реализации в секунду. В результате через полчаса 3600 реализаций сдвигают оперативную отметку времени на 23:59:59. И приехали :(
Есть такие кто попадал в похожую ситуацию? И как боролись?

очевидно, что это не оперативное проведение документов.

Оперативно? явно нет - я сомневаюсь что сотрудники генерят с такой скоростью.

Реализации автоматом генерить не в 23 часа, а по факту готовности данных для генерации реализации - хоть в 18 часов, хоть в 17.
Или вести подсчет "готовности" к генерации реализаций, как только колов таких "готовнгостей" переваливает "длительность " в 1 час - сдвигать начало генерации...
Это первые мысли что не думая пришли в голову

(1) Однозначно!

(0) https://its.1c.ru/db/metod8dev/content/2737/hdoc

Хотя я неправильно понял проблему и нужная инфа тут https://its.1c.ru/db/metod8dev/content/2746/hdoc

(1) +1

(0) Не совсем понимаю, а что мешает по 10 реализаций в секунду писать?

(6) вера

(6) 1с8 может писать  в 1 секунду в 10 раз больше чет 1с77. те 100 000.

(8) а с чего ты взял, что в восьмерке есть ограничение на количество документов в секунду?

(5) Прочитал, много думал. Что они курили?

"Механизм оперативной отметки выдает текущее время или большее на одну секунду последней выданной какому-либо пользователю отметки, если последняя выданная отметка больше или равна текущему времени."

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

(8) я что-то думаю, что в 77 в секунду можно писать поболее чем 10000

(1) Да. Скажем, юзеру делаем отдельную кнопку "Провести", которая будет проводить документ не оперативно, текущим временем, а остатки контролировать "оперативно".
Какие косяки могут при этом быть?

(11) там есть ограничение. именно в 10 000.

(2) У нас время убегает начиная с "послеобеденного" часа. 40 тыс накладных за день случилось :(

1.1.3. Хранение времени
Время может храниться в двух форматах: Числовое представление, Строковое представление.
В случае числового хранения времени оно отсчитывается от начала суток в десятитыcячных долях секунды. Т.е. фактически будет получено число: (Часы*3600+Минуты*60+секунды)*10000. Т.е. Для времени 19:05:36 – 687360000 (1С умеет учитывать время до 10000 долей секунды, как в случае с документами).
В случае числового хранения времени время с числового значения (Часы*3600+Минуты*60+секунды)*10000 переводиться в 36-ричный формат. Так, для времени 19:05:36 - BD8IDC.

https://www.script-coding.com/v77tables.html

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

(16) Да мы надеялись, что не упремся в 23:59:59 и хватит стандартного оперативного проведения, а тут еще коронавирус злой - клиенты затариваются :)

Кстати, если оперативная отметка улетела на 23:59:59, тогда можно на клиенте поменять дату на будущую, и, несмотря на расхождение с датой сервера 1С, документы "будущей" (относительно сервера 1С) датой, нормально проводятся оперативно (с датой 00:00:01 и т.д.).
Но пока оперативная отметка до 23:59:59 не улетела - такой фокус не проходит.

МоментВремени() использовать при проведении, а не секунды пибавлять

(19) А вот что касается МоментаВремени()

http://catalog.mista.ru/public/84177/

если верить статейке, ВОЗМОЖНА некоторая неоднозначность в расположении документов введенным одной секундой, причем как она может возникнуть сама 1С не поясняет :-(

(20) Там всё понятно. Упорядочивание таблиц идет по Дата+GUID. А у новых документов гуид не всегда "больше" старого. Но это немного другая тема. А нам, похоже, остается только переходить на полунеоперативное проведение (неоперативное технически, но с оперативным контролем остатков).

(13) точно, уверен?
припоминается мне что мы тут с кемто с мисты проводили исследование в тис - сколько доков можно запихнуть а 23-59-59 - получалось дофигища... но вот сколько именно - хз... проверю вечером. имхается всетаки больше 10 тыс... там это скорее всего ограничивается уникальностью ида, а там в конце вроде как две позиции под инкремент... 23 буквы плюс 10 цифр - может оно и получится под 10 тыс..

а почему не использовать последовательности?
там вроде хоть миллион документов в секунду все будет однозначно располагаться как положено.

(22) уверен, наступал на эти грабли в далекие годы. и в (15) ссылка

(24) ... но я проверю на всякий случай...

(22) В семерке понятие "момент времени" присутствует, он гарантирует сохранение последовательности документов в порядке их проведения в пределах одной секунды. А в восьмерке такого нет. Там в одну секунду тоже может быть много документов, но при этом не гарантируется сохранение последовательности в хронологии.

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

Сортируй по дате + номер документа

(15) это никак не ограничивает количество документов в пределах секунды. + хотя возможность закладывалась, она не использовалась - платформа 7.7 всегда записывала документы в целых секундах

(27) Угу, так замечательно сделали, что теперь для сохранения хронологии приходится фальсифицировать время..

(25) проверяли количество документов в пределах одной секунды?

(21) "А у новых документов гуид не всегда больше старого" - но в пределах одного вида можно реализовать алгоритм генерации GUID возрастающей последовательности (имхо, справедливо в пределах одной, не РИБ, базы). Тогда более поздний новый документ всегда(!) будет "больше" существующих документов. Но, как я уже ранее говорил, идея лишена смысла пока есть возможность редактирования даты и времени существующих документов.

(32) Неа, в пределах одной ИБ нельзя. Только в пределах одного сеанса.

повторю вопрос из (23)

(32) когда говорят про "повторяемость" никакого "редактирования даты и времени" не бывает

(34) Технологические и организационные проблемы

(34) Это про 8ку или 77? Последовательность никак тут не поможет.
В общем, пока заткну дыру так: если время "улетело вперед" - провожу накладную неоперативно датой последнего документа (но при этом контроль остатков - оперативный). Завтра посмотрим результат (а то второй день не спим, время ночью переводим).

(13) (25) в 77 похоже нет ограничения на количество документов в одной секунде. Запустил создание документов в транзакции. на даный момент уже создано 170000 документов (партиями по 500 шт) и обработка продолжает работать. Но заметил замедление в создании документов

(38) время документов созданных проверял?
(37) про 8. почему не поможет, если это механизм который 1с рекомендует для подобных случаев?

(39) все в 23:59:59

(39) Последовательность нужна для "пересчета" данных в случае, когда она нарушается из-за работы "задним числом". Её граница - МоментВремени(), включающий "дату документа + Ссылку". Это та же проблема 8ки: нет нормального упорядочивания документов внутри секунды. Что им мешало сразу предусмотреть хотя бы 1/1000 доли секунды? :(

(41) "Что им мешало сразу предусмотреть хотя бы 1/1000 доли секунды? :(" // Видимо, возвели ситуацию в абсолют: кому не хватает секунды, тому и тысячных секунд не хватит

(42) По большому счету, секунд хватает для 99,9% клиентов. Но остальным - страдать.

Создайте свое поле, Дата2.
Оно будет числовым и хранить время до милисекунд.

(44) Останется его в регистр накоплений запихнуть и придумать свои виртуальные таблицы с миллисекундами :)

(44) Угу. А потом третье поле - макросекунды. А потом - нано.

(24) вот не зря я сомневался. потому что я успел забыть больше чем некоторые знали... ;-)
не зря у меня в мозгу в дальних закоулках маячит что когда мы проводили испытания - в одну секунду можно было записть дофига документов. не 10 тыс (это не дофига), а реально больше. Как и обещал (с задержкой правда) провожу испытания:
.
Уже в 23:59:59 в 17.03.20 записано 60 тыс.
во, в (38) уже проверено... я, кстати, тоже по 500шт генерю в транзакции.

при этом IDDOC - совсем небольшой, влезет еще дофигища...

(0) У нас система может генерировать тысячи документов за один день, и т.к. документы проводятся очень быстро то за одну секунду один сеанс успевает сгенерировать несколько десятков документов. Естественно при оперативном проведении дата мгновенно уплывает "вправо". В итоге:
- Отказались от неоперативного проведения
- Контроль остатков выполняется так же как и выполнялся бы при оперативном проведении
- Перед записью нового документа дополнительно устанавливаем значение точной даты записи (используя ТекущаяУниверсальнаяДатаВМиллисекундах() в последней строке события "ПередЗаписью" модуля объекта)

(49) Наверное, ты хотел сказать "отказались от оперативного проведения"

(50) Точно. Еще забыл дополнить, что для новых документов все блокировки устанавливаются в событии "Перед записью" и до вычисления "точной даты записи". Что бы при необходимости можно было понять последовательность проведения документов изменяющих остатки по одинаковым комбинациям измерений.

(49) а что за система такая?

(52) Типа Microsoft Project Server

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

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

(47) странно. документы просто пишутся, без проведения?
ну значит запамятовал я. извините.

(49) "Перед записью нового документа дополнительно устанавливаем значение точной даты записи " - а куда вы миллисекунды деваете? В дате документа ведь их нет.

(57) Отдельный реквизит.

(58) И во запросах - дополнительная сортировка по нему?

(59) Скорее мы ее используем для целей анализа. Например, когда необходимо восстановить последовательность действий в системе, что бы понять почему был построен именно такой план проекта. В этом случае очень удобно видеть приблизительную очередность регистрации документов, т.к. документы по сути отражают как действия пользователей так и реакцию на эти действия системы. В тех редких случаях когда важно получить порядок стараемся использовать поля "момента времени".

(56) просто, без проведения. но с проведением или без - это ни на что не влияет имхо.