대표가 회사 상황을 쉽게 확인하려면 큰 매출 숫자만 보여 주는 것으로는 부족하다. 얼마가 들어왔고 어떤 거래에 배분됐으며 무엇이 아직 미확인인지 알아야 한다. 이 ERP 제작 기록에서도 거래 문서와 입금·지급을 별도로 이어 가는 구조가 남아 있다. 나는 같은 화면에서 편하게 본다는 목표가 서로 다른 금액을 하나로 합친다는 뜻이 되어서는 안 된다고 본다. 보기의 단순함은 숫자의 의미가 분명할 때 도움이 된다.
전표 한 장과 돈 한 번은 일대일이 아니다
한 전표를 나눠 입금할 수도 있고 여러 전표의 금액을 한 번에 받을 수도 있다. 거래가 생기기 전에 선입금을 받는 경우도 있다. 이런 상황을 전표의 입금 완료 체크박스 하나로 처리하면 일부만 받은 상태를 설명하기 어렵다. 보관된 금액 흐름 코드는 입금·지급 기록과 전표나 기초 잔액에 배분한 항목을 따로 저장하는 구조를 갖고 있다.
입금 자체의 금액과 어디에 배분했는지를 나누면 아직 연결하지 않은 돈도 남길 수 있다. 배분되지 않았다는 이유로 실제 입금 사실을 지울 필요는 없다. 반대로 전표를 확정했다고 실제 입금 기록이 생겨서도 안 된다. 직원은 실제로 확인한 돈을 입력하고 적절한 대상에 연결하며, 대표는 받은 금액과 미배분 금액을 구별해 볼 수 있어야 한다. 이 설명은 해당 프로그램의 기록 구조에 관한 것이며 실제 은행 이체를 실행하는 기능은 아니다.
기초 잔액을 모르면 영으로 시작하지 않는다
새 장부를 시작할 때 과거 거래의 미수나 미지급이 남아 있을 수 있다. 그 잔액을 확인하지 않았는데 영으로 저장하면 새 화면은 정확해 보이지만 출발점부터 다르다. 이 구현에는 사업자별 시작일과 거래처별 기초 잔액을 확인하는 경계가 있다. 시작일 이전의 전표에 새 입금을 임의로 배분하지 않고 확인한 기초 값으로 처리할 수 있게 한 것이다.
대표용 요약에서도 기초 확인 전이라는 상태가 보여야 한다. 미수금이 영인 업체와 아직 잔액을 확인하지 못한 업체를 같은 색과 숫자로 보여 주면 잘못된 판단이 생긴다. 일단 영으로 만들고 나중에 고치는 방식이 쉽더라도 그동안의 보고서가 어떤 전제 위에 있었는지 남겨야 한다. 모르는 값을 계속 미확인으로 표시하는 것이 불편할 수 있지만 없는 빚이라는 사실을 새로 만드는 것보다는 정확하다.
배분은 같은 사업자와 같은 방향 안에서
같은 업체와 거래하더라도 우리 쪽 발행 사업자가 다르면 금액을 섞어서는 안 된다. 매출 대금과 매입 지급도 방향이 다르다. 보관된 배분 코드는 사업자, 거래처와 방향을 확인하고 선택된 현장과 전표가 맞는지 검사한다. 다른 화면에서 넘겨받은 식별자라고 무조건 신뢰하지 않는 것이다. 화면 필터만으로 이 경계를 지키면 다른 API 경로에서 잘못 연결될 수 있다.
입금보다 많이 배분하거나 같은 전표에 같은 금액을 중복 배분하는 문제도 살펴야 한다. 대상 전표가 그 사이 바뀌었다면 최신 상태를 다시 확인해야 한다. 저장 중 응답을 못 받은 경우 같은 요청을 재확인해 중복 기록을 피하는 경로도 필요하다. 대표가 보기 편한 화면을 만들려면 화면 아래에서 이런 경계가 먼저 일관돼야 한다. 숫자가 간단해 보인다는 이유로 저장 검사를 줄이면 확인의 편의도 오래 유지되지 않는다.
취소와 환불도 설명 가능한 기록으로
잘못 기록한 입금과 실제 돈이 나간 환불은 같은 일이 아니다. 취소 사유와 원래 기록, 새로 확인한 움직임을 구분해야 한다. 보관된 코드도 취소 상태의 기록을 조용히 다시 쓰기보다 보존하고 새 기록으로 이어 가는 조건을 갖고 있다. 수정할 때 유지해야 하는 거래의 정체성과 바꿀 수 있는 설명 값을 나누면 나중에 왜 잔액이 달라졌는지 확인하기 쉬워진다.
검토용으로는 전표 하나의 부분 입금, 여러 전표의 한 번 입금, 미배분 선입금, 기초 잔액 미확인과 반대 방향의 잘못된 배분을 준비하면 좋다. 각 화면이 같은 금액을 다른 이름으로 부풀리지 않는지 확인한다. 이번 글은 선택한 금액 흐름 코드와 당시 기록을 바탕으로 정리했으며 실제 계좌와 현재 잔액을 대조하지 않았다. 대표가 쉽게 확인하는 시스템은 작은 숫자 묶음만 보여 주는 화면이 아니라, 각 숫자의 근거와 아직 확인할 일을 이어서 볼 수 있는 화면이다.