Yakov52
Яков А

Спасибо за проделанную работу!

Но что-то мне подсказывает, что проблемы бы не было, если бы у продукта была четкая изначально продуманная линия развития, я не так давно посчитал, текущая типовая версия конфигурации ЗУП содержит около 1000 объектов и реквизитов с припиской "Удалить"! Продукту уже лет 5, а функционал так и не стабилизировался, снова имеем две параллельные ветки (к слову, выбрать из которых невозможно, т.к. нет информации о том какой функционал будет пилиться в "продвинутой" версии по сравнению с консервативной). Мы, конечно, привыкли к роли бета-тестеров у 1С, но не так же, блин, долго оставаться в бете...

Еще это решение негативно влияет на производительность, разработка и так отвязанная от структуры СУБД еще и будет "отвязана от структуры конфигурации"... это до добра не доводит, что я думаю многие заметили.

Извините, надо было выговориться.

(5) Не смешите людей, "серьезные" люди уж точно не из-за новостей ходят на такие сайты, а "бенчмарк" на ИТ ресурсе (и не только) вполне употребимо.

Добрый день! У вас случаем для УТ 10.3 или 11 нет аналогичного функционала? Или может ссылки какие-то...

Мы очень остро столкнулись с проблемой количества ролей на работе встроенной функции "ИзменитьРеквизиты" на какой версии платформы это происходило не скажу (года 1,5 назад), но из-за этой проблемы пришлось написать обработку распарсивающую набор ролей профиля и выдающую одну сводную роль. Правда потом 1С поправили эту проблему, но от сводных ролей мы так пока не отказались)

Ну и хочу на всякий случай напомнить, что в случае с наличием РЛС главное контролировать чтобы на один и тот же объект не было задано прав с разных ролей, если шаблоны в этих ролях одинаковы, то задублируются условия РЛС, что крайне негативно (не линейно) может сказаться на длительности запросов. Такие случаи встречаются и на типовых конфигурациях.

Спасибо!)

(12) alex_fursov С описанной ошибкой к сожалению не сталкивался, можно попробовать на тех. поддержку 1с написать, хотя вы уже наверное нашли выход)

Рад, что обработка помогает :)

(1) Boroda
Предосторожности для тех, кто не знает (не понимает) разницы между основными и дополнительными видами расчета, не предупредить я не могу, да и первая публикация :)
(2) 105raz
По поводу нужности это решать каждому, мне несколько раз понадобилось, когда базы большие на повторный перенос бывает уже нет времени... Или другой случай: данные уже перенесены, клиент уже вовсю работает и тут вылазит проблема с расчетом среднего... повторно не перенесешь, а клиент не доволен (мы же как раз для расчета среднего расчетные данные и переносили).
(3) alon
Ну средний заработок может включаться в перенесенный период, а, например, включить премию уже перенесенную в основные начисления в "премии учитываемые частично" не получится, т.к. подбираются только из дополнительных.

При небольших, корректных базах и когда проблема вовремя найдена конечно лучше перенести заново, правильно расставив галочки "разовые..." у видов расчета в ЗиКе (кстати, при этом в предопределенные видах расчета галочку трогать не стоит).

Спасибо за комментарии!

Часто после переноса данных из ЗиК в ЗУП(ЗБУ) мы обнаруживаем, что вид расчета попал не в тот план видов расчета и соответственно все расчеты попали не в тот регистр расчета (регистры расчета Основные или Дополнительные начисления организаций), из-за чего неправильно считается средний заработок или у бюджетников нельзя проставить нужное отношение к денежному содержанию (списки возможных значений для планов видов расчета разные). Обработка поможет исправить данную ситуацию без повторного переноса.