Доброе утро, коллеги.
Планируем включить Филиальность, сделали общими все таблицы по документу "Филиальность. Прикладные решения" 2016г. Вопросы:
1. Нам нужно сделать общими документы планирования в производстве - mnplan, indent и все, что с ними связано, включая таблицы настройки. Есть ли у кого- нибудь такой список?
2. В этом документе рекомендуется таблицы зарплаты сделать общими, а филиалы вести как обособленные подразделения. Что такое "обособленное подразделение"? Как сделать структурные единицы в этом случае? Где прочитать?
Здравствуйте. У меня на предприятии филиальность ввели до моего прихода. Поэтому не подскажу по настройке. Единственно обращу внимание на таблицу Catalogs. Почему-то ее сразу не сделали общей для филиалов, поэтому впоследствии столкнулись с рядом проблем. В частности необходимость для каждого филиала заполнять одну и ту же справочную инфо. Была пара проблем и в з/п, в частности одна связана с формированием пенсионных стажей по сотрудникам. Проблемы в з/п решили ПИР.
Сейчас переделать (сделать Catalogs общей) нереально, т. к. в указанной таблице практически вся справочная инфо модуля Управление персоналом и частично з/п.
Спасибо, с catalogs понятно. Я все таблицы по списку из упомянутого документа перевёл в общие.
И по "обособленному" подразделению здесь есть отдельные комментарии, можно проиграть.
Мы вот тоже хотим перейти на филиальность.
У нас сейчас Enterprise, часть таблиц уже общая, но, например, таблицы видов оплат, удержаний, налогов в зарплате не общие. И непонятно как с этим быть? Там уже есть записи с одинаковыми nrec'ами и есть одинаковые виды оплат с разными nrec'ами.
А есть еще не совсем стандартные общие таблицы - SaldoMC например. Как себя в такой ситуации будет чувствовать филиальность?
А эту инструкцию не актуализировали? С 2016 года ж много новых таблиц появилось.
Да, с 2016 г. добавлялись новые таблицы, в частности в з/п в 2018 г. Blankbln и Fssinfo. По правде говоря, при добавлении новых таблиц у нас даже не задумывались, что возможно какие-то из них надо делать общими для филиалов. Возможно до тех пор, пока не проявятся какие-то проблемы. К тому же иногда после добавления новых таблиц конвертером автоматом идет перенос инфо из одной таблицы в другую.
По поводу таблиц в з/п. Таблицы ВО, ВУ, н-гов должны быть общие. И это логично. Ведь Вы не должны по каждому филиалу настраивать одни и те же расчеты. По поводу Nrec у ВО и ВУ. Насколько я сталкивалась, во многих таблицах з/п нет Nrec ВО или ВУ, там имеются только коды ВО/ ВУ системные и пользовательские одновременно или только системные. Хотя возможно все-таки где-то могут быть использованы их Nrec, но мне навскидку не попадались такие таблицы.
На мой взгляд, перед началом использования филиальности Ваши вопросы следует адресовать разработчикам.
Irina_ писал(а):...
Сейчас переделать (сделать Catalogs общей) нереально, т. к. в указанной таблице практически вся справочная инфо модуля Управление персоналом и частично з/п.
Ирина, можно поподробней этот момент? Перевод таблицы в общие сделает её записи доступными для всех филиалов. Будут видны дублированные записи- неудобство для пользователей, но ссылочная целостность сохранится
Здравствуйте.
То, что в случае перевода Catalogs в общие появятся дубли, на мой взгляд это проблема. К тому же в этой таблице помимо пользовательских записей есть системные (от разработчика). Есть ряд ф-ций (инициализация, контроль данных), запуск которых на мой взгляд может принести проблемы в случае перевода таблицы в общие.
К слову, помню очень давно была проблема, когда при запуске инициализации в режиме обновления создавались дубли, т. е. сколько раз запускали ф-цию, столько дублей записей создавалось. Ставили ПИР для решения этой проблемы.
Напомню, что в Управлении персоналом есть настроенные типовые отчеты, есть возможность настраивать иерархические отчеты по картотеке или использовать построитель отчетов. При наличии дублей, в т.ч. системных записей, получаем проблемы с настройкой этих отчетов. Хотя и сейчас имеем проблемы. Я когда пришла на предприятие, не могла понять почему некоторые отчеты, настроенные в построителе, не работают, а также есть настройки с одинаковыми именами. Потом до меня дошло, что проблема в том, что на предприятии используется филиальность, а Catalogs не общая.
Лет 6-7 назад, когда у нас возникла одна из проблем, которая напрямую была связана с тем, что Catalogs не общая, я обратилась в ОТП, чтобы проблему решили, учитывая состояние таблицы, или же написали конвертер, который бы позволил изменить ссылки на эту таблицу в одном филиале на значения в другом филиале, чтобы сделать потом таблицу общей и избавиться от дублей. Разработчики пошли более простым путем: просто решили конкретную проблему. А позже еще одну. Собственно я сама понимаю насколько сложно было бы писать конвертер, т. к. во многих таблицах кадров и з/п есть ссылочные поля на Catalogs, и чаще всего это не одно поле, а несколько. Причем по имени поля и его описанию в Support далеко не всегда можно понять, что это поле хранит ссылку на Catalogs. В любом случае я сама бы не стала что-то писать по замене данных.
Таблица Catalogs действительно уникальная среди остальных таблиц. В ней хранится инфо различного назначения, и на ней завязана работа всего модуля УП и частично з/п. При написании своих отчетов по персоналу и з/п часто сталкивалась с необходимостью работы с этой таблицей. Поэтому то, что написала выше, это итог работы по написанию и/или настройке отчетов, настройке процессов в з/п.
Catalogs однозначно необходимо делать общей при включении филиальности. При этом не забываем про зависимые от нее. CatHist например.
Реализовать виртуальную филиальность для отдельных каталогов (Штатную структуру и ей подобные) не так сложно.
Докомпиляция пары интерфейсов и пара триггеров.
Прошу помочь в настройке филиальности в Зарплате. Пошёл по пути "обособленных подразделений", согласно руководства "Филиальность. Прикладные решения" таблицы persons, lcshet и связанные с ними должны быть общими. Сделал обособленные подразделения, но вот как сделать разграничение прав доступа к подразделениям не нашёл. В итоге лицевые счета в обоих филиалах отображаются некорректно. У кого такая схема работает, посмотрите, пож., настройку разграничения прав. Или, может, другая причина?
