Перенесення оперативних даних до управлінського контуру
Загальновідомо, що управлінський облік базується на даних, що фіксують факти господарської діяльності. Щоб ці факти перетворилися на важливу управлінську інформацію, їх треба перенести з бухгалтерського обліку до управлінського контуру. Завдання загалом вирішено, але при його виконанні є певні особливості.
Оскільки бухгалтерський план рахунків або регістри оперативного обліку в загальному випадку відрізняються від управлінського плану рахунків, то для того, щоб отримувати інформацію в управлінському відношенні, слід спочатку перенести її на управлінський план рахунків. Це означає, що треба перенести всі проведення й аналітику, необхідні для повного відображення господарських та фінансових операцій на управлінському плані рахунків.
З цією метою найкраще створити окрему базу даних і перенести до неї з оперативної бази все необхідне. Такі дані можуть бути найрізноманітнішими. Наприклад, для будівельної компанії може знадобитися перенесення аналітики (проекти, тип обороту, статті бюджету руху грошових потоків і бюджету доходів та витрат), яких просто немає у бухгалтерському плані рахунків.
У загальному випадку швидкість побудови звітів в управлінській системі вища, ніж в оперативній за рахунок того, що інформація до неї надходить у більш укрупненому вигляді.
Перенесення факту можна умовно розбити на три етапи.
1. Експорт зі системи оперативного (бухгалтерського) обліку в проміжний формат даних (xls, xml тощо).
2. Транспортування проміжних даних (e-mail, ftp тощо).
3. Імпорт факту з проміжних даних до управлінської системи обліку.
Розглянемо вищеперелічені етапи докладніше.
Які дані важливіші?
Перша проблема, яку доводиться вирішувати на етапі експорту даних до системи оперативного обліку в проміжний формат, — це завдання ідентифікації даних, що їх треба експортувати. Є три способи розв’язання проблеми.
1. Вивантаження даних за період
Ця схема найчастіше використовується. Для користувача робота за нею проста й зрозуміла. Усе, що при цьому треба зробити, — вибрати період, за який вивантажуються дані, і натиснути кнопку. Хоча є й недолік — неможливо автоматично відстежувати зміни даних у системі оперативного обліку. А в результаті — необхідність відстежувати ці зміни у «ручному» режимі, перевивантажуючи періоди зі зміненою інформацією. Також до недоліків віднесемо необхідність вивантажувати дані як мінімум за цілий день, навіть якщо треба вивантажити лише одне проведення, що тягне за собою збільшення розміру файлу, який пересилається, і час на його формування.
Як правило, ця схема обміну використовується у системах оперативного обліку, де зміна даних «заднім числом» — рідкість.
2. Вивантаження тільки тієї інформації, яка ще не завантажувалася до управлінського контуру
Класична схема реалізації цього способу полягає ось у чому:
в інформаційній базі з оперативними даними створюється довідник реєстрації змін;
до довідника реєстрації змін щоразу при зміні документа або довідника автоматично записується посилання на змінений об’єкт і номер вихідного пакета;
номер вихідного пакета збільшується на одиницю при кожній операції експорту, незалежно від того, чи був цей пакет завантажений в управлінський контур.
Таким чином, кожного разу під час експорту даних вивантажується тільки та інформація, яка була додана або змінена. При успішному завантаженні такого пакета даних до системи управлінського обліку формується файл підтвердження з номером останнього завантаженого пакета. Цей файл, що підтверджує коректне завантаження, надсилається назад до тієї бази з фактом, на підставі якого він був сформований.
Усі ці дії відбуваються автоматично — від користувача оперативної бази даних потрібно лише ініціювати сеанс передачі/приймання даних і запустити обмін в оперативній базі даних (тобто натиснути кнопку). Наступного разу перед виконанням операції експорту фактичних даних усі об’єкти у довіднику реєстрації змін з номером вихідного пакета, що менший або дорівнює номеру підтвердженого пакета, видаляються. Лише після цього об’єкти, що залишилися, вивантажуються.
Недоліки схеми:
необхідність двостороннього зв’язку (тобто можливості як приймати, так і надсилати дані);
складніше налаштування системи обміну (проводиться фахівцем один раз перед початком експлуатації системи).
3. Вивантаження даних на вибір користувача
Як правило, цей спосіб є доповненням до першого або другого варіанта. Окремо він не використовується і полягає у тому, що список об’єктів на експорт формує сам користувач системи, безпосередньо вибираючи їх з інтерфейсу програми вивантаження. Приклад використання такого способу вивантаження — збій при завантаженні даних, у результаті якого не завантажився останній документ з оперативного обліку (помилка при транспортуванні файлу тощо). У цьому разі є сенс вручну повторно вивантажити і заново завантажити тільки цей документ.
Усе буде гаразд, якщо мережа надійна
Складність реалізації етапу транспортування проміжних даних безпосередньо залежить від якості каналу зв’язку між інформаційною базою з фактом та системою управлінського обліку. Ідеальний варіант для транспортування — коли системи перебувають в одній локальній мережі або мають швидкий доступ до Інтернету.
Швидкість передачі даних має бути достатньою (вона визначається на підставі розміру вивантаження і необхідної частоти обміну даними) для того, щоб отримувати факт з необхідною частотою. При невисокій швидкості з’єднання великі обсяги фактичних даних можуть не встигати пересилатися необхідну кількість разів на добу і вивантаження можуть накладатися одне на одне.
Оскільки при передачі (особливо у мережі Інтернет) можливим є доступ до даних третіх осіб, украй бажано всю інформацію, що передається, шифрувати. Найпростіше це зробити за допомогою звичайного архіватора (наприклад Rar), використовуючи стиснення з паролем, заразом вирішивши проблему контролю цілісності даних.
Якщо підсумувати всі «плюси» і «мінуси» деяких видів транспортування даних, отримаємо таку картину (див. таблицю 1).
Таблиця 1
Транспортування проміжних даних
Види транспортування даних
Переваги:
Недоліки:
E-mail
простота налаштування
обмеження за розміром листа (залежить від поштового сервера); час доставки листа може значно змінюватися; є імовірність отримання небажаної пошти (спаму)
FTP (Інтернет)
немає обмежень розміру даних, що пересилаються; передача даних «онлайн» («тут відіслали - там відразу отримали»)
необхідність підтримувати й адмініструвати ftp-сервер*
* FTP-сервер використовується для обміну інтернет-ресурсами, гнучко управляє об’ємами трафіку, списками доступних файлів і користувачів. Для використання потрібен так званий FTP-клієнт, що підключається до FTP-сервера (звідки будуть стягуватися або затягуватися дані).
Імпорт факту з проміжних даних до управлінської системи обліку
Нарешті факт у нас, залишилося коректно завантажити його в управлінську систему обліку. Ось тут, особливо на початку експлуатації, коли довіри до системи у користувача ще немає, потрібен механізм, який достатньо швидко й ефективно дозволить відповісти на запитання, чи «коректний факт» (тобто чи збігаються обороти за всіма рахунками й аналітикою).
Одне з вирішень проблеми — створення дзеркального бухгалтерського плану рахунків в управлінській системі (він створюється за допомогою стандартного функціонала управлінської системи і, як правило, вводиться вручну). Завантаження фактичних даних спочатку здійснюється на цей план рахунків і лише після звіряння з фактом із первинної бази даних відбувається перенесення проведень на управлінський план рахунків. Карта перенесення з бухгалтерського плану рахунків на такий самий план рахунків в управлінській системі досить проста, адже рахунки пов’язані один з одним однозначно один до одного.
Цей метод дозволяє значно спростити і прискорити процедуру перевірки якості факту, наприклад, за допомогою оборотно-сальдових відомостей у системі оперативного обліку і за таким самим планом рахунків в управлінській системі. Отже, позитивно відповівши на це запитання, при виникненні проблем з якістю факту в процесі експлуатації системи ми, довіряючи даним на бухгалтерсько-дзеркальному плані рахунків, позбавляємо себе необхідності повторно вивантажувати і завантажувати факт. У результаті можна зосередитися на перевірці правил перенесення з бухгалтерського на управлінський план рахунків.
Точно, як в аптеці
Розглянемо всі етапи трансляції факту з оперативних баз даних в управлінську на прикладі аптечної мережі. Ця схема успішно реалізована в одній з конфігурацій компанії «Інталев Україна».
Для експорту факту був використаний метод вивантаження даних за період. Проте виявилося, що фактичні дані досить часто змінюються заднім числом (така специфіка аптечної торгівлі). До того ж кваліфікація користувачів на місцях, які працюють з обліковою системою, недостатня для того, щоб вони самостійно й оперативно могли вирішувати проблему синхронізації даних. У результаті інформація, завантажена в систему управлінського обліку, часто не збігалася з фактичною. Довелося відмовитися від цього способу на користь обміну даними з підтвердженням.
Як «транспорт» для факту на рівні ієрархії «аптека-кіоск (пункт)» було вирішено використовувати «флешки», бо використання мережі Інтернет не скрізь було технічно можливим та обгрунтованим. Далі передача даних від аптеки до консолідованої бази факту відбувалася за допомогою Інтернету (ftp) за розкладом. Внаслідок цього була отримана центральна база факту з точністю до первинного документа. І, нарешті, завантаживши дані в управлінську систему обліку на бухгалтерський план рахунків і налаштувавши карту перенесення фактичних даних на управлінський план рахунків, отримали ЦБ «Управлінський облік».
Резюме
У кожному конкретному випадку і на кожному рівні взаємодії зі системою доцільно вибирати ті технології, які дозволять компанії вирішувати завдання консолідації найефективніше, не створюючи проблем, а розв’язуючи їх. Як показує практика, універсальних схем немає, тобто універсальна схема може виявитися неефективною.
Потрібен електронний підпис Не «1С»-ОМ єдиним Набрання чинності законами України про електронний цифровий підпис, електронні документи й електронний документообіг дало платникам податків не тільки можливість подавати електронну звітність. Це стане добрим стимулом для значного зростання ділової...
