Бухгалтерські конструктори: чи перейде кількість у якість?, Комерція, Різне, статті

У пошуках ідеалу

Зараз ринок програмних продуктів заповнений величезною кількістю великих і малих систем, що автоматизують бухгалтерський, податковий та інші види обліку на підприємствах. Виникає резонне питання: невже зробити подібну програму так просто, що за це не береться тільки ледачий?

І чому до цих пір не з’явилася “ідеальна” програма для автоматизації обліку, незважаючи на те що існує безліч компаній, які створюють конструктори і готові рішення і пишаються тим, що вони вже “Більше десяти років на ринку”.

Але факт залишається фактом. Користувачі незадоволені, дирекція змінює одну програму за одною, вибираючи з багатьох зол менше, і все одно не знаходить того, що влаштувало б і бухгалтерів, і керівництво в повній мірі.

Якщо це коробковий продукт, то функцій у ньому може бути недостатньо і він потребує значних доопрацювань під специфіку підприємства. У великих системах, навпаки, функцій, як правило, занадто багато, а це тягне за собою високу ціну, труднощі в освоєнні і в кінцевому підсумку використання дорогого програмного продукту далеко не в повному його обсязі.

Замовне професійне рішення також обходиться недешево і часто зводиться до встановлення стандартного продукту і доопрацювання його з урахуванням специфіки компанії.

Засоби малої автоматизації

А як бути малим підприємствам, які тільки починають свій бізнес? На яку програму звернути увагу? Багато хто, не задаючись цим питанням, просто створюють щось невелике, але своє, за допомогою інструментів, які практично завжди під рукою, – Access або FoxPro.

Сам бухгалтер далі електронної таблиці зазвичай не забирається, але системний адміністратор, наприклад, вже може зайнятися нескладної автоматизацією на одному зі знайомих йому інструментів.

Для прискорення процесу розробки таких програм також застосовуються бухгалтерські конструктори. Вони мають вбудовані засоби створення форм введення і друку документів, підключення довідників та звітності, дозволяють проектувати облікові системи значно швидше, ніж при використанні мов програмування загального призначення.

Можна довго обговорювати переваги і недоліки конструктора тієї чи іншої компанії, але тільки попрацювавши з декількома такими інструментами, розробник неминуче приходить до розуміння, що кожен з них має ті чи інші обмеження, непомітні з першого погляду, але роблять неможливою автоматизацію-якого процесу на конкретному підприємстві.

Коструктори … А що всередині?

Якщо звернутися до діяльності бухгалтерії, то її можна представити таким чином: реєстрація первинних документів, складання за ним бухгалтерських проводок або інших документів та отримання форм звітності.

Таким чином, розробляються програми повинні підтримувати автоматизацію створення документів, проводок і звітів, а пропоновані конструктори – прискорювати цей процес у порівнянні з програмуванням на мовах загального призначення.

З цього випливає, що призначення ядра конструктора – направляти діяльність програміста прикладних рішень і брати на себе реалізацію максимальної кількості загальних функцій, які не стосуються предметної області.

Що розробникам хотілося б бачити в “ідеальному” конструкторі облікових додатків? Можливість, по-перше, заводити структури первинних документів та їх обробки, включаючи шаблони журналів, форми введення і друкованих документів і прив’язку їх до довідників, а по-друге – створювати схеми проведення цих документів (інакше кажучи – типових операцій) і власних звітів.

Будемо виходити з того, що будь-яка сутність предметної області у програмній системі представляється документом. Документи збираються в журнали, посилаються на інші документи і довідники.

Ядро системи-конструктора відповідає за єдину для всіх типів документів обробку, а прикладному програмісту залишається тільки створити структуру даних, визначити алгоритми обробки окремих полів і форму виводу на друк.

Хоча більшість конструкторів надає вбудовані засоби редагування, в даний час об’єктно-орієнтований підхід дозволяє вирішити це завдання вже без розробки спеціальних засобів. Потрібно лише створити бібліотечний клас документа з необхідними методами і властивостями і його опис уявити прикладним програмістам. В ядрі можуть бути закладені такі функції, як поділ прав доступу, експорт-імпорт і вирішення інших завдань, які не мають відношення до конкретної предметної області.

До виключно “ядерним” функцій можна віднести і створення проводок по інформації, введеної в документ. При цьому шаблони проводок (типові проводки) – повинні бути доступні для редагування навіть не прикладним програмістам, а кінцевим користувачам.

Як же без звітів?

Будь-яке переміщення в системі, будь то грошові кошти, продукція або документи, відображається проводками з одного облікового регістру на іншу. Головне – не плутати такі проводки з бухгалтерськими, які відображають тільки переміщення грошових коштів і є окремим випадком проводок в загальному вигляді.

Облікові регістри, як і бухгалтерські рахунки, повинні мати настроюється набір атрибутів – аналітичних ознак, необхідних для створення зрізу аналітичних “кубів” – звітів.

При такому підході за наявними в системі проводках за допомогою звітів як частини ядра можна отримати дані для будь-якого виду обліку в будь-якому доступному розрізі аналітичних ознак. Таким чином, механізми генерації звітів будуть єдині як для бухгалтерії, так і, наприклад, для складу.

Отже, ми підійшли до того, що ідеальний, або майже такий, конструктор забезпечує розглянуті функції, а розробник прикладних рішень лише задає структуру даних і форму подання для сутностей предметної області. А ось з цим завданням чудово можуть впоратися мови загального призначення.

І тоді рутинна робота з програмування загальних функцій значно скорочується і розробники можуть основний час приділити аналізу та створення моделей майбутньої облікової системи.

Головне, що повинно бути досягнуто за допомогою такого конструктора, – велика незалежність результату роботи від програмістів, оскільки основна діяльність з проектування структур документів, їх зв’язків і алгоритмів проведення покладається на аналітичний відділ.

. NET на службі у автоматизаторів

Чому ж практично кожна фірма – разом з конструктором – створює власну мову програмування рішень? Може бути, тому, що до часу появи цих конструкторів відповідних коштів ще не було?

Уявімо, що ми вирішили розробити такий конструктор зараз, коли в нашому розпорядженні є технологія. NET. Ми створюємо описану структуру ядра і надаємо програмістам інтерфейси доступу та бібліотеки, а вони за допомогою стандартних мовних засобів С # або VB.NET будують прикладні рішення.

При цьому розробники Visual Studio. NET вже зняли багато проблем, пов’язаних з сумісністю, організацією розподілених систем, обміном даними між додатками, доступом до різних СУБД та оновленням клієнтських модулів (при використанні ASP.NET досить стандартного Internet Explorer).

Розширення функціональності проводиться нескладним додаванням в систему нових сутностей, а настройка бізнес-процесів на основі типових проводок доступна в будь-який момент самому користувачеві. Все що вносяться сутності уніфіковані, тому їх легко можуть використовувати інші розробники, а вбудована в. NET концепція збірок дозволить не замислюватися про можливе порушення працездатності системи при перетині імен.

Адаптація побудованої на такому ядрі системи для невеликого підприємства займе всього один-два тижні і не зажадає витонченого програмування, оскільки тут потрібно лише опис сутностей предметної області та типових проводок.

Звіти як одна з найбільш трудомістких частин системи надаються ядром, і їх потрібно тільки підлаштувати. При цьому розширювати й допрацьовувати систему зможе будь-який програміст, знайомий з Microsoft Visual Studio.NET.

Що далі?

Зараз розробники конструкторів йдуть приблизно таким шляхом, правда, зі змінним успіхом. Можливо, це відбувається саме тому, що більшість систем створювалося до появи таких засобів розробки, як Microsoft Visual Studio.NET, і програмісти зобов’язані підтримувати сумісність зі старими системами.

Цей багаторічний багаж більше не допомагає, а все сильніше тягне назад, створюючи чергові труднощі в автоматизації підприємств. Може бути, настав час на основі отриманого досвіду зробити щось нове, як вчинила компанія Microsoft, запропонувавши С #?

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*