Деловой еженедельник "КОНТРАКТЫ" №48/2008 Деньги:
Причины и следствия инфляционных процессов в Украине :: Кто еще нужен и
уже не нужен работодателям :: Почему резко дешевеет коммерческая
недвижимость...
Перенос оперативных данных в управленческий контур
Общеизвестно, что управленческий учет основывается на данных, фиксирующих факты хозяйственной деятельности. Чтобы эти факты превратились в важную управленческую информацию, их необходимо перенести из бухгалтерского учета в управленческий контур. Задача в общем-то решена, но при ее выполнении есть некоторые особенности.
Так как бухгалтерский план счетов или регистры оперативного учета в общем случае отличаются от управленческого плана счетов, то для того чтобы получать информацию в управленческом отношении, следует вначале перенести ее на управленческий план счетов. Это значит, что нужно перенести все проводки и аналитику, необходимые для полного отражения хозяйственных и финансовых операций на управленческом плане счетов.
С этой целью лучше всего создать отдельную базу данных и перенести в нее из оперативной базы все необходимое. Такие данные могут быть самыми различными. Например, для строительной компании может потребоваться перенос аналитики (проекты, тип оборота, статьи бюджета движения денежных потоков и бюджета доходов и расходов), которых просто нет в бухгалтерском плане счетов.
В общем случае скорость построения отчетов в управленческой системе выше, чем в оперативной за счет того, что информация в нее поступает в более укрупненном виде.
Перенос факта можно условно разбить на три этапа.
1. Экспорт из системы оперативного (бухгалтерского) учета в промежуточный формат данных (xls, xml и др.).
2. Транспортировка промежуточных данных (e-mail, ftp и др.).
3. Импорт факта из промежуточных данных в управленческую систему учета.
Рассмотрим вышеперечисленные этапы подробнее.
Какие данные важнее?
Первая проблема, которую приходится решать на этапе экспорта данных из системы оперативного учета в промежуточный формат, — это задача идентификации данных, которые необходимо экспортировать. Есть три способа решения проблемы.
1. Выгрузка данных за период
Это наиболее часто используемая схема. Для пользователя работа по ней проста и понятна. Все, что при этом необходимо сделать, — выбрать период, за который выгружаются данные, и нажать кнопку. Хотя есть и недостаток — невозможно автоматически отслеживать изменения данных в системе оперативного учета. А в результате — необходимость отслеживать эти изменения в «ручном» режиме, перевыгружая периоды с измененной информацией. Также к недостаткам отнесем необходимость выгружать данные как минимум за целый день, даже если нужно выгрузить всего одну проводку, что влечет за собой увеличение размера пересылаемого файла и время на его формирование.
Как правило, эта схема обмена используется в системах оперативного учета, где изменение данных «задним числом» — редкость.
2. Выгрузка только той информации, которая еще не загружалась в управленческий контур
Классическая схема реализации данного способа заключается в следующем:
в информационной базе с оперативными данными оздается справочник регистрации изменений;
в справочник регистрации изменений каждый раз при изменении документа или справочника автоматически записывается ссылка на измененный объект и номер исходящего пакета;
номер исходящего пакета увеличивается на единицу при каждой операции экспорта, независимо от того, был ли этот пакет загружен в управленческий контур.
Таким образом, каждый раз при экспорте данных выгружается только та информация, которая была добавлена или изменена. При успешной загрузке такого пакета данных в систему управленческого учета формируется файл подтверждения с номером последнего загруженного пакета. Этот подтверждающий корректную загрузку файл отправляется обратно в ту базу с фактом, на основании которого он был сформирован.
Все эти действия происходят автоматически — от пользователя оперативной базы данных требуется лишь инициировать сеанс передачи/приема данных и запустить обмен в оперативной базе данных (т. е. нажать кнопку). В следующий раз перед выполнением операции экспорта фактических данных все объекты в справочнике регистрации изменений с номером исходящего пакета меньше или равным номеру подтвержденного пакета удаляются. Только после этого оставшиеся объекты выгружаются.
Недостатки схемы:
необходимость двусторонней связи (т. е. возможности как принимать, так и отправлять данные);
более сложная настройка системы обмена (производится специалистом один раз перед началом эксплуатации системы).
3. Выгрузка данных по выбору пользователя
Как правило, этот способ является дополнением к первому или второму варианту. Отдельно он не используется и заключается в том, что список объектов на экспорт формирует сам пользователь системы, непосредственно выбирая их из интерфейса программы выгрузки. Пример использования такого способа выгрузки — сбой при загрузки данных, в результате которого не загрузился последний документ из оперативного учета (ошибка при транспортировки файла или т. п.). В этом случае имеет смысл вручную повторно выгрузить и заново загрузить только этот документ.
Все будет в порядке, если сеть надежная
Сложность реализации этапа транспортировки промежуточных данных напрямую зависит от качества канала связи между информационной базой с фактом и системой управленческого учета. Идеальный вариант для транспортировки — когда системы находятся в одной локальной сети или имеют быстрый доступ к Интернету.
Скорость передачи данных должна быть достаточной (она определяется на основании размера выгрузки и необходимой частоты обмена данными) для того, чтобы получать факт с необходимой частотой. При невысокой скорости соединения большие объемы фактических данных могут не успевать пересылаться необходимое число раз в сутки и выгрузки могут накладываться друг на друга.
Так как при передаче (особенно в сети Интернет) возможен доступ к данным третьих лиц, крайне желательно всю передаваемую информацию шифровать. Проще всего это сделать с помощью обычного архиватора (например Rar), используя сжатие с паролем, заодно решив проблему контроля целостности данных.
Если подытожить все «плюсы» и «минусы» некоторых видов транспортировки данных, получим следующую картину (см. таблицу 1).
Таблица 1
Транспортировка промежуточных данных
Виды транспортировки данных
Достоинства:
Недостатки:
E-mail
простота настройки
ограничение по размеру письма (зависит от почтового сервера); время доставки письма может значительно изменяться; существует вероятность получения нежелательной почты (спама)
FTP (Интернет)
отсутствуют ограничения размера пересылаемых данных; передача данных «онлайн» («здесь отослали - там сразу получили»)
необходимость поддерживать и администрировать ftp-сервер*
* FTP-сервер используется для обмена интернет-ресурсами, гибко управляет объемами трафика, списками доступных файлов и пользователей. Для использования необходим так называемый FTP-клиент, подключающийся к FTP-серверу (откуда будут скачиваться или закачиваться данные).
Импорт факта из промежуточных данных в управленческую систему учета
Наконец факт у нас, осталось корректно загрузить его в управленческую систему учета. Вот здесь, особенно в начале эксплуатации, когда доверия к системе у пользователя еще нет, необходим механизм, который достаточно быстро и эффективно позволит ответить на вопрос, «корректен ли факт» (т. е. совпадают ли обороты по всем счетам и с аналитикой).
Одно из решений проблемы — создание зеркального бухгалтерского плана счетов в управленческой системе (он создается с помощью стандартного функционала управленческой системы и, как правило, вводится вручную).
Загрузка фактических данных вначале осуществляется на этот план счетов и только после сверки с фактом из первичной базы данных происходит перенос проводок на управленческий план счетов. Карта переноса с бухгалтерского плана счетов на такой же план счетов в управленческой системе довольно проста, так как счета связаны друг с другом однозначно один к одному.
Этот метод позволяет значительно упростить и ускорить процедуру проверки качества факта, например, с помощью оборотно-сальдовых ведомостей в системе оперативного учета и по такому же плану счетов в управленческой системе. Таким образом, положительно ответив на этот вопрос, при возникновении проблем с качеством факта в процессе эксплуатации системы мы, доверяя данным на бухгалтерско-зеркальном плане счетов, избавляем себя от необходимости повторно выгружать и загружать факт. В результате можно сосредоточиться на проверке правил переноса с бухгалтерского на управленческий план счетов.
Точно, как в аптеке
Рассмотрим все этапы трансляции факта из оперативных баз данных в управленческую на примере работающей аптечной сети. Эта схема успешно реализована в одной из конфигураций компании «Инталев Украина».
Для экспорта факта был использован метод выгрузки данных за период. Однако оказалось, что фактические данные довольно часто изменяются задним числом (такова специфика аптечной торговли). К тому же квалификация пользователей на местах, работающих с учетной системой, недостаточна для того, чтобы они самостоятельно и оперативно могли решать проблему синхронизации данных. В результате информация, загруженная в систему управленческого учета, часто не совпадала с фактической. Пришлось отказаться от этого способа в пользу обмена данными с подтверждением.
В качестве «транспорта» для факта на уровне иерархии «аптека-киоск (пункт)» было решено использовать «флэшки», так как использование сети Интернет не везде было технически возможным и обоснованным. Далее передача данных от аптеки к консолидированной базе факта происходила с помощью Интернета (ftp) по расписанию. Вследствие этого была получена центральная база факта с точностью до первичного документа. И, наконец, загрузив данные в управленческую систему учета на бухгалтерский план счетов и настроив карту переноса фактических данных на управленческий план счетов, получили ЦБ «Управленческий учет».
Резюме
В каждом конкретном случае и на каждом уровне взаимодействия с системой целесообразно выбирать те технологии, которые позволят компании решать задачи консолидации наиболее эффективно, не создавая проблем, а устраняя их. Как показывает практика, универсальных схем не существует, т.е. универсальная схема может оказаться неэффективной.
Нужна электронная подпись Не «1С»-ОМ единым Вступление в силу законов Украины об электронной цифровой подписи, электронных документах и электронном документообороте дало налогоплательщикам не только возможность подавать электронную отчетность. Это станет хорошим стимулом для значительного роста...
