Reporting problems
Czynności sprawdzające przed zgłoszeniem, sposób opisania sprawy umożliwiający obsługę bez dopytywania oraz różnica między usterką a zachowaniem zamierzonym.
First, three quick checks
Before you write a report, go through three things. They resolve most matters in a minute and need no one's help.
- Are you in the right company? If you work across several companies, a missing document is usually in the other.
- Did you refresh the screen? If someone changed a record a moment ago, the displayed form may show an older state.
- Is it about permissions? An area you do not see may not be available to the given role. This is not a fault, but the access scope.
If none of these three explains the matter, report it. Do not try to fix things by working around the system.
Do not work around a problem on your own. Creating a second record "because the first got stuck", or entering data in someone else's field, later breaks far more than the original problem. Report it and wait for an answer.
Describing the reported matter
A good report contains four things and fits in a few sentences.
- What you were doing. A specific action, for example "I was approving an invoice", not "I was working in the system".
- What you expected. What was supposed to happen.
- What happened instead. Preferably with the text of the message, if one appeared.
- Where. The number or name of the record, the company, the date and time.
The record number is the most important. With it the administrator checks the history and the run in a few minutes; without it they start by looking for which document it is.
Example. Instead of "invoices do not work", write: "Today around 10:15 in the Trade company I was approving invoice FV/2026/0087. I expected it to move to approval, but the document stayed at the preparation stage and there was no message". This report can be handled right away.
Behaviors confused with a fault
Four behaviors that look like an error but are intended.
| Symptom | The actual cause |
|---|---|
| I do not see an area a colleague mentions | a different access scope or a different company |
| A field is locked | the record is at a stage where it is not changed |
| A change did not save | validation rejected the save; the message is usually above the field |
| A record changed without my involvement | a rule or an integration acted; you can see it in the history |
For each of these, look into the record's history first. It answers the question of who did what, faster than working out the cause yourself.
A screenshot helps, but does not replace a description
A screenshot with an error message is very helpful. A screenshot alone, without a description, is not: it does not show what you were trying to do or what you expected.
If you take a screenshot, capture the whole screen together with the address bar, not just the snippet with the message. The rest of the screen tells the administrator where you were.
Urgent matters
When a problem blocks the whole team's work or concerns a document with a deadline, write it outright in the first sentence of the report. "It blocks issuing today's invoices" is information that changes the order of handling, and the administrator will not guess it from the symptom description alone.
Related
Change history describes the record of who changed a record and when. Roles and permissions describe why you do not see some areas. Working across companies describes the company context. My tasks describe the matters awaiting the user.
Changes in the system
Dlaczego zmiany w systemie pojawiają się nagle i w całości, czemu czasem trzeba odświeżyć ekran i co zrobić, gdy nowa wersja działa niezgodnie z oczekiwaniem.
Overview
Use the Opero API to connect systems with selected Opero resources. Authenticate requests with an Opero API token.