> For the complete documentation index, see [llms.txt](https://kb.logicerp.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.logicerp.com/logic-erp-learning-hub-tutorials-and-best-practices/payroll/payroll-entry/attendance-app-hr-review.md). # Attendance App HR Review **Available on:** Desktop · Web · Phone Navigate to **Payroll Entry** and click on "Attendance App HR Review". **Attendance App HR Review** collects everything from the attendance app that needs a person to decide, in four lists. Use it daily. ## The top bar * **Branch** — the branches your user may see; **ALL MY BRANCHES** shows them all. Changing it refreshes the lists. * **Date From** / **To** — the days **Punches Left for HR** and **Auto-absent Days** cover (the last 7 days to start). The other two lists are not limited by date. * **Refresh** reads the lists again. ## Working through a list * Tick the rows in **Select** (or **Tick / Untick All**), then press the action. The screen asks first, does each row, and lists any row that did not go through and why (the first 10, then how many more). * Remarks are typed in the **Remarks** column of each row. To give several rows the same remark, type it in one row, stay on that row, tick the others and press **Copy Remarks** — it replaces any remark they had. ## The four lists | List | What it lists | What HR does | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Punches Left for HR** | Days where the app's IN and OUT could not be written — because someone had already entered or changed the day by hand, its payroll is processed, or the import failed. Shows the app's times, what the day holds now, and why. | **Use App Punches** replaces the day with the app's IN and OUT (not when payroll is processed, and only when the app has both an IN and an OUT). **Mark Resolved** when you have fixed the day yourself in the Attendance Register — it leaves the list. | | **Flagged Punches** | Punches made away from the branch's sites (for users set to FLAG FOR MANAGER) or with a faked location, waiting for a decision. | **Accept** keeps the punch. **Reject** removes it and rebuilds the day from the punches left — unless the day was entered by hand, which is left as it is and moves to Punches Left for HR. | | **Auto-absent Days** | Days that Auto Absent marked absent and that are still absent. | Pick a **New Status** (present, a leave, half day…) for each day to change, then **Save Status**. A leave is checked against the employee's balance and leave rules, as in the Attendance Register. The app then leaves that day alone. | | **Requests Waiting for HR** | Leave, missed-punch, short-leave, profile-change and comp-off requests whose current approval level is HR. A comp-off shows as **COMP-OFF** with the days and the hours worked, for example *1 DAY(S), WORKED 9:00 AM - 6:00 PM (9 h)*; a cancellation as **CANCEL COMP-OFF**. | **Approve** or **Reject Request**. Rejecting needs a remark on every ticked row — the employee sees it. When HR is not the last level, approving sends the request to the next level. A leave is checked against the leave rules again when it is finally approved; if it fails, the request is refused and the reason is listed. | On the web the four lists are a switch with short names: **Left for HR**, **Flagged**, **Auto-absent**, **Requests**. > **Example —** On Monday morning **Flagged Punches** shows two punches by Deepak, made 600 m from the store on Saturday. His manager confirms he was at a customer's site. HR ticks both rows, types *At customer site, confirmed by manager* in one Remarks cell, presses **Copy Remarks**, then **Accept**. Every action is recorded in the [Change Log Viewer](/logic-erp-learning-hub-tutorials-and-best-practices/user-access/change-log-viewer.md) with the user who did it — as an HR Attendance Fix, an App Punch Review or a Request Approval. The screen warns before closing when a New Status has been picked but not saved. ## Messages you may see | Message | Why | What to do | | --------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Tick at least one … first. | An action was pressed with no row ticked | Tick the rows in Select, then press it again | | Enter the reason in REMARKS for each ticked request (the employee sees it); Copy Remarks copies one to all ticked rows: … | **Reject Request** with a ticked row that has no remark | Type the reason; **Copy Remarks** gives it to all ticked rows | | Type the remark in the REMARKS cell of a row first, stay on that row, then press Copy Remarks. | The row you are on has no remark to copy | Type it in that row, stay on the row, press **Copy Remarks** | | Tick the rows (SELECT) the remark should go to first. | **Copy Remarks** with no row ticked | Tick the rows | | …: payroll is processed for this day; it cannot be replaced. | **Use App Punches** on a day whose payroll is processed | Leave the day as it is and **Mark Resolved** | | …: the app has no IN and OUT for this day. | Only one of the two punches reached the app | Fix the day in the Attendance Register and **Mark Resolved**, or wait for the employee's missed-punch request | | …: payroll is processed for this day. | **Save Status** on a day whose payroll is processed | Leave it | | …: choose the new status. | **Save Status** on a ticked day with no New Status | Pick the status | | …: the day was changed since it was listed; refresh the list. | Someone changed the absent day after the list was loaded | **Refresh** | | Changing … failed: … | **Save Status**: the new status was refused — for example not enough leave | Pick another status, or ask the employee to apply in the app | | This request is not waiting for HR now. / This request is no longer waiting for approval. / This punch is not waiting for review. | It was moved on or decided while the list was open | **Refresh** | | Enter Date From as dd/mm/yyyy. / Enter Date To as dd/mm/yyyy. / Date To cannot be before Date From. | The dates are wrong | Correct them | | … auto-absent day(s) have a New Status not saved yet. Close without saving? | Closing with New Status picks not saved | **No** goes back so you can **Save Status** | | Modification rights are not available... | Any action button: your user may only view this menu | Ask for modify rights in User Access | ## On the web The same screen is on the web. The four lists are a switch on a phone and on a desktop. On a phone, Branch, the dates and Refresh fold behind **Branch and dates**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://kb.logicerp.com/logic-erp-learning-hub-tutorials-and-best-practices/payroll/payroll-entry/attendance-app-hr-review.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.