Skip to main content

Testing codeto report

This page guides you through a structured first test run of codeto report. Goal: map realistic workflows, understand roles and approval levels, check whether the recorded data is sufficient for the payroll export.

Recommendation

Read the page through once before starting the data preparation. Some decisions (approval structure, roles, scope of the test week) influence the Excel template and therefore the import.

1. Basic concept: report

A report is a single entry in codeto report. It can cover 15 minutes or 8 hours, but never spans more than one day.

2. Questions at the start

Before starting, clarify the most important points:

  • Which people and which week should be covered in the test?
  • Which approval levels do you want to test? Typical chains:
    • Employees, Managing director
    • Employees, Project manager, Managing director
    • Employees, Project manager, Office, Managing director
  • Which people take on which role in the approval structure?
  • Which additions / supplements are tied to employees, which to projects? Typical examples:
    • Saturday supplement: tied to a project, only triggered by a project booking on a Saturday.
    • On-call lump sum: tied to the employee, also paid out when there is no booking on a project.
  • Are there part-time patterns or different target hours that need to be mapped?
  • GAV or your own supplement rules?

3. Defining the approval structure

codeto report supports four approval levels. Each level is currently filled by a single person, multiple assignment is not possible. For absences, substitutes can be defined.

LevelDesignationTypicalAssignment
1Project manager checkLead site fitterVia Excel template per project (submit to the codeto team).
2Project managerProject managerVia Excel template per project.
3Supervisor checkOfficeDefine and edit directly in codeto report.
4SupervisorManagement / supervisorsDefine and edit directly in codeto report.
Important to know
  • Absences always go directly to the supervisor check level and skip the project managers.
  • Fewer levels can be used as well, e.g. only one (Employees, Supervisors).
  • The approval structure determines the order in which a closed week or individual days run.

4. Defining roles and test users

Define which roles are involved in the test:

  • Service fitters
  • Project employees
  • Project manager check
  • Project managers
  • Supervisor check
  • Supervisors
Minimum

Not all roles need to be filled. For a working test, one employee (service fitter or project employee) and one supervisor who checks and approves the reports are sufficient.

5. Preparing test data

Once all points are clarified, the data preparation follows:

  1. Fill in the Excel template completely, based on the defined roles and scenarios.
  2. Submit the template to the codeto team.

6. Setting up the environment (with the codeto team)

The following points are set up by codeto in the test environment. You provide the information, the codeto team handles the configuration. Without specific input, codeto uses default values:

  • Default working hours of the company
  • People with different target hours (part-time, special patterns)
  • Enter public holidays
  • Additions / supplements, project-related (e.g. Saturday supplement)
  • Additions / supplements, employee-related (e.g. on-call lump sum)
  • Default absences and any special absence types

Once everything is set up, you receive an email from us with all the links to the test environments. With it:

  • Install the Mobile App on the phone (see info box below).
  • Inform additional test users and pass on access.
Short call recommended

From experience, the test result is significantly better if we have a short call at the start and go through the test environment together. Just get in touch, we will organise it.

App access for test users
  • Android: Send the email address of the test users to the codeto team, release happens via Google Play.
  • iOS: Access via Testflight, the invitation link comes from the codeto team.

7. Recreating a realistic week

Build the test week as realistically as possible:

  • Service fitters: a week with many different bookings per day.
  • Project employees: a week on one or two projects.
Test both access points

Record reports both from the Mobile App and from the Web App. This shows whether both ways work for the employees in everyday use.

8. Targeted testing of special cases

So that no surprises arise in productive operation, it is worth deliberately covering the exceptional cases:

  • Variable additions / employee-related additions, e.g. on-call lump sum.
  • Daily allowances: who receives them, and do they apply on all projects or only on certain ones?
  • Expenses: tied to a single report and therefore project-related.

9. Checking reports in the test

This step is central. Here it shows whether the data is transferred and displayed in such a way that the check really works in everyday use. Take the time for it deliberately.

First check how the reports should be checked: per employee (entire week) or per project?

ProcedureRecommended view
Check per employee / entire weekEmployee view or week view
Project-related checkProject view

Checklist during the check

  • Are all needed information directly visible (hours, projects, additions, expenses, absences)?
  • Can the check route be carried out understandably and efficiently?
  • Does the view match the workflow that supervisors / the office need in everyday use?
  • Are there cases (e.g. variable additions, daily allowances) where the data is not immediately clear?

If something is missing or unclear, involve the codeto team before productive operation begins. The check view can usually be adjusted.

10. Further processing of the data

At the end of the test, the focus is on what happens to the data after approval: payroll, billing and evaluations. Two paths:

  • With export interface: The data flows automatically into the payroll or ERP system. This check cannot be inspected from the outside, so go through it together with the codeto team.
  • Without export interface: Check the extracts and the information per employee and see whether the values are correct and sufficient for payroll and billing.
Support

In case of uncertainties, involve the codeto team at any time to define the best check and export strategy for your operation.