Earned Wage Engine은 이미 일한 임금을 어떻게 계산하는가?

Earned Wage Engine은 승인된 근무일을 해당 급여 기간에 수령할 수 있는 기발생 임금으로 전환하는 계산 계층입니다. 단순히 근무일수에 일급을 곱하는 것이 아니라 정확한 근로자, 근무지와 기간을 확인하고, 이미 받은 금액을 차감하며, 기업 규정에 따른 유보액을 적용한 뒤 결과를 반환해야 합니다.

Earned Wage Engine의 실제 역할은 무엇인가?

EWA 시스템에서 근로자용 화면은 결과를 표시하는 곳일 뿐입니다. 더 중요한 작업은 서버에서 이루어집니다. 엔진은 권위 있는 데이터를 모으고 근로자가 금액을 조회하거나 신청할 때 다시 계산해야 합니다.

엔진의 핵심 역할은 설명 가능한 숫자를 만드는 것입니다. 오늘의 금액이 어제와 다르다면 시스템은 그 변화를 근무 데이터, 적용 단가, 기수령액 또는 유보 규칙까지 추적할 수 있어야 합니다.

엔진은 휴대전화나 브라우저가 전송한 숫자를 그대로 신뢰해서도 안 됩니다. 사용자 기기에 오래된 데이터가 남아 있을 수 있기 때문입니다. 거래를 만들기 전에 서버는 현재 데이터로 다시 계산해야 합니다.

기본 공식은 어떤 구성 요소로 이루어지는가?

Nhan Kiet의 기발생 임금 접근 서비스는 다음 원칙으로 계산합니다.

수령 가능 금액 = (승인된 근무일수 × 일급) − 해당 기간 기수령액 − 기업 규정에 따른 유보액.

구성 요소	데이터 출처	역할
승인된 근무일	인정된 근무 기록 출처	이미 형성된 노동 가치를 확인
일급	유효한 급여 데이터 또는 정책	근무를 금전 가치로 환산
기간 내 기수령액	확인된 거래 원장	동일한 가치를 다시 사용하는 것을 방지
유보액	기업 정책	기간 말 조정을 위한 여유 확보
급여 기간	급여 시스템	가산, 차감 및 정산 범위를 제한

엔진은 새 데이터를 스스로 만들지 않습니다. 원천 시스템이 확인한 데이터만으로 계산합니다.

근무 기록이 승인 대기 상태라면 아직 계산에 포함해서는 안 됩니다. 거래 상태가 불명확한 경우에도 엔진은 이를 실패로 간주해 금액을 다시 열어서는 안 됩니다.

승인된 근무가 출발점인 이유는 무엇인가?

출퇴근 기록과 승인된 근무 기록은 서로 다른 상태입니다.

QR 스캔, GPS 기록, 근무표 데이터 또는 앱 기록은 출퇴근 데이터가 존재한다는 사실만 보여 줍니다. 이 데이터가 재무 입력값이 되기 전에 기업의 절차에 따른 확인 단계가 필요합니다.

관리해야 할 상황은 다음과 같습니다.

• 출근 또는 퇴근 시간이 누락된 경우
• 근무조가 잘못된 경우
• 자정을 넘기는 근무조
• 확인되지 않은 연장근무
• 반영되지 않은 휴가
• 중복 근무 기록
• 승인 후 수정된 근무 기록

기록 데이터 → 승인 데이터 → 임금 계산 자격 데이터를 명확히 구분하면 임시 기록이 너무 일찍 재무 가치로 바뀌는 것을 막을 수 있습니다.

엔진은 변경된 데이터를 어떻게 처리하는가?

신뢰할 수 있는 급여 시스템은 데이터가 바뀔 수 있다는 사실을 전제로 해야 합니다.

예를 들면 다음과 같습니다.

• 승인된 근무 기록이 수정됨
• 효력 발생 시점에 따라 단가가 변경됨
• 근로자가 근무지를 옮김
• 조사 후 거래가 대기에서 성공으로 변경됨

따라서 엔진은 각 계산을 데이터 버전과 계산 시점에 연결해야 합니다.

구성 요소가 바뀌면 최종 숫자를 직접 수정하는 대신 최신 원천 데이터에서 결과를 다시 계산해야 합니다.

재계산하고 결과를 설명하는 능력은 급여 무결성의 중요한 요소입니다.

엔진은 동일한 노동 가치의 재사용을 막아야 한다

중요한 위험 중 하나는 동일한 노동 가치가 여러 번 사용되는 것입니다.

예를 들어 근로자가 해당 기간에 기발생 임금 일부를 이미 받았지만 시스템이 다음 계산에서 이를 차감하지 않을 수 있습니다.

또 다른 사례는 성공한 거래에 연결된 근무일이 데이터 동기화 후 다시 더해지는 것입니다.

이를 방지하려면 엔진은 다음을 함께 살펴봐야 합니다.

• 승인된 근무일
• 총 기수령액
• 대기 중 거래
• 성공한 거래
• 이미 사용된 근무일 또는 가치
• 관련 급여 기간

기간 내 기수령액은 계산에서 차감해야 합니다. 거래에 사용된 근무일은 기간 말 급여 처리 시 어느 부분이 미리 지급되었는지 확인할 수 있도록 명확한 이력을 남겨야 합니다.

Earned Wage Engine과 Eligibility Engine은 어떻게 다른가?

두 계층은 서로 다른 질문에 답합니다.

Earned Wage Engine:
“현재 근무 데이터를 기준으로 이미 형성된 임금은 얼마인가?”

Eligibility Engine:
“현재 상황에서 이 사람이 서비스를 사용할 자격이 있으며 얼마까지 받을 수 있는가?”

Earned Wage Engine의 초점은 다음과 같습니다.

• 근무 기록
• 단가
• 급여 기간
• 기수령액
• 유보액

Eligibility Engine의 초점은 다음과 같습니다.

• 프로필 상태
• 고객사의 기능 활성화 여부
• 계좌 확인 여부
• 정책 조건
• 이용 한도
• 기타 통제

두 계층을 분리하면 자격 정책을 변경하더라도 이미 형성된 임금의 이력이 왜곡되지 않습니다.

거래 전에 서버에서 다시 계산해야 하는 이유는 무엇인가?

앱이 10시 정각에 1,000,000 VND를 표시한다고 가정해 보겠습니다.

10시 5분이 되면 다음 변화가 생길 수 있습니다.

• 근무일 하나가 수정됨
• 다른 거래가 방금 성공함
• 관련 정책이 변경됨

앱이 1,000,000 VND를 다시 보내고 서버가 그대로 믿으면 잘못된 지급 명령이 만들어질 수 있습니다.

따라서 지급 전에 서버는 다음 작업을 해야 합니다.

1. 최신 근무 기록을 다시 읽기
2. 승인 상태 확인
3. 최신 기수령액 조회
4. 유효한 정책 조회
5. 재계산
6. 신청 금액 검증
7. 그 후에만 거래 계층으로 전달

화면은 정보를 보여 주고 신청을 보내는 역할만 해야 하며 최종 금액을 결정하는 출처가 되어서는 안 됩니다.

엔진은 결과를 어떻게 설명해야 하는가?

좋은 결과는 숫자 하나로 끝나지 않습니다.

시스템은 다음을 설명할 수 있어야 합니다.

• 승인된 근무일수
• 적용된 단가
• 근무에 따른 총 가치
• 기간 내 총 기수령액
• 유보액
• 남은 수령 가능 금액
• 계산 대상 기간

금액이 변경되면 감사 추적 기록에서 어떤 구성 요소가 바뀌었는지 보여 줘야 합니다.

이는 다음 업무에 도움이 됩니다.

• 근로자 지원
• 이의 제기 처리
• 급여 대사
• 오류 조사
• 내부 감사

엔진이 0을 반환하거나 사용을 제한해야 하는 경우

다음과 같은 상황이 있을 수 있습니다.

• 승인된 근무일이 없음
• 기수령액이 자격 금액을 모두 소진함
• 중요한 데이터가 확인 대기 중임
• 근무 기록이 방금 수정되어 재승인되지 않음
• 근로자가 현재 열린 급여 기간에 속하지 않음
• 그 밖의 프로그램 조건을 충족하지 못함

결과가 0이라면 화면은 “0 VND”만 표시하지 말고 적절한 수준의 이유를 안내해야 합니다.

모니터링할 기술 및 운영 KPI

기업은 다음 지표를 추적할 수 있습니다.

• 완전히 설명 가능한 계산의 비율
• 근무 기록 수정으로 수령 가능 금액이 변경된 횟수
• 엔진과 급여 시스템 간 차이 건수
• 근무 기록이 중복 사용된 건수
• 거래 후 재계산 횟수
• 잘못된 기간으로 인한 예외 건수
• 수령 가능 금액 관련 이의 제기 건수
• 예외 처리 시간

좋은 엔진은 빠르게 실행되는 데 그치지 않고 정확하고 추적 가능한 결과를 만들어야 합니다.

결론

Earned Wage Engine은 승인된 근무 데이터를 설명 가능하고 추적 가능한 재무 결과로 전환하는 계층입니다. 정확한 원천 데이터를 사용하고, 기수령액을 차감하며, 유보액을 적용하고, 데이터 변경 시 다시 계산하며, 동일한 노동 가치가 여러 번 사용되지 않도록 해야 합니다. Earned Wage Engine을 Eligibility Engine 및 거래 계층과 명확히 분리하면 EWA 시스템을 더 쉽게 통제하고 대사하며 확장할 수 있습니다.

작성자: Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

기업용 기발생 임금 접근 상담: Hotline 0937.022.655 · Email info@nhankiet.vn · 기업용 기발생 임금 접근 서비스