Проведение будущей датой

процесс сервера пухнет из-за каких-то сеансов? Причем там вообще состояние записанных в базу каких-то объектов, зачем объектам память сервера, если они уже в базе?

А насколько будущая эта дата? Если в 28м веке - то запросто может. Если в этом году, то не из-за этого.

То, что рпхост пухнет - это можно считать утечка памяти, а не состояние конкретно записываемых в базу при перепроведении объектов.

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

Ну понятно, что ночью не формируют отчеты... А если формируют? И как раз в что при формировании отчетов, что при получении временных таблиц в перепроведении документов используются одинаковые запросы?

А давайте вообще не будем к базе запросы выполнять, чтоб память не пухла!!!

(0) не вижу связи будущей даты и распуханием процесса.

(3) может ты это обьяснишь?

Насколько оправдана "необходимость" проводить будущей датой вопрос не задавать?

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

Но проблема точно не в том, что дата документов установлена куда-то не туда

(7) А какая разница, если в конфиге есть некоторое количество функционала, который не учитывает дату документа при проведении в оперативном режиме, например

(0) В УПП такого вроде не наблюдал. А в ERP было.

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

(9) ну, оперативные остатки в несколько раз быстрее, чем неоперативные. Может с этим свезано? Раньше процесс длился 5 минут, а теперь 105 минут.

(7) например, реализации готовятся с вечера на утреннюю отгрузку

(7) например я знаю что событие будет отражено некоторой датой и сразу даю вводить людям эту дату. Это же в 1с связали дату документа с датой отражения события.

(12) Ну... если идти по этому рассуждению, то тогда любой массовое перепроведение документов с любой датой (что прошлой, что настоящей, что будущей) должно стартовать с принудительным неоперативным - всегда. И тогда при любом выполнении такой процедуры должна утекать оператива рпхоста

Это будет именно свойство конкретной используемой платформы, а не разрешенных "будущих дат" в конкретной использованной базе/конфигурации УПП 1.3

(13) я понимаю что почти 100% в это упирается. У нас выписка начинается в 0-00

(14) какой в этом глобальный смысл? Почему нельзя сделать во время?

(15) итоги бывают оперативные и помесячные. Если дата в середине месяца, то документ проводится в несколько раз дольше, потому что остатки берутся не по таблице итогов, а по реальной таблице регистра. То есть берутся итоги на 1-е число и прибавляются обороты внутри месяца.

(18) ну потому, что вовремя - это когда служба обрабатывает документ (это как раз момент даты документа), а момент события может быть лююой.
Например у меня аренда .. и расторжение вводят в тот момент когда договор оформляют .. т.е. вводят и заключение и расторжение сразу, а не когда оно случится. А когда оно случится ? Это обход по какому то списку .. а так просто уже все в базе заведено

(18) А зачем ждать? Вот возьмет заказы покупателей. Есть заказ на декабрь. Логично его ввести декабрьской датой. Потому что потом любой валенок установив в декабре отбор по периоду "Декабрь 2020" увидит все заказы на декабрь. Это во-первых. Во-вторых, при планирование закупок под заказ надо начинать еще в сентябре, так что заказ на декабрь должен быть уже проведен в сентябре.

(21) С датами заказов была прикольная штука...
Говорят мне "выведи дату заказа"... Вывожу.
После долгих разборов выяснилось, что им надо дату создания (!!!) заказа ))))

(19) и что, это объяснение какое-то ноу-хау, из-за которого "течет память" у рпхоста?

з.ы. я знаю всю такую арифметику для первоклассников :-)

у нас то же раньше на 32 текла .. а на 64 внезапно перестала. Всего то внесли 50 тысяч 1с.

(24) Она не перестала течь. Просто ёмкость, куда вытекает - увеличилась ))

(21)  А зачем ждать?/// Я понимаю что с арендой (теоретически) можно не ждать, но почему можно не ждать с валенками... да делайте что хотите, инвентаризации, я так понимаю, не интересуют

64-32 ~ 50 ре

(23) это я не знаю. Но тот факт что процесс находится в памяти на 2 часа больше, это может и есть утечка

(25) у меня последние год когда было принято решение с 32 на 64 переходить внутри периодов когда бухгалтер рисовал ндс ..сервер надо было раз в день гасить ..
а вот с тех пор как поменял .. то сервер гасился только вместе с электричеством

(21) заказ на декабрь должен быть уже проведен в сентябре/// на проведение заказа нет ограничения

(26) Да какая собственно разница. Есть дата документа, а есть дата события которое этот документ отражает. Они могу быть не равны. Когда 1с запустила одну дату она конечно все сильно упрастила .. но вот сейчас во взаиморасчетах в онлайне ты можешь наслаждаться как она изгаляется ..
а я могу тебе так сказать ..мы например за месяц до события уже считаем что нам денег должны .. прикинь какой у меня угар с датами ..

(29) Так я и говорю - места под утечки больше.

(26) у меня заказ на 24 число. Вывоз начинается в 2 часа ночи 24 числа в объеме нескольких десятков машин. Когда документы готовить бухгалтерии? Поэтому они и готовятся 23 числа, но отражаются 24, т.к. по факту все происходит 24

(32) может быть, но мне за поиск утечек не платят. А 50 тысяч ре сняло все проблемы в организации.

(31) за месяц до события уже считаем что нам денег должны .. прикинь какой у меня угар с датами ../// угара быть не должно :) расчет дз по заказам -- штатный

33) Когда документы готовить бухгалтерии/// я тут не советчик. Не вижу необходимости эти доки готовить бухам

(36) Правильно! Не бушное это дело - готовить бухгалтерские документы! Пусть сторож оформляет!

(36) ты не понимаешь: речь не о том, кто конкретно готовит, а о том, что их физически невозможно подготовить в момент отгрузки, без задержки оной. Именно поэтому они готовятся заранее

(37) ой, вы у них всё забрали давно и объявили не нужными, а операторская работа вдруг резко стала бухгалтерской.
ЗЫ. У меня сотрудники, которые работают в ночь и оформляют отгрузочные документы называются бухгалтерами, но скорее это только формальное название.

(35) в заказах насколько я помню уже фигурирует две даты, и я давно не сижу на товарном учете что бы точно сказать что там .. но все сводится к простой формуле...хозяин заказывает музыку.
Вот например акты , мы их готовим в следующем месяце но дата у них конец месяца. Но , я после 15 числа текущего месяца мог бы сделать 90 процентов актов за месяц, но дата все равно конец месяца. Т.е. у меня дата ввода вообще никак не влияет на дату акта. Он почти всегда на конец месяца.

(38) заявки сделаны заранее, с их автоматической обработкой на "десяток машин" нужно max час

(41) ой все

(42) сегодня была 61 машина

(43) в каждой машине по сколько клиентов?

(44) по разному. В зависимости от маршрута

(41) А что, у вас никогда машины не грузятся "с ленты в кузов"?

(46) с производственной ленты? Вроде нет... Всё же через камеру складскую
+(45) от 1 до 20

(47) значит молодцы. Но у вас есть специальные кладовщики-бухгалтеры ))

(47) Ну, у нас было такое. Продукция транзитом практически с ленты в кузов. Кладовщики пикнут сканером и алга, в кузов. И это в 4-30 утра. А в 4-40 машина должна выйти. И лучше немного недогрузим, чем задержим приезд машины к клиенту. А там, если не в 4-40 выехать, а в 4-50 - по железке идёт сапсан и переезд закрывается на полчаса минимум )))

(49) ну у нас кто-то и ещё раньше должен выехать... хуже то, что некоторые сети хотят до 23 иметь возможность корректировки заказа...

(48) и 1 контрагент <> одна накладная :)

(30) С датой документа будущей датой? И давно отменили?

(37) Угу, а если что-то пойдет не так - звонить кому будут? В лучшем случае позвонят сразу 1Снику. Но скорее всего сотрудник позвонит своему начальнику, который выдернет из постели начальника 1Сника. Ну а в худшем случае он пойдет по вертикали до общего начальника логистов и ИТ... и наутро все выслушают какие все вокруг <censored>.

(53) "если что-то пойдет не так" - то не так пойдут они. Согнувшись. И далеко.

(54) смотря что куда пойдёт и по какой причине. А поднимут всех :)
Вот с маркировкой я не знаю что будет... :( Мы протестировали, одну машину грузили 3 часа :)))

(52) не поняла

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

(56) Заказ на январь сделать датой 01.01.2021 и провести.

(57) Почему из-за системы? Система работает стабильно.

(57) кто же товар в заказ добавляет после того как он обработан)

(59) Да потому что пользователи разбудили начальство, что неправильно. Там причина уже не важна, если это выйдет дальше начальника 1Сника. Это же его задача, чтобы вышестоящих начальников не грузили проблемами.

(60) А где написано, что нельзя? ;) А логисты в заказе постоянно пасутся, потому что там обеспечение надо менять, чтобы что-то отгрузить. И клиенты постоянно хотят поменять заказ.

(57) ИМХО, в данном случае - я на стороне 1С.
Ты попробуй в чек "добавить, после того, как он пробит.

(62) Вот именно что не получится. А с заказом - получается.

(61) же его задача, чтобы вышестоящих начальников не грузили проблемами/// у диспетчера три телефона по которым нужно сообщить о нештатной ситуации.

А где написано, что нельзя?/// А что можно, написано? Впрочем, думаю что где то написано

(64) Если не написано, что нельзя - значит можно (С)
(я люблю говорить, что эта фраза из американских инструкций к бытовой технике :)))))) )

(58) почему его нужно сделать именно этой датой? Что за подтасовки? :) Дата заказа, вот когда делаешь заказ, тогда и дата, а отгрузка по этому заказу хоть в следующем веке

(61) я еще в 2005 году на 7 ке у себя в базе писал что если заказ дошел до склада .. то уже нельзя. Но с тех пор в товар не лезу .. не думал, что такой ужас .. с изменением заказов по которым началась отгрузка возможен в 20 году))

(67) не хватает Джинна. Он бы быстро научил Родину (зачеркнуть) 1 С любить.

(64) А теперь представь: 1Сник не разобрался в отведенное время - и звонки пойдут наверх. Что в принципе невозможно, если документы уже сделаны заранее.

(66) Чтобы потом в январе установить отбор по периоду "Январь 2021", и в списке остались только заказы, которые поставляются в январе 2021. Так-то некоторые клиенты вообще на год вперед могут заказать поставку.

(67) Там еще веселее - чтобы отгрузить товар, надо поменять реквизит в строке заказа и перепровести документ. Т.е. правка заказов производится постоянно.

(69) (70) Автоматизация бардака приводит к автоматизированному бардаку (С)

(70) ну, да ..я помню, что там надо переставить статус готовности к отгрузке. В принципе оно нормально пока кто-то не лезет править сам документ , а не статусы. Ну допустимая гибкость присутствует .. все остальное на усмотрение руководства .. например оставить все без контроля и жестокое анальное карание за любые ошибки)

(71) Так если январский заказ в январе - это же порядок :) Бардак будет, если январский заказ в мае будет. Его, во-первых, сначала найти надо. А при отключенном отборе по периоду народ, бывает, год заказа путает. Может отгрузить заказ на будущий год в текущем году, например.

(72) Проблема в том, что начальнику при каждом эскалированном инциденте потом прилетает. А они это не любят.

(73) ну когда одни не любят других но продолжают отношения то это называется садо мазо - тут самое главное свою роль точнее определить)

(74) Это я к тому, что не прокатит наказание за ошибки. 1Снику предпишут поставить ограничитель, чтобы такая ошибка не могла произойти. Ну а дальше уже насколько у 1Сника фантазии хватит.