ERP 거래처 계좌변경 승인 개발: 지급 전 변경 이력을 확인하는 법

ERP 거래처 계좌변경 승인 개발은 현재 지급에 사용하는 계좌와 아직 승인되지 않은 변경안을 분리하고, 어떤 버전이 지급 준비에 사용됐는지 추적하도록 만드는 일입니다. 화면 승인뿐 아니라 파일 가져오기·API·지급파일 재생성까지 같은 보호 기준을 적용해야 합니다. 승인 절차는 계좌의 진위나 송금 안전을 보증하지 않으므로 확인 책임과 실제 지급 통제도 따로 정합니다.

거래처 담당자가 새 계좌 정보를 보내왔고 구매팀이 ERP의 계좌 필드를 고쳤다고 가정해 보겠습니다. 재무팀은 전날 만든 지급자료를 사용하고 있어 변경 사실을 모릅니다. 반대로 승인 대기 중인 값을 지급파일이 먼저 읽어가면 검토되지 않은 정보가 다음 업무에 쓰일 수 있습니다. 화면에 결재 이력이 있는지보다 현재 사용값과 변경 제안값, 지급 준비에 고정한 값의 관계를 먼저 살펴야 합니다.

이 글은 거래처 지급 기준정보를 바꾸는 과정의 시스템 설계입니다. 실제 계좌번호나 증빙 원본은 예시에 쓰지 않습니다. 가상 거래처 V사의 계좌 버전 B1과 변경 제안 B2처럼 식별자만 사용합니다. 자동송금 구현, 은행 실명 확인, 사기 탐지와 법적 효력 판단은 범위 밖입니다. 실제 확인 방식과 민감정보의 수집·보관 조건은 조직의 재무·보안 책임자가 별도로 정해야 합니다.

범용 결재 시스템을 연결할 때도 승인 대상이 정확히 무엇인지 확인하세요. 거래처 전체를 승인하는지, 특정 은행 필드의 한 변경 버전을 승인하는지에 따라 후속 동작이 달라집니다. 결재자가 화면을 본 뒤 신청자가 내용을 고쳤다면 이전 승인으로 새 값을 적용하면 안 됩니다. 계좌변경 기능의 납품 범위에는 변경 대상 고정, 검증 자료와 승인본 연결, 적용 실패의 처리까지 포함할지 합의해야 합니다.

공식 제품도 화면과 가져오기 경로의 승인을 나눕니다#

Microsoft Dynamics 365 Finance의 vendor bank account workflow 문서는 보호할 필드와 생성·수정 승인 여부를 설정하는 방식을 설명합니다. 데이터 엔티티를 통한 기존 계좌 수정에는 승인 없이 변경, 변경 거절, 변경 제안 생성 등 별도 동작을 선택할 수 있습니다. 변경 제안을 만들더라도 워크플로가 자동 제출되는 것은 아니라고 명시합니다. 따라서 화면에서 결재를 거친다는 사실만으로 가져오기 경로까지 보호된다고 볼 수 없습니다. 아래 버전 대사와 지급파일 통제는 조직이 추가로 정의할 설계 조건입니다.

• Microsoft Learn: 거래처 은행 계좌 워크플로: 보호 필드, 생성·수정 승인과 데이터 엔티티 경로의 설정 차이를 확인합니다. 은행 검증이나 모든 지급 경로의 안전 보장이 아닙니다.

파일·API 우회와 반려 뒤 복구를 함께 설계합니다#

기준정보를 바꾸는 경로를 먼저 목록으로 만듭니다. ERP 화면, 엑셀 가져오기, 외부 포털, 야간 동기화와 관리자 도구가 같은 필드를 쓸 수 있습니다. 경로별로 보호 필드를 거절할지 변경 제안으로 받을지 정하세요. 승인 계좌를 복사하는 배치가 별도 권한으로 직접 덮어쓰면 화면 결재는 쉽게 우회됩니다. 현재 구조에서 막을 수 없는 경로가 있으면 제외 범위와 모니터링, 수동 점검 책임을 제안서에 드러내야 합니다.

서로 다른 경로에서 B2와 B3를 동시에 제안한 상황도 정합니다. 최신 요청을 자동으로 채택할지보다 어떤 변경이 동일한 현재값을 전제로 했는지 확인하는 게 먼저입니다. B2가 적용된 뒤 B1을 기준으로 만든 B3를 승인하려면 차이를 다시 검토하도록 할 수 있습니다. 늦게 도착한 연동 응답이 사용값을 B1로 되돌리지 않도록 대상 버전과 결과를 묶으세요. 처리에 실패한 제안과 아직 판단하지 않은 제안은 운영 목록에서 구분해야 합니다.

반려는 현재 계좌를 과거 값으로 되돌리는 행동과 다릅니다. 아직 적용하지 않은 제안 B2를 반려했다면 B1의 상태가 그대로 남는지 확인합니다. 적용이 끝난 뒤 잘못을 발견했을 때는 별도의 사용중지나 정정 요청으로 처리하고 누가 어떤 버전을 사용했는지 남깁니다. 증빙을 삭제해 승인 이력과의 연결을 끊지 않도록 보관 정책도 합의하세요. 민감한 자료는 무조건 오래 저장하는 대신 목적과 권한, 필요한 보관 조건을 조직 기준으로 정합니다.

운영 화면에는 승인 대기 건수뿐 아니라 승인 후 미적용, 적용 후 대사 불일치, 지급자료 버전 차이와 확인자 부재를 구분해 보여줍니다. 알림 실패가 계좌 변경 성공으로 기록되지 않게 하고, 담당자가 다시 알림을 보내도 승인이나 적용이 반복되지 않는지 확인합니다. 역할이 바뀌면 계좌 상세 열람과 승인 권한이 함께 회수됐는지도 점검합니다. 공용 관리자 계정으로 모든 행동을 남기면 실제 확인 책임을 추적하기 어려우므로 운영 방식까지 검토하세요.

거래처 계좌변경 기능은 실제 사용값으로 검수합니다#

첫 검수 표본은 승인 대기 중인 B2가 지급 준비 조회에 노출되는지입니다. 목록 화면의 마스킹만 보지 말고 파일 출력과 API 응답까지 확인하세요. 승인자가 거절한 뒤 현재 사용값이 바뀌지 않는지, 승인된 제안을 수정하면 재검토되는지, 권한 없는 사용자가 직접 호출했을 때도 차단되는지 확인합니다. 오류 메시지가 표시돼도 데이터가 변경됐을 수 있으므로 실행 전후 버전과 실제 기준정보를 대조해야 합니다.

지급파일 관련 표본은 생성 전 변경, 생성 후 변경, 검토 완료 후 변경을 나눕니다. 새 파일을 만들었을 때 이전 파일이 여전히 사용 가능으로 남지 않는지 확인하고, 외부 전달을 담당자가 기록하지 못한 상황의 보류 동작도 시연합니다. 시스템 밖에서 처리하는 단계는 화면 시연만으로 완료 판정을 내릴 수 없습니다. 어느 문서와 확인 기록으로 인수할지 정하고, 자동화하지 않은 부분을 명확히 표시해야 운영자가 기능 범위를 이해합니다.

기존 ERP에 보호 필드와 승인 기능이 있으면 그 설정을 먼저 검토합니다. 부족한 변경 확인 화면이나 지급자료 차이 조회만 확장할 수도 있습니다. 별도 포털을 만들 때는 ERP를 기준정보의 정본으로 유지할지, 승인 원장을 새 모듈이 맡을지 결정하세요. 두 시스템에 각각 현재 계좌가 생기면 어느 쪽이 맞는지 사람이 매번 판단하게 됩니다. 계약에는 기준 시스템, 연동 방향, 적용 실패 복구와 운영 지원 범위를 함께 적습니다.

인수 자료에는 보호 필드 목록, 경로별 변경 정책, 역할·대리 승인 표, 상태 전이와 버전 예시, 지급파일 연결 방식, 오류 복구 절차를 포함합니다. 실제 금융정보를 제거한 샘플로 새 운영자가 변경 요청부터 반려·재신청·적용 확인까지 수행해 보게 하세요. 계좌 확인의 업무 판단과 시스템 구현의 기술 판단이 어디서 만나는지도 기록합니다. 설정 변경으로 보호가 약해지는 경우 누가 승인하고 어떤 표본을 다시 확인할지 정해두면 운영 중 통제 범위를 유지하기 쉽습니다.

공통 결재 흐름은 전자결재 시스템 설계에서 확인하세요. 거래처 식별 연결은 CRM·ERP 거래처 코드 매핑로 구분합니다. 지급을 포함한 재무 업무 범위는 재무관리 시스템를 참고하세요.