Настройка ролей и прав доступа
Область применения: управляемое приложение, обычное приложение.
Действует для конфигураций УП (ERP), УТ 11 и входящих в них библиотек.
Для других конфигураций рекомендуется к использованию.
Содержит уточнения к требованиям других стандартов.
1. Общие положения
1.1. Роли создаются «атомарными», т.е. дающими права на доступ к элементарным функциям программы. Из этих элементарных ролей создаются профили пользователей, которые уже и назначаются пользователям средствами БСП. Деление прав на доступ к объектам между функциями должно быть таким, чтобы на типовом внедрении не возникало необходимости в создании новых ролей.
Исключение: для ролей, назначаемых внешним пользователям, задается исчерпывающий набор прав к необходимым объектам.
Например, в УП(ERP) это роль ПартнерСамообслуживание .
1.2. Роль ПолныеПрава (англ. FullAccess ) совместно с ролью АдминистраторСистемы (англ. SystemAdministrator ) дает неограниченный доступ (без RLS) ко всем объектам. См. стандартные роли.
1.3. Ни одна роль (в т.ч. ПолныеПрава и АдминистраторСистемы ) не должна давать право на интерактивное удаление ссылочных объектов.
- после создания нового объекта нужно зайти в роль ПолныеПрава и отключить право интерактивного удаления у ссылочных объектов.
1.4. Только роль ПолныеПрава и АдминистраторСистемы должна давать право на удаление ссылочных объектов.
1.5. Только для роли ПолныеПрава должен быть установлен флаг «Устанавливать права для новых объектов». Для всех остальных ролей этот флаг должен быть снят.
1.6. Если какое-то право может быть использовано только администратором системы (например, использование какого-то отчета или обработки), то достаточно, чтобы это предоставлялось одной из ролей ПолныеПрава и АдминистраторСистемы , создавать отдельные роли в этом случае не требуется.
1.7. Во всех документах, предполагающих проведение, должны быть выставлены флаги «Привилегированный режим при проведении» и «Привилегированный режим при отмене проведения», поэтому не нужно создавать роли, дающие права на изменение регистров, подчиненных регистраторам.
Исключение: документы, предназначенные для непосредственной корректировки записей регистров, могут проводиться с проверкой прав доступа, но в этом случае необходимо предусмотреть роли, дающие права на изменение регистров.
1.8. Во всех функциональных опциях должны быть выставлены флаги «Привилегированный режим при получении».
Исключение: в конфигурации могут быть предусмотрены параметризированные ФО, для которых разработчик специально предусматривает различия в получаемых значениях пользователями с разными правами.
Пример: Есть параметризованная ФО ИспользоватьВалютуПриРасчетеСПерсоналом , которая параметризуется организацией. Если пользователь будет получать ее значение в контексте своих прав, то он не увидит поле «валюта» в документе, если у него нет ни одной организации, где применяется валютный учет.
1.9. Не должно быть ролей, кроме стандартных ролей БСП, которые дают общие права (такие как Администрирование , ТонкийКлиент и т.п.).
- при создании новой роли нужно следить, чтобы эти права были выключены.
1.10. В отдельных случаях для неконфиденциальных данных и общедоступных функций не требуется создавать отдельную роль на чтение (а также просмотр и ввод по строке — для ссылочных данных), а следует включать эти права в роли БазовыеПрава (англ. BasicAccess ) и БазовыеПраваВнешнихПользователей (англ. BasicAccessExternalUser ) (эта роль необходима только если в конфигурации предусмотрена работа с внешними пользователями). Например, это константы, общенациональные классификаторы, общие формы выбора периода, ввода контактной информации и др.
1.11. Не допускается, чтобы одна роль давала права на объекты, которые относятся к другим подсистемам.
Например, в хранилище УП (ERP) нельзя, чтобы одна роль давала права на объекты, которые есть в УТ 11 и на объекты, которых в УТ 11 нет. См. также: Разработка ролей в библиотеках.
2. Правила создания ролей к элементарным функциям
2.1. Объекты, при проектировании прав доступа, необходимо объединить в элементарные функции. Если объекты входят в одну функцию, то это означает, что не может быть задачи, когда доступ к этим объектам может быть разный.
Пример:
Есть документ «Заказ клиента» и связанный с ним регистр накопления «Заказы клиентов», который хранит остатки неотгруженных товаров и неоплаченных сумм. По сути этот регистр является отражением текущего состояния табличной части заказа. Если пользователь имеет права на документ, то будет странно, что он не будет иметь прав на регистр. Поэтому документ «Заказ клиента» и регистр накопления «Заказы клиентов» можно объединить в одну элементарную функцию. Если есть отчет, отображающий в удобном виде остатки регистра «Заказы клиентов», то логично его тоже включить в эту функцию.
Противоположный пример:
Есть документ «Реализация товаров и услуг», выступающий в роли распоряжения на отгрузку товаров. Остатки по распоряжениям на отгрузку товаров хранит регистр накопления «Товары к отгрузке». Объединять «Реализацию товаров и услуг» и регистр «Товары к отгрузке» в рамках одной функции было бы не правильно, т.к., например, кладовщик, вполне может иметь права на чтение регистра «Товары к отгрузке», но может не иметь прав на чтение документа «Реализация товаров и услуг».
2.2. В случае если возникают сомнения в том, что два объекта могут быть отнесены к одной элементарной функции, лучше выделить их в разные.
2.3. Каждый объект должен быть отнесен к элементарной функции, и только к одной.
2.4. Объекты, относящиеся к разным библиотекам не могут быть отнесены к одной элементарной функции.
3. Ссылочные объекты и регистры
3.1. Для функций, включающих в себя ссылочные объекты и независимые регистры сведений, должно быть создано две роли
- Чтение (англ. Read );
- ДобавлениеИзменение (англ. AddEdit ) или Изменение (англ. Edit ), если добавление выполняется автоматически, либо только администратором.
Роли должны содержать следующие права (когда они имеются у объекта метаданных):
Настройка прав пользователей на управляемых формах в 1С 8.3
Задача: создать роль с ограниченными правами. Запретить редактирование проведенных документов.
Среда: 1С Предприятие «Комплексная автоматизация 2.4» на управляемых формах.
Исходя из поставленной задачи, нам необходимо создать в базе данных роль, при которой пользователь сможет свободно заходить и пользоваться всеми основными функциями программы, но при этом у него будет запрет на редактирование проведенных документов. В нашем случае документа «Реализация товаров и услуг». Приведенный пример настройки прав является базовым (универсальным) и может быть взят за основу как пример для настройки прав в других конфигурациях на управляемых формах (интерфейс такси/не такси) и других документов, а не только «Реализация товаров и услуг». В процессе настройки прав мы сталкивались со специфическими особенностями конфигурации, описывали такие ситуации и способы решения. Не исключено, что с настройкой прав других документов будут другие исключительные ситуации. С этими вопросами вам придется разбираться точечно и самостоятельно.
ОЧЕНЬ МНОГО СТАНДАРТНЫХ РОЛЕЙ
Когда мы зашли в конфигуратор, то увидели порядка 1280 стандартных ролей. Ожидали, конечно, что 1С добавит дополнительный функционал, но что «рассиропит» настройку прав на 1280 ролей — не думали. Конечно, у каждого администратора 1С при наличии стольких стандартных ролей возникнет закономерный вопрос: «А как из 1280 выбрать нужные?». Действительно, задача не простая, но мы нашли ключ к решению проблемы. Мы решили действовать как скульпторы — взять камень и отсечь все лишне.
Мы подумали, что гораздо легче и правильнее взять полную версию прав и ее урезать, чем комбинировать различные наборы ролей из 1280 пытаясь угадать с помощью многократной проверки результата. Поэтому был выбран алгоритм копирования роли «Полные права» и постепенное сужение прав на определенных участках.
На примере документа «Реализация товаров и услуг» мы покажем вам, как отредактировать права таким образом, чтобы пользователь мог создать, провести, просмотреть и распечатать документ и не мог его отредактировать после проведения.
НАСТРОЙКА РОЛИ С ОГРАНИЧЕННЫМИ ПРАВАМИ
1. Копируем роль «Полные права» и переименовываем ее как угодно. В нашем случае мы переименовали роль в «Менеджер РП» (менеджер регионального представительства). Сразу дадим краткую справку относительно настройки ролей пользователей в конфигурациях на управляемых формах, так как есть различия в настройках по отношению к предыдущим конфигурациям. Первое, самое важное, то что создавать пользователей и назначение ролей в новых версиях 1С нужно производить НЕ в Конфигураторе, а в 1С Предприятие. Второе, то что помимо ролей в режиме 1С предприятия появились «Профили», которые являются неким шаблоном, набором прав для должности, типа: Менеджер по продажам, Менеджер по закупкам, Бухгалтер и т.д. Третье, то что в режиме 1С Предприятие хоть и добавили возможность настраивать профили и группы доступа, а также ограничения на уровне записей (организации, контрагенты), но по прежнему, узкая, точечная настройка прав производится в Конфигураторе теми же самыми средствами что и раньше, то есть галочками напротив каждого действия, которые разрешены (не разрешены) пользователю. Мы сделали это уточнение, относительно настройки прав, поскольку изменения, относительно настройки прав пользователей в режиме 1С Предприятие несколько запутывают и, вначале, кажется, что и настройка доступа также производится в режиме 1С Предприятие. Это не так.
Добавляем в профиль роли и у пользователя появляюся права в конфигураторе
2. После того как мы скопировали роль и переименовали ее, можем задать конкретные действия, которые может совершать пользователь с документом «Реализация товаров и услуг». Ниже приведен рисунок с шаблоном настроек, отвечающих нашей задаче. Как вы поняли это нужно делать в режиме Конфигуратор.
Права на документ Реализация товаров без права редактирования
3. Поскольку скопированная роль с полных прав теперь называется не «Полные права», а «Менеджер РП» то возникнут трудности со входом в программу. Это связано с тем, что мы потеряли статус «полные права», и программа накладывает на нас при входе различные проверки и ограничения. Для того чтобы справится с различными трудностями входа в программу, рекомендуем установить для пользователя несколько стандартных ролей, решающих проблему входа в 1С: Базовые права БП, Базоовые права БСП, Базовые права УТ.
Недостаточно прав для входа в программу
Назначаем несколько прав, чтобы зайти в 1С
4. После того как вы произведете настройку роли и попытаетесь проверить то как она работает, то можете столкнутся с дополнительными препятствиями, с которыми столкнулись мы. А именно в документе «Реализация товаров и услуг» есть механизм проверки проведения документа с обязательной ссылкой на заказ покупателя. Соответственно, если есть такая проверка, то есть и маленькая дополнительная роль (одна из 1280), которая может разрешить проводить документы реализаций без обязательной ссылки на заказ. Действительно, в нашем случае такая роль оказалась. Она называлась «Проведение реализаций без ссылки на заказ». Её удалось вычислить через программный код документа «Реализация товаров и услуг». Элемент кода, осуществляющий такую проверку, приведен ниже. В каждом конкретном случае, в каждом конкретном документе нюансы могут быть другие. Просто знайте, что они могут быть. Теперь вам знаком способ как их искать и исправлять.
Нет прав проводить реализации без заказа покупателя
Находим программный код, блокирующий проведение реализации без заказа
Подключаем дополнительную роль для проведения реализаций без заказа
Заметьте, что при создании новой роли мы не вносили какие-либо изменения в программный код, чтобы решить нашу задачу, а настраивали все штатными средствами программы 1С. Иногда чтобы выполнить какую-либо новую задачу в новой программе просто нужно знать, как это делать. Надеемся, наш материал поможет вам в решении ваших вопросов администрирования прав пользователей в новых версиях программы 1С.
Стандартные роли
Область применения: управляемое приложение, обычное приложение.
1.1. Если в конфигурации есть разграничение прав доступа пользователей к данным информационной базы, то настройку доступа следует выполнять с помощью ролей. Роли должны создаваться разработчиком конфигурации исходя из задачи ограничения доступа пользователей к данным.
1.2. В простейшем случае, роли в конфигурации могут непосредственно соответствовать должностным обязанностям пользователей ( Директор , Бухгалтер , Кладовщик и т.п.).
Для возможности более тонкой настройки прав доступа администратором, роли могут соответствовать более «мелким» отдельным функциям, совокупность которых образует набор прав для конкретной категории пользователей. В этом случае пользователям назначается комбинация ролей (например, ЧтениеПроизводственныхДокументов , ДобавлениеИзменениеСкладскихДокументов , ЧтениеНСИ и т.п.). Для упрощения администрирования рекомендуется поставлять в составе конфигурации типовые комбинации таких ролей (например, готовый профиль для директора, бухгалтера, кладовщика и т.п.) При использовании в конфигурации Библиотеки стандартных подсистем для этого можно воспользоваться средствами подсистемы «Управление доступом» .
2. В конфигурации должны быть определены три обязательные роли, которые предназначены для «прикладного» и системного администрирования информационной базы, а также для интерактивного открытия внешних отчетов и обработок:
ПолныеПрава (синоним «Полные права»), АдминистраторСистемы (синоним «Администратор системы») и ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок (синоним «Интерактивное открытие внешних отчетов и обработок»).
2.1. ПолныеПрава (англ. FullAccess ) — обязательная роль, которая предоставляет неограниченный доступ ко всем «прикладным» данным информационной базы, но не дает прав доступа для администрирования информационной базы в целом (обновление конфигурации, работа в конфигураторе и т.п.).
Эта роль должна:
- позволять самостоятельное использование (может быть назначена пользователям);
- предоставлять неограниченный доступ ко всем данным области (к разделенным данным), кроме права интерактивного удаления (см. также п.5);
- позволять выполнять все административные действия с областью данных (администрирование пользователей, настройка программы, удаление помеченных объектов и т.п.);
- включать в себя перечисленные права:
- Администрирование данных
- Активные пользователи
- Журнал регистрации
- Монопольный режим
- Тонкий клиент
- Веб-клиент
- Сохранение данных пользователя
- Вывод
В случае если конфигурация рассчитана на работу в модели сервиса, то роль ПолныеПрава назначается администраторам абонентов (администраторам областей данных).
При работе конфигурации в локальном режиме роль ПолныеПрава назначается пользователям совместно с ролью АдминистраторСистемы , так как в этом режиме функции системного и «прикладного» администрирования информационной базы, как правило, совмещены.
2.2. АдминистраторСистемы (англ. SystemAdministrator ) – обязательная роль, предоставляющая дополнительные права на администрирование информационной базы в целом (обновление конфигурации, работа в конфигураторе и т.п.).
Эта роль должна:назначаться пользователям только совместно с ролью ПолныеПрава ;
предоставлять неограниченный доступ ко всем неразделенным данным информационной базы;
содержать все права доступа к объектам (кроме права интерактивного удаления — см. ниже п.5);включать в себя все права к корню конфигурации (в частности, права Администрирование и Администрирование данных ), кроме прав Интерактивное открытие внешних отчетов и Интерактивное открытие внешних обработок .
2.3. ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок (англ. InteractiveOpenExternalReportsAndDataProcessors ) обязательная роль, предоставляющая дополнительные права на открытие внешних отчетов и обработок через меню «Файл – Открыть».
Эта роль должна:- включать в себя права к корню конфигурации Интерактивное открытие внешних отчетов и Интерактивное открытие внешних обработок .
При работе конфигурации в локальном режиме роль ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок назначается администраторам, но в целях повышения безопасности информационной базы администратор может запретить использование данной роли.
При работе в модели сервиса роли АдминистраторСистемы , ПолныеПрава и ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок назначаются администраторам сервиса.
2.4. Роли ПолныеПрава , АдминистраторСистемы и ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок должны устанавливаться как основные роли конфигурации (свойство ОсновныеРоли ).
Методическая рекомендация (полезный совет)
2.5. При необходимости дать возможность удаления объектов «неполноправным» пользователям, рекомендуется добавить отдельную роль УдалениеПомеченныхОбъектов (англ. DeleteMarkedObjects ). Такая роль не предназначена для самостоятельного использования, ее следует назначать пользователям совместно с остальными ролями конфигурации.
3. Роли для настройки общих прав на информационную базу . В случае если в конфигурации для пользователей необходимо настраивать общие права работы с информационной базой (такие как «Тонкий клиент», «Толстый клиент», «Интерактивное открытие внешних обработок» и т.д.), то в конфигурации должны быть определены отдельные роли для предоставления этих прав. Такие роли не предназначены для самостоятельного использования, их следует назначать пользователям совместно с остальными ролями конфигурации.
Конфигурация должна быть одинаково рассчитана на работу как при наличии этих ролей, так и в условиях отсутствия любой из этих ролей у пользователя.
3.1. Администрирование (англ. Administration ) — предоставляет права «Администрирование», «Администрирование данных», «Администрирование расширений конфигурации» и «Активные пользователи».
3.2. ВыводНаПринтерФайлБуферОбмена (англ. OutputToPrinterFileClipboard ) — предоставляет право «Вывод».
3.3. ЗапускAutomation (англ. StartAutomation ) — предоставляет право «Automation».
3.4. ЗапускВебКлиента (англ. StartWebClient )- предоставляет право «Веб-клиент».
3.5. ЗапускВнешнегоСоединения (англ. StartExternalConnection ) — предоставляет право «Внешнее соединение»
3.6. ЗапускТолстогоКлиента (англ. StartThickClient )- предоставляет право «Толстый клиент».
3.7. ЗапускТонкогоКлиента (англ. StartThinClient ) — предоставляет право «Тонкий клиент».
3.8. ИнтерактивноеОткрытиеВнешнихОтчетовИОбработок (англ. InteractiveOpenExternalReportsAndDataProcessors ) — предоставляет права «Интерактивное открытие внешних обработок» и «Интерактивное открытие внешних отчетов».
3.9. ОбновлениеКонфигурацииБазыДанных (англ. UpdateDatabaseConfiguration ) — предоставляет право «Обновление конфигурации базы данных».
3.10. ПросмотрЖурналаРегистрации (англ. ViewEventLog ) — предоставляет право «Журнал регистрации».
3.11. РежимТехническогоСпециалиста (англ. TechnicalSpecialistMode ) — предоставляет право «Режим технического специалиста». Этот режим предназначен только для разработчиков/внедренцев и для разбора нештатных ситуаций, поэтому конфигурация должна обеспечивать работу пользователей без использования этого режима. Например, все стандартные обработки (удаление помеченных, управление итогами и агрегатами и т.п.) должны быть доступны соответствующим пользователям в разделах интерфейса программы.
3.12. СохранениеДанныхПользователя (англ. SaveUserData ) — предоставляет право «Сохранение данных пользователя». Рекомендуется предоставлять эту роль всем категориям пользователей, за редким исключением, когда требуется явно запретить настройку пользовательского интерфейса и любые другие персональные настройки таким образом, чтобы работа пользователя не оставляла никаких «следов» в информационной базе. Как правило, такой режим работы требуется для внешних или временных пользователей (респонденты, аудиторы и пр.) или для пользователей, работающих по тем или иным причинам под одной учетной записью.
Конфигурация должна быть рассчитана на работу пользователей без роли (права) СохранениеДанныхПользователя . В случае если конфигурация обращается из кода
- к пользовательским настройкам (сохранение и загрузка из различных хранилищ настроек: ХранилищеОбщихНастроек , ХранилищеВариантовОтчетов , ХранилищеНастроекДанныхФорм , ХранилищеПользовательскихНастроекОтчетов , ХранилищеСистемныхНастроек )
- к истории работы пользователя ( ИсторияРаботыПользователя ) и избранному ( ИзбранноеРаботыПользователя )
- к пользовательским настройкам отчетов (метод УстановитьТекущиеПользовательскиеНастройки расширения управляемой формы для отчета)
то при отсутствии у пользователя права СохранениеДанныхПользователя , этот код должен быть пропущен таким образом, чтобы это не оказывало влияния на основные сценарии работы пользователя. Кроме того, если в конфигурации предусмотрены пользовательские интерфейсы или отдельные элементы форм для работы с пользовательскими настройками (история вводимых значений, флажки «Запомнить мой выбор» и пр.), то они не должны быть доступны пользователям без права СохранениеДанныхПользователя .
При использовании в конфигурации Библиотеки стандартных подсистем можно также воспользоваться функциями ХранилищеОбщихНастроекЗагрузить и ХранилищеОбщихНастроекСохранить общего модуля ОбщегоНазначения .
4.1. В тех случаях когда определенным пользователям требуется временный или постоянный доступ на просмотр всех данных информационной базы без ограничений, рекомендуется поставлять в составе конфигурации отдельные роли. Например, это может быть временный доступ для аудитора, постоянный – для собственника или директора организации.
4.2. В простейшем случае, когда роли в конфигурации соответствуют должностным обязанностям пользователей ( Директор , Бухгалтер , Кладовщик и т.п.), должна быть добавлена отдельная роль ТолькоПросмотр (англ. ViewOnly ).
Роль ТолькоПросмотр должна включать права Чтение , Использование , Просмотр , Ввод по строке (если применимо) для большинства объектов метаданных (за исключением тех данных, которые никогда не выводятся пользователю, а используются в конфигурации только в технологических целях, и поэтому доступ к ним осуществляется всегда в привилегированном режиме).4.3. В конфигурациях, в которых роли соответствуют более «мелким» отдельным функциям (совокупность которых образует набор прав для конкретной категории пользователей), рекомендуется назначать пользователям комбинацию ролей, которые предоставляют доступ только на чтение (например, ЧтениеПроизводственныхДокументов , ЧтениеСкладскихДокументов , ЧтениеКассовыхДокументов и т.п.). Рекомендуется поставлять в составе конфигурации типовые комбинации таких ролей (например, готовый профиль для аудитора, собственника, директора и т.п.)
При этом для неограниченного доступа на просмотр всех данных информационной базы для таких пользователей нужно отключать (не задавать) условия ограничения доступа на уровне записей (RLS).
5. Ни в одной роли, включая ПолныеПрава и АдминистраторСистемы , не должно быть установлено (кроме отдельных обоснованных случаев) следующих прав:
- Право интерактивного удаления
- Интерактивное удаление предопределенных данных
- Интерактивная пометка удаления предопределенных данных
- Интерактивное снятие пометки удаления предопределенных данных
- Интерактивное удаление помеченных предопределенных данных
Право удаления рекомендуется оставить только в ролях ПолныеПрава и АдминистраторСистемы .
Стандартные роли в расширениях конфигурации
6. При разработке расширений конфигурации не рекомендуется заимствовать и изменять роли АдминистраторСистемы и ПолныеПрава . Вместо этого необходимо добавить в расширение собственные роли по следующему принципу.
6.1. В простейшем случае, если права на все объекты расширения одинаковы для всех категорий пользователей, то создать одну роль с указанным именем, настроить в ней необходимые права на объекты расширения и включить ее в основные роли расширения:
6.2. Если права на объекты расширения различаются для администратора и пользователей, то создать две роли с именами:
- ПолныеПрава (включить в основные роли расширения)
- БазовыеПрава
6.3. Если права на объекты расширения различаются для администратора, пользователей и внешних пользователей (см. подробнее документацию Библиотеки стандартных подсистем ), то создать три роли с именами:
- ПолныеПрава (включить в основные роли расширения)
- БазовыеПрава
- БазовыеПраваВнешнихПользователей
6.4.1. В конфигурациях на базе Библиотеки стандартных подсистем роли расширений из пп. 6.1-6.3 автоматически включаются в профили групп доступа при установке расширений в информационную базу:
- Роль ОбщиеПрава включается во все профили с ролями БазовыеПраваБСП , БазовыеПраваВнешнихПользователейБСП , ПолныеПрава .
- Роль БазовыеПрава включается в профили с ролью БазовыеПраваБСП .
- Роль БазовыеПраваВнешнихПользователей включается в профили с ролью БазовыеПраваВнешнихПользователейБСП .
- Роль ПолныеПрава включается в профили с ролью ПолныеПрава .
6.4.2. Кроме того, если в расширении требуются гибкая настройка прав доступа, то следует дополнительно спроектировать и создать любые необходимые прикладные роли. При этом такие роли не включаются в профили групп доступа автоматически, но возможно программно дополнить ими поставляемые профили или интерактивно назначить их в справочнике Профили групп доступа .
6.5. В конфигурациях без использования Библиотеки стандартных подсистем (или без использования профилей) роли расширений из пп. 6.1-6.3 следует аналогично назначать пользователям ИБ программно средствами встроенного языка или интерактивно. Тем самым, разработанное расширение конфигурации может быть единообразно, без каких-либо доработок состава ролей, подключено в конфигурации как на базе Библиотеки стандартных подсистем , так и без нее.
«Базовые права БРО» — что это такое?
БТС — включает в себя набор подсистем, предназначенных для реализации в прикладных решениях на платформе «1С:Предприятие 8» функционала, необходимого для работы через Интернет в модели сервиса в соответствии с технологией 1cFresh. Библиотека состоит из набора подсистем, часть которых может работать не только в модели сервиса, но и в локальном режиме.
ГИСМ — Для хранения информации о маркировке товаров контрольными (идентификационными) кодами и отслеживания движения маркированных товаров
БРО — настройки отправки Регл.Отчености в контр.органыShipilov_ivan; Ketzalkoatl; yoops; user695247_acido86; info1ctart; ybatiaev; Hoppius; wowik; Barmolei; Denis Nsk; galexo; YanTsys; + 12 – Ответить
3. YanTsys 12 11.09.17 19:09 Сейчас в теме
БТС — Библиотека технологий сервиса
БРО — Библиотека регламентированной отчетности
ГИСМ — Государственная информационная система маркировкиuser813214; UJF; Alexandr73Rus; Ingraf; SilverKey; doggernaut; Shipilov_ivan; ils_prog; Ketzalkoatl; Innuil; Mahinya; AnKonAlm; temdj; yoops; leonidol; user695247_acido86; Suslik_Johns; info1ctart; ybatiaev; Hoppius; Lexx100; Sagat777; wowik; suepifanov; user705522_constantin_h; Denis Nsk; galexo; + 27 – Ответить