[bolobol]

И снова здравствуйте!

Возник вопрос по оптимизации: Требуется при перепроведении документа максимально сократить запросы, расчёты, запись, изменения. Другими словами - обрабатывать только изменения в документе.

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

Суть задачи:
1. перед записью узнать объёмы повреждения производительности на сервере - вычислить изменения, заодно, в качестве полного лога, можно это и записать в ту же базу данных. Какой объект целесообразнее для этого использовать или возможно это сделать не выходя из рамок перепроводимого документа?
2. удалить неактуальные записи в регистрах. Возможно ли такое вообще, т.к. наборы записей читаются и пишутся, насколько мне известно, только целиком?
3. обработать изменения документа, запросы, расчёты только по нужным позициям - это, как бы, просто, да?
4. записать заново рассчитанные данные в регистры. Возможно, запись данных придётся делать только добавляя записи, возможно ли добавить набор записей, если в БД уже есть такой набор записей? почему бы нет, при очередном чтении получим старый набор плюс дописанный набор, или я не тут ваще?

В общем, кто что знает - поделитесь(?)

[Ardi]

Что нам стоит Artificial intelligence построить.

[bolobol]

Что нам стоит Artificial intelligence построить.

Не понял? Интеллект требуется на этапе разработки, или это намёк на обращение к многоуважаемому All?

[pablo]

1. В двух словах, нужно строить список изменений перед сохранением объекта, а обрабатывать сей список - При проведении. Потенциальные грабли находятся в случае если пользователь нажмёт Сохранить дважды перед проведением.
2. Нет. Очищается вся запись в регистре. Можно, конечно сравнивать старую запись с новыми данными, но дополнительное чтение данных из регистра не убьёт ли всю оптимизацию на корню?
3. см. п.1
4. Платформа не позволяет такой вольности.

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

[bolobol]

Суть задачи:
1. перед записью узнать объёмы повреждения производительности на сервере - вычислить изменения, заодно, в качестве полного лога, можно это и записать в ту же базу данных. Какой объект целесообразнее для этого использовать или возможно это сделать не выходя из рамок перепроводимого документа?

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

Сделано так: берётся сохранённая версия (ссылка.*, ссылка.ТабличнаяЧасть.*) и получается разница в новый документ. При этом блокирован, как я понимаю, только текущий документ? А проведённый документ при записи так же перепроводится, т.е. весь алгоритм отработается и при первой записи. Вот записывать многие очень часто любят - и это правильно, вдруг чё переглючит, а я работал...

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

2. Нет. Очищается вся запись в регистре. Можно, конечно сравнивать старую запись с новыми данными, но дополнительное чтение данных из регистра не убьёт ли всю оптимизацию на корню?

Понял так: для получения набора записей, я не смогу установить отбор по регистратору и остальным реквизитам для получения одной записи, соответствующей удалённой строке документа. Да?
Старый набор записей читать придётся, т.к. в худшем случае - этот набор записей будет основанием для новой записи, но до тех пор, пока я не собираюсь корректировать этот набор записей (идёт анализ изменений) - блокировка итогов не нужна - в этом ожидается первый плюс. Блокировка итогов регистра начнётся только по факту расчёта на основании этого же регистра новых движений или вообще - только по факту записи. А перерасчёт - это, как правило, 5% документа, что в 20 раз сокращает необходимые блокировки на время расчёта и проверок отрицательных итогов там... А вот запись всего набора - как раз пугает потерей всего выигрыша. Но ведь новый документ (документ корректировки) записывает данные только на саму корректировку в регистры, вот и думается - почему бы не установить отбор при создании дополнительного набора записей настолько узким, чтобы не задев при очистке в регистре по установленному отбору в нём существующие записи других строк документа?

4. записать заново рассчитанные данные в регистры. Возможно, запись данных придётся делать только добавляя записи, возможно ли добавить набор записей, если в БД уже есть такой набор записей? почему бы нет, при очередном чтении получим старый набор плюс дописанный набор, или я не тут ваще?

4. Платформа не позволяет такой вольности.

Тут нужно мне пример привести для полного понимания ограничений платформы:
Возьмём регистр из бухгалтерии (испытательный полигон, как самая незагруженная конфа):
ВзаиморасчетыСРаботникамиОрганизаций:
Отбор устанавливается по:
Регистратор, Физлицо, Организация, ПериодВзаиморасчётов - что дострочно по документу отражает движение.
В документе три Физлица, изменилось только Физлицо2 - уменьшилась сумма в два раза.
Установив отбор по Физлицу2, заполнив новыми значениями и записав - получаем удаление прошлой записи в регистре по Физлицу2 и запись нового значения. Или я не правильно что-то понимаю? Или есть другие ограничения?

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

Выигрыш должен быть во времени блокировки данных. Чтение данных из регистра по тому документу, который проводим, не приводит к появлениям блокировок, т.к. кроме нас, никто другой не может менять этот документ. А вот запись 5-ти% новых движений должно существенно сокращать возникающие с этим блокировки, по сравнению с полной перезаписью. Или как?

[pablo]

Насколько я знаю, при чтении вообще не должно возникать блокировок данных.

ля получения набора записей, я не смогу установить отбор по регистратору и остальным реквизитам для получения одной записи, соответствующей удалённой строке документа. Да?

Отбор установить можно и получить старые запись(записи). Можно даже через Движения добавлять/удалять нужные без дополнительного поиска. Вот только при использовании Движений будут ли старые записи заново помещаться в регистр?

[mister-x]

Возник вопрос по оптимизации: Требуется при перепроведении документа максимально сократить запросы, расчёты, запись, изменения. Другими словами - обрабатывать только изменения в документе.

1. Многим, наверное, известна любимая кнопка оператора, бухгалтера - посмотрел в документ - "ОК"-ей... и перепроведение пошло. А зачем? Вот.

Подивіться ще в методичку 8.2 Решение оперативных задач п.3.8. Правда там механізм реалізовний на регістрах накопичення, в бух-ії - по аналогії.

[Ardi]

Сколько пользователей в каждой базе?
Сколько документов в день?

[bolobol]

Подивіться ще в методичку 8.2 Решение оперативных задач п.3.8. Правда там механізм реалізовний на регістрах накопичення, в бух-ії - по аналогії.

Курим, восполняем

Сколько пользователей в каждой базе?
Сколько документов в день?

Пользователей около 20-ти, документов в день не много, проводятся они, как правило, перед обедом и перед уходом. Такие два пика. Очень много исправлений - вот в чём загвоздка. В результате перепроведений старых - тормозится весь сервер, а ночью ещё и перепроведение всех от первого старого нужно перепроводить, меняется себестоимость во всех документах, бухгалтерия плачет, что у них опять всё поменялось. основная задача - изменился один документ - как не перепроводи остальные - по ним ничего не меняется, даже расчёт себестоимости (это для примера).
А за ночь, восстановиться вся последовательность не успевает, т.к. ещё и бухгалтерия завязана, в которую должны поступать изменённые данные. Вот это всё и нужно изничтожить. Разумеется, не давая возможности корректировки закрытых кварталов.

Подивіться ще в методичку 8.2 Решение оперативных задач п.3.8. Правда там механізм реалізовний на регістрах накопичення, в бух-ії - по аналогії.

Во, блин... у меня книжка без пункта 3.8. Есть известные ссылки на новую литературу?

[pablo]

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

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

[mister-x]

Во, блин... у меня книжка без пункта 3.8. Есть известные ссылки на новую литературу?

шукаємо в Литература, ссылки на полезные ресурсы.

[Batchir]

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

В таком случае нужно забыть про типовое восстановление последовательности и делать своё - в разрезе документов и номенклатуры (серии, характеристики).
Провели задним числом документ - перепроводим все последующие документы где участвует номенклатура изначально проведенного документа.

[DartRomanius]

Помимо всего прочего, лично я бы посоветовал автору провести аудит соответствия железа нагрузочной потребности!!!

8.х платформа достаточно оптимизирована (ну почти! ), так-что вопрос может быть не в программной оптимизации (весьма трудоемкой операции!), а просто сделать "апгрейд" железа - ибо дешевле выйдет.

[Ardi]

При ночном перепроведении никаких блокировок не возникает.

А днем такие сильные тормоза???


Зачем перепроводить весь квартал каждый раз???
Менеджеры перепроводят отгрузки сделанные 2 месяца назад? Запретить. Оставить неделю.


В бухгалтерию переносится себестоимость из упр. базы??? Что за себестоимость такая?

Сообщение отредактировал Ardi - 12.09.11, 20:07

[bolobol]

В таком случае нужно забыть про типовое восстановление последовательности и делать своё - в разрезе документов и номенклатуры (серии, характеристики).
Провели задним числом документ - перепроводим все последующие документы где участвует номенклатура изначально проведенного документа.

Вот в этом случае - оперативная работа никак не поменяется, а указанный анализ при восстановлении последовательности (аналитически) только затормозит процесс перепроведения. Ди и к тому же - номенклатура одна и та же везде, и выигрыш от пропуска 5-ти-10-ти процентов документов не оправдает анализа, который и так не понятно как и делать-то.

Помимо всего прочего, лично я бы посоветовал автору провести аудит соответствия железа нагрузочной потребности!!!

8.х платформа достаточно оптимизирована (ну почти! ), так-что вопрос может быть не в программной оптимизации (весьма трудоемкой операции!), а просто сделать "апгрейд" железа - ибо дешевле выйдет.

Железо в порядке, пиковая загрузка показывает изнасилованность дисковой системы, которую и не улучшишь за приемлемые средства. А три миллиона - это несколько больше, чем зарплата программистам за обозначенную задачу.

При ночном перепроведении никаких блокировок не возникает.

А днем такие сильные тормоза???

Зачем перепроводить весь квартал каждый раз???
Менеджеры перепроводят отгрузки сделанные 2 месяца назад? Запретить. Оставить неделю.

В бухгалтерию переносится себестоимость из упр. базы??? Что за себестоимость такая?

Перепроведение осуществляется за период от закрытого квартала, а это до 3-х месяцев + 20 дней до НДС. Тут уж некуда уменьшать. Месяц отпуска, месяц переговоров до исправления... А где два, там и четыре. Рабочим процессам, связанным с налоговой отчётностью надо не мешать, а помогать ))
Себестоимость в бухгалтерию не переносится, а из-за изменения документов, из-за перевыгрузок - пересчитывается.

Суть в чём - приходный документ, записанный задним числом, заставит все списания передвинуться на этот документ, таким образом, списания нужно фиксировать по партии в самом документе. Значит, при перепроведении, если эта партия изменилась (в ней стала другая себестоимость), то и документ реализации тоже должен поменять себестоимость. Перепроводя документ с уменьшением количества приходный или с увеличением расходный - потребуется проверить остатки по этой партии, чтобы никогда не уйти в минус. Когда необходимо уйти в минус - потребуется перепроведение других документов расхода по этой партии и заменять при проведении партию (это, наверное, можно сделать используя последовательности и реквизиты... там же есть реквизиты(?) - партию и номенклатуру). Всё это можно делать ночью, днём необходимо контролировать только наличие остатка в принципе и, перепроводя задним числом натыкаемся на ситуацию:

Приход1: 15 шт.
Расход1: 5 шт.
Остаток: 10 шт.
Приход2: 10 шт.
Остаток: 20 шт.
Расход2: 7 шт.
Остаток: 13 шт.

Можно задним числом списать 13 шт. (они есть в остатке). Спишем их Расходом3 между Приход1 и Расход1 (они есть в остатке на тот момент), на сегодня будет ноль, но списание по партии ночью не сможет провестись! Нельзя также Расход3 сделать на 15, хоть остаток 15 и есть на тот момент, но на сегодня - всего 13. Поэтому нельзя опрашивать остатки только на момент проведения.
Можно и увеличить Расход1 только на 10 шт. (в остатке есть на тот момент +10, а если смотреть на сегодня, то +13) - этот пример показывает, что нельзя остатки проверять только по наличию на сегодня.

Итого: Необходимо при перепроведении/вводе документа задним числом иметь партионное списание, остатки на сегодня в разрезе партии. Необходимо и достаточное условие. Проверять остаток на момент проведения по данной партии нет необходимости.

Значит, анализ изменённых позиций, перепроведение без проверки остатков, если кол-во уменьшено, проверка по партиям, если кол-во увеличилось/появилось новая номенклатура.

Зачем регистр остатки?

[Batchir]

Сначала нужно избавиться от всех проведений которых не должно быть:

1.

Многим, наверное, известна любимая кнопка оператора, бухгалтера - посмотрел в документ - "ОК"-ей... и перепроведение пошло. А зачем? Вот.

Проверка на модифицированность объекта вам в помощь

2.

Исправления в комментарии документа запускают по "ОК"-йу полный цикл, несмотря на то, что в табличных частях ничего не поменялось.

я когда-то делал так: блокировал комментарий, добавил спец кнопку, при нажатии которой открывалось окно ввода текста, при закрытии устанавливал комментарий и записывал документ без перепроведения. Но делал так потому что обычные пользователи могли только одни раз провести документ, после чего он был доступен только на просмотр, а комментарий редактировать нужно было.

3.

Оператор, бухгалтер выписал что-то не то в одной из позиций документа, при этом, к тому же, для целей определения стоимости, были проведены запросы-расчёты себестоимости, одну позицию исправили, а перепроведение пересчитает, переспишет все позиции.

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

А так пока вижу:
1. Избавиться от проведений-паразитов
2. Контроль остатков задним числом при проведении документа
3. Своя обработка восстановления последовательности.

[bolobol]

А что за фокус такой, сообщение от меня есть, но при просмотре форума - оно пустое, а при ответе - весь текст его видно??

Спецы - ХЕЛП!

Ничего не понимаю - теперь я вижу сообщение своё со всем текстом, как и вчера...

Сначала нужно избавиться от всех проведений которых не должно быть:
1.
Проверка на модифицированность объекта вам в помощь

Это я вычисляю перед записью - Беру Документ и Документ.Ссылка - сравниваю - получаю новый документ того же типа с изменениями. Сейчас знакомлюсь плотнее с платформой по ссылке на доку по 8.2, где рассказываются способы использования временных таблиц в менеджерах документов, регистров - буду думать, куда воткнуть.

2.
я когда-то делал так: блокировал комментарий, добавил спец кнопку, при нажатии которой открывалось окно ввода текста, при закрытии устанавливал комментарий и записывал документ без перепроведения. Но делал так потому что обычные пользователи могли только одни раз провести документ, после чего он был доступен только на просмотр, а комментарий редактировать нужно было.

Данное становится неактуальным, в следствии проверки изменённости документа, т.к. обращений, насколько я понимаю, к базе данных для сверки с записанной информацией не происходит, она же у же была считана, но, с другой стороны, документ могут открыть два пользователя и начать менять, вот когда блокировка его начинается - понять не могу, но в какой-то момент платформа отказывает одному из пользователей из-за того, что версия документа устарела - ещё буду проверять. Но сравнение Документ с Документ.Ссылка в теории приводит к перечитыванию данных с базы? Как упростить?
Ведь не только комментарий не изменяет данные проведения - там ещё кучка реквизитов.

3.
Думаю это основная причина, а все предыдущие - предисловие.
Прошу озвучить конкретные причины того почему редактируются (создаются) приходные документы задним числом и уже эти причины будут анализироваться что бы что-то Вам посоветовать.

Причины? Вы меня удивили ))
Я один что ли такой реалист? Информационная система предназначена для облегчения работы пользователей, то есть - не должна заставлять работать правильно. Должна быть дружелюбной ))
Причины:
- Документ забыли ввести. Здесь ясно - списание с него начнётся тогда, когда его всё-таки введут, а найдёт его отсутствие, как только чего-то не смогут списать, что присутствует фактически.
- Поставщик отказался менять брак - заменил документы, т.к. менять товар не на что - это долгий процесс.
- Оператор по вводу документов ошибся - всякого рода косяки - номенклатура/количество
На текущий момент всё это решается корректировками, но тот же акт сверки - очень нагруженный обработками сверок... Другие отчёты, которые лопатят дополнительный объём данных, обмен с объединением документов с корректировками для бухгалтерии - это всё очень сложно и для пользователя в том числе.

[Vofka]

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

Информационная система должна на входе принимать, а на выходе выдавать определённые данные - это всё, что она должна. Больше она никому ничего не должна. И если надо делать действия А, Б, В то значит надо делать действия А, Б и В, а не действие Г и получать при этом кучу Г на выходе, которое потом разгребать и плеваться в сторону системы.

[bolobol]

Информационная система должна на входе принимать, а на выходе выдавать определённые данные - это всё, что она должна. Больше она никому ничего не должна. И если надо делать действия А, Б, В то значит надо делать действия А, Б и В, а не действие Г и получать при этом кучу Г на выходе, которое потом разгребать и плеваться в сторону системы.

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

Но, покурив ещё методичку по 8.2 - дошло и следующее, что при мною озвученной задаче - процесс пересписания никогда не наступит, т.к. при перепроведении - документ не меняется. Поэтому, в методичке и озвучен универсальный алгоритм, лишённый преимуществ перепроведения без изменения самого документа, но универсальный.

Так же, вижу что тема уходит от конкретных вопросов, но и сами вопросы меняются по мере осознания темы ))

Спасибо. Буду вкуривать дальше!