Приветствую!
Кто с сабжем сталкивался? Какие есть подводные камни?

:-)

В Пятницу ходите поиграть?

камней нет, есть течения - вроде никто не тонет

Хотим начать пользоваться 1С.
Кто сталкивался? Какие есть подводные камни?

(1) (2) На самом деле все не так смешно

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

(0) Еще Все зависит от доп вопросов.
1. Сколько сотров в каждой компании?
2. Компании связаны друг с другом? Афилированные?
3. Расчетчики и кадровики разные не связаны между собой?
5. Требуется ли запрет на просмотр ЗП друг у друга кадровиками расчетчиками итп?

ИТП

(0)

Основной подводный камень -- в один прекрасный момент организации  могут "развестись".

(4) на самом деле, это все очень смешно, потому что указанная тобой фича далеко не единственная. И размазывать _все_ фичи и баги от работы нескольких организаций в одной базе придется по нескольку раз, в зависимости от разных вохдящих условий.

А кто нибудь пытался программировать в конфигураторе 1С? Какие есть подводные камни?

(7) "указанная тобой фича далеко не единственная"

Дык понятно что не единственная, но первая о которой надо думать
В (5-6) тоже вполне резонные соображения высказаны, но развода фирм может и не наступить, а вот разные настройки 146% захочется сделать. Но и все там сказанное надо безусловно учитывать

(8) резонное соображение о выделении отдельной организации в отдельную базу?! На 3.1 ?!

А ничего, что в конфе уже есть РИБ с отбором по Организации и внезапно отделить как раз проблемы не составит, а вот слить в общую будет затруднительно.

(6) не критично. развод юриков на ИП и обратно собственно без особых забот, кадровики попыхнят чуток и поехали.

(4) - очасти прав, есть там всякие константы расчета среднего и пр., но это уже в плоскости "примирения" бухов. что касается видов расчетов, то можно создавать/клонировать.

(0)
―"С 8 утра до 10 - подвиг."
―Как это понимать?
―Это значит, что от 8 до 10 утра у него запланирован подвиг. Ну? Что Вы скажете, бургомистр, о человеке, который ежедневно отправляется на подвиг, точно на службу?
―Я сам служу, сударыня. Каждый день к девяти утра я должен идти в мой магистрат. Я не скажу, что это подвиг. Но вообще что-то героическое в этом есть.

Есть опыт работы в ЗУП с несколькими десятками организаций в одной базе.
Подводные камни есть.
Все их без конкретики вводных условий перечислять смысла не вижу.

(11) Руководство придумало разделить организацию на несколько частей. Поставлена задача выяснить на какие грабли придётся наступать и, по возможности, этого избежать. На текущий момент очевидная проблема одна - главбух резко против ведения этого безобразия в одной базе. Вот и спрашиваю на что обратить внимание.
(5) Насколько понимаю, связаны части будут довольно слабо. Но совсем исключить пересечений не получится. Возможно какие-то сотрудники будут числиться в нескольких организациях, как совместители. Кадровик до сих пор был один.

(12) "Руководство придумало разделить организацию на несколько частей. "

Размер бедствия ?

(12) вот теперь более менее есть предмет длч обсуждения.

А сейчас уже в ЗУП 3.1 всех ведете? - просто уточняю

Разделять в разные организации лучше сразу в этой же базе. Если после захотите, то можете включить РИБ и отделить в периферийные базы созданные и заполненные работниками.

Учетные политики в новых организациях будут иметь существенные различия друг от друга?

(13) пока не знаю
(14) Да, до сих пор была одна база. Про учётные политики ничего ещё не сказали.

И ещё вопрос вдогонку. Если сделать несколько баз, как это будет выглядеть с точки зрения лицензионной политики. Большое нарушение?

Вот сейчас автор скажет "планируем купить базовую версию ЗУП"... и всё заиграет новыми красками :)

(16) вообще никаких нарушений.
У вас же все равно сеть будет одна, сервер один и т.д.?
Хоть в одной базе, хоть в разных - для лицензий разницы нет.
Понятно, что если захотят на разных 1С:серверах, то нужны будут дополнительные серверные лицензии на каждый сервер.

(17) Нет, не скажет. Уже всё куплено и учёт ведётся давно.

Имхо, смысл вести учет нескольких юридических лиц имеет смысл пока они все входят в одну компанию. Хотя бы по тому, что разделить их позднее в автономные базы - это гораздо значительно легче, чем сливать их позднее в единую базу.

Почему-то мне кажется, что задачи сливания не возникнет. Иначе зачем было разделять. Хотя, конечно зарекаться нельзя.

«А сегодня в завтрашний день не все могут смотреть...»(с)

Да, согласен:)

(12) " Поставлена задача выяснить на какие грабли придётся наступать и, по возможности, этого избежать. На текущий момент очевидная проблема одна - главбух резко против ведения этого безобразия в одной базе. Вот и спрашиваю на что обратить внимание."

Обратите внимание на мнение главбуха. Он прав.

(12) Хороший у вас главбух...
Очень рекомендую прислушаться.

(24) (25) Допустим, прислушались.
Деление текущей организации по кускам, как сверхзадача - это остается.

Дальнейшие действия?

Ну если сейчас сотрудников порядка 1000 и их надо разделить примерно на 25 организаций с численностью по 40 человек в каждой.

(26) Вести учет.

Разделите. А потом приходит дир и говорит: хочу управленческую отчетность по кадрам.

Разделить базы по организациям проще чем объединить.
Разделение делается достаточно просто, копии баз, пометка на удаление ненужных и удаление на хорошем шустром компе.

(26) Сова не тактик, Сова стратег.

Методик разделения множество, можно найти наиболее подходящую. Но стратегически решение вести каждую организацию в своей базе - верное.
Что же касается (28) - ну так управленческая ЗП должна быть вообще отдельно, в другой базе. И храниться так, чтобы никакие маски-шоу до нее не добрались.

Имел ввиду не сову-эффктивного менеджера, а анекдот про мудрую сову и зайцев, которых задрали волки.

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

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

Или все базы файловые, а количество работников порядка 100 человек, что вообще не создает обычно особых проблем, как ни крути эти данные

(0) нет проблем. Если учет ведет один отдел.
Тк например настройки начислений едины,
Настройки учета. Если тут расзождений нет то вопросов не возникает.

Удобно когда сотрудники пыгают по организациям.

Если надо разделить базы, то делается без проблем.

(0) и так,и так нужен программист)

Если владельцы бизнеса разные, то и базы лучше вести раздельно

(36) Они внезапно могут стать разными, хотя до этого считали себя лучшими друзьями и партнерами.. Наблюдал такое неоднократно.

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

(32) На данный момент списочный состав порядка 500-600 человек, несколько филиалов по разным городам. Самый крупный филиал - где-то 80 чел. Бухгалтерия единая в Москве, там же головной филиал. ЗУП стоит проф, серверная. Владелец один, вроде новых не предполагается.
Разделить предполагается частей на 5, структура типа холдинга. И по меньшей мере в двух планируется отдельная бухня или вообще аутсорс. Отсюда и бунт нынешнего главбуха.

(37) Они изначально были разные, просто плыли в одной лодке. А потом решили плыть в разных
Если владелец один то он физически не разделится на несколько

(39) Тогда смею предположить, что  для каждой из организаций не будет необходимости индивидуальных настроек, вынесеных на глобальный уровень базы, т.е. настроенно будет одинаково.

Возможность отделения какой-либо организацию в отдельную базу нужно иметь ввиду, но такая возможность имеется, как было упомянуто ранее, через создание РИБ с отборами по Организации с выгрузками в периферийную базу. Но торопиться с этим не стоит, т.к. на таком размере вряд ли это займет критичное время.

Для проведения всех оформлений с переводом сотрудников в создаваемые организации из филиалы самое удобное оставаться в этой же базе.
Мало того, вполне вероятно, что оснований для регистрации кадровых документов по работникам даже не возникнет.
Но для работы с кадровой историей по работникам проблема будет возникать.
И практически разбираться с этими проблемами легче всего в общей базе, а не в разделенной.
Соответственно, что может оказаться и подготовка регламентированной отчетности лучше будет работать в общей базе. Именно такой, которая учитывает кадровую историю.

Далее, филиалы должны быть уже обособленными, поскольку выделены в разных городах и наделены сдачей НДФЛ и остального по налоговым уже зарегистрированным в разных городах.
Надо посмотреть, что для таких филиалов _уже_ зарегистрированы Организации в базе с установленным признаком, что это Обсобленное подразделение, т.е. филиал.

Если это так и есть, то есть возможность изменить в реквизитах организации, что она является подчиненной, на неподчиненную, т.е. самостоятельную.
И этого будет достаточно, чтобы работать далее со всеми данными сотрудников, обычных подразделений никуда и никого не переводя.

Если по какой-то причине такого обособления филиалов до сих пор не выполнили, то придется действовать последовательно.
Сделать действие, необходимость которого ранее проигнорили.
Создавать подчиненные организации-филиалы, перезаписать в них соответствующих работников кадровым переводом (без галочки отражения в трудовых книжках).
И нужно попробовать это все на копии, но есть подозрение, что сквозные отчеты, формируемые с начала года накопительным итогом могут заглючить.
Поэтому перепроводить всю эту кухню или с начала текущего года, т.е. переводить всех 1-ым января задним числом и создавать переходящие остатки по НДФЛ в разрезе Организаций.
Или принимать решение, что до конца года оставлять все по старому, а с первого января делать все по новому.
Старая копия базы должна дойти вплоть до 31 декабря и ее заморозить в том состоянии.
Новая база пройдет создание всех новых филилалов-организаций-подразделений в декабре и войдет в новый год с выставленными остатками по НДФЛ.

Насчет отдельной бух и аутсорс на бух. Обмен с ЗУП->БП работает с указанием Организаций без проблем. А вот с указанием подразделений обособленных могут быть проблемы.
Т.е. подчиненные периферийные узлы обмена ЗУП-БП на стороне БП могут быть в разных базах или в одной базе - это для ЗУП не критично совершенно.
НО обособленные выгружать отдельно в БП без проблем можно только в том случае, когда это Организации, а не подразделения-филиалы. Или Просто Организации без признаков, что это филиалы.
Т.е. все опять возвращается к тому, что необходимо было _уже_ иметь филиалы в разных обособленных и подчиненных Организациях (не в разных базах, а внутри одной)
И если так уже сделано, что достаточно будет просто отменить в Организации признак, что это обособка и работать далее ничего никуда не выделяя раньше времени.

Угу, картина примерно проясняется. Будем думать, спасибо