Вход | Регистрация
    1  2  3  4  5  6  7  8   
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: 1С 7.7 ТИС ДБФ УРИБ 40 юзеров. Надо победить блокировки транзакций

v7: 1С 7.7 ТИС ДБФ УРИБ 40 юзеров. Надо победить блокировки транзакций
Я
   tgu82
 
28.10.20 - 13:18
1С 7.7 ТИС ДБФ УРИБ 40 юзеров.

В понедельник вообще с утра работать не могли. И так почти полтора часа.
Только когда я стал по очередности выгонять всех ввидимо отцепилась блокировка и
и все наконец заработали.

Заметил что 3 варианта блокировок:
1. при обмене урбд, попытка захвата доступа к 1SUPDTS
2. При попытке создать новый документ - попытка захвата 1SJOURN
3. При поытке создать элемент справочника - попытка заквата SC214 или 1SDNLOCK
3.1 Блокировка 1SDNLOCK возникает и при создании нового документа (видимо из-за нумерации что ли)

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

Базы не малые, регистр RA328 подходит к 1.7 ГБ
Я так понимаю что многие проблемы из-за проведения документов задним числом ну и перепроведения если надо
Время ожидания захвата БД сброшено в ноль у всех вроде бы, но уточню. Может кого прозевал.
Заметил что в понедельник много потому что делают много приходов и в пятницу тоже.
Причем всем надо с утра.

На ПБ как-то особенно с этим всем проблем и нет а вот на ЦБ бывают, и неприятные
Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше.
В ЦБ банк касса розница енвд перемещения поступления оптовые реализации комплектации и т.д.
Магазины для себя в ЦБ делают большие перемещения с Центрального склада.

Мне бы хотя бы четко понимать из-за кого в любой конкретный момент времени возникает блокировка (за исключением обмена)
Тогда бы можно было его притормозить а другие бы работали дальше !!!
   Mikeware
 
301 - 02.11.20 - 11:19
(293) (292) ну так создание  документа - это тоже транзакция. Создав документы заранее - уже уменьшишь число транзакций вдвое.
Хотя по хорошему, надо сразу писать туда дату, чтоб занять.. Но если готовить данные для дока сильно заранее, и проверять перед записью документ на свободность - можно сильно уменьшить число коллизий
   tgu82
 
302 - 02.11.20 - 11:20
(300) Да понял, хорошая придумка. И так до упора, пока не освободит?
(299) Нет, ГП я вообще не использую. С утра в понедельник Поступление и большие перемещения с центра на магазины (все делается в ЦБ)
   Mikeware
 
303 - 02.11.20 - 11:21
(.) проверь почту, я тебе какое-то УГМамонтов скинул, откуда можно взять планировщик
   tgu82
 
304 - 02.11.20 - 11:22
(301) Да, пробую уже так делать. Но это только на Создание.
На ДохБухт.записать() - мне это не поможет
   tgu82
 
305 - 02.11.20 - 11:23
(303) Видел и поблагодарил
   tgu82
 
306 - 02.11.20 - 11:26
(300) Справочник из одной записи служебный с одним полем - так получается?
И ФлагВзведен - это если элемент этот не блокирован
   tgu82
 
307 - 02.11.20 - 11:30
Пот интерактивной записи и проведении все бы и ничего, но как только внутри записи проводятся транзакционные операции с дополнительным документом -- сразу ошибки транзакций. ТАкой получается вывод.
   Злопчинский
 
308 - 02.11.20 - 11:32
(302) " и большие перемещения с центра на магазины"
вот они у тебя и тупят. потому что скорее всего делаются задним числом (?) (а предыдущий документ от ТА - это уже заднее число). плюс перемещения возможно у тебя тянут партионку, а если регистр незакрыт - обьем обработки в проведении будет большой, вот тебе и тормоза. И я очень сомневаюсь что даже 30 манагеров прям таки раком могут поставить базу если они проводят документы интерактивно и документ проводится до секунды.
   Mikeware
 
309 - 02.11.20 - 11:32
(304) а записать - долби, пока не продолбится, только давай паузу, чтоб другие.
(306) (300) а ишшо при "взведении надо проверять, что его другой в это время не взводит :-)"
   Злопчинский
 
310 - 02.11.20 - 11:33
(307) При записи делай асинхронное генерацию внешнего события и после записи документа это нормально отработает.
   Злопчинский
 
311 - 02.11.20 - 11:34
(303) а мне?!
   Андрей_Андреич
 
312 - 02.11.20 - 11:35
(311) В очередь, щукины дети - в очередь! (с)
   Злопчинский
 
313 - 02.11.20 - 11:35
(309) потенциально - наверное да. но взвести такой флажок - это быстро. очень быстро.
у меня на таком принципе было сделано когда расфасовка книжек по заказам разными людьми делалась, чтобы пересорта/лишнего не случилось
   Андрей_Андреич
 
314 - 02.11.20 - 11:35
(303) Тоже люблю УГ Мамонта посмоктать :)
   Mikeware
 
315 - 02.11.20 - 11:36
(311) а оно те надо?
   tgu82
 
316 - 02.11.20 - 11:36
(315) Ну они все есть у меня в адресной.
Если вы не против - тут же перешлю
   Mikeware
 
317 - 02.11.20 - 11:40
(316) кидай, мне не жалко.
Просто сейчас продолжать делать что-то на клюшках - странно...
Хотя, они, конечно, "неисчерпаемы, как атом"©
   Злопчинский
 
318 - 02.11.20 - 11:41
(315) а то ж!
у меня крутится простенький робот-планировщик, но хочется побольше возможнгстей
   Злопчинский
 
319 - 02.11.20 - 11:42
(317) на 8-ке делать еще страшнее.
осваиваю EYA/
это иснтрумент для ручной работы толпы обезьян. автоматизации по минимуму.
ошибок - вагон.
   tgu82
 
320 - 02.11.20 - 11:43
(308) Регистр партий в-основном кончено закрыт, RА328 намного меньше RG328
А какое внешнее событие генерироватьв процедуре ПриЗаписи() ?
   Mikeware
 
321 - 02.11.20 - 11:43
(318) перекинул. Если надо будет для сиквельной - пиши, там выборка немного  ускорена, на пару порядков вроде. поищу
   Злопчинский
 
322 - 02.11.20 - 11:45
(321) не скуль не надо. спсб.получил
   Злопчинский
 
323 - 02.11.20 - 11:46
(320) должно быть наоборот РГ (итоГ) должен быть раз в 10 меньше РА
   Злопчинский
 
324 - 02.11.20 - 11:47
(320) да похрен какое. главное сгенери ;-) выше в ветке я для автосоздания СЧФ код написал.
абсолютно аналогично.
.
только надо посмотреть аккуратно  что запись отдельно идет интерактивная или с проведением.
   tgu82
 
325 - 02.11.20 - 11:47
(323) ДА наоборот же РА намного больше РГ. Просто затупил
   tgu82
 
326 - 02.11.20 - 11:48
(324) Тогда для чего его генерить? если по хрен какое)
   Mikeware
 
327 - 02.11.20 - 11:50
(326) для того, чтоб на него отреагировать и создать док..
   Mikeware
 
328 - 02.11.20 - 11:54
(319) Эх, я вот с СКД воюю. шткуа мощнейшая, но себе на уме. Убивает отсутствие внятной доки. Рекомендации на ИТС и книжка дают примитив, который и так понятен. а сложнее - уже хреннайдешь, только разбираться методом нашего известнейшего профэссора...
   ДенисЧ
 
329 - 02.11.20 - 12:01
(328) Ты с ней воюешь, вот она тебя и убивает.
А ля герр ком а ля герр, понимаешь ли....

)))
   Mikeware
 
330 - 02.11.20 - 12:03
(329) угу. подружиться не получается
 
 Рекламное место пустует
   tgu82
 
331 - 02.11.20 - 12:07
Получается что надо максимально ускорять провведение документов. Именно тут собака зарыта.
Хотя если задним числом через РассчитатьИтогиНа - тут сильно и не ускоришь вообще-то. И еще же одно замедляет.
Если один и тот же товар в нескольких строках. Потому что партии тогда будут списыватьс  учетом уже списанных. И Это ксатит тоже тормозит проведение, ведь такая возможность в нем учтена
   Андрей_Андреич
 
332 - 02.11.20 - 12:12
(331) Вроде прямые запросы и для ДБФ есть?
   tgu82
 
333 - 02.11.20 - 12:28
(332) Есть конечно. Но только цены при проведении как-то не используются, там же уже готовые суммы.
Цены используются на этапе формирования тч документа, то есть вне транзакции. Но может так делать - все равно удобно. И займет этот и на обчыных запросах очень немного времени.
   Mikeware
 
334 - 02.11.20 - 12:33
(331) это, вообще-то, базовая штука: максимум готового, минимум расчетов в транзакции.
(333) кроме как цены получать - у прямыхЪ запросовЪ есть еще много других применений.
(332) не помнишь, как в дбфной версии РассчитатьИтогиНа делаются - пробегом по РА, или выгрузкой выборки РА во временную дбф, как с запросами?
   Андрей_Андреич
 
335 - 02.11.20 - 12:41
(334) Не работал с ДБФ прямыми
   Mikeware
 
336 - 02.11.20 - 12:42
(335) не, не прямыми - именно при штатной работе. как прямые работают - я знаю
   Злопчинский
 
337 - 02.11.20 - 12:57
(326) причем отреагировать и создать во время простоя системы
   Злопчинский
 
338 - 02.11.20 - 12:58
(331) в оперативной работе убить нахуй всю работу задним числом. особенно реализации, перемещения и прочую хрень. не вижу никакой необходимсоти проводить это в оперативной работе задним числом массово.
   tgu82
 
339 - 02.11.20 - 13:08
(338) Хорошо бы. Ну воте сли резюмировать - то получается что я вставляю в цикле с паузой попытку исключение конецпопытки в узких местах связанных с созданием и записью дополнительного документа к родительскому и мониторю время проведения документов, если вижу что сильно длинное - пытаюсь уменьшить. То есть никаких сильно неправильных дел в базе нет и все это вполне обычно для работы одновлеменной многих пользователей.
Даст ли что переход на гигабитные хабы или это мелочь?
   Djelf
 
340 - 02.11.20 - 13:10
(339) ОМГ Клюшки по сетке это зло!
   tgu82
 
341 - 02.11.20 - 13:11
(34) В терминальном режиме. если б по сети до 40 юзеров - я б нобелеввку получил бы )))
   Djelf
 
342 - 02.11.20 - 13:18
(341) Лови архив V7dbnet https://cloud.mail.ru/public/C3fY/CWQwnhy5L
Это клиент-серверная база 1С 7.7 на dbf. Сайт у wirth давно сдох, но там внутри хорошее руководство по установке есть.
foxpro, если используется работать не будет, а 1sqlite будет.
Ну и что за проблема поднять терминал на 40 мест? Нынче память дешевая, и процы слишком быстрые.
   Djelf
 
343 - 02.11.20 - 13:19
А, в терминальном все таки! Неверно прочитал. Ну и чем тогда замена сетевой хабов поможет?
   Djelf
 
344 - 02.11.20 - 13:21
+(343) В терминальном очень сильно помогает патч FlushFileBuffers Книга знаний: Ускорение 1С:Предприятие 7.7
   tgu82
 
345 - 02.11.20 - 13:22
(343) Вот получается что ничем. Ладно. За неделю=другую соберу статистику в ЖР по времени проведения через _getperfomancecounter в начала и в конце обработки проведения и посмотрю что будет
   Mikeware
 
346 - 02.11.20 - 13:25
(339) у тебя ж терминальник. пофиг какой канал
   Mikeware
 
347 - 02.11.20 - 13:26
(340) (341)  ну у меня только на 85-м юзвере  затыкались.
   tgu82
 
348 - 02.11.20 - 13:33
(347) 50 с лишним бывало но до 85 как то не доходило)
   Mikeware
 
349 - 02.11.20 - 13:36
(348) а я так и не понял, почему. причем знаю, что у людей более сотни юзверей тогда было - и работало.Не победил, в общем. только обошел.
   Mikeware
 
350 - 02.11.20 - 13:37
+(347) наврал. 75
   tgu82
 
351 - 02.11.20 - 13:38
(344) Спасибо. Вроде не звморачивался, сейчас заморочился
   tgu82
 
352 - 02.11.20 - 14:06
(292) А как организовать очередь проведения документов - может было бы хорошо именно так.
В понедельник хотя бы - 
1. чеки ккм (с утра их немного)
2. рко и пко (с утра много, но там проведение наносек)
3. Поступление ТМЦ (вот здесь может быть много-много сторк и относительно много документов)
4............прочие
   tgu82
 
353 - 02.11.20 - 14:25
(352)+ Нет, лучше глянуть насчет времени проведения с записью события в жр и обработать те ошибки что обнаружил связанные с программными опреаицями над доп. документом в призаписи и в призакрытии "родительского документа"
   Mikeware
 
354 - 02.11.20 - 14:37
(352) анакуа тут очередь-то?
чеки проводятся когда вводятся, рко-пко тоже
Для поступления тмц и перемещений - можешь подготовить заранее элементы справочника ПартииТМЦ
   Djelf
 
355 - 02.11.20 - 15:07
(353) Я конечно понимаю что может быть уже проверил, но проц случаем не перегревается?
У меня как-то 3.3 на 1.6 троттлил... Не всегда все программно же решается.
   tgu82
 
356 - 02.11.20 - 15:11
(354) Заранее? Для постпуления тмц так и получается потому что их грузят моей универсальной обработкой из различного вида файлов (csv dbf xml txt xls) - получается что все кроме разбухтовки - готово. Затем разбухтовка и весь процесс завершен. Что касается перемщения - мысль интересная, но поскольку что-то корректируется задним числом то возможно партии эти поменяются и документ перепровести уже не удастся, надо либо на авто либо переподбирать партии. А так идея сокрашения времени проведения - очень даже здравая. Спасибо!
   Злопчинский
 
357 - 02.11.20 - 15:19
(352) "3. Поступление ТМЦ (вот здесь может быть много-много сторк и относительно много документов)
- в поступлениях шттано в ТИС нет ничего сложного. проводится практически мгновенно.
если ты только руками туда не понапихал всякой хрени типа разбухтовок каких нить..
   Злопчинский
 
358 - 02.11.20 - 15:20
(356) перемещения..? корректировать задним числом? нахуа?!
   tgu82
 
359 - 02.11.20 - 15:49
(357) Нет у меня вооблще разбухтовок в модулях проведения, есть только в ПриЗаписи чтоб в единой транзакции все было иможно было откатиться.
(358) Да потому что это перемещения с ЦС на магазины, и там есть куча всяких нюансиков поэтому приходится порой перепроводить их, там еще отдел перемещений дорабатывает иъ.
   tgu82
 
360 - 02.11.20 - 15:53
(357) Если ЖД заблокирован то значит кто-то его проводит хотя ПриЗаписи ведь записывает же и шапку и тч документа если он еще не был записан. Но все равно если блокировка значит в этот момент кто-то что-то проводит. Так ведь?
 
 Рекламное место пустует
   Злопчинский
 
361 - 02.11.20 - 15:56
(360) не обязательно проводит. открой DD и посмотри что в журнале общем полном написано по реквизитам.
   tgu82
 
362 - 02.11.20 - 15:59
(361) ну да
   Mikeware
 
363 - 02.11.20 - 16:09
(358) переместили-недопереместили-перепереместили... перемещали-перемещали, да не выпереместили...
   tgu82
 
364 - 02.11.20 - 16:50
(363) А что происходит в процедуре призаписи - там же явно сама пользовательская часть а ведь есть еще неявная системная. То есть пришем ЗАписать(). Это запись в базу данных. А призаписи и только когда интерактивное сохранение объекта - это как бы то что увенчивается самой записью в базу, все реквизиты тч и шапки раскидываются по своим таблицам
   tgu82
 
365 - 02.11.20 - 16:56
(364)+ То есть блокировка возможна когда запись идет процедурой записать() Но мне кажется что это очень короткая процедурка.
   Mikeware
 
366 - 02.11.20 - 17:04
(364) ПриЗаписи (которая вызывается при интерактивной записи) ничего не блокирует. просто заполняет реквизиты объекта (в памяти)
   tgu82
 
367 - 02.11.20 - 17:10
(366) Ага понял, но она же заканчивается хоть и неявно методом Записать()
   tgu82
 
368 - 02.11.20 - 17:41
В монопольном режиме но задним числом (в милисек)
Реализация  ЭлТД006710 (20.10.20) ВремяПроведения 3460
Вот еще
Реализация  ЭлТД006874 (23.10.20) ВремяПроведения 4033
Медленновато похоже
   tgu82
 
369 - 02.11.20 - 19:22
(368)+
Монопольный, новые 1 строка товара
Реализация  ЭлТД006879 (02.11.20) ВремяПроведения 55
Монопольный 2 строки
Реализация  ЭлТД006878 (02.11.20) ВремяПроведения 151
   tgu82
 
370 - 02.11.20 - 19:30
(369)+ Вывод понятен. Новая формируется в раз в 30 быстрее
   Злопчинский
 
371 - 02.11.20 - 20:44
(365) в Записать() собственно в самой - никаких блокировок нет. если ты только руками туда не вписал чтонить транзакционное (как у тебя с бухтами) (еще и см. выше хз как там у тебя отрабатывает разбухтовка при записи когда ты повтрно записываешь документ с уже ранее сделанной разбухтовкой)
   Злопчинский
 
372 - 02.11.20 - 20:47
(368) задним числом 4 секунды - это трэш адский. ткаое допустимо только в монопольном режиме в регламентых работах. у меня под 3-4 секунды реализации задним числом проводятся которые под несколько сотен строк... я сомневаюсь что у тебя в розниуе такие реализации ;-) поэтому заднее число УБИРАЙ НАФИГ. чем больше тем лучше. ситуация сразу станет на порядок легче. и манагеры у тебя тупо открыв документ в ззаднем числе на просмотр тупо жимут ОК. с перепроведением задним числом и всеми прелестями этого.
   tgu82
 
373 - 02.11.20 - 21:40
(372) А еще варианты? Не могу я отказаться от заднего числа.
Надо как-то оптимизировать запросы что ли в модуле проведения. Там еще высчитывается просрочка задолженности контрагента согласно условиям договора. А ведь это тоже запросы к регистру
   tgu82
 
374 - 02.11.20 - 21:42
(373)+ Не чистил все эти процедуры ибо они в-основном из типового ТИС взяты с добавлением своих как бы внешних нюансов
   Злопчинский
 
375 - 02.11.20 - 22:05
(373) " Не могу я отказаться от заднего числа." тотальный трындеж. полностью может и нет, но до уровня когда это перестанет быть проблемой - достаточно просто. надо это тупо сделать. и все.
   Злопчинский
 
376 - 02.11.20 - 22:06
(373) " Там еще высчитывается просрочка задолженности контрагента"
- с дуба рухнул? в типовой в модулях проведения никаких просрочек задолженнойтсей на рассчитывается.
   tgu82
 
377 - 02.11.20 - 22:09
(376) А это уже я сам вставлял наверное. Не помню. Буду смотреть раз такая хреновая ситуация. Но пусть проводится 3-4 сек, не так уж это и много. Хотя елси взять все доки которые хотят провести пользоватлеи до 9 утра - вот им времени получается и не хватает
   Злопчинский
 
378 - 02.11.20 - 22:10
(377) проблема не втом что им времени не хватает. проблема в том что они ломятся все массово. хотя это нахер не надо.
   tgu82
 
379 - 02.11.20 - 22:41
(378) А что - запретить им проводить? Что значит массово ломятся? Надо делать документ и они его делают, насчет того что перепроводят по ОК - да нет, просто закрывают и все.
   Ёпрст
 
380 - 02.11.20 - 23:07
читай (40) долго думай.
   Ёпрст
 
381 - 02.11.20 - 23:08
И да, запрещать кому-то чего-то.. это моветон
   tgu82
 
382 - 02.11.20 - 23:16
(380) В групповых обработках проведения втыкать счетчик на запись, допустим 20 попыток, в обработка исключения ловить, что если это ошибка блокировки журнала, например при транзакции, то долбить дальше.

1. Почему в групповых обработках проведения? Мне что не проводить документ после его записи интерактивно? А проводить групповой обработкой?
2. Как называется эта вот ошибка блокировки если я ее поймал в исключениях ?
20 попыток  без пауз? а если все-таки будет продолжаться тогда же надо чтобы отшибла транзакцию и всякая "грязь" чтоб не осталась.

Но главное конечно - это групповая обработка проведения. Что вы под этим в данном случае понимаете?
   Ёпрст
 
383 - 02.11.20 - 23:21
(382) если ты спрашиваешь об этом, то у тебя их нет.
   tgu82
 
384 - 02.11.20 - 23:34
(383) раз в квартал я делаю перепроводку базы.
Пожалуйста расшифруйте мне ваш пост (40)
   Ёпрст
 
385 - 02.11.20 - 23:39
(384) если ты не пользуешься групповыми обработками для изменения реквизитов документов, типа юниджорнал/ючойз/сетатрс и т.п, то тебе достаточно прочитать только первый абзац в (40). Всё.
   Злопчинский
 
386 - 03.11.20 - 01:06
(379) " насчет того что перепроводят по ОК - да нет, просто закрывают и все."
да, именно. просто закрывают. ПО КНОПКЕ ОК.
   hogik
 
387 - 03.11.20 - 03:40
(0)
Посмотрите мои «теоретические» :-) рассуждения тут: http://catalog.mista.ru/1c/articles/87339/
И сделайте рекомендации из сообщения (40) учитывая текст из (156) сообщения.
   tgu82
 
388 - 03.11.20 - 07:42
(385) Пользуюсь реплвал в-основном. Время Ожидания в ноль установлено везде.
Но вообще конечно 3-4 сек на проведение документа пусть и задним числом - это что-то до хрена.
(387) Смотрел. Обратил еще внимание на (156). Дело в том что я пользуюсь кажется solution6 (секретным релизом), который много всяких вопросов мне помог решить. Насчет кернел - надо глянуть. Я так понял что кернел33 обеспечивает только работу с дбф свыше 1 ГБ а кернел37 решает вопрос и 100% загрузки процессора при транзакциях и проблемы 1 ГБ.
   tgu82
 
389 - 03.11.20 - 07:51
(385) При работе под SQL проблемы транзакций пропадают или все равно дело в движке 1С?
   tgu82
 
390 - 03.11.20 - 08:03
(387) То есть мне надо DBEng32 Ваше себе установить? Заменить НачатьТранзакицю Попытка Исключение КонецПопытки ?
Ставить на проведение в очередь? Каким образом? При чем тут учойс сетатрс или униджорнал?
   tgu82
 
391 - 03.11.20 - 08:28
(387) А как мне понять теперь уже у меня кернел33 используется или кернел37?
Получается что если время ожидания в ноль то мне достаточно кернел33 для решения проблемы 1 ГБ?
   tgu82
 
392 - 03.11.20 - 08:46
(391) Получается что при установке времени ожидания в ноль - кернел37 избыточна?
   tgu82
 
393 - 03.11.20 - 10:39
Как и писал раньше - вторник, все тихо, ошибок транзакций и нет вовсе.
Но все равно хотелось бы управлять этим процессом.
   sdaf
 
394 - 03.11.20 - 11:00
всю ветку не читал, но в свое время победил тормоза отключением проведения по партиям, как правило они самые ресурсоемкие. По партиям ночью перепроводилось.
   Андрей_Андреич
 
395 - 03.11.20 - 11:01
(393) парочке юзеров в понедельник сдвинуть график на час и все
   tgu82
 
396 - 03.11.20 - 11:15
(395) Четвертьмеры. Просто не пойму как очередь проведения организовать. где проверять блокировку слуэжебного элемента?
В начале обработки проведения пробуем блокировать и елси не блокируется ставим в очередь или же просто гоняем цикл с проврекой блокировки в начале процедуры ОбработкаПроведения? Если я вошел в ОбработкаПроведения не значит ли это что все равно уже я пытаюсь проводить документ и блокироваать журнал ?
1. Беру первый документ за день и провожу его
пока он проводится, пытается проводиться второй документ, и он же ставится в какую-то "стековую очередь", если проведение первого еще не завершилась? Когда этот второй будет проводиться? И какой обработкой?
   АгентБезопаснойНацио
 
397 - 03.11.20 - 11:17
(396) нахрена множить сущности без необходимости?
   tgu82
 
398 - 03.11.20 - 11:17
(394) Давал провести с каким-то флагом? А обмен ведь тоже ночью с магазинами так можно и не успеть весь регламент отработать
   tgu82
 
399 - 03.11.20 - 11:19
(397) Подступает конец года, там цже и чеки не по 200 штук в день а по 350 начнут бить и реализаций будет много очень и поступлений к новому году ну и соответственно перемещений - может и стоит их умножить наконец-то?
   tgu82
 
400 - 03.11.20 - 11:21
(399) Да и что особенного, просто некая очередь массового обслуживания причем далеко не по всем видам документов. В очерередь попадут реализации поступления перемещения чекиккм списания оприходования ну документы по движению разбухтовки.
  1  2  3  4  5  6  7  8   

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