Перенос оперативных данных в управленческий контур

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

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

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

Перенос «факта» можно условно разбить на три этапа:

1. Экспорт из системы оперативного (бухгалтерского) учета в промежуточный формат данных (xls, xml и др.)
2. Транспортировка промежуточных данных (e-mail, ftp и др.)
3. Импорт факта из промежуточных данных в управленческую систему.

Рассмотрим  вышеперечисленные этапы подробнее. 

Какие данные важнее? 

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

1. Выгрузка данных за период

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

Как правило, эта схема обмена используется в системах оперативного учета, где изменение данных «задним числом» – редкость. 

2. Выгрузка только той информации, которая еще не загружалась в управленческий контур.

Классическая схема реализации данного способа заключается в следующем:

• в информационной базе с оперативными данными создается справочник регистрации изменений:
• в справочник регистрации изменений каждый раз при изменении  документа или справочника автоматически записывается ссылка на изменённый объект и номер исходящего пакета:
•  номер исходящего пакета увеличивается на единицу при каждой операции экспорта, независимо от того, был ли этот пакет загружен в управленческий контур.

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

Недостатки схемы:

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

3. Выгрузка данных по выбору пользователя.

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

Все будет в порядке, если сеть надежная 

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

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

Транспортировка промежуточных данных

Импорт «факта» из промежуточных данных в управленческую систему учета

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

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

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

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

Точно, как в аптеке 

Рассмотрим все этапы трансляции факта из оперативных баз данных в управленческую на примере работающей аптечной сети. Эта схема успешно реализована в одной из конфигураций компании «ИНТАЛЕВ Украина». 

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

Резюме 

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