58
Array ( )
Контакты
в регионах
Контакты в регионах
Свернуть
РоссияМосква тел: +7 (495) 223-27-93 e-mail: info@intalev.ru
РоссияНовосибирск тел: +7 (383) 203-53-95 e-mail: info@intalev-siberia.ru
УкраинаКиев тел: +38 (044) 537-74-11 e-mail: sales@intalev.com.ua
КазахстанАлма-Ата тел: +7 (727) 311-07-96 e-mail: info@intalev.kz
+7 (495) 223-27-93
info@intalev.ru
Услуги
Компания
Мероприятия

Все мероприятия
История успеха

ВИСАНТ
Сергей Бондарев, Член Правления.

«...Для нас было важно комплексное предложение по постановке системы стратегического управления... »

Читать
Все отзывы

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



Автор(ы): В. Янчук
Вадим Янчук, консультант по управленческим технологиям украинского офиса ГК «ИНТАЛЕВ»

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

Вадим Янчук,
консультант по управленческим технологиям украинского офиса ГК «ИНТАЛЕВ»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Виды транспортировки данных

Достоинства

Недостатки

e-mail
  • Простота настройки
  • Ограничение по размеру письма (зависит от почтового сервера);
  • Время доставки письма может значительно измениться;
  • Существует вероятность получения нежелательной почты (спама)

FTP (Интернет)

  • Отсутствуют ограничения размера пересылаемых данных;
  • Передача данных «онлайн» («здесь отослали- там сразу получили»)
  • Необходимость поддерживать и администрировать ftp-сервер.

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

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

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

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

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

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

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

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

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


v.1.81.1.1

v.1.81.1.2

Импортировать данные в консолидированную базу надежнее всего с помощью Интернета по протоколу FTP

В качестве «транспорта» для факта на уровне иерархии аптека-киоск (пункт) было решено использовать «флешки», т.к. использование сети Интернет не везде было технически возможным и обоснованным. Далее передача данных от аптеки к консолидированной базе «факта» происходила с помощью Интернет (ftp) по расписанию. В результате мы получали центральную базу «факта» с точностью до первичного документа. Загрузив данные в управленческую систему учета на бухгалтерский план счетов, и настроив карту переноса фактических данных на управленческий план счетов, получаем ЦБ «Управленческий учет».


ЦБ «Управленческий учет»

На каждом уровне иерархии аптечной структуры использовались разные способы транспортировки данных в управленческий учет.

Резюме 

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