Строим ролевую модель управления доступом. часть первая, подготовительная

Введение

Сложно представить себе современную компанию, не использующую в своей работе какие-либо базы данных, системы учета, контроля и прогнозирования. Данная работа посвящена разработке проекта системы автоматизации для предприятия, а именно – системы складского учета. Актуальность данной работы обусловлена необходимостью автоматизировать процессы деятельности склада. Информационная система разрабатывалась для небольшой фирмы ООО «МетаФлекс».

Цель данного курсового проекта – разработка проекта системы автоматизации (ИС) склада.

Для достижения указанной цели определим ряд задач:

1. исследовать предметную область;
2. проанализировать внутренние бизнес-процессы организации складского учета;
3. сформулировать требования к разрабатываемой ИС;
4. разработать модель бизнес-процессов организации;
5. разработать модель данных ИС складского учета;
6. разработать подсистему автоматизации склада.

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

Предмет исследования – автоматизация учета информационных потоков деятельности склада.

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

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

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

Во второй главе представлены результаты разработки проекта подсистемы складского учета в 1С: Предприятие 8.2. Расписаны этапы создания объектов конфигурации (справочников, документов, отчетов и т.д.).

В заключении сделаны выводы о работе и решенных задачах проекта.

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

В качестве программных средств были использованы: CA ERWin Process Modeler; CA ERWin Data Modeler; 1С: Предприятие 8.2.

Работа представляет практическую значимость не только для руководителя склада, но и для кладовщиков, так как они могут использовать всю информацию о хранимой продукции в единой базе, управлять поступлением и расходом товаров, формировать необходимые отчеты. Данные возможности информационной системы значительно облегчают и ускоряют рабочий процесс сотрудников склада ООО «МетаФлекс».

Использование учетных данных клиента при проверке подлинности клиента службой

Учетные данные клиента, необходимые для связи со службой, предоставляются с помощью свойства ClientCredentials или Credentials. Безопасный канал может использовать эту информацию для выполнения службой проверки подлинности клиента. Проверка подлинности выполняется в одном из двух режимов.

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

• Учетные данные используются для проверки подлинности всех сообщений приложения, отправляемых службе. В этом случае контекст между клиентом и службой не устанавливается.

Невозможность изменения установленных идентификаций

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

Важно!

Есть ситуация, в которой следует учитывать невозможность изменить идентификацию (то есть при поведении по умолчанию, когда включена установка контекста безопасности). При создании службы, которая взаимодействует со второй службой, удостоверение, используемое для открытия клиента WCF во второй службе, изменить нельзя. Это становится проблемой, если несколько клиентов могут использовать первую службу, а служба олицетворяет клиенты при доступе ко второй службе. Если служба использует для всех вызывающих один и тот же клиент, все вызовы ко второй службе происходят под идентификацией первого вызывающего, с помощью которой был открыт клиент для второй службы. Иными словами, служба использует идентификацию первого клиента для связи всех своих клиентов с другой службой. Это может привести к повышению привилегий. Если такое поведение службы нежелательно, нужно отслеживать каждого отдельного вызывающего и создавать для каждого из них новый клиент для второй службы. Следует убедиться, что служба использует для связи каждого вызывающего со второй службой только соответствующий клиент.

Дополнительные сведения об учетных данных и безопасных сеансах см. в статье вопросы безопасности для защищенных сеансов.

Загрузка исходных данных

Исходные данные для подготовки отчетности по МСФО с использованием трансформационной модели могут загружаться в учетную систему следующими способами:

• непосредственно из внешних учетных систем. В этом случае создается аналитическая ОСВ по НСБУ, которая в дальнейшем транслируется в аналитическую ОСВ по МСФО;
• из форм сбора данных (ФСД), заполняемых вне системы. Перед загрузкой данных пакета ФСД структура этих форм должна быть задана в справочнике Виды отчетов. Аналитическая ОСВ по НСБУ собирается на основе ФСД и синтетической ОСВ по НСБУ. В дальнейшем эта аналитическая ОСВ по НСБУ транслируется в аналитическую ОСВ по МСФО.

Перенос исходных данных при трансформационной модели осуществляется полностью, без исключения отдельных хозяйственных операций. Это является особенностью и отличием трансформационной модели от транзакционной Каждый отчетный период исходные данные загружаются заново. Данные НСБУ из прошлых периодов в следующие периоды не переносятся.

Для трансформации исходных данных по НСБУ в формат МСФО необходимо создать экземпляр отчета, куда загружается синтетическая ОСВ по НСБУ (рис. 2).

Рис. 2. ОСВ по РСБУ (экземпляр отчета)

В этой ОСВ нет расшифровок по аналитикам, но такая агрегированная ОСВ позволит проконтролировать корректность данных, расшифровывающих показатели ОСВ по аналитикам в ФСД, загружаемых в систему вместе с ОСВ по НСБУ.

Для расшифровки показателей синтетической ОСВ по аналитикам, необходимым в дальнейшем для проведения корректировок для целей МСФО и подготовки примечаний к отчетности, нужно создать экземпляры отчетов для каждой загружаемой в систему ФСД. Например, для раскрытия сведений о дебиторской и кредиторской задолженности, а также о кредитах и займах требуются расшифровка и хранение в системе остатков и оборотов по этим счетам в разрезе аналитик Контрагенты и Договоры. Для этого в подготовленный экземпляр отчета загружается соответствующая ФСД (рис. 3).

Рис. 3. Раскрытие показателей в экземпляре отчета

Поскольку при трансформационном подходе транслируются не корреспонденции между счетами и субконто, а обороты и остатки по счетам, то стандартных аналитик, имеющихся у счета, по которым расшифровываются данные в ФСД, не всегда достаточно. Поэтому в «1С: Управлении холдингом 8» используется дополнительная аналитика показателей ОСВ – Виды движений. Данная аналитика нужна как для подготовки трансформационных корректировок по МСФО, так и для расшифровок к отчетности.

БУХ.1С открыл канал в мессенджере Telegram. В этом канале мы ежедневно публикуем самые главные новости дня для бухгалтеров и пользователей программ 1С. Для того, чтобы стать подписчиком канала, необходимо установить мессенджер Telegram на ваш телефон или планшет и присоединиться к каналу: https://t.me/buhru (или набрать @buhru в строке поиска в Telegram).

Новости о налогах, бухучете и 1С — оперативно в вашем телефоне!

Например, для целей подготовки отчета о движении денежных средств (ОДДС) необходима расшифровка поступлений (списаний) денежных средств по статьям их движения. Счета 50, 51, 52 позволяют это сделать по соответствующему субконто. Но при переоценке валютных остатков в НСБУ в субконто Статьи движения денежных средств автоматически подставляется значение Прочее, которое невозможно расшифровать после трансляции в МСФО. Поэтому в ФСД необходимо прописать корреспондирующие счета по видам движения с указанием соответствующего субконто. 

В данном примере для выделения суммы переоценки указывается корреспонденция со счетом 91.01 «Прочие доходы» (91.02 «Прочие расходы») с аналитикой по субконто Прочие доходы и расходы по статье Переоценка валютных счетов. ФСД дополняется колонкой Виды движений, где и проставляется сумма по такой корреспонденции. При подготовке аналитической ОСВ по МСФО по данному счету в расшифровке Раскрытие показателей группы отобразится данная аналитика, что позволит корректно составить ОДДС.

Для организации расшифровки по аналитике Виды движений необходимо создать элементы одноименного справочника (рис. 4).

Рис. 4. Виды движений МСФО

В поле План счетов указывается тот план счетов, который используется при трансформации. В разделе Корреспонденции создаются регистры сведений, содержащие корреспонденции для данного вида движения. Данный справочник позволяет автоматически проставлять аналитику Вид движения в трансформационных корректировках, используемых в процессе трансформации данных НСБУ в данные МСФО.

Интернациональная модель

Пожалуй, именно эту модель можно было бы назвать международной.

Она учитывает тот факт, что бухгалтерский учёт становится средством интернационального общения.

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

Профессиональные организации многих стран мира поддерживают деятельность Комитета по международным стандартам (IASC — Internacional Accounting Standards Committee).

Комитет пытается обобщить учётную практику разных стран и выработать единые подходы (IAS), для взаимопонимания управленческого персонала разных зарубежных предприятий – партнёров.

(IAS — Internacional Accounting Standards)

Использование IAS — абсолютно добровольное дело каждой МНК (мультинациональной корпорации) и не снимает необходимости подчиняться требованиям правил, принятых внутри страны.

Шаг 2. Аудируем ИТ-системы и составляем план приоритизации

• Связана ли система с операционными процессами, от выполнения которых зависит основная деятельность компании?
• Повлияет ли нарушение функционирования системы на целостность активов компании?
• Каково максимально допустимое время простоя системы, достигнув которого невозможно восстановить деятельность, после прерывания?
• Может ли нарушение целостности информации в системе привести к необратимым последствиям, как финансовым, так и репутационным?
• Критичность к мошенничеству. Наличие функционала, при недостаточном контроле которого, возможно осуществление внутренних/внешних мошеннических действий;
• Каковы требования законодательства, а также внутренние правила и процедуры к этим системам? Будут ли штрафы со стороны регуляторов за несоблюдение?

N.B. Крупные компании с развитыми ИТ-процессами наверняка знакомы с процедурой ИТ-аудита – IT general controls (ITGС), который позволяет выявить недостатки в ИТ-процессах и наладить контроль так, чтобы улучшить процессы в соответствии с best practice (ITIL, COBIT, IT Governance и др.) Такой аудит позволяет ИТ и бизнесу лучше понять друг друга и выработать совместную стратегию развития, проанализировать риски, оптимизировать затраты, выработать более эффективные подходы в работе.

Шаг 4. Фиксируем параметры существующей модели управления доступом

• как осуществляется управление учётными записями (напрямую в БД или через программные интерфейсы);
• как пользователи выполняют вход в систему (с помощью отдельной учётной записи или с использованием учётки AD, LDAP или др.);
• какие уровни доступа к системе используются (уровень приложения, системный уровень, использование системой сетевых файловых ресурсов);
• описание и параметры серверов, на которых работает система;
• какие операции по управлению учётными записями поддерживаются (блокировка, переименование и т.п.);
• по каким алгоритмам или правилам формируется идентификатор пользователя системы;
• по какому атрибуту можно установить связь с записью о сотруднике в кадровой системе (ФИО, табельный номер или др.);
• все возможные атрибуты учётной записи и правила их заполнения;
• какие права доступа существуют в системе (роли, группы, атомарные права и др., есть ли вложенные или иерархические права);
• механизмы разделения прав доступа (по должностям, подразделениям, функционалу и др.);
• есть ли в системе правила разграничения прав (SOD – Segregation of Duties), и как они работают;
• как обрабатываются в системе события отсутствия, перевода, увольнения, обновления данных о сотрудниках и т.п.

Документы параллельного учета МСФО и закрытие периода

После того как процесс трансляции завершен, необходимо ввести документы МСФО по областям, учет которых ведется параллельно. Области параллельного учета – это объекты, которые не были транслированы из РСБУ в МСФО (то есть, были пропущены при трансляции).

Операции с отдельными объектами учета МСФО осуществляются с помощью специальных инструментов программы, расположенных в разделе Учет по МСФО (Внеоборотные активы (ОС, НМА и прочие), Финансовые инструменты, Резервы и т.д.).

Рассмотрим пример: при настройке механизма трансляции при помощи фильтров и условий отбора были установлены соответствия РСБУ – МСФО для всех категорий основных средств, кроме сооружений. В части сооружений ведется параллельный учет по МСФО, начальные остатки по данной группе ОС введены на основании отчета оценщика по МСФО, поэтому показатели РСБУ по сооружениям не транслируются.

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

При помощи документа Ввод событий ВНА по данным отчета оценщика пользователь вводит исходные данные по ОС, входящим в группу Сооружения. Далее, в процессе закрытия периода в МСФО начисляется амортизация по данной группе. При этом из РСБУ данные по амортизации не транслируются. Если в РСБУ отражается выбытие или поступление объектов, входящих в группу Сооружения, эти данные также не транслируются в МСФО, однако существует возможность автоматического заполнения документов параллельного учета МСФО на основе этих данных. Например, в документе Ввод событий ВНА по кнопке Заполнить можно выбрать команду Заполнить из учетной системы, после чего данные РСБУ переносятся в документ МСФО. При необходимости эти данные могут быть скорректированы пользователем.

Таким образом, для областей параллельного учета предусмотрена отдельная процедура ввода данных в МСФО, не связанная с трансляцией. Эти данные могут быть введены:

• на основании уже существующих данных РСБУ путем заполнения документов параллельного учета из учетной системы РСБУ;
• из внешних источников, не связанных с учетной системой (например, на основании отчета оценщика).

Закрытие периода является еще одним из инструментов параллельного учета МСФО. В рамках процедуры закрытия периода выполняются такие операции, как переоценка финансовых инструментов, регламентные операции параллельного учета ОС (корректировка финансового результата выбытия основных средств, начисление амортизации основных средств), расчет отложенных налогов и корректировка себестоимости в МСФО, а также ряд других операций.

Рис. 9. Закрытие периода

Полный список операций, выполняемых в рамках закрытия периода, приведен на рисунке 9. Отдельные операции могут выполняться «на выборочной основе», то есть их выполнение не является обязательным для закрытия периода и зависит от специфики учета конкретной организации.

В следующих статьях, посвященных учету МСФО в «1С:Управлении холдингом 8» мы подробно расскажем об отдельных объектах параллельного учета, об особенностях формирования трансформационных корректировок в рамках каждого блока учета, а также о процедуре закрытия периода.

Континентальная учетная модель

Данная модель характерна для стран Европы, Японии и России. Этим странам присущ значительный контроль со стороны влвстей на бизнес-сферу. С помощью широко развитого банковского сектора государство проводит свою политику, направленную на достижение макроэкономических задач.

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

Южноамериканская модель

Используется в странах южного континента Америки (Аргентина, Боливия, Бразилия, Чили, Уругвай и др.)

Ориентируется на потребности правительства и отличается от других моделей ежегодными корректировками на темпы инфляции.

В этих странах разрабатываются специальные методики, учитывающие нестабильность денежной единицы и нарушение принципа первоначальной оценки основных средств, (Historical Cost Principle).

Исламская и интернациональная модели

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

Настройка правил трансляции

Для настройки правил трансляции данных используется такой же инструмент сопоставления счетов НСБУ и счетов МСФО, как и для трансформационного подхода – справочник Шаблоны трансляций (рис. 2).

Рис. 2. Элемент справочника «Шаблоны трансляций» для транзакционной модели

Для транзакционной модели в поле Направление трансляции из предопределенного списка следует выбрать значение Регистр бухгалтерии – регистр бухгалтерии. Только в этом случае данные из регистра бухгалтерии НСБУ переносятся на регистр бухгалтерии МСФО.

Раздел Соответствия ресурсов заполняется автоматически при выборе планов счетов (источника и приемника).

После записи элемента справочника можно устанавливать соответствие счетов и правила трансляции. Для этого в командной панели нужно нажать на кнопку Сопоставление счетов и перейти в форму Установка соответствия счетов (рис. 3).

Рис. 3. Установка соответствия счетов в транзакционной модели

В поле Счет (исх.) выбирается счет плана счетов — источника, транзакции которого будут транслироваться на счет плана счетов МСФО, указанный в поле Счет.

Транзакционная модель учета подразумевает трансляцию проводок (транзакций), а не остатков и оборотов, как в трансформационной модели, поэтому нет необходимости транслировать все исходные данные из НСБУ. Настройка правил трансляции позволяет устанавливать сложные отборы и использовать различные фильтры, для того чтобы транслировались только определенные проводки. Для этого в форме Установка соответствия счетов в полях Дт, Кт плана счетов — приемника следует установить флаги только для тех счетов, обороты по которым необходимо транслировать.

В том случае, когда исходные данные из НСБУ транслируются выборочно, необходимо обеспечить дополнительную проверку полноты признания всех фактов хозяйственной деятельности общества для целей МСФО. Это означает, что по тем операциям, которые не транслируются, обязательно должны быть проведены документы параллельного учета МСФО или ручные трансформационные поправки, обеспечивающие признание и оценку таких операций в соответствии с принципами МСФО. В противном случае часть операций может быть потеряна и вовсе не отражена в отчетности по МСФО.

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

Имеется возможность агрегировать несколько значений субконто счета-источника на один счет-приемник. Также можно транслировать транзакции одного счета-источника НСБУ на несколько счетов-приемников МСФО, используя отборы по значениям субконто в поле Дополнительно.

Например, в МСФО банковские депозиты сроком менее трех месяцев необходимо классифицировать в денежные эквиваленты, а краткосрочные депозиты сроком более трех месяцев — отражать в прочих краткосрочных активах. Чтобы не делать дополнительных реклассификаций, в транзакционной модели эту задачу можно решить с помощью настройки сложных отборов в правилах трансляции (рис. 4).

Рис. 4. Настройка сложных отборов в правилах трансляции

Правило для счета 1.1.04.55.03 «Краткосрочные депозиты сроком менее 3 месяцев» выглядит следующим образом: транслировать дебетовые и кредитовые обороты счета 55.03 «Депозитные счета» со всеми корреспонденциями на счет 1.1.04.55.03 только в том случае, если в карточке субконто Банковские счета установлен флаг Срок депозита менее 3 месяцев.

Правило для счета 1.2.03.55.01 «Краткосрочные депозиты сроком более 3 месяцев»: транслировать дебетовые и кредитовые обороты счета 55.03 со всеми корреспонденциями на счет 1.2.03.55.01 только в том случае, если в карточке субконто Банковские счета не установлен флаг Срок депозита менее 3 месяцев.

Проектирование приложения с поддержкой MAC

Системное ПО	Описание
ОС Astra Linux Special Edition / SELinux	ОС с поддержкой MAC. Предоставляет хранилище информации о мандатных разрешениях пользователей, связанное с хранилищем пользователей операционной системы. Предоставляет механизмы контроля доступа к объектам, защищаемым MAC (объектам файловой системы, запуску приложений в режиме мандатной метки и т.д.).
СУБД PostgreSQL (PostgresPro)	Имеет интеграцию с хранилищем учетных записей и мандатных меток ОС. СУБД предоставляет функциональность присваивания мандатной метки к таким объектам, как кластер, база данных, таблица, столбец и запись.
Веб-сервер с поддержкой MAC (Apache Http Server)	Ретранслирует мандатную метку от запроса клиента с поддержкой MAC и запускает обработчик приложения (скрипт/службу) с идентичной меткой и передачей данных аутентификации пользователя.
Браузер с поддержкой MAC (Mozilla Firefox)	Считывает мандатную метку сеанса пользователя (графической оболочки пользователя) и добавляет ее в запросы к веб-приложениям.

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

1. Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает приложение. Процесс приложения наследует мандатную метку.
2. Приложение взаимодействует с БД на PostgreSQL, отображая пользователю, к примеру, только записи таблиц БД с текущей мандатной меткой.

1. Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает браузер с поддержкой MAC, в нашем примере — Mozilla Firefox («обычный» браузер для этих целей не подойдет). Процесс браузера наследует мандатную метку.
2. Пользователь запрашивает адрес ресурса приложения с поддержкой мандатных меток. Браузер формирует запрос, добавляя в него мандатную метку.
3. Запрос обрабатывает веб-сервер с поддержкой мандатных меток, в нашем примере — Apache Http Server. Веб-сервер (процесс которого работает в режиме минимальной мандатной метки) считывает мандатную метку запроса, находит приложение-обработчик запускает его процесс с переданной мандатной меткой.
4. Приложение взаимодействует с БД на PostgreSQL, ретранслируя в запросах мандатную метку.

Как избежать MAC, когда его уже не избежать

• Кроссплатформерность приложения (ограниченную только лишь возможностями языков программирования) и его независимость от среды выполнения.
• Возможность использования современных инструментов виртуализации (например, Docker) с целью автоматизации.
• Простоту тестирования и отладки функций, которые не связаны непосредственно с MAC.

Рекомендации:

Добавить параметр включения/отключения поддержки мандатных меток в приложении.

Во всех местах, требующих взаимодействия с MAC, прежде всего проверять значение параметра.

При отладке и тестировании необходимо отлаживать (на стороне команды разработки) и тестировать (на стороне команды тестирования) оба режима работы приложения.

Разделяй и властвуй

Рекомендация:  Следует разделить приложение на модули и классифицировать их по режимам обработки мандатных меток.

• Минимальная метка. Модуль обрабатывает данные в режиме минимальной мандатной метки (минимальная метка, в которой функционируют процессы ОС — например, 0 мандатная метка) либо без мандатной метки.
• Одна метка. Модуль работает с данными только одной мандатной метки выше минимальной мандатной метки (любой метки, отличной от той, в которой функционируют процессы ОС).
• Несколько меток. Модуль работает с данными сразу нескольких мандатных меток (как метки, в которой функционируют процессы ОС, так и других меток, отличных от метки процессов ОС).

Рекомендация: При проектировании следует обеспечивать минимальную связность (cohesion) модулей, работающих в различных парадигмах обработки мандатных меток.