Kintai

The starting point of attendance is people, contracts, and assignments.

Even if the check-in time is the same, if the scheduled shift, contract, or workplace differs, the content to be verified will also change. Therefore, in attendance management, it is necessary to organize who is working where under what conditions before recording the time.

Kintai handles employee records, employment contracts, placement and transfer history, and shifts. It separates roles such as employee operations, store manager confirmation, and head office HR management, connecting employee information with daily work records.

Rather than a single check-in screen,A foundation for attendance and HR that handles both personal information and working time together.It is designed as such. The HR information and login accounts are not treated as the same entity, but are managed in a connected manner.

The information is lost when a day is summarized in one line.

For example, consider a day where work is divided into day and night shifts. Simply treating the entire period from the first check-in to the last check-out as one interval would not clarify which time periods were worked, where breaks were taken, or which shifts require confirmation.

Kintai adopts a structure where each day's attendance has intervals per shift. It handles work performance, warnings, and approval status per interval, connecting them to daily summaries. Overtime work and work outside scheduled shifts are also subject to summary and verification.

By dividing the management units in this way, you can prepare information to confirm which work sections require response, rather than making judgments based only on daily totals. Note that the work examples shown here are for explanation of the design and are not actual employee data.

Making missed check-ins and corrections part of an approved process.

In the field, it is common to forget to clock in or need to correct records. If managers simply change the numbers, it becomes difficult to understand what was requested by the employee and in what state it was accepted.

In Kintai, there is a process for employees to submit correction requests and for their verification and approval. The application handles the target work records and the reasons, and also confirms whether the records are from the employee themselves. It is structured so that work records are not immediately changed by the application, but rather proceed to processing after approval.

There are different constraints for closed periods and duplicate applications compared to regular unprocessed data. It is important to handle not only whether the input is possible, but also whether the operation is acceptable in the current state, in order to connect daily attendance and monthly business operations.

Connecting store verification and headquarters closing.

Monthly closing is not just a process of selecting the target month on the screen and summarizing. There is a flow where the content is confirmed at the store, submitted to the head office, and, if necessary, returned. If corrections are needed after confirmation, a resumption procedure is also required.

Kintai handles the closing of individual employee records at the store level and the submission and approval to the head office. Depending on the settings, some organizations may have a process where the store confirms the records, and not all organizations have a fixed approval process. Applications for resuming after confirmation and their approval are treated as separate states.

In implementation, we check the status of the target before processing and consider situations where operations on the same record overlap. This state management may be less visible to users, but it forms the foundation for passing confirmed work data to the next business process.

Handling of store terminals and when communication is unstable.

There are two entry points for clocking in: the employee's web screen and the store tablet. The store terminal is registered and connected as a device, and handles records such as attendance, breaks, and outings. The operational premises differ between screens used by individuals and shared terminals used by multiple employees.

The store tablet has a mechanism to keep the clock-in records on the device during periods of no communication and synchronize them after the connection is restored. However, just because records were made during the communication outage does not mean all times are automatically confirmed. It handles cases where records obtained offline need verification of the time and human confirmation.

This is not a guarantee that it will never stop completely, but rather a design that considers how to continue recording and verifying in field environments where communication conditions change. It includes checking the operation during implementation, including the usage terminals and settings.

Data passed to payroll processing and the product's scope of responsibility.

Working hours are organized, including categories such as regular hours, overtime, night shifts, and holidays. Furthermore, related tasks such as shift changes, overtime applications, absences, and the granting, usage, and balance of paid leave are also involved in verifying work records.

Kintai has an API for monthly output and reading work data, and it has a connection point to pass data to subsequent processes such as payroll processing. However, it does not mean that all processes from payroll calculation to transfer and tax declaration are completed within the same product.

When developing, we consider collecting data, confirming and finalizing it, and passing it to the next system separately. Determining where Kintai takes responsibility and where existing systems or personnel take responsibility is also part of the design of the business system.