Вход | Регистрация
 

Как победить оперативное проведение 1С, если документов больше, чем секунд?

Как победить оперативное проведение 1С, если документов больше, чем секунд?
Я
   ptiz
 
16.03.20 - 23:55
Как победить оперативное проведение 1С, если документов больше, чем секунд? Например, вечером в 23 часа начинается вал реализаций, которые проводятся оперативно. Проводится по 2 реализации в секунду. В результате через полчаса 3600 реализаций сдвигают оперативную отметку времени на 23:59:59. И приехали :(
Есть такие кто попадал в похожую ситуацию? И как боролись?
 
 
   МихаилМ
 
1 - 17.03.20 - 00:31
очевидно, что это не оперативное проведение документов.
   Злопчинский
 
2 - 17.03.20 - 00:31
Оперативно? явно нет - я сомневаюсь что сотрудники генерят с такой скоростью.

Реализации автоматом генерить не в 23 часа, а по факту готовности данных для генерации реализации - хоть в 18 часов, хоть в 17.
Или вести подсчет "готовности" к генерации реализаций, как только колов таких "готовнгостей" переваливает "длительность " в 1 час - сдвигать начало генерации...
Это первые мысли что не думая пришли в голову
   Злопчинский
 
3 - 17.03.20 - 00:31
(1) Однозначно!
   Garykom
 
4 - 17.03.20 - 01:20
   Garykom
 
5 - 17.03.20 - 01:22
Хотя я неправильно понял проблему и нужная инфа тут https://its.1c.ru/db/metod8dev/content/2746/hdoc

(1) +1
   Krendel
 
6 - 17.03.20 - 01:40
(0) Не совсем понимаю, а что мешает по 10 реализаций в секунду писать?
   seevkik
 
7 - 17.03.20 - 02:20
(6) вера
   МихаилМ
 
8 - 17.03.20 - 02:40
(6) 1с8 может писать  в 1 секунду в 10 раз больше чет 1с77. те 100 000.
   Конструктор1С
 
9 - 17.03.20 - 03:39
(8) а с чего ты взял, что в восьмерке есть ограничение на количество документов в секунду?
   Провинциальный 1сник
 
10 - 17.03.20 - 06:39
(5) Прочитал, много думал. Что они курили?

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

О какой вообще оперативности может идти речь, если система фальсифицирует данные, в частности время регистрации факта?? Что мешало сделать правильно - ввести таблицу "последовательность регистрации", где фиксировать последовательность документов при оперативном проведении в один момент времени..
   Злопчинский
 
11 - 17.03.20 - 09:19
(8) я что-то думаю, что в 77 в секунду можно писать поболее чем 10000
   ptiz
 
12 - 17.03.20 - 09:43
(1) Да. Скажем, юзеру делаем отдельную кнопку "Провести", которая будет проводить документ не оперативно, текущим временем, а остатки контролировать "оперативно".
Какие косяки могут при этом быть?
   Bigbro
 
13 - 17.03.20 - 09:43
(11) там есть ограничение. именно в 10 000.
   ptiz
 
14 - 17.03.20 - 09:44
(2) У нас время убегает начиная с "послеобеденного" часа. 40 тыс накладных за день случилось :(
   Bigbro
 
15 - 17.03.20 - 09:44
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
   Cyberhawk
 
16 - 17.03.20 - 09:46
Я так понял, автору надо чтоб задействовалась прикладная логика всяких контролей остатков, которая по недалекости ребяток из 1С подвязана на оперативный режим проведения, а не на какой-нибудь другой - прикладной - семафор.
   ptiz
 
17 - 17.03.20 - 09:49
(16) Да мы надеялись, что не упремся в 23:59:59 и хватит стандартного оперативного проведения, а тут еще коронавирус злой - клиенты затариваются :)
   ptiz
 
18 - 17.03.20 - 09:59
Кстати, если оперативная отметка улетела на 23:59:59, тогда можно на клиенте поменять дату на будущую, и, несмотря на расхождение с датой сервера 1С, документы "будущей" (относительно сервера 1С) датой, нормально проводятся оперативно (с датой 00:00:01 и т.д.).
Но пока оперативная отметка до 23:59:59 не улетела - такой фокус не проходит.
   Bootini
 
19 - 17.03.20 - 09:59
МоментВремени() использовать при проведении, а не секунды пибавлять
   Сияющий Асинхраль
 
20 - 17.03.20 - 11:13
(19) А вот что касается МоментаВремени()

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

если верить статейке, ВОЗМОЖНА некоторая неоднозначность в расположении документов введенным одной секундой, причем как она может возникнуть сама 1С не поясняет :-(
   ptiz
 
21 - 17.03.20 - 11:19
(20) Там всё понятно. Упорядочивание таблиц идет по Дата+GUID. А у новых документов гуид не всегда "больше" старого. Но это немного другая тема. А нам, похоже, остается только переходить на полунеоперативное проведение (неоперативное технически, но с оперативным контролем остатков).
   Злопчинский
 
22 - 17.03.20 - 11:38
(13) точно, уверен?
припоминается мне что мы тут с кемто с мисты проводили исследование в тис - сколько доков можно запихнуть а 23-59-59 - получалось дофигища... но вот сколько именно - хз... проверю вечером. имхается всетаки больше 10 тыс... там это скорее всего ограничивается уникальностью ида, а там в конце вроде как две позиции под инкремент... 23 буквы плюс 10 цифр - может оно и получится под 10 тыс..
   Bigbro
 
23 - 17.03.20 - 11:40
а почему не использовать последовательности?
там вроде хоть миллион документов в секунду все будет однозначно располагаться как положено.
   Bigbro
 
24 - 17.03.20 - 11:41
(22) уверен, наступал на эти грабли в далекие годы. и в (15) ссылка
   Злопчинский
 
25 - 17.03.20 - 11:45
(24) ... но я проверю на всякий случай...
   Провинциальный 1сник
 
26 - 17.03.20 - 11:47
(22) В семерке понятие "момент времени" присутствует, он гарантирует сохранение последовательности документов в порядке их проведения в пределах одной секунды. А в восьмерке такого нет. Там в одну секунду тоже может быть много документов, но при этом не гарантируется сохранение последовательности в хронологии.
   Bigbro
 
27 - 17.03.20 - 11:56
(26) ну так все верно, отказались от этого и правильно я считаю сделали. механизм последовательностей позволяет не думать о количестве документов в секунду в принципе никогда.
совсем. там где важен "момент времени" именно последовательностью и надо пользоваться.
   Tonik992
 
28 - 17.03.20 - 12:46
Сортируй по дате + номер документа
   Дык ё
 
29 - 17.03.20 - 12:56
(15) это никак не ограничивает количество документов в пределах секунды. + хотя возможность закладывалась, она не использовалась - платформа 7.7 всегда записывала документы в целых секундах
   Провинциальный 1сник
 
30 - 17.03.20 - 13:05
(27) Угу, так замечательно сделали, что теперь для сохранения хронологии приходится фальсифицировать время..
 
 Рекламное место пустует
   vova1122
 
31 - 18.03.20 - 10:15
(25) проверяли количество документов в пределах одной секунды?
   Serg_1960
 
32 - 18.03.20 - 11:02
(21) "А у новых документов гуид не всегда больше старого" - но в пределах одного вида можно реализовать алгоритм генерации GUID возрастающей последовательности (имхо, справедливо в пределах одной, не РИБ, базы). Тогда более поздний новый документ всегда(!) будет "больше" существующих документов. Но, как я уже ранее говорил, идея лишена смысла пока есть возможность редактирования даты и времени существующих документов.
   Cyberhawk
 
33 - 18.03.20 - 11:54
(32) Неа, в пределах одной ИБ нельзя. Только в пределах одного сеанса.
   Bigbro
 
34 - 18.03.20 - 12:01
повторю вопрос из (23)
   Йохохо
 
35 - 18.03.20 - 12:10
(32) когда говорят про "повторяемость" никакого "редактирования даты и времени" не бывает
   palsergeich
 
36 - 18.03.20 - 12:18
(34) Технологические и организационные проблемы
   ptiz
 
37 - 18.03.20 - 12:32
(34) Это про 8ку или 77? Последовательность никак тут не поможет.
В общем, пока заткну дыру так: если время "улетело вперед" - провожу накладную неоперативно датой последнего документа (но при этом контроль остатков - оперативный). Завтра посмотрим результат (а то второй день не спим, время ночью переводим).
   vova1122
 
38 - 18.03.20 - 12:52
(13) (25) в 77 похоже нет ограничения на количество документов в одной секунде. Запустил создание документов в транзакции. на даный момент уже создано 170000 документов (партиями по 500 шт) и обработка продолжает работать. Но заметил замедление в создании документов
   Bigbro
 
39 - 18.03.20 - 12:56
(38) время документов созданных проверял?
(37) про 8. почему не поможет, если это механизм который 1с рекомендует для подобных случаев?
   vova1122
 
40 - 18.03.20 - 13:00
(39) все в 23:59:59
   ptiz
 
41 - 18.03.20 - 13:11
(39) Последовательность нужна для "пересчета" данных в случае, когда она нарушается из-за работы "задним числом". Её граница - МоментВремени(), включающий "дату документа + Ссылку". Это та же проблема 8ки: нет нормального упорядочивания документов внутри секунды. Что им мешало сразу предусмотреть хотя бы 1/1000 доли секунды? :(
   Cyberhawk
 
42 - 18.03.20 - 16:29
(41) "Что им мешало сразу предусмотреть хотя бы 1/1000 доли секунды? :(" // Видимо, возвели ситуацию в абсолют: кому не хватает секунды, тому и тысячных секунд не хватит
   ptiz
 
43 - 18.03.20 - 16:43
(42) По большому счету, секунд хватает для 99,9% клиентов. Но остальным - страдать.
   Tonik992
 
44 - 18.03.20 - 16:43
Создайте свое поле, Дата2.
Оно будет числовым и хранить время до милисекунд.
   ptiz
 
45 - 18.03.20 - 16:48
(44) Останется его в регистр накоплений запихнуть и придумать свои виртуальные таблицы с миллисекундами :)
   Cyberhawk
 
46 - 18.03.20 - 17:06
(44) Угу. А потом третье поле - макросекунды. А потом - нано.
   Злопчинский
 
47 - 18.03.20 - 20:01
(24) вот не зря я сомневался. потому что я успел забыть больше чем некоторые знали... ;-)
не зря у меня в мозгу в дальних закоулках маячит что когда мы проводили испытания - в одну секунду можно было записть дофига документов. не 10 тыс (это не дофига), а реально больше. Как и обещал (с задержкой правда) провожу испытания:
.
Уже в 23:59:59 в 17.03.20 записано 60 тыс.
во, в (38) уже проверено... я, кстати, тоже по 500шт генерю в транзакции.
   Злопчинский
 
48 - 18.03.20 - 20:10
при этом IDDOC - совсем небольшой, влезет еще дофигища...
   celentano
 
49 - 19.03.20 - 19:06
(0) У нас система может генерировать тысячи документов за один день, и т.к. документы проводятся очень быстро то за одну секунду один сеанс успевает сгенерировать несколько десятков документов. Естественно при оперативном проведении дата мгновенно уплывает "вправо". В итоге:
- Отказались от неоперативного проведения
- Контроль остатков выполняется так же как и выполнялся бы при оперативном проведении
- Перед записью нового документа дополнительно устанавливаем значение точной даты записи (используя ТекущаяУниверсальнаяДатаВМиллисекундах() в последней строке события "ПередЗаписью" модуля объекта)
   Cyberhawk
 
50 - 19.03.20 - 20:19
(49) Наверное, ты хотел сказать "отказались от оперативного проведения"
   celentano
 
51 - 19.03.20 - 20:39
(50) Точно. Еще забыл дополнить, что для новых документов все блокировки устанавливаются в событии "Перед записью" и до вычисления "точной даты записи". Что бы при необходимости можно было понять последовательность проведения документов изменяющих остатки по одинаковым комбинациям измерений.
   Злопчинский
 
52 - 19.03.20 - 21:08
(49) а что за система такая?
   celentano
 
53 - 19.03.20 - 21:12
(52) Типа Microsoft Project Server
   Сияющий в темноте
 
54 - 20.03.20 - 00:26
а в чем проблема?
если есть документы за текущее время,то просто переносим их все на секунду назад ну или наш сиещаем на секкнду вперед,далее оперативное проведение документа,а далее возврат всего в зад,то есть правка даты без проведения в документе и движениях.
   Провинциальный 1сник
 
55 - 20.03.20 - 06:55
(54) Проблема в том, что тогда теряется последовательность проведения документов внутри секунды.
   Bigbro
 
56 - 20.03.20 - 08:00
(47) странно. документы просто пишутся, без проведения?
ну значит запамятовал я. извините.
   ptiz
 
57 - 20.03.20 - 09:20
(49) "Перед записью нового документа дополнительно устанавливаем значение точной даты записи " - а куда вы миллисекунды деваете? В дате документа ведь их нет.
   celentano
 
58 - 20.03.20 - 15:07
(57) Отдельный реквизит.
   ptiz
 
59 - 20.03.20 - 15:08
(58) И во запросах - дополнительная сортировка по нему?
   celentano
 
60 - 20.03.20 - 15:31
(59) Скорее мы ее используем для целей анализа. Например, когда необходимо восстановить последовательность действий в системе, что бы понять почему был построен именно такой план проекта. В этом случае очень удобно видеть приблизительную очередность регистрации документов, т.к. документы по сути отражают как действия пользователей так и реакцию на эти действия системы. В тех редких случаях когда важно получить порядок стараемся использовать поля "момента времени".
   Злопчинский
 
61 - 20.03.20 - 23:33
(56) просто, без проведения. но с проведением или без - это ни на что не влияет имхо.


Список тем форума
Рекламное место пустует  Рекламное место пустует
Компьютеры — это как велосипед. Только для нашего сознания. Стив Джобс
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.