Компьютер в бухгалтерском учете и аудите 1998'2
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Фирма “Формоза-Софт”

Проблемы автоматизации торговых компаний

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

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

Программный продукт “МОНОПОЛИЯ” представляет собой комплексную многофункциональную систему управления торговым предприятием со сборочным производством. Эта автоматизированная система предназначена для руководителей (владельцев) торговых организаций, использующих ее как инструмент для сбора информации о деятельности предприятия, анализа эффективности деятельности предприятия, ценообразования, контроля за товаром, деятельностью персонала, работы с поставщиками, составления баланса и других форм бухгалтерской отчетности, а также для решения многих других задач.

При проектировании и реализации системы “МОНОПОЛИЯ” были решены такие задачи, как:

• полная надежность системы;
• безопасность и контроль прав доступа;
• максимальная гибкость и настраиваемость системы.

Проблема надежности действительно является одной из самых важных, а если речь идет о комплексной системе автоматизации, ее важность возрастает многократно, так как “в руках” системы находятся абсолютно все данные о фирме и ее деятельности, и потеря этих данных равносильна стихийному бедствию. В этом смысле очень важно выбрать СУБД, отвечающую этим требованиям. Решения ORACLE наиболее проверены временем, большим количеством пользователей, полностью отвечают требованиям надежности и гарантируют целостность данных. Клиентские приложения, работающие в среде Windows 95 или Windows NT, менее защищены, однако сбой на конкретном рабочем месте никак не влияет на целостность данных и на работу системы в целом.

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

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

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

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

Средства разработки

Система “МОНОПОЛИЯ” разработана на основе открытых технологий с использованием архитектуры “клиент—сервер”. В качестве сервера баз данных была выбрана СУБД ORACLE, как самое надежное и проверенное временем решение. Еще один аргумент в пользу ORACLE — многоплатформенность, то есть безболезненная переносимость между операционными системами (Windows NT, UNIX и т. д.) и аппаратными платформами (Intel, Sun, DEC, …). Это дает возможность легко масштабировать систему в соответствии с развитием фирмы.

Проект ведется с применением CASE-технологии в ORACLE Designer/2000. Клиентская часть выполнена на ORACLE Forms и, частично, Borland Delphi Client/Server 32-бит и работает под управлением операционной системы Windows 95 или Windows NT.

Структура системы

Особенностью системы “МОНОПОЛИЯ” является отсутствие в ней отдельных модулей. Кроме того, в системе не существует такого традиционного понятия, как отдельное автоматизированное рабочее место (АРМ), а есть настраиваемое рабочее место сотрудника организации. Тем не менее, в системе можно выделить логические модули. Рассмотрим некоторые из них. При этом основное внимание будем уделять не функционированию системы, а возможностям ее настройки. Причина вполне понятна. Дело в том, что если описывать конкретную функциональность, то в результате мы получим описание не всей системы, а лишь одной из ее возможных настроек.

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

Настройкой рабочих мест, полномочий и обязанностей сотрудников занимается логический модуль “Штатное расписание”.

Управление структурой фирмы и персоналом.
Штатное расписание

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

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

Рис. 1. Форма редактирования объектов

Рис. 2. Форма распределения обязанностей по должностям

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

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

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

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

Товарное пространство и прайс-лист

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

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

Как показывает практика, древовидная структура очень удобна при большом ассортименте товара (1000–10 000 позиций), кроме того, наличие трех типов объектов, участвующих в иерархической схеме имеет (в отличие от общепринятой двухуровневой — позиция и группа) ряд преимуществ. Например, при формировании заказа необязательно указывать конкретную позицию товара. Достаточно указать номинал, и система позволит выдать со склада любой из аналогов.

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

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

Система может работать с произвольным количеством валют, по каждой из валют система может хранить произвольное количество курсов. Это могут быть курсы ММВБ, ЦБ РФ, банка, клиентом которого является организация. Кроме того, полезно иметь несколько своих курсов пересчета (например, для того, чтобы обслуживать разных клиентов на разных условиях). Их можно не вводить в систему специально, а вычислять от одного из введенных.

Формирование цены

Система поддерживает многоколоночный прайс-лист, то есть один и тот же товар может иметь несколько цен.

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

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

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

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

Настройка бизнес-логики

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

Рис. 3. Форма для работы с прайс-листом

Рис. 4. Форма редактирования списка типов оснований

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

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

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

Основной инструмент настройки бизнес-логики — это описание бизнес-процессов или, на языке системы, настройка типов оснований.

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

И более того: необязательно полностью настраивать систему до ее запуска в эксплуатацию — бизнес-логику можно изменять и добавлять новые бизнес-процессы уже во время эксплуатации.

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

Основание каждого типа описывает свой бизнес-процесс, то есть содержит свой набор хозяйственных операций.

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

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

Рис. 5. Форма настройки типов оснований

Рис. 6. Форма основания общая

Кроме того, может быть наложено ограничение на работу с основанием по сумме, то есть если сумма документа превышает ограничение, работник теряет право на работу с ним и должен обратиться к вышестоящему сотруднику.

Исполнение бизнес-процессов

Исполнение бизнес-процессов — реализация всех действий, заложенных в основании данного типа. Рассмотрим на конкретном примере, как исполняется бизнес-процесс, описываемый основанием типа “Продажа под залог с оплатой по б/н расчету”. Первый этап — это создание конкретного основания с наполнением его данными о параметрах сделки.

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

1. Внесение залога наличными.
2. Выдача товара.
3. Приход безналичных денег.
4. Регистрация доверенности.
5. Возврат залога наличными.

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

Заполнение финансовой информации о сделке отражается в плане оплаты основания.

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

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

Управленческий учет в системе

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

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

С другой стороны, при принятии решений руководство опирается не только на бухгалтерскую информацию. Необходимо иметь возможность видеть всю накапливаемую системой информацию в любом разрезе, с возможностью ее визуализации для быстрого восприятия. Сегодня и эти возможности реализованы в системе “МОНОПОЛИЯ”.

Бухгалтерский учет

Идеология построения бухгалтерии, предлагаемая в рамках системы, опирается на понятие “хозяйственная операция” (определение ему было дано в разделе “Основные понятия и термины, используемые в системе”)

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

Посмотрим, как логический модуль бухгалтерского учета органично вписывается в систему. Для этого обратимся к разделу “Настройка бизнес-логики”. В нем описана настройка типов оснований как основного инструмента описания бизнес-процессов. Бизнес-процесс, описываемый основанием, представляет собой набор состояний, в котором может находиться данное основание, а в каждом из этих состояний возможно выполнение (в общем случае) набора хозяйственных операций. На сегодня в системе реализована возможность выполнения только одной хозяйственной операции в каждом состоянии, поэтому можно говорить о том, что тип основания описывает упорядоченный набор хозяйственных операций. А так как хозяйственная операция — это факт изменения состояния предприятия, то очень логично “привязать” проведение бухгалтерских проводок именно к хозяйственной операции.

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

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

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

Рис. 7. “Привязка” проводок к хозоперациям

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

Отчеты и Средства анализа

Серьезные средства анализа — вопрос, выходящий за рамки систем автоматизации. Это отдельно стоящая сложная и трудоемкая задача. Задача системы автоматизации — собрать и сохранить максимум информации о деятельности фирмы в виде, удобном для анализа. Система “Монополия” с этой задачей справляется более чем успешно.

В стандартную поставку системы входит более 50 видов отчетов, которых вполне достаточно для работы персонала и получения повседневной оперативной информации. Более того, пользователи системы, знакомые со стандартными средствами формирования отчетов (Oracle Reports, Crystal reports) могут создавать новые виды отчетов и подключать их к системе по мере необходимости.

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

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

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

Оперировать придется такими понятиями, как товар, группа товаров, период времени и другими аналогичными параметрами, хранимыми в базе данных. Можно накладывать ограничения, фильтры. Результат отработки — информация в табличном виде с построением графиков, с возможностью экспорта в таблицы Excel.

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

Хочется добавить, что работа как с системой анализа, так и с системой в целом возможна с удаленной рабочей станции по коммутируемым или выделенным каналам связи, а также по сетям Internet/Intranet.

Кроме вышеописанной системы анализа, с системой отлично работает средство анализа фирмы Oracle. Это Oracle Discoverer 3.0. Данный инструмент предназначен также для сбора и анализа информации. Пользователь определяет таблицы (снапшоты), в которых хранится агрегированная информация, готовая к анализу по запросу пользователя. Данный инструментарий автоматически обновляет таблицы с заданной периодичностью. Пользователь работает также не в терминах запросов к базе данных, а в терминах своего бизнеса. Результаты также представляются в табличном виде, в графическом виде, есть возможность экспорта всей информации в Excel.

Рис. 8. Работа с системой анализа

Сборочное производство

Автоматизация производственного процесса — очень сложная задача. Однако нам удалось, в рамках системы “МОНОПОЛИЯ”, решить более узкую задачу, ограничив производственный процесс масштабами сборочного производства. Объем данного документа не позволяет подробно остановиться на том, как это реализовано в системе “Монополия”. Хотелось бы лишь в нескольких словах сказать, какие задачи решает в системе логический модуль “Сборочное производство”. Это формирование заказа на сборку, резервирование товара под заказанное изделие, обработка заказов и формирование нарядов, заказ внешней сборки (силами третьей организации), входной контроль, ОТК, продажа готовых изделий, поддержка серийных номеров изделий, отслеживание состава изделия вплоть до серийных номеров комплектующих, гарантийный ремонт, изменение конфигурации изделия и так далее. Вот неполный перечень задач, решаемых в рамках системы логическим модулем “Сборочное производство”.

Интернет — магазин

На базе системы “Монополия” работает полнофункциональный Интернет-магазин с возможностью оплаты по кредитным карточкам, реализованный с использованием Java-технологий. Ознакомиться с ним можно по адресу http://shop.formoza.ru. Хочется особо отметить, что данные о наличии товара на складе, его цене и т.д. покупатели Интернет-магазина узнают из реальной базы данных в режиме on-line: заказанный в Интернет-магазине товар резервируется на складе предприятия.

Перспективы

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

Следующая, вторая версия системы полностью разрабатывается с применением CASE-средств ORACLE Designer/2000, а клиентская часть будет выполнена на ORACLE Forms ver.5 с применением трехуровневой архитектуры “клиент-сервер”, что сделает предлагаемое решение еще более универсальным, многоплатформенным и еще более масштабируемым.

Использование OLAP-технологии для многомерного анализа сделает возможным построение еще более гибкой и очень мощной системы анализа и прогнозирования деятельности предприятия.

Вот лишь некоторые направления развития системы “МОНОПОЛИЯ” в ближайшее время.

Виноградова Лариса Анатольевна
Эксперт отдела продаж

Copyright © 1994-2016 ООО "К-Пресс"