Методи дослідження файлів баз даних за допомогою спеціальних програмних продуктів
Методи дослідження файлів баз даних клієнта базуються на тому, що більшість бухгалтерських програмних продуктів зберігає в базі даних інформацію про бухгалтерські проводки. У проводки є обов'язковий набір реквізитів (облікова фраза). Як мінімум, це такі реквізити: дата, номер, текст, сума, валюта, рахунок дебету, рахунок кредиту, інформація про об'єкти аналітичного обліку за дебетом і кредитом проводки. Сучасні програмні продукти для КСБО також зберігають інформацію про імена користувачів, дату і час проводки. Ця база даних завантажується в спеціалізовану аудиторську програму. Після цього аудитор здійснює над цими даними ряд автоматизованих процедур. Як правило, в країнах, де дослідження файлів баз даних в комп'ютерному аудиті є поширеним явищем, аудитори для аналізу файлів даних використовують такі програмні пакети, як ACL або IDEA. IDEA — Interactive Data Extraction and Analysis — програмний продукт, який був розроблений в 1987 р. Канадським інститутом присяжних бухгалтерів (Canadian Institute of Chartered Accountants) як інструмент для зов-нішніх аудиторів , а сьогодні підтримується і вдосконалюється фірмою CaseWare IDEA. Цікаво, що інший подібний загальновживаний аудиторський програмний продукт — ACL (Audit Command Language) також був розроблений у м. Ванкувері, в Канаді фірмою ACL Services. Таке програмне забезпечення дає змогу аудитору здійснювати такі операції з бухгалтерськими проводками: знайти проводки, введені в незвичайний час дня, тобто не в робочий час; знайти проводки, введені незвичайними користувачами, анонімно або під явно вигаданим ім'ям, вищим керівництвом або, наприклад, працівниками відділу інформаційних технологій; відфільтрувати операції, що є типовими для підприємства, щоб побачити певні разові проводки; проаналізувати пари "дебет-кредит" на відповідність законодавству та правилам бухгалтерського обліку; • розрахувати окремі підсумки за рахунками, які потім звіряються із даними роздрукованих і офіційно завірених журналів і звітів. Це спеціалізоване аудиторське програмне забезпечення може здійснювати просте підсумовування, перехресне підсумовування, вибірку і аналіз результатів, перевіряти відповідність даних в багатьох різних файлах, імпортувати й експортувати дані, проводити аналітичні процедури та розрахунки над такими "первинними" даними. Аудиторське програмне забезпечення може допомогти відшукати й певні логічні аномалії у файлах даних про виключені транзакції (наприклад, про подвійну оплату за одним номером рахунку-фактури). Наприклад, перед аудитором поставлене завдання проаналізувати процес продажу продукції покупцям та її оплати за рік. За допомогою програми IDEA бухгалтерська програма клієнта зберігає дані в стандартному текстовому форматі поквартально. Також ми маємо наданий відділом кадрів підприємства-клієнта файл в форматі Microsoft Excel, який містить інформацію про скорочені імена користувачів (авторизацію), яким дозволене здійснення записів в бухгалтерській програмі (logon — поле Approved Auth), а також максимальні суми операцій, які дозволено проводити цим працівникам не звертаючись за дозволом до своїх керівників — поле Limit (табл. 3.1). Таблиця 3.1. Інформація про користувачів та їх ліміти авторизації
Approved Auth Limit ВС 100 000,00 СW 50 000,00 HMV 100 000,00 VST 90 000,00 WJN 85 000,00 Аудитору необхідно ідентифікувати всі операції, які відбувалися протягом вихідних днів, знайти всі операції з "круглими" сумами (наприклад, всі операції, суми в яких закінчуються двома нулями). Далі аудитор має перевірити, чи всі операції здійснені тими працівниками, яким це дозволено і чи не перевищений ліміт авторизації. На початку аудитор послідовно завантажує в програму IDEA квартальні масиви даних, щоб мати суцільну річну базу (рис. 3.3). Програма за допомогою функції Import Assistant належним чином ідентифікувала файл як текстовий (ASCII Delimited) і запропонувала розглядати перший рядок даних як назви полів даних. Після цього, використовуючи вбудовані засоби програми IDEA, ми вводимо в базу даних два додаткових службових поля, яких не було в базі даних бухгалтерської програми. Перше з них — NEW_AUTH нам знадобиться для перевірок з авторизації. А поле DAY_OF_WEEK буде заповнене програмою значеннями від 1 до 7 (обчислюється на підставі інформації про дату здійснення господарської операції; відповідає дням тижня з неділі — "1" до суботи — "7" послідовно). Після цього база даних про відвантаження продукції покупцям буде мати такий вигляд (рис. 3.4). У наведеному прикладі база даних операцій з відвантаження продукції має такі поля: INVOICE_NUMBER — номер накладної, INVDATE — дата накладної, AMOUNT — сума, CKNUMBER — порядковий (контрольний) номер запису, PMTDATE — дата оплати, AUTH та NEWAUTH — ім'я користувачів, під якими вони входять в програму, DAYOFWEEK — день тижня, в якому здійснена операція. Для того, щоб ідентифікувати всі операції, які відбувалися протягом вихідних днів, створюємо нову базу даних (пункт Direct Extraction з меню Data), яка і буде містити такі відібрані нами операції. Назвемо її "операції протягом вихідних днів" — Weekend Transactions. Після цього за допомогою редактора логічних виразів (Equation Editor) сформуємо запит, згідно з яким програма відбере всі операції, здійснені в неділю і суботу — DAY_OF_WEEK — 1 .OR. DAY_OF_WEEK = 7 (рис. 3.5). Результат вибірки — нова база даних, яка містить 166 записів — всього операцій за рік, здійснених у вихідні дні із загальної кількості 1 017 записів. Тепер аналогічно віднайдемо всі "заокруглені" за сумою операції. Записувати їх будемо в нову базу даних Round Payments, а логічним виразом буде AMOUNT % 100 = 0. Знак " % " відображає функцію, яка видає результат у вигляді десяткової частини числа, яке утворюється від ділен ня суми (amount) на 100. Якщо залишок нульовий, це вказує, що сума закінчується на "00". Результат виявився досить несподіваним (рис. 3.6). -
Рис. 3.4. Вигляд бази даних з реалізації продукції в програмі IDEA Всього відібраними згідно з нашим запитом виявились З операції. Причому дві — взагалі з нульовими сумами. Якщо перша відібрана операція на суму 79 500 може бути підставою для подальшого розслідування на предмет шахрайства, то наявність операцій з нульовими сумами однозначно свідчить, окрім помилок, допущених виконавцями в обліку, про слабкі засоби контролю прикладної програми щодо введення даних. Програма взагалі не повинна дозволяти вводити операції з нульовими сумами.
ми щодо введення даних. Програма взагалі не повинна дозволяти вводити операції з нульовими сумами.
Рис.3.5. Формування запиту на операції, здійснені у вихідні дні в програмі IDEA
Так само просто проаналізувати дані в IDEA шляхом побудови логічного виразу, який визначає прийнятний інтервал значень для одного чи декількох полів в базі даних. Наприклад, для того, щоб відібрати всі накладні з підсумками від 4000 до 5000 грн. це рівняння має виглядати таким чином: AMOUNT >= 4000 AND AMOUNT <= 5000. Аналогічним чином можна відібрати, наприклад, всі матеріальні цінності, що зберігаються на складі, залишок за кількістю яких більший від якогось значення.Для того щоб перевірити, чи всі операції здійснені тими працівниками, яким це дозволено, і чи не перевищений ліміт сум операцій, в межах якого їм дозволено їх здійснювати, слід до вже відкритої, основної бази даних бізнесових операцій (primary database) завантажити в програму також і файл Excel Approved Auth's з інформацією про користувачів, який буде допоміжною базою даних (secondary database) за допомогою команди об'єднання баз і отримаємо третю, об'єднану базу Payments and limits (рис. 3.6.).
Рис. 3.6. Одночасне завантаження кількох баз даних
Після цього, застосовуючи просту формулу AMOUNT > LIMIT одержуємо базу даних записів операцій Transactions over Limit, які здійснені з перевищенням дозволених лімітів. Ця база даних містить 205 записів. Причому з них насправді перевищено ліміт тільки в 35 операціях, а 170 записів попали в цю базу, тому що інформацію про цих користувачів відділ кадрів нам не надав взагалі, тобто таких користувачів немає у відповідному файлі Excel (відповідно, програма вважає цей ліміт таким, що дорівнює нулю). Якщо це не наслідок навмисного зламу системи ззовні, то, швидше за все, нові працівники просто могли використати для входу в систему ідентифікатори вже звільнених працівників, що знову ж таки свідчить про слабкі вбудовані в бухгалтерську програму засоби контролю доступу або ж про неузгодженість в роботі бухгалтерії і відділу кадрів. Цікавою для подальшого вивчення аудитором щодо виявлення, наприклад, шахрайства може бути інформація про те, з якими покупцями мали справу наші працівники — продавці або агенти, скільки вони уклали угод з кожним покупцем і на які загальні суми. Для цього використовується функція програми, що дає змогу підсумовувати за ключовими полями (рис. 3.7). У результаті отримуємо спеціальну базу даних, яка містить 123 записи (відповідає кількості найнятих підприємством продавців). Тут поле VENDOR містить код нашого продавця, поле PAYEE — назву покупця, поле NO_OF_ RECS — кількість угод, поле AMOUNT — загальну суму за цими угодами. Причому тут же можна переглянути і записи за кожною угодою зокрема. Надалі, якщо ми підозрюємо когось з наших працівників в шахрайстві, то ми могли б, наприклад, за допомогою програми порівняти номери домашніх телефонів продавців та підприємств-покупців, адреси тощо. Аудитор може використати для аналізу файлів клієнта і досить поширене програмне забезпечення із пакета програм Microsoft Office, наприклад Microsoft Access. На рис. 3.8. наведений файл lsentry.dbf бази даних однієї із типових конфігурацій програми "1С: Бухгалтерия", відкритий за допомогою Microsoft Access. Звичайно, в базі даних будь-якої програми дані зберігаються у певному внутрішньому форматі, і для того, щоб над ними здійснювати певні операції, необхідно знати цей формат. Так, з наведеного прикладу є очевидним, що в полях DATE і SUM зберігаються відповідно дата і сума проводки. А от в полях TIME, ACCDTID та ACCKTID — відповідно точний час введення проводки, рахунок дебету і рахунок кредиту у внутрішньому комп'ютерному форматі.
Рис. 3.7. Результат підсумовування продажу за продавцями та покупцями Поле CURRID призначене для зберігання інформації про тип валюти суми проводки (в прикладі — "0" — україн ська гривня, може бути "1" — долар США тощо). Коли відомий формат зберігання даних, аудитор може використовувати для їх обробки засоби власне СУБД Access.
Рис.3.8. Структура файла бази даних бухгалтерських проводок програми "1С: Бухгалтерия 7.7" Якщо в КСБО передбачена можливість збереження облікової інформації в одному зі стандартних форматів, наприклад Microsoft Excel, то завдання аналізу таких даних може значно спроститися. Наприклад, така можливість передбачена в конфігурації програми "1С: Бухгалтерия" для автоматизації обліку і планово-фінансової роботи українських університетів — бюджетних установ компанії "Тен-Тек" . Тут реалізована можливість формувати журнал операцій з проводками в зручному для перегляду і роздруку вигляді. Після перенесення в Excel дані виглядають таким чином (рис. 3.9.). Далі можна аналізувати дані або вручну стандартними засобами Excel, або створити програму із застосуванням мови Microsoft Office Visual Basic. Такий набір інструментів фактично дасть змогу аналізувати й перевіряти Головну книгу й оборотно-сальдові відомості, а також, наприклад:
Рис.3.9.Фрагмент з журналу проводок(перенесено в Excel з програми "1С: Бухгалтерия") отримати структуру будь-якого рахунку, тобто з якого дебету склався кредит того чи іншого рахунку з розбиттям за місяцями (у сумарному або відсотковому до загального обороту вираженні) або навпаки; отримати вибірку некоректних проводок; отримати вибірку значущих проводок (встановивши відсоток значущості до загального обороту); отримати вибірку сторнуючих проводок; перевірити проводки списання МШП; перевірити проводки нарахування амортизації нематеріальних активів; перевірити проводки нарахування амортизації основ них засобів; перевірити проводки нарахування платежів до бюджету; розрахувати структуру витрат; розрахувати і звірити показники податкових декларацій за ПДВ; провести аналіз даних, наприклад, порівняти оборот за певним рахунком з оборотами за іншими рахунками. Таким чином, програма може відстежити проводки з очевидно неправильною кореспонденцією рахунків (точніше кажучи, кореспонденції рахунків, які неможливі за правилами бухгалтерського обліку)33; вибрати проводки з великими сумами, сторнуючі тощо. Все це дає можливість скласти подальший план аудиторської перевірки, який буде спрямований на найбільш ризикові зони стосовно помилок. Насправді не тільки файли баз даних, що містять бухгалтерські проводки, можуть бути досліджені. Це можуть бути також, наприклад, бази даних із довідниками аналітичних об'єктів. Багато важливої інформації містять також журнали обліку завдань або системні журнали (log-файли), зокрема дані про використання ресурсів. Досліджуючи такі файли, можна, наприклад, порівняти плановий час роботи програми або працівника з фактичним і виявити всі серйозні розбіжності, що потребують подальшого розслідування. Іноді аудитор використовує спеціальне програмне забезпечення навіть для управління і контролю змісту програмних файлів з кодом — файлів-бібліотек (dll-файли). Таке програмне забезпечення реєструє всі зміни в коді, модулях і операційних системах. Пошук несанкціонованих змін у цих журналах допоможе розкрити порушення цілісності даних. Поширеним в українській практиці способом тестування облікового програмного забезпечення є його опосередкована перевірка за допомогою спеціальних бухгалтерських програм, підготовлених аудиторською фірмою. Ця методика тестування передбачає використання тільки реальних даних клієнта, що їх обробляють одночасно в комп'ютерній системі бухгалтерського обліку клієнта та в програмному забезпеченні, яке використовує аудитор. У світовій практиці вона має назву паралельного виконання обчислень (parallel simulation). Таку перевірку здійснюють шляхом рівномірного моделювання облікового циклу з програмною перевіркою всіх можливих параметрів облікового процесу. На основі цих моделей, що відображають особливості господарської діяльності конкретного підприємства, аудитор здійснює імітаційну обробку даних зі структурою, аналогічною структурі реального програмного забезпечення. Отримані вихідні дані порівнюють із реальними даними, і за результатами порівняння виявляють відхилення, що їх фіксують у протоколі перевірки. Таким чином, за допомогою спеціальних програмних засобів здійснюють перевірку, моделювання й аналіз облікових даних з метою визначення їх повноти, якості, правомірності й вірогідності. Для цього виконують порівняння змодельованих облікових даних з реальними даними інформаційної системи, а також здійснюють тестування розрахунків і перерахунків, підсумовування, повторне упорядкування і формування звітних даних і їх порівняння з реальними даними. Крім цього, здійснюють контроль правильності відновлення даних . Метод паралельного моделювання позбавляє від необхідності готувати тестові дані й дає змогу аудитору проводити тести неявно і з більшою частотою, не заважаючи роботі операційної системи і не змінюючи файлів КІСП клієнта. Для підприємств, з якими аудиторська фірма має довгострокові договірні відносини, можуть бути розроблені спеціальні вбудовані аудиторські модулі, які вбудовують у наявні програмні засоби обліку, контролю й аудиту (рис. 3.10.) і які дозволяють контролювати необхідні параметри облікового процесу. За допомогою цих модулів виконують відбір операцій, що становлять інтерес з погляду аудиторської перевірки. Вбудований аудиторський модуль фільтрує файли операцій та проводок і шукає аномалії в даних або в їх співвідношенні, наприклад, факти використання кредитної картки в дванадцяти країнах в межах двох годин. Відібрані при цьому дані групують за операціями у спеціальну аудиторську базу даних для подальшої обробки.
Рис. 3.10. Збирання аудиторської інформації за допомогою вбудованого контрольного модуля
Вбудовані програмні модулі застосовують такі види контролю даних: систематичний контроль, коли тестування облікових даних здійснюють за всіма основними критеріями (діапазон, зіставлення з нормативно-довідковою інформацією тощо); вибірковий контроль, здійснений на деякій вибірці даних (за визначеними операціями, за окремими задачами). Модулі для безперервного систематичного тестування простіше за все можна використовувати для систем, в яких вже передбачене ведення журналу помилок та реєстрації нетипових подій (transaction log) — наприклад, програм для електронної комерції. Безперервний моніторинг в цьому випадку дозволить аудитору оцінити не тільки ризик контролю, а й притаманний (властивий) ризик, оскільки тут саме ведення бізнесу цілковито базується на функціонуванні комп'ютерної системи. Прикладами подій, на які реагують подібні модулі, в цьому випадку можуть бути автоматична відмова від обслуговування у випадку, коли замовлення на товари більше від деякої визначеної суми, або якщо ціна перевищує заданий діапазон. Вбудовані аудиторські модулі слід застосовувати тільки при повній згоді й підтримці з боку керівництва підприємства клієнта і працівників внутрішнього аудиту (якщо така служба є на підприємстві), оскільки подібне втручання в схему і реалізацію засобів аудиту може поставити під питання незалежність аудитора.
Ви переглядаєте статтю (реферат): «Методи дослідження файлів баз даних за допомогою спеціальних програмних продуктів» з дисципліни «Комп’ютерний аудит»
