DNSokol
Дмитрий Соколов

(11) при перерегистрации ФН можно в ЛК в налоговой поставить галку, что старый ФН неисправен. В этом случае по идее чек от старого ФН с признаком закрытия не требуется. Но, это проверять надо. Я видел что так можно, но сам не делал.

(54) Значит в базе небольшое количество значений в регистре. Для того, чтобы понять почему 2 часа считается, надо прогнать расчет с/с под замером производительности, посмотреть на каком запросе тормоза и танцевать оттуда. Тормоза могут быть как вычислительные (только увеличивать производительность сервера), так и из-за гигантского количества запросов к базе. И тут вот нужно смотреть, куда лезет расчет и там ковыряться. Если есть интерес повысить скорость, можем вместе как-нибудь посмотреть.

(2) по дням

Дня доброго!
Что-то уже мозг спалил, никак не пойму как лучше сделать...
По сменным сотрудникам ведутся табели учета рабочего времени. Соответственно есть у сменных сотрудников начисление "оклад", по которому берется норма дней в месяце (по производственному календарю) и уменьшается только на неявки (болел, отпуск, просто прогулял). Если сотрудник отработал в текущем месяце больше или меньше, чем норма дней по производственному календарю, то в расчет все-равно попадает только норма дней. И раз в квартал у сотрудника или удерживается недоработанное, или оплачивается переработанное. Собственно, переработки с суммированным учетом я сделал, а вот с окладом что-то туплю. Он либо всегда по норме, и, тогда не уменьшается на количество дней отсутствия, либо начинает считаться относительно отработанного времени, что не верно..
Я пробовал сделать в формуле Мин(ВремяВДнях,НормаДней), т.е. итоговая формула по показателю (Оклад*ДоляНеполногоРабочегоВремени)*(Мин(ВремяВДнях,НормаДней)/НормаДней) и тогда расчет в принципе верный, но, в расчетном листке в "отработано" все равно лезет значение показателя "ВремяВДнях". Конечно можно еще переделать и расчетный листок, но... Вот может что-то по проще есть?

(51) значит у вас тормоза где-то в другом месте. Надо конкретно с вашей базой разбираться. Так же тормоза могут быть из-за не корректно произведенных настроек сервера СУБД. У меня как-то одним тюнингом СУБД получилось существенно поднять производительность.

В любом случае без каких-либо подробностей о базе, что-то конкретное сказать сложно.

(49) leo-i,

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

По вопросам:
1. На сколько я понял из описаний, то при установке значения повторного использования "на время вызова", то по окончании работы процедуры на стороне сервера, кэш слетает, а если выбрать "на время сеанса", то кэш существует на все время сеанса работы, т.е. пока клиентское приложение не закроется. Т.к. в расчете себестоимости постоянно вызовы между клиентом и сервером прыгают, то я подумал, что лучше режим выбрать "на время сеанса", хотя, тут может и не сильно прав... нужно будет поиграть с вызовами, посмотреть, к чему это приведет.

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

(43) AlexBar,
И да, похожая "петрушка" наблюдается еще на строительстве, где много отношений с комиссионерами. У меня есть такой филиал. АналитикаУчетаПартий содержит 20 тыс. уникальных строчек (уникальные пары Комиссионер/Договор), но, считается по ним всё очень быстро, т.к. нет кучи циклов. По комиссионерам ключ/значение читается только 1 раз, и далеко не все 20 тыс. записей (в отличие от спец**), т.к. отношения эти не долгоиграющие.

(43) AlexBar,

Написал же... Речь о хоз. документах естественно в части создания и РСВ - в части чтения. Документ "Передача материалов в эксплуатацию" создает много уникальных ключей, которые потом вычитываются РСВ.

Если смотреть по этапам:

Этап 1. Первичные документы (конкретно по спец**) в течение месяца формируют множество уникальных ключей.

Этап 2. Документами Корректировка НЗП так же походу создаются ключи (или читаются). документы делают бухгалтера перед закрытием.

Этап 3. Документом "расчет себестоимости" вызывается процедура "ПроцедурыРасчетаСебестоимостиРасширеннаяАналитика.ВыполнитьДействияДокумента", которая в конечном счете приводит к вызову "ВыполнитьРаспределениеЗатрат", которая в свою очередь в цикле вызывает следующую функцию:

Код
// Заполним аналитику получателя (кор. аналитику)                АналитикаПолучателя = ПолучитьАналитикуПолучателя(СтрокаБазы, СтрокаДанныеИсточника, ПравилоРаспределения, СтруктураШапкиДокумента);

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

Код
// Возвращает аналитику получателя согласно способу определения аналитики, который указан в правиле распределения. // Функция ПолучитьАналитикуПолучателя(СтрокаБазы, СтрокаИсточника, ПравилоРаспределения, СтруктураШапкиДокумента)        АналитикаПолучателя = Новый Структура;

Соответственно, если повторное значение не использовать, то при каждом вызове "ПолучитьАналитикуПолучателя" происходит чтение базы. При повторном использовании заполнение структуры "АналитикаПолучателя" производится сильно быстрее, т.к. при одинаковом наборе входящих параметров мы читаем базу только при первом вызове ПолучитьАналитикуПолучателя. При всех последующих вызовах то, что уже закэшировано сервером - просто возвращается. Чтение базы происходит только по тем ключам, которые не были получены ранее.

Надеюсь, теперь понятнее объяснил. Или нет? Что не понятно?

(40) AlexBar,
Расчет типовой. РСВ естественно не создает. Я специально написал про материалы и физлиц. Типовой документ "Передача материалов в эксплуатацию" создает ключи. у меня таких документов в месяц более 200. В каждом документе около 100 строчек. Помимо этого, есть еще возвраты, перемещения и т.д. Которые так же ключики создают. В идеале, если ключ единожды создан, то он должен использоваться, если бы не одно "но". В типовой УПП есть механизм назначений использования спецодежды и спецоснастки. В этом механизме используется справочник "назначения использования", который в свою очередь подчинен номенклатуре. Т.е. для каждой номенклатурной позиции будет столько записей в этом справочнике, сколько вариаций "счет учета/статья/подразделение/метод списания". У меня при 50 подразделениях, 10 статьях затрат (5 статей Принимаемые + 5 статей не принимаемые) и 4 счетах учета, используемых для отражения амортизации спец. одежды, на каждую позицию создается в итоге (т.в. спец* выдается во все подразделения) около 500-800 записей в этот справочник. А это всё - уникальные ключи для РАУЗа. Вот отсюда и вызовы.

Я, собственно, по этому и писал, что такое ускорение, как в статье, в первую очередь касается тех, у кого большой объем спец* на производстве. Можно, конечно, переделать этот блок, но, опять же, это упирается в большое количество трудозатрат. Проще провести оптимизацию вызовов. По крайней мере, на данном этапе.

Что до эксперимента, то каждый документ "Передача материалов в эксплуатацию" в итоге или создает, или использует 100 ключей. которые еще и "длинные", потому как для того, что бы по спец. одежде добраться до затратного счета, нужно проделать путь "Документ передачи (в измерениях для РАУЗ есть) -> Физлицо (в измерениях для РАУЗ) -> Назначение использования (ключ) -> Способ отражения расходов (по ссылке из ключа)".

Про измерения. После того как попередвигал измерения, документ стал проводиться около 3х секунд. До этого около минуты проводился.

Если взять регистры РАУЗа, то самый маленький - это аналитика вида учета. Там порядка 20 тыс. записей. Дальше аналитика учета затрат - 80 тыс. записей. Еще дальше - аналитика учета партий. Там около 200 тыс. записей уже. Когда оптимизировался было 150 тыс.

Вся "проблема" в спец. одежде. Если её выкинуть, то да, процедура по чтению ключей вызывается 3 или 4 раза.

Количество вызовов смотрел замером производительности. Не поверил. Поставил итератор. Сходится. Могу скрин в ЛС кинуть, если интересно. Не могу тут прицепить изображение.

(37) asved.ru,

ну-ну. С выключенной галкой "индексировать" время расчета себестоимости 11:20. Если включаем эту галочку и проводим расчет себестоимости, то время получается 8:02.

Внимание вопрос - что делает галочка?