What is the template for reporting an issue ▾
The subject of the bug report needs to be in the following format:
Guidelines for creating the correct subject line are:
• Platform – operating system (Win, OSX, iOS, Android). NB! This needs to be specified only if the bug is
• Product (Standard Accounts, Standard POS, Standard ERP etc) – only needs to be specified if the bug is product-specific
and is not repeatable in Enterprise.
• Module code (NL, SL, TS, IN, PL, SY etc) - these can be found in the modules menu section in translation file haengm.hal
• Function (Register, Report, Maintenance, Export, Import, Document).
• Name of the function (e.g. Balance Sheet, Invoices, Forms, Recalculate Prices).
• Short description of the problem.
Examples of bug report subjects:
• SY>>Register>>Forms>>Form of Invoice>>Field GP not recalculated
• SL>>Report>>Item List>>Item group column header missing
• DI>>Maintenance>>Delete Price Lists>>doesn't take specified price list into account
• Win>>Standard Accounts>>Routines>>Export>>not possible to export
What if a bug is not related to a particular module ?
In these cases, replace the Module Code in the subject with one of the following:
• PRINT - problems concerning printing (printing lines, image problems etc).
• GENERAL - any other non-module-specific problems, including master control and navigation
• CBS – Cloud Based Services bugs (e-invoicing, e-banking, currency exchange services etc)
• Translation System – bugs related to translation system functionality
• HAL - bugs related to HAL code
• Market Place - For Market Place related bugs
Other special cases:
• Country specific bugs
Use the country code in the subject of bug reports that are country specific. Sample:
RUS>>Standard Accounts>>General>>Welcome banner>>How to get started>>Wrong link
• Data Corruption bugs
Add code DC (Data Corruption) to bugs that are harmful to the data, for example when a wrong NL transaction is created
from an invoice or stock record. Sample: DC>>SL>>Invoice>>wrong NL transaction when prepayments are used
• Crash bugs
Add word Crash to bugs that cause the client or server program to shut down unexpectedly.
Layout of the body of the bug report:
1. first line: version number and date (Must be e.g.: 8.2 2016-11-14)
2. second line: platform repeated (samples: Win, Win only, Win 32-bit only,”x language” only (if relevant))/product.
3. third line: specify if only repeatable in a server/client environment
4. fourth line: [blank]
5. fifth line: explain setup settings, including where to take data (if relevant) – import UK Sample data or text backup
(avoid passwords, customer text backups are not allowed.
6. next lines: steps how to repeat the problem
7. next lines: define what is the problem->bug situation
8. next lines: define:
• actual situation - occurring if bug is not fixed
• expected situation – occurring if bug is fixed
The text lines should be as short and yet as detailed as possible in order to enable easy verification of the bug.
If the bug report contains an error message, write the full error message in the bug report as text (don't attach it as a screenshot).
Attach a backup when the problem can be repeated or explain how to repeat the problem in UK Sample data.
If attaching a text backup, set up the data in a way that makes it easy to repeat the problem (with as few steps as possible).
Choose easy numbers when reporting calculation issues.
Do not attach a backup, when the issue is not repeatable and then specify in the bug report on what needs to be
changed to be able to repeat it.
It is important that a backup should always be set up to repeat the issue!
Screenshots should only be attached when reporting bugs that are related to user interface design, pixel problems or wrongly displayed special characters.
Screenshots should never be used for calculation problems. If the issue is related to a calculation problem, the issue should be repeated in the demo data and attached as a text backup.