Система управления базами данных MS Access 2007

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

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

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

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

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

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

При очевидной простоте организации работы подобных программ практическая реализация этого подхода в продуктах различных фирм не одинакова. Если, например, в “1С: Бухгалтерии” (разработчик фирма “1С”) документы помещаются в журнал операций вместе с проводками, которые генерируются по этому же документу, то в “Инфо-Бухгалтере” (ТОО “Информатик”) документы хранятся отдельно от журнала в специальном архиве. Кроме того, в “Инфо-Бухгалтере” в журнал вносятся не проводки, а хозяйственные операции. Сам журнал получается фактически разбитым на две части — верхнюю и нижнюю: в верхней содержится описание хозяйственных операций, а проводки, формируемые по каждой операции, отображаются в нижней части экрана.

На практике при организации аналитического учета необходимо использование большого количества специфических данных, не имеющих прямого количественно-стоимостного выражения. Например, при ведении учета основных средств важными содержательными понятиями, без которых невозможен полноценный учет, являются: “норма амортизации”, “остаточная стоимость”, “дата ввода в эксплуатацию”, “материальноответственное лицо” и т.д. Понятно, что необходимость использования такого рода информации существенно нарушает стройную концепцию двойной записи, восходящую к Луке Пачиоли. Для того чтобы отразить специфику учета на каждом балансовом счете так, как этого требует его экономическое содержание и принятая учетная политика, в “1С: Бухгалтерии” и “Финансах без проблем” каждый объект аналитического учета имеет набор “параметров”, а в “Турбо-Бухгалтере”— аналитические признаки. Параметр или аналитический признак — это любая условнопостоянная характеристика объектов аналитического учета (количественная или качественная), которая может использоваться в алгоритмах обработки документов, расчетов, при формировании проводок и т.д. На практике использование параметров, благодаря которым не нарушается стройная концепция модели единого информационного поля в виде журнала операций, невозможно без знания пользователем внутреннего макроязыка программы. Это, в свою очередь, требует от него определенных навыков и знаний в области алгоритмизации вычислительных процессов. По сути именно специфика разделов учета приводила и приводит многих разработчиков программного обеспечения по автоматизации бухгалтерского учета к концепции функциональных бухгалтерских программ, построенных как совокупность АРМ, ориентированных на тот или иной конкретный раздел.

Программы, основанные на использовании принципов упрощенной формы учета, предназначены прежде всего для малых и средних предприятий, поскольку способны удовлетворить ограниченные информационные потребности небольшой бухгалтерии. На крупных предприятиях, в связи с возрастанием объема учетных работ, бухгалтерия объективно разделяется на участки учета. На каждом из них сохраняются общие принципы учета и в то же время выполняются специфические для данного участка функции. Разделение труда и специализация рабочих мест позволяет бухгалтерам более качественно и эффективно выполнять работу на своих участках, но одновременно возникают и проблемы их взаимодействия, так как обеспечить полную автономность работы бухгалтеров невозможно. Именно для отражения специфики отдельных участков учета, упорядочения потоков информации и согласования коллективной работы бухгалтеров в бывшем СССР была разработана журнально-ордерная форма учета, массовое внедрение которой началось после Великой Отечественной войны, когда Министерство финансов СССР в 1949 г. разработало типовые регистры журнально-ордерной формы учета и рекомендовало их всем отраслям промышленности. Журнально-ордерная форма учета пришла на смену громоздкой и нерациональной мемориально-ордерной форме учета, которая в настоящее время используется
редко. Основной недостаток журнально-ордерной формы заключается в том, что она в большей мере ориентирована на ручную обработку учетной информации. Несмотря на изменения, внесенные Министерством финансов в журнально-ордерную форму учета в 1963 г., в связи с внедрением счетно-клавишных машин, и все последующие модификации в организации журнально-ордерной формы учета, сегодня невозможно “перенести” на ПК журнально-ордерную форму учета, не изменив основных информационных связей между учетными регистрами. Трудоемок также процесс формализации всех учетных процедур, присущих этой форме бухгалтерского учета. Поэтому ко второй группе программных продуктов относятся программы, которые не основаны на принципах ни мемориально-ордерной, ни журнально-ордерной, ни упрощенной форм учета.

Отличительной особенностью этих программ является наличие совокупности автоматизированных решений различных учетных задач, таких, как учет основных средств и нематериальных активов, учет материальных ресурсов, учет труда и заработной платы и т.д., а также специального модуля для сведения главной книги и построения баланса. В различных пакетах число таких автоматизированных решений (программ-модулей) варьируется от пяти до двадцати. Например, в системе БЭСТ-4 (разработчик — ЗАО “Интеллект-Сервис”) их восемь, в комплексе “Галактика” (разработчик — корпорация “Галактика”) — восемнадцать (подсистема оперативного управления и бухгалтерского учета).

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

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

Системы MRP и ERP

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

Так, специалисты корпорации «Парус» считают, что для российских предприятий пока актуальна только поддержка требований стандарта MRP I (планирование потребностей в материалах), которые полностью реализуются, к примеру, в системе «Парус-корпорация». В полной мере претворить в жизнь процесс управления в соответствии со стандартом MRP II (планирование потребностей в ресурсах), ни на одном российском предприятии просто невозможно, в связи с чем поддержка данного стандарта в программе присутствует лишь частично.

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

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

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

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

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

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

Что касается беззаказного планирования, то в системе можно вести планы продаж, это своего рода уступка стандарту MRP I.

Значительное внимание уделено тому, чтобы система облегчала организацию решения различных бюрократических процедур. Например, здесь можно установить режим, при котором для выполнения отгрузки или платежа потребуется отдать соответствующее распоряжение, настроить механизмы рассылки сообщений по какому-либо факту, скажем, проинформировать об оплате лицо, которое должно выписать документ на отгрузку. Сообщения можно посылать по разным адресам – своим и чужим – различными способами: по сети, электронной почте, факсу. Настраивать способы и маршруты рассылки сообщений должен администратор системы. Следует отметить, что возможность рассылки уведомлений — это первый шаг к процессоориентированному управлению. По нашему мнению, система должна «уметь» не только рассылать уведомления, но и сама автоматически готовить проекты связанных документов и предлагать их для утверждения уполномоченным пользователям. Однако это ещё предстоит реализовать.

Существенное продвижение в поддержке стандартов MRP, ERP заметно и в системе «Галактика». Многие элементы этих стандартов присутствуют в ней уже давно, и теперь функциональное развитие идёт главным образом в сторону полномасштабной реализации требований MRP II. Это вполне понятно, поскольку основной контингент клиентов «Галактики» – средние и крупные производственные предприятия, и только функций управления закупками под существующие заказы, определяющихся требованиями MRP I, для таких организаций оказывается уже недостаточно, то есть крайне желательно, чтобы система взяла на себя помощь в управлении производственным циклом. Корпорация обещает выпустить новые модули — «Контроллинг» и «Управление портфелем заказов», которые и будут реализовывать соответствующие функции. Похоже, что на текущий момент «Галактика» продвинулась в данной области дальше других отечественных разработок.

Несколько необычной кажется на первый взгляд точка зрения, высказанная по поводу стандарта ERP специалистами фирмы «Бизнес-Консоль» — разработчиками системы «Фигаро». По их мнению, данный стандарт следует трактовать как корпоративную надстройку над MRP II, а не как соответствие известному перечню требований. ERP-систему здесь рассматривают в качестве автоматизированной системы управления, поддерживающей стандарты MRP, но дополненной блоками решения задач сквозного бюджетирования, подсистемой управления персоналом, позволяющей решать задачи консолидации отчётности. Поэтому основное внимание разработчики уделяют реализации стандартов MRP. Фирма работает преимущественно с крупными заводами, где применение этих стандартов уже актуально.

Система «Фигаро» пока не реализует в полной мере такие функции, как составление календарного плана движения товарно-материальных ценностей, загрузки производственных мощностей и трудовых ресурсов. Однако уже имеется возможность статического планирования потребностей в ресурсах, рассчитанных исходя из производственных заказов на определённый период. В этом заключается принципиальное отличие этой системы от западных, реализующих MRP. Там действительно составляется график, здесь же пока решается менее сложная задача — определение общей потребности в ресурсах, требуемых производственной программой. Но и это довольно серьёзный шаг вперёд, ведь даже такого набора функций для большинства наших предприятий, по-видимому, вполне достаточно, поскольку выполнение строгого графика поставки в настоящих условиях в России вряд ли возможно. Да и сами предприятия, скорее всего, ещё не готовы к тому, чтобы их управление осуществлялось по графику, рассчитанному компьютерной системой.

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

Вертикальная интеграция

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

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

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

Перед российскими разработчиками стоит сложный вопрос, связанный с тем, как лучше поступить: в спешном порядке заняться реализацией названных стандартов или выбрать альтернативу и найти способ интеграции своих разработок с соответствующими блоками западных систем. Многие выбрали первый путь, и кто-то уже начал понимать всю его сложность. Естественно, стандарты развиваются, и в этой гонке трудно успеть за иностранными компаниями, стартовавшими намного раньше. К тому же у них значительно больше ресурсов. По этой причине некоторые отечественные разработчики пошли по второму пути. Так поступила, например, компания «Никос-Софт»: она заключила стратегическое соглашение с финской фирмой Solagem — известным поставщиком компьютерных систем управления производством – и теперь активно занимается локализацией её продуктов и их интеграцией со своей системой. Похоже, этот альянс складывается удачно, и клиенты «Никос-Софт», наладив учёт на основе программного комплекса NS2000, смогут в дополнение получить первоклассное решение от опытного зарубежного разработчика.

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

Горизонтальная интеграция

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

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

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

Если они созданы одним разработчиком, то проблем обычно не возникает. В противном же случае организация взаимодействия ПО разных фирм выливается в серьёзную проблему. Для её решения необходимо не только создание специальных программ, обеспечивающих конвертацию данных из структур и форматов хранения, используемых одной программой, в структуры и форматы хранения другой, но и разработка новой технологии организации обмена данными между разными системами. Поставщикам корпоративных комплексов для крупных предприятий приходится сталкиваться с такого рода задачами очень часто. Как мы уже отмечали, в решении подобных проблем определённых успехов добилась корпорация «Галактика», сопрягая специфические отраслевые программы со своей системой. По свидетельству специалистов корпорации, проблему организации взаимодействия целого «зоопарка» программ, используемых на различных предприятиях, приходится решать почти при каждом внедрении. В этой связи интересно отметить, что налаживать взаимодействие случается не только с собственными разработками предприятий, но и с программами конкурентов. А что делать, если они уже задействованы в технологическом процессе управления? Вот и получается, что на одном предприятии мирно уживаются программы, скажем, от «1C», «Галактики» и других разработчиков.

В последнее время средства обмена данными с наиболее популярными программами встраиваются во многие разработки. Так, к примеру, большинство торгово-складских программ позволяют выгружать проводки в форматах, которые могут принимать наиболее популярные бухгалтерские программы: «1C:Бухгалтерия», «Инфо-Бухгалтер», «Турбо Бухгалтер», «Инфин-Бухгалтерия», разработки фирм «Парус», «Интеллект-Сервис» и ряд других. Однако структуры этих систем различны, и для конкретного решения подобной задачи нужно разрабатывать свой дополнительный программный блок.

Ещё хуже обстоит дело с взаимодействием бухгалтерских программ и программ финансового анализа. Так, популярнейшая программа «ИНЭК: АФСП» легко и просто «умеет» принимать данные отчётности из «1C: Бухгалтерии», а во всех остальных случаях требуется дополнительная настройка. Более широкие возможности интеграции имеются в программе Audit Expert фирмы «ПРО-Инвест-ИТ», где поддерживаются функции автоматической загрузки из форм отчётности различных бухгалтерских программ и существуют средства настройки загрузки из текстовых файлов. Кроме того, здесь можно создавать нестандартные методики анализа и для них экспортировать из бухгалтерских программ остатки и обороты счетов. Очень широкие возможности импорта данных из различных форматов предоставляет также модуль «ФинАнализ» системы «Галактика».

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

В то же время отдельные попытки стандартизации процедур взаимодействия программ уже предпринимаются. Так, например, фирмой «1C» и рядом других компаний при активном содействии специалистов российского представительства Microsoft предложен стандарт обмена коммерческой информацией под названием CommerceML. Он базируется на применении языка XML, поддерживаемого всеми ведущими мировыми компьютерными компаниями. В развитых странах проблема организации взаимодействия программ стоит не менее остро, чем у нас. Поэтому ведущие производители программного обеспечения во всём мире активно работают над созданием общесистемных средств, способствующих её разрешению. В основу этих средств положен язык XML, предназначенный для описания стандартов.

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

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

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

Важно лишь, чтобы эти программы поддерживали его, т. е. «понимали», какие данные чему соответствуют. Стандарт можно использовать и при организации электронной торговли через Интернет. К сожалению, пока этот стандарт поддерживается только в программах системы «1С: Предприятие 7.7», а также в разработках нескольких фирм, оказывающих услуги по организации торговли через Интернет. Большинство же разработчиков экономических программ пока далеки от понимания целесообразности поддержки, использования и развития подобного рода стандартов. О поддержке стандарта высказались разве что представители корпорации «Парус», другие же разработчики либо не предпринимали попыток в нём разобраться, либо критиковали его. Это недальновидная позиция. Ведь нацеленность стандарта правильная, и «1C» рано или поздно его «проведёт» и утвердит «де-факто», а пока ещё можно совместными усилиями его усовершенствовать.

Средства настройки программ

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

Средства настройки программ всё больше и больше «расслаиваются» по профессиональному принципу. Если раньше в бухгалтерских программах пользователю были предоставлены относительно несложные средства для настройки правил формирования типовых операций и расчёта показателей отчётности, то теперь в большинстве разработок кроме простого инструментария, ориентированного на конечных пользователей, имеются также и сложные механизмы, предназначенные для профессиональных внедренцев и программистов. Более того, чётко прослеживается тенденция «разделения» систем на разные слои. Нижний слой — ядро системы в машинномкоде, доступ к которому есть только у производителя системы. Средний – составляющие её программы, написанные на специализированных языках, открытые для внесения изменений профессионалам, использующим средства вычислительной техники. Верхний слой — готовые настройки типовых операций, относительно простые формулы, определяющие алгоритмы расчёта показателей отчётов, которые в принципе может изменить даже относительно неопытный пользователь системы. Такое расслоение кода программ можно только приветствовать. Увлечение созданием мощного универсального «языка программирования для бухгалтера» начало затихать.

Особенности «слоистого» построения программ рассмотрим на примере системы «Компас» для Windows (фирмы «Компас», Санкт-Петербург).

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

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

Значительный «кусок» бизнес-логики разработки фирмы «Компас» выполняется хранимыми процедурами SQL-сервера (средний слой). Эта часть открыта для изменений, и модифицировать её уже намного проще, чем создавать свои DLL-библиотеки. В то же время понятно, что изменения в хранимые процедуры может вносить лишь специалист, который не только знаком с языком SQL, но и хорошо представляет себе структуру базы данных и принципы функционирования системы. Если пользователь модифицировал какие-либо стандартные SQL-запросы, то при установке новой версии программа будет запрашивать возможность замены пользовательских запросов на фирменные. Эта процедура сравнения и обновления запросов реализована, на наш взгляд, очень удачно.

Большая часть логики выполнения прикладных функций реализована на встроенном языке системы (верхний слой). Это некое подобие языка Basic с огромным количеством встроенных функций, обеспечивающих в том числе и доступ к базе данных. На нём можно запрограммировать почти любую логику. Но это не всегда эффективно, а потому часть особо важных процедур прикладной обработки данных прописана в SQL-процедурах и даже в коде ехе-файла. Например, алгоритм расчёта подоходного налога жёстко встроен в систему. Разработчики объясняют это тем, что уж если такие алгоритмы поменяются, то всё равно придётся выпускать новую версию. То есть в отличие от системы программ «1С: Предприятие» или системы «Конкорд», где вся бизнес-логика реализуется на встроенном языке, здесь она как бы распределена по разным слоям системы. Интересно, что бизнес-процедуры на встроенном языке могут быть своеобразным «клеем», скрепляющим различные программные слои, поскольку из них можно вызывать встроенные функции, табличные, экранные формы, отчёты, SQL-запросы.

ОБЩИЕ СВЕДЕНИЯ О БУХГАЛТЕРСКИХ ИНФОРМАЦИОННЫХ СИСТЕМАХ. СИСТЕМЫ ЭЛЕКТРОННОГО ДОКУМЕНТООБОРОТА