Галактика в вопросах и ответах

Доброе утро, коллеги.
Планируем включить Филиальность, сделали общими все таблицы по документу "Филиальность. Прикладные решения" 2016г. Вопросы:
1. Нам нужно сделать общими документы планирования в производстве - mnplan, indent и все, что с ними связано, включая таблицы настройки. Есть ли у кого- нибудь такой список?
2. В этом документе рекомендуется таблицы зарплаты сделать общими, а филиалы вести как обособленные подразделения. Что такое "обособленное подразделение"? Как сделать структурные единицы в этом случае? Где прочитать?

Здравствуйте. У меня на предприятии филиальность ввели до моего прихода. Поэтому не подскажу по настройке. Единственно обращу внимание на таблицу Catalogs. Почему-то ее сразу не сделали общей для филиалов, поэтому впоследствии столкнулись с рядом проблем. В частности необходимость для каждого филиала заполнять одну и ту же справочную инфо. Была пара проблем и в з/п, в частности одна связана с формированием пенсионных стажей по сотрудникам. Проблемы в з/п решили ПИР.
Сейчас переделать (сделать Catalogs общей) нереально, т. к. в указанной таблице практически вся справочная инфо модуля Управление персоналом и частично з/п.

Спасибо, с catalogs понятно. Я все таблицы по списку из упомянутого документа перевёл в общие.
И по "обособленному" подразделению здесь есть отдельные комментарии, можно проиграть.

Мы вот тоже хотим перейти на филиальность.
У нас сейчас Enterprise, часть таблиц уже общая, но, например, таблицы видов оплат, удержаний, налогов в зарплате не общие. И непонятно как с этим быть? Там уже есть записи с одинаковыми nrec'ами и есть одинаковые виды оплат с разными nrec'ами.
А есть еще не совсем стандартные общие таблицы - SaldoMC например. Как себя в такой ситуации будет чувствовать филиальность?
А эту инструкцию не актуализировали? С 2016 года ж много новых таблиц появилось.

Да, с 2016 г. добавлялись новые таблицы, в частности в з/п в 2018 г. Blankbln и Fssinfo. По правде говоря, при добавлении новых таблиц у нас даже не задумывались, что возможно какие-то из них надо делать общими для филиалов. Возможно до тех пор, пока не проявятся какие-то проблемы. К тому же иногда после добавления новых таблиц конвертером автоматом идет перенос инфо из одной таблицы в другую.
По поводу таблиц в з/п. Таблицы ВО, ВУ, н-гов должны быть общие. И это логично. Ведь Вы не должны по каждому филиалу настраивать одни и те же расчеты. По поводу Nrec у ВО и ВУ. Насколько я сталкивалась, во многих таблицах з/п нет Nrec ВО или ВУ, там имеются только коды ВО/ ВУ системные и пользовательские одновременно или только системные. Хотя возможно все-таки где-то могут быть использованы их Nrec, но мне навскидку не попадались такие таблицы.
На мой взгляд, перед началом использования филиальности Ваши вопросы следует адресовать разработчикам.

Планирую остатки и ордера сделать общими: sporder, sklorder, saldomc, teksaldo, sklost, tekmc, saldofnd, saldmnf

zna писал(а):Планирую остатки и ордера сделать общими: sporder, sklorder, saldomc, teksaldo, sklost, tekmc, saldofnd, saldmnf

У нас еще складские ордера общие - sklorder и sporder

Irina_ писал(а):...
Сейчас переделать (сделать Catalogs общей) нереально, т. к. в указанной таблице практически вся справочная инфо модуля Управление персоналом и частично з/п.

Ирина, можно поподробней этот момент? Перевод таблицы в общие сделает её записи доступными для всех филиалов. Будут видны дублированные записи- неудобство для пользователей, но ссылочная целостность сохранится

Здравствуйте.
То, что в случае перевода Catalogs в общие появятся дубли, на мой взгляд это проблема. К тому же в этой таблице помимо пользовательских записей есть системные (от разработчика). Есть ряд ф-ций (инициализация, контроль данных), запуск которых на мой взгляд может принести проблемы в случае перевода таблицы в общие.
К слову, помню очень давно была проблема, когда при запуске инициализации в режиме обновления создавались дубли, т. е. сколько раз запускали ф-цию, столько дублей записей создавалось. Ставили ПИР для решения этой проблемы.
Напомню, что в Управлении персоналом есть настроенные типовые отчеты, есть возможность настраивать иерархические отчеты по картотеке или использовать построитель отчетов. При наличии дублей, в т.ч. системных записей, получаем проблемы с настройкой этих отчетов. Хотя и сейчас имеем проблемы. Я когда пришла на предприятие, не могла понять почему некоторые отчеты, настроенные в построителе, не работают, а также есть настройки с одинаковыми именами. Потом до меня дошло, что проблема в том, что на предприятии используется филиальность, а Catalogs не общая.
Лет 6-7 назад, когда у нас возникла одна из проблем, которая напрямую была связана с тем, что Catalogs не общая, я обратилась в ОТП, чтобы проблему решили, учитывая состояние таблицы, или же написали конвертер, который бы позволил изменить ссылки на эту таблицу в одном филиале на значения в другом филиале, чтобы сделать потом таблицу общей и избавиться от дублей. Разработчики пошли более простым путем: просто решили конкретную проблему. А позже еще одну. Собственно я сама понимаю насколько сложно было бы писать конвертер, т. к. во многих таблицах кадров и з/п есть ссылочные поля на Catalogs, и чаще всего это не одно поле, а несколько. Причем по имени поля и его описанию в Support далеко не всегда можно понять, что это поле хранит ссылку на Catalogs. В любом случае я сама бы не стала что-то писать по замене данных.
Таблица Catalogs действительно уникальная среди остальных таблиц. В ней хранится инфо различного назначения, и на ней завязана работа всего модуля УП и частично з/п. При написании своих отчетов по персоналу и з/п часто сталкивалась с необходимостью работы с этой таблицей. Поэтому то, что написала выше, это итог работы по написанию и/или настройке отчетов, настройке процессов в з/п.

Понятно. Спасибо за подробный ответ. Не хочется наступать на такие проблемы..

Catalogs однозначно необходимо делать общей при включении филиальности. При этом не забываем про зависимые от нее. CatHist например.
Реализовать виртуальную филиальность для отдельных каталогов (Штатную структуру и ей подобные) не так сложно.
Докомпиляция пары интерфейсов и пара триггеров.

Не нахожу руководство пользователя "Переводы сотрудников из филиала в филиал". Документация скачана последняя с ftp. У кого-нибудь есть?

Den писал(а):https://cloud.mail.ru/public/xZjH/5B8KzSUMB

Скачал, спасибо. Странно, что на ftp.galaktika.ru нет этого руководства.

Прошу помочь в настройке филиальности в Зарплате. Пошёл по пути "обособленных подразделений", согласно руководства "Филиальность. Прикладные решения" таблицы persons, lcshet и связанные с ними должны быть общими. Сделал обособленные подразделения, но вот как сделать разграничение прав доступа к подразделениям не нашёл. В итоге лицевые счета в обоих филиалах отображаются некорректно. У кого такая схема работает, посмотрите, пож., настройку разграничения прав. Или, может, другая причина?