Возможность ведения учета по нескольким организациям: плюсы и минусы #512732

Добрый день! Восьмерка позволяет вести раздельный учет по разным организациям. С точки зрения администрирования, это удобнее (обновлять одну конфу, а не несколько, например). А вот с точки зрения бухгалтерии - не очень (по крайней мере они меня хотят в этом убедить). По их словам им легче так: 5 организаций - 5 баз. Так вот хотелось бы спросить у знающих людей: какие плюсы и минусы в ведении учета по нескольким организациям в одной базе? С какими проблемами можно столкнуться? Заранее спасибо

ведем 8 юрлиц. Проблем нет.

Бухи страхуются, им стабильность надо.

Happy Bear, спасибо:) zGainer, это я уже понял:)

справочники для 8 баз тоже будут вручную набивать? а если операции (купля/продажа и тд) между 8 организациями? тоже вручную?

В случае ЧП проблемы у всех, а не в одной базе. Но это из разряда .

RLS однако! разделения по организациям, настройка 10-20 минут, разные пользователи для разных организаций. Если будут спрашивать, скажи что базы разные, но система аутентификации едины, типа электронной проходной и супер-пупер безопасность, скажешь еще что писал 2 года и попроси премию и секретаршу!

Минус: - При групповом проведении документов по одной организации, все остальные сидят и курят бамбук. Так же при проведении громоздких документов. Сложно назвать минусом, но все же: - если база гакнется, а бэкапов нема (что по веткам на мисте иногда бывает), то потеряем все организации, а не одну. - Если надо в конфигураторе, что то подправить для одной организации, все остальные, опять же, отдыхают.

премию просил, пойду секретаршу просить ;))

и массажистку

У меня бухт на филиалах работают в основном один логин - вся база (все фирмы). В головном офисе им так не удобно. У них один логин - одна фирма. Т.е. поработали под фирмой А, закрыли базу - зашли под другим логином на фирму Б Но, сейчас буду разделять их на отдельные базы. Причина - блокировки. Т.е. в отчетный период месяц по одной фирме перепроводиться 2-3 часа (а если квартал, то и практически рабочий день). В это время другие организации в этой базе нервно курят в сторонке. Поэтому перепроводить приходиться мне по ночам. Поэтому и буду разделять, чтобы сами перепроводили свои базы

Если премию не дали, секретаршу точно не дадут. Или что еще страшнее, дадут в наказание, а отказаться будет нельзя.

Ага посмотрю я на тебя с RLS на файловой базе. Это первое что отключаешь, чтобы база могла работать

А в один прекрасный день один из бухов решит "в целях оптимизации и собственного удобства" полностью перелопатить парочку справочников типа "Статьи затрат" и "Статьи прочих доходов и расходов" причем сделает это с заменой видов затрат по НУ у многих элементов. А потом все будут долго удивляться при каждом перепроведении любого документа....

Важной особенностью ведения нескольких организаций в одной базе является наличие единых справочников и классификаторов. Для кого-то это плюс, а для кого-то минус. Номенклатуру доходов/расходов, прибылей/убытков, номенклатурные группы и номенклатуру  придется согласовывать между организациями. Особенно это важно, если используются различные системы налогообложения (ОСН, УСН, ЕНВД). А бухгалтерам стопудово будет лень договариваться друг с другом и согласовывать потом каждый шаг. Наверняка каждая привыкла делать в своей базе всё что угодно, полагая себя хозяйкой. А без согласования в справочниках начнется бардак. Также могут возникнуть проблемы при различных особенностях НДС. Например, в одной организации захотят использовать режим упрощенного ведения НДС, а в другой есть импорт/экспорт со ставкой НДС 0%. В таком случае всем придется вести партионный учет и всю детализацию необходимую для подробного учета НДС. Если это организации не связанные друг с другом или мало связанные, то лучше вести отдельные базы. ИМХО.

ну а если на скули крутится?! просто автору было бы проще настроить РЛС за 5 минут, чем переносить организации в отдельные базы, сколькож это геморроя =)) а если разделения только по организациям и нагрузка на базу не большая, то больших тормозов при РЛС это не вызовет. если автор все таки решит вести каждую организацию в отдельной базе, то действительно пусть вешается с переносами и контроля общих справочников + обновления. Хотя могу посоветовать тогда сделать РБД, где родительская база будет пустой, а потомки рабочие базы. Обмен между ними будет на уровни метаданных, т.е обновил основную-родительскую конфигурацию, сделал обмен и все базы-потомки обновились автоматически. Но повторюсь это способ может оказаться большим геморроем для автора =(

Или РБП

Не вижу проблем вести в одной базе фирму с партионным учетом и с учетом по среднему

Единственный что нельзя сделать в одной ИБ это по одной организации считать ЗП в БП, по другой во внешней программе (по крайне мере в БП 2.0). Т.е. если даже разнести данные через УРИБ, то настройка ведения з/п мигрирует и одинакова для всех организаций в этой базе. Т.е. например есть большое ООО, где зарплата ведется в ЗУП. А есть ИП у которых один сотрудник. Программа не позволяет вести учет ЗП по ИП в БП, а ООО в ЗУП. Все должно быть единообразно :(

>> если автор все таки решит вести каждую организацию в отдельной базе, то действительно пусть вешается с переносами и контроля общих справочников Точно те же проблемы он получит при "сливании" нескольких баз 7.7 в одну базу 8-ки. После загрузки у него будет во всех справочниках зоопарк, собранный из 7-шных баз. И если контрагенты еще как-то синхронизируются (по ИНН, КПП), то разбираться с остальными придется очень долго и упорно.

Плохо, когда ведешь учет нескольких организаций в одной базе, и они торгуют друг с другом, нужно организацию дублировать как спр. Организации и как спр. Контрагент.

про риб никто не вспоминал?

Я хочу на БП 2.0 такую схему организовывать. Причем Контрагенты и Номенклатура загружаются у нас из 7-ки, поэтому буду преобразовывать идентификатор 7-ки в ГУИД 8-ки, что бы при обмене не задваивались

(20 И?... Что в этом такого ужасного? А если все организации ведутся в отдельных базах и торгуют между собой, то создавать элементы справочника "Контрагенты" не нужно?...

22 в случае с контрагентами есть в принципе ИНН/КПП - т.е. вот у меня три базы (в разных городах) - сливать в 8ку будем именно по ИНН/КПП чтобы избежать дублей (причем дублируются в основном поставщики, тк подавляющее большинство клиентов - как минимум с разным КПП). Правда обнаружился уже косяк - в трех базах у одного и того же контрагента три разных ИНН, КПП и адреса (!!!!!) :) Но как бы никто не отменял проверку перед/после. 20 ничего ужасного нет 0 главный плюс должен быть не для бухов (или админов етц) а для руководства компании (я так понимаю 5 юриков = одна компания) - им нужна полноценная инфа по всей компании а не отдельно по каждому юрику.

"Ага посмотрю я на тебя с RLS на файловой базе. Это первое что отключаешь, чтобы база могла работать" А как оно отключается?

Мне просто не в кайф ломать типовые правила обмена и рисовать свои правила. Какая разница при загрузки по какому реквизиту будет искать по ИНН и КПП или ГУИД? А так непридеться менять правила обмена Дать полные права юзеру :)

25 отключается видимо там же где и включается :) 26 ИНН и КПП в большинстве случаев однозначно идентифицируют контрагента. Если баз откуда берутся контрагенты больше чем одна (например из двух 77 все переносится в одну 8х) то это имхо единственный вариант правильно перенести контрагентов (ну кроме как изобретения велосипеда)и не наделать дублей.

У нас просто источник 7-ка номенклатура и контрагенты общие для всех филиалов (настроен обмен с помощью мод). Т.е. эти справочники изначально засинхронизированны

Не 8-ка, а типовые конфигурации