Руководство выдвинуло идею перевести все филиалы фирмы на учет в одной базе (БП 8), в связи с этим рассматриваем плюсы и минусы такого учета. На форумах я нашла такой минус, как сложность с восстановлением последовательностей. Кто знает, расскажите пожалуйста, с чем это связано?

Минусов всего 2
1. Желание ограничить доступ пользователей к фирмам.
2. Обновление одной большой базы (следовательно все отдыхают) вместо нескольких маленьких (независимых баз)

Самая большая проблема - организация НСИ, но она решаема. С последовательностями проблем нет.

+(1) и (2) зато куча плюсов :)

(1) а почему 2 - минус?

обновил и все. а то у нас не все пользователи обновлять умеют, как минимум 5 баз обновляю сама

(3) само собой - я за единую базу :) человек хотел услышать минусы - значит плюсы он знает :)
(4) Это я к тому, что если у тебя 10 баз то обновить одну небольшую базу уйдет пару минут (пользователь пока курит) а вот обновить большую базу времени уйдет куда больше и при этом  (все курят)...ну если конечно обновление (без изменений конфы) - тогда не вопрос.

(1)
п.1 Вполне рашается использованием общих реквизитов с разделением авторизации.
п.2 Вопрос чисто индивидуальный. Что лучше - обновить одну базу или штук семь?

Плюсы от создания единого информационного поля наголову перевешивают незначительные минусы.

(0) Здесь каждый случай индивидуален, но как правило одно только отсутствие лишней синхронизации говорит в пользу единой базы

(7) Решается почти все...еще раз - лично я за единую базу.

к (2) Необходимо обспечивать качественный канал связи и бесперебойную работу серверов ЦОДа.

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

(0) Я почему-то всегда думал, что в одной базе имеет смысл вести только если совпадают контрагенты/номенклатура (как в данном случае скорее всего - филиалы), а так яйца в разных корзинах.

всего 2 минуса? хм, я насчитала гораздо больше. Например, у нас по некоторым филиалам схема работы немного отличается и конфигурация у них доработана. То есть, нужно будет их доработки согласовывать со всеми или не использовать вовсе, что вызовет недовольство.
еще 1 минус - если налоговики запросят базу одного из филиалов, придется придумывать как "выудить" инфу по нему из общей базы, или отдавать целиком по всем.

(14) "запросят базу одного из филиалов, придется придумывать как "выудить" инфу по нему из общей базы" риб и выгрузка, или просто правилами выгрузить

такая красивая и такая умная - таких не бывает )))

(12) да, еще железо надо покупать. знать бы еще наверняка - какое. чтоб не было так, что купили крутой сервер, а окажется что надо было в 10 раз круче.

(16) спасибо, но вы немного льстите.

+ (15) "запросят базу одного из филиалов" - это как? Вы когда нибудь налоговикам файл *.1ЦД отдавали? Налоговикам нужна отчетность с "живыми" подписями и мокрыми печатями. Вы их будете на винты/флешки накладывать?

>>если налоговики запросят базу одного из филиалов, придется придумывать как "выудить" инфу по нему из общей базы
На основании чего налоговые органы могут требовать базу данных? Такое требование не законно.

(20) не знаю на основании чего, но там налоговые проверки всякие. про "отдавать базу" - при мне не было, но слышала что такое бывает. А при мне было, что аудиторы приходили.

(6) - а динамическое обновление?

(0)Смотря что считать плюсами.
Кто и как администрирует НСИ?

(18) Еще и скромная

(22) Динамическое обновление - зло.

(25) чем грозит?

(26) В поиск на этом же форуме.
Кратко. Самых тяжелый случай - потеря базы. Самый частый - несоответствие "актуальной" конфигурации и конфигурации в кеше пользователя.

(14) >> нужно будет их доработки согласовывать со всеми или не использовать вовсе

это не так

а вот выгрузка инфы только по одному юрлицу или филиалу - здесь лишние трудозатраты

(23) - плюс только 1: головная организация видит оперативную информацию, в одной базе.
Консолидация нам не нужна, нам нужно видеть данные по каждому отдельно взятому филиалу.
Кто и как администрирует НСИ - пока не придумали!

(28) почему не так?

(19) например попросят вежливые ребята в масках, что им отвечать? "Не отдам, у меня все в одной базе!"?

+ (27) Вот : v8: Динамическое обновление зло или добро ?
вот : v8: Ошибка при динамическом обновлении
и вот : v8: Динамическое обновление конфигурации

Для примера.

(30) Потому что можно прописать разные варианты работы 1С в зависимости от филиала

Наверное, есть две категории обновляльщиков: те, кто еще использует ДО, и те, кто уже не использует :)

(31) "вежливые ребята в масках" обычно не просят базу. Она им нафик не сдалась. Чаще всего они просто забирают системники.

(35) Зависит от черноты масок, а так-то да)

А по сути - лично я за единую базу.
Плюсы значительно перевесят минусы.

(29) На этом и запнетесь.
Администрирование НСИ, работа в "одном графике" (закрытие периода и т.д.), внесение информации по одной методике.
В общем при правильной организации это огромные плюсы. Но они требуют не маленьких финансовых и административных затрат.
Выигрыш будет виден не раньше чем через полный год такой работы. Но он будет большим.
В случае если первые три вопроса административно решены не будут, от и начинать не стоит. Только одни муки получите.

(33) - это как?
Если Организация = "БлаБлаБла1" тогда ...
Иначе если Организация = "БлаБлаБла2" тогда... ?

(38) что даст работа в одном графике? ну и что что, допустим, 5 фирм закрыли месяц, а 10 еще нет?

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

(41) что за реквизиты, к примеру?

Бывает так что за разные организации отвечают разные люди с разными подходами к учету. Потом начинается - я хочу видеть только свою номенклатуру, без лишнего бардака, который назаводил другой бух, и еще только своих контрагентов и еще... и тд и тп.

(1) А по твоему 25 баз приятнее обновлять чем одну раз в месяц в выходные, пока никого нет?

(44) Читай все комменты - я за одну единую базу...

(12) т.е. когда базы крутятся рядом то это не так тормозить будет?

Незабываем, что каждая база еще по умолчанию будет пытаться породить с десяток регламентных заданий (спасибо 1С за это), что принесёт дополнительную нагрузку

(42) Да любые.
Например, булевый реквизит "Проблемный филиал". И проставить на нем галку у половины филиалов.
И всегда, когда потребуется, обращаться в условии к нему.

(40) Работа в одном графике даст:
* Порядок и предсказуемость;
* Своевременное получение информации руководством для принятия управленческих решений;
* Позволит оптимизировать финансовые и логистические потоки между организациями.

Не знаю, есть ли в БП какое-то подобие УУ (как в УПП), но если есть документы которые производят расчеты сразу по всем организациями, то с восстановлением последовательности ой как намучаетесь (если конечно там не РАУЗ, но не помню что б он был в БП).

+(47) А не, например, к названию филиала

(14) Налоговая запросит базу? Это что же за беспредел у вас там творится?
Спроси у них есть ли у них лицензия на запуск твоей конфигурации (БП), а то ты не хочешь быть пиратом и распространять чужой интеллектуальный труд (конфигурацию)

(31) Когда придут ребята, они не будут спрашивать где и чьё, забирут сервак и уже сами будут разбираться в какой базе какая фирма

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

(0)
Плюс - если ведется разработка (постоянная допилка/изменения конфы) - намного проще обновить одну конфу и одну базу, чем обновлять 10 баз.

(52) Лучший вариант

(54) мне тоже понравился этот вариант, просто и красиво!

(44) ну дай-то бог раз в месяц! А то во время отчетного периода или важного изменения законодательства 1С обновления выпускает чуть ли не ежедневно.

Лично я вижу только 2 минусов

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

2. Безграмотность разработчиков
Очень много косяков в коде типовых которые непозволяют настроить разделение по организации, или вызывают взаимные блокировки при работе в разных организациях. К примеру в БП 2.0 это использовать конструкцию  Документ.Выбрать() для проверки наличия документа корректировки записи регистра, который не совместим с RLS. Или например у меня перепроводка базы комитента (у нас комиссионная торговля) блокировала работу всех остальных фирм

(55) "просто и красиво" это если документов по десятку в месяц. Да база за год. А вот если документов под две сотни в день, да база года за три - выпиливание ненужного может занять не один день.

(58) Не более получаса, если база на скуле. Ибо дроб табл по фильтру средствами скуля отрабатывается очень быстро

со справочниками чуть сложнее, ибо у них нет разделителя организации

Кстати не совсем понятно под многофирменным учетом подразумевается УРИБ или аля сап, все работают в одной базе и никаких обменов

(59) Средствами скуля = забыть за ссылочную целостность. Либо подготовка (составление списка таблиц для удаления) займет не один день.

Я как бухгалтер против многофирменного учета в одной базе, за исключением случаев реальной связности юрлиц - например, когда цепочка перепродавцов используется

(62) ссылочная целостность на что?

(61) А какая разница?
Даже если РИБ - каждый работает в своей базе, после обмена все синхронизировано в ЦБ. Настройка планов обмена с фильтром по организации только и всего.

(63) обоснуй? Я как программист могу тебе сделать 3 логина с к одной базе с жесткой привязкой к организации, и для тебе это будет "как будто 3 разных базы"

(65) В части плюсов и минусов - очень большая

(64) На объекты базы данных. Для поддержания оной кроме удаления документов нужно будет предусмотреть удаление связанной информации (регистры сведений, накопления, ссылка в справочниках, константах, хранилищах ...). Средствами скуля (который не знает о их взаимосвязи) добиться очччень тяжело.

(67) Обоснуйте.

(66)
1. Обновление это вообще не проблема. По моему опыту обновления требуются дай бог раз в квартал, а то и реже
2. Организация справочников, об этом уже говорили. Если в базе работают разные бухгалтера - то вообще туши свет
3. Возможность ошибок, т.е. тупо взяли и сделали документ по другому юрлицу и не заметили
4. Необходимость постоянного выбора юрлица.

Сейчас вот еще что обсудили. Поскольку нам в принципе не нужно консолидировать данные, а важен только своевременный доступ - а что если просто разместить все базы филиалов на нашем сервере - какие проблемы могут быть?

(68)
РН - грохнутся сами после пересчета итогов, РС - после ТиИ
ссылка в справочниках, константах, - привили пример в каком справочнике ссылка на документ.

В любом случае цель какая? База будет работать, просто в некоторых местах будет "объект не найден", но наша цель чтобы данные о других фирмах удалить - мы своей цели добились. А битые ссылки - да ну и хрен с ними. К тому же удалять можно и обработкой, в которой можно предусмотреть хоть чёрта лысого, в том числе и поиск и удаления связанной информации

(71) А может лучше вообще ничего не трогать?)

(70)
1. Конечно, не ты же а прог выполняет, поэтому для тебя это не проблема. У меня сейчас более 3-х десятков базу и при условии что в отчетный период 1С любит отзывать и штамповать обновления по 3-4 на недели ...

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

4. Т.е. необходимость перезахода в другие базы вас не смушает, а нажать F11 для вас тяжело?

(73) я вот это и пытаюсь выяснить )

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

(71) Главное чтобы мощности серваки и лицензий хватило, а так какая разница где лежат, правда если на вашем серваке, то тебе как админу, проще бекапить и обслуживать

(70)
"4. Необходимость постоянного выбора юрлица."
Проблема решена уже лет десять как. Используются значения для автоподстановки. Более того при использовании разделения данных за правильным назначением разделителя следит сама система.

"3. Возможность ошибок, т.е. тупо взяли и сделали документ по другому юрлицу и не заметили"
В режиме разделения сама система вам не даст такой возможности. Только зайти в базу под другим логином. см (66)

"1. Обновление это вообще не проблема. По моему опыту обновления требуются дай бог раз в квартал, а то и реже "
Это если у вас обновления только в связи с изменением законодательства. Если у вас имеют место постоянных "хотелки" (ваши же - бухгалтеров или руководителей) - обновлений может быть несколько за день.

(70) Когда много фирм то редко когда один бух ведет одну фирму  - обычно один бух ведет 2,3 фирмы (а фирм например не один десяток) то проще все таки в одной базе все это делать (выбор будет только тех фирм которые бух ведет - другие для него будут скрыты)

Скорость работы пользователей в одной базе скорее всего замедлится

+ (76) Или по РИБ полный образ себе тянут. У меня так.

(75) Таки плясать надо от потребностей руководства, желательно письменно оформленных. А потом уже думать, как эти желания/потребности реализовать.

(74)
1.Я же написал, что обновления на практике ставятся раз в квартал в лучшем случае. Тут твое удобство приводит к неудобству пользователей
3. Ф11 - это что за клавиша?
4. Не смущает. Никто за раз с 30 базами работать не будет
(78)
4. Автоподстановка это не то, она тут даже повредить может, а заход под другим логином - и смысл тогда в многофирменности
3. агналогично
1. И хотелки одинаковые для всех 30 фирм?

(73) А разве автору предложи на выбор "трогать\не трогать" ? :)

(83) нажми когда будешь в журнале документов. Кнопка появилась с выходом 2.0, в 3.0 тоже работает

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

(83) По поводу обновления. Везёт вам. А я на прошлой недели поставил 49.8 ибо народу уже срочно формы ФСС понадобились, а на этой недеи УЖЕ еще 2 релиза вышло. Ну никак у меня не выходит раз в квартал

(86) я имею в виду по ярлыку на каждый

(83) "1. И хотелки одинаковые для всех 30 фирм?"
Для тех бухгалтеров, которые "для сдачи отчетности" :

Если 1(одна) фирма, в которой несколько направлений
1. Химия (розница)
2. Химия (опт)
3. Галантерея, канцелярщина (розница)
4. Техника (розница)
5. Техника (опт)
На каждом направлении несколько менеджеров, несколько торговых точек. На каждой ТТ несколько касс и терминалов. Автопарк один. Складов грубо два (территориально, не помещений).  Бухгалтерия одна. Руководство одно. Центральная касса одна.
Отчетность как по каждому направлению своя, так же и консолидированная. Хотелки как от менеджеров так и от руководства сыпятся как из рога изобилия. Поддерживать конфигурации по каждому направлению в актуальном состоянии, да еще и синхронно с базой офиса уже задолбался. Мечтаю о единой базе.

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

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

(90) спасибо за понимание, да, после того как я озвучила минусы, встал вопрос именно о разных базах, но на ОДНОМ сервере. Вопрос сейчас в том, какова будет производительность, если клиент останется толстым??? потому что у нас БП 2.0, а тонкий и веб - на 3.0, переходить я боюсь!

как дополнить тему???

(89) А причем тут БП?

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

(94) А никто за БП и не говорил.
Точно так же на каждой ТТ своя база (периферийка). В офисе на сервере ЦБ. Отдельно база офиса.

+ (95) Могу привести миллион минусов такого построения.

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

(0) одни плюсы только, все минусы надуманные и решаются организационно

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

(92) а вот на 3.0 не надо бояться переходить) я своих перевел, нормально работают уже несколько месяцев, причем там довольно сложный учет финансового посредничества, ценных бумаг и другой всякой всячины. правда пришлось все изменения и дополнения переписывать под УП, но это совсем не трудно, если написано изначально правильно.

(97) Были на версии БП 1.6, потом многое допилили

(99) не, многофирменную уже не так уж и хочется руководству, на данный момент им не нравится момент администрирования НСИ, а консолидация им не нужна. важно лишь удобство и оперативность доступа. Фирмы у нас не в 1 здании, а в разных городах и даже областях.
да, у нас в том-то и дело что допиленная.  т.е. на 3.0 надо это все реализовывать почти что с нуля. я даже не знаю с какой стороны подступиться, с чего начать? конвертировать обычными средствами или писать обработки чтобы из рабочей базы 2.0 перетаскивать все в чистую 3.0.

Из минусов,если не говорили до этого:
-если полетит база,то сразу у всех юрлиц
-размер базы будет расти быстрее

(92) Мда, про производительность мы тут еще не успели подумать)
(101) Вечер перестает быть томным. Тут одним форумом не обойдешься никак

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

(101) Начать с того, что переход на 3.0 делается через объединение, то есть все добавленные программистом объекты метаданных легко сохраняются и их данные тоже, точно так же нужно позаботиться о целостности данных в новых и измененных реквизитах и табличных частях. Так вот после обновления у нас останутся все данные, надо будет только переписать код под УП и набросать управляемые формы. Ну и чтобы убедиться что всё работает - позакрывать месяцы в 2.0 и 3.0, должно всё совпадать. В общем суть такова, что проще всего подготовить конфигурацию на 3.0 со всеми доработками, а потом просто накатить её на 2.0. У меня сам процесс перехода занял пару часов, пользователи дискомфорта не испытывали)

(105) а конфигурация поставщика тут играет роль? я хотела по-нормальному попробовать, через поддержку-обновление, но конфигурация поставщика у нас оч старая, представьте сколько промежуточных надо поставить

разрешаю её грохнуть

(106) Конфигурацию поставщика обновлять просто долго, но лучше это сделать. Обновить через поддержку, в окне сравнения\объединения снять все галки. И таким образом чтобы сравнять с релизом основной конфигурации.

(108) - вот это не поняла: в окне сравнения\объединения снять все галки. так не объединится ж ничего.

(109) не объединится левое окошко (основная конфа) с правым (конфа из файла).  Конфа поставщика скрыта и обновится, тем не менее