ERP 모듈은 실제로 어떻게 통합되는가

“통합”이라는 말 뒤에 숨은 세 가지

거의 모든 ERP 안내 책자가 “통합”이라는 단어를 씁니다. 그 이면에는 월말에 문제가 생겼을 때 전혀 다르게 작동하는 최소 세 가지 방식이 있습니다. 첫째는 파일 또는 예약 배치 전송입니다. 한 시스템이 내보내고 다른 시스템이 가져오며, 보통 야간에 이루어집니다. 둘째는 API 또는 미들웨어 동기화로, 서로 분리된 두 데이터베이스가 메시지를 주고받으며 보조를 맞춥니다. 셋째는 진정한 데이터 공유로, 모듈이 별도의 시스템이 아니라 하나의 테이블 집합, 하나의 총계정원장, 하나의 마스터 레코드 집합을 서로 다른 관점에서 보는 화면입니다.

어느 것도 보편적으로 옳지는 않습니다. 배치 전송은 저렴하고 이해하기 쉬우며, 파일이 그냥 기다려 주기 때문에 어느 쪽의 장애도 견딥니다. 그러나 설계상 항상 최신이 아니며, 실패한 작업은 누군가 보고서에 의문을 제기할 때까지 눈에 띄지 않을 수 있습니다. API 동기화는 거의 실시간에 가까운 동작을 제공하고 유지할 합당한 이유가 있는 시스템을 계속 쓸 수 있게 해 주지만, 이제 분산 시스템을 떠안게 됩니다. 재시도, 순서, 부분 실패, 그리고 서로 어긋날 수 있는 두 개의 진실이 그것입니다. 데이터 공유는 데이터베이스가 하나뿐이므로 두 데이터베이스가 어긋나는 유형의 문제를 없애 주지만, 모듈들이 하나의 계정과목표, 하나의 품목 정의, 하나의 릴리스 주기에 합의해야 한다는 뜻이며, 이는 공짜 이점이 아니라 제약입니다.

실무적인 질문은 어느 수준이 최선이냐가 아니라 각 흐름에 어느 수준이 적합하냐입니다. 은행 거래내역서를 야간에 전송하는 것은 괜찮습니다. 실시간 POS 뒤의 재고 수준을 야간에 전송하는 것은 그렇지 않습니다. Skyline Nexus는 자체 모듈에 대해 세 번째 수준에 있습니다. 회계, POS 및 재고, CRM, 설비 보전, 인사, 차량 및 자산이 하나의 원장과 하나의 마스터 집합에 기록하며, 고객이 이미 유지할 가치가 있는 시스템을 갖고 있는 경우에는 API를 통해 외부 시스템과 통합합니다.

어긋남은 마스터 데이터에서 시작됩니다

통합 실패는 흔히 인터페이스 탓으로 돌려지지만, 첫 균열은 대개 내용이 조금씩 다른 채로 두 번 존재하는 마스터 레코드에서 생깁니다. 두 시스템이 각자 고객 목록을 보유하면 몇 주 만에 목록이 어긋나기 시작하고, 이후의 모든 숫자가 그 어긋남을 물려받습니다.

• 고객: 판매, 청구, 수금, 신용 관리 전반에 걸친 하나의 식별자. 그렇지 않으면 매출채권 연령분석이 판매 보고서와 일치하지 않습니다.
• 공급업체: 구매, 매입채무, 지급에 걸쳐 공유하며 은행 정보도 포함합니다. 은행 정보가 중복되면 사기의 표적이 됩니다.
• 품목: 하나의 코드, 하나의 측정 단위, 하나의 원가 계산 방법. 품목 마스터가 두 개면 재고 평가도 두 개가 됩니다.
• 계정과목표: 단일 구조. 모듈이 자체 계정 목록을 유지하면서 귀사의 목록에 매핑한다면, 그 매핑은 관리해야 하고 틀릴 수도 있는 또 하나의 대상이 됩니다.
• 세금 코드: 세율, 처리 방식, 적용 시작일에 대한 하나의 정의를 거래와 신고서 양쪽에서 사용합니다.
• 지점 및 위치: 재고와 회계가 모두 이를 기준으로 구분되므로 공유합니다.
• 직원: 급여, 근태, 보전 작업지시, 차량 배정 뒤에 있는 하나의 레코드.
• 자산: 감가상각, 보전 이력, 처분 뒤에 있는 하나의 대장.

보조원장과 통제계정

총계정원장은 요약된 잔액을 보유합니다. 상세 내역은 보조원장에 있으며, 각 보조원장은 원장의 통제계정과 연결됩니다. 매출채권 보조원장은 고객 청구서와 수금을 건별로 보유하며, 그 합계가 매출채권 통제계정이 됩니다. 매입채무도 공급업체 청구서에 대해 같은 방식으로 작동합니다. 재고 이동은 재고 통제계정에 전기되며, 상품이 출고될 때 매출원가가 인식됩니다. 급여는 총급여, 사용자 부담금, 공제액, 순지급 부채를 전기합니다. 고정자산은 취득, 감가상각, 처분을 자산 원가와 감가상각누계액에 전기합니다. POS는 매출, 징수한 세금, 결제 수단 유형, 그리고 계속기록법을 사용하는 경우 각 판매의 원가 측면을 전기합니다.

이를 신뢰할 수 있게 만드는 규칙은 간단합니다. 보조원장은 항상 통제계정과 최소 통화 단위까지 일치해야 합니다. 매출채권 연령분석이 한 금액을, 매출채권 통제계정이 다른 금액을 보여 준다면 둘 중 하나는 틀렸고, 조사하지 않고는 어느 쪽인지 알 수 없습니다. 이것이 통제계정에 대한 직접 분개가 일반적으로 차단되는 이유입니다. 매출채권에 대한 수동 분개는 어떤 고객도 빚지지 않은 잔액을 만들며, 그 잔액은 고객에게 보내는 어떤 거래명세서에도 나타나지 않습니다.

대사는 누군가 관리하는 스프레드시트가 아니라 필요할 때 실행할 수 있는 보고서여야 합니다. 모듈이 하나의 원장을 공유하면 대사는 거의 동어반복에 가깝습니다. 그렇지 않다면 대사는 자동화할 수 있는 가장 중요한 단일 점검입니다.

전기 규칙과 감사 추적

모든 원장 라인은 원천 문서까지 추적할 수 있어야 합니다. 청구서 번호, 입고, 급여 실행, 감가상각 일정, POS 거래 등입니다. 원천 없이 존재하는 라인이 있다면 누군가 절차를 우회한 것입니다. 문서 식별자는 별도의 매핑 테이블에 있을 것이 아니라 원장 라인과 함께 이동해야 합니다.

전기된 분개는 조용히 수정할 수 없어야 합니다. 정정은 역분개나 대변표로 해야 하며, 그러면 원래 분개와 정정 분개가 각자의 날짜와 사용자와 함께 모두 보입니다. 기간 마감은 사람들이 소급 입력하지 않기를 기억하는 데 의존할 것이 아니라 기간을 잠가야 합니다. 판단 기준은 어떤 잔액이든 열어서 시스템을 벗어나지 않고 그 잔액을 만든 문서까지 내려갈 수 있는지입니다.

통합이 실제로 깨지는 곳

실패 유형은 잘 알려져 있으며 거의 항상 같은 것들입니다.

• 시점과 기간 귀속: 기간 마지막 날 자정 직전에 전기된 매출이 마감 후에 다른 시스템에 도착하여 두 기간이 결코 일치하지 않습니다.
• 아무도 지켜보지 않는 실패 작업: 예약 전송이 멈추고, 데이터가 없는 것이 조용한 한 주처럼 보입니다.
• 부분 기록: 청구서 헤더는 생성되었는데 라인이 실패하여, 한쪽은 다른 쪽이 인식하지 못하는 문서를 보유하게 됩니다.
• 중복 키: 재시도된 메시지가 같은 청구서의 두 번째 사본을 만들거나, 번호 체계가 지점 간에 충돌합니다.
• 통화 및 반올림 차이: 두 시스템이 서로 다른 지점에서 반올림하거나 같은 날에 서로 다른 환율을 사용하여 작은 차이가 누적됩니다.
• 이중 세금 계산: 거래 시스템과 회계 시스템이 할인, 세금 포함 가격, 라인별 반올림과 문서별 반올림에 관해 조금씩 다른 규칙으로 각자 세금을 계산합니다. 그러면 고객에게 발급한 청구서와 신고서의 금액이 서로 달라집니다.

멱등성, 그리고 양쪽의 일치를 입증하는 방법

재시도할 수 있는 것은 결국 재시도되므로, 모든 전기 작업에는 원천 문서에서 도출한 안정적인 키가 필요합니다. 같은 청구서를 두 번 보내면 전기는 두 번이 아니라 한 번이어야 합니다. 수신 측은 이미 처리한 키를 기록하고 새 전기를 만드는 대신 이전 결과를 반환해야 합니다. 이것이 없으면 평범한 네트워크 동작이 중복 수익으로 바뀝니다.

이와 함께 대사를 핵심 기능으로 갖추어야 합니다. 기간별·문서 유형별 건수와 합계를 양쪽에서 비교하고, 차이를 요약하는 것이 아니라 목록으로 보여 주어야 합니다. 마지막 작업이 성공했다는 것만 알려 주는 초록색 체크 표시는 일치의 증거가 아닙니다. 유용한 보고서는 한쪽에는 있고 다른 쪽에는 없는 문서 일곱 건을 하나하나 짚어 주는 보고서입니다.

지점과 통화

다지점 운영에서는 모든 거래가 생성되는 순간부터 위치를 차원으로 가져야 하며, 나중에 보고서 로직으로 배정해서는 안 됩니다. 재고, 수익, 원가, 인력은 모두 지점에 속하며, 지점 간 이전은 양쪽 모두 전기되어야 합니다. 그렇지 않으면 두 지점의 재고 수치 합계가 회사 수치와 맞지 않습니다. 문서 번호는 지점 전체에서 고유하면서도 한 지점 안에서 의미가 있어야 합니다.

다중 통화에서는 거래 통화, 적용 환율, 기준 통화 금액이 모두 라인에 저장되어야 합니다. 환산된 금액만 저장하면 증거가 사라집니다. 그래야 미결제 잔액의 재평가와 결제 시 실현 외환차손익을 전기할 곳이 생기고, 환율 차이가 정체 모를 반올림 문제로 남지 않습니다.

지역별 참고 사항: 사전 승인(clearance) 방식은 시점을 바꿉니다

전자세금계산서 제도가 적용되는 곳에서는 통합의 시점이 더 이상 설계상의 선호 문제가 아닙니다. 여러 세무 당국이 이제 청구서가 구매자에게 도달하기 전 또는 도달하는 시점에 당국의 승인을 받거나 당국에 보고하도록 요구합니다. 사우디아라비아의 ZATCA 제도가 실제 사례입니다. 청구서는 정해진 구조, 암호화 요소, 식별자를 갖추어 생성되며, 당국은 사후에 요약을 받는 것이 아니라 문서의 생애주기에 관여합니다. 이 때문에 청구서 생성은 실시간 통합 문제가 됩니다. 야간 배치로는 계산대에서 고객이 기다리는 문서를 만들어 낼 수 없습니다.

다른 지역의 상황은 다르며, 정확히 짚어 둘 가치가 있습니다. 미국에는 연방 차원의 전자세금계산서 의무가 없으며, 판매세는 주 단위로 관리되고 규칙과 세율이 주마다, 또 흔히 지방 관할권마다 다릅니다. 캐나다는 연방 차원에서 GST와 HST를 운영하며 주별 차이가 있고, 일부 주에는 주 판매세가 있습니다. 더 넓은 MENA 시장은 서로 다른 단계에 있습니다. 설계상의 교훈은 세금 결정과 문서 발행을 한곳에 두어, 어떤 시장이 보고 방식에서 사전 승인 방식으로 바뀌더라도 아키텍처가 아니라 설정만 바꾸면 되도록 하는 것입니다. Skyline Nexus는 원장 분개를 기록하는 바로 그 거래에서 ZATCA 사전 승인을 처리하므로, 고객이 받는 청구서와 신고서의 금액이 하나의 계산에서 나옵니다.