Oketz Systems: How to Get Data Out When Nothing Is Documented

Oketz Systems supplies time clocks, access control hardware, the Adam attendance software and the Trio payroll program, and it publishes no API, database schema or file layout. Extracting data therefore starts with a question of physical location - where the data actually sits - and ends with a written agreement about a file, not with a developer portal.

What Oketz actually sells, and why that changes where the data lives

The public product list spans two worlds. On the hardware side: attendance clocks, access-control controllers, proximity readers, barcode and fingerprint readers, and employee cards. On the software side: Adam attendance products including a project variant, Trio payroll with versions aimed at kibbutzim, subcontractors and the food industry, an ERM human-resources module, cafeteria management, and payslip printing as a service.

This matters because a hardware-anchored vendor is frequently installed on-premise, and an on-premise installation changes the entire extraction conversation:

• If the database runs on a server in your building, the access question is administrative, not technical - who authorises a read-only account.
• If the clocks poll a local controller, the raw event stream exists somewhere on your own network before it ever reaches the attendance software.
• If a hosted or bureau arrangement is in place, none of that applies and you are back to files.
• If payslip printing is outsourced to the vendor, the finished payroll output already leaves the building in some format, and that format is worth asking about.

Nobody can answer these from a website. They are questions for the person who installed the system.

What do you do when the vendor publishes no specification?

You stop looking for a specification and start defining one, together with the vendor, as a deliverable. The sequence that works:

• Inventory the physical layout. Which application, which server, on-premise or hosted, which database engine, who administers it, and whether the maintenance contract permits third-party read access.
• Name the exact output you need, in business terms - hours per employee per day with a project code, or gross-to-net per employee per month - before anyone discusses format.
• Ask for a sample of every route the product already has. Existing report exports are free; a new interface is not. A vendor asked for "an interface" quotes a project. A vendor asked "which of your existing reports contains these five fields" often answers in a day.
• Turn the sample into a written layout - column order, types, encoding, decimal and date conventions, what an empty value looks like - and have the vendor confirm it as the agreed definition.
• Agree the operational terms: delivery mechanism, schedule, retention, who is notified on failure, and the notice period for a change.

The output is a one-page interface agreement. It is not glamorous, and it is the difference between a pipeline that runs for five years and one that breaks the first time the vendor updates the software. The broader argument for treating a supplier's missing API as a solvable problem rather than a blocker is in safe alternatives when a supplier has no API.

The five routes, compared

The third row is where most organisations start and where most of them stay, because it costs nothing to begin. It is also the row that generates the annual conversation about why last month's numbers do not match.

Reading the clocks instead of the software - when is that the right call?

Rarely, and only for a specific class of need. Clock hardware holds raw entry and exit events. It does not hold work agreements, rounding rules, overtime tiers, absence codes or approvals, and those are precisely what turns an event into a payroll quantity.

Going to the hardware is defensible when:

• You need presence data for something that is not payroll - site safety, headcount in a building, access auditing.
• You need it in near real time, and the attendance software only closes periodically.
• The attendance software is a black box you cannot get an export from, and the raw stream is genuinely reachable.

It is the wrong call when the answer has to agree with the payslip. Oketz's own description of the flow is instructive here: the data is collected and processed, then goes to the department manager for approval, and only after final approval moves on for processing. Anything read before that approval point is a different number from the one payroll will use, and rebuilding the approval logic outside the system is how two systems of record get created by accident.

The agreement that makes a file interface survive

A file interface fails for organisational reasons far more often than technical ones. Five clauses prevent most of it:

• A version stamp inside the file or in its name. Without it, nobody can prove which layout produced last March's data.
• A named owner on each side, as a role and not a person, so a resignation does not orphan the interface.
• A change notice period, with the explicit rule that a new column is appended at the end and never inserted in the middle.
• A failure signal. A run that produces no file must raise something; silence is the most expensive failure mode there is. The general pattern is in monitoring silent failures in automation flows.
• A monthly reconciliation of one total - hours or headcount - between source and destination, run automatically and reported whether or not it matches.

Payroll and attendance files carry salary and identity data, so the transport and the recipient list are part of the design. Keep the number of copies small and the list of people who can open them shorter.

Sources

• Oketz Systems - attendance reporting
• Oketz Systems - home
• Interface to payroll software - JB Clock