ERP 월마감 기능 개발: 기간 잠금과 재개방 승인 범위를 정하는 법

ERP 월마감 기능 개발은 회사·기간·거래 종류별로 더 이상 반영할 수 없는 작업을 정하고, 예외로 다시 열 때 변경 대상과 권한·종료 조건을 남기는 일입니다. 체크리스트의 완료 표시, 전표 입력 잠금, 연동 자료의 수신 보류는 서로 다른 통제입니다. 재개방 후에는 최초 마감본과 수정 마감본을 비교하고 다시 잠겼다는 증거까지 확인해야 합니다.

매출 보고서를 공유한 다음 날, 전날 출하 자료가 늦게 들어옵니다. 운영자는 누락을 채우려고 마감을 풀고, 다른 부서는 그 사실을 모른 채 이전 보고서를 계속 사용합니다. 잠깐 열린 기간에 수정한 거래까지 섞이면 원래의 누락을 고친 범위를 설명하기 어렵습니다. 월마감 화면에서 마감 버튼이 잘 눌리는지만 확인하면 이런 문제가 남습니다. 어떤 자료를 확정했고 예외 변경을 어디까지 허용하는지부터 기록해야 합니다.

이 글의 가상 제조기업은 기존 회계 ERP를 유지하면서 구매·출하 연동과 마감 승인 화면을 확장하려는 상황입니다. 월말 날짜를 어느 시간대로 계산하는지, 반품을 어떤 계정으로 처리하는지는 각각 별도 정책입니다. 여기서는 특정 법인의 한 기간을 잠그고 다시 열었다 닫는 권한과 증거에 집중합니다. 회계 처리와 신고 판단은 재무 책임자가 정하며, 개발사가 시스템 상태만 보고 정답을 결정하지 않습니다.

요구사항에는 마감이라는 말의 뜻을 풀어 적습니다. 업무 담당자가 할 일을 모두 끝냈다는 표시인지, 거래의 신규 등록이 막혔다는 뜻인지, 수정과 취소도 막는지 구분하세요. 재고는 잠겼는데 매입 정정은 열려 있을 수 있고, 본사는 닫혔지만 다른 법인은 처리 중일 수도 있습니다. 한 개의 공통 상태로 모든 화면을 제어하기 전에 실제 원장을 소유한 시스템과 통제 범위를 맞춰야 합니다.

제품의 기간 상태와 마감 작업 관리는 따로 확인합니다#

Microsoft Dynamics 365 Finance 공식 문서는 기간을 On hold로 두어 추가 전기를 막고 사용자 그룹으로 접근을 제한하는 방식을 설명합니다. Permanently closed 상태는 다시 열 수 없다고 명시합니다. 별도의 Financial period close workspace는 회사·영역·담당자별 작업과 의존성을 추적합니다. 이 구분은 체크리스트 완료와 실제 원장 통제를 나눠 확인할 근거입니다. 아래 재개방 요청과 차이표는 그 제품의 기본 기능 목록이 아니라 발주자가 검토할 설계 제안입니다.

• Microsoft Learn: 기간 말 총계정원장 마감: 기간 상태와 사용자 그룹 통제의 제품 사례입니다. 다른 ERP의 상태 의미는 별도 확인합니다.
• Microsoft Learn: 재무 기간 마감 작업 공간: 작업 담당자·완료·의존성 추적을 설명합니다. 모든 원장 변경의 자동 차단 보장이 아닙니다.
• Microsoft Learn: 기간 상태와 모듈 접근: Open·On hold·Permanently closed와 모듈별 접근을 구분하는 공식 자료입니다.

늦은 연동 거래는 보류함에서 처리 경로를 결정합니다#

마감 뒤 도착한 자료를 접수 실패로만 돌려보내면 원천에서는 계속 같은 요청을 보낼 수 있습니다. 수신 자체와 원장 반영을 나누고, 받을 수 있는 범위에서 원천 ID·수신 시각·대상 기간·보류 이유를 기록하세요. 원천의 재시도는 같은 보류 건으로 연결해야 합니다. 자료를 받았다는 응답이 회계나 재고에 반영됐다는 뜻으로 읽히지 않도록 상태명과 연동 계약도 맞춥니다. 보류함에는 업무 판단이 필요한 건과 기술 재처리만 필요한 건을 따로 보이게 합니다.

보류 건의 선택지는 조직 정책에 따라 정합니다. 원천에서 정정할지, 다음 기간의 후속 처리로 남길지, 승인된 재개방으로 반영할지 재무와 현업이 판단합니다. 개발자는 날짜를 당월로 자동 치환해 오류를 숨기지 않아야 합니다. 거래를 다시 처리할 때 이미 반영된 사실을 확인하고 재전송으로 수량이나 금액이 두 번 늘지 않는지 검수합니다. 사유와 결정자는 원본 자료와 함께 보존해 다음 마감에서도 같은 질문을 반복하지 않게 합니다.

기존 ERP 설정으로 잠금행렬을 충족하면 별도 원장을 만들 필요가 없습니다. 설정과 마감 작업 화면을 연결하는 방안, 연동 보류함만 추가하는 방안, 제한된 재개방 모듈을 개발하는 방안을 같은 표본으로 비교하세요. 외부 화면이 승인했어도 ERP 쪽 임시 권한 변경을 적용할 수 없다면 수동 운영 단계가 남습니다. 그 단계를 자동화된 것처럼 견적에서 빼지 말고 실행자·검증자·소요 작업을 명시해야 합니다.

운영 인수에는 재개방을 신청한 사람과 재마감을 확인할 사람이 동시에 부재한 경우도 넣습니다. 대리 승인권은 업무 책임자가 사전에 정하고 운영자가 임의로 확대하지 않습니다. 알림이 실패했을 때 마감이 자동으로 풀리거나 승인 없이 기간이 연장되지 않도록 기본 동작을 합의하세요. 진행 중 요청, 만료된 권한, 닫히지 않은 기간을 한 화면에서 대사할 수 있으면 다음 달에도 같은 절차를 반복할 수 있습니다.

제안 비교와 인수는 잠금의 우회 경로까지 봅니다#

검수 자료는 정상 전기 한 건과 승인 거절 한 건만 준비하지 않습니다. 마감 직전에 연 화면, 잠금 직후 도착한 파일, 재개방이 만료된 상태의 저장, 다른 법인으로 복사한 요청, 부분 실패 뒤 재전송한 거래를 포함하세요. 각 표본에는 기대되는 원장 상태와 보류 상태를 따로 씁니다. 화면에 오류가 보이더라도 데이터가 이미 저장됐다면 차단 성공으로 판정하지 않습니다. 실제 반영 결과와 감사 이력까지 확인해야 합니다.

마감본 비교는 두 버전의 건수와 합계뿐 아니라 변경 거래를 원천 증빙까지 따라가는 시연으로 받습니다. 담당자가 임의의 정정 한 건을 골라 최초 값, 승인 요청, 최종 값, 후속 보고서 수정 여부를 찾아보게 하세요. 수치가 같더라도 거래가 바뀌었을 수 있으므로 합계 일치만으로 종료하지 않습니다. 미처리 보류 건과 의도적으로 제외한 건의 목록도 납품 자료에 남겨야 실제 인수자가 미완료 업무를 파악할 수 있습니다.

계약할 때는 원장 제어 권한, 지원하는 거래 유형과 ERP 버전, 파일·API 연동 범위, 마감본 보관 방식과 복구 절차를 적습니다. 회계 처리 정책을 정하는 일과 그 정책을 구현하는 일의 담당자를 분리하세요. 운영 지원의 시간·장애 대응·월말 입회와 추가 거래 유형 반영은 포함 여부를 별도로 확인합니다. 개발 완료 후에도 재무팀이 바꿀 수 있는 설정과 개발 변경이 필요한 항목을 구분해 받아두면 마감 조건이 달라질 때 판단하기 쉽습니다.

거래 자체의 후속 처리는 반품·분할출하 검수에서 확인하세요. 업무일 계산은 일별 집계 날짜 경계로 구분합니다. 재무 업무 전체 범위는 재무관리 시스템 설계를 참고하세요.