ЗУП Кто-либо может объяснить - зачем в ЗУП регистр расчета среднего? #94587

ЗУП Кто-либо может объяснить - зачем в ЗУП регистр расчета среднего? И почему это не сделанно в самом документе в табличной части? Так быстрее что-ли?

а ты законодательство то хорошо знаешь? А то бы не задавал таких вопросов...

При чем здесь законодательство и програмная реализация? Я спросил - в чем разница данные для расчета среднего хранить в табличной части документа или в отдельном регистре расчета. Я не спрашивал как расчитывается средний. Вопрос как расчитывать средний меня уже давно не интересует ( ).

Ошибся наверное в адресе -

В данном регистре хранятся события связанные с расчетом среднего. Т.е. под каждым документом, требующим расчета среднего заработка, лежит свой набор записей, который и используется в расчетах и в других случаях Как то так все енто выглядет Зачем и почему пока неразберался:)

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

Есть такое дело. Однако как я понял про закрытые периоды это сделано сознательно по просьбе трудящихся. Сейчас платформа не чего не контралирует (перерасчеты например) Как в зике это работает знаеш сам. А вот в 8.0 это все нужно обрабатывать на программном уровне (тоесть песать свои алгоритмы). Наверное сумбурно написал если что не понятно попробую объяснить (на сколько сам понял)

Да нет все понятно про периоды и перерасчеты. В 7.7 была стратегическая ошибка вводя вообще записи перерасчеты - необходимо было оботись сторно и новой записью, и при вводе сторно прописывать сторно чего она непосредственно является, а не той самой первой записи... Вот в принципе и все. В 8.0 я так понял они вообще не стали на уровне платформы такие вещи делать, так как решили наверное что не смогут, поэтому на прикладную задачу переложили. В 7.7 в типовой тоже ведь вводится типа новый записать, а не ВвестиРасчет ... Пока не сильно пойму смысл ввода регистра расчета среднего, кроме того, что предположил о скорости, ну может еще и удобнее в чем-то. Может принцип заложен что любой расчет должен быть в регистре.... Смысл явно есть, только пока не понятен. :-)))

Предположение "Может принцип заложен что любой расчет должен быть в регистре..." - неверен. Имелся ввиду регистр расчетов. НДФЛ находится в регистре накоплений. А НДФЛ у нас влияет на алименты.... В общем мне пока не понятно зачем регистр надо было создавать для среднего... :-)

Я так понял теперь нет такого понятия начислить доночислить...... Ну по крайней мере в той реализации что сейчас. Если по сотруднику было начисление то и все..... Заходи туда и правь. Если надо будет долговременное начисление доначислить будь добр перезаполнять докумет. А если в этом документе уже был сотрудник, по которому было руками поправленное значение, то будешь его искать и исправлять заново или руками надо добовлять в документ начисление, что бы не перезаполнять и не пересчитывать.... :-(((

Пока как ты и заметел "в той реализации что сейчас" именно так

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

Зачем два документа о начислении премии и начислении разового расчета. При этом в документе Начисление премии есть форма Т-11, а разовом нет. Что-то я плохо понимаю необходимость создавать два аналогичных документа по своей сути.

Тоже прикол. Зачем две абсалютно одинаковые табличные части для документа РасчетПриУвольненииРаботникаОрганизаций? :-) Одной мало что-ли?

Слухай я еще на столько не копал:))) Времени нет к сожелению.

Да я и не копал просто сел посмотреть.... А про средний можно было бы и один документ сделать - начисление по среденму заработку + для БЛ отдельный так как состав реквизитов в БЛ на много больше в шапке. Принцип же расчета среднего одинаковый что для выходного пособия, что для компенсации при увольнении, что для отпуска, командировки и т.д. Зачем делать 1 000 документов подобных не понятно..... :-(( Есть документ основания - кадровый приказ, а на основании его и делать документ начисление по среднему. В зависимости от алгоритма и расчет среднего будет разный.... По моему так должно быть..... Жалко, что никто на вопрос в . :-(((

Скорей всего там собираются накапливать инфу о средней для расчетов... Чтобы быстро юзать...

Да но накапливается она там только если есть документ о среднем или БЛ. Что-то мне подсказывает, что тащить из регистратора данныые по времени для конкретной записи быстрее чем из регистра запросом. А во вторых правильнее хранить таблицу о среднем заработке в развернутом виде. Почему - писал выше.

Я так понял сделан отдельный план что бы использовать тип данных не ПланВидовРасчетаСсылка, а ПланВидовРасчетаСсылка.СреднийЗаработок. Так как в срений заработок попадают не только основные начисления, но и дополнительные.... Я так понял что бы не делать, скажем так множественный тип данных. Хотя это по моему совсем не множественный, но назавем его так. При этом не совсем понятно правда в чем выйгрыш.....?

Раз нет ответов значит просто ни кто не задумывался еще наверное. А раз не задумывался значит не работает на этом счастье не кто. Камин обещал нарисовать на 8.0. конфигу... И еще один вопрос - если база среднего хранится свернуто как мы потом распределять проводки, если в сумму вошли несколько реальных начислений на по разным проводкам?!!!

По-моему, регистр расчета среднего в ЗУП нужен для того чтоб можно было сворачивать базу. При свертке базы в 7.7 основная проблема как раз в расчете среднего. С регистром расчета проблем со сверткой зика не больше чем со сверткой бухгалтерии.

Не вряд ли. В 7.7 если таблицу среднего в документе заполнил, то можешь журнал расчетов в принципе очищать, все равно средний по данному документу очиститься...... Мы тут подумали и решили, что создали этот регистр расчетов для того что бы быстро собирать базу для среднего и расчета результата. Почему быстро, да потаму что это системное свойство сбора базы. Но !!! Получить, то результат они получат, но вот как они его потом по проводкам распределять будут? Эта информация в свернутом виде не отражает действительности. Т.е. (выше уже писал) есть две премии разные но за один месяц и по разным проводкам. В базу попала общая сумма, но из чего она сложилась информации нет. Т.е. средний расчитать просто, а вот ......

В описался.... "если таблицу среднего в документе заполнил, то можешь журнал расчетов в принципе очищать, все равно средний по данному документу РАСЧИТАЕТСЯ...... "

Да кстати в расчете среднего есть такая фигня как п. 14 Положения 213 - в расчет среднего входят "премии и вознаграждения - не более одной за одни и те же показатели, в размере ....". Так вот как из базы которую собирает платформа выкинуть те начисления, которые не должны попадать в данном случае (так как в данном периоде два одинаковых начисления), а не по определению (в средний данное начисление входит). Т.е. другими словами нет возможности на уровне платформы сказать что данное начисление входит, но при условии отсутствия подобных, либо при их присутствии, но при условии что данное начисление будет больше/меньше и т.д.