거래처를 매입처와 매출처로 따로 관리하고 싶다는 요청을 받으면 테이블부터 두 개 만들기 쉽다. 하지만 한 업체에서 사기도 하고 그 업체에 팔기도 한다면 같은 상대가 두 번 생긴다. 과거 전표는 어느 쪽으로 옮겨야 할까. 이 프로젝트의 요청과 역할 코드를 읽으며 내가 다시 확인한 것은 목록을 나누는 일과 사람이나 업체의 정체성을 나누는 일이 같지 않다는 점이다. 화면에서의 편의가 이력의 단절로 이어지지 않게 해야 한다.
역할은 상대가 아니라 거래의 방향을 설명한다
보관된 구현에는 매출처, 매입처, 양쪽 모두, 분류 대기라는 역할이 있다. 매입 문서를 쓸 때는 매입 역할을 받을 수 있는 업체를 선택하고 판매 문서에서는 반대 방향을 사용한다. 이 구분은 불필요한 목록을 줄이는 데 도움을 준다. 한 업체가 양쪽 역할을 갖더라도 같은 식별자를 유지하면 이전 거래와 현재 상세가 서로 다른 복사본으로 갈라지지 않는다.
그렇다고 모든 업체를 양쪽 모두로 두면 구분의 의미가 없다. 실제로 확인한 업무 관계만 역할에 반영해야 한다. 이름이나 브랜드가 비슷하다는 이유로 매입처라고 추정하는 것도 피해야 한다. 당시 요청은 특정 판매 상대와 공급처의 역할을 바로잡는 방향으로 이어진다. 이 판단을 확인된 분류로 남기되 원래 받은 업체 자료와 전표의 출처는 보존하는 편이 다음 확인에 도움이 된다.
입력 문맥이 목록과 검증에 함께 이어져야 한다
같은 거래처 검색창을 여러 화면에서 쓰더라도 문서 역할이 다르면 허용 대상과 기본 목록이 달라질 수 있다. 화면에서만 매입처를 골라 보여 주고 서버가 어떤 업체든 받아들이면 다른 경로에서 잘못 저장할 수 있다. 반대로 서버만 거부하면 사용자는 선택 가능한 목록에서 골랐는데 저장이 안 되는 경험을 한다. 필터와 저장 검증은 같은 역할 계약을 설명해야 한다.
분류되지 않은 업체를 처리할 경로도 필요하다. 검색 결과에서 숨기기만 하면 이미 존재하는 업체를 다시 등록하게 될 수 있다. 이름과 번호로 기존 자료를 찾고, 필요한 권한으로 역할을 확인해 수정하거나 분류 대기로 남기는 흐름이 있어야 한다. 새로운 업체를 만드는 것과 기존 업체의 역할을 추가하는 것은 다른 동작이다. 버튼 문구도 두 동작을 구별해 주는 편이 명확하다.
역할을 바꿔도 과거 거래의 방향은 남는다
현재 매입처로 분류했다고 오래된 매출 전표가 매입으로 바뀌어서는 안 된다. 전표 종류와 상대의 식별자, 거래 당시 금액은 과거 사건을 설명한다. 현재 분류는 앞으로 검색하고 선택할 때 사용할 기준이다. 나는 이런 값을 같은 설정 하나로 묶지 않으려 한다. 사용 중지나 역할 변경이 과거 문서의 열람과 재출력까지 막는지도 별도로 확인해야 한다.
관계 정리가 필요한 경우에는 변경 이유와 이전 값을 남기는 방법이 좋다. 잘못 붙인 역할을 정정하는 일과 중복 업체를 병합하는 일도 구별한다. 병합은 연결된 모든 전표와 원본 식별자를 다루므로 단순한 체크박스 변경보다 범위가 크다. 목록을 보기 좋게 만들기 위해 그 작업까지 자동으로 실행하면, 나중에 왜 이 업체에 다른 이력이 붙었는지 설명하기 어려워진다.
다른 관리 프로그램에도 같은 질문이 남는다
회원과 거래처, 고객과 협력사처럼 메뉴 이름이 달라도 같은 상대가 여러 역할을 가질 수 있다. 공통 식별자를 유지하면서 역할별 화면과 권한을 나누면 반복 입력을 줄이고 이력의 연결을 지킬 수 있다. 다만 법적 주체가 다른데 이름만 같다면 별개로 보존해야 한다. 재사용할 것은 무조건 하나로 합치는 규칙이 아니라 동일성의 확인과 역할 선택을 분리하는 원리다.
검토할 때는 한쪽 역할만 있는 업체, 양쪽 역할이 있는 업체, 분류 대기 업체, 같은 이름의 다른 업체를 합성 자료로 만든다. 검색·등록·역할 수정·과거 상세 열람을 따라가며 어떤 값이 바뀌고 무엇이 그대로 남는지 확인한다. 이번 글에서는 선택한 요청과 보관된 역할 구현·당시 기록을 읽었으며 실제 업체 분류를 바꾸지 않았다. 잘 나뉜 화면은 같은 상대의 기록을 잃지 않는 구조 위에서 만들어져야 한다.