Skip to Content
TroubleshootingHours import fails

Why won’t the hours import go through?

You tried to import an hours sheet under Custom layout, and the app refused at the column-mapping step. All three messages below happen because the sheet’s layout doesn’t tell the app enough about what a row or a code means, so it asks again rather than guess and record a day wrong.

What the screen says

The sheet isn’t laid out as daily rows

Importing into daily entries needs a sheet with one row per day, a date column and a work-type column. Go back to the mapping step, set “Row granularity” to one row per day, then pick both columns under “Daily layout options”.

This happens when the sheet carries monthly totals per employee (one row per month), but you tried to import into daily entries, which need one row per day.

The code legend is missing

Importing into daily entries needs a work-type code legend: each code in your sheet must say whether that day is worked hours or an absence. Add one row per code under “Daily layout options”.

The app recognizes known codes automatically (for example from a Minimax export), but for any other code it needs to know what it means before it can import it.

Choosing which periods to import isn’t possible

Choosing which periods to import needs a sheet with one row per day and a date column. Go back to the mapping step and set “Row granularity” to one row per day and pick the date column, or import the whole file.

This appears when you try to import only selected periods (for example just the current month) from a sheet that isn’t laid out as daily rows.

Without one date per row, the app can’t tell which part of the file belongs to which period. Choosing periods out of a monthly sheet is therefore not possible by any route: either lay the sheet out as daily rows, or import the whole file.

Why this happens

Hours-import sheets come in two shapes: one row per employee for the whole month, or one row per employee for each day. The app can’t reliably infer which one it’s looking at from the data alone, and it can’t tell on its own whether a code in your sheet (for example for vacation or sick leave) means worked time or an absence. Guessing wrong would mean a sick day gets counted as worked time or the other way around, so the app asks at the column-mapping step instead.

What to do

  1. Open Payroll → Data import → Import Hours.
  2. Select the Custom layout tab.
  3. On the Map columns step, under Row granularity, choose One row per day (daily) if your sheet carries one day per row.
  4. Under Daily layout options, pick the date column and the work-type code column.
  5. Under Code legend, add one row for each code in your sheet and mark whether it means worked hours or an absence.
  6. If you want to import only selected periods rather than the whole file, row granularity and the date column both need to be set as in steps 3 and 4; otherwise choose to import the whole file.
  7. Retry the import.

If your file has a note column

If the file carries a note column (for example “Opomba” or “Comment”), every row whose note is not empty is shown on the column-mapping step under Notes the import will not act on. The note’s text is carried onto the daily or monthly entry exactly as written, but the import never infers an absence or a working-day change from it. A note reading “4 hours sick leave” does not create a half-day sick absence on its own. Review those rows and make any needed change by hand, on the absence calendar or the affected cell.

If you can’t fix this yourself

Anyone with edit access to hours and absences in the Payroll module can run the hours import. If the app won’t let you import, your organization’s administrator needs to grant you that access.

If your sheet’s layout doesn’t match either shape above (for example an export from a system that writes neither monthly nor daily rows per employee), contact support and attach a sample of the file with no employee personal data.

Last updated on