Постановка задачи

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

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

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

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

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

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

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

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

Основные требования к системе

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

  1. Он должен обеспечивать передачу из ERP-системы в систему РБУ всей информации, которая необходима для формирования отчетности в соответствии с российскими стандартами: это проводки хозяйственных операций и все элементы справочников, на которые имеются ссылки в проводках.
  2. Он должен обеспечивать передачу из системы РБУ в ERP-систему информации из тех разделов учета, которые по тем или иным причинам ведутся в системе РБУ, а данные из них требуются для работы разделов, обслуживаемых в ERP-системе.
  3. Он должен гарантировать полноту передаваемой информации с учетом возможного внесения изменений и дополнений в информационную базу.
  4. Он не должен допускать повторной передачи ранее переданных данных, которые после передачи не подвергались изменениям, если пользователь не требует такой передачи сознательно.
  5. В нем должна присутствовать процедура верификации переданной информации.
  6. Для настройки механизма обмена (в идеале) должно быть достаточно введения соответствующих настроечных параметров; это не должно требовать модификации текстов программных модулей.

Варианты реализации

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

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

Для такого варианта организации обмена данными характерна высокая оперативность. Однако для его успешной реализации требуется подробная информация об организации данных в обеих системах на табличном уровне представления. Далеко не во всех случаях такая информация доступна стороннему разработчику. Поэтому наилучшие результаты при реализации такого варианта будут достигнуты в том гипотетическом случае, если система обмена данными будет создаваться совместными усилиями фирм-разработчиков объединяемых ERP-системы и системы РБУ.

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

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

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

Еще один подход - использование системы РБУ как OLE-сервера. Естественно, он применим только при условии, что система РБУ может выступать в таком качестве.

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

В тех же случаях, когда ERP-система допускает непосредственное обращение к OLE-серверу, отпадает необходимость в программе управления обменом.

Варианты для iRenaissance

Применительно к ERP-системе iRenaissance компании Ross Systems (http://www.rossinc.com), кроме перечисленных вариантов реализации механизма передачи данных, есть еще два способа выборки необходимой информации из базы iRenaissance. Это связано с тем, что данные о проводках одних и тех же хозяйственных операций существуют в iRenaissance в нескольких экземплярах. С момента их возникновения эти данные хранятся в специализированных таблицах того функционального модуля, где они создавались. Далее они поступают в таблицу промежуточного хранения модуля главной книги GL_POSTINGS и после процедуры обновления главной книги попадают собственно в таблицы главной книги. Соответственно и извлечь эти данные можно как из таблиц главной книги, так и из таблиц функциональных модулей.

Одна из попыток создания системы обмена данными iRenaissance с системой РБУ принадлежит компании Interface (http://www.interface.ru). В качестве системы РБУ была выбрана «1С:Предприятие» фирмы «1С» (http://www.1c.ru). На выбор здесь повлияли следующие факторы:

  • фирма-разработчик ежеквартально обновляет все формы регламентированной отчетности в соответствии с изменениями российского законодательства;
  • открытость и хорошая документированность системы «1С:Предприятие», благодаря чему пользователь при необходимости может вносить в нее необходимые изменения самостоятельно или с привлечением сторонних организаций, не связанных непосредственно с компанией «1С»;
  • широкая распространенность и известность системы.

Обмен данными между iRenaissance и «1С:Предприятие»

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

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

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

Реализованный прототип системы обеспечивает двусторонний обмен данными между iRenaissance и «1С:Предприятие». В состав передаваемых данных входят проводки хозяйственных операций; аналитика передаваемых проводок по клиентам, поставщикам, подразделениям, товарам; виды и курсы используемых в проводках валют. Протокол обмена данными обеспечивает выполнение следующих функций:

  • пометку экспортированных данных;
  • проверку подтверждения приема со стороны получателя;
  • исключение повторного экспорта уже экспортированных и успешно принятых данных;
  • повторный экспорт в отсутствие подтверждения получателя;
  • проверка корректности принимаемых данных и формирование подтверждения приема.

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

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

В заключение отметим, что отработанные в рамках данного проекта алгоритмы преобразования данных можно использовать при создании систем обмена данными между другими ERP-системами и системами РБУ.

Юрий Пекач - специалист компании Interface. С ним можно связаться через Web-сайт компании: http://www.interface.ru