Разработка ПО
Менеджмент
Для компаний
Для стартапов
Архитектура ПО
Taxer — це автоматизований бухгалтер. На цей момент системою користуються сотні тисяч Українських підприємців. Це онлайн платформа, у якій Ви можете швидко та безпечно здавати податкову звітність прямо в податкову через інтернет, використовуючи свій електронно-цифровий підпис. Цікавий факт. Засновник нашої організації systems.ingello раніше працював у компанії Таксер на позиції технічного директора і брав активну участь у розробці цього сервісу. У цій статті буде розказано про деякі публічно-відомі деталі автоматизації такого роду. Звісно, ми не будемо зачіпати інформацію, яка є корпоративно-цінною та конфіденційною для таксера.
https://taxer.ua
Таксер - це найбільший Український проєкт у сфері систематизації та автоматизації здачі податкової звітності з використанням цифрового підпису. Ним регулярно користуються сотні тисяч українських підприємців, підприємств, бухгалтерів і менеджерів. Компанія взяла на себе завдання розібратися і спростити, можливо, одну з найскладніших і найзаплутаніших предметних областей, і їй це вдалося, таксер один із перших подібних сервісів у країні і на 2024 рік - найпопулярніший і найзручніший. Сервіс дозволяє як у безкоштовному режимі здавати податкову звітність, так і в платному - де доступні засоби автоматичного заповнення документів, що суттєво скорочує витрати часу. Також містяться інструменти для ведення бухгалтерії, календарі, нагадувалки, обширна база знань. Компанія відстежує всі зміни в українському податковому законодавстві та актуалізує свій сервіс і інформаційну базу.
Якщо Ви стикалися з автоматизацією у сфері державних і адміністративних структур — Ви знаєте, яке це пекло. Якщо не стикалися — тоді, можливо, Вам доводилося працювати з бухгалтерією і здавати податкові звіти “вручну” — через ці паперові форми і відділення ДФСУ. Так ось. Автоматизувати здачу податкової звітності — у сотні разів важче.
Річ у тім, що API (або, точніше сказати, податкові державні шлюзи) працювали і працюють недостатньо стабільно, погано задокументовані, використовують непопулярні методи видачі даних і валідації, часто працюють контр-інтуїтивно з надлишковими або недостатніми функціями. Правила часто змінюються, іноді звіти не приймаються і на це не дається чіткого опису причини, доводиться з'ясовувати це непрямими і креативними методами. Програмісти на стороні держави можуть викочувати нові версії, достовірно не протестувавши результат або не внісши це до відповідної документації. Та документація, яка є, — це окрема і теж складна історія, яка не покриває всіх потенційних питань і проблем.
Сама система прийняття податкової звітності — це багатоетапний процес. Він включає в себе повністю автоматичну перевірку, напівавтоматичну і перевірку податковим інспектором особисто. Усі ці етапи повні потенційних помилок з обох боків, і в цих умовах має працювати сервіс, максимально згладжуючи кути цього заковиристого флоу.
Звісно, найважчий етап — це автоматичний режим. Сам звітний документ — це досить складний об'єкт (а точніше - група об'єктів, агрегат) із множиною взаємопов'язаних властивостей. Деякі документи складаються з композиту під-документів, що складаються з десятків блоків, кожен із яких складається з форм-опитувань. І таких документів навіть найзвичайніший підприємець здає кілька.
Щоб здати документ — він має пройти досить складну автоматичну перевірку — валідацію. Сам документ являє собою XML об'єкт (чи потрібно згадувати, що це не найпопулярніший формат у сучасних програмних інтерфейсах). А валідація являє собою XSD валідатор. Це теж складний вкладений XML об'єкт, який декларує правила, за якими звіт проходитиме перевірку. Деякі правила декларативні. А деякі описуються спеціальними регулярними виразами, з якими працювати набагато складніше. Деякі правила видають досить чіткі та зрозумілі помилки при описі. Деякі — непрямі відповіді, які вимагають вручну заходити в документ і аналізувати помилку, імітуючи повторну перевірку напівручними засобами.
Кожні зміни - як на стороні автоматизованої системи, так і на стороні податкових шлюзів — тягнуть за собою необхідність вносити зміни, які потребують уважності й аналітики. Для того, щоб системою користувалися сотні тисяч користувачів — вона має бути максимально-стійкою до такого роду змін, і це становить додаткові вимоги до архітектури системи та стандартів програмування.
Побудова такої архітектури - це наріжний камінь стартапів. Стартап на ранніх стадіях має викотити робочу функціональність швидко, і в нього немає ні фінансових, ні темпоральних ресурсів для того, щоб зробити все обдумано і за стандартами. Але через час стартап стає регулярною, системною, прибутковою компанією і стикається з тим, що його софт також має перейти на новий архітектурний рівень. Тут і з'являється робота для архітектора - системний аналіз, модульна декомпозиція, бережливий покомпонентний рефакторинг, усунення міжмодульного ефекту брижів, узагальнення дубльованої функціональності, нормалізація об'єктно-орієнтованої моделі, нормалізація бази даних зі збереженням цілісності, побудова робочого потоку в постачанні та розгортанні нових версій, систематизація конфігурування і багато багато іншого. Фахівцям є чим зайнятися на стадії активного росту успішного стартапа.
Але навіть якщо відволіктися від технічних особливостей державних сервісів і внутрішньої архітектури сервісу, то і в самій предметній області бухгалтерії та звітності викликів вистачає. Форм податкової звітності досить багато. І навіть це саме по собі - вже велика проблема. У кожній формі, окрім вищеописаної валідації, зашита
Наприклад, облік податку на додану вартість (ПДВ) потребує особливої уваги через складність розрахунків і необхідність своєчасного подання декларацій. Помилки в розрахунках або пропущені строки можуть призвести до серйозних штрафів і додаткових перевірок з боку податкових органів.
Розрахунок заробітної плати співробітників також є складним завданням. Він включає в себе не лише нарахування заробітної плати, а й обчислення податків, пенсійних і соціальних внесків. Кожне з цих обчислень підпорядковується своїм правилам і ставкам, які можуть змінюватися.
Якщо Ви таким займалися — то помітили, що є безліч правил, які пов'язують поля введення одне з одним, а безліч необхідних для заповнення операцій — це справжня рутина, група однотипних дій.
Також Ви могли помітити, що майже всю цю рутину можна скоротити, оскільки всі ці правила повторюються, іноді просто без видимого сенсу дублюються, а це означає - можуть виконуватися автоматично, необхідно лише знати деякі базові цифри для розрахунку і дані про підприємство. Дані про підприємство або підприємця рідко змінюються. Дані про доходи\витрати змінюються кожен обліковий цикл. Але їх небагато. Уся суть платної версії онлайн-сервісу Таксер у тому, що система знімає з Вас цей головний біль. Ви разово вводите дані про підприємство, а потім просто оновлюєте цифри (Ваші доходи\витрати\співробітники тощо). Решту Taxer зробить за Вас.
Технічно це досягається відтворенням математики кожної з форм. І тут також є великий простір для інженерної думки. Форми різні, але мають безліч спільних знаменників. І чим успішніше програміст зможе створити поліморфну форму, яка інкапсулює деякі спільні функції форм, чим успішніше програміст зможе узагальнити спільну математику, виносячи її за межі конкретної форми і скорочуючи дублювання — тим менше буде рутинної роботи у відділі розробки і тим більше відділ розробки зможе зробити нових корисних функцій для розвитку сервісу. Само собою, є безліч цікавих технічних нюансів, але ми не можемо висвітлити їх у цій статті.
Важливо згадати про безпеку. Підсистема обміну документів у таксері багато в чому схожа з іншими держ системами електронного підпису. До речі, такими ж користуються суди і приватні банки. До таких підсистем є досить жорсткі вимоги щодо шифрування і безпеки як такої. Перша проблема, з якою Ви зіткнетеся, якщо розробляєте онлайн-сервіс з ЕЦП — це те, що Ви юридично не маєте права отримувати електронно цифровий підпис Вашого клієнта через браузер і обробляти його на сервері. Це не законно. Тому різні сервіси вигадують безпечніші шляхи обробки. Хтось робить сертифікований браузерний застосунок. Хтось пропонує завантажити спеціальне програмне забезпечення. Завдання просте — ЕЦП має завантажитися і розшифруватися за спеціальним алгоритмом НА КОМП'ЮТЕРІ КЛІЄНТА. Наприклад, Таксер використовував схему з Java аплетом. Проблемна сторона цього рішення в тому, що користувач має попередньо встановити віртуальну машину Java на свій комп'ютер. І в цьому процесі є нюанси для різних операційних систем. Тому доводиться створювати відео-інструкції з установлення, адже навіть просунутий користувач тут може зіткнутися з різними незрозумілостями типу версіонування або змінних оточення.
Після того як усе успішно встановлено — процес простіше нікуди. Ви просто відкриваєте цей аплет, розроблений у таксері. Цей аплет за спеціальним алгоритмом розшифрує дані Вашої ЕЦП. І синхронізується із сервером таксер через спеціальний Gateway, який розроблений за допомогою Node JS і встановлює безперервне (сокетне) з'єднання з Java аплетом. Це працює миттєво, без жодних оновлень сторінок, відправок форм і тому подібних неприємностей.
Звісно, це далеко не все. Таксер — це найскладніший продукт із великою історією і безліччю особливостей як архітектури, так і інфраструктури. Сервіс постійно розвивається, додаються нові функції, а старі стають кращими і зручнішими. Усе це досягається поєднанням боротьби з гетерогенністю, високою складністю за допомогою своєчасної інженерної думки. І звісно, це роки непосильної праці різних фахівців — юристів, дизайнерів, програмістів, архітекторів, системних адміністраторів і фахівців технічної підтримки.
Якщо Вам потрібно розробити складний проєкт - запишіться до нас на консультацію, у нас є великий досвід в управлінні та розробці. І ми займаємося виключно складними системами багато років.
Посилання на презентацію нашої компанії - трохи нижче.
