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

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

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

В таких случаях наиболее подходит метод инкрементального тиражирования данных (то есть их перенос в одну или несколько систем), характерными особенностями которого являются:

-      периодическая передача порций данных из системы-источника в систему-приемник;

-      отслеживание изменений в очередной порции данных по сравнению с ранее переданными;

-      наличие контрольных событий, после которых данные за некоторый период считаются неизменяемыми;

-      просмотр и проверка найденных изменений с возможностью их подтверждения (приема) или отказа от них;

-      обработка только изменившихся данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

1.     Колесов Ю.Б., Сениченков Ю.Б. Моделирование систем. Объектно-ориентированный подход. СПб: БХВ-Петербург, 2009.

2.     Грегор Хоп, Бобби Вульф. Шаблоны интеграции корпоративных приложений. М.: Издат. дом «Вильямс», 2007.

3.     Егорычев И.Б. Инструментарий для построения автоматизированных учетных систем с web-интерфейсом // Программные продукты и системы. 2008. № 4. C. 49–52.