키자드에 등록된 sapfcmhub의 네이버 블로그 포스트 목록

sapfcmhub의 등록된 링크

sapfcmhub로 등록된 네이버 블로그 포스트 수는 207건입니다.

제품 원가계산(Product Costing) : 제품 생산 오더 투입/생/정산 흐름 [내부링크]

제품 생산 오더에 재료비/가공비 투입 및 가격 차이 정산을 통한 자재 원장 수불 결산의 흐름 개요 표준원가를 사용하는 제품을 생산하기 위해 투입된 원재료/가공비를 감안하여 월중 흐름 및 월말 결산 흐름에 대한 정보이다. 원재료 수불 월중 흐름 월표준원가를 채택한 원재료에 대해서 월중에는 표준원가를 기준으로 수불이 발생한다. 그리고, 송장 정산 과정에서 가격 차이 금액이 집계된다. 월말 결산 자재 원장 결산 과정을 통해 월중 해당 원재료가 출고된 제품 생산 오더 이력을 따라 제품의 가격 차이로 정산된다. 생산 오더 월중 흐름 표준원가로 평가된 원재료가 원재료비가 되어 생산 오더에 투입된다. 가공비는 액티비티 유형의 계획 단가와 액티비티 실제 수량을 기준으로 계산되어 생산 오더에 투입된다. 월말 결산 제조 경비 마감 후 재계산된 가공비 (실제 단가 - 계획 단가) * 액티비티 실제 수량만큼 생산 오더에 추가 투입된다. 오더 정산 과정을 거쳐 발생한 생산 오더 차변/대변의 Balance

제품 원가계산(Product Costing) : 상품 구매 오더 구매/정산 흐름 [내부링크]

표준원가 또는 이동평균 채택한 경우, 구매 오더 발생 및 정산 과정 흐름 개요 상품의 경우는 표준원가 또는 이동평균을 선택적으로 적용할 수 있다. 각 경우에 따라서 발생하는 거래 분개가 다를 수 있고, 표준원가를 채택한 경우에는 월말 결산 과정이 필요하다. 상품 수불 (표준원가) 월중 흐름 표준원가로 설정한 금액 기준으로 구매 입고가 처리되고, 송장 처리 시점에 가격 차이 금액이 추가될 수 있다. 월말 결산 월중에 발생한 가격 차이 금액은 자재 원장 결산 과정을 거쳐 출고/기말 수량 기준으로 Allocation 된다. 상품 수불 (이동평균) 월중 흐름 이동평균의 경우, 매입 시점마다 재고금액의 단가가 재 결정된다. 재고금액의 단가는 현재 재고금액 ÷ 현재 재고수량으로 반영된다. 입고 시점과 송장 시점에 가격 차이가 발생하더라도 가격 차이 계정으로 반영되지 않고, 상품 재고 계정에 가감하여 반영된다. 월말 결산 이동평균 방식을 채택한 자재의 경우는, 월중에 실시간으로 실제원가가 계산되

240505 - 대형 벤츠 지바겐 전동 AMG G63 RC카 [내부링크]

바퀴가 작은 대신 덩치가 커진 RC 카 스무쓰하게 전후좌우 조용한 것이 특징

240505 - 미니 사이즈의 오프로드 험머 H2 RC카 [내부링크]

RC카에 흥미가 생긴 아이 선물 군데 군데 부딪힘을 생각해서 물렁한 바퀴가 필요했다.

240505 - 러시아워 주니어 교통정리 퍼즐게임 [내부링크]

현재는 미개봉 상태 생각이 필요한 아이스크림 자동차 탈출 놀이

제품 원가계산(Product Costing) : 자재 전기 기간(Material Posting Period) [내부링크]

Material 입력을 동반한 재고자산 이동 거래의 허용 기간 개요 SAP 에서는 Material Movement 문서를 원천으로 하는 Accounting 문서가 있고, Material Movement 와 무관한 Finance 영역의 Accounting 문서가 존재한다. 기본적으로 Material Movement 는 수량을 근거로 Material 의 이동을 기록하는 구조이고, SAP 에서는 당월과 최대 전월까지의 전표 Posting 만을 허용하고 있다. 자재 조회 아래는 Material Master 화면으로 MM03 (트랜잭션) 을 통해 접근할 수 있다. 이중에서 Costing2 View 의 화면이고, Current period 칼럼 우측에 현재 Open 된 자재 기간이 2024년 5월인 것을 확인할 수 있다. 이전 기간에 대한 전기 허용 MMRV (트랜잭션) 은 현재 Open 된 자재 기간 및 이전 기간에 대해서 Posting 을 허용할지 여부를 선택할 수 있다. Current P

제품 원가계산(Product Costing) : 제조원가 및 제품원가 흐름(Manufacturing Cost & Product Cost Flow) [내부링크]

계획 재료비/가공비의 발생부터 실제 재료비/가공비로 정산되는 각 마스터와 트랜잭션 데이터의 흐름 개요 SAP 원가회계에서 재료비와 가공비의 발생부터 실제원가로 정산되는 과정을 일련의 자료 예시를 통해서 알아보자. SCM 의 각 영역 그리고 재무회계로부터 발생하는 데이터가 원가회계 영역에서 데이터가 집계되고, 집계된 데이터는 분할 구조와 자재 원장 정산 과정을 통해 자재의 실제원가가 확정 되어진다. 본 과정의 가공비 정산은 생산 오더에 반영되지 않고, 자재 원장에 직접 반영되는 방식으로 나타내었다. 자세한 흐름은 아래 표에 정리되었기 때문에, 각 단계에서 다루는 의미에 대해서 주로 살펴보자. 분할 구조 분할 구조에서는 계정과 연관이 있는 각 액티비티 유형과의 연계성을 기준으로 예시에서는 기계시간과 노무시간으로 구분하였다. 그리하여 이러한 내용을 분할 구조로 일컬으며, 각 제조 코스트센터의 유형 별로 다르게 설정할 수 있겠다. 관리 원장 관리 원장은 관리회계 영역의 데이터가 관리되는 전

240427 - 에어하키 슈팅배틀에어하키게임 오락실 보드게임 [내부링크]

어린이날을 즈음하여 준비한 스포츠 게임 바람이 솔솔 나오니 퍽이 이리저리 잘 움직인다. 이런 게임 취향에 잘 맞을까

제품 원가계산(Product Costing) : 구매 계정 활성화(Activate Purchase Account) [내부링크]

구매 오더를 통한 입고/송장 처리 시, 재고 계정 외 당기 매입액을 별도로 기표 가능한 구매 계정 설정 기능 개요 아래 국가는 구매 계정 활성화를 통한 전표 기표가 필요한 국가 정보이다. 이 부분은 Local Regulation 사항으로 판단된다. Belgium Spain Portugal France Italy Finland 다만, 필요한 경우 SPRO (트랜잭션) 에서 아래 Configuration 을 통해서 기능을 활성화할 수 있다. ㄴ Activate Purchase Account in Company Code ㄴ Calculation of Value for Purchase Account Activate Purchase Account in Company Code 회사코드 단위로 구매 계정 사용을 활성화할지 여부를 선택할 수 있다. Calculation of Value for Purchase Account Recpt val (Post purchase account with rece

제품 원가계산(Product Costing) : 액티비티 단가 흐름(Activity Price Flow) [내부링크]

수량 단위를 측정할 수 있고, 이를 기준으로 비용과 연관성을 갖고 가공비를 부과할 수 있는 기준정보의 관리 개요 액티비티 유형 마스터를 기준으로 가공비를 부과할 수 있다. 이러한 액티비티 유형 마스터는 수량을 측정할 수 있는 단위로 정의하며, 각 액티비티 유형 마스터는 코스트센터에서 발생한 계정의 비용과 연계성을 갖고 있어야 한다. 적절한 연계성이 없다면, 발생 비용을 액티비티 수량 값을 기준으로 분할할 수 있다. 분할 구조 비용이 발생하는 코스트센터를 기준으로 코스트센터에서 발생하는 각 계정을 연관된 수량 활동 단위에 연결하는 구조를 의미한다. 아래의 예시처럼 특정 계정을 특정 액티비티 타입과 1:1 로 분할할 수 있고, 특정 계정을 2개 이상의 액티비티 타입에 특정 기준으로 분할을 적용할 수도 있다. 해당 비용의 발생하는 요인이 특정 액티비티 타입에 기인한 것이라고 판단할 수 있을 때, 아래와 같이 지정할 수 있겠다. 분할 구조는 일종의 기준정보의 역할을 수행하고 있고, 분할 구

채무(Accounts Payable) : 외화 환산손익(Gain/Loss from Exchange Rate Differences) [내부링크]

Balance 가 관리되는 G/L Account 에 대해 거래 발생/종결 시점의 환율 차이를 환산 손익으로 평가하여 기록 개요 주로 Open Items 항목으로 관리되는 회계 거래 기준으로, 거래가 발생하는 시점과 거래가 종결되는 시점의 환율 차이가 존재할 수 있다. 이러한 경우, 거래 종결 시점에 외화 환산 손익을 식별할 수 있다. 다른 개념으로 거래가 종결 되지 않은 시점이라면 해당 평가일 기준으로 외화 평가 손익을 발생시킬 수 있다. 그리고 이번에는 예시적으로 Supplier Incoming Invoice 를 기준으로 이러한 거래 형태를 확인해보자. Exchange Rate 거래 통화는 ERU 이고 회사코드 통화는 USD 인 상태에서 각 거래일 별로 다른 환율을 가정하였다. Incoming Invoice FB60 (트랜잭션) 에서 Supplier 와의 송장을 생성하였고, 2024년 4월 1일로 Posting Date 를 지정하여 1.00 EUR 당 1.00 USD 로 환산되도록

240410 - 레고 시티 휴가용 캠핑밴 60283 [내부링크]

약속에 대한 선물용으로 한 켠에 두었던 레고 외출했다 저녁 먹자마자 아이에게 주니 잠자리에 들 기전 부리나케 조립을 시작

간접비 관리(Overhead Management) : 손익센터 & 배부(Cost Center & Distribution) [내부링크]

CO Object 가 입력되지 않는 계정에서 발생한 금액을 대상으로, 손익센터 간 배부 프로세스를 적용 개요 코스트센터나 WBS 또는 수익성 세그먼트 값이 입력되지 않은 이외의 계정 (Balance Sheet / Nonoperating Expense or Income) 계정을 대상으로 배부를 진행할 수 있다. 이 경우는, 위 CO Object 가 아닌 손익센터를 기준으로 배부가 가능하다. 그리고 기존에 여러 차례 설명된 Manage Allocations App 을 통해서, 손익센터 배부 주기 및 수행과 Result 분석기능이 제공된다. Manage Allocations Create Manage Allocations App 에서 신규 배부 주기를 생성하는 과정으로 아래와 같이 주요 Value 를 입력하였다. ㄴ Allocation Cycle : 배부 주기의 코드이다. ㄴ Allocation Context : ㄴ Cycle Description : 배부 주기의 명칭이다. ㄴ Alloca

간접비 관리(Overhead Management) : 내부 오더 예산(Internal Order Budget) [내부링크]

예산 관리가 가능한 Object 중 하나인 내부 오더를 활용한 예산 편성/집행/조정 및 레포팅 과정 개요 SAP 표준에서 제공되는 기능만을 활용하는 내부 오더를 통해서 예산 관리하는 프로세스이다. 내부 오더를 활용하면 연간 단위 예산 가용성 점검 (사용자가 가용성 점검 % 설정 가능) 을 반영할 수 있으나, 계정 별 특정 기간 별 (월/분기/반기 등) 세부적인 기능은 제한된다. 내부 오더 예산 Configuration 예산 프로파일 등록 "Maintain Budget Profile" 예산 프로파일에서는 예산 수립 기간 및 기간 범, 활성화 여부 등을 결정할 수 있다. 오더 유형 별 예산 프로파일 등록 "Maintain budget profile in order types" 에서 진행할 수 있다. 내부 오더 생성 이전에 내부 오더 생성 유형 별 예산 프로파일을 지정할 수 있다. 이후에 내부 오더 유형만을 선택하여 내부 오더를 생성하게 된다. 예산 프로파일 별 후속 조치 등록 "Defi

자산 회계(Asset Accounting) : 건설중인자산(Asset Under Construction) [내부링크]

재무회계 관점에서 건설중인자산과 본자산 코드를 생성하여 결산 회계처리 기능 제공 개요 직전 Posting 에서 WBS 라는 CO Object 를 사용한 건설중인자산 회계처리 프로세스를 알아보았다. 이어서, 건설중인자산을 재무회계 관점에서 취득 및 본자산 대체하는 프로세스에 대한 설명이다. 구분 상세 재무회계 관리회계 마스터 건설중인자산 마스터 AS01 (트랜잭션) : 자산 마스터 생성 불필요 본자산 마스터 AS01 (트랜잭션) : 자산 마스터 생성 AS01 (트랜잭션) : 자산 마스터 생성 CO Object (WBS) 불필요 CJ11 (트랜잭션) : WBS 마스터 생성 정산 규칙 AIAB (트랜잭션) : 본자산 코드 입력 CJ12 (트랜잭션) : 본자산 코드 입력 트랜 잭션 비용 전표 불필요 FB01 (트랜잭션) : 비용 전표 생성 건설중인 자산 전표 AIBU (트랜잭션) : 본자산 대체 전표 생성 CJ8G (트랜잭션) : 본자산 대체 전표 생성 건설중인자산 자산 마스터 생성 재무회

간접비 관리(Overhead Management) : 마진 분석 & 배부 유형(Margin Analysis & Allocation Type) [내부링크]

마진 분석 영역에서 사용되는 배부 유형으로, Receiver 기준으로 수익성 세그먼트 정보가 집계 개요 마진 분석은 수익성 분석과 관련된 배부 영역이다. Sender 는 OC (간접비 회계) 또는 PA (수익성 분석) 이 될 수 있고, Receiver 는 반드시 PA (수익성 분석) 이 된다. 결론적으로 수익성 분석 영역의 데이터를 집계하기 위한 목적으로 사용하는 배부 형태이다. 그리고 Allocation Context 를 Margin Analysis 를 선택한 뒤에 Allocation Type 의 Listbox 를 보면 3가지의 배부 유형이 제공되는 것을 확인할 수 있다. 3가지 유형은 Sender 데이터의 성격과 원 계정 또는 평가 계정 사용여부 등에 따라서 구분되어 진다. Top Down Distribution 이미 PA 영역에 집계된 데이터를 수익성 세그먼트 내 리시버로 비용을 배부하는 기능으로, SAP 결산 작업에서 시간이 가장 오래 소요되는 단계로 보면 된다. 센더 기준으

조직 구조(Organization Structure) [내부링크]

Public Cloud 시스템에서 Customizing 이 가능한 조직의 범위 및 최초 생성 방식의 차이점을 알아보자 Configuration Localization Toolkit (CLT) Public Cloud 시스템 내에서는 최초 시스템 환경을 설정할 때, 아래와 같은 방식으로 Building 을 진행한다. Configuration 을 하나하나 진행하는 방식이 아닌 Pre-defined 된 Steps 안에서 국가/산업에 적합한 설정 (아래 1단계 ~ 4단계) 을 선택하면, 관련된 주요 시스템 설정이 Setup 되는 방식이다. 이후부터는 SSCUI 라는 Configuration Step 을 통해 Detail 한 Configuration 를 통해 Fit-to-std 단계를 진행할 수 있다. https://www.sap.com/assetdetail/2022/09/3090548e-5b7e-0010-bca6-c68f7e60039b.html Configuration Localization

수익성 분석(Profitability Analysis) : PA 전송 구조(PA Transfer Structure) [내부링크]

SAP 의 기준정보 및 주요 개념적인 부분 위주로 글을 쓰고 있다. 이전에 문득 생각이 들었다 놓친 주제가 있는데, 오늘은 PA 전송구조에 대해서 써보고자 한다. PA Type 제한사항 일전에도 언급을 하였지만, PA 는 수익성 분석을 의미하는 CO Module 의 Sub 한 주제이다. 그리고 오늘 알아보기로한 PA 전송구조는 Costing Based (원가중심) 에서만 사용할 수 있다. PA 전송구조의 형태 PA 전송구조는, 원가요소 또는 원가요소 그룹으로 발생한 계정을 집계하여 PA Table 상 Value Field 와 Mapping 하는 구조를 의미한다. 즉, 태생적으로 Costing Based Type 안에서만 사용할 수 있는 형태이다. 우리가 경영단위 생성 시점에 Costing Based 를 최초 채택하여 사용하는 시점에 Value Field 를 다수 정의하여 생성하게 된다. Value Field 기준으로 매출/원가/비용을 분석하기로 정의한것이므로, 모든 비용이 PA 로

주요 개념(Key Concept) : 세트(Set) [내부링크]

표준 그룹 외에도 사용자가 정의하는 테이블/칼럼 기준으로 사용자 마스터 값을 관리 가능 개요 그룹과 세트는 Table 구조상 유사한 형태로 관리된다. 그럼에도 불구하고 그룹과 세트는 아래의 차이가 있다. ㄴ 그룹 : SAP 표준 트랜잭션 코드로 제공된다. ㄴ 세트 : Table 상 구조는 유사하나, 각 그룹 별 표준 트랜잭션이 존재하지 않고 사용자가 구조화를 원하는 테이블과 칼럼을 정의하여 사용할 수 있다. 세트 생성 세트는 GS01~03 (트랜잭션) 을 통해 관리할 수 있다. 위의 정형화된 그룹 관리 이외에 CBO 마스터 값들을 관리하고자 하는 경우, 세트를 새로 생성하여 그 세트에 관리하고자 하는 값들을 등록할 수 있다. CBO 마스터 테이블 자체를 만들어 기준정보를 관리하거나, 세트를 생성하여 기준정보를 관리할 수 있는데 이러한 세트는 운영 시스템에서도 유지보수가 즉시 가능하여 간편하다는 장점이 있다. GS01 (트랜잭션) 에서 사용자 정의 세트를 생성할 수 있다. 아래처럼 구

간접비 관리(Overhead Management) : 건설중인자산 - WBS(Asset Under Construction - WBS) [내부링크]

WBS 통해 발생 비용을 집계하고, 정산 기준을 등록하여 정산 수행 시 건설중인자산/본자산 대체 적용 가능 개요 CO Object 중 하나인 WBS 를 활용하여 월중에 비용 전표를 집계하고, 발생한 비용으로 건설중인자산으로 대체할 수 있다. 건설중인자산으로 정산하기 위해서는 WBS 정산을 수행해야 하고, 이후 본자산 취득시점에 자산회계 영역에서 자산 코드를 생성한 뒤에 WBS Settlement Rule 에 취득할 본자산 코드를 입력하여 정산을 수행하면 일련의 프로세스가 종료된다. 프로젝트/WBS 생성 프로젝트 생성 CJ01 (트랜잭션) 에서 프로젝트를 생성할 수 있다. 프로젝트는 전표에 실제로 입력되는 WBS 의 상위 개념이다. 하나의 프로젝트 하위에는 여러 개의 WBS 를 등록할 수 있다. 프로젝트 생성을 위해서는 사전에 정의된 Project Profile 을 선택해야 한다. 건설중인자산으로 정산하는 것이 목적이기 때문에 고정자산으로 정산이 가능한 Profile 선택하여 진행한다

기업 구조(Enterprise Structure) : 관리회계 - 손익센터 & 코스트센터(CO -Profit Center & Cost Center) [내부링크]

회사코드 하위의 사업부 단위 구분회계 목적으로 손익센터와 코스트센터를 활용 가능 개요 코스트센터와 손익센터를 관리회계 시각에서 이해할 때는 비용 중심과 이익 중심을 대비하여 고려할 수 있다. ㄴ 손익센터 : 매출에서 원가와 비용을 차감한 이익을 보고할 수 있는 최소 단위 ㄴ 코스트센터 : 비용을 집계하고 분석하는 활동을 수행할 수 있는 최소 단위 손익센터 일반적으로 관리회계에서는 손익센터를 이익을 분석할 수 있는 최소단위로 관리된다. 즉, 매출-원가-비용 = 영업이익에 대한 최소 Reporting 단위가 된다. Case 별로 다르긴 하나, 손익센터 1 : 코스트센터 1 이 될 수도 있고, 하나의 매출 관리조직 (손익센터) 하위로 여러 개의 부서 (코스트센터) 가 관리될 수도 있다. 관리회계 관점에서는 손익센터를 손익 분석의 단위로 Focus 를 먼저 맞출 수 있고, 필요할 경우 이 손익센터 View 를 BS 계정에도 확장할 수 있겠다. 코스트센터 일반적인 경우에는 회사의 Divisi

주요 개념(Key Concept) : 관리회계 오브젝트 - 주요 사례(Controlling Object - Major Case) [내부링크]

주요 사용 관점에서 코스트센터 / 수익성세그먼트/ 오더 / WBS 의 사례가 존재 코스트센터 (Cost Center) 코스트센터를 통해 Posting 이 이루어질 경우, 코스트센터는 Controlling Object 역할을 수행하게 된다. 공통적인 부분으로, FS00 (트랜잭션) 을 통해 생성된 PL 계정에 원가요소 범주정보가 있을 경우 Controlling Object 는 필수 입력사항이다. 즉 원가요소 범주를 입력한 것은 원가요소로 관리한다는 의미이고 원가요소로 관리한다는 의미는 Controlling Object 로 결정짓는 요인이 된다. 단, 코스트센터는 비용 Posting 이 주요 목적인 Obejct 인데 반해 아래 Controlling Object 의 경우 비용/수익을 모두 Posting 하는 역할이다. (기능적으로 코스트센터도 수익을 Posting 할 수 있으나 일반적이지는 않다) 수익성세그먼트 (Profitability Segment) 수익성세그먼트는 수익성 분석 관점에

240208 - Dickie toys 디키 트럭 시리즈 보트 플레이 세트 [내부링크]

자동차 장난감에 대한 흥미는 이제 미지근 이런건 어떨까? 길다랗고 보트가 얹어진 모습

The blog topics to be registered in the future [내부링크]

Blog Posting Topic 추천은 Comment 로 남겨주세요. 관리회계 진행 WBS 에 전표 발생 및 정산 건설중인 자산에 대한 전표 발생 및 정산 - CO Object 활용 완료 코스트센터 회사 간 배부 관리회계 조직 구성 재무회계 진행 건설중인 자산의 집계 및 정산 - Fixed Asset 활용 재무 송장 및 지급 반제 완료 재무 송장 및 입금 반제

간접비 관리(Overhead Management) : 코스트센터 & 회사간 배부(Cost Center & Intercompany Allocation) [내부링크]

동일 관리회계영역 내에서 발생한 공통비를 서로 다른 회사코드간에 배부하는 기능 Manage Allocations Cycle Header Cost Center 에서 발생한 비용을 배부하기 위해서 아래와 같이 속성을 선택하고 Cycle 을 생성한다. ㄴ Allocation Context : Cost Centers (코스트센터 간 배부) ㄴ Allocation Type : Intercompany Allocation (회사간 배부) ㄴ Ledger : 0L (0L 원장 데이터 배부) ㄴ Actual/Plan : Actual (실적 데이터 배부) Segment - Rules 회사간 배부의 경우에는 Distribution 방식 (1차 원가요소 배부) 와는 다르게 2차 원가요소를 활용한 배부가 필수적으로 적용된다. 테스트의 편의상, Allocation Structure 를 적용하지 않고, 특정 2차 원가요소를 선택하였다. Segment - Senders Cycle 을 Header 정보를 위와 같

기업 구조(Enterprise Structure) : 관리회계 조직(Controlling Organization) [내부링크]

관리회계에서 주로 논의되는 조직으로, 경영단위, 관리회계 영역, 손익센터, 코스트센터의 각 특징 요약 경영단위 & 관리회계 영역 경영단위는 예외없이 1개로 관리된다. 보통은 수익성분석 (손익계산서) 데이터를 집계하여 Reporting 할 수 있는 최상위 조직 Level 이다. 즉, 관리회계에서 집계한 모든 데이터가 관리되는 조직 Level 로 볼 수 있다. 경영단위를 Setting 한다는 것은, 프로젝트 초기에 수익성 분석 목적의( 분석 관점과 분석 지표) 를 Define 하는 것으로 시작하게 된다. 회계 전표 데이터가 관리되는 ACDOCA (테이블) 및 CEXXXX (테이블) Structure 와 연동되기 때문에, 최초 설정한 이후에는 추가는 가능할 것으로 보이나 Operation 단계에서는 쉽지 않을 것으로 보인다. 경영단위는 하위에 관리회계 영역과 1:1 또는 1:N 으로 Assign 되는 구조이다. 기술적으로 모든 관리회계 영역은 1개의 경영단위와 연결되어야 하므로 특이사항은

제품 원가계산(Product Costing) : 자재 원장 가공비 재평가 흐름(Processing Cost in the Material Ledger Flow) [내부링크]

월 중에 계획 단가로 계산된 가공비는 월말에 실제 단가만 계산하고 생산 오더 정산 후에 자재원장 전표로 반영 개요 월 중에는 코스트센터와 액티비티 유형에 등록된 계획 단가 기준으로 투입되었다가, 월말 코스트센터 실적 집계 종료 이후에 실제 가공비 단가가 계산되고 (생산 오더 정산 후 자재 원장 과정에서) 추가 가공비 기표까지 완료하는 방식이다. Event Based Settlement > 실제원가 분할 (KSS2) > 가공비에 대한 실제 단가 계산 (KSII) > > 자재원장 정산 (CKMLCP) 순으로 진행할 수 있다. 이 방안은 Public Cloud 에서 제공되는 Event Based Settlement 시나리오와도 관련이 있다. Event Based Production Order 를 사용하면 별도의 Settlement (KO88, CO88) 과정 없이, 생산 오더에 투입 즉시 재공품 또는 Variance 가 계산되는 방식이다. 가공비 추가 기표 분을 생산 오더 정산 전에 반영

자산회계(Asset Accounting) : 고정자산(Fixed Assets) [내부링크]

유무형 자산 취득 및 감가상각 수행 이전에 자산 마스터를 생성하는 과정으로 이에 대한 기준정보가 사전 관리 Create Main Asset Create 버튼을 눌러 신규 Asset 생성을 진행할 수 있고, Asset Class 라는 자산 유형 선택이 필수적이다. Asset Class 선택 이후 해당 코드를 기준으로 Account Determination 이 결정된다. Header Data General/Inventory Data : 해당 자산의 공통 속성 정보를 입력하는 것으로 Text 및 자산 클래스 정보가 조회된다. 이전 단계에서 입력한 자산 클래스를 기준으로 연결된 Account Determination 코드인 160010 이 조회되는 것을 확인할 수 있다. Time-Dependent Data : 공통 속성 정보와 더불어 필수로 입력되어야 하는 정보로, Cost Center 나 WBS 등이 입력될 수 있다. 입력된 Cost Object 단위로 이후 감가상각 수행 시 비용이 집계

일반 회계(General Ledger Accounting) : 전표 분할(Document Splitting) [내부링크]

전표에 코스트센터를 입력하여 손익센터 별 구분회계 데이터 산출을 위한 Document Splitting 기능 공급업체 전표 생성 우선 FB60 (트랜잭션) 을 활용하여 Vendor Incoming Invoices 를 생성한다. 서로 다른 코스트센터를 입력하였고, 각 코스트센터는 서로 다른 Profit Center 로 입력되어있다. 전표 조회 - Entry View 그리고 생성된 전표를 보면, Cost Center 에 연결된 Profit Center 정보가 함께 조회된 것을 확인할 수 있다. 차변 : Expense 500.00 - Cost Center1 (ZBU1000), Profit Center (ZBU1) 차변 : Expense 500.00 - Cost Center2 (ZBU2000), Profit Center (ZBU2) 대변 : Supplier 1,000.00 전표 조회 - General Ledger View Leger View 로 전환하여 조회해보면, 국외 채무에 해당하는 2

주요 개념(Key Concept) : 관리회계 아키텍처(Controlling Architecture) [내부링크]

SAP 시스템 내 타 Module 과의 Integration 및 집계 데이터를 기반의 운영/결산 데이터 Flow 한글 버전 영문 버전

주요 개념(Key Concept) : 재무회계 아키텍처(Financial Accounting Architecture) [내부링크]

SAP 기반 재무회계 일반적인 데이터 흐름에 대한 마스터 데이터와 트랜잭션 연계 구조 한글 버전 영문 버전

간접비 관리(Overhead Management) : 누적 & 비누적 배부(Cumulative & Non-Cumulative Allocation) [내부링크]

당월 발생 비용을 당월 기준으로 배부하거나, 누적 발생 비용을 누적 기준으로 배부할 수 있는 기능 개요 당월 발생한 비용이나 배부 비율이 특정 기간에만 그 차이가 큰 경우에 누적 배부 기능을 활용하면, 당월에만 특별히 영향받은 요인을 감소시킬 수 있다. 누적 배부 우선 리시버인 코스트센터1 기준으로 24년 1월~3월까지의 누적 배부 금액이다. 24년 1월 배부 : ㄴ 1월 누적 비용 (600) x 1월 누적 비중 (3 ÷ 7) = 257 24년 2월 배부 : [2월 누적 비용 (1,100) x 2월 누적 비중 (8 ÷ 23)] - 1월 배부 (257) = 125 24년 3월 배부 : 3월 누적 비용 (2,100) x 3월 누적 비중 (9 ÷ 36) - 2월 배부 (125) - 1월 배부 (257) = 142 비누적 배부 우선 리시버인 코스트센터1 기준으로 24년 1월~3월까지의 비누적 배부 금액이다. 누적 배부 방식과 비교할 때, 최초 기간의 배부 결과는 동일하나 이후 기간부터 배부

간접비 관리(Overhead Management) : 반복 배부(Iterative Allocation) [내부링크]

공통비 배부 과정에서 Sender 와 Receiver 에 동일 Cost Object 가 존재하는 경우, 반복 배부 기능 개요 반복 배부는, Receiver 가 Sender 에도 포함되는 상황이고 일반적인 배부 구조로 보기는 어려울 것 같다. Sender 가 가지고 있는 금액의 잔액이 최종적으로 0 이 될 때까지 배부하는 Concept 으로, 최종 배부 금액이 어떻게 산정되었는가에 대한 추적성이 상대적으로 떨어져 보인다. 다만, 기능적인 관점에서 어떤 구조로 작동하는 지 결과 관점에서 확인해볼 수 있겠다. 1차 배부 ZSENDER 코스트센터에서 발생한 1,000.00 원을 RECEIVER1/2/3 코스트센터로 배부하는 시나리오이다. 특이사항은 ZRECEIVER1 코스트센터가 SENDER 와 RECEIVER 에 등록된 상황이다. 실제로 배부 전표는 한 번에 생성되나, 원활한 도식화를 위해 1차와 2차로 구분하였다. 1차 배부에서는 ZSENDER 코스트센터 비용 1,000 원이 각 20%

수익성 분석(Profitability Analysis) : 재조정 유지보수(Maintain Realignment) [내부링크]

수익성 세그먼트에 입력된 특성치 Value 에 대한 대량 변경 기능 개요 재전기 방식으로 개별 전표의 특성치를 변경하는 전표를 발생시키는 방안을 사용하거나, 이번처럼 특정 조건에 만족하는 값들을 일괄 추출하여 Mass 로 그 Value 를 변경하는 방안을 채택할 수도 있다. Display Line Items - Margin Analysis 변경 전의 Document 정보로 Product Sold 칼럼의 Value 는 TG12 로 입력되어 있다. 재조정 유지보수 실행 이후에 값을 미리 확인해보자면, 동일 칼럼의 Value 가 TG11로 변경되어 있다. 동일 전표이나 특정 칼럼의 Value 만 변경된 상태이다. Run Realignment - Profitability Analysis KEND (트랜잭션) 을 통해서 실행하거나, 또는 Fiori 에서는 위 키워드로도 App 을 검색하여 실행할 수 있다. 재조정 실행 생성 (Create Realignment run) "Realignment

채무(Accounts Payable) : 공급업체 송장 엑셀 업로드(Supplier Invoices Excel Upload) [내부링크]

Fiori 에서 사전에 제공되는 Excel Template 을 활용한 Supplier 인보이스 대량 업로드 기능 개요 일반 전표 엑셀 업로드 : 조정 계정 외 BS 계정과 PL 계정이 대상 고객 송장 엑셀 업로드 : 고객 코드를 기준으로 Invoices 를 발생 공급업체 송장 엑셀 업로드 : 공급업체 코드를 기준으로 Invoices 를 발생 Create Incoming Invoices Finance 영역에서 Supplier 별로 Invoice 를 개별로 생성할 수 있다. Create Supplier Invoice Procurement 영역에서 Supplier 별로 Invoice 를 개별로 생성할 수 있다. Purchase Order 에 대한 Invoice 처리 App 이다. Import Supplier Invoices Excel Template 을 활용하여 대량 업로드가 가능하다. 전반적으로 Excel Template 작성 방식은 Customer Invoice 와 유사하다. 특이사항

채권(Accounts Receivable) : 고객 송장 엑셀 업로드(Customer Invoices Excel Upload) [내부링크]

Fiori 에서 사전에 제공되는 Excel Template 을 활용한 Customer 인보이스 대량 업로드 기능 개요 일반 전표 엑셀 업로드 : 조정 계정 외 BS 계정과 PL 계정이 대상 고객 송장 엑셀 업로드 : 고객 코드를 기준으로 Invoices 를 발생 공급업체 송장 엑셀 업로드 : 공급업체 코드를 기준으로 Invoices 를 발생 Create Outgoing Invoices Customer 를 입력하고 전표 처리가 가능한 App 이다. Upload Customer Open Items 위의 Genral Journal 업로드 양식과 비교하면 헤더와 아이템이 위/아래가 아닌 좌우로 배치되어 있다. 그렇기 때문에, Line Item 의 Sum 이 Header 의 금액 Sum 이 되도록 작성해야 한다. 특이사항1. Excel Template 를 활용하여 대량 데이터 처리가 가능하나, 엑셀 건 수 기준으로 2,000 건만 가능하다. 특이사항2. Upload 직후 전표 Post 를 하

채무(Accounts Payable) : 공급업체 송장 결재 라인(Supplier Invoices Approval Line) [내부링크]

Fiori 를 통해 제공되는 최종 공급업체 송장 Post 를 위한 Workflow 설정 및 상신/승인 프로세스 개요 Fiori 에서 제공하는 Workflow (결재 상신/승인) 제공 리스트 유형이다. 일반 전표에 대한 Worklow 의 설정 공급업체 송장에 대한 Workflow 의 설정 자동지급 전표에 대한 Workflow 의 설정 고객 송장에 대한 Workflow 의 설정 - 미제공 Configuration (SSCUI) Supplier Invoice 에 대한 Workflow 활성화를 위한 Configuration (SSCUI) 를 설정한다. ㄴ Activate Flexible Workflow for Supplier Invoices Manage Workflows for Supplier Invoices 위 App 에서 Workflow 의 활성화 여부와 적용 순서 그리고 각 Workflow 별로 이벤트가 활성화되는 Condition 과 수신자를 설정할 수 있다. Park Supplie

채무(Accounts Payable) : 자동 지급 결재 라인(Automatic Payment Approval Line) [내부링크]

Fiori 에서 제공하는 기능으로, 자동 지급 전표 생성 이후 승인을 통해 Payment Media 파일이 최종 생성된다. 개요 Fiori 에서 제공하는 Workflow (결재 상신/승인) 제공 리스트 유형이다. 그 중에 자동 지급에 대한 기능으로, GUI 에서는 F110 (트랜잭션) 과 관련되어 있다. 일반 전표에 대한 Worklow 의 설정 공급업체 송장에 대한 Workflow 의 설정 자동지급 전표에 대한 Workflow 의 설정 고객 송장에 대한 Workflow 의 설정 - 미제공 Configuration (SSCUI) 자동 지급 프로세스를 위한 Approval 프로세스는 J77 과 J78 Scope Item 이 선행되어야 하고, 아래 Configuraiton (SSCUI) 가 필요하다. ㄴ Define Basic Settings ㄴ Settings for Payment Approval Processes ㄴ Create/Assign Selection Variants (Alte

기업 구조(Enterprise Structure) : 손익센터 그룹 & 표준 계층구조(Profit Center Group & Standard Hierarchy) [내부링크]

구분회계 최소 단위인 Profit Center 와 상위 Grouping 단위인 Profit Center Group 의 관계와 특징 손익센터 손익센터 생성 시점에 Profit Center Group 은 필수로 입력되어야 한다. 아래 Profit Center Group 칼럼에는 Profit Center Group 중 특별한 유형인 Stanard Hierarcy 에 해당하는 Profit Center Group 코드르 입력해야 한다. Standard Hierarchy 는 표준계층구조로 불리며, 관리회계영역 (회사코드의 상위 조직) 에 단일 값으로 지정된다. 그렇기 때문에 생성이 필요한 모든 손익센터는 관리회계영역 하위의 표준계층구조에 해당하는 Profit Center Group 중 하나에 Assign 이 되어야 한다. 표준계층구조는 관리회계영역과 동일한 Level 로 지정된 최상위 Profit Center Group 개념으로 볼 수 있다. 손익센터 그룹 본격적으로 손익센터 그룹을 만들수 있

제품 원가계산(Product Costing) : 이동평균가 변경(Change Moving Average Cost) [내부링크]

재고자산 단가 측정방법이 이동평균가인 경우, 재고자산 단가를 변경하는 방법 개요 MR21 (트랜잭션) 을 통해 재고자산의 단가 정보를 변경할 수 있고, 단가 정보 변경을 통해 재고자산 금액 변경 전표가 생성될 수 있다. Price Control 이 Moving Average 에 해당하는 경우, 별도의 Quantity Structure 가 존재하지 않는다. Price Control 재고금액 존재 MR21 (트랜잭션) 수행 결과 S (Standard Price) O 1. Material Master 의 표준원가 단가 변경 2. 재고금액 조정 전표 생성 ㄴ 차변 : 재고자산 XX ㄴ 대변 : 가격차이 발생 XX - UMB 3. 자재원장 정산 ㄴ 가격차이 정산 XX - PRY ㄴ 재고자산 또는 매출원가 XX) X 1. Material Master 의 표준원가 단가 변경 V (Moving Average) O 1. Material Master 의 이동평균 단가 변경 2. 재고금액 조정 전표 생

제품 원가계산(Product Costing) : 이동평균가 가격차이 수동 생성(Manual Creation of Moving Average Variance) [내부링크]

이동평균 방법으로 재고자산을 평가하는 경우, 사용자가 직접 가격차이 금액을 발생시키는 방법 요약 Price Control 재고금액 존재 MR22 (트랜잭션) 수행 결과 S (Standard Price) O 1. 재고금액 조정 전표 생성 ㄴ 차변 : 가격차이 발생 XX - PRD ㄴ 대변 : 가격차이 발생 XX - UMB 2. 자재원장 정산 ㄴ 차변 : 재고자산 또는 매출원가 XX ㄴ 대변 : 가격차이 정산 XX - PRY 3. 가격차이 조정 ㄴ 차변 : 가격차이 정산 XX ㄴ 대변 : AP 또는 매출원가 XX V (Moving Average) O 1. 재고금액 조정 전표 생성 ㄴ 차변 : 재고자산 XX ㄴ 대변 : 가격차이 발생 XX - UMB 2. 가격차이 조정 ㄴ 차변 : 가격차이 정산 XX ㄴ 대변 : AP 또는 매출원가 XX Manage Material Valuation (Fiori App) 개요 Fiori 에서 제공되는 Manage Material Valuation 이라는

제품 원가계산(Product Costing) : 표준원가 가격차이 수동 생성(Manual Creation of Standard Cost Variance) [내부링크]

표준원가 방법으로 재고자산을 평가하는 경우, 사용자가 직접 가격차이 금액을 발생시키는 방법 요약 Price Control 재고금액 존재 MR22 (트랜잭션) 수행 결과 S (Standard Price) O 1. 재고금액 조정 전표 생성 ㄴ 차변 : 가격차이 발생 XX - PRD ㄴ 대변 : 가격차이 발생 XX - UMB 2. 자재원장 정산 ㄴ 차변 : 재고자산 또는 매출원가 XX ㄴ 대변 : 가격차이 정산 XX - PRY 3. 가격차이 조정 ㄴ 차변 : 가격차이 정산 XX ㄴ 대변 : AP 또는 매출원가 XX V (Moving Average) O 1. 재고금액 조정 전표 생성 ㄴ 차변 : 재고자산 XX ㄴ 대변 : 가격차이 발생 XX - UMB 2. 가격차이 조정 ㄴ 차변 : 가격차이 정산 XX ㄴ 대변 : AP 또는 매출원가 XX Manage Material Valuation (Fiori App) 이전 Posting 을 통해 이동평균가를 사용하는 Material 을 사례를 선정하여

채권(Accounts Receivable) : 재무 송장 및 입금 반제(FI Invoies and Manual Clearing) [내부링크]

Customer 거래처와 거래에서 발생한 인보이스와 거래 종결을 의미하는 Clearing 의 처리 Create Outgoing Invoices FB70 (트랜잭션) 과 동일한 UI 로 구성된 Create Outgoing Invoices App 을 활용하여 Customer 전표를 생성할 수 있다. Basic data 에 입력한 정보는 정상 Invoice 의 경우, 차변을 구성하게 된다. Item data 영역에 입력한 정보는 Trasaction 유형에 의해 Debit 또는 Credit 이 결정된다. ㄴ 매출 거래의 경우, Sales Revenue 와 관련된 계정과 Profit Center/Profitability Segment 정보를 입력한다. ㄴ 기타 거래의 경우, Expense 계정과 Cost Center 정보 등을 입력할 수 있다. 생성된 전표는 아래와 같이 차변의 매출채권과 대변의 Sales Revenue 로 구성되어 있다. Company Code 가 USA 라면, Output

비용과 수익 요소(Cost and Revenue Element) : 수익 전기(Revenue Postings) [내부링크]

관리회계에서 수익을 인식할 수 있는 Object 단위로 수익성 세그먼트/내부오더/코스트센터 등 활용 가능 수익성세그먼트를 입력 원가요소 범주 = "11" 에 해당하는 계정을 사용하여 전표를 입력하는 경우에는 수익성세그먼트 정보를 필수로 입력하는 것이 보통이다. 이런 경우, 수익성세그먼트를 입력하지 않는다면 아래와 같이 Account Assignment 정보가 필요하다는 오류 메시지가 발생하게 된다. 내부오더를 입력 (with Revenue postings) 내부 오더는 보통 Overhead/Investment 목적 등으로 사용할 수 있다. 그럼에도 매출 계정과 내부오더를 사용하여 전표 처리를 시도한다면, 아래와 같은 오류가 발생할 수 있다. 이런 경우에는 Revenue postings 를 Check 하면, 위의 오류 없이 전표 처리가 가능하다. 다만, 위와 같은 상황에서 내부오더는 Revenue 관점에서 Real Object 가 되므로 수익성세그먼트와 동시에 입력은 불가능하기에 아래

일반 회계(General Ledger Accounting) : 주기적인 일반 전표(Recurring Journal Entry) [내부링크]

동일 차/대변 계정과 금액으로 특정 주기 별로 반복 전표 생성이 필요한 경우 사용 개요 일반 전표 (AP 제외) 를 대상으로 임대료/재산세/수수료 등의 유형에 대해서 반복하여 전표처리하는 기능이다. 따라서 계정과 금액을 동일하게, 전표 기표가 필요한 경우 Recurring 프로세스를 채택할 수 있다. 단, 공급업체와의 거래인 AP 에 대한 Recurring 프로세스를 위한 App 은 별도로 제공되고 있다. Recurring 정보 입력 아래는 Post Journal Entries App 과 동일한 Layout 을 제공하고 있는데, 최종적으로 전표 Posting 을 위한 정보를 제공하기 위한 기초 정보를 입력하게 된다. 이렇게 입력하는 차변/대변/Account Assignment/Amount 은 이후에도 동일하게 실제 전표로 Posting 되고, Date 만 변경되어 반영되는 구조이다. Recurring 주기 입력 Case1 Start Date : Start Date 를 시작으로 최초

채권(Accounts Receivable) : 마이너 결제 차이(Minor payment difference) [내부링크]

거래처와의 Open Item 금액 중, 반제 (Clearing) 금액에 미미한 차이가 있을 경우 기타 계정 처리 Minor payment difference : 원 채권금액과 입금 금액에 미세한 차이가 존재하는 상태로 반제 행위를 하는 것 Partial payment difference : 원 채권금액 중 일부 금액에 대해서만 반제 행위를 하는 것 (기존 채권 유효) Residual payment difference : 원 채권금액 중 일부 금액에 대해서만 반제 행위를 하는 것 (신규 채권 생성) Complete payment : 원 채권금액과 동일하게 완전 반제 행위를 하는 것 원 채권 전표 아래와 같이 Customer 매출채권을 생성하였고, 이 금액은 Open Item (미결 항목) 으로 관리된다. Dr) Customer 1,000 USD Cr) Sales Revenue 1,000 USD 아래 미결항목 조회 App 을 통해서 미결항목 현황을 조회할 수 있다. 현재 Clearing

채권(Accounts Receivable) : 부분 결제 차이(Partial payment difference) [내부링크]

거래처와의 Open Item 금액 중, 일부 금액만을 반제 (Clearing) 하여 미결 금액이 존재하는 상태 개요 채권의 Payment 프로세스는 금액 및 반제 방식에 따라 크게 4가지로 구분된다. Minor payment difference : 원 채권금액과 입금 금액에 미세한 차이가 존재하는 상태로 반제 행위를 하는 것 Partial payment difference : 원 채권금액 중 일부 금액에 대해서만 반제 행위를 하는 것 (기존 채권 유효) Residual payment difference : 원 채권금액 중 일부 금액에 대해서만 반제 행위를 하는 것 (신규 채권 생성) Complete payment : 원 채권금액과 동일하게 완전 반제 행위를 하는 것 원 채권 전표 아래와 같이 매출채권 Item 을 발생시켰다. Debit) 매출채권 1000.00 USD Credit) 매출 1000.00 USD 입금 반제 전표 (Partial) Partial Payment 는 원 채권금

채권(Accounts Receivable) : 잔여 결제 차이(Residual payment difference) [내부링크]

거래처와의 Open Item 금액 중, 일부 금액만을 반제 (Clearing) 하되 기존 거래는 종결 후 신규 거래로 생성 Minor payment difference : 원 채권금액과 입금 금액에 미세한 차이가 존재하는 상태로 반제 행위를 하는 것 Partial payment difference : 원 채권금액 중 일부 금액에 대해서만 반제 행위를 하는 것 (기존 채권 유효) Residual payment difference : 원 채권금액 중 일부 금액에 대해서만 반제 행위를 하는 것 (신규 채권 생성) Complete payment : 원 채권금액과 동일하게 완전 반제 행위를 하는 것 원 채권 전표 고객 매출채권을 아래와 같이 발생시켰다. Debit) 매출채권 1,000.00 USD Credit) 매출 1,000.00 USD 입금 반제 전표 (Residual) 이전의 Partial 과 비교해 보았을 때, 차이가 있는 Residual 의 경우이다. Parial 과 유사하나, 입금

채무(Accounts Payable) : 구매 오더 프로세스(Purchase Order Process) [내부링크]

공급업체 생성을 시작으로 구매 오더를 생성하여 재고 자산의 매입/송장을 처리하고, 대금 지급하는 프로세스 구매 오더 생성 GUI 기준으로는 ME21N (트랜잭션) 화면이다. Header 에 Supplier Code 등을 입력하고 Item 에는 Material 에 대한 수량과 Net Price 정보를 입력하였다. Condition 에는 입력한 Net Price 를 기반으로 각 Condition 라인이 등록되었다. 구매 오더를 통한 입고 이전 단계에서 생성된 구매 오더를 참조하여 구매 입고를 진행할 수 있다. MIGO (트랜잭션) 에 접속하여 구매 오더 번호를 입력하면 대부분의 칼럼 정보가 입력되고, Location (Plant/Storage Location) 정보를 입력한다. Post 를 선택하면, 구매 오더의 수량과 단가를 기준으로 입고 전표가 생성된다. 위 과정을 거쳐서 생성된 전표의 형태는 아래와 같다. Debit) 재고자산 1,000.00 USD Credit) GRIR 1,00

채권(Accounts Receivable) : 판매 오더 프로세스(Sales Order Process) [내부링크]

고객 매출 거래 활동으로, Sales Order 를 생성하여 재고자산 출고/매출채권 생성/대금 입금 처리 프로세스 개요 이전 구매 오더 프로세스를 통해 상품 (Trading Goods) 을 1,000.00 USD 로 입고했고 송장 처리 시점에는 500.00 USD 를 추가로 발생시켰다. 그리고 가정상 해당 거래만 존재할 경우, Material 에 대한 재고자산의 단가는 1개당 1,500.00 USD 이다. 이러한 재고자산을 Sales Order 생성을 시작으로 후속 프로세스를 진행하 수 있다. 판매 대상 자재 정보 MM03 (트랜잭션) 의 Accounting1 View 에서 확인할 수 있다. 현재 판매 예정인 Material 의 Stock 은 1개이고, 단가는 1,500.00 USD 이다. 그리고 이동평균가 방식으로 재고자산을 평가하는 방식이다. Sales Order 생성 VA01 (트랜잭션) 에서 판매 단가에 해당하는 PPR0 Condition 을 입력하고 금액은 개당 2,000.

일반 회계(General Ledger Accounting) : 환율(Exchange Rate) [내부링크]

From - To Currency 간 환율을 등록하면 외화 거래에 대해서 회사코드 통화/그룹 통화 환산 정보를 확인 가능 환율 등록 Currency Exchange Rate App 을 통해 Currency Type 별 환율 정보를 등록할 수 있다. 아래는 환율이 최종 등록된 결과 화면이다. ㄴ EUR > USD : 1.09 (Direct) ㄴ KRW > EUR : 1,411.80 (Indirect) ㄴ USD > EUR : 1.09 (Indirect) 위 환율과 별개로 환율을 개별로 등록하는 경우, 아래와 같이 등록할 수 있다. Exchange Type 은 M 을 사용하여 USD 와 KRW 간 환율을 1,300.00 으로 입력하였다. 환율을 전표 생성 시 Posting Date 를 기준으로 최종 등록된 환율이 유효하게 추출된다. 외화 거래 유형 (거래 통화 USD) 회사코드 통화는 EUR 이고, 그룹 통화는 USD 로 고정된 상황에서 거래 통화를 USD 로 입력한 경우이다. ㄴ 거래

231128 - 또봇V MINI 맥시머스V [내부링크]

아이의 요청과 관계없이 구매한 크리스마스 선물... 타요 변신 로봇의 상위호환...

주요 개념(Key Concept) : 보조 원장(Sub Ledger) [내부링크]

G/L Account 의 속성 (Recon Account for Account Group) 별 회계 원장 외 보조 원장 연동 여부가 결정 개요 기본적으로 원장 (Ledger) 이라고 하면 회사의 재무제표 생성의 기반이 되는 회계 원장을 의미한다. SAP 에서는 각 데이터가 발생하게 되는 G/L Account 단위로 보조 원장 연동 여부를 정의하게 된다. 보조 원장이 연동된다는 말은, 거래 데이터가 생성될 때 회계 원장 (General Ledger) 과 보조 원장 (Sub Ledger) 에 동시에 기록된다는 의미로 이해할 수 있다. 이러한 정보는 아래 화면 예시를 통해 확인할 수 있다. G/L Account 의 Company Code View 에서 각 계정의 속성에 보조 원장 연동 여부가 정의되어 있다. 고객 보조 원장 Accounts Receivable 거래에 대해 Business Partner (Customer) 별 상세 View 를 제공한다. Business Partner 라는

간접비 관리(Overhead Management) : 통계주요지표 값(Statistical Key Figure Values) [내부링크]

Sender 와 Receiver 간 비용 배부를 위해 기준이 되는 배부 기준 값을 전표 형태로 생성하는 기능 통계주요지표 값 Statistical Key Figure : 인원수라는 통계주요지표 마스터를 생성했다. Receiver Cost Center : ZSALES1 과 ZSALES2 코스트센터를 생성하여 Quantity 칼럼에 각 인원수에 해당하는 Value 를 입력하였다. GUI 화면에서는 KB31N (트랜잭션) 을 통해 동일한 통계주요지표 값을 생성할 수 있다. 본 Fiori 화면에서는 생성/변경/조회/역분개 과정을 한 App 을 통해서 진행할 수 있게 된다. 동일 기간에 동일 Receiver 에 대해서 전표를 여러 차례 생성할 경우, 누적금액으로 배부 비율을 구성하게 된다. 코스트센터 배부 위에서 생성한 통계주요지표 값 전표를 통해서는 CCA (코스트센터) 배부에 활용할 수 있다. Manage Allocation App 을 통해 위에서 생성한 통계주요지표 값을 적용하여 배부한

#Cloud. Downloading Fiori app information [내부링크]

Fiori App 에 대한 전반적인 정보를 아래 Link 에서 제공하고 있다. 개별 App 에 대한 정보 획득을 목적으로 여러 차례 사용할 수 있고, Scope Group 또는 Scope Item 별로 필요한 App 전체 리스트를 다운 받을 수 있다. 용이한 것은 영문과 한글로 된 명칭도 일괄 다운로드 받아볼 수 있다. 기타 Technical 정보는 필요에 따라 선택하기에도 손쉽다. 우선 아래 사이트에 접속을 먼저하고, https://fioriappslibrary.hana.ondemand.com/ SAP Fiori Apps Reference Library Explore, plan and implement SAP Fiori, the latest user experience from SAP including all relevant content for the SAP Fiori launchpad. Watch this video and find out how to get the most o

제품 원가계산(Product Costing) : 생산 오더 가공비 재평가 흐름(Processing Cost Flow in the Production order) [내부링크]

월 중에 계획 단가로 계산된 가공비는 월말에 실제 단가가 계산되면서 생산 오더 정산 전에 전표로 추가 반영 개요 월 중에는 코스트센터와 액티비티 유형에 등록된 계획 단가 기준으로 투입되었다가, 월말 코스트센터 실적 집계 종료 이후에 실제 가공비 단가가 계산되고 (생산 오더 정산 전) 추가 가공비 기표까지 완료하는 방식이다. 실제원가 분할 (KSS2) > 가공비에 대한 실제 단가 계산 (KSII) > 생산 오더 정산 (KO88, CO88H) > 자재원장 정산 (CKMLCP) 순으로 진행할 수 있다. 월중 가공비 투입 제조 코스트센터에서 발생한 이러한 가공비는, 월중에는 계획 단가 (임률) X 투입 실적 (Activity Type 수량) 을 기반으로 제조 코스트센터 실적에서 차감되면서 생산 오더 등으로 투입되는 구조이다. Debit) Activity Type (생산 오더) XX Credit) Activiy Type (코스트센터) XX 월말 가공비 정산 월말 제조 코스트센터로 배부/재전기

제품 원가계산(Product Costing) : 직접 액티비티 배부(Direct Activity Allocation) [내부링크]

사전에 정의된 Cost Center 별 Activity Type 의 계획 단가를 활용하여 입력 수량만큼 가공비를 투입 개요 가공비 실적 반영하려면, 생산 영역에서 CO11N (트랜잭션) 등을 통해서 발생시키는 것이 일반적이다. 이외에 CO 에서 제공하는 트랜잭션을 통해서 Activity Type 수량과 가공비 계획 단가를 근거로 가공비 실적 전표를 생성할 수 있다. 이번 사례는 코스트센터에서 생산 오더로 직접 액티비티를 배부하는 경우이다. 액티비티 투입 KB21N (트랜잭션) 트랜잭션을 통해 가공비를 투입할 수 있다. Screen Variant 를 통해 생산 오더를 Receiver 로 지정할 수 있도록 하자. Sender CCtr : 센더 코스트센터를 의미한다. SAty Typ : Activity Type 을 의미하는 것으로, 앞서 입력한 센더 코스트센터와의 조합으로 활용될 수 있다. Total Quantity : 센더 코스트센터와 센더 액티비티 유형에 사전 입력된 계획 단가와 여기

240101- 랩앤툴스 캔디 타이머 [내부링크]

시간과 숫자 측정 세계에 빠진 아이를 위한 최고의 선물 - 타이머

일반 회계(General Ledger Accounting) : G/L 계정-총계정원장 뷰(General Ledger Account-Chart of Accounts View) [내부링크]

G/L Account 마스터에서 조직 (회사코드/관리회계영역) 종속성 없는 계정 고유의 General 정보 관리 Basic Information > Control > G/L Account TYPE 가능한 기술적인 속성이 제외된 내용으로 이해할 수 있는 계정의 유형이다. 크게 보면 Balance Sheet Account 와 Profit & Loss Account 로 구분된다. Balance Sheet Account : 재무상태표 대상 계정을 의미하는 것으로 특정 시점의 자산/부채 잔액 측정대상이 되는 계정이다. Cash Account : Bank 계정은 Balance Sheet Account 로 지정할 수 있으나, Cash Account 를 사용하여 단일 계정으로 사용할 수 있다. 이 때에는 House Bank 와 Account ID 를 활용하여 계좌 정보를 식별할 수 있게 된다. Nonoperating Expense or Income : P&L 대상 계정 중에서 관리회계 관리 목적

일반 회계(General Ledger Accounting) : G/L 계정-관리회계 영역 뷰(General Ledger Account-Controlling Area View) [내부링크]

S/4 HANA 에서부터 G/L Account 에 기능적으로 통합된 관리회계영역 View 하위 속성 Cost Element Category : 계정 마스터에서는 Controlling Area View 를 통해서 원가요소 범주가 관리된다. 기본적으로 G/L Account Type 이 Primary Cost or Revenue 이건 Secondary Costs 인 경우에는 원가요소 범주를 필수로 입력해야 한다. 원가요소 범주 입력을 통해서 Controlling Area 에서 해당 계정의 세부 속성을 세부적으로 관리할 수 있고, 이를 근거로 Cost/CO Object 에 입력을 관리할 수 있게 된다. https://blog.naver.com/someday84/221844550464 SAP CO 기준정보 : 원가요소(Cost Element) 원가요소 개요 원가요소는 Cost Element 로, SAP 에서 사용되는 용어이다. 재무회계에서 계정 (Gener... blog.naver.com h

일반 회계(General Ledger Accounting) : G/L 계정-회사코드 뷰(General Ledger Account-Company Code View) [내부링크]

G/L Account 속성 중 회사코드에 종속되는 Dependent View 에서 관리되는 주요 속성 CONTROL DATA > Account Control Account Currency : 해당 계정 속성에 부여되는 통화로 기본적으로는 회사코드 통화가 입력된다. 회사코드 통화 외 입력하는 경우, 해당 외화 통화로만 기표 가능하게 된다. Only Balance in Local Currency : Yes 는 회사코드 통화로만 평가되는 의미로 사용되는데, 이런 경우 외화 거래가 존재하더라도 현지 통화로만 평가되기 때문에 외화 평가에서 제외된다. Tax Category : 해당 계정으로 전표를 입력하는 경우, Tax Code (Tax Jurisdiction) 정보 입력 여부를 결정짓는 속성이다. Output Tax 또는 Input Tax 또는 둘다 또는 특정 Tax Code 를 특정할 수 있다. Posting Without Tax Allowed : Tax Cateogry 상에서 Tax 정

231013 - 대한민국지도 4절 퍼즐 [내부링크]

지도박물관 미니 퍼즐 이후로, 대형 퍼즐이 등장했다. 북한을 포함하여 무려 15 * 13

231018 - 모던하우스 뚝딱뚝딱 3D 드릴공구 놀이세트 146PCS [내부링크]

그간 없었던 새로운 놀이 만지작 거리는 공구세트가 마음에 들런지

간접비 관리(Overhead Management) : 누적 배부(Culmulative Allocation) [내부링크]

비용 배부 Cycle 에서 누적 배부 기능에 대해서 알아보자 23년 1월 재무팀에서 발생한 1,000원이 배부 대상 금액이다. 그리고 당월에 영업 1팀 ~ 영업 4팀가지 발생한 매출이 존재한다. 최초 발생 시점에는 전월이 존재하지 않음으로, 당월 배부와 누계 배부 결과가 동일하다. 즉 당월 배부 (전표) 금액과 누계 배부 (계산식) 금액이 같다. 23년 2월 비용이 발생한 2번째 월이다. 배부 대상 금액을 계산하기 위해 누계 비용 금액이 3,000원으로 집계되었다. (당월에 발생한 비용은 2,000원이지만) 그리고 배부 기준은 당월 매출이 아닌 누계 매출을 기준으로 한다. 당월 배부 금액 전표를 생성하기 위해서는 먼저 누계 배부 금액이 계산되고, 당월 배부 금액 (전표) 는 (당월 누계 배부 금액에서 전월 누계 배부 금액을 차감) 하여 결정된다.

231022 - 너프 엘리트 2.0 스펙터 워든 배틀팩 [내부링크]

스펀지총 생각했던 것보다 쎄고 그럴듯하게 실제에 가깝다. 스펀지총이지만 조심하자

#Certification. Public Cloud Edition [내부링크]

SAP Product 형태 중 Public Cloud 에 대한 Certification 이 있다. Public Cloud 가 아닌 경우 FCM 에서는 아래처럼 FI/CO Certification 이 별도로 구분되어 있다. C_TS4FI_2021 - SAP Certified Application Associate - SAP S/4HANA for Financial Accounting Associates (SAP S/4HANA 2021) C_TS4CO_2021 - SAP Certified Application Associate - SAP S/4HANA for Management Accounting Associates (SAP S/4HANA 2021) Public Cloud Edition 의 경우 과목코드 뒤에 Cloud 버전 정보가 포함되어 있고, 현재 6개월 단위로 시험코드가 갱신되어 Release 된다. 6개월 단위로 갱신되는 이유는, Public Cloud Edition 제품군이 자

231024 - 토이맨 뉴꼬마 사각블럭 3 350pcs [내부링크]

더더더 많이 필요해진 블럭 50층 아파트 이제는 가능

일반 회계(General Ledger Accounting) : 특별 G/L 지시자(Special G/L Indicator) [내부링크]

거래처 (Customer/Supplier)와의 거래 중 예외 거래를 신규 계정으로 식별하기 위한 목적으로 사용 Default Setting Business Partner 의 Company Code 속성을 보면, Reconciliation Account 가 등록되어 있고 해당 Customer 또는 Supplier 코드를 입력하여 전표를 생성하면 실제 원장에는 아래 예시처럼 Reconciliation Account 로 계정이 인식된다. Cusotomer 나 Supplier 는 보조원장에서 관리되는 Level 이고 원장에는 G/L Account 로 Level 로 집계된다. Special G/L Indicator Customer Invoice 또는 Supplier Invoice 생성 시에, Special G/L Indicator 를 선택할 수 있다. 기본적으로 Customer 또는 Supplier 마스터 데이터에 AR/AP 계정이 설정되어 있으나, Special G/L Indicator 를

간접비 관리(Overhead Management) : 코스트센터 & 1차 원가요소 배부(Cost Center & Primary Cost Element Allocation) [내부링크]

코스트센터에서 발생한 1차 원가요소를 그대로 사용하여 발생한 공통비를 하위 코스트센터로 배부 Manage Allocations Cycle Header Cost Center 에서 발생한 비용을 배부하기 위해서 아래와 같이 속성을 선택하고 Cycle 을 생성한다. ㄴ Allocation Context : Cost Centers (코스트센터 간 배부) ㄴ Allocation Type : Distribution (1차 원가요소 배부) ㄴ Ledger : 0L (0L 원장 데이터 배부) ㄴ Actual/Plan : Actual (실적 데이터 배부) Segment - Senders Cycle 을 Header 정보를 위와 같이 입력하고 실제 배부 정보는 Segment 를 생성하여 입력할 수 있다. 배부 대상이 되는 Sender 정보는 아래와 같다. ㄴ Account Number : 63003000 계정으로 지정하였고 필요 시 Interval 로 설정이 가능하다. ㄴ Cost Centers : 1

비용과 수익 요소(Cost and Revenue Element) : 원가요소 회계(Cost Element Accounting) [내부링크]

1차 원가요소를 통해 타 Module 발생 데이터 집계 / 2차 원가요소를 통해 CO Module 데이터 가공 및 정산 개요 공통적으로는, G/L Account 내에서 Cost Element Category 속성을 통해서 관리되는 것이 원가요소이다. 그리고 최근에는 원가요소라는 명칭을 많이 사용하지 않으나 여전히 Controlling Part 에서는 Data Flow 의 기초가 되는 기준정보 중 하나이다. 원칙적으로 돌아가면, 관리회계에서 Focusing 대상이되는 Account 는 Profit & Loss Account 이다. 그러므로 Profit & Loss Account 에 대해서 기술적으로 1. Revenue or Cost Element 를 선택하고 세부적으로는 2. Cost Element Category 속성을 등록하는 것이다. Revenue Element Cost Element Category 에서 (11,12) 등으로 지정한 경우에는 기본적으로 Profitability

기업 구조(Enterprise Structure) : 손익센터 할당(Profit Center Assignment) [내부링크]

구분회계 목적으로 사용되는 손익센터 정보가 관련 마스터 데이터의 입력을 통해 추출되는 Assignment 유형 Cost Center 부서 기반으로 비용을 집계하여 분석이 가능한 Object 인 코스트센터이다. 보통 Primary Cost 계정을 사용하여 전표를 입력하는 경우, 코스트센터를 사용하게 된다. 코스트센터 마스터에는 손익센터와 회사코드 정보를 필수로 입력하도록 되어 있고, 이러한 코스트센터는 대표적인 간접비를 집계하는 Object 의 역할을 하게 된다. 생성된 전표를 살펴보면 코스트센터와 손익센터 (코스트센터 마스터를 기반으로) 가 통계 목적으로 추출되었다. Internal Order 비용 관점에서 보면, 내부 오더도 간접비 집계 목적으로 사용될 수 있는 Obejct 중 하나이다. 내부 오더 마스터에도 회사코드와 손익센터를 입력할 수 칼럼이 제공되어 있다. 내부 오더를 사용하여 전표를 생성하면, 손익센터 정보가 추출된 것을 확인할 수 있다. WBS 수익이나 비용을 담는 요소

간접비 관리(Overhead Management) : 계정 할당 로직 (Account Assignment Logic) [내부링크]

전표 입력 시에 관리회계 목적으로 입력하는 Real Object 와 통계 Object 를 우선순위 용도에 맞게 사용 개요 Primary Cost or Revenue 속성의 G/L 계정을 사용하여 전표를 입력하는 경우에, Real Object 는 필수 입력 대상으로 1개를 반드시 입력해야 한다. Real Object 는 실제 전표 상 유효한 Object 역할을 하는 것으로, 이 Real Object 를 통해서 Repost 또는 Allocation 등 alue Transfer 진행이 가능하다. 반면에 Statistical Object 는 Real 과는 다르게 통계 정보의 역할만 수행하는 것으로, 통계 값을 이용해서는 Repost 나 Allocation 등 Value Transfer 진행은 제한된다. Case1. 입력 (수익성세그먼트/코스트센터) + 추출 (손익센터) Real : 수익성세그먼트 (CO-PA) * 값유형 칼럼 = 04 Statistical : 코스트센터 * 값유형 칼럼 =

자재 수불부(Material Ledger) [내부링크]

Cloud 시스템에서는 Material Ledger Settlement 또는 Posting 단계의 결과 값을 근거로 자재 수불부를 제공한다. Display Actual Costing Result Key Date : 자재원장 결산이 이루어지는 각 월의 말일을 기준으로 데이터를 조회할 수 있다. Currency Type : Company Code Currency 또는 Group 또는 Freely Defined Curreny 가 그 대상이 되고, Cloud 시스템에서는 1개의 Freely Defined Currency 만 존재할 수 있다. Valuation View : Legal Valuation 을 기본으로 제공한다. Ledger : Dual Ledger (Local 또는 IFRS) 가 존재하는 경우, Ledger 를 선택할 수 있다. Controlling Area : Cloud 시스템에서 관리회계영역은 별도로 Configuration 을 필요로 하지 않고 A000 단일 값만 존재한다.

현금흐름표(Cash Flow) [내부링크]

Cloud 에서는 현금흐름표에 대한 Report 를 제공하고 있다. 그리고 2가지 방식으로 현금흐름표를 구성할 수 있다. Cash Flow Statement - Indirect Method 간접법으로 현금흐름표를 작성하는 것으로, 아래와 같이 각 라인은 SAP 에서 제시를 해주게 된다. 각 라인 별로 구현하는 회사의 계정과목표 정책에 맞게 G/L Account 또는 재무제표 버전의 Note 정보를 Mapping 하는 방식이다. 여기서 Semantic Tag 라는 용어가 나오는데, 각 라인의 의미를 Tag 라는 Keyword 를 통해 관리하는 방식이다. 그리고 Semantic Tag 는 Finance 영역에서 재무제표 버전 Base 로 레포트를 구성하고자 할 때, 많이 사용되게 된다. 예를 들어, 관리식 손익계산서 역시 Semantic Tag 별로 라인을 정의하고 이에 대한 원천 데이터를 재무제표 버전의 각 G/L Account 또는 Note 와 연결하는 방식이다. 이러한 형태는 Pr

일반 회계(General Ledger Accounting) : 일반 전표 결재 라인 (Approval Line) [내부링크]

Cloud 에서 제공하는 Workflow 기능에 대해서 살펴보자. 보통은 개발을 통해서 상신/승인 기능을 구현하지만, Cloud 내에서는 기본 Scope 내에서 Workflow 설정 및 상신/승인 프로세스가 제공된다. 그리고 기본적으로 상신 거래의 유형을 구분하여 별도의 Workflow 를 설정하거나, 단계 별 Approver 를 거칠 수 있는 기능이 제공되어 이를 활용할 수 있겠다. 일반 전표에 대한 Worklow 의 설정 공급업체 송장에 대한 Workflow 의 설정 자동지급 전표에 대한 Workflow 의 설정 고객 송장에 대한 Workflow 의 설정 - 미제공 1. Manage Workflows for Journal Entry Verification Supplier Invoice 에서는 1개의 App 을 통해서 결재를 위한 세부 정보를 설정했으나, 일반 전표는 2개의 단계로 구분되어 있다. 이 단계에서는 결재자 정보를 제외한 Steps 의 세부 내역을 등록할 수 있다. 2.

일반 회계(General Ledger Accounting) : 일반 전표 엑셀 업로드(General Journal Entries Excel Upload) [내부링크]

Finance 영역에서 Excel 을 활용한 전표 대량 업로드 Function 이 존재한다. 일반 전표 엑셀 업로드 : 조정 계정 외 BS 계정과 PL 계정이 대상 고객 송장 엑셀 업로드 : 고객 코드를 기준으로 Invoices 를 발생 공급업체 송장 엑셀 업로드 : 공급업체 코드를 기준으로 Invoices 를 발생 Post General Journal Entries App Recon 성격이 아닌 일반 BS 와 PL 계정을 대상으로 Manual 전표를 생성할 수 있다. Upload General Journal Entries App Recon 성격이 아닌 일반 BS 와 PL 계정을 대상으로 Excel Template 기준으로 대량 전표를 생성할 수 있다. 특이사항1. 다만, Upload 건수에 제한이 존재하는데 Header 기준으로 999 전표까지 1회 업로드 가능하다. 특이사항2. 그리고 전표의 Line Item 기준으로 999 라인까지만 허용한다. 단, 이에 대한 예외사항 관리는

#Cloud. Regular update [내부링크]

SAP S/4HANA Cloud, public edition SAP 가 제공하는 Cloud Product 중 Public Edition 에 대한 글이다. 6개월 주기로 Upgrade 가 진행된다. 개인적으로 각 2202, 2208, 2302, 2308 (현재 진행 중) 버전을 경험하였다. 23(YY), 08(MM) 의 Naming Rule 을 가지고 있다. On-Prem 이나 Private 과는 다르게 Public Cloud 의 경우에는 Upgrade 가 일괄 적용된다. 각 Customer 나 Project 에 따라서 별도로 선택할수 있는 부분은 없고, SAP Roadmap 에 의해 정해진 Schedule 로 진행되게 되어 있다. 각 버전 별로, 새롭게 Release 된 기능 (신규 App 또는 신규 Process) 들이 존재하거나 기존에 존재하는 App 에 대해서 Extended 된 소소한 기능들이 제공되어 진다. 그리고 이러한 기능들은 각 Cloud 시나리오 안에 Update 되

6b5dabc8ca174fc7abdd8e883beeeb36 [내부링크]

6b5dabc8ca174fc7abdd8e883beeeb36

제품 원가계산(Product Costing) : 가격 차이 정산 - 이동평균가(Variance Settlement - Moving Average) [내부링크]

Material 의 원가가 최종 평가되기 위한 이전 과정인 Variance 정산 단계를 살펴보자. 그리고 이동평균가의 일반적인 정산 과정과 예외적인 정산의 경우의 차이점에 대해서 아래와 같이 구분할 수 있다. 일반적인 가격 차이의 정산 이동평균가는 매입 시점의 단가가 실제원가가 되는 방식으로, 여러 차례 매입이 있을 경우 (총 재고 금액 ÷ 재고 수량) 으로 이동평균 단가가 관리된다. 표준원가 방식의 Variance 와는 다르게 발생한 Variance 는 즉시 재고 금액에 반영되고, 출고되는 즉시 출고에 대한 실제원가도 확정된다. 단, 월에 서로 다른 매입 단가로 여러 차례 매입이 발생하는 경우, 각 시점에 따라 출고 단가도 다르게 발생할 수 있다. 이동평균가 방식은 제조원가 결산 과정을 거치지 않음으로, 매입 시점의 Variance 만 존재하여 재고 금액으로 반영할 수 있기 때문에 이와 같이 즉각적인 실제원가 금액 확정이 가능한 구조이다. 예외적인 가격 차이의 정산 구매 오더에 대

제품 원가계산(Product Costing) : 가격 차이 정산 - 표준원가(Variance Settlement - Standard Price) [내부링크]

이어서 표준원가의 가격 차이 정산 방법 그리고 예외적인 Case 에 대해서도 살펴보자, 일반적인 가격 차이의 정산 당월에 새롭게 Release 된 제품을 예시로 당월 수불부의 형태는 아래와 같다. 당월에 발생한 생산 과정에서 발생한 가격 차이는 출고 수량과 기말 수량 Base 로 Allocation 되어 동일 단가를 유지한다. 표준원가 방식은 월 Closing 이후에 Variance 금액을 확정할 수 있음으로, 시점 상 결산이 완료되어야 실제원가가 도출되는 구조이다. 예외적인 가격 차이의 정산 이 경우는, 가격 차이 발생 시점에 재고의 입고와 출고가 모두 발생하여 재고 수량이 없는 상태에서, 다음 달 정산 금액 (입고 금액 - 송장 금액) 이 집계된 경우이다. 1. 23년 6월의 수불부 A 구매 오더로, 23년 6월에 입고 수량 10개와 표준 원가 Base 로 입고 금액 10,000 으로 발생하였다. 입고 시점에 가격차이는 90,000 이 함께 발생하였다. 이어서 입고 수량 5개에

기업 구조(Enterprise Structure) : 경영단위(Operating Concern) [내부링크]

경영단위 개요 경영단위 (Operating Concern) 는 SAP 관리회계 상 최상위 조직 단위이다. SAP CO 에서 단독으로 관리하는 경영단위/관리회계영역의 경우는, 재무회계의 회사코드/사업영역 등과는 다르게 그 실체를 명확하게 구분하기는 쉽지 않다. 일반적으로, 수익성분석 (CO-PA) 서브 모듈 역할에서 사용된다고 인지하면 된다. 관리회계 - 경영단위와 하위 조직간 연결 구조 우선 경영단위의 쓰임을 알기 위해서 조직 간 연결관리를 간단하게 살펴보도록 하자. 경영단위는 관리회계상 최상위 조직이라고 했음으로, 경영단위 하위에는 관리회계영역이 존재한다. 그리고 관리회계영역 하위에는 회사코드가 존재한다. - 계층구조 - 회사코드 > 관리회계영역 > 경영단위 (좌측에서 우측으로 갈수록 상위 그룹) 우선, 현재까지 경험상으로 경영단위와 관리회계영역은 1:1 로 연결하여 생성하여 관리한다. Technical 관점에서는 경영단위 1 : 관리회계영역 N 으로 연결이 가능하나 실질적으로는

기업 구조(Enterprise Structure) : 관리회계영역(Contorlling Area) [내부링크]

관리회계영역 개요 관리회계영역은 Controlling Area 로 명명한다. 일반적으로는 동일한 통화 단위로 여러 개의 회사를 묶는 단위로 주로 사용된다. 기본적으로 CO 모듈상에서는 수익성분석 모듈을 제외하고는 관리회계영역이 최상위조직이면서 기본 Key 칼럼으로 사용된다. 즉, 재무회계 모듈에서는 회사코드가 Key 칼럼으로 관리되듯이 동일한 역할을 하는 것이 관리회계영역이다. 관점을 살펴보자면, 재무회계에서는 회사코드 단위로 자료를 입력하고 결과를 저장하나 관리회계에서는 관리회계영역 기준으로 자료를 입력하고 결과를 저장하는 Case 가 많다. SAP Standard 에서는 관리회계영역 기준으로 구현되는 것이 대부분이고, 별도로 개발된 프로그램에서는 관리회계영역과 회사코드 중 적절한 조직 단위로 Mix 해서 사용한다. 관리회계 - 관리회계영역과 하위 조직간 연결 구조 위에서 잠시 언급했듯이, 관리회계영역은 N개의 회사코드를 포함할 수 있고 1:1로 관리할 수도 있다. - 계층구조 -

기업 구조(Enterprise Structure) : 회사코드(Company Code) [내부링크]

회사코드 개요 회사코드는 일반적을 알고 있는데, 회사 = 법인 단위와 동일하다. 외부에 공시하는 회사 단위의 시스템 내 조직을 일컫는 용어이다. SAP 시스템 내에서 Data Input 의 기본이 되는 항목이며, 재무회계 내 모든 Data 에는 회사코드가 기본적으로 저장된다. 회사코드는 법적으로 존재하는 법인을 시스템 내 생성하는 단위이기 때문에, 실제 기준으로 생성하는 것으로 사용자의 판단 여지는 없다. 회사코드와 관리회계 조직 간 연결 구조 관리회계 내에서도 회사코드는 중요한 정보로써 필수 값으로 대부분 관리된다. 중요한 점은, 회사코드 지정 이후에 Transaction Data 가 1건이라도 발생했다면 해당 회사코드 정보는 변경이 불가하다. - 손익센터 - 동일 관리회계영역내 존재하는, 2개 이상의 회사코드를 지정하여 관리할 수 있다. - 코스트센터 - 1개의 회사코드를 지정하여 관리할 수 있다. - 내부오더/WBS - 1개의 회사코드를 지정하여 관리할 수 있다. 회사코드 생성

기업 구조(Enterprise Structure) : 사업영역(Business Area) [내부링크]

사업영역 개요 사업영역(Business Area) 은 회사코드 하위 레벨로 관리하는 회사 법인내 부문 조직 개념이다. 법적으로 하나의 회사의 경우에도, 내부적으로는 여러 사업부문을 영위하는 경우가 많다. 서로 다른 비즈니스 유형을 전개하는 경우에, 사업영역으로 이를 구분하여 관리할 수 있다. 회사내 부문 조직 구성 : 사업영역 또는 손익센터 결론적으로 사업영역은 필수가 아닌 하나의 대안의 일부이다. 사업영역을 대신하여 사용할 수 있는 손익센터 또는 손익센터 그룹도 존재한다. 손익센터는 이후에 하나의 주제로 언급을 하려고 하는데, 사업영역은 손익센터 (또는 그룹) 을 통해서 관리할 수 있다고 본다. 다만 사업영역은 재무회계 영역에서 제공하는 조직 개념이고, 손익센터는 관리회계 영역에서 제공하는 조직 개념이라 어느 한 모듈에서 단독적으로 결정하기 보다는 해당 법인의 비즈니스 형태를 판단 후 재무회계/관리회계 모듈 간 협의를 통해서 적정한 구현 Level 를 결정하는 것이 유리하다. 사업

기업 구조(Enterprise Structure) : 손익센터(Profit Center) [내부링크]

손익센터 개요 손익센터는 Profit Center 로, 관리회계 상에서는 이익중심점으로 불리는 조직 단위이다. 손익 (수익 - 원가 - 비용) 을 측정하고 관리하는 최소 단위를 의미하는 조직이다. Project 단위의 손익 측정이 아닌 경우, 조직 단위로 손익을 측정하는 경우가 많기 때문에 손익센터를 활용할 수 있다. 조금 더 간단하게 생각한다면, 매출이 발생하는 최소 단위를 손익센터로 정의하여 관리하는 경우라고 보면 된다. 손익센터 Input 프로세스 - 매출 - 매출의 시작은 영업 모듈의 판매문서(Sales Order) 와 대금청구문서(Billing Document) 이다. 영업 쪽 프로세스를 (단위 테스트 경험) 으로 보면, 판매문서(Sales Order) → 납품문서 (Delivery Document) → 출고문서 (Goods Issue Document) → 대금청구문서 (Billing Document) → 회계문서 (Accounting Document) 의 과정으로 여러 단

기업 구조(Enterprise Structure) : 코스트센터(Cost Center) [내부링크]

코스트센터 개요 코스트센터는 Cost Center 로 비용중심점의 의미를 가지고 있다. 다른 SAP 조직에 비해 직관적으로 이해를 하자면, 현재 소속 Team (인사 조직 상) 과 거의 1:1 로 동일하게 관리한다. 회계상으로는 비용을 집계하는 최소단위로, 비용전표를 처리할 때는 반드시 Cost Center 를 입력해서 비용의 귀속을 정확히 관리해야 한다. 예외적으로 비용 배부 목적으로 배부용 코스트센터를 관리하기도 하나, 특별한 상황이 아니라면 인원이 배정된 인사조직을 Default 로 하여 코스트센터를 생성하여 관리한다. 코스트센터와 손익센터 연관 관계 기본적으로 코스트센터와 손익센터는 연결되어 있고, N개의 코스트센터와 1개의 손익센터로 관리될 수 있다. 하나의 손익 분석 단위인 손익센터에 대해서, 여러 부서가 연계되어 있다면 손익센터 1개당 코스트센터 여러 개가 생성되는 구조이다. 기능영역 - 코스트센터 기준 - 코스트센터 기준정보에 중요한 Input 값으로 기능영역(Func

간접비 관리(Overhead Management) : 자금관리센터(Fund Center) [내부링크]

자금관리센터 개요 자금관리센터는 예산 관리 목적으로 사용하는 조직단위이다. SAP 를 사용하는 회사의 경우, 예산은 필수 구현 범위이기 때문에 예산 관리 조직 단위가 있을텐데, 예산을 관리하는 단위로 자금관리센터를 사용한다. 자금관리센터를 Fund Center 라고 부르고, 일반적으로는 부서 단위 조직에 연동하여 자금관리센터를 생성/관리한다. 자금관리센터 관리 프로세스 - FM 모듈 - 자금관리센터는 기본적으로 FM 모듈안의 기준정보의 하나이다. FM 모듈은 Fund Management 로 자금관리센터와 약정항목을 기준정보로 가지고 있다. - 예산 모듈 구현 방안 - SAP Standard FM 모듈을 사용한다면, 자금관리센터를 Concept 을 그대로 사용하되 생성 기준과 Level 만 정의하면 된다. 그러나, 예산 모듈의 경우에는 꼭 FM 모듈을 활성화시켜서 사용하지는 않는다. 예산 모듈 구현 범위 및 사용 빈도와 적정성 등을 고려하여 독자적으로 개발하기도 하고, 표준과 개발을

간접비 관리(Overhead Management) : WBS(Work Breakdown Structure) [내부링크]

WBS 개요 WBS 는 Work Breakdown Structure 로, 프로젝트 단위의 손익/비용/예산 관리 목적 CO Object 의 하나이다. 범용으로 사용하는 CO Object 는 아니나, 경우에 따라 다양한 용도로 사용된다. 단, 프로젝트와 WBS 라는 형태로 계층구조를 갖고 있다는 것이 특징이다. WBS 사용 용도 1. 예산 관리 WBS 에는 예산을 관리할 수 있는 기능이 부여되어 있다. 즉, 예산관리가 필요한 프로젝트를 정의하고 해당 프로젝트 또는 WBS 에 예산을 부여하여 해당 한도안에서만 예산을 관리하도록 한다. 2. 투자 관리 투자예산 및 투자정산 부분이다. 설비 등 투자 목적으로 최초 프로젝트/WBS 를 생성한 뒤, 해당 투자 건에 대해 개별로 예산을 부여하여 관리할 수 있다. 투자예산의 경우, 기간 무관하게 해당 투자건에 대한 예산을 관리하는 경우가 많다. 투자정산의 경우, 아래와 같은 과정을 거치게 된다. 하나의 건설중인 자산에 대해서도 N개의 본자산으로 대체

수익성 분석(Profitability Analysis) : 수익성세그먼트(Profitability Segment) [내부링크]

수익성세그먼트 개요 수익성세그먼트는 CO 모듈 하위의 CO-PA (수익성분석) 영역과 관련이 된다. 수익성세그먼트라는 용어 자체가 SAP 에서 손익분석 (수익성분석) 의 핵심 사상을 설명하기 위한 용어로 이해하면 될 것 같다. 관리회계 > 수익성 분석 (CO-PA) 를 이해하기 위해 수익성세그먼트를 알아보자. 매출/원가/비용의 세부 계정의 상위 Category 로 구분했을 때, 발생한 각 금액 지표들을 분석하는 관점이 수익성세그먼트가 된다. 예를 들어, 특정 지역 x 특정 고객 x 특정 제품 입력 값의 조합이 수익성세그먼트가 되는 것이다. 수익성세그먼트는 최초 설계 시점에 각 발생 전표에 입력이 되어야 하는 최소한의 특성 (조직/고객/제품 등) 을 정의하고, 이를 기준으로 발생한 자료를 분석하는 과정이다. 수익성세그먼트 생성 시점 SAP 상 전표가 입력될 때, 다양한 CO Object 들을 입력할 수 있다 (코스트센터/수익성세그먼트/오더/WBS 등) 그 중에 수익성세그먼트라는 칼럼에

비용과 수익 요소(Cost and Revenue Element) : 원가요소(Cost Element) [내부링크]

원가요소 개요 원가요소는 Cost Element 로, SAP 에서 사용되는 용어이다. 재무회계에서 계정 (General Leder Account) 이 존재하는데, 관리회계에서는 계정에 대해서 원가요소 관리 여부를 결정할 수 있다. 재무제표에 결과물을 도출하기 위해 최소 집계되는 단위가 계정인데, 관리회계에서도 관리회계목적으로 자료를 집계하기위한 원가요소를 관리하고 있다. 조금 더 구체적으로 이야기하자면, 원가요소를 생성했다는 의미는 Cost Object 를 입력하겠다는 이야기와 같다. 즉, 전표를 입력할 때 원가요소가 존재하는 계정으로 입력 시에는 Cost Obejct (코스트센터/오더/WBS/수익성세그먼트) 를 반드시 입력해야 한다. 원가요소 생성 여부 원가요소 관리여부를 판단하고, 사용하는 순서는 아래와 같다. 계정 생성 → 원가요소 생성 여부 판단 (1차 원가요소 또는 2차 원가요소) 해야 한다. - 1차 원가요소 - 일반적으로 재무회계에서 사용하는 손익계산서계정에 대해서 원가

간접비 관리(Overhead Management) : 약정항목(Commitment Item) [내부링크]

약정항목 개요 약정항목은 이전 Posting 했었던 자금관리센터와 함께 FM 모듈에서만 사용하는 기준정보 중 하나로, 예산을 관리할 수 있는 단위이다. 약정항목을 불리는 이유는, Commitment 라는 용어의 의미처럼 실적을 발생시키는 시점에 예산을 선점 및 점유한다는 의미로 판단된다. 약정항목 관리 단위 약정항목 (Commitment Item) 의 속성은 기본적으로 계정과 1:N 으로 관리된다는 점이다. 즉, 복리후생비에 해당하는 계정이 여러 개 있을텐데 그러한 계정은 "복리후생비" 약정항목 1개로 연결되는 구조이다. 계정처럼 세부적인 단위로 예산을 관리하기가 어려우니, 동일한 속성을 갖고있는 계정 그룹 별로 묶어서 예산을 부여하고 잔액을 관리한다는 것이다. 단, 예산부여 및 잔액 관리를 약정항목 단위로 한다는 것이지 실적은 여전히 계정 단위로 발생 및 집계/추적이 가능하다. 약정항목 성격 약정항목에 대해서는 "예산과목유형" 에 통제 또는 비통제 여부를 설정할 수 있고, 설정이후

간접비 관리(Overhead Management) : 통계주요지표(Statistical Key Figure) [내부링크]

통계주요지표 개요 통계주요지표는 Statistical Key Figure 로, 간단하게 SKF 또는 배부적수로 불리기도 한다. 통계주요지표는 비용 배부 등을 목적으로, CO-CCA 또는 FI-GL 에서 사용되는 기준정보이다. 여기서 CO-CCA 는 코스트센터회계를 의미하고, FI-GL 은 총계정원장을 의미한다. 참고로, 비용계정에 대한 배부가 아니더라도 FI-GL 상에서는 BS 계정에 대한 배부도 지원한다. 통계주요지표 유형 통계주요지표에는 두 가지 종류가 있다. 위 예시 그림에 나온 Fixed Value 와 Total Value 이다. Fixed Value : 통계주요지표 전표 값이 고정되는 Case 를 의미하는 것으로, 한번 입력한 통계주요지표 전표 값이 바뀌지 않고 그대로 유지된다. 단, 동일 리시버로 N회 기표 시에는 최종 값 기준이 반영되고 배부 전기일 이후 미래 전기일로 처리된 통계주요지표 전표 값은 유효하지 않다. Total Value : 일반적인 Case 로, 매출액과

제품 원가계산(Product Costing) : 노무비 & 제조경비(Labor & Overhead Cost) [내부링크]

제조원가 결산의 흐름 액티비티유형은 단순하게 보면 CO-PC 영역에서 사용되는 기준정보에 불과하지만, 액티비티유형이 왜 필요한지를 포함하여 역할을 이해하려면 제조원가 결산 및 흐름을 이해해야 한다. 즉, 액티비티 유형의 경우는 시스템 측면이 아닌 업무 프로세스와 제조원가 관점에서 설명이 먼저 필요할 것 같다. 일반적인 제조원가는 생산 과정에서 당기에 투입된 "직접재료비 + 직접노무비 + 제조간접비" 를 모두 합산한 "당기총제조원가" 를 의미한다. CO-PC 의 최종역할은 제조원가 결산 과정을 거쳐 제조원가 명세서를 산출하는 과정으로, 제조원가 결산 프로세스에 대해서는 이후 Posting 을 통해 자세한 내용을 설명하기로 한다. 월중 노무비 및 제조경비 계산 과정 기본적으로 제조원가 프로세스는 표준원가 평가방법을 적용하는 것으로 가정한다. 표준원가 역시도 "직접재료비 + 직접노무비 + 제조경비" 로 구성되는데, 표준원가를 구성하는 이 각 요소들도 모두 계획에 의해 설정된 표준금액을 합

제품 원가계산(Product Costing) : 분할 구조(Splitting Structure) [내부링크]

분할 구조 분할 구조 (Splitting Structure) 는 CO-PC 모듈에서 사용되는 개념이다. 이 단계에서 코스트센터 별 발생한 비용을 적절한 액티비티 유형과 Mapping 하여 단가를 계산하는 것이 목적이다. 발생한 비용이 2개 이상의 액티비티 유형과 연관이 있을 경우에는 분할 규칙 (액티비티 수량/SKF/등가계수 등) 규칙을 설정하여 분할할 수도 있다. 단가계산이 완료되면 계산된 단가는 KP26 (트랜잭션) 에서 최종 확인이 가능하고, 계획원가 및 실제원가를 계산할 수 있는 Price 역할을 수행하게 된다. 분할 구조의 설정 순서 1. 분할 구조 설정 : ㄴ 원가요소 그룹 또는 원가요소 별로 하나의 액티비티 유형 (Activity Type) 을 Assign 할 수 있거나 ㄴ 하나의 원가요소를 2개 이상의 액티비티 유형 (Activity Type) 으로 분할하여 Assign 할 수 있다. 2. 코스트센터 별 분할 구조 Assign : ㄴ 각 코스트센터 별로 위의 분할 구조

제품 원가계산(Product Costing) : 원가 대상 유형(Cost Object Type) [내부링크]

원가추정 및 제조원가 결산에 사용되는 Cost Object 의 대표적 유형이다. 아래 Usage 부분이 어떤 Cost Obejct 를 사용할지 결정짓는 주요 요인으로 판단되고, 나머지 항목은 기능적인 차이로 기재했다. 생산 오더 : 특정 로트 (Lot 수량) 단위로 생산을 수행하는 경우, 해당 로트 별 원가 파악이 용이하다. 다만, 생산 종료 이후에 추가 생산이 필요한 경우 생산 오더를 반복해서 생성이 필요하다. 원가취합처 : (기계/부품업) 등에서 반복해서 동일 제품을 생산하는 경우, 기간 별 (월) 단위로 원가를 끊어서 정산하는 것이 용이하다. 투입량과 생산량만 차이가 있을 뿐이지 같은 제품을 매일 반복해서 생산하기 때문에 제품 1개당 (BOM X Routing) 원가취합처만 관리한다. 구분1 구분2 생산 오더 (Production Order) 원가취합처 (Product Cost Collector) 마스터 관리 주체 생산 Module 원가 Module 생성 단위 제품/플랜트 차수

수익성 분석(Profitability Analysis) : 수익성 분석 유형(Profitability Analysis Type) [내부링크]

원가중심 vs 계정중심 원가중심은 Costing Based 로 불리고, 계정중심은 Accounting Based 로 불린다. CO 운영 업무를 하거나, SAP 를 접한 경험이 많지 않은 경우 원가중심과 계정중심에 대해서 충분히 구분하기는 어려울 수 있다. 전체 내용 비교 및 Table 구조 차이 구분 원가중심 계정중심 수익성분석 전표 생성 O X (계획전표는 생성 가능) Value Field 관리 O X Table 구조 (CE1~4 + 경영단위) 사용 (CE4 + 경영단위) 사용 배부 성능 계정중심 보다 빠름 원가중심 보다 느림 배부 방식 Value Field 기준 배부 (계정중심 비해 데이터 양 小) FI 계정 기준 배부 (원가중심 비해 데이터 양 大) 데이터 정합성 CO 기준 집계되어 정합성 상시 검증 필요 FI 계정 기준 집계되므로 정합성 100% IMG Setting IMG Setting 大 IMG Setting 小 관리회계 기준 자료 생성 필요 시, 수익성분석 전표 생성하여

제품 원가계산(Product Costing) : 마킹 & 릴리스(Marking & Release) [내부링크]

표준원가 Marking 및 Relase 프로세스 표준원가 Base 로 제품원가 관리를 수행하는 경우, 자재 마스터에 대한 Marking 과 Release 는 필수로 관리되어야 하는 프로세스이다. 차이점과 중요사항은 아래와 같다. 구분 Marking Release 시점 당월 차월 1일 0 시 목적 차월 변경할 표준원가 추정금액을 사전 등록 차월부터 변경된 표준원가로 반영 트랜잭션 CK24 CK24 자재 마스터 원가계산 2 View > 선물 > 계획가격 원가계산 2 View > 현재 > 계획가격 선행 조건 ① 당월 표준원가 대비 차월 표준원가 변경 자재 ② CK11N (트랜잭션) 을 통한 표준원가 추정 성공 ① MMPV (트랜잭션) 을 통한 당월 물류기간 오픈 유의 사항 (표준원가 추정 성공한 경우) 신규 자재코드의 경우, Making 과 Release 까지 즉시 수행 가능

간접비 관리(Overhead Management) : 예산 시스템 유형(Budget System Type) [내부링크]

FM Standard vs CBO 개발 구분 FM Standard CBO 개발 구현 범위 Master Data : Standard Transaction Data : Standard 가용성 점검 : Standard 또는 개발 레포트 : Standard (Report Painter 또는 개발) Master Data : Standard 또는 개발 Transaction Data : 개발 가용성 점검 : 개발 레포트 : 개발 IMG FM 모듈 활성화 및 IMG Setting 상당히 많음 없음 가용성 점검 IMG 기준으로 설정 가능하나, 상세하지 못하므로 User Exit 개발 필요 User Exit 또는 유효성 확인 개발 필요 실적 관리 Accounting Document 기반으로, FM Document 가 생성되므로 정합성 보장 전표 기반이나, 100% 개발사항이므로 실적 누락 가능성 존재 예산 조정 Process Type 활용 (Supplement/Return/Transfer/Carry

간접비 관리(Overhead Management) : CCA 배부 유형(CCA Allocation Type) [내부링크]

SAP 사이클에서 사용되는 2가지 방식에 대해서 차이점을 알아보자. CCA, CCA TO PA 와 계획/실적에서 모두 사용되는 개념이므로 차이점을 정확히 파악 후, 적절한 방식을 적용한다. 구분 Distribution Assessment 원가요소 방식 1차 원가요소 배부 2차 원가요소 배부 속도 원계정 배부이므로 상대적 시간 多 소요 집합계정 배부이므로 상대적 시간 少 소요 배부 데이터 생성 센더 x 원가요소 x 리시버 별 라인 생성 센더 x (2차 계정) x 리시버 별 라인 생성 배부 추적 추적이 상대적 용이 추적이 상대적 어려움 배부 후 실적 (Sender) 원계정 원본 실적 + a (원계정 배부 실적) = 0 원계정 원본 실적 + b (2차 계정 배부 실적) = 0 배부 후 실적 (Receiver) 원계정 원본 실적 + a (원계정 배부 실적) = 000,000 원계정 원본 실적 + b (2차 계정 배부 실적) = 000,000 비용 실적 Sender 조직 비용 실적이 모두 차

간접비 관리(Overhead Management) : 배부 유형(Allocation Type) [내부링크]

포스팅을 쓴 목적은 비용 배부 관점에서 SAP 에서 제공하는 방식을 비교하고자 하는 목적이다. 사실 목적이 일부 겹칠 수도 있긴하나, 어떤 관점에서 보면 서로 다른 목적으로 제공하는 비용 배부 기능일 수 있다. 단순히 표로써 차이를 나열하기가 쉽지 않고, 글로써 부연 설명이 필요할 것 같다. CCA 일반적으로 CCA 배부라는 용어로 사용하는데, 주로 코스트센터 간 배부를 통해 간접비를 영업부서에 모으는 역할을 많이 한다. CCA 에서는 직접비 개념이 없기 때문에, 통계주요지표를 활용 적정한 지표를 선정하여 배부하는 방식으로 사용한다. 단, 제조비용 배부와 판관비용 배부할 때 목적이 다르므로 CCA 사이클의 형태로 상이하게 관리될 수 있다. PA CCA 비용을 PA (수익성세그먼트) 로 배부하는 과정이다. 즉, COSP 나 COEP 등 CO 쪽 관리회계전표로 발생한 자료를 PA 영역으로 이동시키면서 배부를 진행한다는 의미이다. 결론적으로 수익성분석을 하려면 PA 영역에서 레포트를 구성

간접비 관리(Overhead Management) : 사이클(Cycle) [내부링크]

배부 사이클 개요 배부 사이클 (Cycle) 은 CO 모듈의 비용 배부 목적으로 사용되는 기능으로, 배부 프로세스 설계 및 결산 구조 전반에 걸쳐 연계되어 있음으로 상황에 적절한 배부 사이클 선택 및 설계가 매우 중요하다. 배부 사이클은 사이클로 명명하기도 하고, 배부 주기라고도 부른다. 배부 프로세스 Tehcnical 기준으로 보면, 배부 사이클의 형태가 다양하나 관리되는 구조 및 Data 흐름은 서로 다른 배부 사이클 (Transaction Code) 라고 하더라도 공통적인 부분이 존재한다. ① 센더 센더는 배부할 대상 금액에 대한 정보를 필요로 한다. 센더의 조직 정보는 Cost Object 중 하나 (예를 들어 코스트센터) 가 되고, 원가요소가 필수로 조건으로 포함되어야 한다. 위의 조직/원가요소 외에 조건을 추가로 지정할 수 있다. 일반적으로 간접부서의 발생 비용을 의미한다. ② 리시버 리시버는 센더로 조건을 지정한 대상을 누구에게 배부할 것인지에 대한 조건을 지정하는 것을

비용과 수익 요소(Cost and Revenue Element) : 원가요소 범주(Cost Elemenet Category) [내부링크]

관리회계 기준정보인 원가요소에는 원가요소 범주 별로 구현 가능한 범위가 구분되어 있다. 2차 원가요소는 기능 별로 원가요소 범주가 다양하므로 해당되는 기능 사용에 따라 세팅하도록 한다. 원가요소 범주 내역 대상 계정 용도 비고 1 Primary Costs 매출원가 또는 비용 계정 CO Object 필수 수익성세그먼트 선택 11 Revenues 매출 계정 수익성 세그먼트 필수 수익성세그먼트 필수 12 Sales Reduction 매출차감 계정 상동 Costing Based 하에서는 매출 마이너스 부호 제공 21 Internal Settlement N/A Internal Order/WBS 정산 트랜잭션에서 사용 22 External Settlement 제품 생산입고 상대 계정 Controlling 에서 생성한 데이터를 FI 로 전송하는 경우 31 Order/Project Result Analysis 재공품 계정 Order Settlement 재공품 전표 생성 시 사용 41 Overhea

주요 개념(Key Concept) : 기능영역(Functional Area) [내부링크]

글을 쓰기 앞서 상대적으로 여유가 있었던 올 2월과 3월에 SAP 글을 많이 올렸다. 그 동안은 포스팅을 할 시간을 퇴근이후로 잡기가 조금 어렵기도 했고, SAP 기준정보 이외에 추가로 어떤 주제로 글을 쓸지도 방향이 안 잡히기도 했다. 몇일 전에 기능영역에 대해서도 글을 쓰면 괜찮겠다는 생각이 들어 금요일 밤늦게 적어본다. 이렇게 글을 남기는 이유는, 나름의 지식을 바탕으로 생각을 정리해두기도 하고 필요할 때 틈틈히 보면 괜찮을 것 같다는 생각이다. 기능영역에 대한 이야기 SAP 관리회계 라는 주제가 Technical 하게는 SAP 의 특정 CO 모듈에 대한 이야기이기도 하고, 더 큰 범주를 찾아보자면 원가/관리회계 영역에 맞추어져 있다. 기능영역은 SAP 내 관리회계에서 사용하는 단어이고, 사실상 재무회계 영역의 이야기이기도 하다. 성격별 손익계산서와 기능별 손익계산서 이야기를 들어보았을 것이다. 회계원리에서도 나오는 이야기인데, 일반적으로 우리가 많이 보는 형태가 기능별 손익계

간접비 관리(Overhead Management) : 불공제 세금코드(Exclusion of input tax deduction) [내부링크]

불공제 세금코드로 인한 관리회계 이슈 SAP 예산 모듈 구현에 관련해서, 불공제 세금코드 사용으로 인한 실적 및 예산 가용성 점검에 이슈가 있을 수 있다. (1) 현황 재무회계 모듈에서 불공제 세금코드를 통해 비용전표를 기표하는 상황으로, 시점별로 나열하면 아래와 같다. 불공제 세금코드를 사용하게 되면 VAT 는 존재하지 않기 때문에 아래에서도 제외되었다. 아래 ② 예외 Case 를 보면, 임시전표 시점에는 실적이 1,000원으로 발생하고 예산 가용성 점검도 1,000원 기준으로 처리된 것을 예상할 수 있다. ① 공제 세금코드 Case - 임시전표/승인전표 (차변) 복리후생비 1,000원 (대변) 미지급금 1,100원 (차변) VAT 100원 ②-1 불공제 세금코드 Case - 임시전표 (차변) 복리후생비 1,000원 (대변) 미지급금 1,100원 ②-2 불공제 세금코드 Case - 승인전표 (차변) 복리후생비 1,100원 (대변) 미지급금 1,100원 (2) 이슈 일반적으로는 임시

주요 개념(Key Concept) : 그룹/세트(Group/Set) [내부링크]

관리회계에서 사용되는 기준정보 관점에서 Group Group 이 용도 및 어떠한 종류가 있는 지 알아보자. 다른 모듈은 어떠한지 정확치는 않으나, Group 이라는 표준 개념은 주로 FCM 영역에서 사용하는 것으로 보인다. Group 은 주로, 최하위 마스터를 Grouping 하여 묶음으로 조회 및 관리 단위로 삼는데 목적을 두고 있다. 그리고 아래 Group 의 특징은 단순 합산이 아니라 계층구조를 적용하여 관리할 수 있다는 것이 큰 장점이라고 볼 수 있다. (1) 재무회계 1) 계정그룹 : 계정그룹은 사용하는 회사도 있고 사용하지 않는 회사도 다수이다. 최초 프로젝트 당시 설계 방향에 따라 크게 갈린다고 본다. 계정그룹의 목적은 계정의 묶음 단위로 조회하는 것이므로, 재무제표를 구성하는 기초자료로 쓰이기도 한다. 대신에 계정그룹 대신 재무제표 버전이 일반적으로 사용되는 것으로 보인다. 계정그룹은 일반 트랜잭션으로 운영 시스템 내에서도 유지보수가 가능한 반면에, 재무제표 버전은 I

주요 개념(Key Concept) : 관리회계(Management Accounting) [내부링크]

관리회계 이해의 필요성 SAP 관리회계에 대한 글을 쓰면서 관리회계 자체에 대한 글을 써보는 게 좋을 것 같다는 생각이 이제야 들었다. 거시적 관점에서 SAP 도 이해하고, 관리회계도 이해하는 것이 좋겠다. 부분만 살펴보고 집중하는 것도 필요하겠지만, 전체적인 흐름을 바라보고 양쪽에서 조금씩 지식을 쌓고 넓혀가보자. 회계 그리고 관리회계 SAP 관리회계라고 할 것도 없이, SAP 관리회계도 관리회계라는 영역일 뿐이다. 회계라면, 머리가 복잡할수도 있겠지만 회계에서부터 출발한다. 회계 쪽 업무를 하던사람이라면, 아래 분야에 대해서 들어본 적도 있을 것이다. SAP 쪽 회계를 오랫동안 해오기도 했지만, 회계 쪽 자격증을 오래 공부하기도 했어서 잠깐 짚고 넘어가보자. 재무회계 공시목적의 재무제표를 만들기위한 회계원칙에 대한 영역이다. 현재는 IFRS 라는 회계기관에서 기준을 부여하고, 규모에 해당하는 기업은 IFRS 기준으로 재무제표를 공시해야 한다. 재무회계는 Rule 에 대한 부분이

간접비 관리(Overhead Management) : CCA(Cost Center Accounting) [내부링크]

지난 포스팅에서는 회계라는 큰 영역 안에서의 관리회계를 살펴보았다. 이번에는 CO(Controlling) 라는 SAP 모듈 내의 관리회계 Sub Module 은 무엇이 있으며, 각 항목 별로 알아보도록 하자. SAP CO Module SAP 내에서의 관리회계의 큰 주제들은 주로, 아래의 영역으로 구분되어 있다. 우선, Posting 은 나누어서 CCA 부터 설명하는 시간을 갖고자 한다. 간단하게 개요 수준으로 구분하면 아래와 같다. (1) CO-CCA 코스트센터로 비용이 발생/기표/배부의 전체 과정을 의미하며, 제조경비와 판매관리비로 크게 구분되어 경영관리/생산지원 또는 재무 부서에서 기준을 정립하고 결산 수행을 주로 한다. (2) CO-PC 제품원가계산에 대한 부분으로, 제조원가명세서를 보고해야하는 회사의 경우 중요한 Sub Module 이다. 생산오더 또는 제품취합처를 활용하여, 월중에는 표준원가로 제품원가를 확인하고 결산 시점에는 실제원가로 계산 및 확정하는 과정이다. 제조원가

간접비 관리(Overhead Management) : 배부 구조(Allocation Structure) [내부링크]

배부 구조란, 비용배부 사이클 또는 정산에 사용되는 개념이다. 일반적으로 비용 결산이 필요한 곳에는 필수적으로 사용된다고 보면 된다. 결론적으로, 비용 정산의 대상 Cost Object 가 변경되면서 최초 원계정이 집합계정으로 변경되는 Rule 을 등록하는 것이다. 1. 소스 소스는 원가요소 또는 원가요소 그룹을 의미한다. 해당 원가요소 (그룹) 으로 발생한 전표 금액을 집계한다는 의미이다. 2. 평가 원가 요소 비용배부 사이클에서는 Assessment 방식의 경우에만 해당하는 것으로, 원계정에 대한 집합계정 (즉, 관리회계 2차 계정) 을 활용하여 배부하는 것이다. 이 때, 사용하는 것이 배부구조의 평가 원가 요소라는 항목이다. 평가 원가 요소의 경우, 원가요소 범주 42번 = 평가만 가능하다. 3. 정산 원가 요소 정산 원가 요소는, 전표 기표 시점의 Cost Object 가 필수적으로 입력은 되었으나 결산 시점에 해당 비용을 최종 Cost Object 로 정산하고자 할 때 사용

기간 관리(Period Management) : 마감 관리 시나리오(Periodic Management Scenario) [내부링크]

SAP 기준정보에 대한 주요 주제들을 대부분 Posting 한 것 같다. 내가 적는 블로그의 SAP 부분은 Technical 관점의 Trasaction 단위보다는 Process 및 해당 Posting 주제에 대한 전반에 대한 내용이다. 즉, 해당 기능을 사용하는 이유나 사용 목적 등에 대한 이해를 우선으로 하고 있다. 그러면, 본 Posting 의 목적인 Closing 에 대한 부분을 이야기하고자 한다. 여기서 말하는 Closing 은 실제 CO Settlement 이전 Periodic Closing 관점에서 먼저 이야기하고자 한다. 예상 시나리오 단순 마감에 대한 주제이기도 하나, 결산에 본격 임하기에 앞서 가장 중요한 과정이다. 실제로 결산 프로세스에 선행하여 마감은 필수 단계이다. 그렇다면, 마감이 이루어지지 않았거나 마감에 대한 설정이 잘못된 경우에는 결산에 어떤 영향이 미치게 될 것인가, 가장 기본적인 내용이기는 하나, 실제로 이 단계에 대한 이슈 때문에 결산작업을 반복하거

주요 개념(Key Concept) : 중요성(Significance) [내부링크]

전체 결산 과정에 대해서는 주요 영역 별로 구분하도록 하자. 여기서 이야기하는 주요 영역은, 생산 및 물류, 그리고 재무회계와 관리회계 각 Part 를 주제로 적어보고자 한다. 본격적으로 글을 쓰기에 앞서, 결산 업무의 중요성 등에 대해서 간단히 알아보자. 결산 업무의 어려움 한 달에 한번 찾아오는 결산의 과정은 업무를 수행하는 현업 그리고 Issue 가 발생했을 때 조치를 취해야하는 Engineer 에게는 참 어렵고도 버거운 과정이 되기도 한다. 아무런 문제 없이 사전에 Define 된 과정을 Process 대로 수행할 경우 정상적으로 결산이 완료되면 좋겠지만은, 온전히 한 명이 수행하는 것도 아니고 서로 다른 업무 부서간 마감 일정에 맞추어 순차적으로 진행하는 것 만큼 누락이나 실수, 오류 등 다양한 Case 가 결산 시점에 종합적으로 발생할 수 있다. 즉, 월중에 실시간 발생한 Event 에 대한 처리는 반드시 결산 과정을 거쳐 시스템적으로 또는 Data 결과상으로 정산/정리되

간접비 관리(Overhead Management) : 재전기(Reposting) [내부링크]

1. Reposting 관리회계에서 사용하는 주요 재전기 유형이다. 재전기는 관리회계 전표가 동반되어 생성되는 유형을 의미한다. Cost Object 만 변경되므로, 재무회계에 영향이 없다. 2. Data Rearrangement 더불어 재조정 유지보수의 경우, 대량으로 값을 조정하는 경우 사용된다. PA 특성만 변경되므로, 재무회계에 영향이 없다. T-Code 명칭 개요 대상 특이시항 KB11N 원가 수동 재전기 Cost Object 와 원가요소 기준 총액 조정 원가요소 범주 = "11" 동일 관리회계영역 내라도, 회사코드간 반제 거래 등록 필요 (OBYA) KB41N 수익 수동 재전기 Cost Object 와 원가요소 기준 총액 조정 원가요소 범주 = "1" or "12" 상동 KB61(KE26) 개별 항목 재전기 원 회계전표 기준 동일 금액 내 조정 　 이미 재전기 처리한 전표 불가 Cost Object 는 변경 가능하나, 원가요소 및 총 금액 변경 불가 KEND 재조정 유지보

주요 개념(Key Concept) : 재무회계 통화(Finance Currency) [내부링크]

거래 통화/회사코드 통화 FB01 (트랜잭션) 을 통해 전표를 입력할 때, Header 레벨에서 먼저 통화를 입력하도록 되어 있고, 아래 화면에서 "통화/환율" 입력란을 의미한다. 회사코드 통화와 전표 전기 화면의 "통화/환율" 이 다른 경우, 아래와 같이 금액 칼럼 외에 현지 통화액 칼럼이 추가로 생성된다. 회사코드 통화 회사코드 조직 Level 로 유효한 기능통화를 의미한다. 해당 국가에 속한 회사코드에 대한 재무제표 작성의 기준이 되는 통화이다. 관리회계 통화 관리회계 조직 Level 상 관리기준이 되는 통화를 설정한다. 오브젝트 통화 오브젝트는 전표 기표할 때, Input 이 되는 CO 영역 내 Obejct 로 볼 수 있다. 일반적으로 코스트센터, WBS, 오더 등으로 해당 오브젝트에 통화정보를 입력할 수 있다. 경영단위 통화 관리회계 영역을 포괄하는 관리회계상 최상위 조직으로, 경영단위기준으로도 통화설정이 가능하다.

주요 개념(Key Concept) : 유효성확인(Validation) [내부링크]

이번 주제는 Validation 부분이다. FCM 영역에서는 주로 Validation 이 Rule Base 로 관리되어야 한다고 본다. 1. Validation 의 필요성 전표가 Posting 되는 시점에, 아래의 역할을 수행하는 Validation Point 가 최소한은 필요하다. 1. 조직 및 원천 데이터의 유형 별로 원하는 결과를 얻기 위한 (손익계산서 등) 2. 예외사항을 발생시키지 않도록 하거나 3. 정해진 규칙에 의해서만 필요한 데이터를 발생시키도록 2. Validation 의 유형 Validation 은 주로 Financial Accouting 과 Cost Center Accounting 부분을 사용한다. (1) Financial Accoutning : 일반적으로 재무회계 전표가 Posting 되는 시점에 Validation 을 수행하는 것으로, 전표 Header Level, 전표 Item Level, 전표 완료 Level 로 그 시점이 다시 세분화 되어 있다. 결론적으

기업 구조(Enterprise Structure) : 코스트센터 & 손익센터(Profit Center & Cost Center)) [내부링크]

코스트센터와 손익센터를 관리회계 기준으로 비용중심점과 이익중심점으로 대비해서 이해하면 적절하다. 결론적으로, 손익센터 : (매출-원가-비용 = 이익) 을 Reporting 할 수 있는 최소 단위 코스트센터 : 비용을 집계 할 수 있는 최소 단위 1. 재무회계 관점 (1) 손익센터 재무회계 관점에서는 회사의 재무제표만 있으면 된다. 그 회사에서 여러 가지 사업부 (서로 다르거나 유사하거나) 를 운영한다고 하더라도 재무회계 기준으로 BS/PL 을 볼 수 없다. 그러나, 사업부 별 재무제표를 보고자 한다 또는 공시해야한다고 하면 손익센터를 활용하여 구분된 재무제표를 도출할 수 있다. 여기서 손익센터는 관리회계에서 제공하는 구분회계의 기준이 되는 조직이고 재무회계 관점에서는 사업영역이 그 역할을 할 수 있다. 결론적으로 사업영역 = 손익센터를 같은 Level 로 삼아도 되고, 둘 중에 하나만 사용해도 되고, 사업영역보다 더 하위로 손익센터를 구분해도된다. 위와 같이 BS 관점으로도 구분손익

주요 개념(Key Concept) : 대체(Substitution) [내부링크]

유효성 확인과 더불어 전표 생성 시점에 자주 등장하는 대체(Substitution) 이다. 1. 유효성 확인 및 대체에 대한 접근 GGB4(트랜잭션) 을 통해 아래 화면까지 연결이 되어 있다. 크게 보면 유효성확인과 대체의 2가지 기능이 구분되어 있고, 어플리케이션 영역 별로 Input 값으로 사용가능한 Value 및 진입가능한 시점이 각각 상이하다. 2. 재무회계 기준 상세 재무회계 기준으로는 아래 3가지 단계로 구분되어 있다. 전표 완료단계에서는 헤더 및 개별 정보를 기준으로 전표 전기 직전에 완성된 전표의 Data 를 기준으로 Validation 및 Subsituion 가능한 구조이다. 전표 헤더 전표 개별 전표 완료 3. 기능적인 차이 및 순서 (1) 적용 순서 순서상으로는 대체 > 유효성 확인 순으로 적용된다. 그리고 임시전표의 경우는 대체가 적용되지 않는다. (2) 구현 방식 대체도 유효성 확인과 동일하게 선행조건을 기반으로 특정 칼럼을 대체하거나 선행조건이 있거나 없거나

주요 개념(Key Concept) : 관리회계 오브젝트(Controlling Object) [내부링크]

Controlling Object 는 Management 영역 내에서 중요한 역할을 하는 기준정보의 범주에 속한다. Controlling Object 정의 아래 4가지 기준정보의 공통점을 살펴보자면, 최초 FI Document 생성 시점에 Primary Cost & Revenue 계정에 대해 입력받는 Object 라는 것이다. 나열하자면 아래와 같은 리스트로 존재한다. Controlling area Cost element Revenue element Profit center Investment center Cost center Activity type Order Project Business transaction WBS element Cost object Business process Operating concern Profitability segment Object class True & Statistical Controlling Objects True 와 Statistical 개

제품 원가계산(Product Costing) : 재고자산 평가(Inventory Valuation) [내부링크]

이번엔 재고자산의 단가를 결정하는 여러 가지 방법이다. SAP 에서는 Material Type 별 내부생산 또는 외부구매를 요인으로 하여 표준원가 방법과 이동평균가 방법을 사용한다. 재고자산은 판매(또는 생산) 하기 위해 보유하고 있는 자산을 의미한다. 재고자산 평가방법은 일반적인 원가회계의 내용을 SAP 내 옮겨둔 것과 동일하다. 참고로, 또 다른 자산의 유형인 유형자산은 사용을 목적으로 하는 자산이다. 이동평균법 (Moving Average) 이동평균법은 매입가 기준으로 재고자산의 단가가 계속 변경되는 방식이다. 실제단가 즉, 매입단가 기준으로 재고자산이 평가되기 때문에 월중 재고의 입출고는 실제단가 기준으로 기록되고 월말 별도 결산과정이 불필요하다. 구분 일자 실제단가 표준단가 가격차이 입출고 수량 이동평균가 (월중/월말) 기초 11월 1일 - - - - - 매입 11월 10일 1,000원 - - 2개 1,000원 판매 11월 11일 - - - (1개) 1,000원 매입 11월

주요 개념(Key Concept) : 세그먼트 회계(Segment Accounting) [내부링크]

https://terms.naver.com/entry.naver?cid=43659&docId=5894&categoryId=43659 세그먼트회계 부문별·지역별 매출액과 이익을 나타내주는 회계정보. 미국의 자본시장에서 자금을 조달하는 회사는 이러한 세그먼트회계를 미국증권거래위원회(SEC)에 제출해야 한다. 자금을 조달하는 경우에 필요한 유가증권신고서에 이를 기재하는 것이 의무화되고 있다. 이에 대해 이러한 정보를 제공하는 것은 경쟁상 불리하다고 해서 해외기업들은 반발하여 미국시장에서의 기채나 증자를 꺼리는 경향이 있다. 이에 따라 SEC는 1979년말 연차보고서에서 세그먼트회계를 해외기업에 대해서는 면제했다. terms.naver.com 재무회계 정보 결산 재무제표로 Stock (재무상태표) 와 Flow (손익계산서) 등 결산서가 제공된다. 법인 또는 주요 사업부문을 조직 단위로 계정의 그룹 단위의 매출 및 이익 정보를 확인할 수 있다. 상품 별 손익 정보의 중요성 우선은 각 거래(매

제품 원가계산(Product Costing) : 오더 정산(Order Settlement) [내부링크]

오더 정산의 목적 월중에 CO Object 의 하나인 Order 에 원부재료 등이 투입되게 된다. Order 에 투입된 내역은 결산시점에 재공품 또는 원가차이 금액으로 정산이 반드시 필요하다. 오더 정산 Step 을 완료하면, 재공품 또는 원가차이 계산된 결과가 FI Document 로 Posting 된다. 오더 정산이 완료되면 CO Object 인 Order 에서 정산 Target 인 Material 로 반영된다. 예를 들어, 투입내역은 존재하나 생산이 완료되어 입고된 제품이 없다면 재공품이 될 수 있고 생산이 완료되어 입고된 내역이 존재한 경우 원가차이 금액이 발생할 수 있다. (원가취합처를 사용한 경우에는 재공품과 원가차이 금액이 같이 계산될 수 있다) 오더 정산 금액 계산 방식 1. 생산 오더 (Production Order) (DLV/TECO 인 경우) 생산 오더에 (실제 투입 금액 - 표준원가 입고금액) 기준으로 원가차이을 계산한다. (DLV/TECO 가 아닌 경우) 생산

210323 - 카카오프렌즈 블루투스 마이크 어피치 [내부링크]

고모가 사준 네 살 생일선물, 화려한 미러볼을 좋아한다. 부엌불을 꺼고 전원을 켜면 실감난다. 성능좋은 에코는 아파트에서 조심해야할 부분, 블루투스가 되니 Hearing 과 Speaking 을 동시에 하는 기분

210505 - 맥포머스 원더 크리에이터 세트 121PCS [내부링크]

어린이날 선물, 창의성을 마구 올려줄 것 같은 장난감, 늦은 후기지만, 지금도 여전히 좋아한다. 애써 만들고 망가뜨리기도 하고, 아이는 새로운 걸 자주 만들어낸다.

211218 - 맥포머스 인스파이어 세트 30PCS [내부링크]

어린이날 선물 121 PCS 의 맥포머스가 부족하다 부족하다 아이의 요청사항을 받아들였다. 조금 더 높은 집을 많이 지을 수 있겠네,

210903 - 레고 듀플로 즐거운 우리집(10929) [내부링크]

예전에도 듀플로 세트가 2개 있었다. 요즘 아파트 집을 좋아하던데, 모처럼 손길이 많이 필요한 장난감이 생겼다.

211023 - 타요 컨트롤 주차타워 [내부링크]

재난지원금 받은 김에 큰 장난감을 샀다. 근방에 신토이 매장에서, 이미 집에 있는 주차장은 비할 수가 없다. 나에게도 아이에게도 기분좋은 무게감이 느껴진다.

주요 개념(Key Concept) : HANA 신규 트랜잭션(New transaction for HANA) [내부링크]

개요 SAP S/4HANA 에서는 신규 트랜잭션이 아래와 같이 제공된다. 기존 ECC 에서 사용하는 트랜잭션도 존재하나 폐기되지는 않았기 때문에 병행해서 존재한다. HANA DB 기준으로 최적화된 트랜잭션이 제공되기 때문에 빠른 결산 또는 조회 성능이 향상되었다고 보면 된다. 데이터 Handling 과 관련된 영역이 HANA DB 에서 대부분 이루어지기 때문에 User 입장에서 향상된 속도를 체감할 수 있다. 신규 트랜잭션 비교 Transaction Description S4HANA ECC Actual Settlement: Prod./Process Ord CO88H CO88 Acct. Settlement: Int./Maint. Orders KO8GH KO8G Actual Settlement: Projects/Networks CJ8GH CJ8G Actual Results Analysis: Sales Ordrs KKAKH KKAK Variances - Product Cost by Lot

220216 - 꼬마버스타요 라켓볼 [내부링크]

새벽배송으로 도착 말랑한 라켓의 탄성이 제법된다. 안전해보이는 건 안심이건만, 어른도 컨트롤이 쉽지 않다. 어디로 튈줄 모르는 상황 아이는 공을 가지고 천장으로 쿵쿵

주요 개념(Key Concept) : 재무회계(Financial Accounting) [내부링크]

회계에도 종류가 여러 분야가 있다. 가장 일반적으로 회사에서 기본적으로 작성대상이 되는 부분은 재무회계 영역이다. 재무회계는 기업에게 요구하는 회계기준을 바탕으로 작성되어진다. - K-IFRS (한국채택 국제회계기준) : 외부회계감사대상인 상장 또는 금융회사 - K-GAAP (일반기업회계기준) : 외부회계감사대상인 상장되거나 금융회사가 아닌 경우 - 중소기업회계기준 : 외부회계감사대상이 아닌 경우 구분 재무회계 관리회계 요약 공시목적 재무회계 회계기준으로 작성 재무회계 정보 기반 내부 의사결정목적으로 작성 보고대상 투자자, 채권자 등 외부정보이용자 내부정보이용자 보고양식 재무제표 - 재무상태표 - 손익계산서 - 현금흐름표 - 자본변동표 기업내부 별 정의 상이 보고시점 연간/분기/반기 일/월/분기/반기 등 수시 강제력 있음 없음

CDS 뷰(Core Data Service View) [내부링크]

SAP ECC 에서 S/4 HANA 로 전환되면서 CDS View 기능이 새롭게 제공되었다. 1. ECC 에서는 전통적으로 Database Table 을 활용한 Data 수집 이후에 ABAP Language 를 활용하여 Data Processing 처리가 일반적이였다. OPEN SQL 을 활용하여 Database 에서 1차적으로 Data 를 추출한 이후에 필요한 출력물 또는 데이터 가공은 ABAP 영역에서 처리되므로 속도 및 성능의 개선이 제한적이였다. 2. S/4 HANA 부터는 CDS View 가 제공되었다. 기본적으로 ABAP Data Processing 영역이 Database 영역으로 전환되었고 S/4 HANA Database 의 빠른 성능 향상을 충분히 활용하여 Data handling 이 Database 의 영역에서 수행되는 차이가 있다. CDS View 는 Database 영역 내에서 Data handling 이 가능하게 해주는 Model 이다. (1) Query 사용

일반 회계(General Ledger Accounting) : 사업장(Business Place) [내부링크]

재무회계에서 사용되는 주요 조직은 아래 3가지로 볼 수 있다. 회사코드/사업영역/사업장 회사코드와 사업장은 필수적인 정보로 판단되고 다만 사업영역에 대해서는 사업부별 구분공시 대상 회사인 경우, 사업영역 또는 손익센터를 활용하여 선택적으로 구분손익의 단위로 활용할 수 있다. 그렇다면 사업장 사업장은 재무회계 목적으로 존재하는 조직 단위는 아니고 세금계산서 발행 그리고 부가가치세 신고 및 납부를 위한 기본 정보이다. 재무회계에서 회사코드가 공시단위라면 이하 부가가치세 영역에서는 사업장이 최소단위인 것이다. SAP 에서 처리되는 매출전표와 매입전표에는 부가가치세 Code 에 의해 매출부가세/매입부가세에 해당하는 예수금 Item 이 자동 생성된다. (과세표준금액을 Base 로 하여 부가가치세 코드에 Define 된 세율 기준) 이 때 이러한 전표에 입력되는 조직 단위가 사업장인 것이다. 일반적으로 사업을 개시하면서 사업자등록증을 신청하고 발급받게 되는데, 사업자등록증번호와 SAP 의 사업

일반 회계(General Ledger Accounting) : 계정과목표(Chart of Account) [내부링크]

회계기표에 사용되는 모든 G/L Account 의 모음을 정의한 단위이다. 국가 별로 다를 수 있고 회사 별 비즈니스 형태가 다르므로 계정과목표의 구성은 다를 수 있다. 반대로 이러한 부분을 모두 감안하여 그룹 단위로 SAP 가 도입된 회사들은 모든 계정의 속성을 합산한 형태의 계정과목표를 채택할 수도 있다. 계정의 주요 속성에 대한 부분은 G/L Account 영역에서 다루기로 하고, 계정과목표에서는 아래 2가지 기능적인 부분만 설명하고자 한다. 1. 회사코드 기준 주요 계정과목표 모든 회사는 단일의 주요 계정과목표를 설정해야한다. 전표 Posting 에 필요한 계정 입력 및 계정 설정의 표준이 되는 계정과목표의 역할을 수행한다. 2. 회사코드 기준 대체 계정과목표 대체 계정과목표 기능은 존재하나 실제로 설정하여 운용하는 사례는 확인하지 못했다. 예를 들어, 국내외 회사를 운용하는 본사 입장에서 표준 계정과목표 (COA) 를 표준으로 설정하되 Local 계정과목표가 존재하는 경우

일반 회계(General Ledger Accounting) : G/L 계정(General Ledger Account) [내부링크]

이전 Posting 글에 이어지는 내용이다. G/L Account 는 계정과목표를 구성하는 개별 계정을 의미한다. SAP FI 에서 가장 기초가 되는 기준정보로 G/L 계정은 전표 Posting 및 데이터 분석의 기초 역할을 부여받는다. G/L 계정의 변화사항 더욱이 S/4 HANA 에서부터는 SAP CO 영역의 원가요소 영역까지 G/L 계정으로 관리되므로 FI 본연의 기능 이외에도 Controlling 영역 (이전 원가요소) 까지 포괄적으로 G/L 계정으로 포함하게 되었다. 실제로 Controlling 의 CO-PA 영역을 살펴보면 Accounting-Based Concept 이 주로 강조되고 있음으로 Value Field Concept 이 G/L 계정으로 옮겨졌다고 판단된다. 참고로 S/4 HANA Cloud Version 에서는 Costing-Based 는 완전히 사라졌다. G/L 계정의 역할 조금 단순하게 보자면 전표 생성을 위한 기초 정보로써의 역할로 판단할 수 있으나 G/

220308 - 68조각 판퍼즐 - 꼬마버스 타요 놀이공원 [내부링크]

내가 아이에게 배웠듯 아이의 놀이가 꼭 단순함을 의미하는 것은 아니다. 퍼즐도 아름다울 수 있으며 타요 퍼즐에서도 완전한 느낌이 있다.

주요 개념(Key Concept) : BP(Business Partner) [내부링크]

Customer 와 Vendor Master 는 SAP S/4 HANA 에서 Business Partner 라는 용어 및 트랜잭션으로 변경되었다. 용어가 조금씩 혼재되긴 했으나, 근본적으로 고객/공급업체 Master 에 대해서 알아보자. 1. 주요 역할 - 전표 생성 시점에 Customer 및 Vendor Code 를 직접 입력하는 방식이다. - 입력한 Master Code 에 해당하는 G/L Account 정보가 자동으로 인식된다. - 생성한 전표는 Customer 및 Vendor 별 Open Item (미결) 여부를 관리한다. 2. 주요 기능 - 계정그룹 : 거래처 유형별로 Grouping 해주는 기능으로 계정그룹 단위로 번호 범위를 관리 가능하다. - 은행키 : 국가에서 제공하는 고유 은행 Code 정보를 사전에 Master 로 등록하고 해당 거래처의 정보를 등록한다. - 은행계좌 : 해당 거래처의 계좌번호 정보를 입력한다. - 계정보유자 : 거래처 계좌에 대한 예금주 이름을

채무(Accounts Payable) : 지급조건(Payment Terms) [내부링크]

지급조건은 Payment Terms 용어로 사용되나, Incoming payment (입금) 및 Outgoing payment (지급) 시점에 사용할 수 있는 Master 성격을 갖고 있다. 기본적으로 Customer 및 Vendor Master 생성 시점에 속성 값 (Default) 로 지정할 수 있으며 거래처 별 계약 조건 기준으로 설정하게 된다. 단, 전표 생성 시점에 Default 로 설정된 값은 변경 가능하다. 주요 기능 Account type 생성한 Payment Terms 을 Customer 및 Vendor 중 일부 또는 공통으로 적용할지 여부를 선택한다. - Customer - Vendor Default for baseline date 만기일 (Due date) 계산을 위한 시작일을 아래 중에서 Default 로 결정할 수 있다. - Posting date - Document date - Entry date Baseline date Calculation 위에서 선정한

제품 원가계산(Product Costing) : 자재 원가 변경(Change material costs) [내부링크]

요약 MR21 (트랜잭션) 을 통해 재고자산의 단가 정보를 변경할 수 있고, 단가 정보 변경을 통해 재고자산 금액 변경 전표가 생성될 수 있다. 단, Manual 방식으로 Update 하는 것이 일반적인 경우는 아니라고 판단되고 Standard Price 를 채택한 Material 의 경우 Quantity Structure 정보가 더 이상 집계되지 않으므로 고려사항이 존재한다. Price Control 재고금액 존재 여부 MR21 (트랜잭션) 수행 결과 V (Moving Average) O 1. Material Master 의 이동평균 단가 변경 2. 재고금액 조정 전표 생성 (재고자산 XX / 가격차이 XX) 3. 가격차이 조정 (가격차이 XX / AP 또는 매출원가 XX) S (Standard Price) O 1. Material Master 의 표준원가 단가 변경 2. 재고금액 조정 전표 생성 (재고자산 XX / 가격차이 XX) 3. 자재원장 정산 (가격차이 XX / 재고자산

#Site. SAP 솔루션 도입 방법 [내부링크]

https://www.youtube.com/watch?v=PxvwtloiYb8

주요 개념(Key Concept) : 원장(Ledger) [내부링크]

재무회계에서 0L 원장을 Leading Ledger 로 사용하는 것이 일반적이다. Configuration 사항으로, 특별한 경우가 아니면 0L 원장을 단독으로 사용한다. 그러므로 일반 사용자 등은 0L 이라는 Ledger 정보를 인지하는 경우는 많지 않다. Ledger Table 구조 기술적인 관점에서는 Accounting Document Data 모두 저장되는 최상위 Key 정보이라고 보면 된다. 조직 관점에서는 Company Code 가 존재하지만 Company Code 등 Organization 단위와 무관하게 모든 회계정보는 0L 하위에 집계된다. 0L 이 회사코드 국가의 Local 회계기준 원장이면, 2L 은 별도 회계기준을 적용받는 원장의 개념이다. 전표 Posting 시점에 동시에 두 개의 원장에 같은 정보가 기록된다. 단, 원장이 분리되어 있음으로 각 원장을 지정하여 Posting 이 가능하다. 예시적으로 2L 을 IFRS 기준의 원장으로 설정한 경우, IFRS 에

주요 개념(Key Concept) : 그룹 통화(Group Currency) [내부링크]

재무회계에서 기본적으로 지원하는 통화는 Company Code Currency 이다. 추가로 관리 가능한 대표적인 통화 유형인 Group Currency 에 대한 글이다. 이전 Posting 에서 관리회계에서 사용가능한 통화에 대해서 기재한 바 있다. https://blog.naver.com/someday84/222063743860 SAP CO 관리회계 Overview : 통화(Currency) 1. 전표 금액 FB01 (트랜잭션) 을 통해 전표를 입력할 때, Header 레벨에서 먼저 통화를 입력하도록 되... blog.naver.com Group Currency 의 사용 설명을 이어나가자면, 아래와 같다. Group Currency 를 설정한 경우, 동일 통화 Base 로 재무제표를 구성할 수 있는 토대가 된다. 일반적으로 각 국가의 Company Code Currency 가 기능통화 역할을 하면서 단일 회사의 재무제표를 구성하는 기준이 된다. 추가로 Group Currency

220408 - 토도리브로 원목교구 한글 입체 판퍼즐 [내부링크]

아이에게 한글을 익히게 하기 위해 노력하는 일이 시작되었다. 아무렴 노력은 배신을 덜한다

수익성 분석(Profitability Analysis) : 마진 분석(Margin Analysis) [내부링크]

수익성 분석 유형 Cloud 에서는 On-premise 와는 다르게 CO-PA Type 선택이 주어지지 않는다. 단, 월중 손익분석은 Configuration 사항으로 관리된다. Version SAP ECC SAP S/4 HANA On-premise SAP S/4 HANA Cloud Margin Analysis Not available Recommended Mandotory Costing-Based Available Available Not available Combined Available Not available Not available Accounting-Based Available Not available Not available Margin Analysis 요약 S/4 HANA 의 Accounting-Based CO-PA 가 Margin Analysis 로 명칭이 변경되면서 기능이 강화되었다. Accounting-Based 에 비해 추가된 내용은 아래와 같다. 기존에 Pro

220503 - 레고 클래식 라지 조립 박스 10698 [내부링크]

현재 압도적 최애는 1부터 20까지 숫자판, 그리고 이토록 작은 블록은 해보지 않았다, Lego Transfer 가능할까,

220506 - 브루더 지프랭글러와 사륜바이크 [내부링크]

이제 막 오픈할 채비를 갖추고 있다. 과감했던 5세 어린이날 선물

#Cloud. 클라우드 서비스 모델(Cloud Service Model) [내부링크]

Cloud 에서 제공하는 서비스 모델을 알아보자. Cloud 는 일반적인 주제이고, SAP 에서도 제공하는 서비스의 유형이다. 계속해서 SAP 의 Cloud 솔루션에 대한 이해도를 높이기 위해 원론적인 내용 정리가 필요하다. Cloud Service Model - General Hardware/Platform/Application 영역까지 Service Provider 가 제공하는 영역 별로 구분된다. ※ On-Premise 클라우드 컴퓨팅이 본격적으로 도입되기 이전에 대부분의 기업에서 채택한 서비스 모델이다. 기본적으로 서버를 비롯한 Hardware 를 구입하고 O/S 를 설치하여 Software 를 운용하는 것이다. 위와 같은 일련의 행위들을 모두 기업에서 자체적으로 수행하는 방식이다. 1. IaaS (Infrastructure as a Service) Hardware 의 영역으로, 기존에 물리적으로 구매하여 보유하던 자산은 Cloud 회사를 통해 가상화 방식으로 제공받는다. 기

#Cloud. SAP ERP 클라우드 솔루션(SAP ERP Cloud Solution) [내부링크]

인터넷에 접속만 가능하다면, 물리적인 서버나 장치의 보유 없이도 언제든지 제약없이 업무를 할 수 있다. 굳이 알 필요조차 없다는 뜻에서 이러한 무형의 모습을 구름으로 표현하였고, 그래서 Cloud 라고 한다 . 전통적으로 On-Premise 는 Infra 부터 Software 까지 전체를 아우르는 영역이였다. Infra 에 대해서는 Cloud 도입을 통해 관리자체의 노력과 비용을 줄이려는 시도가 시작된 것 같다. 자체 Infra 를 보유하고 운용하는 것이 운영하는 기업 입장에서나 많은 수고가 들어가게 마련이다. SAP 의 Cloud Service Model 은 아직은 익숙하지 않다. 앞서 이야기했던 Infra 에서 Software 의 범위를 Cloud Model 화 해서 제공하는 영역으로 보고 있다. 그리고 Public 이니 Private 이니 하는 구분은 아래처럼 기능 차이의 모음처럼 보여진다. Public Fiori App 기반 표준화 기능만을 제공하고, 더해서 개발 Platfr

주요 개념(Key Concept) : 확장 원장(Extension Ledger) [내부링크]

개요 Ledger 는 원장으로 회계 데이터가 저장되는 제일 상위 Level 이다. ACDOCA (테이블) 에 보면, Leading Ledger 0L 이 기본으로 보일 것이다. 그래서 0L Ledger 외에 2L... 또 다른 Ledger 를 추가할 수 있다. Local Accounting Priciple 과 IFRS Accounting Principle 을 각각 지정하여 관리하는 형태이다. 관리회계와의 연결성 Leading Ledger 는 반드시 존재해야 하고 0L 은 관리회계의 버전 0 과 연결되어 데이터가 관리된다. (법적뷰) 그룹평가 또는 손익센터 평가 관점에서 0L 원장을 관리회계의 또 다른 버전과 연결도 가능하다. 연결할 경우, 재무회계의 실제 회계 데이터 생길 때마다 관리회계에서는 N 개 버전의 실제 데이터가 쌓이게 된다. 확장원장의 용도 확장원장은 위의 0L 또는 2L 처럼 기초 원장에 기반하여 데이터를 관리하는 형태이다. 전표 Posting 시에 원장 그룹 Blank

은행 회계(Bank Accounting) : 은행키(Bank Key) [내부링크]

Bank Accounting 에 대한 최초 관리 정보이다. Bank Key 생성 Bank Key 는 아래 FI01 (트랜잭션) 을 통해 가능하고, 기본적으로 Key 와 Text 만 입력하면 생성된다. 그리고 Bank Key 는 기본적으로 최대 15자리 Char 속성으로 관리할수 있다. Bank Key Rule 그리고 중요한 것은, Bank Key 라는 용어에서 알 수 있듯이 은행 코드 자체를 의미한다. 그 전에 아래 링크로 들어가서 (한국의 경우) 금융기관 별 코드 정보를 확인해볼 수 있다. Https://www.kftc.or.kr/kftc/data/EgovBankList.do 금융기관 별 대표 코드가 숫자 3자리로 구성된 것을 알 수 있다. 즉, 이 3자리 코드 기준으로 Bank Key 를 구성하면 대표 금융기관 식별이 용이하다. (어떤 은행인지 식별) Bank Key 자체를 금융기관의 대표 코드로 할지 (대표코드는 3자리) 실제 지점 코드로 할지는 각 회사의 선택의 영역으로 (지

은행 회계(Bank Accounting) : 주거래은행(House Bank) [내부링크]

은행키 (Bank Key) 이후에 생성하는 후속 기준정보이다. 은행키 (Bank Key) 와의 관계 은행키를 대표 은행코드라고 본다면, 주거래은행 (House Bank) 는 실제 존재하는 금융기관 지점코드 Level 로 하위 기준정보이다. 두 기준정보는 주거래은행 (House Bank) 기준으로 은행키 (Bank Key) 와 연결되어 있다. 단, 은행키나 주거래은행은 시스템 내부에서 관리하는 Code 이기 때문에 구축 시점에 Key Data 의 하나로 관리된다. FI12 (트랜잭션) 에서 아래와 같이 입력 값을 관리한다. 그리고 T012 (테이블) 에서 5자리 CHAR Type 으로 관리된다. 주거래은행 (House Bank) 의 용도 주거래은행은 실제 존재하는 지점 Level 의 은행코드를 시스템 내부에서 관리할 수 있도록 Code 화한 것이다. 전표 입력 시점에 Bank Account 의 경우, House Bank 와 Account ID 를 필수 입력하게 된다. 입력된 정보를 통

은행 회계(Bank Accounting) : 계정 ID(Account ID) [내부링크]

계정 ID 의 기술적 요건 계정 ID 는 Account ID 로 계좌번호를 SAP 내부적으로 식별할 수 있는 Code 이다. 아래 HKTID 칼럼으로 5자리 Code 로 생성하여 관리한다. 전표 입력 정보 앞서 House Bank 정보에서 기재했듯이 Bank 계정을 입력할 때, House Bank 와 Account ID 입력을 요구받는다. Business Partner 입력 정보 추가적으로 Business Partner 에서 Bank 정보를 입력할 때에는 계좌번호는 입력하나 Account ID 를 입력하지는 않는다. 계좌번호를 대체할 수 있는 IBAN Code 도 존재하는데, IBAN Code 는 유럽에 위치한 금융기관에서 사용하는 정보로 국가/은행코드/계좌번호 정보를 모두 포함하고 있다. 즉, IBAN Entry 에 정보를 입력하면 Bank Details 는 국가 별 사전 규칙에 의해서 자동 추출 가능한 정보가 된다. 아래는 IBAN Code 의 예시 규칙이다.

제품 원가계산(Product Costing) : 액티비티 유형(Activity Type) [내부링크]

액티비티 유형 개요 액티비티 유형 (Activity Type) 은 CO 모듈의 CO-PC 영역에서 사용되는 기준정보이다. 액티비티라는 말에서처럼 활동에 기인하여 발생한 정보를 수집하고 이를 저장하는 용도로 활용된다. 크게 보면 생산 영역의 수량에 대한 정보를 수집하고 CO 영역에서는 실제 또는 계획 단가 정보를 저장한다. 단가 정보를 저장하려면 총금액이 필요하고, 생산에서 수집한 수량정보를 취합하여 단가를 완성하는 방식이다. 간단하게 액티비티 유형 마스터에 대한 설명은 여기까지로 하고, 마스터 자체의 정보를 확인해보도록 하자. 참고로, 기본적으로 생산활동이 존재하는 산업 및 회사에서 노무비를 계산할 때, 사용하는 기준이므로 단순 구매/유통/수입을 주로 하는 법인에서는 이러한 개념이 사용되지 않는다. 액티비티 유형 기준정보 1. Activity Unit : 해당 활동이 발생하는 단위를 의미하는 것으로, Name 에 기재된 것처럼 시간단위 활동을 의미한다. 2. Cost Center C

주요 개념(Key Concept) : 관리회계 통화(Controlling Currency) [내부링크]

지난 번 Posting 에서는 관리회계 관점에서 Controlling Area 통화/Object 통화/Transaction 통화를 다뤘었다. FI 관점에서 통화유형 별 주요 특징을 알아보자. 통화 유형 Description Status T-Code 00 Document Currency ㄴ 회사코드통화와는 무관하게 발생한 거래를 기준으로 입력하는 통화이다. FB01 10 Company Code Currency ㄴ 회사코드 Level 로 통화 속성이 부여되는 통화유형이다. ㄴ 거래통화 (USD) ≠ 회사코드통화 (KRW) 인 경우, 회사코드통화로 Conversion 되어야 한다. OX02 20 Controlling Area Currency ㄴ 관리회계영역 단위로 통화 속성이 부여될 수 있다. OKKP 30 Group Currency ㄴ 클라이언트 Level 통화로, CO/AM/FI 상호간 원활한 데이터 전송을 목적으로 한다. ㄴ 관리회계영역통화 (USD) ≠ 회사코드통화 (KRW) 인

제품 원가계산(Product Costing) : 액티비티 단가(Activity Price) [내부링크]

앞서 액티비티 유형과 분할구조에 이어 실제 트랜잭션 수행에 대한 내용이다. 액티비티 단가 계산 프로세스는 계획과 실제의 프로세스가 대부분 일치하기 때문에, 계획 기준으로 설명하도록 한다. 아래 순서대로 Posting 이 이어지는 것은 참고하도록 한다. SAP CO 기준정보 : 액티비티 유형(Activity Type) 액티비티 유형 개요 액티비티 유형 (Activity Type) 은 CO 모듈의 CO-PC 영역에서 사용되는 기준정... blog.naver.com SAP CO 원가 : 분할구조(Splitting Structure) 분할 구조 분할 구조 (Splitting Structure) 는 CO-PC 모듈에서 사용되는 개념이다. CO 모듈의 Ma... blog.naver.com 액티비티 단가 계산 Flow 아래 순서대로 수행 시, KP26 (트랜잭션) 을 통해 계산된 결과 확인이 가능하다. 2번의 과정은, KP26 (트랜잭션) 내 코스트센터/액티비티 유형 별 수량 임의 입력을 통해

간접비 관리(Overhead Management) : 내부 오더 사전 정산(Internal Order Pre-Settlement) [내부링크]

개요 Margin Alalysis 의 또 다른 기능 중 하나는, 월 중 전표 발생 시점마다 Settlement 가 진행된다는 것이다. 원칙적으로는 KO88 (트랜잭션) 등으로 결산 시점에 수행하여 Settlement 내역을 반영하는 것이었으나, 실시간으로 PA 특성 값으로 Settlement 를 수행하는 것이 차이점이다. (단, 실제 정산 시점에 월 중에 생성된 전표의 취소 전표가 생성은 된다) Tutorial 1. Activate Derivation for Items without Profitability Segment Settlement Rule 관리 대상인 Internal Order 에 대해서 활성화를 체크한다. 2. Settlement Rule Internal Order 의 Settlement Rule 은 PSG 로 아래와 같이 등록되어 있는 상태이다. 3. Posting Document FB01 (트랜잭션) 을 통해 Internal Order 가 입력되도록 한다. (PA S

간접비 관리(Overhead Management) : 코스트센터 추출(Cost Center Derivation) [내부링크]

개요 Margin Alanysis 의 주요 기능 중 하나는, 월 중 입력한 코스트센터 기준으로 특성 값을 Derivation 하는 부분이다. Derivation 기능은 기존 KEDR (트랜잭션) 을 그대로 활용할 수 있고, PA 특성 값이 채워지기는 하나 Object Scope = OC 로 그대로 존재한다. 즉, 특성 값은 통계값으로 머무른다. Tutorial 1. Activate Derivation for Items without Profitability Segment 각 Object 별로 활성화 여부를 설정한다. 2. Define Characteristic Derivation 특정 코스트센터인 경우, Material Group 이 Derivation 되도록 설정한다. 3. Post Document 사전에 입력한 Derivation Rule 이 충족되도록 비용 전표를 생성한다. 4. 결과 값 분석 (3~4행은 적용하지 않은 비교군) 생성된 전표에는 Material 추출 값이 집계된

220621 - 디키 아웃도어 시리즈 캠퍼밴 [내부링크]

아이는 마트의 장난감 코너에서 진지하다. 표정을 보니, 그냥 지나치기 어렵다. 조금은 이해할 수 있다. 좋아하는 장난감이 분명한 아이다.

220630 - 타요 워터트랙 목욕놀이 [내부링크]

반사적으로 조립이 어려워보임을 감지한다. (이 장난감은 욕조안에서 물이 위에서 아래로 흘러가도록 해야,,)

일반 회계(General Ledger Accounting) : 조정 계정(Reconciliation Account) [내부링크]

조정 계정은 SAP New Install 케이스에서는 설명이 필요하다. SAP 에서는 매출채권이나 매입채무 또는 고정자산 G/L Account 에 대해서 조정 계정 Concept 을 적용한다. Concept 실제 원장에는 매출채권 계정이나 매입채무 계정으로 관리되나, (재무제표에는 원장 기준으로 표시된다) 보조 원장을 통해서 상세 고객/공급업체 코드가 관리되는 방식이다. 원장 관리 Level Account Group Recon Accout Type 보조 원장 관리 Level 매출채권 계정 ABST. Recon.account AP/AR D. Customers 고객 코드 A 고객 코드 B.. 매입채무 계정 K. Vendors 공급업체 코드 C 공급업체 코드 D.. 고정자산 계정 ANL. Fixed assets accounts A. Assets 고정자산 A... Create G/L Account - FS00 아래에서 보면 매출채권 계정 생성 시에 G/L Account Type 은 B/S

간접비 관리(Overhead Management) : 내부 오더(Internal Order) [내부링크]

내부 오더는 용도에 따라 확장성이 있는 CO Object 이다. WBS (프로젝트) 를 CO Object 로 활용하는 것과 기능적으로 유사하다고 볼 수 있으나, 마스터 자체 관리의 용이성 측면에서 일부 수월하다. 반대로 WBS 는 프로젝트 하위로 관리할 수 있는 계층구조를 보유하고 있다는 점에서 확장성 있게 활용할 수 있다. 아래의 있는 모든 기능은 내부 오더를 WBS 로 바꾸어도 동일한 효과를 거둘 수 있다. 관리 트랜잭션이나 일부 Config 에 차이가 있을 수 있다. 내부 오더의 주요 역할 Case Details 오더 별 손익분석 전표 생성 시점에 내부 오더를 Assignemnt 에 입력 ㄴ 내부 오더 단위를 손익 분석 단위로 활용 오더를 통계 값 활용 내부 오더 마스터 내 Statistical Order 를 체크 ㄴ Real CO Object 는 별도로 관리하고 통계 값으로 오더 정보를 활용 오더 정산 1. 내부 오더 마스터 생성 시 Settlement Rule 에 코스트센터

일반 회계(General Ledger Accounting) : 월중거래 및 재무결산(Daily Operation & Finance Closing) [내부링크]

월중거래 및 재무결산 각 회계거래 특징 재무회계 영역에서 발생하는 Daily Transaction 및 Closing 단계에서 발생하는 회계거래를 정리하였다. 7월 31일 및 8월 1일 거래를 제외하고는 일반적인 매입/매출 거래를 의미한다. 이외에 Accrual 의 거래가 존재할 것이고, 연말에 Balance Carryforward 작업이 있을 수 있겠다. (Balance Carryforward 는 회계거래를 일으키지는 않는다) 1. 매입 프로세스 매출이 발생하기 전에 재고자산 매입이 필요하다. 재고자산은 판매를 위해서 매입하는 자산을 의미한다. 재고자산 매입과 이후에 매입채무 인식 프로세스로 진행된다. 단, SAP 에서는 재고자산 매입과 송장 처리 Step 이 분리되어있고 상대계정을 GRIR 임시계정으로 인식한다. 위의 과정은 Purchase Order 를 통해 수행되고, Vendor Master 와의 거래를 뜻한다. (Vendor 와의 거래에서 선급금이 발생할 수 있고 본 거래표에

제품 원가계산(Product Costing) : 월중거래 및 원가결산(Daily Operation & Controlling Closing) [내부링크]

월중 제조원가의 투입 및 ML 정산까지 Flow 에 대한 설명이다. 실제로 발생한 제조원가가 실제원가로 정산되어 손익계산서에 보이는 형태를 살펴보자. 원가 결산 Flow ① 재무회계 마감 (더 이상 전표 처리가 진행되지 않도록 제한) > ② 제조간접비에 해당하는 비용 배부 (단계배부 또는 직접배부 방식을 통해 제조직접부서로 최종 배부) > ③ 코스트센터 액티비티 분할 과정을 통한 Activity Price Revaluation 수행 (실제 Price 로 재측정) > ④ 재공품 계산 (Target Cost 또는 Actual Cost 대비 재공품 계산) > ⑤ Variance 계산 (재공품이 아니거나 재공품을 제외하고 원가차이 계산) > ⑥ Settlement 수행 (재공품 또는 원가차이 전표 생성) > ⑦ Material Ledger 정산 (Inventory 또는 COGS 에 실제 가격차이 반영 및 전표 생성) 제조원가 결산 대상 Standard Cost : 속성을 갖고 있는 Mate

제품 원가계산(Product Costing) : 가공비 재평가(Processing Cost Revaluation) [내부링크]

제조원가 결산 과정에서 액티비티 유형을 활용한 단가 재계산을 통해 가공비 재평가 과정을 알아보자. Flow 상 계획 액티비티 단가 계산부터 시작된다. 계획단가 계산 버전 0 기준으로 코스트센터 분할 과정을 통해 액티비티 단가가 계산된다. 코스트센터에서 발생한 계획 금액 총액은 관련된 액티비티로 분할하는 단계이다. 분할하는 방법은 계획 액티비티 수량 또는 SKF 값 또는 등가계수를 활용할 수 있다. 계획단가 계산 코스트센터 금액 액티비티 수량 분할금액 (금액 ÷ 수량) 시간당 금액 (분할금액 ÷ 수량) 포장공정 10,000 노무시간 30 3,000 100 기계시간 70 7,000 100 생산오더 가공비 투입 본 과정은 월중에 생산실적에 투입되는 가공비 금액에 대한 계산부분이다. 가공비 금액은 계획단가 계산 시점에 확정된 (시간당 단가 X 해당 생산오더에 투입되는 액티비티 수량) 을 기준으로 반영된다. 즉, 수량은 실적이나 단가는 계획단가가 적용되는 것이다. 생산오더 가공비 투입 생산오

220722 - EDU 1331 1-100 수배열판 Hundreds Number Board [내부링크]

1부터 10 1부터 20 그리고 한참을 뛰어넘어 1부터 100 눈으로보는 것보다 손으로 만져봐야 더 신이난다. 글씨가 좀 작긴한데, 마음에 들어할까?

주요 개념(Key Concept) : 비즈니스 트랜잭션(Business Transaction) [내부링크]

SAP 의 CO 영역 내 Posting (Plan 또는 Actual) 이 발생할 때마다 Orgin Transaction 을 파악할 수 있는 비즈니스 트랜잭션 정보가 기록된다. 예시적으로 Actual 데이터가 기록되는 ACDOCA (테이블) 의 경우에 비즈니스 트랜잭션 칼럼이 존재한다. 이러한 정보를 바탕으로 발생한 데이터의 Orgin 을 원활하게 파악할 수 있다. SAP GUI 기준의 각 TCODE (Transaction Code) 에 따라 아래 비즈니스 트랜잭션이 1:1 로 Mapping 되거나 여러 개의 TCODE 당 동일한 비즈니스 트랜잭션으로 발생할 수 있다. 비즈니스 트랜잭션 in Planning area 1. Period-Based Transaction Description CPPP ABC Process Assessment: Plan FIPA Automatic Payment Schedule JVPL JV Planning Data Document KAZP Cost cente

주요 개념(Key Concept) : 관리회계 특징(Controlling Features) [내부링크]

관리회계를 구성하는 Sub Component 에 대한 내용이다. Cost Element Accounting (CO-OM-CEL) Cost Element 는 FI 에서 사용하는 계정 중, CO 에서 목적을 가지고 Managing 하는 대상이되는 특정 계정을 의미한다. 1. FS00 (트랜잭션) 상 G/L Account Type 분류 아래 2가지가 해당한다. Primary Costs or Revenue Secondary Costs 2. Cost Element Category 분류 위 2개 G/L Account Type 에 해당하는 경우에도, Controlling Area 에서 용도를 구체적으로 지정하는 것이 필요하다. Cost Element Category 라고 칭하며, 아래 Post 를 참고하자. https://blog.naver.com/someday84/221876045839 SAP CO 기준정보 : 원가요소 범주(Cost Elemenet Category) 관리회계 기준정보인 원가요

220830 - 브루더 지프 크로스컨트리 레이서 피규어 [내부링크]

머리 부상 위로 시리즈1 아들이 두 번째로 고대하던 자동차, 그리고 바퀴가 크게 나온 게 인상적,

220830 - 브루더 RAM 2500 파워웨건 두카티 [내부링크]

머리 부상 위로 시리즈2 아들이 첫 번째로 고대하던 자동차로써, 빨간색 큰 자동차 노래를 부르던 터 다음날 눈을 번쩍 뜨더니 냉큼 내 손을 잡고 이끈다. 아빠 자동차 새거 구경할래? 내가 소개시켜줄게

220904 - 변신 로봇 타요 [내부링크]

아이는 눈치도 못챘는데 변신이 된다는 말에 내가 신기하고 혹해서 이거 필요해? 물어보니 매우 필요하다고 한다

간접비 관리(Overhead Management) : 코스트센터 예산(Cost Center Budget) [내부링크]

코스트센터 단위의 가용성 점검 기능에 대한 소개이다. 관리회계에서 사용하는 많은 Object 에는 대부분 예산 가용성 점검이 포함되어 있었고, (WBS / 내부오더 그리고 FM Module 을 활용한 자금관리센터) 이번에는 코스트센터를 활용한 예산 가용성 점검을 알아보자 코스트센터의 예산 가용성 점검은 내부오더의 가용성 점검 방식과 유사하다. ㄴ 가용성 프로파일 등록 (경고 기준/에러 기준) ㄴ 예산 등록 ㄴ 예산 보충/전달/반환 ㄴ 전표 생성 ㄴ 예산 현황 레포트 Flow 관점에서 아래와 같이 소개한다. 1. Maintain Budget Availability Control Profile for Costs Profile 을 기준으로 가용성 점검을 위한 기간 및 기준 통화를 등록한다. 다시 Profile 하위의 가용성 점검 대상 G/L Account Group 을 등록한다. 이 단계를 수행하려면 그 전에 G/L Account Group 정보가 필요하다. (Manage Global H

제품 원가계산(Product Costing) : 이벤트 기준 생산 원가(Event-Based Production Cost) [내부링크]

이전에 Posting 한 Margin Analysis 관련 주제로 아래 내용이 있었다. ㄴ Internal Order 실시간 정산 ㄴ Cost Center Derivation 이어서 CO-PC 의 영역에도 실시간 정산의 내용을 담고 있는 Event-Based Production Cost 이 있고 이에 대한 소개이다. 우리가 기존에 알고 있던 방식은 Year/Month 종료 시점에 WIP 과 Variance 를 계산 및 Posting 하는 내용이고, 이에 대한 변화라고 볼 수 있다. 그리고 Event-Based Production Cost 는 Cost Object 를 (현재까지는) Production Order 방식을 채택한 경우에만 제공된다. 특징1 - WIP/Variance 계산 시점 If you post Goods Movements/order confirmation/change order status(DLV/TECO) to trigger EBWP postings. 위의 Trigg

220925 - Matchbox | 5-Pack MBX Off Road [내부링크]

출장 일정은 이제 반환점을 돌았다. 주말에 산책 겸 걷다가 가까운 Coop 에 들렀다. https://goo.gl/maps/kj8h2eDvcNr3Fbvo7 Coop Supermarché Vevey · Rue du Simplon 28, 1800 Vevey, 스위스 · 슈퍼마켓 goo.gl 요즘은 브루더 자동차만 좋아하는데, 작은 장난감이 통할지 모르겠다. 실제 자동차처럼 바퀴가 돌아야만 움직이는 맛이 나나보다. 그리고 통화하면서 사진보여주며 잠깐 물어보니 앞 바퀴 움직이는 거 맞아요?

221021 - 브루더 지프랭글러 부품 [내부링크]

아이에게 아주 좋은 루비콘 이미 망가져 버린 바퀴와 차문을 바라보며 도와줄 방법이 없을까, 고민하며 방법을 찾았다.

일반 회계(General Ledger Accounting) : 대체 조정계정 (Alternative Reconciliation Account) [내부링크]

Business Partner (Customer & Supplier) 에 대한 Reconciliation 계정 관리 방안이다. Default Setting Business Partner 의 Company Code 속성을 보면, Reconciliation Account 가 등록되어 있고 해당 Customer 또는 Supplier 코드를 입력하여 전표를 생성하면 실제 원장에는 아래 예시처럼 Reconciliation Account 로 계정이 인식된다. Cusotomer 나 Supplier 는 보조원장에서 관리되는 Level 이고 원장에는 G/L Account 로 Level 로 집계된다. Alternative Reconciliation Account 기본적으로 Cusomter & Supplier 마스터에 등록된 Reconciliation Account 의 변경은 불가능하다. 그러나, 첫 번째 예외사항은 Special G/L Indicator 를 활용하는 것이고 두 번째 예외사항은 AR/A

221027 - 브루더 랜드로버 [내부링크]

눈찢어짐의 위로는 앞바퀴 움직이는 자동차 시리즈로 보답 이제 바퀴가 움직이는 자동차도 제법 많다 후진을 하며 후방센서 소리까지 재연하는 아이의 주차하는 마음

221121 - 마우스로 클릭 뽀로로 코딩컴퓨터 [내부링크]

이제는 컴퓨터까지 섭렵 아빠 컴퓨터로 엑셀을 즐겨하던 아이가 이제는 컴퓨터가 생겼다. 아이가 무조건 사겠다고 들고 나온 것을 겨우 말리고 늦추어 아이의 나이에 맞아 보이는 이것으로 사줬다. 덕분에 아침저녁으로 컴퓨터로 업무 봐야된다고 난리 중

221025 - 친환경 원목 숫자 알파벳맞추기 - 마카롱1-20 숫자판 [내부링크]

1부터 20 가지고는 만들고 싶은 숫자 조합이 안된다고 하여, 같은 숫자판을 두 번째로 샀다. 숫자만 그려진게 아니라 숫자 모양으로 된 숫자가 더 좋은가 보다.

일반 회계(General Ledger Accounting) : BS 마이그레이션(BS Migration) [내부링크]

연중에 최초 BS 마이그레이션에 대한 부분이다. 2021년 최초 사업을 개시하여 (Old) 2022년 상반기 마감 이후 (New) 2022년 상반기 잔액을 New System 으로 BS 마이그레이션을 수행하는 경우이다. 1. 2021년 거래 및 PL 자료 2021년에 발생한 거래로 2021년의 당기순이익 3,300 은 이익잉여금으로 2022년에 이월된 상태이다. 2. 2022년 상반기 거래 및 PL 자료 2022년 상반기까지 발생한 거래로 2022년 상반기 당기순이익은 350 이다. 3. 마이그레이션 1차 2022년 상반기 누적 BS 계정과 2021년 12월 이익잉여금이 마이그레이션 대상이다 . BS 계정의 상대계정은 Offset 계정을 사용하여 마이그레이션 전표를 생성한다. 4. 마이그레이션 2차 마이그레이션 과정에서 발생한 Offset 계정의 Balance 를 0 으로 조정하면서, 2022년 상반기 PL 계정의 누적 실적도 마이그레이션 할 수 있다. 그리고 Offset 계정의 합

일반 회계(General Ledger Accounting) : 미결항목 & 반제(Opens Item & Clearing) [내부링크]

Clearing 의 개념 Open Item (미결) 상태의 전표를 Clearing (반제) 한다라고 표현한다. FS00 (트랜잭션) 으로 알려진 G/L Account 의 회사코드 속성 중 아래 항목과 관련이 있다 보통 BS 계정은 누적으로 잔액이 관리되는 개념이고, Open Item Management 가 Yes 로 되어있다면 말그대로 Open Item 을 관리한다는 의미이다. Case1. AR/AP (Reconcilation accounts) Open Item 의 의미를 거래의 시작과 종료의 관점에서 살펴보자. 고객과의 거래에서 매출채권이 발생하는 경우, 이 거래의 시작은 채권의 생성이다. 이 채권은 대금을 수령해야 종료되는 것으로, 대금 수령하기 전의 상태가 Open Item 상태가 되는 것이다. Customer 와 Supplier 는 당연 Open Item 관리대상이라 아래 GRIR 계정과는 Open Item 여부 관리하지 않는다. 발생한 채권과 입금된 현금과의 Clearing

일반 회계(General Ledger Accounting) : GRIR(Goods Received/Invoice Received) [내부링크]

직전에 Clearing 개념을 설명하면서 GRIR 계정의 발생 형태도 포함했다. 이번엔 Purchase Order 기준으로 실제 GRIR 계정의 세부 내역을 살펴보도록 하자. 구매오더 관점 분석 아래 2개의 구매오더를 살펴보자. 첫 번째 구매오더의 세부내역을 살펴보는 것으로, 입고 전표와 송장 전표가 이미 모두 생성되었고, 금액과 수량 관점에서 Balance 가 0 이 된 것을 확인할 수 있다. 회계적인 관점에서 보면, 입고 시점에 발생한 GRIR 금액과 송장 발행 시점에 발생한 GRIR 금액이 모두 발생했고 일치한다는 의미이다. 아래의 예시에서 확인이 가능하다. 입고와 송장 수령이 모두 정상적으로 발생했고 다만 Clearing 만 미진행된 상태이다. 이 상태에서 Clearing 을 진행하지 않더라도 보통 GRIR 은 임시계정이라 재무제표에 포함되지 않기 때문에 Balance Sheet 상 변화는 없다. 다만 Open Items 관리 관점에서는 여전히 미결상태로 남아있게 된다. 이

일반 회계(General Ledger Accounting) : 미결 항목 자동 반제(Clear Open Items Automatically) [내부링크]

앞서 Clearing 의 개념을 설명했고, 이제 Clearing 프로그램을 통해서 진행되는 선행/후행 관계에 대해서 아래의 프로그램의 작동법을 알아보자. F.13 (Automatic Clearing) This program clears open items from customer, vendor and G/L accounts (in particular, GR/IR clearing accounts) automatically. The program selects all accounts that are specified in the value sets and that have debit and credit postings. Clearing 대상 Open Item 이 관리되는 Customer AR, Supplier AP, 일반 GL 이 그 대상이다. ㄴ Customer AR : 채권과 입금전표에 대한 Clearing ㄴ Supplier AP : 채무와 지급전표에 대한 Clearing ㄴ 일반

일반 회계(General Ledger Accounting) : 외화 평가 실행(Perform Foreign Currency Valuation) [내부링크]

외화 거래의 후속 결산 프로세스에 대해서 알아보자, 외화 거래 SAP 에서 외화 거래란, 회사코드 통화 ≠ 거래 통화를 의미한다. 한국 회사의 회사코드 통화 (기능 통화) 는 KRW 원화이다. 해외 업체와의 USD 달러로 거래를 해서 장부에 USD 로 기록했다면 거래 통화는 USD 이다. 이와 같은 경우, USD 달러의 환율 변동에 따른 원화 가치를 발생 시점과 평가 시점 (결산) 에 각각 기록하게 된다. 이처럼 환율이 고정이 아닌 상태에서는 원화 가치는 계속해서 변경이 될 수 있다. 외화 거래의 발생 12월 중에 한국 회사에서 100.00 USD 거래가 발생했고 거래 발생 시점 (시스템 반영일 기준) 환율은 USD 1 당 1,500 KRW 였다. 100.00 USD 입력 시점에 환율 정보를 불러와서 Local Currency 인 150,000 KRW 가 실시간으로 반영된다. Dr : 매출 채권 100.00 USD (140,000 KRW) - 외화 평가 대상 Cr : 매출 100.0

일반 회계(General Ledger Accounting) : 입고/송장 수령 반제 재전기(Repost GR/IR Clearing) [내부링크]

GRIR 의 발생과 반제 이후에 마감 단계의 최종 Task 이다. SAP Gui 트랜잭션 코드 기준으로 F.19 이다. 1. GRIR 의 발생 Purchase Order 를 통해 입고 전표와 송장 전표가 분리되어 발생한다. 그리고 GRIR 은 임시 계정의 성격이고 보통 재무제표에 포함되지 않는다. 특정 Purchase Order 에 대한 입고/송장 전표가 모두 당월에 발생하지 않은 경우, GRIR Balance 에 대한 후속 처리가 필요하다. 2. GRIR Balance 처리 대상 대상은 입고전표만 존재하거나 송장전표만 존재하는 Purchase Order 이다. 아래의 예시는 특정 Purchase Order 의 세부사항으로 입고전표는 존재하나 송장전표가 발생하지 않은 상태이다. 3. GRIR 처리 기준 그리고 아래의 Transaction Key 기준으로 자동계정지정을 위한 G/L 계정이 Assign 되어 있어야한다. ㄴ BNG : 송장 전표만 생성되었고 입고 전표는 생성되지 않은 사

채무(Accounts Payable) : 구매오더 가격차이(Purchase Order Price Variance) [내부링크]

구매오더를 통해 외부 자재를 매입할 경우, 발생할 수 있는 가격차이 유형이다. 보통은 표준원가 Base 로 자재를 평가하는 경우에만 아래 내용이 유효하다. 표준원가 자재는 기중에 표준원가 기준으로 입고/출고가 발생하나, 구매오더를 통한 매입가격이 다르게 입력된 경우 발생할 수 있는 Case 이다. 더불어 외환차손익은 입고시점과 송장처리 시점의 환율의 변동이 발생한 경우에 이를 별도의 계정으로 평가한다. 아래의 거래를 통해서 발생한 차이금액은, 관리회계 자재원장 결산 시점에 Actual Price 를 산출하기 위한 배부대상 금액이 된다. Case1. 입고 가격차이 발생 및 송장 외환차익 발생 ㄴ 가격차이 손실 : 입고 시 PRD 거래 유형으로 발생하며 원재료 표준원가와 매입가격의 차이로 발생한다. ㄴ 외환차익 : KDM 거래 유형으로 발생하며 입고와 송장 처리 시점 환율 (하락) 차이로 발생한다. Case2. 입고 가격차이 발생 및 송장 외환차손 발생 ㄴ 가격차이 손실 : 입고 시 P

수익성 분석(Profitability Analysis) : 계정 중심 손익계산서(Accounting based Profit&Loss) [내부링크]

개요 새로운 S/4 HANA Implementation Project 가 많아짐에 따라 구축 시에 짚고 넘어가야 하는 주제 중 하나이다. SAP Recommend 는 Accounting Based 를 사용하는 것이며, 최신 Trend 및 Technology 를 적용하는 Cloud Model 에서는 선택 대안지에 Costing Based 란 없다. ACDOCA Table (Universial Ledger) 기반의 SAP S/4 HANA 에서 구조적 유연성을 갖고 있고, 계정 기반의 모든 데이터 발생 및 집계 그리고 분석까지 Accounting Based 가 갖고 있는 최대 장점이다. 더불어 컨설턴트 입장에서 Configuraiton 대상도 상대적으로 많지 않다. 다만, 모든 분석 지표들이 발생하려면 계정 (G/L Account) 가 반드시 있어야 하고 혹여 그러한 지표들이 보통의 재무 계정이 아니라면 통계 목적으로라도 계정 생성이 불가피하다. Costing Based 의 경우, 시간이

221226 - 변신 로봇 로기 [내부링크]

변신 로봇 타요 변신 로봇 로기 이제 두 친구가 생겼고, 누가누가 빨리 변신하는 지 만들어보자,

230124 - 포켓몬스터 체인징 피규어 시리즈 몬스터볼 피카츄/이브이 [내부링크]

타요에서 새로운 캐릭터로 넘어가려는 시기, 피카츄가 지금 마음에 와닿은 것 같다, 피카츄 피카츄하면 좋아한다. 포켓몰 안에 넣기위한 변신은 조금 어려움, 넣다가 부러질 것 같은 느낌,

주요 개념(Key Concept) : 모듈 간 유효성 검사(Cross Module Validation) [내부링크]

SAP 에서는 여러 Module 영역에서 Closing Period 를 관리할 수 있다. 재무회계 기본적으로 재무회계에서는 회사코드 단위 및 계정의 속성 별로 Open Period 를 관리할 수 있다. 전표 헤더의 Posting Date 기준으로 마감된 Period 에 해당할 경우, 전표 생성이 제한된다. 관리회계 관리회계 비즈니스 트랜잭션 단위로 Open/Close 여부를 관리할 있는데, 재무회계가 Open 된 상태라도 특정 비즈니스 트랜잭션만을 Close 할 수 있다. 반대의 경우, 재무회계 기간이 Close 된 상태에서 특정 비즈니스 트랜잭션을 Open 하더라도 재무회계 기간 Close 로 인해 후속 트랜잭션 생성은 제한된다. 원가회계 CKMLCP (트랜잭션) 을 통해 자재원장 결산을 수행할 수 있다. Posting 이전에 Lock 을 설정하면 Material Document 생성을 제한할 수 있다. Material Ledger Posting 시에 아래와 같은 차이가 존재한다.

제품 원가계산(Product Costing) : 월중 표준원가 릴리스(Release new price in the month) [내부링크]

개요 기존 표준원가가 존재하는 상황에서, 월중에 새롭게 원가추정/Mark/Release 까지 수행하는 경우이다. 동일월에 Material Document 단위로 기존 표준원가와 신규 표준원가가 동시에 존재하게 된다. 단, 재고가 존재하는 경우로 가격 변경 전표 (Revaluation) 가 생성된다. 각 전표 Level 에서는 (신규 표준원가 Release) 전후로 서로 다른 표준원가가 조회되게 된다. 이후에 Material Ledger Settlement 를 수행하게 되면, 발생한 가격차이가 Consumption 과 Ending Inventory 에 Allocation 되면서 Actual Price 는 동일월에 같은 단가로 반영되게 된다. 신규 Material 의 경우는 필요한 시점에 Release 를 수행할 수 있고 기존 Material 의 경우에도 재고가 존재하더라도 Release 수행은 가능하다. 다만 동일월에 최대 2개의 서로 다른 표준원가가 존재하는 것은 감안이 필요하다.

제품 원가계산(Product Costing) : 기간 마감 메시지(Periodic Closing Message) [내부링크]

개요 FCM 영역에서 기간 마감을 설정할 수 있는 영역이 있고, 이에 따른 Validation 을 알아보도록 하자. 다양한 Case 가 존재하다보니 생각보다 내용이 복잡하나, 각 영역 별로 영향도는 아래와 같다. 기본적으로 자재 Open Period 기준으로 재무회계에서 설정한 마감 기간과 자재원장 결산 (CKMLCP) 상 Lock/Posting 여부에 따른 영향도를 기재하였다. Material Document 외에도 일반 Financial Document 의 경우, 재무회계 및 관리회계의 기간 마감 기준을 따른다. 기간 마감 Case 별 Return Message MMPV (트랜잭션) OB52 (트랜잭션) CKMLCP (트랜잭션) MIGO (트랜잭션) Return Message 자재 Open Period 재무 Open Period Locked / Posting Posting Period 23년 7월 23년 5월~ N/A 23년 5월 Posting only possible in pe

채무(Accounts Payable) : 자동 지급 메세지(Automatic Payment Message) [내부링크]

개요 F110 (트랜잭션) 을 통해 다수의 Open Items 에 대한 Clearing (Payment) 프로세스를 수행할 수 있다. 이 경우, Business Partner 에 대한 Value 유지보수 여부와 Configuraiton 값에 따라서 Error 메시지가 발생할 수 있다. 이에 대한 선행 조건 조합에 대해서 알아보자. Result 1. Supplier Master Payment Method 와 Bank Accounts 정보는 필수이다. 2. Configuration 각 Hosue Bank & Account ID & 통화 & 지급방법 별 은행 계정 등록이 필요하다.

간접비 관리(Overhead Management) : 마이너스 추적 요인 스케일링(Negative Tracing Factors) [내부링크]

개요 사이클에서 배부동인을 결정할 때 사용되는 스케일링(Scaling) 에 대해서 알아보자. 스케일링(Scaling) 은 Sender 로부터 발생한 비용을 Receiver 로 배부할 때, 그 배부 기준은 Receiver 별로 산정되게 되는데 특이사항이 존재하는 Value (마이너스 등) 에 대한 기준을 관리하는 것이다. 그리고 아래 시나리오는 Accounting Based 기준으로 정리된 것이다. 특이사항은 정상 매출액은 마이너스로 표시된 것이다. Result 1. 표준화 없음 ㄴ 마이너스 매출인 경우, 비용 배부금액이 차감되었다. 2. 표준 스케일링 ㄴ 마이너스 매출인 500 만큼 나머지 Matrial 에 합산되어, 배부비율이 재 결정되었다. 3. 절대값 ㄴ 정상 매출과 마이너스 매출 모두 + 로 치환 배부비율이 결정되었다. 4. 마이너스 추적요인을 0 으로 설정 ㄴ 정상 매출은 0 이 되고, 마이너스 매출만 정상 매출로 감안되어 모든 비용을 배부 받았다. 5. 최소 마이너스 추적

200210 - Matchbox 탑건: Maverick 차량 및 비행기 5팩 [내부링크]

두번째 출장도 COOP 에서 아이 선물 최종 생소한 모습의 자동차와 특별한 전투기

230327 - 브레드이발소 1 70조각 퍼즐 [내부링크]

이제는 무료한 퍼즐 시리즈 그렇지만 좋아하는 캐릭터의 시작

간접비 관리(Overhead Management) : 정산 & 배부(Settlement & Allocation) [내부링크]

관리회계 영역에서 정산과 배부의 역할은 아래와 같이 조금 다르게 이해할 수 있다. 그리고 근본적으로 관리회계에서 주로 다루게 되는 데이터 관리 측면이란, 이 2 가지로 크게 구분할 수 있다. 재무회계 또는 구매/생산/영업에서 생성된 데이터 (Finance Document) 모두는 관리회계 대상으로 보게 되고 각 회사의 필요한 과정 (정산과 배부) 을 거쳐 재무제표의 일부 또는 분석 데이터의 역할을 할 수 있다. 1. 발생 (1) SCM Document SCM (구매/생산/영업) 프로세스 간 발생하는 Operation 문서가 있고 이에 후속적으로 Finance Document 가 발생하게 된다. 주요 Operation 문서 유형은 아래와 같다. Operation 문서 간 연계를 위해 생성되는 문서를 포함하고, 최종 단계에서는 재무회계 문서 (Journal Entry) 가 생성되는 방식이다. (2) Finance Document Operation 문서의 최종 단계에서 생성된 Financ

#Site. SAP 에서 제공하는 표준 가이드1 [내부링크]

이번에 자유롭게 쓰는 새로운 주제를 만들었다. SAP 는 기업용 ERP Solution 중 Global 에서 신뢰받는 점유율% 이 높은 솔루션 중 하나이다. 그리고 SAP 입문을 위한 두 가지 유용한 사이트를 소개하겠다. SAP 의 기본부터 Expert 영역에 이르기까지 충분한 자료를 찾을 수 있다고 본다. 첫 번째 - SAP Help 그 방대한 양 때문에 검색해서 원하는 정보를 꼭 맞게 찾기는 어려울 수는 있지만, SAP 관련되어 누락된 데이터는 없다고 보여진다. 그리고 과거의 On-Premise 부터 새롭게 제공되는 Cloud Soultion 까지 그 Details 이 상당하고, 각 버전 별로 Update 가 지속적으로 이후어지기 때문에 유용하다. 원하는 주제를 찾았으면 해당 페이지를 PDF 로 내려받을 수도 있다. 궁금한 내용은 Google 도 좋지만, SAP Help 를 보면서 SAP Standard 구조를 익히는 것도 필요한 과정이다. https://help.sap.com/

#Site. SAP 에서 제공하는 표준 가이드2 [내부링크]

SAP 표준 관점에서 유용한 정보를 제공하는 Url 이 몇 가지 더 있다 . SAP Best Practices SAP Best Practices 를 각 시나리오를 On-Premise 와 Cloud Model 별로 구분하여 제공하고 있다. 시나리오 단위로 Tutorial 및 Script 가 Process 흐름대로 정리되어 있음으로 표준 관점의 시나리오를 익히는데 굉장히 유용하다. https://rapid.sap.com/bp/# SAP Best Practices Explorer Application is loading ...... rapid.sap.com Fiori App Library 아직은 T-Code 기반의 GUI 용 프로그램을 많이 사용하고 있지만 Web 기반 Fiori App 은 지속적으로 Release 되고 있다. Fiori App 을 통해서 혁신적인 새로운 기술들이 계속해서 반영되고 있는 상태이다. 아래 Url 을 통해서 현재까지 출시된 Fiori App 에 대한 자세한 정

230408 - 아톰 NEW 공룡사파리 [내부링크]

서로 머뭇머뭇 그리고 긴가민가 싶으면서 안겨준 공룡 장난감, 괜찮을까?

#Module. SAP Core Module [내부링크]

SAP 를 처음 시작할 때, Module 을 선택하는 과정을 겪게 된다. Module 은 보통 아래 Core 에 해당하는 영역을 의미한다. 아마도 아래 Core 에 해당하는 5개 Module 을 한 사람이 제대로 이해하고 업무를 수행하기에는 Coverage 가 넓다고 보기 때문에 이렇게 Module 이 구분되게 된게 아닐지 싶다. 다만 회사의 규모가 다소 적거나 Operation 관점의 업무 단위가 많지 않을 경우, FCM / SCM 단위로 업무를 같이 수행하기도 하기도 한다. 아래 Core Module 이 일반적으로 많이 알려져있고, 제조업에 해당하는 회사라면 필수적으로 필요한 영역이기 때문에 기본이 되는 Module 이라고 보면 된다. 회사 내부 생산 행위가 없을 경우, PP Module 이 불필요할 수 있고, 주된 재고자산에 대한 거래가 없을 경우, MM 과 SD 가 선택적으로 제외될 수 있다. 단, 재고자산이 아니더라도 MM 과 SD 가 존재할 수는 있으나, 그 범위는 상당히

#ABAP. SAP Language for Development [내부링크]

SAP 에서는 Standard Process 기반의 프로그램을 기본으로 제공하고 있다. (Advanced Business Application Programming) 다만, To-Be Process Design 시점에 발생한 표준과의 Gap 에 대해서는 사실 여러 가지 가이드가 있겠지만, 많은 프로젝트에서 신규 프로그램 개발을 그 대안으로 많이 제시하고 있다. 개발 프로그램은 SAP 표준 프로세스가 존재하지 않거나, 표준 프로세스로 진행하기에 복잡한 과정이 필요하여 비효율적인 상황인 경우가 대표적이다. e.g. 복잡한 과정의 데이터를 발췌하여 이에 대한 대량 전표 보통은 SAP 에서도 국가/산업군 특화사항을 감안하여 표준 프로세스를 제공하기 때문에, 개발 프로그램이 제공되는 경우는 구축 회사 또는 PI 의 요구사항으로 인한 부분이 상당할 것으로 예상한다. 회사/부서/사용자 특화 개발 프로그램이 많아지게 되면, Operation 관점에서 관리 대상 프로그램이 많아지고 작은 비즈니스 변

230420 - 지구본 학습용 서전지구본 [내부링크]

아이의 흥미가 옮겨가는 순서 구구단 > 우리나라 지도 > 세계지도 > 태양계 세계지도에서의 우리나라의 위치 그리고 태양계에서의 지구의 모습 사이에서 혼란이 있는 중

230427 - 레고 프렌즈 41730 오텀 하우스 [내부링크]

계속해서 새로운 건물을 만들고 싶어하는 아이를 위한 선물

일반 회계(General Ledger Accounting) : 불량 채권 평가(Bad debt valaution) [내부링크]

Customer 와의 거래에서 발생한 거래에 대한 Bad Debt Valuation 에 대해서 알아보자 간단하게 요약하면, 대손충당금을 인식하기 위해 Open Item 상태의 고객 채권을 평가하는 단계이다. 1. Valuation Key Configuration 항목으로, 신규로 Valuation Key 를 생성하여 Overdue (만기일 초과) 기간 별 대손충당율 정보를 설정할 수 있다. 2. Customer Master (1) Valuation Key 직전에 생성한 Valuation Key 는 Customer Master 의 Company Code View 상 Value Adjustment 칼럼에 등록하여 연동할 수 있다. (2) Payment Terms Payment Temrs 은 Customer 의 경우, 입금 조건으로 관리하는 항목이다. Customer Invoice 발생 건에 대한 입금의 기한을 설정하는 항목으로 Code 및 Attribution 은 Configuratio

채무(Accounts Payable) : 자동 지급(Automatic Payment) [내부링크]

매입채무 발생 이후에 Outgonig payment process 에 대해서 알아보자, 이미 발생한 Supplier open items 전체에 대한 Mass processing 방안이다. 1. Prerequisite Business partner (Supplier) 에 대한 Master 등록이 전제사항이다. (1) Terms of Payment (Payment terms) Supplier 의 경우, 지급 조건으로 Supplier invoice 발생 시점에 Baseline date 를 기준으로 Net due date 를 결정짓는 요소가 된다. 아래의 경우는, 즉시 지급으로 Baseline date = Net due date 가 된다. (2) Payment Methods 지급 조건을 의미하는 것으로, Outgoing Payment 를 위한 지급 조건 (T) 를 입력하도록 한다. (3) Bank details Supplier 에 대한 Bank key, Bank account number.

자산 회계(Asset Accounting) : 감가상각(Depreciation) [내부링크]

감가상각은 유무형자산을 비용화하는 과정이다. 회사 내 사용 목적으로 취득한 자산을 (취득가액 ÷ 내용연수) 를 기준으로 기간으로 비용을 반영하게 된다. 1. 자산 마스터 생성 (1) 기본 정보 Asset Accounting 영역에서 발생하는 모든 Transaction 은 Asset 이라는 마스터를 기준으로 하기 때문에, 선행 작업은 반드시 Asset 마스터의 생성으로부터 시작한다. Asset Master 의 생성은 간단하다. Asset Class (자산 유형) 과 이에 대한 Description, Cost Object (코스트센터 등) 만 입력하면 다른 Value 는 Asset Class 에 지정된 기본 값이 입력된다. (2) 기준 정보 감가상각 실행의 최소 단위가 회사코드/Accounting Principal 이다. Accounting Principal Accounting Principal 을 아래와 같은 연관관계를 갖고 있다. (Ledger > Accounting Principa

230430 - WOW WORLD Playsets / Track Sets [내부링크]

갑작스레 들른 TJ MAX 에서, 때마침 아이가 좋아하는 공룡 세트를 발견했다. 그리고 그냥 지나칠 수 없어 두 제품을 골랐다. Medium T-Rex, Triceratops, Pachycephalosaurus, & Velociraptor - 4pk Medium Brachiosaurus, Therizinosaurus, Carnotaurus & Stegosaurus - 4pk

#Cloud. 퍼블릭 클라우드 특징(Public Cloud Feature) [내부링크]

SAP S/4HANA Cloud, public edition SAP 에 대해서 알아보자 Public Cloud 는 SAP 에서 Release 된 Product 군이다 보통 우리가 접해서 알고 있는 SAP GUI 화면은 On-Premise 환경하에 사용하는 경우가 대부분이거나, Infrastructure 만 Cloud 사업자 제공 환경을 띄는 경우가 다수이다. 그렇다면 Public Cloud 환경의 주요 차이점은 다음과 같다. Business Model 구독형 모델이다. 보통 Cloud 의 경우 구독형 모델을 많이 따르게 된다. 즉, 사용 기간 동안에는 구독 회사에서 관리하지만 사용 계약이 종료되면 구독이 종료되는 것 뿐이다. User Interface SAP GUI 화면은 더 이상 존재하지 않는다. 실시간 Update 된 최신의 Fiori App 만이 제공된다. 그렇지만 One Source Base 이기 때문에 SAP S4 HANA 의 Logic 은 동일하게 적용된다. SAP GUI

제품 원가계산(Product Costing) : 표준원가 평가(Inventory Valuation) [내부링크]

SAP 에서 재고자산을 평가하는 방법 중 하나로 표준원가법을 사용할 수 있다. 표준원가법을 통해 평가된 재고자산의 Flow 이해를 위해 회계 원장의 거래와 연결된 자재원장을 살펴보도록 하자. 재고자산을 평가하는 방법에 대해서 표준원가법 & 이동평균법에 대해서 간략히 소개한 기존 Post 도 참고하도록 하자. https://blog.naver.com/someday84/222582987423 SAP CO 원가 : 재고자산 평가(Inventory Valuation) 이번엔 재고자산의 단가를 결정하는 여러 가지 방법이다. SAP 에서는 Material Type 별 내부생산 또는... blog.naver.com 회계 원장 (1) 입고 & 출고 월 중에 발생하는 Material Document 기준으로 기록된 Finance Document 의 예시 흐름이다. 기본적으로 입출고 Document 의 금액은 Standard Price * Qty 기준으로 측정된다. (2) 출고 & 기말 재고 결산월에

실시간 검색어