Petroglif

Введение

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

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

При написании настоящего руководства мы придерживались следующих принципов:

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

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

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

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

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

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

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

Архитектура системы

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

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

Пойдем по порядку снизу-вверх.

Операционная система

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

СУБД

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

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

Слой SLIB

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

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

Слой интерфейса с СУБД

Этот слой реализует механизмы взаимодействия системы с СУБД. В этом он похож на слой SLIB (только последний, главным образом, обеспечивает взаимодействие с операционной системой).Учитывая то, что на уровне использования и настройки системы данный компонент практически невидим, мы и долго задерживаться на нем не станем.

Объекты данных

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

Как правило, объект данных представляет множество однотипных сущностей, моделирующих нечто во внешнем либо внутреннем окружении предприятия.Самые простые примеры объектов данных: персоналии, товары, документы.

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

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

Идентификация объектов данных

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

Требования к процессу выборки самые несложные:

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

Скорость - время на выборку заданного экземпляра объекта данных должно быть предельно малым.

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

Перечислим возможные универсальные средства идентификации записей объектов данных в системе Papyrus :

Идентификатор

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

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

Так, товар знает о единице измерения на основании того факта, что в записи этого товара содержится идентификатор единицы измерения (но не ее наименование или какие-либо иные атрибуты).

Наименование

Текстовая строка, по которой пользователь может идентифицировать запись объекта. В отличии от идентификатора наименование несет в себе смысл, воспринимаемый человеком. Соответственно, и сам способ идентификации важен для пользователей, а не для системы. Для большинства объектов данных система “насильно” поддерживает уникальность наименований записей. То есть пользователь не сможет ввести две записи объекта с одинаковым именем. Однако, это верно не для всех объектов. Так, персоналии, могут иметь одинаковые имена. Это - необходимость, обусловленная тем, что как имена людей, так и названия компаний могут дублироваться.

Символ

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

Примером идентификации по символу может служить объект данных Суммы документов. Здесь символ используется для того, чтобы ссылаться на значения этих сумм в формулах при настройке шаблонов проводок по документам (стр. link). Другой пример - символ склада. Он часто используется для контекстной синхронизации записей складов, созданных независимо в разных разделах базы данных (стр. link).

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

Номенклатурные коды (штрихкоды): обеспечивают (опциональный) список уникальных кодов, связанных с товаром. Необходимость в этих кодах очевидна - кодировка очень часто присваивается товару вне пределов предприятия, и каждый код может быть ассоциирован с количеством единиц товара. То есть ни один из рассмотренных выше стандартных методов идентификации заменить эту кодировку не может (идентификатор - не управляемый, символ - один на запись).
Артикулы: коды аналогичные номенклатурным, но с дополнительным условием: каждый артикул может быть связан с каким-либо контрагентом предприятия. Уникальность артикулов обеспечивается по сочетанию (контрагент - товар - код). Опять мы видим, что ни один из стандартных методов (даже дополненных номенклатурными номерами) не способен решить проблему столь сложной идентификации.

Общие черты всех объектов данных

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

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

Общие атрибуты типа объекта данных

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

Общие атрибуты экземпляра объекта данных

Идентификатор типа

Идентификатор

Наименование

Символ

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

Еще один атрибут “поле флагов” присутствует в записях практически всех объектов данных. Он используется для установки переключаемых признаков экземпляров объектов. Само собой, значения каждого флага в этом поле специфично.Все остальные атрибуты записей определяются назначением объектов и будут рассмотрены отдельно в соответствующих разделах.

Общие функции объектов данных

Отображение списка записей

Большинство объектов реализуют отображение своих записей посредством контроллеров анализа данных (о них речь пойдет ниже).

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

Создание новой записи

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

Редактирование записи

Функция состоит в изменении существующего экземпляра объекта данных. Аналогично функции “Создание новой записи”, эта реализована практически для всех типов объектов.

Удаление записи

Как следует из названия, данная функция решает задачу удаления экземпляра объекта данных.

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

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

Передача в другой раздел базы данных

Тема синхронизации данных между удаленными разделами рассматривается в главе link.

Здесь мы только заметим, что большинство типов объектов данных предоставляют сервис независимой передачи в другие разделы. Несмотря на то, что явно этими функциями пользуются редко, они оказываются крайне полезными в некоторых случаях.

Объединение двух записей

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

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

Ограничение прав доступа, регламентированное правами пользователя

Для всех типов объектов данных существует функция регламента прав доступа. Базовый набор прав состоит из следующих флагов:

✓Просмотр

✓Создание

✓Модификация

✓Удаление

✓Админ

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

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

Контроллеры анализа данных

Контроллеры анализа данных представлены семейством унифицированных модулей, реализующих следующие функции:

Отображение данных в таблицах

Отбор данных в соответствии с условиями фильтра, заданного пользователем

Вывод отображенных данных на печать или экспорт этих данных

Вызов функций, характерных для отображенного в таблице набора данных

Унифицированная техника реализации контроллеров анализа данных не только определяет логичность внутренней структуры этого архитектурного слоя, но и позволяет предоставлять конечным пользователям следующие преимущества:

Общая идеология использования

Механизм предварительной настройки условий фильтрации

Единые принципы построения интерфейсов доступа к данным Papyrus из других программ

Простота кастомизации отчетов и экспорта данных

Инфраструктура

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

Администрирование и резервное копирование баз данных

Управление конфигурациями и правами доступа

Управление синхронизацией данных между распределенными разделами

Модули, реализующие функции импорта/экспорта данных

Подсистема DL600, обеспечивающая формирование данных для печати, экспорта и интерфейсы с внешними программами