계산 체계 SAP MM & SD

⚡ 스마트 요약

계산 체계 SAP 순가격을 산출하기 위해 조건 유형이 적용되는 순서를 정의합니다. 사용자 정의 제어는 가격 책정(A) 및 구매(M)에 적용되며, 각 단계에는 고유한 계산 및 계정 설정이 있습니다.

  • 🧮 핵심 정의: 총 가격, 할인, 추가 요금 및 순 가치를 계산하는 데 사용되는 조건 유형의 순서 목록입니다.
  • ⚙️ 경로 사용자 지정: IMG에서 계산 스키마를 정의합니다. 여기서 사용 A는 가격 책정, 응용 M은 구매를 나타내며 절차 집합을 식별합니다.
  • 🪜 스텝 앤 카운터: 스텝은 순서를 고정하고 카운터는 여러 조건이 하나의 스텝을 공유할 수 있도록 합니다.
  • 보내는 사람 및 받는 사람: 이러한 참조 단계는 백분율 조건을 계산하는 데 사용되는 기준값을 제공합니다.
  • 🔒 제어 플래그: 수동, 필수 및 통계 옵션은 조건을 입력할 수 있는지, 반드시 존재해야 하는지, 또는 보고 전용인지 여부를 결정합니다.
  • 🏦 계정 키: AccKey 및 AccrualAccKey는 계산된 값을 올바른 총계정원장 계정 또는 충당금으로 라우팅합니다.

계산 스키마 SAP MM과 SD

계산 스키마란 무엇인가요? SAP?

계산 체계(가격 책정 절차라고도 함)는 레시피와 같습니다. SAP 이 절차는 개별 조건 목록을 구매 문서상의 단일 순 가격으로 변환하는 데 사용됩니다. 이 절차가 없으면 할인과 운송비는 서로 관련 없는 숫자로 존재하며, 이들이 어떻게 결합되는지에 대한 규칙이 없게 됩니다.

이 스키마는 모든 구매 주문 품목에 대해 세 가지 질문에 대한 답을 제공합니다.

  • 어떤 순서로요? 운송비를 고려하기 전에 계산된 할인 금액과 운송비를 고려한 후에 계산된 할인 금액은 다릅니다. 단계 번호가 이러한 순서를 고정합니다.
  • 무엇을 기반으로합니까? 백분율 조건을 사용하려면 기준값이 필요합니다. '시작'과 '끝' 참조 단계는 어떤 이전 줄들을 합산할지 지정합니다.
  • 어디에 게시하는 건가요? 계산된 각 금액은 총계정원장 계정에 입력되어야 하며, 해당 계정은 해당 줄에 있는 계정 키가 제공합니다.

해당 스키마는 가격 구성 체인의 최상위에 있습니다. 조건 테이블 및 액세스 시퀀스 가격이 어디에서 발견되는지 결정하세요. 조건 유형 값이 어떤 종류인지 설명하고, 계산 방식은 이 모든 값들이 어떻게 결합되는지를 결정합니다.

계산 스키마를 정의하는 프로세스

이전 항목에서 본 것처럼 조건 유형에는 계산 스키마가 할당됩니다. 이는 사용자 정의에서 정의됩니다.

단계 1) IMG에서 계산 스키마 정의 옵션을 선택합니다.

계산 스키마 정의 SAP

단계 2)

  1. 초기 화면에는 최상위 메뉴로 스키마가 있는 대화 상자 구조가 포함되어 있는 것을 볼 수 있습니다. 또한 드롭다운 메뉴를 통해 제어 데이터도 확인할 수 있습니다.
  2. 화면 오른쪽에는 사용량 및 애플리케이션 데이터가 표시됩니다. 사용량은 다음과 같습니다. A – 가격, 애플리케이션은 다음으로 설정됩니다. 남 – 구매.
  3. 스키마 목록과 간단한 설명이 포함되어 있습니다.

계산 스키마 정의 SAP

단계 3)

  1. 변경하려는 스키마를 클릭하세요.
  2. Double 제어 데이터 노드를 클릭합니다.

계산 스키마 정의 SAP

단계 4) 다음 조건 유형 표(참조 단계)는 이 계산 스키마에서 사용됩니다. 이 계산 스키마에 설정할 수 있는 조건 유형에 대한 여러 옵션이 있습니다(다른 계산 스키마에서 동일한 조건 유형에 대해 다른 설정을 설정할 수 있음). 간단한 설명이 있는 가능한 옵션 목록:

  1. 단계 (절차의 순서를 나타냅니다)
  2. 계수기 (단계의 조건 수 계산)
  3. 조건 유형 (이미 정의된 조건 유형 중 하나 – 이전 주제)
  4. 이와 같은 서비스: (백분율 조건을 계산하기 위한 기준으로 사용되는 참조 단계)
  5. (어떤 단계까지 조건을 백분율 조건 계산의 기준으로 사용해야 하는지)
  6. Manual (수동으로 입력 가능)
  7. 필수 (필수조건)
  8. 통계 (통계적 조건만 해당)
  9. 인쇄 (조건에 따른 인쇄 제어)
  10. 소계 (소계 계산 방법)
  11. 요구 사항 (요구사항에 대한 사용자 정의 루틴)
  12. CalType (루틴 계산 – 사용자 정의 루틴이 필요한 경우)
  13. BasType (기본 조건 값에 대한 사용자 정의 루틴)
  14. AccKey (G/L 계정 키)
  15. AccrualAccKey (발생 또는 충당금에 대한 G/L 계정 키)

계산 스키마 정의 SAP

절차의 모든 조건에 올바른 설정을 적용한 후 거래 데이터를 저장할 수 있습니다.

⚠️ 경고: 표준을 절대 수정하지 마세요 SAP RM0000과 같은 스키마를 직접 복사합니다. 고객 범위 내의 이름으로 복사한 다음 복사본을 변경합니다. 표준 스키마는 지원 팩에 의해 덮어쓰여질 수 있으며, 이 경우 사용자 구성도 함께 삭제됩니다.

통계 조건, 소계 및 계정 키

위의 15개 열 중 3개 열이 실제로 가장 많은 혼란을 야기하는데, 그 이유는 해당 열들이 숫자의 본질이 아니라 숫자가 수행하는 기능을 바꾸기 때문입니다.

통계. 통계 조건은 계산되어 표시되지만 순 가치에 더해지거나 회계에 반영되지 않습니다. 단지 정보 제공 목적으로만 존재합니다. 일반적인 예로는 참고용으로 표시되는 현금 할인, 예상 운송비, 또는 실제 지불액을 비교하는 데 사용되는 시장 가격 등이 있습니다. 실제 비용에 통계 항목을 체크하는 것은 흔한 설정 오류인데, 이 경우 해당 금액이 주문 금액에서 조용히 사라지기 때문입니다.

소계. 이 필드는 해당 단계의 누적 합계를 특정 필드에 저장하여 이후 단계나 보고서에서 참조할 수 있도록 합니다. 예를 들어, 값 9는 유효 가격 기준으로 사용되는 필드에 기록됩니다. 소계가 없으면 중간 수치가 계산된 후 손실되므로 이후의 백분율 계산에서 참조할 항목이 없게 됩니다.

계정 키. 이 키는 자동 계정 결정 기능을 통해 계산된 금액을 일반 원장 계정에 매핑합니다. 운송비는 재고가 아닌 운송비 정산 계정에 기록되고, 할인은 재고 가치를 직접 차감합니다. 청구가 예상되지만 아직 청구되지 않은 경우, 발생주의 계정 키는 대신 충당금을 생성합니다.

계정 키가 없는 조건은 순 주문 금액에 영향을 미치지만, 거래 내역을 기록할 곳이 없습니다. 이는 단순히 가격을 낮추는 할인에는 필요한 기능이지만, 배송비에는 바람직하지 않은 기능입니다.

방법 SAP 계산 방식을 결정합니다.

구매자가 스키마를 선택하는 것이 아닙니다. SAP 구매 주문서가 생성될 때 세 가지 마스터 데이터 값을 조합하여 자동으로 도출합니다.

  1. 벤더의 스키마 그룹. 벤더 마스터의 구매 데이터를 기반으로 저장되는 이 정보는 국내산과 수입산처럼 가격 책정 행태가 유사한 공급업체를 그룹화합니다.
  2. 구매 조직의 스키마 그룹. 각 구매 조직에 맞게 사용자 정의 설정에서 할당되는 이 기능은 가격이 다른 조달 단위를 구분합니다.
  3. 스키마 결정 테이블. 두 그룹을 합치면 정확히 하나의 계산 스키마가 지정됩니다. 두 그룹 중 하나라도 변경되면 다른 스키마가 적용됩니다.

실질적인 결과는 가격 문제가 실제로는 가격 문제가 아닌 경우가 많다는 것입니다. 특정 조건 유형이 주문서에 나타나지 않을 경우, 가장 먼저 공급업체가 해당 조건 유형을 포함하는 스키마로 이어지는 스키마 그룹을 보유하고 있는지 확인합니다. 해당 구성은 다음에서 다룹니다. 정의 스키마 그룹.

Standard SAP 제공 RM0000 참조 구매 스키마는 총 가격(PB00 및 PBXX), 할인, 할증료, 운송비, 그리고 실효 가격을 산출하는 소계를 포함합니다. RM0000을 복사하고 복사본을 조정하는 것이 모든 프로젝트의 일반적인 시작점입니다. 더 자세한 구성 순서는 전체 문서에서 다룹니다. SAP MM 튜토리얼 시리즈.

자주 묻는 질문

단계는 계산 순서를 결정합니다. 카운터는 동일한 단계를 차지하는 여러 조건 유형을 구분합니다. 예를 들어, 하나만 적용되는 대체 할인 등이 있습니다.

해당 줄에 통계 플래그가 선택되어 있습니다. 통계 조건은 정보 제공 목적으로만 표시되며, 순값을 변경하거나 회계에 반영하지 않습니다.

AI trac문서 가격이 그렇게 책정된 이유를 설명하고, 적용된 스키마를 예상 조건과 비교하고, 편차를 발생시킨 단계를 명시함으로써 구성 디버깅 시간을 단축합니다.

예. 게시된 문서를 분석하면 어떤 조건이 전혀 값을 갖지 않는지 알 수 있습니다. 사용되지 않는 단계를 제거하면 절차가 간소화되고 향후 구성 오류 발생 가능성이 줄어듭니다.

네, 그리고 제어 설정은 각 스키마마다 다를 수 있습니다. 동일한 운송 조건이 한 스키마에서는 요구되고 다른 스키마에서는 통계적으로 요구될 수 있는데, 이는 플래그가 조건 유형이 아닌 스키마 라인에 있기 때문입니다.

이 게시물을 요약하면 다음과 같습니다.