Стаття також опублікована на dou.ua
Питання створення регламентованого обліку на базі Odoo витає в повітрі останні 5 років, але до сих пір немає рішення яке б відповідало запитам ринку — і тут я маю на увазі скоріше не функціонал, а питання підтримки та подальшого розвитку такого рішення. Деякі компанії вже вирішили і питання заробітної плати, і питання обліку ПДВ, але цього як показує практика недостатньо.
Я вже писав і про перспективи створення такого рішення, і про рішення у створенні якого я приймав безпосередню участь (і вийшло доволі непогано). Зараз же ще раз я хочу поговорити про те, що потрібно зробити для того, щоб на ринку з’явилося конкурентноздатне рішення, яке б дійсно могло спозиціонувати на ринку себе як заміна 1С (та її клона BAS).
І почну я з функціональної складової такого рішення.
Функціональна складова
Odoo не містить в собі функціоналу, який необхідний для ведення українського регламентованого обліку. Та локалізація, яка є в базовій версії, вона мінімальна і по сути додає лише план рахунків, податки та деякі дефолтні налаштування. І тут не треба казати, що Odoo погана. Той функціонал який є — його достатньо для ведення обліку в країнах Європи, Північної Америки або Близького сходу. І там якщо треба якась кастомізація — то вона мінімальна в більшості випадків. І Odoo в принципі на ті ринки і створювала свій продукт.
В Україні ж облік занадто регламентований і містить нюанси, яких немає в інших країнах (взяти ту ж першу подію по ПДВ). Але всі ці питання вже вирішені в тій чи іншій мірі. Що ж треба реалізувати в Odoo, щоб український бухгалтер зміг в ній повноцінно працювати?
Заробітна плата
Напевно це одна з найскладніших ділянок обліку і не всі ПЗ для ведення обліку містять її в повному обсязі. Але, на мою думку, повноцінне рішення для бухгалтерів повинно містити хоча б просту заробітну плату, яке б в у себе включало можливість робити розрахунок заробітної плати, відпускних, лікарняних, індексацій, включення в неї усіляких доплат та утримань та відображення результатів розрахунку у бухгалтерському обліку.
В Україні вже декілька компаній реалізували заробітну плату в Odoo:
- ERP Ukraine — на enterprise версії системи (досить проста) — почитати про неї можна ось тут
- Simbioz — на 14-й версії системі — напевно сама повноцінна заробітна плата, про неї я вже писав ось тут;
- BJet — на 11-й версії системи — повноцінна заробітна плата, але на превеликий жаль на застарілій версії системи. Має в собі ряд цікавих реалізацій, які я задію при створенні ЗП на 16-й версії (і це буде топова ЗП 🙂 )
Якщо підвести підсумки, то можна сказати, що реалізація заробітної плати на Odoo вже вирішена і особливих складнощів не представляє (ну хіба що часових та фінансових витрат).
ПДВ
Облік ПДВ в Україні це та ще пригода. Перед тим як його реалізовувати на Odoo, я шукав в якій ще країні світу є таке дурнувате поняття, як перша подія, і не знайшов. Може ви знаєте? Задача складна, але вона має декілька рішень. Я робив різні спроби, доки не народився такий варіант (до речі це відбулося у ванні), який був реалізований компанією Simbioz, про який я писав ось тут. Є і більш прості варіанти реалізації — наприклад у компанії ERP Ukraine воно реалізовано ось так. Але, як на мене, такий варіант вимагає багато ручної роботи і робить в обліку зайві бухгалтерські проведення.
В майбутньому рішенні, яке я буду реалізовувати в майбутньому, я врахую ті недоліки, які були в попередньо спроектованому та реалізованому рішенні і воно буде вже більш досконале. Або може зроблю по геть іншому. Поживемо -побачимо, як кажуть 🙂
Основні засоби
Відразу скажу, що особливих складнощів тут немає, але є одна проблема, яку треба вирішити першочергово — це відірвати основні засоби від складського обліку. Це, в принципі, можна зробити і штатними засобами системи (просто вказавши, що картка основного засобу — це сервіс). Дві спроби, які в мене були (і обидві цей суттєвий момент не враховували): одна в компанії Simbioz, де була зроблена досить суттєва доробка, яка дозволяла вести ідентифікований облік основних засобів, та робити їх переоцінку в разі потреби. Але це все одно ускладнювало їх облік і для реалізації деяких облікових моментів довелося би робити ще доробки.
Друга спроба була в компанії BJet, там досить прикольно реалізована закупівля основних засобів (краще ніж в Simbioz), а також додані операції з продажу, ліквідації та модернізації (а ось це взагалі прикольно вийшло, хоча я спочатку віднісся скептично до того варіанту реалізації, який запропонувати бізнес-аналітики).
Але зараз вже є розуміння того, як це треба зробити правильно, і наближений до цього варіант реалізований вже в Enterprise.
Валюта
Починаючи з 16-ої версії в Odoo було частково вирішено питання розрахунку та відображення в обліку курсових різниць при частковій оплаті інвойсу. В Enterprise ж є інструмент переоцінки валютних залишків, який працює майже так же як і модуль на ком’юніті currency_revaluation (якщо не помиляюсь). Мінусом є те, що він робить дуже велику кількість проведень. Я вже писав більш детально ось тут.
Ще досить складно реалізований облік операцій з купівлі-продажу валюти (він є, але потребує певної ручної роботи).
Ну і окремим питанням є формування собівартості імпортованих товарів — там є деякі певні облікові нюанси.
Інші питання
В регламентованому обліку є ще досить велика кількість нюансів, але їх досить легко вирішити в системі і вони не потребують якогось довгого та особливого проектування.
Розвиток рішення та його підтримка
Зрозуміло, що створювати відразу повноцінне рішення, яке б закривало усі-усі питання, дурна робота. Спочатку треба зробити рішення, яке б закривало більшу кількість питань, які є у бухгалтерів, та максимально пропрацьовувати ті, які займають у бухгалтера більшість часу (наприклад рознесення виписок, чи виписку документів з реалізації). Якщо якась операція трапляється досить рідко, то вкладати ресурси в реалізацію якоїсь фічі — марнотратство.
Але після реалізації якогось завершеного рішення (наприклад для невеликих юридичних осіб неплатників ПДВ) не варто думати, що ви все зробили. Рішення повинно еволюціонувати і надавати користувачам впевненість в тому, що:
- воно буде розвиватись і в нього постійно будуть додаватися нові фічі та функціонал, який буде дозволяти вирішувати більшість задач та робити роботу користувачів більш зручною;
- воно буде мати належний рівень підтримки. Регламентований облік (а особливо податковий) має властивість мінятися і якщо він змінився, то треба оперативно робити зміни в існуюче рішення. Це, власне кажучи, є одним із критеріїв вибору рішення користувачем.
Також рішення повинно мати належний рівень консультаційної підтримки і максимальну покритість документацією. Це напевно одне із самих критичних питань при створенні подібних рішень. Без цього ви будете стикатися з купою проблем і недовірою користувачів (воно й зрозуміло — хто захоче користуватися рішенням, по якому будуть виникати питання, а відповіді на нього не буде).
Не пам’ятаю вже, в котрий раз я про це пишу, але як показує практика — основна проблема при впровадженнях це не сам продукт, який впроваджується, а користувачі та їхні уявлення про те, яким має бути продукт (а він має в їх уявленні бути таким же як і той, яким вони користувалися до цього).
Тож, для більш вдалого переходу на новий продукт, великий акцент треба зробити на питанні навчання користувачів. Кожне рішення унікальне (звісно якщо це не клон якогось ПЗ), і не треба з нього робити інше рішення. Треба спочатку зрозуміти філософію рішення, максимально його освоїти і тільки після цього вносити в нього якісь зміни.
Це питання досить важливе, і його актуальність підтверджує відповідь на питання: «Скільки до сих пір компаній працюють на 1С 7.7 і чому вони не перейшли на 1С 8?». Подумайте над цим.
Висновки
Тож Odoo можна адаптувати під ведення в ній регламентованого обліку, але компанія, яка це зробить, повинна не забувати і про інші аспекти створення такого рішення. Я маю надію, що ринок все таки дочекається повноцінного рішення для ведення бухгалтерії і найбільше перспектив у цьому питанні є зараз у компанії Self-ERP, адже вона зараз закумулювала в себе найкращих спеціалістів по Odoo в Україні. Співпадіння вимог ринку та досвід фахівців — вагомий аргумент у створюванні очікуваного продукту.
