| Оберон |
|
Прикладні рішенняЦей розділ присвячений не діючим прикладним рішенням, а скоріше тим напрацюванням що є в нашому розпорядженні і які не соромно запропонувати для розгляду потенційним клієнтам. Національна депозитарна система УкраїниБезсумнівно, найбільш потужна та розгалужена із прикладних систем, побудованих на базі СКА "Оберон". Забезпечує облік прав на цінні папери та прав за цінними паперами в Національному депозитарії України та більш ніж 130-ти зберігачів цінних паперів. Презентація програмного комплексу доступнабезпосередньо із сайту Національний депозитарій України. Створення системи почалося після перемоги у тендері у серпні 2007 року. До кінця жовтня велися роботи зі створення та узгодження Технічного завдання. У січні 2008 року готову систему було встановлено на випробувальному стенді. З 13 березня 2008 року систему запроваджено у промислову експлуатацію. На той момент у системі було реалізовано близько 45 депозитарних операцій, розподілений документообіг між учасниками системи вівся з використанням приблизно 100 типів повідомлень у форматі ISO.15022. Система створена коштом Державного бюджету України. Являє собою систему розподіленого фінансового документообігу, суміщену з обліковою системою та безліччю підсистем: інформаційно-аналітичною, білінговою, підсистемою побудови звітності перед регулятором ринку тощо. Основою системи є розподілена база даних, квантом якої є база даних вузла системи. Вузлом системи є Національний депозитарій України та кожен із зберігачів. База даних вузла системи працює під керуванням СУБД MS SQL або Oracle Залежно від вибору учасника депозитарної системи. Інформаційний обмін побудовано за топології "Зірка", центром якої є вузол Національного депозитарію. Особливістю даної системи є унікальна технологія гарячого резервування центрального вузла системи на віддаленій (понад 1000 км.) технічного майданчика, з постійною синхронізацією бази даних резервного вузла та з можливістю негайного перенесення навантаження на цей вузол у разі виходу з ладу основного технічного майданчика. нформаційним квантом обліково-операційної системи є депозитарна операція. В даний час система підтримує 93 облікові, інформаційні та адміністративні операції, їх Список постійно поповнюється. У ході виконання операцій, вносяться зміни до баз рахунків клієнтів (на кожному вузлі системи ведеться своя клієнтська база) та залишків на цих рахунках. Виконання Більшості операцій вимагає участі більш ніж одного вузла системи. У цьому випадку виконання операцій спирається на обмін між вузлами повідомлення формату ISO.15022. В даний час підтримується 172 типи таких повідомлень, їхня кількість постійно зростає. При цьому кожен вузол системи зберігає певну автономність, багато дій можуть виконуватися всередині вузла. без взаємодії з рештою учасників депозитарної системи. Інформаційний обмін між вузлами учасників депозитарної системи здійснюється в on-line режимі з допомогою каналів Internet. Використовується оригінальний протокол високого рівня, побудований над протоколом TCP Socket. Підтримується протокол проксі-сервера SOCKS5. Протокол обміну інформацією між вузлами системи побудований на сеансовому принципі та виключає втрату, дублювання чи втрату порядку прямування інформації під час передачі/прийому даних. Підтримується розподілена система нормативно-довідкової інформації, що включає близько 25 довідників, що автоматично оновлюються з центрального вузла системи на перефірійні вузли. За час експлуатації системи, перелік довідників та їх реквізитний склад кілька разів переглядався у бік розширення. На центральному вузлі системи існує штатний механізм формування дистрибутива до створення нового перифірійного вузла. До кожного вузла формується унікальний, персоніфікований дистрибутив. Існує централізована система автоматичного поновлення версій системи. Система оновлення версія побудована на кілька "поверхів": на центральному вузлі системи формується еталонний зліпок робочої версії системи для кожного типу перифірійних вузлів (розрізняються вона як мінімум СУБД, під керуванням якої працює база даних вузла); при підключенні перифірійного вузла, проводиться звіряння версії, встановленої на вузлі та еталонним зліпком, при необхідності оновлення передаються на вузол і завантажуються у його локальну базу даних; АРМ кожного користувача перифірійного вузла в початку роботи звіряє версію, встановлену на комп'ютері користувача, із завантаженою в базу даних та за необхідності здійснює оновлення версії на цьому комп'ютері. Система має багатофункціональний криптографічний захист, побудований на базі Системи криптографічного захисту інформації, що належить Національному депозитарію України, що спирається на власний авторизований Центр сертифікації ключів підвищеного рівня захисту. Криптозахист системи включає безліч заходів, від автоматичної постановки та перевірки ЕЦП на повідомленнях, якими обмінюються вузли системи, до шифрування потоку інформаційного обміну Численні супутні підсистеми, що прилягають до основної обліково-операційної депозитарної системи, що автоматизують виконання суміжних функцій. Деякі з них не належать до депозитарної діяльності навіть побічно, як, наприклад, покладена на Національний депозитарій функція ведення Національного реєстру кодів міждепозитарного обліку (код MDO). Реалізовано автоматизовану інформаційну взаємодію з іншими учасниками фондового та супутніх ринків. Серед них Національний банк України (взаємодія у галузі рефінансування банківських установ під заставу цінних паперів), фондові біржі, банківські установи (рух коштів, що супроводжує перехід прав власності на цінні папери); емітенти цінних паперів. Система активно розвивається. Так, вже у процесі промислової експлуатації додано обслуговування цінних паперів, номінованих в іноземних валютах, що призвело до появи цілого ряду довідників ("Валюта", "Курс валюти", "Країна",...), зміни формату існуючих сутностей, організації взаємодії із системою Національного банку України з автоматичної реплікації в депозитарну систему інформації про валютні коливання. курсів, зміни алгоритмів обробки та побудови вихідних форм, але, найголовніше, все це пройшло абсолютно непомітно для більшості учасників депозитарної системи. - - -Біржова електронна торгова системаБіржова електронна торгова система "Оберон-Бліц" зареєстрована як самостійна об'єкт авторського права(Авторське свідоцтво №19580 від 09.02.2007), похідний від системи комплексної автоматизації "Оберон". Для її експлуатації створено окрему юридичну особу. Розподілена система, призначена для проведення біржових торгів у реальному режимі часу. Включає найпростіший бек-офіс на стороні брокера і достатньо розвинений - за біржі. Інформаційний обмін побудовано за топології "Зірка", центром якої є вузол біржі. Підтримує різні торгові інструменти – подвійний закритий аукціон, односторонній аукціон, редукціон. Допускає ручне акцептування заявок, поданих зустрічними до реперної, або автоматичне акцептування на підставі виставленої вручну або автоматично обчисленої ціни відсікання. Надає можливость організації в рамках одного торгового майданчика кількох ринків, з індивідуальним визначенням торгового інструменту та правил акцептування кожного з них. Допускає як опцію для ринку часткове задоволення заявок. База даних центрального вузла ведеться під керуванням СУБД MS SQL( 2000 - xxxx ). База даних периферійних вузлів - під керуванням СУБД SQLite. На центральному вузлі системи існує штатний механізм формування дистрибутива до створення нового перифірійного вузла. До кожного вузла формується унікальний, персоніфікований дистрибутив. Система має багатофункціональний криптографічний захист, що спирається на зовнішню систему криптографічного захисту інформації (підключається за допомогою механізму плагіна, кожна біржа може використовувати свою криптосистему, можливе використання модуля-муляжу системи криптозахисту). Криптозахист системи включає низку заходів, від автоматичної постановки та перевірки ЕЦП на інформаційних повідомленнях, якими обмінюються вузли системи (заявки, угоди, котирування), до шифрування потоку інформаційного обміну між вузлами Спочатку створювалася для організованого ринку. Однак, згодом була створено та успішно впроваджено версію для товарно-сировинного ринку. Інформаційний обмін між вузлами учасників біржової системи здійснюється в on-line режимі з допомогою каналів Internet. Використовується оригінальний протокол високого рівня, побудований над протоколом TCP Socket. Підтримується протокол проксі-сервера SOCKS5. Протокол обміну інформацією між вузлами системи побудований на сеансовому принципі та виключає втрату, дублювання чи порушення порядку прямування інформації під час передачі/прийому даних. Підтримується розподілена система нормативно-довідкової інформації, що включає понад 10 довідників, що автоматично реплікуються з центрального вузла системи на вузли перефірій. Під час експлуатації системи можливий змінювати перелік довідників та їх реквізитний склад. У "фондовій" версії підтримується автоматизована взаємодія з інформаційною системою депозитарію, що забезпечує, зокрема, імпорт частини нормативно-довідкової інформації з депозитарної системи з автоматичною реплікацією її учасникам біржової системи. - - -Облік договорівБлок обліку договорів було створено у складі системи бухгалтерського обліку великого підприємства у 2004-2005 роки. Сама по собі система бух.обліку на базі системи "Оберон" мало цікава в тому сенсі, що не несе в собі нічого унікального: більш менш той же функціонал є в будь-якій системі бухобліку, зробленого на замовлення. Блок обліку договорів розрахований на ведення великої кількості договорів із постачальниками та споживачами за умов, коли з одним контрагентом укладено багато договорів. Договору поділяються наскалярні (з кінцевим обсягом робіт, терміном та сумою, нехай і коригованими додатковими угодами) таревольверні (тобто, підписані на невизначений термін, з регулярним виконанням робіт/наданням послуг та їх оплатами на підставі актів виконаних робіт). Для револьверних договорів ведеться розшифровка позиції за договором у заданий період обліку. Відповідно, всі нарахування та оплати за договорами мають подвійне маркування датою: коли ввиникло нарахування/здійснена оплата та за коли. Розрахунок пені та внесення її до бази договорів як нарахування особливого типу. Зв'язок з АРМами предметних підрозділів, які виконують роботи/надають послуги за договорами. Автоматичні нарахування за договорами виходячи з даних АРМів предметних підрозділів. Імпорт даних із систем банк-клієнт, розробка виписки, рознесення сум приходу по договорів (в автоматичному, напівавтоматичному чи ручному режимі). Обробка квитанцій, що надійшли з банків на розшифровку платежів. Рознесення квитанцій по договорів, обробка комісії банку: рознесення її за бухгалтерськими рахунками витрат пропорційно рознесення сум квитанцій за типами договорів. Зв'язок договорів з постачальниками з АРМами "Склад" та "Основні засоби". Обробка нестандартних договорів (наприклад, коли ціна на пісок, щебінь чи інший видатковий матеріал залежить від обсягу поставки протягом місяця, і, отже, матеріали, що надійшли не можуть бути розцінені в момент надходження, а до настання певної події враховуються тільки у натуральному обчисленні та не мають грошового еквівалента). Податковий облік. Ведення книги продажу та книги покупок. Виписування (друк) податкових накладних з урахуванням черговості настання подій. Особливості податкового обліку продажу бюджетному сектору та населенню. Коригувальні податкові накладні, відстеження стану коригувальних податкових накладних, коригування сум податкових зобов'язань щодо наступу належної події. Відстеження подій за договорами з постачальниками, ведення бази даних очікуваних податкових накладних з посиланням на співробітників, відповідальних за надходження цих податкових накладних. АРМ казначейства: рознесення договорів та/або позицій за договорами за статтями бюджетного плану. Планування оплат за договорами із постачальниками. Відстеження залишків на рахунках у банках, моніторинг надходжень на рахунки у порівнянні з прогнозом та планом у бюджеті грошових коштів коштів. Підготовка та узгодження платіжних доручень. Експорт затверджених платіжних доручень у системи банк-клієнт. Юридична служба: АРМ договірного відділу. Підготовка договорів до підписання, погодження договорів. Підготовка шаблонів текстів типових договорів. Врахування укладених договорів. Архів виконаних договорів. Додаткові угоди до договорів. Відстеження виконання скалярних договорів, термін якими минув/закінчується. Юридична служба: АРМ претензійно-позовного відділу. Аналітика по контрагентам (загальна позиція щодо контрагенту, позиція за кожним договором, позиція в розрізі періодів обліку). Підготовка претензій та позовів: ведення бази шаблонів претензій та позовів, напівавтоматичне формування претензії або позовної заяви за шаблоном з урахуванням даних блоку обліку договорів, а також індексів інфляції та деякої іншої інформації, що черпається з АРМу планово-економічний відділ. Ведення бази судових та позасудових розглядів з дебеторами та кредиторами, внесення до бази даних блоку обліку договорів як нарахування особливого типу штрафних санкцій, нарахованих рішеннями, що набрали законної сили судових інстанцій. - - -Кадри+ЗарплатаПочаткове рішення розроблено у межах того ж замовлення, що й блок обліку договорів. Трохи пізніше, в рамках іншого замовлення блок був дещо перероблений так, що за фактом для виконання розрахунку заробітної плати перестав бути потрібний бухгалтер. Застосовувався в цій якості, в тому числі, для перевірки даних розрахунку зарплати на підставі даних відділу кадрів та табелювання за тривалий період часу в минулому. Блок розрахований на велике підприємство з ієрархічним довідником орг-штатної структури, з нарахуваннями нічних, вечірніх, авральних, з урахуванням класності, надбавок, тимчасового виконання обов'язків, неповною зайнятістю, простоєм, та іншими принадами великого та небезпроблемного виробництва (спочатку створювався для великого газорозподільного господарства, де цього добра теж вистачає). Бухгалтер потрібен на етапі налаштувань: проставлення номерів рахунків для бухгалтерського обліку нарахувань, утримань та відрахувань (можуть бути встановлені для коду нарахування/утримання/відрахування, або в розрізі підрозділів, та можуть бути випмсані для співробітника персонально). АРМ планово-економічного відділу: аналітичний блок, підготовка обґрунтувань для зміни штатного розкладу, нова версія штатного розкладу (з переведенням посад та фахівців, що їх заміщають в інші підрозділи, якщо потрібно). АРМ відділу кадрів. Накази – проекти, затвердження, переміщення. Ведення карток співробітників, включаючи інформацію про інвалідність, кваліфікаційні розряди, аліменти тощо. Звітність, внутрішня та зовнішня (служба зайнятості, військкомат,...). АРМ "Табелювання". Крім штатних інтерфейсів, які використовуються для введення нерегулярної інформації (наприклад, лікарняні), включає спеціально розроблений інтерфейсний плагін, з можливістю введення/перегляду/коригування даних табеля у максимально адаптованому вигляді. АРМ адміністрування: розмежування повноважень табелювальників та інспекторів відділу кадрів, ведення довідників, ведення календаря робочих/неробочих днів, власне виконання розрахунку зарплати для однієї особи, підрозділу або всього підприємства. Результатами розрахунку є платіжна відомість (під друк та/або передачу до банку), реєстр зведених бухгалтерських проводок (аналітика за рахунками доступна для перегляду з АРМу адміністрування), розрахункові листки для видачі на руки, деякі специфічні форми. - - -Електронний документообертСистема канцелярського документообігу була створена для участі у тендері, який не було виграно, а систему, відповідно, впроваджено. Проте, сама система документообігу, розроблена на основі досить ретельно опрацьованих технічних вимог замовника, на наш погляд представляє деякий інтерес. Рішення розподілене. Ієрархічний довідник підрозділів із прив'язкою підрозділу до вузлу, у якому воно обслуговується. Довідник працівників підрозділів. Довідники контрагентів та співробітників контрагентів. Документ зберігається у базі даних у вигляді документа MS Office і за потреби пересилається між вузлами системи Зберігаються також усі версії документа. При необхідності, у вигляді посторінкових скан-копій зберігається і образ друкованого документа. Окремо, у сусідній таблиці, зберігаються резолюції на документі (текстові примітки обсягом до 4000 символів). Можливість встановлення рольового зв'язку між документами. Ведеться довідник ролей зв'язків між документами. Можливість пошуку документа за будь-якими параметрами картки документа, а також із можливістю повнотекстового пошуку у тілі документа (за винятком скан-копії у форматі картинки). Можливість перегляду історії документа: хто з ним працював, які резолюції накладав, які доручення згідно з документом давалися і як виконувались, версії документа. Автоматична реєстрація документів у журналах. Необмежену кількість журналів реєстрації вхідних, вихідних та внутрішніх документів, з автоматичною нумерацією документів та автоматичним скиданням нумерації із заданою періодичністю (рік, місяць, тиждень чи день). Можливість закріплення журналів за підрозділами. Ведення бази шаблонів документів з розбивкою на загальну, базу підрозділу та особисту базу шаблонів працівника. Можливість створення нового документа на підставі шаблону або взявши за основу будь-який з доступних у базі даних документів або їх версій. Маршрут документа. Перелік доручень, даних згідно з документом працівникам чи підрозділам. Для кожного доручення визначається хто його дав, тип (ведеться довідник типів доручень), особу чи підрозділ, якому доручення дано, час на виконання або строк виконання ("виконати до 12:00 16.04" або "виконати протягом двох робочих днів"). Доручення у зв'язку з документом оформляються в маршрут, що визначає черговість виконання доручень, які доручення мають виконуватися послідовно, а які можуть виконуватися паралельно. Співробітнику, якому надано доручення, або керівнику підрозділу, якщо доручення дано на підрозділ, надсилається повідомлення (можливо, з використанням електронної пошти, а можливо, внутрішньосистемними засобами) про активацію доручення (всі доручення, які відповідно до маршруту роз0писані на Виконавця). З погляду реалізації немає різниці між маршрутом при підготовці та погодження проекту внутрішнього або вихідного документа та маршрутом при обробці вхідного документа. У будь-якому випадку, у маршруті визначається співробітник-контролер, якому надсилаються повідомлення у разі зриву строків виконання доручень. Якщо доручення надано на підрозділ, керівник підрозділу (особа, наділена відповідним повноваженням, не обов'язково одна на підрозділ) має можливість розподілити це доручення конкретного співробітника. Ця ж особа може перенести доручення, дане співробітнику підрозділу, на іншого співробітника (наприклад, у разі хвороби працівника). Співробітник, якому дано доручення, може створити вкладений маршрут. У цьому випадку, виконання Початкового доручення припиняється до виконання доручень вкладеного маршруту. Вкладених маршрутів у зв'язку з одним дорученням може бути більше одного. При необхідності, доручення та пов'язані з ними документи пересилаються з одного вузла розподіленої системи в інший. Існує можливість моніторингу виконання доручень: можливість перегляду всіх доручень незалежно від документа, у зв'язку з яким вони надані, у розрізі "активні" / "прострочені" / "зупинені" тощо. Механізм оповіщень. Оповіщення надсилаються автоматично після виникнення події (активізація чи зрив терміну виконання доручення тощо) чи вручну користувачем. Можуть бути адресовані конкретному співробітнику чи підрозділу. За потреби повідомлення пересилаються на вузол, де обслуговується відповідний підрозділ. Користувач, якому надійшло повідомлення, інформується про наявність повідомлення звуковим сигналом та, залежно від встановленої терміновості повідомлення, появою повідомлення у спливаючому немодальному вікні або появою піктограми в системній області (tray). Користувач інформується про нове повідомлення безпосередньо при його появі, або, якщо воно з'явилося, коли користувач не був активний у додатку, - негайно по запуск програми. Про появу повідомлень, надісланих на підрозділ, інформуються усі співробітники підрозділу - доки повідомлення не буде позначене як прочитане. Механізм ведення справ. Документ може бути віднесений до певної справи. Номенклатура справ визначається уповноваженими користувачами. Віднесення документа до конкретної справи може бути здійснено у довільний момент життя документа. Існує механізм упорядкування справ та перенесення їх до архіву. Перенесення справи в архів не означає неможливість доступу до віднесених до нього документів. При створенні Системи канцелярського документообігу були ширше ніж зазвичай використані зовнішні програмні засоби: програми MS Office, Outlook/ Outlook Express, для перегляду образів документів використано налаштування операційної системи для визначення програми, що відповідає типам файлу образу. Для додатків MS Word та Excel були розроблені надбудови, які забезпечують збереження редагованого документа до бази даних СКА "Оберон". Для реалізації механізму оповіщень розробили окремий інтерфейсний плагін. | ||||||||||||||||
| © СКА -=Оберон=- | |||||||||||||||||