This article outlines the current limitations and areas for improvement within the GNUKhata application. We are committed to transparency and continuous enhancement of GNUKhata, ensuring that the users are well-informed about the current state of the application and the plans for future development.
A brief history
GNUKhata development was started in 2009. It has went through multiple framework changes over the years, with contributions from various people throughout its evolution. The current version of GNUKhata employs a RESTful architecture, featuring an API server called gkcore developed in Pyramid (Python-based web framework) for the backend and the frontend called gkapp is decoupled and built using Vue.js v2. While gkcore has been there from 2015, the current frontend, gkapp was added in 2020. Before gkapp, the frontend was built using Pyramid itself with JQuery and was called gkwebapp. The frontend migration from JQuery to Vue has not yet reached feature partiy with the previous gkwebapp, but has a lot of new features that were not in the old version. There can be potential issues due to these multiple rewrites with multiple people working on partially documented codebase over an extended period of time as mentioned here. While many of the issues were fixed in the past year, there could still be some overlooked issues. Following are some of the known limitations of the GNUKhata project (gkcore and gkapp combined).
To know more about GNUKhata, see here.
Known Limitations
API Schema documentation (swagger)
API Schema documentation is incomplete/incorrect for some of the APIs. This is because the available/acceptable fields for some APIs are hard to identify. This will be fixed in the upcoming backend upgrade.
Uknown APIs
There are some unused, unknown, zombie APIs that were lost in the frontend migration. This happened mainly because of the lack of API documentation.
Validation
Schema-based validation is only available for a few of the APIs. Rest of them are still being worked on. Validation for important APIs like the one for invoices can be added only after the backend upgrade. This should not affect the working of gkcore with gkapp, where gkapp will be doing the validation first.
User roles
Role based user management is not documented. Features available for users other than admin are not documented properly or tested enough.
User management
Uses in-house user management module. Features are limited.
Export/Import
Currently GNUKhata backup can be exported as JSON and imported to another instance of the same version of GNUKhata. XLSX import is not extensively tested and is still a work in progress.
Multi-currency support
Since the development was done with an Indian Buisiness perspective, Rupee and Rupee symbol are hard-coded in some APIs and some frontend components. For multi-currency support to be added, these hard-coded strings have to be replaced with variables.
International support
Different countries may have their own accounting standards and may be different in their tax structure. GNUKhata was developed with an “India first” approach and most of the development was focused on GST implementation. This along with the lack of multi-currency support will make it difficult for GNUKhata to be usable in the cotext of other countries.
Translation and multi-language support
Multi language support is not added to the frontend (gkapp). This will be implemented only after upgrading frontend.
Accessibility
GNUKhata was initially envisioned to be able to usable for the visually impaired. The current version does not support that yet.
Shortcuts
As a browser-based application, GNUKhata doesn’t have the keyboard shortcuts that other accounting apps like Tally has.
Disabled modules
There are modules in GNUKhata (like budget, transfer notes, etc.) which were already implemented but disabled due to bugs that could not be fixed before the release deadline.
GST
GNUKhata has GST support and can generate GSTR1 statement that can handle invoices and debit/credit notes, but it doesn’t cover any other reports. GSTR-1 is being actively tested, please double check the data to be uploaded before filing return. The software does not currently support online functions such as “E-way Billing”, “E-invoicing”, “IMS Dashboard”, “GST-2A/GSTR-2B Reconciliation”, or features such as Reverse Charge mechanism, Export invoices, Composition supply, Other charges (Like insurance, freight) on invoice, (Nil rated/Exempted/Non Gst) Inventory classification, Tax on advance receipts, adjustment of such advances, import GST ITC and some other advanced GST features.
Dependency status
In gkcore, SQLAlchemy has not been updated to the latest stable version. A lot has changed between the currently used version (1.3) and the latest version (2.0). SQLAlchemy upgrade will require extensive rewrites.
Pagination
Currently supports only frontend pagination. This will affect performance with large number of invoices.
Performance
Due to how database tables and APIs are structured, the performance of the application will be affected for queries that handle large volume of data.
Security
SQL injection issues are fixed. But security audit for code is not done. It is recommeded to use GNUKhata in a private environment.
Testing
Gkapp has Playwright based end-to-end testing with partial test coverage. GNUKhata previously had frontend and API tests which are outdated now.
Packaging and installation
Currently GNUKhata is being distributed as Docker images. This will affect the ease of installation and updation for non-technical users. Even though it is possible to install GNUKhata in Windows, but it is not tested well.
Maintainability
The currenct frontend and backend architecture are not maintenance-friendly. A lot of undocumented legacy code are copy pasted at multiple places making it more difficult to fix. A rewrite with architecture change will be required to make it more maintainable and understandable.