Hyowon's Archive

https://academyofideas.com/

- 로그인 창 텍스트 수정하려고 하니 이런 창이 뜸. 오브젝트 그 자체를 편집하지 못하고 수정 버전을 새 이름으로 따서 만들라고 시스템이 강제하는 문제가 생김

1. 이상한 점 발견..

- DEV에 있는 ZCOMM 패키지는 QAS와 PRD에 없음..

- 그러면 DEV에만 있는 패키지의 오브젝트를 QAS와 PRD에 전송한 셈

2. 문서 오브젝트 하나 만들어서 테스트

- 테스트로 문서 오브젝트 하나 만들어서 DEV->QAS로 넘겼는데 여전히 QAS에서 편집불가(패키지는 DEV, QAS 모두 있었음)

- 다만 CTS를 생성하면서 해당 테스트 문서 오브젝트를 삭제할 수는 있었음

- 삭제했는데도 불구하고 같은 이름으로 문서 오브젝트 생성하니 DEV에서 넘어온 문서 오브젝트와 같은 패키지가 자동으로 입력됨..

- 새로 만든 것도 "수정 생성" 다이얼로그 뜨면서 직접 편집 불가... 문서를 DEV이외에서는 편집 못하도록 만들었나?

3. 대체안

- DEV에서 QAS - PRD로 CTS 넘겨서 적용함

- 운영 로그온 텍스트 변경은 DEV - QAS - PRD해서 변경하고

- 품질 로그온 텍스트 변경은 DEV - QAS 까지만 반영해서 변경

- 개발 로그온 텍스트 변경은 마지막에 다시 해서 다른 서버로 반영 하지 않는 방식으로 변경했음

참고 URL

https://community.sap.com/t5/enterprise-resource-planning-q-a/difference-between-migo-and-mb1c/qaq-p/5198565

개요

• 자재를 판매하기 전에 플랜트나 저장위치에 재고를 가지고 있어야 한다. 
• 재고를 보유하는 방법은 자동과 수동 2가지로 나뉜다
• 재고를 자동으로 보유한다는 것은 판매 오더를 생성하면 이에 따라 MRP가 진행되고 시스템이 자동적으로 특정 날짜에 대한 자재 수요를 일으킨다. 이 수요는 다시 PP모듈의 계획 오더(planned order)를 생성하고 계획 오더에 따라 생산 오더(production order)가 생성된다. 자재의 생산이 완료되면 생산 업로드(production upload)가 완료된 것이다.
• 다른 방법으로는 MB1C나 MIGO와 같은 트랜잭션을 이용하여 재고를 생성하는 것이 있다. 이 절차는 적절한 MRP가 진행되지 않았을 때 행해진다. 이 과정에서 WIP(재공품)이나 원재료가 특정 코스트 센터로 출고되고 GL 계정에 계상된다. 출고된 수량은 완제품의 양과 스크랩의 양의 합계인 소비된 자재에 기초하여 계산된다.
• 생산이 아니라 다른 상품을 공급자로부터 사와서 파는 유통업의 형태도 있다.

What do you mean by production upload?
- 판매를 위해 재고를 생산하고 입고처리하는 것을 의미한다.

What are the T-codes for production upload?
- MIGO나 MB1C에서 입고를 처리할 수 있다.

What are the processes for production upload?

- 자동화의 경우 MRP를 통한 자동 계산되는 생산 오더 완료 시의 생산 입고

- 수기로 입력할 시 MIGO에서 입고

- MIGO는 오더 다음 과정으로 자재문서를 발생시키는 트랜잭션이다. 오더가 반드시 필요한 것은 아니다.

- 판매오더 - 출하 - 자재문서 단계를 거치듯이 구매오더 - 입고, 생산오더 - 입고의 과정을 거친다고 보면 된다.

- MIGO는 MB1A, MB1B, MB1C 3가지 트랜잭션을 합친 새로운 트랜잭션에 해당한다

- MB1A는 출고, MB1B는 이전 전기, MB1C는 기타 입고 기능을 가진 트랜잭션들이며 이들을 합쳐서 자재의 이동을 모두 소화하는 MIGO화면이 생성되었다.

What is the movement type for production upload?

- 오더 없이 할 수 있는 521 이동유형 등이 있다.

What is the T-code to display stock on posting date?
- MB5B(전기일 시점 재고)

What is the T-code for display stock on current date with all stock type?

- MMBE - 가용, 보류 등 모든 재고를 볼 수 있다.

How to display quality stock status of a material?

- MB52가면 볼수있음

How can you display stock status plant-wise in a single run?
- MB 가면 하나의 플랜트를 지정해서 플랜트를 기준으로 재고를 확인할 수 있다.

MEMO

- MM과 관련된 화면이라 책의 설명이 부실함.. 간단하게 실습만 하고 넘어감

- 나중에 MM 공부할 때 제대로 해야할듯

- production upload란 개념도 일반적으로 쓰이는 개념이 아닌 저자가 만든 개념인듯 판매오더-MRP-계획오더-생산오더-생산입고로 이루어지는 과정을 표현한 것 같음

EASY ABAP 교재 공부 순서 (컨설턴트에게 추천 받은 거)

첫 회독 시 공부 순서는 이대로 하고

2회독 때는 전부 다 자세히 공부하기

오류나 오타 지적해주시면 반영하겠습니다

notion 주소

https://totoda.notion.site/2-5fbf29d84e474ad2abe7ac7cdf0981e9?pvs=74

문제 풀 때는 첫번째 파일로 

마지막 이틀 정도는 파이널 특강으로

시험 날은 시험 시작 5분전 파일로 암기사항만 눈으로 훑고 가시면 될 듯 합니다.

화이팅

영업 조직(판매 조직);Sales Organization이란?

- 재화와 서비스의 판매에 책임을 지는 단위. 법적 책임이나 고객의 클레임에 대한 책임을 포함할 수 있다.(실제로 회사의 영업부를 생각하면 될 듯)

- 영업 조직에는 유통 채널(distribution channels)과 제품군(divisions)을 할당할 수 있다. 이 3가지의 조합을 sales area라고 부른다. 

- 모든 SD 트랜잭션에는 영업 조직의 틀 안에서 진행된다.(판매오더->출하->대금청구, 고객 판매 영역 데이터 생성 등)

- 각 영업 조직은 하나의 회사 코드에 지정된다. 영업 조직의 회계 관련 세부 사항들이 그 회사 코드에 적용된다.(매출액, 매출원가 등의 반영이 영업 조직과 매핑된 회사 코드로 반영된다는 것). 즉, FI모듈과 SD모듈의 연결고리 역할을 한다.

- 예를 들어, 만약 영업 조직에 매핑된 회사 코드A와 플랜트(재화 판매 시 출고 플랜트)에 매핑된 회사 코드B가 다르다면 실질적으로 보았을 때 관계사간 거래에 해당하므로 매출 회계 트랜잭션이 일어나기 전 선행작업으로 B가 A에게 대금청구문서를 발행하게 된다. 

영업 조직 생성

1. IMG 세팅에서 가장 먼저 영업 조직을 정의해야 한다.

- 영업 조직의 코드느 4자리 문자이다. 

- 통계 통화(statistics currency) : 시스템이 리포트를 작성할 때 이 통화를 default로 통계를 작성한다.(외화로 일어난 매출이 일어났을 때 해당 통화로 변환하여 보여준다.)

- 텍스트 관련 필드 : 송장, 오더 확정 등 정보를 출력할 때 표시될 이름을 적는 칸이다. 내용을 직접 적는 것이 아닌 SO10에서 텍스트 모듈을 생성하고 그 모듈을 각 필드에 적어주면 된다.

- RefSorg.SalesDocType : 복사하여 생성하면 참조하는 영업 조직이 적힌다. 참조하는 영업조직과 같은 영업 문서 유형 할당을 공유하게 된다.

- 회사간대금청구고객 : 매출이 일어날 때 관계사 거래가 발생하는 경우 고객이 될 회사(대금을 지불할 회사)를 넣는 곳이다. 필수값이 아니다.

- 영업조직달력 : factory calendar를 입력한다. 영업일의 기준이 되는 달력

- 리베이트 처리 활성화 : 리베이트(한번 지불된 상품이나 용역의 대가의 일부를 다시 그 지불자에게 되돌려 주는 행위 또는 그 금액)를 활성화하는 버튼. 추측하건데 리베이트는 이미 회계문서의 clearing까지 완료된 상태에서 고객에게 대금을 돌려주는 행위이므로 판매 오더의 최종 확정 이후에도 추가적인 빌링 처리가 가능하도록 하는 등의 옵션이 아닐까 한다.

- ALE(Application Link Enabling)  구매 오더 데이터 : Third party Order의 경우 자동으로 PO가 생성되게 하도록 정보를 미리 입력하는 것이다. Third party Order란 판매오더가 릴리즈 될 때 구매 계약이나 구매 가격이 지정되어 구매 요청이 자동으로 생성되는 프로세스이다. 

- 생성을 하면 주소데이터를 입력하라고 뜨는데 입력하지 않아도 된다.

2. 영업조직 지정

- 회사코드에 영업조직 지정 : FI와의 연결고리가 될 매핑 정보를 등록한다.

- 영업조직에 유통경로 지정 : 유통 경로는 재화와 서비스가 고객에게 전달되는 방식을 이야기한다. 도매, 소매, 직판 등이 될 수 있다. 혹은 내수/수출 등으로 나눌 수도 있을 것이다.

- 영업조직에 제품군 지정 : 재화와 서비스를 grouping하는 방식이다. 제품군을 이용해 시스템이 sales area와 business area를 결정한다. 모든 자재는 하나의 제품군이 지정되어 있다.(Material Master의 Basic Data이다) -> 즉 SD와 MM을 연결하는 고리로 활용된다. 

- 영업영역설정 : sales area는 영업 조직, 유통 경로, 제품군의 조합이다. 영업 조직에 유통경로와 제품군을 지정하면 자동으로 조합 엔트리가 등록되어 있다.

- 영업조직 - 유통경로 - 플랜트 지정 : 하나 이상의 플랜트를 영업조직과 유통경로 조합에 지정할 수 있다. 자재의 판매 영역 데이터와 관련되어 있을 것이다. 자재의 판매영역 데이터는 플랜트/판매조직/유통경로를 통해 구분된다.

3. 영업 영역별 규칙 정의

- 사업 영역(business area) 계정 결정을 위해 각 영업 영역에 대하여 SAP 시스템이 사업영역을 찾을 수 있는 규칙을 지정해 주어야 한다.

- SAP R/3 System에서, 수익 계정 결정을 진행하는 동안 사업 영역을 자동 할당하기 위해 3가지 규칙이 미리 지정되어 있다.

   1. 플랜트와 제품군으로 부터의 사업 영역 결정

   2. 영업 영역으로부터의 사업 영역 결정

   3. 영업 조직, 유통 채널, 제품군으로부터 사업 영역 결정

4. G/L 계정 지정

- 수익 계정에 대한 G/L 계정을 지정한다.

- 모든 접근 시퀀스에 대하여 할당을 해야한다. 제대로 하지 않으면 계정 결정 오류로 회계문서가 생성되지 않는다.

- 테이블 : 조건 테이블 - 조건 레코드의 키를 정의하는 필드의 조합을 의미

    - 가격결정절차의 각 조건 타입에 대하여 접근 시퀀스를 정한다. 접근 시퀀스는 시스템에게 어떤 적절한 조건 레코드를 찾아 볼지 유도한다. 접근 시퀀스의 각 접근은 조건 테이블을 참조하고, 이 조건 테이블의 필드들이 시스템에게 어떤 유효한 조건 레코드를 가져올 지 도움을 준다. 즉, 어떻게 수익 계정을 찾을 지 정하는 과정을 지정해주는 것

- 여기 뜨는 조건 테이블은 계정 결정 판매 괸리 조건 테이블이다. V/14 여기서 조회 가능

5. 영업문서유형에 영업영역지정

- 오더 타입을 영업 영역(영업조직, 유통경로, 제품군 조합)에 지정하는 것이다. 

- 모든 오더 타입을 지정하고 싶으면 엔트리를 안 넣으면 되고 특정 오더 타입만 허용하게 할 거라면 엔트리를 등록해주면 된다.

6. 가격결정절차(자세히)

- 영업조직 - 유통 채널 - 제품군 - 문서가격결정절차(DoPr) - 고객가격결정절차(절차) 의 조합으로 가격결정절차를 정한다.

    - 문서가격결정절차는 오더 유형에 매핑되어 있다. '문서가격결정절차를 오더유형에 지정' 항목에서 매핑한다.

    - 고객가격결정절차에 대한 정의는 '고객 가격결정 절차정의'에서 하고 고객 판매영역데이터에 지정한다.

    - 그렇게 지정된 가격결정절차로 판매 오더에 입력될 조건 타입들을 알 수 있다.

- 국내세에서 제대로 된 접근이 성공하면 멈추도록 독점에 체크가 되어 있다.

- 조건 테이블 78에서 적당한 조건을 못 찾으면 다음 조건테이블인 2에서 찾을 것이다.

- ALAND는 납품 플랜트의 국가, 고객세금분류는 고객의 판매 영역 데이터, 세금분류자재는 자재의 영업 데이터에 있다. 따라서 3가지의 필드를 토대로 조건 테이블에서 조건 레코드를 가져올 것이다.

- 세금코드는 회계전표에 입력되는 세금코드이다.

- 참고로 출하 탭에서 플랜트를 지정하지 않으면 조건 탭에 MWST가 뜨지 않는다! 그 이유는 MWST를 가져오기 위해서는 가격결정절차에서 국가/고객세금코드/자재세금코드 3가지가 필요한데 국가는 플랜트 데이터에서 가져오기 때문에 플랜트가 미지정인 상태에서는 매출 부가세가 지정되지 않는 것이다. -> 판매오더를 그냥 저장하면 플랜트가 자동 지정되고 그 때 가격결정절차가 지정되기 때문에 큰 문제는 없을 수도 있다.

*판매세를 수작업으로 하는 판매오더 작업 중 발견한 오류

- 판매가 입력 후 MWR1를 입력하면 MWR1에 대한 세금코드가 지정되지 않는다

- 이유는 ZPR1만 입력해도 가격결정절차가 끝난 것으로 간주하여 MWR1이 새로 입력되어도 가격결정절차를 다시 지정하지 않는다. 아래 경고 메시지와 관련된 것 인지는 모르겠음..

- 즉 유추해보자면, MWR1이 가격결정절차에서 필수가 아니기 때문에 ZPR1만 입력되면 그 이후에 MWR1이 아무리 입력되어도 가격결정절차를 재수행하지 않으므로 세금코드를 지정하는 절차가 진행되지 않아 세금코드가 빈 값으로 들어간다.

- 세금 코드가 빈 값으로 들어가게 되면 추후 대금청구문서 회계문서 릴리즈 시 TAXKR이라는 세금 결정 절차에 빈 세금 코드는 무효로 처리하여 회계문서가 릴리즈되지 않는 문제가 생긴다.

- 시스템 구축시 이렇게 세팅한 이유를 유추해보면, 판매세 수작업의 경우에는 자동 계산이 아니라 수기로 입력하기 위해 조건 유형에 접근 순서를 지정하지 않았을 것이다. 

- 따라서, 접근 순서가 없다는 것은 조건 테이블도 없을 것이고 조건 테이블에서 다른 조건유형처럼 국가/자재세금코드/고객세금코드의 조합으로 세금코드를 결정하지 않는다. 

- 필수를 지정하게 되면 접근 순서를 따라가는 작업이 진행될까봐 이렇게 비필수로 지정한 것이 아닐까 한다. MWST의 경우에는 면세일 때는 0%로 세금을 0으로 계산하고 세금 코드를 21로 잡고, 과세일 때는 10%로 세금을 계산하고 세금 코드를 11로 잡는 조건 테이블을 거친다. 하지만 MWR1은 면세와 과세의 구분을 MWR1이라는 가격 요소 자체를 입력하느냐 하지 않느냐로 구분하도록 두었기 때문에 이런 문제가 발생한 것이다.

- 의문 : 그렇다면 매출세액 입력후 ZPR1을 입력하면 세금 코드 11이 입력되는데 이때 세금 코드 11은 언제, 어디서 가져오는 것인가?

내가 올린 SAP community 질문

https://community.sap.com/t5/supply-chain-management-q-a/how-is-tax-code-determined-in-sales-order-when-condition-type-has-no-access/qaq-p/13646254#M197689

- 답변 : OB40의 계정키 MWS와 FTXP를 참고하라

What is cash sale?

- 현금 판매에 해당하는 경우로서, 마트와 같은 소매업 등에서 고객이 상품을 사고 바로 결제하고 바로 가져가는 형태의 판매 형태. 이때 Order, Delivery, Payment가 동시에 이루어진다고 볼 수 있다.

- Delivery와 Billing이 Sales Order가 생성된 직후에 바로 처리된다.

- 그렇기 때문에 Billing은 order-related가 된다.

- 송장(대금청구문서)의 금액이 곧바로 cash account로 전기된다.

- 현재 일자가 자동적으로 delivery와 billing에 제안된다.

What are the document types for cash sales?

- BV : Cash Sale
What is the item category for cash sale?

- BVN item category is for Cash Sales

What is the document flow for cash sale?

- 현금 판매는 Sales Order에서 Delivery 문서와 Billing 문서가 파생된다.

What is BV and CS?

- 둘다 현금판매를 나타내는 용어

How a cash sale is different from standard sales order?
- 채권 계정(Receivables, Debtor Line Items)이 생기지 않는다.

- 상품/제품과 같은 실물 판매지만 Billing이 order-related이다.

What is rush order?

What is the difference between rush order and cash sales?
- 고객이 바로 상품을 가져가는 형태의 오더. 즉 delivery가 즉각적으로 이루어지는 오더. 하지만 Billing은 차후에 이루어진다. 현금 판매와 달리 Billing이 Delivery-related이다.

- 현금 판매와의 차이점은 Billing 처리 시점의 차이와 고객에 대한 신용 체크가 가능하다는 점이다. 품목 범주(Item Category)가 TAN으로 설정되면 신용 체크가 가능하다. 물론 세팅을 TAN이 아닌 다른 것으로 바꿀 수 있다.

-

What is the document type for rush order?

- Sales Order는 RO, SO

What is delivery document-type delivery against rush order?
- Delivery는 LF (출하)로 표준 판매 오더와 같다.

- 스탠다드 오더의 프로세스와 크게 다르지 않다.

- Cash Order의 경우에는 마트같은 경우를 생각해볼 수 있다. 다만 SAP를 쓰는 기업이 현금 판매를 일일이 기록할 일이 없고 일일이 기록한다 하더라도 실시간으로 SAP 시스템에 반영하는 것이 아니라 주기적으로 특정 시점에 각 POS시스템에서 취합 후 반영하는 것이 일반적이라 쓰일 일은 거의 없을 것 같다. 쓰인다고 하더라도 관리회계를 위한 목적으로 판매문서 유형으로 매출을 분류하는 경우에나 쓰일 수 있을 것임.

- Rush Order의 경우에는 신뢰있는 고객의 짧은 외상 개념으로 볼 수 있다. 철강회사와 수시로 거래하는 제품 제조업체가 있고 해당 제조업체에서 수시로 필요한 만큼의 철강 자재를 가져가고 매주 월요일마다 철강회사가 대금을 청구한다면 Rush Order의 한 형태가 될 수 있다.신뢰가 있는 고객이나 특정 자원에 대한 접근권을 계약한 거래 상대방 등이 이 형태의 매출을 일으킬 수 있다. order와 delivery가 동시에 일어난다는 것은 상대방의 주문에 따라 제품을 제작하는 방식의 사업 형태가 아니라 재고가 이미 충분히 존재하고 거래 상대방의 그때그때의 수요에 따라 매출이 발생한다는 뜻이다. 가구업체들에게 목재를 공급하는 업체가 사용할 만한 판매 형태이다. 쉽게 말하면 아무때나 찾아와서 "이만큼 가져갈게요~" 하는 고객이 대상인 사업 형태에 적합하다.

1. SQVI 에서 퀵뷰 이름을 입력하고 생성

2. 데이터 소스는 '테이블 조인' 선택

3. 조인할 테이블 추가

4. 결과로 보여질 필드들을 리스트 필드에 넣는다.

5. 정렬 순서를 정한다.

6. 조건으로 사용할 필드를 선택한다.

7. 데이터 소스는 대상 테이블을 추가 및 삭제

8. SQVI에서 퀵뷰를 실행하면 이렇게 됨

9. SE93에서 트랙잭션 코드를 생성하고 퀵뷰를 연결한다.

9. report transaction을 선택한다.

10. 퀵뷰 실행화면에서 프로그램 코드값을 복사한다.

10. 퀵뷰 프로그램명을 입력하고 저장하면 다른 사용자들도 사용할 수 있게 된다.