Pull to refresh

Comments 20

в разделённой базе нельзя управлять регламентными заданиями (например, не получится автоматически обновить курсы валют)
.
Не понятно, что именно вы хотели добиться. У вас проблемы с разделенными регламентными заданиями или с общедоступными? На вашем скрине видно, что ни регламентные задания, ни регистр курсов валют вы не разделяли — т.е. у вас сейчас у всех компаний разделенной базы одна и та же информация. Более того, кто-то один может под себя исправить курс, а другие при закрытии месяца могут поймать необъяснимые курсовые разницы (гипотетически конечно; уверен — вы учли этот фактор).

Лично у меня в проектах разделение не прижилось — я его пытался использовать как только оно появилось в последних версиях 8.2, но оно там безбожно глючило и потом еще много версий разработчики чистили найденные баги (в том числе и с моих репортов). Но как я смутно помню из документации (кстати, зачем вам маркетинговая статья с сайта 1С и гугление, если есть хорошая детальная техническая документация???), то «урезанные» админы с установленным в параметрах сеанса правильными значениями разделителей спокойно могут видеть и управлять доступными им экземплярами регламентных заданий (так же как и делать локальные архивы *.dt только своих данных и потом восстанавливаться с них, при этом не беспокоя своих соседей по разделенной базе).
Проблема пока с регламентными заданиями, что оказались общими — они не видны в списке, только в режиме конфигуратора. Это затрудняет их настройку и отслеживание статуса.

По поводу необъяснимых глюков если кто-то что-то поправит — конечно мы об этом подумали — мы так не делаем =) Объяснение наверное звучит как то слабовато, но вы попробуйте, это правда работает!

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

В реальности, в режиме конфигуратора при входе в область вам недоступно ни одно действие, на любой чих вы получаете ошибку «Действие недоступно при установленном разделении данных» — ни открыть конфигурацию ни выгрузить в dt данные области это не позволяет. Возможно в более старых версиях это работало.
Я в этом деле понимаю мало… Но, как бы не сталось так, что: в скорости появится версия 1С 8.4. Что Вы будете творить со всеми этими «костылями»? — Я как Администратор, с 6ти летним опытом, уже пережил: 1с77,1с81,1с82. B скорости будет 1с83. А так конечно — очень, очень круто! Куча фирм, и всего 2гб в MSSQL, это-ж и бесплатной версией можно пользоваться для этого. :)
Смена версии платформы мало влияет на то что мы настроили.
Внутри версии 8.3 мы обновляем её прозрачно, с версии 8.2 на 8.3 я сам обновлял конфигурации через простую конвертацию (встроенную в конфигуратор), а на 8.4 если и нужно будет переходить, то либо будет тот же «конвертатор» — либо через перезагрузку в DT.
Дай Бог, дай Бог, чтобы такие вещи проходили «гладко». А то сами представляете, насколько это опасно всё.
Хозяйке на заметку: справочники и документы лучше выгружать отдельно — так можно избежать лишних ошибок в момент загрузки.

Тут тоже как-то непонятно… В чем сакральность разделения правил? Для гарантирования ссылочной целостности? Это просто нелепо! Тогда нужно и все документы-сделки вынести в отдельный файл правил. На самом деле никогда не было проблем с выгрузкой всех данных одним единым правилом. (заявляю как автор почти десятка работающих правил синхронизации данных между различными восьмерочными, а так же между семерочными и восьмерочными конфигурациями) Может вы хотите таким образом как-то сбалансировать объемы выгружаемых действий? Но мой опыт говорит, что размер первички в несколько порядков превышает данные НСИ. Так что вижу тут абсолютно бесполезное действие. Более того, вероятен человеческий фактор и вы как-нибудь сначала загрузите вторую пачку и получите либо справочники-пустышки, либо битые ссылки (в зависимости от настроек).
Вы не поверите… Но в какой то степени именно для сохранения ссылочной целостности! =)
При загрузке больших баз в разделённую область мы частенько ловили ошибки, переход на режим мухи отдельно от котлет справочники отдельно \ данные отдельно исправил такое поведение.

Загрузка у нас тоже вот вот будет в автоматическом режиме — что минимизирует человеческий фактор. Мне показалось что тема перелива данных через различные механизмы выходит за рамки статьи и\или заслуживает отдельной. И к тому же утверждать что мы что-то делаем не руками, когда на самом деле мы делаем это руками — не честно. Пишем как есть, если кто-то продвинется дальше нас (и потом ещё и статью напишет) будет здорово!
Формально, можно экономить на лицензиях, так как каждый бухгалтер будет запускать несколько копий одной базы, а не десяток разных.

Не очень понятно как происходит экономия лицензий. Если у вас лицензии раздает сервер, один сеанс будет использовать одну лицензию. И неважно отдельные это базы или одна разделенная.
Экономить на лицензиях можно менеджером лицензий. Если им раздавать лицензии, одна лицензия действует на один клиентский компьютер независимо от количества открытых баз или количества открытых сеансов.
Спасибо за замечание. Почитал ещё раз условия лицензионного соглашения, согласен с вами — наш текст звучит не однозначно (и скорее всего релевантный только для наших условий). Внесу правки в статью.
Немного не по теме вопрос.
Подскажите пожалуйста, как лучше организовать базы в 1с, если в одной сети сосуществуют две организации (но с одним общим гендиром, главбухом). Вести учет в одной базе, но по различным организациям или завести две отдельные базы?
Думаю переход в одну базу, не важно разделённую или нет, зависит скорее от:
1. Как ведётся учёт в этих организациях? Одинакового или нет?
2. Одинаков ли план счетов?
3. Кто работает с базами, один и те же пользователи?
4. Нужно ли видеть сводные отчёты, сальдооборотки?
Если на все пункты (наверняка это не всё, но больше я сходу не могу припомнить) ответ «нет» — то лучше не объединять.
Плюс нужно учесть размеры баз, если большие — то лучше не объединять.

Так же советую поговорить об этом с бухгалтером — она, наверняка, может сказать свои доводы, к которым стоит прислушаться.
ОК. Спасибо за список. Будем думать.
Исследовал в свое время возможности разделения данных в БСП-подобных конфигурациях. В БСП есть встроенные механизмы выгрузки и загрузки данных в область.
Выгрузка через ОбщаяФорма.ВыгрузкаДанных, загрузка через ОбщаяКоманда.ЗагрузитьДанныеВОбласть

Не нашел один момент. Может вы сталкивались. Существует ли возможность выполнения запроса по нескольким разделенным областям из сеанса с выключенным разделением?
Вот ответ от нашей замечательной программистки:
«Если разделитель включен в режиме „независимо“, тогда возможности обратиться в одном запросе к нескольким разделенным областям нет. Надеемся, что в ближайших релизах платформы такая возможность появится.»
А вот если бы 1С была устроена немного иначе. Скажем, каждая база не содержала бы метаданные, а только хранила бы данные пользователей. А конфигурация располагалась бы на сервере где-то в другом месте (в файлах md как в 7.7 или на SQL сервере в отдельной базе метаданных).
Тогда можно будет создавать несколько баз одной конфигурации, а при обновлении конфигурации чтобы проходило автоматическое обновление всех баз этой конфигурации.
И еще так же отдельно хранились бы пользователи.
Разделение данных именно для этого и создано. Данные многих организаций лежат в одной общей для них конфигурации. Пользователей так же можно разделить. Не мечта — но вполне себе съедобный кактус.
В случае отдельных баз могли бы решиться некоторые проблемы, например эти:
• если кто-то из пользователей запорол данные в одной организации, приходится откатывать назад всю разделённую базу — нельзя просто взять и откатить одну область данных
• если нужно передать базу клиенту (или слить налоговой:), приходится делать обратную процедуру: выгружать организацию из разделённой базы при помощи универсального обмена, затем загружать в пустую обычную базу и из неё сохранять в.dt-файл
А кто-нибудь экспериментировал с вьюхами на КЛАДР в соседней, специально выделенной базе (вместо отдельных таблиц в каждой из используемых баз)?
Вы не сталкивались с ситуациями, когда на реальных данных в работающей базе:
1. Нужно разделенный по областям данным объект (например, регистр накопления) сделать общим.
2. Обратная операция — нужно общий объект, разделить по областям данных.
Как вы действуете в этом случае?
… очень не рекомендую менять структуру данных уже после начала эксплуатации. В целом сказать, что случится в вашем случае сложно, но мы пару раз ловили после обновления такое:
1. Слетели проводки части документов во всех или некоторых областях
2. Наши разделённые объекты вдруг стали общими — те что мы разделили потерялись
3. Наши общие объекты улетели в одну из областей — остальные области перестали запускаться.

Всё это конечно фиксится и довольно малой кровью, но не приятно. В общем мы сейчас более совершенный способ работы используем. Не могу про него пока написать (надеюсь скоро запилю статью).
Sign up to leave a comment.