학습 일지

BDC(Batch Data Communication)으로 SAP시스템에서 대량의 데이터를 일괄적으로

입력하거나 업데이트하기 위해 사용되는 기술로 수작업으로 데이터를 입력하는 대신 

자동화된 방식으로 데이터를 처리할 수 있는 기능이다.

BDC는 크게 기록(Recording)을 통해 트랜젝션을 기록하고 BDC프로그램을 작성하는 Session Method와

작성한 BDC프로그램을 Call Transaction Method 를 실행하는 방법으로 구성되어있다.

1. T-Code : SHDB 실행 후 기록.

해당프로그램에서 New recording을 클릭.

Recording 명을 작성하고 기록할 T-Code입력 후 start recording을 눌러 실행한다.

내가 프로그램을 자동화 처리하기 위한 하나의 과정을 진행하고 종료하면 다음과 같이 행위에 대한 결과가 저장된다.

2. 코드작성 

DATA : lt_bdcdata TYPE TABLE OF bdcdata WITH EMPTY KEY.

 lv_opt = VALUE ctu_params( dismode = 'E' ).
 lt_bdcdata = VALUE #(
                      ( program = 'RDDM0001' dynpro = '0200' dynbegin = 'X' )
                      ( fnam    = 'BDC_CURSOR'           fval = 'TRDYSE01SN-TR_TRKORR' )
                      ( fnam    = 'TRDYSE01SN-TR_TRKORR' fval = ls_list-trkorr )
                      ( fnam    = 'BDC_OKCODE'           fval = '=SINGLE_LOGS' ) ).

CALL TRANSACTION 'SE01' USING lt_bdcdata OPTIONS FROM lv_opt.

RDDM0001이란 프로그램의 화면 0200을 시작하겠다고 선언.

위의 기록대로 필요한 값을 bdcdata Type table에 넣어주면 된다.

lv_opt 이란 bdc가 작동하면서 화면을 어떻게 보여줄지에 대한 설정이다.

                                       'A' : 모든 화면에 대해 조회하면서 트랜잭션 수행 모드

                                       'E' : 에러 발생할 경우 해당화면 조회

                                       'N' : 화면을 표시하지 않음.

보통 'E' 모드를 많이 쓰고, Data 값을 가져오기 위한 경우엔 'N'화면을 많이 사용한다.

더블클릭 or Hotspot 클릭을 이용하여 특정 필드에 대한 Event를 등록하면

해당 TROKRR ( Request No)를 가지고 바로 SE01의 Log화면을 띄워주는 걸 확인 할 수 있다.

Excel 을 다운로드 하는 경우가 종종 생긴다.

먼저 Download 할 위치를 정해줘야 하는데 SAP 스탠다드 코드를 이용할 수 있다.

Method cl_gui_frontend_services=>file_save_dialog를 이용하면 된다.

  DATA : lv_file_filter       TYPE string,
         lv_initial_directory TYPE string,
         lv_filename          TYPE string,
         lv_path              TYPE string,
         lv_fullpath          TYPE string.

  lv_filename = 'Template'.
  lv_file_filter = 'Excel File(*.xlsx; *.xls )|*.xlsx; *.xls'.
  lv_initial_directory = 'C:'.
  cl_gui_frontend_services=>file_save_dialog(
    EXPORTING
      default_extension         = 'xlsx'                " Default Extension
      default_file_name         = lv_filename           " Default File Name
      file_filter               = lv_file_filter        " File Type Filter Table
      initial_directory         = lv_initial_directory  " Initial Directory
    CHANGING
      filename                  = lv_filename           " File Name to Save
      path                      = lv_path               " Path to File
      fullpath                  = lv_fullpath           " Path + File Name
    EXCEPTIONS
      cntl_error                = 1                     " Control error
      error_no_gui              = 2                     " No GUI available
      not_supported_by_gui      = 3                     " GUI does not support this
      invalid_default_file_name = 4                     " Invalid default file name
      OTHERS                    = 5.
      
  IF sy-subrc <> 0.
    MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
       WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
  ENDIF.
  
  IF lv_fullpath IS INITIAL.
    RETURN.
  ENDIF.

위 코드와 같이 작성을 하면 아래와 같이 Download하는 창을 불러올 수 있다.

Default로 C드라이브 , 제목은 Template고 형식은 Excel로 들어간다.

필요에 따라 저장위치, 파일이름, 형식은 변경이 가능

lv_fullpath 는 저장위치(path) + 파일이름(File Name)  으로 구성되는 String으로 반환된다.

자 그러면 이제 Excel 혹은 Excel Template를 SAP 스탠다드에(웹저장소) 등록을 해보자.

T-Code : SMW0 실행.

Binary data for WebRFC applications를 선택하고 실행을 눌러준다.

해당 프로그램이 포함된 Package를 넣어주고 Excute(실행) 클릭

Obj. name 과 Description을 작성하고 import 버튼을 눌러 생성해준다.

Obj. name은 나중에 select문에 사용된다.

Import 버튼을 누르면 Excel을 선택하는 창이 나오는데,

미리 작성해둔 template excel 파일을 선택하여 등록하면 SAP 스탠다드 웹 저장소에 Upload되면서 저장이 된다.

그럼 코드로 돌아와서 해당 파일을 가져오자.

DATA : ls_item              TYPE wwwdatatab,
       lv_file              TYPE rlgrap-filename.
       
lv_file = lv_fullpath.

  SELECT SINGLE FROM wwwdata
   FIELDS *
    WHERE objid = 'Z_EXCEL_TEMPLATE'
     INTO CORRESPONDING FIELDS OF @ls_item.             "#EC CI_NOORDER

  CALL FUNCTION 'DOWNLOAD_WEB_OBJECT'
    EXPORTING
      key         = ls_item
      destination = lv_file.

  IF ls_item IS INITIAL.
    "File is not exist
    MESSAGE s044 DISPLAY LIKE 'E'.
    EXIT.
  ENDIF.

wwwdata 에서 방금 만든 obj.name 의 data를 가져와 

CALL FUNCTION 'DOWNLOAD_WEB_OBJECT' 를 사용해서 다운로드를 해주면 

기존의 만들어 뒀던 template의 모든 형식그대로 다운로드가 된다.

( 날짜 타입, 엑셀 border, Cell style 모두 적용된 상태로 다운 )

ALV에서 로직을 이용하여 Subtotal 초기 세팅하는 법에 대해서 알아보자.

다음과 같은 List가 있다.

해당 List를 보면 Company Code, Status, Posting Date, Document Date, Document Number는 동일하고

전표안에 있는 Line Item들의 고객마다 처리할 금액이 여러 건 있는 케이스다.

이럴 경우 전표번호에 따른 금액을 Subtotal(소계) 하여 보여주고 싶을 경우가 생길 것이다.

이럴 때 사용하는 Subtotal 에 대해서 알아보겠습니다.

먼저 Fieldcatalog 세팅에서 소계를 해줄 필드에대해서 세팅을 해준다.

해당필드에 do_sum = 'X' (abap_true)로 세팅을 해주면 

해당 필드에 값들이 모두 더해진 라인이 맨 아래 생긴다.

 전표번호를 기준으로 Subtotal이 필요하기에 이 세팅을 해줘야 하는데

Sort 세팅에서 넣어줘야한다.

spos : 정렬 순서를 의미

fieldname : 어떤 필드로 정렬할지

up : 오름차순으로 정렬 (내림차순으로 하고싶은면 down 이다. )

subtot : 해당 필드로 소계를 적용하겠다.

이렇게 설정을 하고 실행을 해보면

해당 전표 별로 소계가 되어 나오는 걸 알 수 있다.

하지만, ALV화면 맨아래 총 합은 모든 전표에 대한 합계이기 때문에 필요없을 수 있다.

이럴 경우에는 Layout 설정에 가서 설정해주면 된다.

no_totline = 'X' (abap_true) 로 설정하고 실행하면

노란색으로 되어있던 전체 합계 라인이 사라진 것을 확인 할 수 있다.

그러면 동일 한 필드에 대해서는 전표번호 처럼 합쳐서 나오게 하려면 

Sort 세팅에서 묶어주면 해결된다.

이렇게 원하는 필드에 대해서 Sort table에 넣어주면 된다.

이러면 테이블이 보는게 훨씬 깔끔해야지고 가독성이 올라간다.

지금까지 세팅한 Sort, layout, fieldcat 은 alv를 불러올 때

입력해주는 값 들에 세팅을 해줘야 하며,

set_table_for_first_display 가 실행되기 전에 세팅을 해야한다.

또한, set_ready_for_input( i_ready_for_input = 0 ) 를

필수로 설정해줘야 동일 필드가 합쳐져서 1개로 보인다.

Special General Ledger

Special General Ledger도 Alternative Reconciliation Account 처리의 또 다른 종류라고 볼 수 있다.

Alternative Reconciliation 계정은 사용자가 직접 화면에 수작업으로 원하는

대체계정을 직접 선택하여 입력하지만, Special G/L은 전표 입력 시에

아래 화면과 같이 SGL Ind( Special G/L indicator for next line item ) 필드에 특정 값을 입력하여,

미리 설정된 Alternative Reconciliation 계정을 가져오게 하는 부분이 다르다고 할 수 있다.

Special G/L Transaction 은 3가지 종류로 분류할 수 있으며,

각각의 종류별로 서로 다른 IMG 설정화면에서 설정작업을 수행한다.

Special General Ledger는 다음과 같이 세가지 Type으로 Main G/L 와 연계된다.

1) Automatic Offsetting Entry.

2) Noted Item                       

3) Free Offsetting Entry        

위 세가지 Type에 대하여 알아보자.

Automatic Offsetting Entry

Automatic Offsetting Entry는 통계목적으로 사용되는 Alternative Reconciliation 계정항목이다.

일반적으로 전표에서 한 라인만 입력하면 되며, 이 때 자동으로 시스템에 정의된 상대계정이 생기게 된다.

Customer/Vendor 에 대한 Special G/L Indicator를 설정하는 IMG경로는 다음과 같다.

위 화면을 보면 Customer에 대한 Special G/L Indicator '2' 값을 설정하고

원래 Customer Master에 설정해 놓은 Reconciliation Account인 11090101 계정이 들어오면

자동으로 13151103으로 변경하라는 의미를 가지고 있다.

Reconciliation Account의 값에 따라서 Special G/L Account를 각각 다르게 설정할 수 있다.

위 버튼 Properties를 눌러보면 상세 내용이 나온다.

Special G/L Transaction types는 Others 로 설정된 것을 확인 할 수 있고,

Noted Items엔 선택이 안되어 있는 걸 알 수 있다.

위 IMG 경로에서 Define Accounts for Automatic Offsetting Entry를 들어가보면

자동으로 발생하는 상대계정을 설정해 놓을 수 있다.

위 버튼 Rules에 들어가보면 아래 화면이 나온다.

'Acct type/sp.G/L ind' 에 체크가 되어있으면 Account Type별로 계정코드를 생성할 수 있으며,

체크가 되어있지 않으면 전체 Account Type에 대하여 하나의 계정코드를 설정할 수 있다.

이렇게 발생한 전표는 통계용으로 사용되는 항목으로 실제 원장에 기표되는 금액은 아니다.

그러므로 G/L 계정원장에는 나오지 않으며 개별항목 조회 시 따로

Special G/L Transaction 타입을 선택해야 조회가 가능하다.

Noted Items

Noted Item도 Automatic Offsetting Entry처럼 G/L에 반영되지 않는 항목이다.

차/대변 없이 하나의 전표 라인항목만 입력을 하므로

Zero Balance Check(차/대변 합계급액 0원)을 수행하지 않는다.

Noted Item은 주로 Due Payments 나 Payment to be made와 같이 지급해야

할 항목이나 입금 받아야 할 항목들을 전표 형태로 입력하여 메모의 용도로 사용된다.

Noted Item은 정상적인 전표가 아니므로, 차변만 발생한 형태로 잔액이 0이 아니다.

G/L 레포트나 개별항목 조회에도 나타나지 않으며, 조회하고 싶은 경우 Type 선택 시

Noted Items 옵션을 체크해야만 레포트로 조회가 가능하다.

Down Payment Request(선지급 요청) 등 이 Noted Items의 한 형태이다.

Free Offsetting Entries - Down Payments

앞의 두 Type과 다르게 일반적인 전표의 형태를 가지고 있고 실제로 많이 사용한다.

사용자가 상대계정에 대하여 차/대변에 관계없이 자유롭게 입력이 가능하며,

정상적인 전표이므로 G/L원장이나 재무제표에도 반영이 된다.

주로 선수금, 선급금, 어음 등에서 많이 사용을 하므로 Special G/L Transaction을 사용하는 가장 중요한 형태이다.

위 그림은 Down Payments(선수금, 선급금) 전표처리 흐름이다.

Down Payments는 AR(매출채권) 전표를 생성하기 전에 미리 대금을 받는 케이스인 선수금 처리와

AP(매입채무) 전표를 생성하기 전에 미리 대금을 주는 케이스인 선급금이 있다.

채권과 채무는 차/대변만 서로 바뀌고 거의 동일한 형태로 이루어져 있다.

1)  Down Payment Request 생성

Down Payment Request를 생성하는 단계로, 위에서 설명한 Noted Item 형태로

차/대변의 잔액이 맞지 않아도 되는 형태의 전표형태이다.

Noted Item이므로 재무제표에 반영이 안되고 단순 Reminder의 역할만 수행한다.

2) 선수금 입금 환인 후 (선급금 지금 확인 후)

채권(AR)전표를 생성하기 전에 일부 대금을 먼저 입금 받은 경우에 생성하는 Down Payment 전표이다.

차변에는 입금 받음 은행 예금 11,000원 들어왔으며, 대변에는 AR에 대한 Down Payment 11,000원이 들어왔다.

이 단계에서  Tax도 기표하여야 하므로 Tax 금액을 기표하고, Tax에 대한 조정계정도 차변에 입력한다.

이 단계에서 발생한 모든 항목은 실제 Bank 계정만 제외하고 반제처리가 되어 잔액이 0으로 떨어져야

할 중간 임시 계정이라고 볼 수 있다.

3) AR(매출채권) 전표 생성

정상적인 계산서를 발행하고 입력하는 AR전표다.

차변에는 AR 총 금액, 대변에는 매출계정과 Output Tax 계정이 온다.

4) 선수금 반제처리 (선급금 반제처리)

미리 받은 선수금(선급금)에 대한 반제처리를 수행하는 단계다.

2번단계에서 입력한 Down Payment, Tax, Tax 조정계정이 모두 반제 되어 사라지게 되며,

정상적인 매출채권 금액 33,000원 중에서 이미 받은 11,000원의 채권도 반제처리가 되게 된다.

그러므로 이제 받아야 할 채권은 22,000원만 남게 된다.

5) 남은 매출채권 입금완료 후 (남은 매입채무 지금완료 후)

남아 있는 채권 22,000원에 대하여 입금이 들어왔을 떄 매출채권을 떨어내고,

은행예금 계정으로 입금하는 형태다.

위의 그림을 보면 알파벳으로 서로 반제 되어 처리되는 항목을 표시 된 것이다.

최종적으로 차변에는 Bank 33,000원과 대변에는 Revenue 30,000원과 Output Tax 3,000원이 마지막까지 남게 되는 계정이다.

즉, 은행에 33,000원이 입금되고, 매출 30,000원과 매출부가세 3,000원이 대변에 기표 되는 형태다.

IMG 경로

위 화면은 Customer에 대한 Down Payment Special G/L Indicator 'A'에 대한 IMG 설정화면이다.

Special G/L Indicator 'A' 는 Posting Key '09', '19'로 설정해 놨으며

Down Payment라는 type 선택코드를 지정한 것을 알 수 있다.

'Rel.to Credit Limit'에 체크가 되어있으면 선급금 처리시에 금액도 여신관리(Credit Management)의

대상항목으로 선정이 되어, 선급금이 입금되면 해당 Customer에 대한 여신 가용금액이 다시 늘어나게 된다.

'Commitments Warning' 선택 필드에 체크를 하면, 전표 입력 시 해당 Customer에 대하여

Down Payment가 얼마나 남아있는지를 작은 메시지창으로 보여준다.

Output tax clearing 필드에 'A'값이 설정되어 있는데,

이 경우에 선급금 처리시에 자동으로 Tax Clearing 계정이 입력되게 하는 설정이다.

이러한 Tax Clearing 계정은 Define Account for Tax Clearing에서 설정이 가능하다.

Output Tax, Input Tax에 대하여 설정을 미리 해 놓으면 된다.

이렇게 Down Payment 처리시에 사용되는 Alternative Reconciliation Account에 대해서는

계정코드 생성할 때 그림과 같이 반드시 Tax Category에 '+B' 혹은 '-B'로 설정이 되어있어야 한다.

'+B'와 '-B'는 Down Payment에서만 사용하는 세금 카테고리로, 부가세를 Gross로 계산할 때만 사용하는 Tax Category다.

 Free Offsetting Entries - Bill of Exchange (BOE,어음)

아래 그름은 BOE처리에 대한 전표처리 흐름이다.

Down Payment는 채권이나 채무전표 생선전에 미리 선입금이나 선수금을 받았을 때 전표처리부터 시작하지만,

BOE는 일단 채권이나 채무전표가 생긴 이후부터 프로세스가 시작된다.

채권의 어음(BOE)에 대하여 2가지 케이스가 있는데,

일반적으로 매출채권(AR) 전표가 발생하면, 매출채권을 반제처리 하면서 새로운 미결항목인

Customer에 대한 BOE 미결계정을 생성하게 된다.

위 그림에서 2) 매출채권을 BOE(어음)으로 반제하는 전표다.

이렇게 발생된 어음 전표는 위의 Customer BOE 처리 1과 같이 간단하게 은행에 어음에 대한

현금이 입금되면 차변에 Bank, 대변에 AR(BOE) 미결계정으로 처리할 수 있으나,

원칙적으로는 Customer BOE 처리2와 같이 은행추심에 의핸 BOE Bank Collection 계정과

BOE Clearing 계정으로 기표처리를 한 후 BOE Bank Collection 계정이나 BOE Clearing계정을

각각 반제 처리하는 과정으로 진행 할 수 있다.

이렇게 처리가 되고 나면 차변의 Bank 계정과 대변의 Revenue, Output Tax 계정만이 실제로 반제 되지 않고 남아있다.

해당 IMG 경로 혹은 (T-code : OBYH)에서 BOE계정 설정이 가능하다.

Special General Ledger의 Posting Key

Posting Key나 Special G/L Indicator는 사용자가 필요에 따라 설정을 변경하거나,

표준으로 제공된 값을 사용할 수 있다.

Posting Key로 여러가지 설정된 정보를 알 수 있는데 ,

해당 IMG 경로에서

Special G/L에 체크가 되어있어야 전표입력 시 이러한 Posting Key를 이용하여

전표를 입력할 때 Special G/L 입력처리가 가능하다.

해당 글은 ' 알기쉽게 정리한 SAP FI' 책을 통해 스스로 공부하면서 정리한 내용이다. 

SAP에서 Class의 Method나 Function Module 혹은 Subroutine( Perform )

을 작성하다보면 모두 파라미터를 주고받는 방식으로 작성하게 된다.

이때 Pass by Value와 Pass by Reference의 차이점을 알아보자.

Pass by Value

Pass by Value는 실제 파라미터를 보낼 때 복사본을 만들어서 사용한다고 보면 된다.

프로시저가 호출되면 파라미터와 반환 값이 초기화 된다.

입력 파라미터는 호출 시 실제 파라미터 값을 받지만,  반환 될 때 초기화가 되기에 

Return을 사용할 경우에 값을 전달 받을 수 있다.

즉, 매개변수가 Method나 Function Module 혹은 Subroutine( Perform ) 안에서 변화가 된다고 해도

복사된 입력 파라미터에만 영향을 미치기 때문에 기존 실제 파라미터에는 영향을 주지 않는다.

이렇기 때문에 Pass by Value는 대용량 데이터를 처리할 경우 메모리와 시간이 많이 들 수 있는 단점이 있다.

Pass by Reference

Pass by Reference는 실제 파라미터를 보낼 때 Reference ( Pointer ) 를 포함하여 보낸다고 보면 된다.

프로시저에 전달되고 실제 파라미터와 함께 작동하는 경우다.

즉, 매개변수가 Method나 Function Module 혹은 Subroutine( Perform ) 안에서 변화가 된다면

실제 파라미터값도 동일하게 변경된다.

그렇기에 Pass by Value에 비해 대용량 데이터 처리를 할 경우 퍼포먼스 측면에서는 확실 히 더 좋은 장점이 있다.

다만, Pass by Reference는 실제 데이터 값을 변경시키기 때문에 증간에 결과가 변경될 수 있어

잠재적은 부작용을 일으킬 수 가 있어서 주의가 필요하다.

Perform 문을 구성할 때 Using / Changing / Tables 를 사용하는데 먼저 이것부터 이해하고 예시를 보겠습니다.

Using은 값을 던져주는 것이고,

Changing은 값을 던지고 받아오는 것,

Tables는 Table을 넘겨서 받아오는 것으로 이해하면 쉽다.

자 그러면 Using과 Changing을 먼저 이해해보도록 하자.

다음과 같이 작성을 하고 실행을 해보면 다음과 같은 결과가 나온다.

Using과 Changing은 결국 값을 변환시키고 내뱉는다. 

즉 Pass by Reference 로 실행이 되는 것이다. 

사실 Using과 Chaning은 차이 없이 값이 변경되어 나오기 때문에 차이가 없고 똑같은 기능이다.

하지만 Value라는 값으로 감싸주면 두개의 기능이 차이가 생긴다.

같은 코드에 Value 구문을 추가해서 실행을 시켜보자.

Using은 초기 파라미터 값이 변경되어 나오지 않은 반면 Changing은 변경되어 나온다.

이부분에서 왜 Using과 Changing 구문이 나눠지는지 알 수 있는 부분이다.

Using은 Value구문을 쓰면 Pass by Value가 되고

Chaning은 쓰나 안쓰나 Pass by Reference가 되는 것이다.

명시적인 표현으로 구분을 하기 위해서는 Using구문에서는 value를 사용하여 Pass by Value로 사용하고

Pass by Reference로 사용하려면 Changing 구문을 사용하는게 맞는 것 같다.

자 그러면 참조변수로 설정 되어있는 값에 대해서는 어떻게 변경되는지도 확인을 해봐야

좀 더 깊게 이해를 한다고 생각한다.

하나는 Value로 하나는 New로 변수가 아닌 Structure 타입으로 생성을 해보자.

디버깅을 태워보면 Value와 New의 차이점을 볼 수 있다.

Value는 Structure타입으로 생성을 해주고 New는 해당 Structure를 Reference 변수로 생성을 한다.

그렇기에 addr_ref2는 -> 동적 개체 할당 기호를 사용하여 접근을 해야한다. 

그러면 생성된 2개의 값을 Using value를 사용하여 Pass by Value로 보내본다.

그리고 실행을 해보면 결과는 다음과 같다.

참조변수로 생성된 값은 Perform문을 통하여 Pass by Value로 보낸다고 해도

Subroutine 내에서 값이 변경되면 파라미터가 변하기 때문에 Using Value가 먹히지 않는 것을 알 수 있다.

이렇게 Pass by Value 와 Pass by Reference 차이를 알아봤다.

Class의 Method나 Function Module 혹은 Subroutine( Perform ) 작성할 때 

어떤 값을 value로 할지 reference로 할지 생각하자.

Tax코드는 세금코드다. 세금에는 국가에 내는 국세와 지방 자치 단체에 내는 지방세가 있다.

세금 중 특히 부가가치세는 고객과 구매처를 통한 모든 채권/채무 거래에 발생한다.

그래서 채권/채무 전표에는 부가가치세가 기표되어 처리된다.

부가가치세는 국세의 일부로 국세청의 세무서에 신고를 해야 하기에 전표 입력시에

세무서가 설정된 조직단위인 Business Place 가 반드시 입력되어야 한다.

해당 IMG경로에서 세무서를 설정할 수 있으며,

이렇게 설정된 세무서는 Define Business Place 에서 Business Place 와 Assign된다.

이렇게 연결을 해주면 전표 입력 시 Business Place만 입력하면 자동으로 세무서 정보가 들어가고

이 Business Place 값을 이용하여 월말에 세무신고 작업을 할 수 있다.

또한, 물동부분에서 자동으로 넘어오는 전표인 경우에는 Business Place를 입력할 수 없다.

그래서 물동에서 사용되는 Plant(플랜트)에 company code 와 Business Place를

연결해놓으면 Plant 정보만으로 company code와 business place정보를 자동으로 가져온다.

하나의 기업에는 여러 개 Business Place가 등록되어 사용될 수 있다.

그 중 대표 Business Place가 있을 수 있으며 이 정보는 Company code 설정화면에서 설정할 수 있다.

해당 IMG 경로에서 Global Parameters 들어가서 위에

Additional Data 버튼을 누르면 Head Office business place 설정이 가능하다.

Section Code

급여 및 소득 지불해야 할 원천세에는 소득세와 주민세가 포함된다.

소득세는 국세이기에 business place가 등록되어야 하지만,

주민세는 지방세이므로 지역관청이 등록되어야 한다.

세무서 및 지역관청 정보가 등록 되어야 하는데

이는 Section Code로 등록이 되어 사용된다.

해당 IMG 경로에서 지역관청을 설정하고 이 지역관청을 section code에 등록해야 한다.

이렇게 하면 Section Code에 Business Place와 지역관청을 모두 Assign할 수 있다.

Tax Procedure

매입과 매출전표에서 여러가지 세금 중 꼭 반영되어야 할 세금이 부가가치세다.

부가가치세는 국가마다 차이가 있기에 국가별로 세금을 계산하기 위한

기본이 되는 절차를 생성해야 하는데 이것이 바로 Tax Procedure다.

SAP에서는 기본적으로 사용할 수 있는 국가별 Tax Procedure을 제공하고 있다.

위 IMG 경로에서 국가별 설정되어 있는 것을 확인할 수 있다.

'TAXKR' Tax Procedure가 국가 'KR'에 연동된 것을 알 수 있다.

이렇게 제공된 Tax Procedure을 사용할 수 있으며,

필요하다면, 새로운 Tax Procedure를 만들고 새로 만든 것을 국가 코드별로 Assign 할 수 있다.

기본적으로는 하나의 국가코드에는 하나의 Tax Procedure만 연결하여 사용 가능하다.

위 화면은 TAXKR의 Control Data화면이다.

Condition Type은 세금계산 시 Rate(퍼센트율), Commercial(사사오입)

혹은 Round up(항상 올림), Round Down(항상 내림) 중

하나의 값으로 할 것인지 등에 대하여 설정 할 수 있다.

그 중 BASB는 세금계산에서 기본 Base가 되는 금액이다.

'KROT'는 Output Tax(매출부가세)로 위의 그림 보면 From Step : 100으로 설정되어 있는데,

이는 Step '100' 인 'BASB' 금액을 기준으로 계산한다는 의미다.

Account Key는 해당 IMG 경로에서 설정 가능하다.

Tax Type을 Output / Input / Additional / Not relevant to tax 인지 설정 할 수 있다.

또한, 별도의 세금라인이 자동으로 생성(Posting indic.)되게 할 것인지,

불공제(Not deductible) 처리를 해야 하는지 설정 가능하다.

불공제는 전표에서 별도의 세금라인은 생기지 않고, 매출이나 채무 항목내에 세금이 포함되어 있는 것을 말한다.

부가세 신고대상이지만 별도의 부가세 라인은 생기지 않는다.

전표에는 보이지 않지만 신고를 위한 세금 레코드는 별도로 만들어져서 저장되어진다.

해당 글은 ' 알기쉽게 정리한 SAP FI' 책을 통해 스스로 공부하면서 정리한 내용이다. 

생성되어 있는 재무전표를 변경하고 싶을 때,

어떤 필드를 변경할 수 있을지의 변경규칙을 설정할 수 있다.

전표 헤더의 필드와 라인항목에 대한 설정이 가능 하다.

Header부분은 변경할 수 있는 필드가 제한되어 있다.

해당 필드들에 대해 설정을 할 수 있으나, 실제 전표 헤더 수정가능한 필드는

Header Text 와 Reference 두개 필드라고 보면 된다.

전표 헤더 필드에 대한 통제는 Account Type별이나 Special G/L의 Trans. Type별

그리고 Company Code별로 설정이 가능하지만,

위에 세팅한 것처럼 모든 타입에 대하여 다 변경 가능하도록 설정한다.

전표 라인항목도 헤더부분과 마찬가지로 Account Type, Trans. Type, Company Code 별로 설정할 수 있다.

Text필드를 제외한 대부분의 필드들을 변경하기 위해서는 아래 조건에서 가능한 경우가 대다수다.

1. 전기기간(Posting Period)이 열려 있다.
2. 라인아이템이 반제(Clearing)되거나 역분개(Reverse)되지 않아야 한다.
3.  관련된 Credit Memo Invoice가 없어야 한다.
4.  Down Payment로부터 관련된 Credit Memo가 없어야 한다.

Reverse and Negative Posting

SAP에서 이미 생성된 재무전표는 물리적으로 삭제나 중요필드 변경이 불가능하다.

금액을 변경하거나 전표를 취소하려면 차변과 대변이 서로 반대되는 역분개(Reverse)전표 방식으로 처리를 해야한다.

전표 역분개 방법은 Normal Reverse Posting 방식과 Negative Reverse Posting 방식이 있다.

1) Normal Reverse Posting

역분개된 계정의 금액이 반대편으로 나타나서 각 차변과 대변에 금액이 그대로 남아 있으며

단순 합계잔액만이 0으로 표시되는 방식이다. (차/대변에 동일한 금액이 남아 있음)

2) Negative Reverse Posting

발생한 차/대변 항목에 마이너스로 해당 금액을 표기하는 방식이다.

차변이나 대변이나 모두 각각 금액이 0원으로 표기되고, 잔액도 0원으로 표기되어

역분개 금액이 보이지 않는 방식이다.

이러한 방식은 역분개된 금액이 과대 계상되어 보이지 않으므로 실제로 대부분 Negative 방식을 사용한다.

Reverse된 전표번호에 Additional Data를 누르면 Negative 체크 여부로 어떻게 처리되었는지 알 수 있다.

Negative Reverse Posting을 하기위해서는 3곳에서 설정이 필요하다.

첫번째는 Company Code에서 허용하도록 설정.

해당 IMG 경로를 통해 Negative Posting을 허용 할 수 있다.

Negative Postings Permitted 필드 체크를 하면 해당 Company Code에서 Negative Posting이 가능하다.

두번째는 Reason Code에 Negative Posting 허용 설정

역분개 T-Code : FB08에 들어가보면 Reversal Reason을 필수 값으로 입력하게 되어있다.

해당 설정은 위 IMG 경로 Define Reasons for Reversal에서 처리 가능하다.

Reversal Reason 코드에서 Negative Posting 필드를 체크하면 Negative Posting이 가능하다.

Alternative Posting Allowed 설정은 이전 전기기간으로의 Posting을 허용할 것인지에 대한 체크다.

체크되어 있지 않다면 당월로만 역분개가 가능하다. (체크 된 경우 이전월로도 역분개 가능)

세번째는 전표타입(Document Type)에서 설정해야한다.

4장에서 Document Type 설정에서 Negative Posting Permitted 필드 부분 체크여부에 대해 설명 했다.

정리하면, Negative Reverse Posting을 하기위해서는 아래 3가지가 필요하다.

1) Company Code에 Negative Posting 관련 부분 설정

2) Reason Code에 Negative Posting 필드 체크 여부

해당 글은 ' 알기쉽게 정리한 SAP FI' 책을 통해 스스로 공부하면서 정리한 내용이다.