Бухгалтерские конструкторы:перейдёт ли количество в качество?

Сергей Трофимов

PCWeek/RE №35/2003

В поисках идеала

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

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

Средства малой автоматизации

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

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

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

Коструктор... А что внутри?

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

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

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

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

        К исключительно “ядерным” функциям можно отнести и создание проводок по информации, введенной в документ. При этом шаблоны проводок (типовые проводки) — должны быть доступны для редактирования даже не прикладным программистам, а конечным пользователям.

Как же без отчетов?

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

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

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

.NET на службе у автоматизаторов

        Почему же практически каждая фирма — вместе с конструктором — создает собственный язык программирования решений? Может быть, потому, что ко времени появления этих конструкторов подходящих средств еще не было?

        Представим, что мы решили разработать такой конструктор сейчас, когда в нашем распоряжении есть технология .NET. Мы создаем описанную структуру ядра и предоставляем программистам интерфейсы доступа и библиотеки, а они при помощи стандартных языковых средств С# или VB.NET строят прикладные решения. При этом разработчики Visual Studio .NET уже сняли многие проблемы, связанные с совместимостью, организацией распределенных систем, обменом данными между приложениями, доступом к различным СУБД и обновлением клиентских модулей (при использовании ASP.NET достаточно стандартного Internet Explorer). Расширение функциональности производится несложным добавлением в систему новых сущностей, а настройка бизнес-процессов на основе типовых проводок доступна в любой момент самому пользователю. Все вносимые сущности унифицированы, поэтому их легко могут использовать другие разработчики, а встроенная в .NET концепция сборок позволит не задумываться о возможном нарушении работоспособности системы при пересечении имен.

        Адаптация построенной на таком ядре системы для небольшого предприятия займет всего одну-две недели и не потребует изощренного программирования, поскольку здесь нужно лишь описание сущностей предметной области и типовых проводок. Отчеты как одна из самых трудоемких частей системы предоставляются ядром, и их нужно только подстроить. При этом расширять и дорабатывать систему сможет любой программист, знакомый с Microsoft Visual Studio.NET.

Что дальше?

        Сейчас разработчики конструкторов идут примерно таким путем, правда, с переменным успехом. Возможно, это происходит именно потому, что большинство систем создавалось до появления таких средств разработки, как Microsoft Visual Studio.NET, и программисты обязаны поддерживать совместимость со старыми системами. Этот многолетний багаж больше не помогает, а все сильнее тянет назад, создавая очередные трудности в автоматизации предприятий. Может быть, настало время на основе полученного опыта сделать нечто новое, как поступила компания Microsoft, предложив С#?