Группа: Пользователи
Сообщений: 65
Спасибо сказали: 0 раз
Рейтинг: 0
И снова здравствуйте!
Возник вопрос по оптимизации: Требуется при перепроведении документа максимально сократить запросы, расчёты, запись, изменения. Другими словами - обрабатывать только изменения в документе.
1. Многим, наверное, известна любимая кнопка оператора, бухгалтера - посмотрел в документ - "ОК"-ей... и перепроведение пошло. А зачем? Вот. 2. Исправления в комментарии документа запускают по "ОК"-йу полный цикл, несмотря на то, что в табличных частях ничего не поменялось. 3. Оператор, бухгалтер выписал что-то не то в одной из позиций документа, при этом, к тому же, для целей определения стоимости, были проведены запросы-расчёты себестоимости, одну позицию исправили, а перепроведение пересчитает, переспишет все позиции.
Суть задачи: 1. перед записью узнать объёмы повреждения производительности на сервере - вычислить изменения, заодно, в качестве полного лога, можно это и записать в ту же базу данных. Какой объект целесообразнее для этого использовать или возможно это сделать не выходя из рамок перепроводимого документа? 2. удалить неактуальные записи в регистрах. Возможно ли такое вообще, т.к. наборы записей читаются и пишутся, насколько мне известно, только целиком? 3. обработать изменения документа, запросы, расчёты только по нужным позициям - это, как бы, просто, да? 4. записать заново рассчитанные данные в регистры. Возможно, запись данных придётся делать только добавляя записи, возможно ли добавить набор записей, если в БД уже есть такой набор записей? почему бы нет, при очередном чтении получим старый набор плюс дописанный набор, или я не тут ваще?
Группа: Команда (модераторы)
Сообщений: 1116
Из: Одесса-Луганск
Спасибо сказали: 192 раз
Рейтинг: 0
1. В двух словах, нужно строить список изменений перед сохранением объекта, а обрабатывать сей список - При проведении. Потенциальные грабли находятся в случае если пользователь нажмёт Сохранить дважды перед проведением. 2. Нет. Очищается вся запись в регистре. Можно, конечно сравнивать старую запись с новыми данными, но дополнительное чтение данных из регистра не убьёт ли всю оптимизацию на корню? 3. см. п.1 4. Платформа не позволяет такой вольности.
В целом, снижение нагрузки на запись требует увеличения нагрузки на чтение. Телодвижений придется делать много, а будет ли выигрыш?
Правильно поставленный вопрос содержит до 90% ответа.
Группа: Пользователи
Сообщений: 65
Спасибо сказали: 0 раз
Рейтинг: 0
Цитата(bolobol @ 11.09.11, 19:23)
Суть задачи: 1. перед записью узнать объёмы повреждения производительности на сервере - вычислить изменения, заодно, в качестве полного лога, можно это и записать в ту же базу данных. Какой объект целесообразнее для этого использовать или возможно это сделать не выходя из рамок перепроводимого документа?
Цитата(pablo @ 12.09.11, 8:37)
1. В двух словах, нужно строить список изменений перед сохранением объекта, а обрабатывать сей список - При проведении. Потенциальные грабли находятся в случае если пользователь нажмёт Сохранить дважды перед проведением.
Сделано так: берётся сохранённая версия (ссылка.*, ссылка.ТабличнаяЧасть.*) и получается разница в новый документ. При этом блокирован, как я понимаю, только текущий документ? А проведённый документ при записи так же перепроводится, т.е. весь алгоритм отработается и при первой записи. Вот записывать многие очень часто любят - и это правильно, вдруг чё переглючит, а я работал...
Цитата(bolobol @ 11.09.11, 19:23)
2. удалить неактуальные записи в регистрах. Возможно ли такое вообще, т.к. наборы записей читаются и пишутся, насколько мне известно, только целиком?
Цитата(pablo @ 12.09.11, 8:37)
2. Нет. Очищается вся запись в регистре. Можно, конечно сравнивать старую запись с новыми данными, но дополнительное чтение данных из регистра не убьёт ли всю оптимизацию на корню?
Понял так: для получения набора записей, я не смогу установить отбор по регистратору и остальным реквизитам для получения одной записи, соответствующей удалённой строке документа. Да? Старый набор записей читать придётся, т.к. в худшем случае - этот набор записей будет основанием для новой записи, но до тех пор, пока я не собираюсь корректировать этот набор записей (идёт анализ изменений) - блокировка итогов не нужна - в этом ожидается первый плюс. Блокировка итогов регистра начнётся только по факту расчёта на основании этого же регистра новых движений или вообще - только по факту записи. А перерасчёт - это, как правило, 5% документа, что в 20 раз сокращает необходимые блокировки на время расчёта и проверок отрицательных итогов там... А вот запись всего набора - как раз пугает потерей всего выигрыша. Но ведь новый документ (документ корректировки) записывает данные только на саму корректировку в регистры, вот и думается - почему бы не установить отбор при создании дополнительного набора записей настолько узким, чтобы не задев при очистке в регистре по установленному отбору в нём существующие записи других строк документа?
Цитата(bolobol @ 11.09.11, 19:23)
4. записать заново рассчитанные данные в регистры. Возможно, запись данных придётся делать только добавляя записи, возможно ли добавить набор записей, если в БД уже есть такой набор записей? почему бы нет, при очередном чтении получим старый набор плюс дописанный набор, или я не тут ваще?
Цитата(pablo @ 12.09.11, 8:37)
4. Платформа не позволяет такой вольности.
Тут нужно мне пример привести для полного понимания ограничений платформы: Возьмём регистр из бухгалтерии (испытательный полигон, как самая незагруженная конфа): ВзаиморасчетыСРаботникамиОрганизаций: Отбор устанавливается по: Регистратор, Физлицо, Организация, ПериодВзаиморасчётов - что дострочно по документу отражает движение. В документе три Физлица, изменилось только Физлицо2 - уменьшилась сумма в два раза. Установив отбор по Физлицу2, заполнив новыми значениями и записав - получаем удаление прошлой записи в регистре по Физлицу2 и запись нового значения. Или я не правильно что-то понимаю? Или есть другие ограничения?
Цитата(pablo @ 12.09.11, 8:37)
В целом, снижение нагрузки на запись требует увеличения нагрузки на чтение. Телодвижений придется делать много, а будет ли выигрыш?
Выигрыш должен быть во времени блокировки данных. Чтение данных из регистра по тому документу, который проводим, не приводит к появлениям блокировок, т.к. кроме нас, никто другой не может менять этот документ. А вот запись 5-ти% новых движений должно существенно сокращать возникающие с этим блокировки, по сравнению с полной перезаписью. Или как?
Группа: Команда (модераторы)
Сообщений: 1116
Из: Одесса-Луганск
Спасибо сказали: 192 раз
Рейтинг: 0
Насколько я знаю, при чтении вообще не должно возникать блокировок данных.
Цитата
ля получения набора записей, я не смогу установить отбор по регистратору и остальным реквизитам для получения одной записи, соответствующей удалённой строке документа. Да?
Отбор установить можно и получить старые запись(записи). Можно даже через Движения добавлять/удалять нужные без дополнительного поиска. Вот только при использовании Движений будут ли старые записи заново помещаться в регистр?
Правильно поставленный вопрос содержит до 90% ответа.
Возник вопрос по оптимизации: Требуется при перепроведении документа максимально сократить запросы, расчёты, запись, изменения. Другими словами - обрабатывать только изменения в документе.
1. Многим, наверное, известна любимая кнопка оператора, бухгалтера - посмотрел в документ - "ОК"-ей... и перепроведение пошло. А зачем? Вот.
Подивіться ще в методичку 8.2 Решение оперативных задач п.3.8. Правда там механізм реалізовний на регістрах накопичення, в бух-ії - по аналогії.
Группа: Пользователи
Сообщений: 65
Спасибо сказали: 0 раз
Рейтинг: 0
Цитата(mister-x @ 12.09.11, 11:08)
Подивіться ще в методичку 8.2 Решение оперативных задач п.3.8. Правда там механізм реалізовний на регістрах накопичення, в бух-ії - по аналогії.
Курим, восполняем
Цитата(Ardi @ 12.09.11, 11:10)
Сколько пользователей в каждой базе? Сколько документов в день?
Пользователей около 20-ти, документов в день не много, проводятся они, как правило, перед обедом и перед уходом. Такие два пика. Очень много исправлений - вот в чём загвоздка. В результате перепроведений старых - тормозится весь сервер, а ночью ещё и перепроведение всех от первого старого нужно перепроводить, меняется себестоимость во всех документах, бухгалтерия плачет, что у них опять всё поменялось. основная задача - изменился один документ - как не перепроводи остальные - по ним ничего не меняется, даже расчёт себестоимости (это для примера). А за ночь, восстановиться вся последовательность не успевает, т.к. ещё и бухгалтерия завязана, в которую должны поступать изменённые данные. Вот это всё и нужно изничтожить. Разумеется, не давая возможности корректировки закрытых кварталов.
Цитата(mister-x @ 12.09.11, 11:08)
Подивіться ще в методичку 8.2 Решение оперативных задач п.3.8. Правда там механізм реалізовний на регістрах накопичення, в бух-ії - по аналогії.
Во, блин... у меня книжка без пункта 3.8. Есть известные ссылки на новую литературу?
Группа: Команда
Сообщений: 3568
Из: Киев
Спасибо сказали: 1434 раз
Рейтинг: 0
Цитата
основная задача - изменился один документ - как не перепроводи остальные - по ним ничего не меняется, даже расчёт себестоимости (это для примера).
В таком случае нужно забыть про типовое восстановление последовательности и делать своё - в разрезе документов и номенклатуры (серии, характеристики). Провели задним числом документ - перепроводим все последующие документы где участвует номенклатура изначально проведенного документа.
Помимо всего прочего, лично я бы посоветовал автору провести аудит соответствия железа нагрузочной потребности!!!
8.х платформа достаточно оптимизирована (ну почти! ), так-что вопрос может быть не в программной оптимизации (весьма трудоемкой операции!), а просто сделать "апгрейд" железа - ибо дешевле выйдет.
----------------------------------------------------------------------------------- Единственный, интуитивно понятный интерфейс - мамкина сиська! Всему остальному надо учиться! (с) Не знаю кто....
Группа: Пользователи
Сообщений: 65
Спасибо сказали: 0 раз
Рейтинг: 0
Цитата(Batchir @ 12.09.11, 13:45)
В таком случае нужно забыть про типовое восстановление последовательности и делать своё - в разрезе документов и номенклатуры (серии, характеристики). Провели задним числом документ - перепроводим все последующие документы где участвует номенклатура изначально проведенного документа.
Вот в этом случае - оперативная работа никак не поменяется, а указанный анализ при восстановлении последовательности (аналитически) только затормозит процесс перепроведения. Ди и к тому же - номенклатура одна и та же везде, и выигрыш от пропуска 5-ти-10-ти процентов документов не оправдает анализа, который и так не понятно как и делать-то.
Цитата(DartRomanius @ 12.09.11, 14:52)
Помимо всего прочего, лично я бы посоветовал автору провести аудит соответствия железа нагрузочной потребности!!!
8.х платформа достаточно оптимизирована (ну почти! ), так-что вопрос может быть не в программной оптимизации (весьма трудоемкой операции!), а просто сделать "апгрейд" железа - ибо дешевле выйдет.
Железо в порядке, пиковая загрузка показывает изнасилованность дисковой системы, которую и не улучшишь за приемлемые средства. А три миллиона - это несколько больше, чем зарплата программистам за обозначенную задачу.
Цитата(Ardi @ 12.09.11, 21:05)
При ночном перепроведении никаких блокировок не возникает.
А днем такие сильные тормоза???
Зачем перепроводить весь квартал каждый раз??? Менеджеры перепроводят отгрузки сделанные 2 месяца назад? Запретить. Оставить неделю.
В бухгалтерию переносится себестоимость из упр. базы??? Что за себестоимость такая?
Перепроведение осуществляется за период от закрытого квартала, а это до 3-х месяцев + 20 дней до НДС. Тут уж некуда уменьшать. Месяц отпуска, месяц переговоров до исправления... А где два, там и четыре. Рабочим процессам, связанным с налоговой отчётностью надо не мешать, а помогать )) Себестоимость в бухгалтерию не переносится, а из-за изменения документов, из-за перевыгрузок - пересчитывается.
Суть в чём - приходный документ, записанный задним числом, заставит все списания передвинуться на этот документ, таким образом, списания нужно фиксировать по партии в самом документе. Значит, при перепроведении, если эта партия изменилась (в ней стала другая себестоимость), то и документ реализации тоже должен поменять себестоимость. Перепроводя документ с уменьшением количества приходный или с увеличением расходный - потребуется проверить остатки по этой партии, чтобы никогда не уйти в минус. Когда необходимо уйти в минус - потребуется перепроведение других документов расхода по этой партии и заменять при проведении партию (это, наверное, можно сделать используя последовательности и реквизиты... там же есть реквизиты(?) - партию и номенклатуру). Всё это можно делать ночью, днём необходимо контролировать только наличие остатка в принципе и, перепроводя задним числом натыкаемся на ситуацию:
Можно задним числом списать 13 шт. (они есть в остатке). Спишем их Расходом3 между Приход1 и Расход1 (они есть в остатке на тот момент), на сегодня будет ноль, но списание по партии ночью не сможет провестись! Нельзя также Расход3 сделать на 15, хоть остаток 15 и есть на тот момент, но на сегодня - всего 13. Поэтому нельзя опрашивать остатки только на момент проведения. Можно и увеличить Расход1 только на 10 шт. (в остатке есть на тот момент +10, а если смотреть на сегодня, то +13) - этот пример показывает, что нельзя остатки проверять только по наличию на сегодня.
Итого: Необходимо при перепроведении/вводе документа задним числом иметь партионное списание, остатки на сегодня в разрезе партии. Необходимо и достаточное условие. Проверять остаток на момент проведения по данной партии нет необходимости.
Значит, анализ изменённых позиций, перепроведение без проверки остатков, если кол-во уменьшено, проверка по партиям, если кол-во увеличилось/появилось новая номенклатура.
Группа: Команда
Сообщений: 3568
Из: Киев
Спасибо сказали: 1434 раз
Рейтинг: 0
Сначала нужно избавиться от всех проведений которых не должно быть:
1.
Цитата
Многим, наверное, известна любимая кнопка оператора, бухгалтера - посмотрел в документ - "ОК"-ей... и перепроведение пошло. А зачем? Вот.
Проверка на модифицированность объекта вам в помощь
2.
Цитата
Исправления в комментарии документа запускают по "ОК"-йу полный цикл, несмотря на то, что в табличных частях ничего не поменялось.
я когда-то делал так: блокировал комментарий, добавил спец кнопку, при нажатии которой открывалось окно ввода текста, при закрытии устанавливал комментарий и записывал документ без перепроведения. Но делал так потому что обычные пользователи могли только одни раз провести документ, после чего он был доступен только на просмотр, а комментарий редактировать нужно было.
3.
Цитата
Оператор, бухгалтер выписал что-то не то в одной из позиций документа, при этом, к тому же, для целей определения стоимости, были проведены запросы-расчёты себестоимости, одну позицию исправили, а перепроведение пересчитает, переспишет все позиции.
Думаю это основная причина, а все предыдущие - предисловие. Прошу озвучить конкретные причины того почему редактируются (создаются) приходные документы задним числом и уже эти причины будут анализироваться что бы что-то Вам посоветовать.
А так пока вижу: 1. Избавиться от проведений-паразитов 2. Контроль остатков задним числом при проведении документа 3. Своя обработка восстановления последовательности.
Группа: Пользователи
Сообщений: 65
Спасибо сказали: 0 раз
Рейтинг: 0
А что за фокус такой, сообщение от меня есть, но при просмотре форума - оно пустое, а при ответе - весь текст его видно??
Спецы - ХЕЛП!
Ничего не понимаю - теперь я вижу сообщение своё со всем текстом, как и вчера...
Цитата(Batchir @ 15.09.11, 8:59)
Сначала нужно избавиться от всех проведений которых не должно быть: 1. Проверка на модифицированность объекта вам в помощь
Это я вычисляю перед записью - Беру Документ и Документ.Ссылка - сравниваю - получаю новый документ того же типа с изменениями. Сейчас знакомлюсь плотнее с платформой по ссылке на доку по 8.2, где рассказываются способы использования временных таблиц в менеджерах документов, регистров - буду думать, куда воткнуть.
Цитата(Batchir @ 15.09.11, 8:59)
2. я когда-то делал так: блокировал комментарий, добавил спец кнопку, при нажатии которой открывалось окно ввода текста, при закрытии устанавливал комментарий и записывал документ без перепроведения. Но делал так потому что обычные пользователи могли только одни раз провести документ, после чего он был доступен только на просмотр, а комментарий редактировать нужно было.
Данное становится неактуальным, в следствии проверки изменённости документа, т.к. обращений, насколько я понимаю, к базе данных для сверки с записанной информацией не происходит, она же у же была считана, но, с другой стороны, документ могут открыть два пользователя и начать менять, вот когда блокировка его начинается - понять не могу, но в какой-то момент платформа отказывает одному из пользователей из-за того, что версия документа устарела - ещё буду проверять. Но сравнение Документ с Документ.Ссылка в теории приводит к перечитыванию данных с базы? Как упростить? Ведь не только комментарий не изменяет данные проведения - там ещё кучка реквизитов.
Цитата(Batchir @ 15.09.11, 8:59)
3. Думаю это основная причина, а все предыдущие - предисловие. Прошу озвучить конкретные причины того почему редактируются (создаются) приходные документы задним числом и уже эти причины будут анализироваться что бы что-то Вам посоветовать.
Причины? Вы меня удивили )) Я один что ли такой реалист? Информационная система предназначена для облегчения работы пользователей, то есть - не должна заставлять работать правильно. Должна быть дружелюбной )) Причины: - Документ забыли ввести. Здесь ясно - списание с него начнётся тогда, когда его всё-таки введут, а найдёт его отсутствие, как только чего-то не смогут списать, что присутствует фактически. - Поставщик отказался менять брак - заменил документы, т.к. менять товар не на что - это долгий процесс. - Оператор по вводу документов ошибся - всякого рода косяки - номенклатура/количество На текущий момент всё это решается корректировками, но тот же акт сверки - очень нагруженный обработками сверок... Другие отчёты, которые лопатят дополнительный объём данных, обмен с объединением документов с корректировками для бухгалтерии - это всё очень сложно и для пользователя в том числе.
Группа: Основатель
Сообщений: 13981
Из: Киев
Спасибо сказали: 4549 раз
Рейтинг: 3678.1
Цитата
Информационная система предназначена для облегчения работы пользователей, то есть - не должна заставлять работать правильно. Должна быть дружелюбной ))
Информационная система должна на входе принимать, а на выходе выдавать определённые данные - это всё, что она должна. Больше она никому ничего не должна. И если надо делать действия А, Б, В то значит надо делать действия А, Б и В, а не действие Г и получать при этом кучу Г на выходе, которое потом разгребать и плеваться в сторону системы.
Группа: Пользователи
Сообщений: 65
Спасибо сказали: 0 раз
Рейтинг: 0
Цитата(Vofka @ 15.09.11, 20:52)
Информационная система должна на входе принимать, а на выходе выдавать определённые данные - это всё, что она должна. Больше она никому ничего не должна. И если надо делать действия А, Б, В то значит надо делать действия А, Б и В, а не действие Г и получать при этом кучу Г на выходе, которое потом разгребать и плеваться в сторону системы.
Полностью согласен, кто ж с этим спорить-то будет. Вопрос-то в другом - на входе Г, а разложить его нужно на А, Б и В _автоматически_, а не заставлять пользователей ждать и догонять, кучу времени на вводы документов убивать. Автоматизация - это процесс замены рутинных операций человека на машинное исполнение.
Но, покурив ещё методичку по 8.2 - дошло и следующее, что при мною озвученной задаче - процесс пересписания никогда не наступит, т.к. при перепроведении - документ не меняется. Поэтому, в методичке и озвучен универсальный алгоритм, лишённый преимуществ перепроведения без изменения самого документа, но универсальный.
Так же, вижу что тема уходит от конкретных вопросов, но и сами вопросы меняются по мере осознания темы ))
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!