По теме из базы знаний
- Разделение базы Бухгалтерии 3.0 по организациям на отдельные базы
- Выделение нескольких организаций из базы через удаление
- Перенос организации в отдельную базу, полная очистка базы от данных организации (версия от 10.02.2022)
- Пометка на удаление объектов (документов и элементов справочников, записей регистров сведений), реквизиты которых ссылаются на объекты от которых избавляем базу. Инструмент для обеспечения непосредственного удаления.
- Помощник загрузки отчетности в разделенную базу данных 1С: БГУ 2.0 в корпоративном облаке 1cfresh
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Воспользуйся типовыми обработками от 1с и перенеси доки и спр одной фирмы, тока сделай обязательно бекап перед перебросом, можно в принципе удалить доки одной фирмы из копии базы и получится база с одной фирмой) конечно если есть обработка или много времени то можно ручками)
(14) Borisych, А есть обработка, которая удаляет все данные не проверяю целостность ссылочной информации?
Оказалось, что в базе не одна организация, а семь. И не могу удалить шесть не нужных, т.к. они ссылаются на одних и тех же контрагентов, договора и тп.
Может есть другой способ выделить одну организацию в отдельную базу?
Оказалось, что в базе не одна организация, а семь. И не могу удалить шесть не нужных, т.к. они ссылаются на одних и тех же контрагентов, договора и тп.
Может есть другой способ выделить одну организацию в отдельную базу?
Создаешь узел РИБ по плану обмена "По организации" для нужной из семи. потом запускаешь обработку - и создаешь первоначальный образ. И всё тип-топ
Прикрепленные файлы:
Запись всех объектов по организации.epf
Операции - Планы обмена - По организации - у существующего узла установит код, добавить - в табличной части указать нужную организацию. Записать. Запустить обработку - выбрав нужную организацию. Потом в форме списка планов обмена установить курсор на созданный узел и наверху кнопка "Создать первоначальный образ" - получится почка рабочей базы с данными только по выбранной организации
(22) Borisych, респект тебе и уважуха!!!!
Парочка вопросов. А для чего эта обработка.
Сделал так:
1. Операции - Планы обмена - По организации
2. Нажал добавить. Присвоил код (просто от балды написал "О") и в табличной части добавил Организацию.
3. В панели выбрал "Создать начальный образ", указал путь.
После пяти минут (база 2 гига) в указанном каталоге появилась база по выбранной организации, со всеми документами и справочниками размером 533 МБ. Оборотная-сальдовые ведомости сходятся.
Парочка вопросов. А для чего эта обработка.
Сделал так:
1. Операции - Планы обмена - По организации
2. Нажал добавить. Присвоил код (просто от балды написал "О") и в табличной части добавил Организацию.
3. В панели выбрал "Создать начальный образ", указал путь.
После пяти минут (база 2 гига) в указанном каталоге появилась база по выбранной организации, со всеми документами и справочниками размером 533 МБ. Оборотная-сальдовые ведомости сходятся.
theCoder пишет:
Базу перенес. Оказалось что в ней ошибки.
Только возникла маленькая проблема. В журналах и документах не дает выбрать организацию - выделено серым цветом.
Может кто знает как исправить?
Базу перенес. Оказалось что в ней ошибки.
Только возникла маленькая проблема. В журналах и документах не дает выбрать организацию - выделено серым цветом.
Может кто знает как исправить?
Перед переносом - проделать стандартную процедуру - чистку и проверку базы. Не должно быть помеченных и не удаленных объектов, база протестирована и сжата.
З.Ы. Borisych зачот! :) Весьма оригинальное и красивое решение! До меня не дошло... удалял подчиненные доки. :)
Вчера не смог отправить - вырубили свет и из-за этого интернет только к обеду восстановили
Эта обработка сделает из почки самостоятельную базу.
Эта обработка сделает из почки самостоятельную базу.
Прикрепленные файлы:
Действия по УРБД (РИБ).epf
Сделал так:
1. Операции - Планы обмена - По организации
2. Нажал добавить. Присвоил код (просто от балды написал "О") и в табличной части добавил Организацию.
3. В панели выбрал "Создать начальный образ", указал путь.
После пяти минут (база 2 гига) в указанном каталоге появилась база по выбранной организации, со всеми документами и справочниками размером 533 МБ. Оборотная-сальдовые ведомости сходятся.
Теперь не могу делать обновления.
Появился значок "Восклицательный знак с замочком" - Изменения конфигурации заблокированы средствами управления распределенной ИБ.
Как вернуть возможность обновления???????
1. Операции - Планы обмена - По организации
2. Нажал добавить. Присвоил код (просто от балды написал "О") и в табличной части добавил Организацию.
3. В панели выбрал "Создать начальный образ", указал путь.
После пяти минут (база 2 гига) в указанном каталоге появилась база по выбранной организации, со всеми документами и справочниками размером 533 МБ. Оборотная-сальдовые ведомости сходятся.
Теперь не могу делать обновления.
Появился значок "Восклицательный знак с замочком" - Изменения конфигурации заблокированы средствами управления распределенной ИБ.
Как вернуть возможность обновления???????
Механизм разделения данных
Наиболее серьезным и даже в некотором смысле революционным новшеством версии 8.2.14 стал механизм разделения данных, позволяющий разделять единую информационную базу «1С:Предприятия» на отдельные изолированные области и реализовывать такие сценарии, при которых пользователи будут работать в единой базе, но независимо друг от друга.
Для каких задач автоматизации может потребоваться такой механизм? Вот несколько типичных примеров.
Пример первый — компания предоставляет услуги бухгалтерского обслуживания. Каждый из бухгалтеров, находящихся в штате компании, ведет фискальный учет нескольких сторонних организаций, в качестве прикладного решения используется типовая конфигурация «Бухгалтерия предприятия». Понятно, что каждый из бухгалтеров должен обладать полным доступом к данным своих подопечных предприятий, но ему абсолютно незачем иметь доступ к данным других обслуживаемых компанией организаций даже на чтение.
Пример второй — компания предоставляет услуги аренды ПО по модели SaaS («software as a service», программное обеспечение как услуга). В качестве прикладного решения используется одна из типовых или отраслевых конфигураций «1С:Предприятия». Например, бизнес-центр может предложить своим арендаторам функциональность прикладного решения «Управление небольшой фирмой», полностью взяв на себя заботы о серверном оборудовании, поддержке работоспособности, регламентном обслуживании, установке новых версий конфигурации и т.?д. Пользователями прикладного решения являются посторонние друг для друга организации — они, разумеется, должны иметь доступ только к своим собственным данным.
Пример третий, из текущей практики автора, — расчетно-кассовый центр предоставляет услуги биллинга и приема платежей. Прикладным решением служит конфигурация собственной разработки, пользователи — также сторонние и независимые друг от друга организации. Какие-то данные будут общими для всех пользователей (классификаторы, тарифы, нормативы), какие-то будут персональной собственностью пользователя (начисления, расчеты, платежи). Пользователи должны сосуществовать в едином информационном пространстве расчетного центра, но не иметь доступа к «чужой» информации.
Следует заметить, что в приведенных примерах, кроме, пожалуй, первого, собственно разграничение доступа к данным не является единственным, и, возможно, даже главным требованием. Это требование, по мнению автора, наиболее очевидно с точки зрения потребностей бизнеса, но с технической точки зрения не менее важно требование обеспечения такой архитектуры прикладного решения, при которой деятельность одного абонента не будет создавать технологических противоречий и помех деятельности других абонентов.
Нельзя сказать, что подобные задачи на платформе «1С:Предприятие» вообще невозможно было решить без специального механизма разделения данных. Разграничение доступа реализовать можно было и ранее, причем двумя принципиально разными способами.
Простое решение: развернуть для каждого пользователя (под пользователем здесь понимается именно предприятие-пользователь, а не отдельно взятый оператор) свою информационную базу, а взаимодействие между ними реализовать посредством механизмов интеграции, имеющихся в платформе. Например, задействовать механизм распределенной информационной базы (РИБ). В литературе по информационным технологиям такая архитектура определяется термином «multiinstance» (множественные экземпляры).
Это действительно очень простое решение, но оно обладает рядом серьезных недостатков. Во-первых, поддерживать и администрировать множество информационных баз значительно сложнее и дороже, чем одну. Во-вторых, регламентные процедуры (например, обновление индекса полнотекстового поиска или резервное копирование) также будут выполняться в каждой информационной базе, а это создаст дополнительную нагрузку на оборудование. В-третьих, практически всегда существуют какие-то общие для всех пользователей данные (в простейшем случае — классификатор банков и адресный классификатор). Эти данные необходимо хранить и поддерживать в актуальном состоянии в каждой информационной базе, как следствие — нужно будет позаботиться о синхронизации (не говоря о том, что разместить одну и ту же таблицу КЛАДР в сотнях баз данных явно не очень хорошая идея с точки зрения эффективного использования аппаратных ресурсов).
Наконец, в некоторых задачах «суперпользователю» (предприятию-владельцу информационного пространства) требуется работать со всей совокупностью данных как с единым целым, например, расчетному центру, как минимум, нужно формировать консолидированную отчетность. Реализация такого требования влечет за собой как интенсивный обмен данными между узлами РИБ (что опять же означает дополнительную нагрузку на оборудование), так и дублирование данных не менее чем в двух разных базах.
Более сложное, но конструктивно более правильное решение — работать с единой информационной базой, а для изоляции «персональных областей данных пользователей» друг от друга использовать механизм RLS (Record Level Security, доступ на уровне записей). Преимущества этого решения зеркально повторяют недостатки первого:
1. Администрировать и поддерживать нужно только одну информационную базу.
2. Все регламентные процедуры выполняются только в одной информационной базе, не создавая лишней нагрузки на оборудование.
3. Общие данные не дублируются и всегда актуальны для всех пользователей.
4. Для «консолидированных» операций над полной совокупностью данных не требуется выполнять постоянную синхронизацию, и данные не дублируются.
При этом пользователи-абоненты имеют доступ только к «своим» данным и могут даже не подозревать о наличии в системе данных других пользователей. Такая архитектура называется «multitenancy» (множественная аренда) — единый экземпляр прикладного решения обслуживает множество независимых абонентов.
Собственно, именно такую архитектуру и обеспечивает новый механизм разделения данных, реализованный в версии 8.2.14 «1С:Предприятия». В чем же заключается принципиальная разница? Принципиальная разница — в технической реализации разграничения доступа.
Механизм RLS в «1С:Предприятии» работает следующим образом: для совокупности сущностей «объект метаданных, роль, право доступа» разработчик конфигурации описывает дополнительные ограничения доступа к данным. Ограничения описываются на языке запросов и могут представлять собой довольно сложные конструкции. При работе пользователя с объектами данных информационной базы стандартные запросы, выполняемые платформой в СУБД, дополняются запросами RLS. Например, если в RLS задано ограничение «роль Кладовщик имеет право чтения документа Накладная только в том случае, если пользователь прикреплен к нужному складу», в любой запрос СУБД, выполняющий чтение соответствующих таблиц, будет добавляться соответствующее условие.
Этот механизм был реализован еще в «1С:Предприятии 8.0», и он весьма эффективен при правильном применении по назначению — в тех случаях, когда требуется ограничить доступ некоторых пользователей к некоторым объектам данных по некоторым, причем весьма разнообразным в разных случаях, правилам. Скажем, менеджер по продажам имеет доступ на изменение только своих сделок, или руководитель подразделения не имеет права читать ежедневные отчеты сотрудников других подразделений.
Но в нашем случае придется установить RLS-ограничения на доступ всех пользователей ко всем объектам данных. На практике это означает следующее:
1. Потребуется выполнить огромный объем работ по настройке, отладке и тестированию RLS-ограничений практически для каждого объекта метаданных конфигурации (а они могут измеряться многими сотнями).
2. Нагрузка на СУБД при выполнении запросов к данным, «обернутым» RLS-ограничениями, существенно увеличивается. Как следствие — падает производительность при параллельной работе множества пользователей.
Новый механизм разделения данных позволяет полноценно реализовать multitenancy-архитектуру прикладного решения, когда разграничивается не только доступ к данным информационной базы, но и использование других механизмов технологической платформы.
Подробный технический разбор механизма разделения данных выходит за рамки статьи, поэтому мы рассмотрим только наиболее важный, с нашей точки зрения, момент — ограничение доступа к данным. В отличие от RLS, при использовании механизмов разделения данные информационной базы разделяются на области без внесения существенных изменений в конфигурацию и практически без потерь производительности. Благодаря чему это достигается?
1. В платформе появился новый объект метаданных — общий реквизит. Такой реквизит может быть включен в состав практически любого прикладного объекта, отвечающего за хранение данных (справочник, документ, план счетов, бизнес-процесс и т.?д.), установкой одного флажка.
2. У общего реквизита есть свойство «Разделение данных», установка которого превращает общий реквизит в разделитель данных. Соответственно все прикладные объекты, включенные в состав общего реквизита, также переходят в режим разделения данных.
3. В конфигурации может быть определено любое количество разделителей, причем для каждого можно настроить условие, при котором он считается действующим. Соответственно можно реализовывать сколь угодно гибкие схемы выделения и изоляции областей данных внутри информационной базы. Причем как для уникальных решений, так и для тиражных, которые должны уметь переключаться между разделяемым и автономным режимами без изменения конфигурации, посредством параметрической настройки.
4. В отличие от механизма RLS, который оперирует ограничениями конкретных прав доступа для конкретных ролей (скажем, можно запретить чтение, но разрешить изменение объекта), логика механизма разделения данных значительно проще: объект или входит в область данных, доступную пользователю, или не входит.
5. Структура хранения разделителей данных в СУБД спроектирована таким образом, чтобы оказывать минимальное влияние на производительность параллельной работы множества пользователей с разделенными данными.
Следует уточнить, что механизм разделения данных никоим образом не подменяет механизмы ролей, прав и ограничений доступа, а дополняет их. Если объект входит в область, доступную пользователю, но пользователь не обладает необходимой ролью и/или не выполняется условие соответствующего ограничения RLS — доступа к объекту пользователь не получит.
Отдельно следует отметить разделение пользователей информационной базы. Разделители данных можно настроить таким образом, что пользователю будет доступна только та часть общего списка пользователей информационной базы, которая принадлежит к доступной области данных. Более того, если задействовать свойство «Разделение аутентификации», то в разных областях данных можно создавать одноименных пользователей — при обычной практике «именем пользователя в базе является его фамилия, иногда дополненная инициалами», такое свойство разделителя данных представляется крайне полезным.
Наиболее серьезным и даже в некотором смысле революционным новшеством версии 8.2.14 стал механизм разделения данных, позволяющий разделять единую информационную базу «1С:Предприятия» на отдельные изолированные области и реализовывать такие сценарии, при которых пользователи будут работать в единой базе, но независимо друг от друга.
Для каких задач автоматизации может потребоваться такой механизм? Вот несколько типичных примеров.
Пример первый — компания предоставляет услуги бухгалтерского обслуживания. Каждый из бухгалтеров, находящихся в штате компании, ведет фискальный учет нескольких сторонних организаций, в качестве прикладного решения используется типовая конфигурация «Бухгалтерия предприятия». Понятно, что каждый из бухгалтеров должен обладать полным доступом к данным своих подопечных предприятий, но ему абсолютно незачем иметь доступ к данным других обслуживаемых компанией организаций даже на чтение.
Пример второй — компания предоставляет услуги аренды ПО по модели SaaS («software as a service», программное обеспечение как услуга). В качестве прикладного решения используется одна из типовых или отраслевых конфигураций «1С:Предприятия». Например, бизнес-центр может предложить своим арендаторам функциональность прикладного решения «Управление небольшой фирмой», полностью взяв на себя заботы о серверном оборудовании, поддержке работоспособности, регламентном обслуживании, установке новых версий конфигурации и т.?д. Пользователями прикладного решения являются посторонние друг для друга организации — они, разумеется, должны иметь доступ только к своим собственным данным.
Пример третий, из текущей практики автора, — расчетно-кассовый центр предоставляет услуги биллинга и приема платежей. Прикладным решением служит конфигурация собственной разработки, пользователи — также сторонние и независимые друг от друга организации. Какие-то данные будут общими для всех пользователей (классификаторы, тарифы, нормативы), какие-то будут персональной собственностью пользователя (начисления, расчеты, платежи). Пользователи должны сосуществовать в едином информационном пространстве расчетного центра, но не иметь доступа к «чужой» информации.
Следует заметить, что в приведенных примерах, кроме, пожалуй, первого, собственно разграничение доступа к данным не является единственным, и, возможно, даже главным требованием. Это требование, по мнению автора, наиболее очевидно с точки зрения потребностей бизнеса, но с технической точки зрения не менее важно требование обеспечения такой архитектуры прикладного решения, при которой деятельность одного абонента не будет создавать технологических противоречий и помех деятельности других абонентов.
Нельзя сказать, что подобные задачи на платформе «1С:Предприятие» вообще невозможно было решить без специального механизма разделения данных. Разграничение доступа реализовать можно было и ранее, причем двумя принципиально разными способами.
Простое решение: развернуть для каждого пользователя (под пользователем здесь понимается именно предприятие-пользователь, а не отдельно взятый оператор) свою информационную базу, а взаимодействие между ними реализовать посредством механизмов интеграции, имеющихся в платформе. Например, задействовать механизм распределенной информационной базы (РИБ). В литературе по информационным технологиям такая архитектура определяется термином «multiinstance» (множественные экземпляры).
Это действительно очень простое решение, но оно обладает рядом серьезных недостатков. Во-первых, поддерживать и администрировать множество информационных баз значительно сложнее и дороже, чем одну. Во-вторых, регламентные процедуры (например, обновление индекса полнотекстового поиска или резервное копирование) также будут выполняться в каждой информационной базе, а это создаст дополнительную нагрузку на оборудование. В-третьих, практически всегда существуют какие-то общие для всех пользователей данные (в простейшем случае — классификатор банков и адресный классификатор). Эти данные необходимо хранить и поддерживать в актуальном состоянии в каждой информационной базе, как следствие — нужно будет позаботиться о синхронизации (не говоря о том, что разместить одну и ту же таблицу КЛАДР в сотнях баз данных явно не очень хорошая идея с точки зрения эффективного использования аппаратных ресурсов).
Наконец, в некоторых задачах «суперпользователю» (предприятию-владельцу информационного пространства) требуется работать со всей совокупностью данных как с единым целым, например, расчетному центру, как минимум, нужно формировать консолидированную отчетность. Реализация такого требования влечет за собой как интенсивный обмен данными между узлами РИБ (что опять же означает дополнительную нагрузку на оборудование), так и дублирование данных не менее чем в двух разных базах.
Более сложное, но конструктивно более правильное решение — работать с единой информационной базой, а для изоляции «персональных областей данных пользователей» друг от друга использовать механизм RLS (Record Level Security, доступ на уровне записей). Преимущества этого решения зеркально повторяют недостатки первого:
1. Администрировать и поддерживать нужно только одну информационную базу.
2. Все регламентные процедуры выполняются только в одной информационной базе, не создавая лишней нагрузки на оборудование.
3. Общие данные не дублируются и всегда актуальны для всех пользователей.
4. Для «консолидированных» операций над полной совокупностью данных не требуется выполнять постоянную синхронизацию, и данные не дублируются.
При этом пользователи-абоненты имеют доступ только к «своим» данным и могут даже не подозревать о наличии в системе данных других пользователей. Такая архитектура называется «multitenancy» (множественная аренда) — единый экземпляр прикладного решения обслуживает множество независимых абонентов.
Собственно, именно такую архитектуру и обеспечивает новый механизм разделения данных, реализованный в версии 8.2.14 «1С:Предприятия». В чем же заключается принципиальная разница? Принципиальная разница — в технической реализации разграничения доступа.
Механизм RLS в «1С:Предприятии» работает следующим образом: для совокупности сущностей «объект метаданных, роль, право доступа» разработчик конфигурации описывает дополнительные ограничения доступа к данным. Ограничения описываются на языке запросов и могут представлять собой довольно сложные конструкции. При работе пользователя с объектами данных информационной базы стандартные запросы, выполняемые платформой в СУБД, дополняются запросами RLS. Например, если в RLS задано ограничение «роль Кладовщик имеет право чтения документа Накладная только в том случае, если пользователь прикреплен к нужному складу», в любой запрос СУБД, выполняющий чтение соответствующих таблиц, будет добавляться соответствующее условие.
Этот механизм был реализован еще в «1С:Предприятии 8.0», и он весьма эффективен при правильном применении по назначению — в тех случаях, когда требуется ограничить доступ некоторых пользователей к некоторым объектам данных по некоторым, причем весьма разнообразным в разных случаях, правилам. Скажем, менеджер по продажам имеет доступ на изменение только своих сделок, или руководитель подразделения не имеет права читать ежедневные отчеты сотрудников других подразделений.
Но в нашем случае придется установить RLS-ограничения на доступ всех пользователей ко всем объектам данных. На практике это означает следующее:
1. Потребуется выполнить огромный объем работ по настройке, отладке и тестированию RLS-ограничений практически для каждого объекта метаданных конфигурации (а они могут измеряться многими сотнями).
2. Нагрузка на СУБД при выполнении запросов к данным, «обернутым» RLS-ограничениями, существенно увеличивается. Как следствие — падает производительность при параллельной работе множества пользователей.
Новый механизм разделения данных позволяет полноценно реализовать multitenancy-архитектуру прикладного решения, когда разграничивается не только доступ к данным информационной базы, но и использование других механизмов технологической платформы.
Подробный технический разбор механизма разделения данных выходит за рамки статьи, поэтому мы рассмотрим только наиболее важный, с нашей точки зрения, момент — ограничение доступа к данным. В отличие от RLS, при использовании механизмов разделения данные информационной базы разделяются на области без внесения существенных изменений в конфигурацию и практически без потерь производительности. Благодаря чему это достигается?
1. В платформе появился новый объект метаданных — общий реквизит. Такой реквизит может быть включен в состав практически любого прикладного объекта, отвечающего за хранение данных (справочник, документ, план счетов, бизнес-процесс и т.?д.), установкой одного флажка.
2. У общего реквизита есть свойство «Разделение данных», установка которого превращает общий реквизит в разделитель данных. Соответственно все прикладные объекты, включенные в состав общего реквизита, также переходят в режим разделения данных.
3. В конфигурации может быть определено любое количество разделителей, причем для каждого можно настроить условие, при котором он считается действующим. Соответственно можно реализовывать сколь угодно гибкие схемы выделения и изоляции областей данных внутри информационной базы. Причем как для уникальных решений, так и для тиражных, которые должны уметь переключаться между разделяемым и автономным режимами без изменения конфигурации, посредством параметрической настройки.
4. В отличие от механизма RLS, который оперирует ограничениями конкретных прав доступа для конкретных ролей (скажем, можно запретить чтение, но разрешить изменение объекта), логика механизма разделения данных значительно проще: объект или входит в область данных, доступную пользователю, или не входит.
5. Структура хранения разделителей данных в СУБД спроектирована таким образом, чтобы оказывать минимальное влияние на производительность параллельной работы множества пользователей с разделенными данными.
Следует уточнить, что механизм разделения данных никоим образом не подменяет механизмы ролей, прав и ограничений доступа, а дополняет их. Если объект входит в область, доступную пользователю, но пользователь не обладает необходимой ролью и/или не выполняется условие соответствующего ограничения RLS — доступа к объекту пользователь не получит.
Отдельно следует отметить разделение пользователей информационной базы. Разделители данных можно настроить таким образом, что пользователю будет доступна только та часть общего списка пользователей информационной базы, которая принадлежит к доступной области данных. Более того, если задействовать свойство «Разделение аутентификации», то в разных областях данных можно создавать одноименных пользователей — при обычной практике «именем пользователя в базе является его фамилия, иногда дополненная инициалами», такое свойство разделителя данных представляется крайне полезным.
ВыгрузкаЗагрузкаДанныхXML81.epf, есть и для 8,0 8,2. Создаешь пустую базу, запускаешь обработку в источнике с отбором по организации. Выгружаешь данные. В пустой базе запускаешь ее же. Делаешь загрузку. Все. Для одинаковых баз проблем нет. Обработка на дисках итс есть.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот