Navigate to Issue Tracking page in the above menu: Support > Issue Tracking
Then use the “Report an Issue” button and select “Bug”

1) Questions before starting:

• Is this really a bug?
  - If you are not sure how certain functionality works, then search in University Training Materials or in hansamanuals.com first.
• Is it already reported?
  - Search if a colleague of yours have reported it already.
• Have you tested on latest version?
  - Use latest development version when testing the issue.
• Is it repeatable in UK sample data?
  - Yes - mention that in report, or attach backup if specific setup steps are added to that sample
  - No - report it anyway and send the bug subject chat local to Product manager or Dev Manager, and work together on how to repeat it to be able to move it further to a programmer to get it fixed.

2) Bug title:

The title of the bug report needs to be short, but specific enough to explain the issue.
Platform, Product, Module Code prefixes are used for issues affecting only the specific Platform, Product, or Module.
The title format is: Prefixes>>Short Description
Goal is to understand the problem from just reading the title and use that title in further communication and it's lifecycle.

Guidelines for adding prefixes in bug subject:

• - Platform – operating system: Win, OSX, iOS, Android.
• - Product (Standard Accounts, Standard POS etc.) – specified only if the bug is product-specific and is not repeatable in Standard ERP.
• - Module code (NL, QT, SO, SL, PO, PL, IN, TC, SY, POS, REST, RENT, etc.). - specified only if the bug is in a specific module. These can be found in the modules menu section in translation file haengm.hal
• - CRASH / Data Corruption - use these prefixes when applicable as first ones to highlight the importance of the bug
• - Pixel - use this prefixe for user interface bugs
• - Function (Report, Maintenance, Export, Import, Document) - use this prefix to point to a specific function if applicable, and always pair it together with the exact function name (e.g. Report>>Item List)
• - Name of the function (e.g. Balance Sheet, Invoices, Recalculate Prices).
  
  Examples of bug report titles:
  
  • CRASH>>WIN>>TC>>Recompile HAL files maintenance crashes server
  • 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>>Export>>Not possible to export
  
  

  3) Tags:

  OS/Platform	Specified only if the bug is OS-specific
  Product	Specified only if the bug is product-specific and is not repeatable in Standard ERP
  Module	Specify the module where the bug is repeatable
  Function	Specify the type of function that has a bug
  Specific	Crash, Data-Corruption, Print and Pixel bugs all need to be marked with a tag here
  Int. Server	In case of the bug report about MyStandard, StandardID or other Hansaworld’s cloud services
  Country	Specify if a bug is country specific

  ⚠ At least one tag should be provided as it helps segmenting the issues for product managers.
  
  

  4) Description:

  Layout of the description of the bug is split in 4-5 logical separated sections:
  • - Environment
  • - Steps
  • - Bug
  • - Expected
  • - Additional Info
  
  
  • Environment (header for this section is not needed)
    - Version number and date where tested/repeated the bug (must be in format: StandardERP 2023-12-03 b3040)
    - Mention if Platform/Product/Country/Languages specific issue (Example: Win only, Win 32-bit only, ”x language” only, SACC only, etc.)
    - Specify if only repeatable in a server/client environment
    - For mobile devices might be important to provide device brand and model and screen size
  
  
  • Steps:
    - Keep short, but include all the important details
    - Explain setup settings, including where to take data (if relevant) – import UK Sample data or attached text backup (avoid passwords, customer text backups are not allowed, write which country's sample data)
    - Exact steps how to repeat the problem
    ⚠ If number calculations are wrong then use simple numbers in bug report example (when possible).
    ⚠ Steps should be in a numbered list.
  
  
  • Bug:
    Explain the bug.
    Example: Shows Error "Full Payment Required" and does not OK the record.
  
  
  • Expected:
    Explain the expected outcome.
    Example: No Error messages and OK the record.
  
  
  • Additional Info:
    If you have managed to investigate the issue further and think this might help fixing the issue, then add additional information here
  
  ⚠ 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 exact full error message in the bug report as text (don't attach it as a screenshot).
  
  

  5) Attachments:

  Backups
  - 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.
  - Do not attach customer data backup.
  ⚠ It is important that a backup data should always be provided to repeat the issue!
  
  Screenshots
  - Screenshots should always be attached when reporting bugs that are related to user interface design, pixel problems or wrongly displayed special characters.
  If possible attach a screenshots of both the bug and the expected result, and name the files accordingly.
  - 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.
  - If the issue might require a "screengrab" (recorded desktop video) to demonstrate the problem, then keep the file size to minimum and record only the issue itself.