수금매출할인 로직

화면: 영업정보 → 수금관리 → 수금예외등록 → 수금매출할인 처리 대상 독자: 업무 분석 · 이식 담당 조사일: 2026-07-10 · 방법: 이 서버 → VPN → 바코드 MSSQL → 연결서버 UNION_ERP → Oracle 읽기 전용 조회

결론 — 현행 공식

수금할인액 = TRUNC( 전월 실수금 합계 × 0.03 )

• 전월 실수금 합계 = 그 거래처의 전월 수금 중 구분 10(현금) 15(보통예금) 20(어음) 30(카드) 의 합
• 3% 고정, 원단위 절사
• 익월 초(대개 4~10일)에 수금구분 35(수금할인) 전표 한 건으로 등록된다
• 이 전표는 단독 행이다. 같은 날 같은 거래처의 실수금 행과 짝지어 있지 않다

검증 (2026년 전수)

전월 실수금 × 3% 절사 로 계산한 값과 실제 등록액을 대조했다.

절사까지 확인된다. 어느 거래처는 전월 수금 4,924,920 × 3% = 147,747.6 → 등록액 147,747.

벗어나는 건 (7건 / 357건) — 대부분 밀린 달을 몰아서 처리한 것

예외등록 이라는 화면 이름 그대로다. 요율은 3% 그대로이고, 곱하는 기간이 전월 한 달이 아닌 경우가 대부분이다. 7건을 개별 추적했다.

두 달치 합산의 예: 전전월 4,000,000 + 전월 3,000,000 = 7,000,000 × 3% = 210,000 (실제 등록액과 일치). 절사도 함께 확인된다: 두 달 합 8,793,930 × 3% = 263,817.9 → 등록액 263,817.

즉 357건 중 353건(98.9%)이 “어느 기간 × 3% 절사”로 설명된다. 나머지 4건만 사람이 정한 값이다.

어느 달을 합칠지, 언제 조정할지는 시스템이 강제하지 않는다. 화면에서 사람이 정한다.

계산은 어디서 일어나는가 — 벤더 클라이언트

오라클의 V$SQL(최근 실행된 SQL 캐시)을 조회해 확인했다.

• COLLECT_ORDER 에 행을 넣는 문장은 클라이언트 프로그램이 직접 실행하는 INSERT 다. 값은 전부 바인드 변수로 넘어온다 — 즉 금액이 이미 계산된 채로 도착한다.
• 이 INSERT 를 감싸는 프로시저가 없다. 전체 스키마(KUP · SYS · SYSTEM 등)의 PL/SQL 소스에서 COLLECT_ORDER 에 INSERT 하는 객체는 SP_COLLECT_DELIV (수금구분 다름, 요율 1%) 하나뿐이다.
• 소스 전문 검색에서 0.03 · 3/100 · DISCOUNT_RATE 는 수금과 무관한 곳에서만 나온다 (연말정산 의료비 3%, 도매 관련 1%).

따라서 3% 요율은 데이터베이스에 존재하지 않는다. 화면의 “자동 계산” 버튼은 클라이언트가 계산한다. 요율을 바꾸려면 DB 가 아니라 벤더 프로그램을 고쳐야 한다.

남은 확인 방법: 담당자가 그 버튼을 누르는 순간 V$SQL 을 조회하면, 버튼이 전월 수금을 어떻게 집계하는지 그 SELECT 문장을 그대로 볼 수 있다. 조사 시점에는 최근 실행 기록이 캐시에 없었다.

계산은 코드에 없다 — 화면에서 확정되어 들어온다

KUP.SP_COLLECT 는 수금 구분별로 분개만 한다(DECODE 로 계정 분류). 할인액을 계산하지 않는다.

,DECODE(CUR_COLLECT.COLLECT_CLASS, '35', CUR_COLLECT.COLLECT_AMT ...)  -- 수금/수금할인
,DECODE(CUR_COLLECT.COLLECT_CLASS, '40', CUR_COLLECT.COLLECT_AMT, 0)   -- 매출할인(거래처)

즉 3% 요율은 어느 프로시저에도 저장돼 있지 않다. 클라이언트 프로그램(화면)이 계산해서 금액을 확정한 뒤 COLLECT_ORDER 에 넣는다. 요율을 바꾸려면 DB 가 아니라 벤더 프로그램을 고쳐야 한다.

수금구분 코드 — 테이블 명세와 코드 주석이 어긋난다

collection.mdx 의 S028 설명과 SP_COLLECT 의 실제 주석이 다르다. 코드를 신뢰한다.

명세의 “40 = 수금할인” 을 믿고 40번 행을 뒤지면 엉뚱한 것을 본다. 현행 수금할인은 35 다.

또한 COLLECT_ORDER.REDUCTION_AMT · UNDICS_CODE 컬럼은 명세에 설명이 있으나 실데이터가 전부 NULL 이다.

폐기된 자동계산 — SP_ORDER_DISCOUNT

소스 전문: SP_ORDER_DISCOUNT.sql · 날짜구간 반복 버전 SP_ORDER_DISCOUNT_LOOP.sql (저장소 경로: public/procedures/. Nextra 가 content/ 안의 .sql 을 페이지로 파싱하려 해서 밖에 둔다.)

이 프로시저는 현행 로직이 아니다. 결과 테이블 COLLECT_ORDER_DISCOUNT 에 2011-01-04 ~ 2013-08-31, 31,533행 이후 데이터가 없다. 13년째 돌지 않는다. 객체의 LAST_DDL_TIME 이 2025-12-31 로 찍혀 있으나 이는 스키마 변경에 따른 재컴파일이다.

내용은 조기 수금 인센티브를 채권 나이별로 차등 지급하는 구조였다. 지금의 단일 3% 와 다르다.

1. 대상: 그날 회계승인된 수금 중 구분 10 15 30. 거래처·부서·담당자·유통구분별 합산.
2. CREDIT_SALES_DAILY 에서 전일 실잔고와 나이 구간별 매출액(31/62/92일 이내)을 읽는다.
3. 실잔고 ≤ 0 → 수금 전액에 1.8%.
4. 실잔고 > 0 → 수금액이 오래된 채권부터 갚는 것으로 보고 구간별 요율 적용:

5. 할인액 = 대상금액 × 요율, 원단위 절사. 부가세 = 할인액 ÷ 10 (절사).

2011~2013 실행 행에서 역산한 요율이 0.600 / 1.200 / 1.800% 로 소스와 일치했다 — 해석은 맞고, 다만 쓰이지 않는다.

검증 쿼리 (직접 돌려볼 것)

이 문서의 주장을 그대로 믿지 말고 재현하라. 게이트웨이 경유 읽기 전용이다.

-- 2026년 수금할인(35) 이 "전월 실수금 × 3% 절사" 와 맞는지 전수 대조
SELECT d.YM,
       COUNT(*) CNT,
       SUM(CASE WHEN ABS(d.DISC - TRUNC(p.PAID * 0.03)) <= 1 THEN 1 ELSE 0 END) MATCH3
  FROM (SELECT SUBSTR(COLLECT_DATE,1,6) YM, SALES_CODE, SUM(COLLECT_AMT) DISC
          FROM COLLECT_ORDER
         WHERE COLLECT_CLASS = '35' AND COLLECT_DATE >= '20260101'
         GROUP BY SUBSTR(COLLECT_DATE,1,6), SALES_CODE) d
  LEFT JOIN (SELECT SUBSTR(COLLECT_DATE,1,6) YM, SALES_CODE, SUM(COLLECT_AMT) PAID
               FROM COLLECT_ORDER
              WHERE COLLECT_CLASS IN ('10','15','20','30')
              GROUP BY SUBSTR(COLLECT_DATE,1,6), SALES_CODE) p
    ON p.SALES_CODE = d.SALES_CODE
   AND p.YM = TO_CHAR(ADD_MONTHS(TO_DATE(d.YM,'YYYYMM'), -1), 'YYYYMM')
 GROUP BY d.YM ORDER BY d.YM;

호출 경로(MSSQL 게이트웨이에서):

SELECT * FROM OPENQUERY(UNION_ERP, '<위 쿼리를 한 줄로, 홑따옴표는 두 개로>');

참고

• CONTRACT_VALUE.CONTRACT_TYPE_2 는 명세상 “매출할인요율” 이나 값 분포가 100 · 50 · 70 · 0 으로 백분율 요율이 아니라 부담 배분율로 보인다. 3% 와 무관하다. 읽는 곳: SP_CLOSE_CREDIT · SP_CLOSE_UNDISC · SP_DELIVERY 계열.
• 소스는 ERP 벤더 소유다. 이 저장소에는 분석 목적의 사본만 둔다.
• 예시에 쓴 거래처코드·금액은 실데이터라 본문에서 마스킹했다.