SAP FEB_FILE_HANDLING: 은행 명세서 통합 가져오기 (XML & Text)

SAP 은행 명세서 가져오기 간소화: FEB_FILE_HANDLING으로 XML 및 텍스트 형식 통합

끊임없이 변화하는 재무 보고 요구 사항과 다양한 은행 명세서 형식의 환경에서, SAP로의 효율적인 가져오기 자동화는 매우 중요합니다. 기존 방식은 특히 텍스트 형식을 처리할 때 한계에 부딪히는 경우가 많았으며, 이는 시대에 뒤떨어진 중간 변환을 필요로 했습니다. 이 글에서는 FEB_FILE_HANDLING의 기능을 XML 및 특정 텍스트 은행 명세서 형식의 통합 가져오기를 위한 중앙 집중식 솔루션으로 탐구하며, Multicash와 같은 레거시 도구의 필요성을 없애고 지급 처리 과정을 최적화합니다.

SAP에서 기존 은행 명세서 가져오기의 과제

과거에는 SAP로 은행 명세서를 가져오는 것, 특히 텍스트 형식의 경우 여러 가지 어려움이 있었습니다. 파일 업로드에 사용되던 기존 RFEBKA00 프로그램은 수동 처리가 필요한 경우가 많았고 로컬 워크스테이션에 의존했습니다. 국가별 텍스트 형식의 주요 한계는 Multicash를 통한 필수적인 중간 변환이었습니다. 이는 25년 이상 전에 개발된 솔루션으로, 현대의 자동화 및 통합 표준과는 더 이상 맞지 않습니다. 이러한 접근 방식은 프로세스를 늦출 뿐만 아니라 추가적인 오류 발생 지점을 만들고 유지 관리를 위해 전문 지식을 요구했습니다.

기존 방식의 문제점:

• 수동 처리: RFEBKA00 시작을 위한 사용자 작업 의존.
• 시대에 뒤떨어진 기술: 텍스트 형식 변환을 위한 Multicash 사용 요구 사항, 이는 기술적 시대착오입니다.
• 분산된 형식: XML 및 텍스트 파일 처리에 대한 통합된 접근 방식 부족, 지원 및 확장성 복잡화.
• 제한된 민첩성: 은행 정보 수신 및 처리 지연, 지급 조정 속도 및 잔액 데이터 정확도에 영향.

이러한 요인들은 재무 프로세스의 비효율성, 계정 조정 지연, 그리고 전반적인 현금 흐름 투명성 저하로 이어졌습니다. 현대 SAP 인프라의 목표는 출처(은행 직접 통신 또는 "은행-클라이언트" 시스템에서 내보내기) 및 형식에 관계없이 모든 유형의 은행 명세서에 대한 단일 진입점을 구축하는 것입니다.

FEB_FILE_HANDLING 아키텍처: 통합의 기반

FEB_FILE_HANDLING은 은행 명세서 가져오기를 자동화하도록 설계된 강력한 SAP 도구입니다. 처음에는 XML 형식을 위해 설계되었지만, 유연한 아키텍처 덕분에 "Client → 1C" 또는 벨라루스 요청 유형 400/600과 같은 국가별 변형을 포함한 모든 텍스트 형식을 처리하도록 기능을 확장할 수 있습니다.

FEB_FILE_HANDLING의 주요 처리 단계:

• 파일 처리 (BAdI FEB_BSIMP_FILE): 이 단계에서 파일 형식이 결정되고, 파일을 읽기 전에 예비 검사가 수행됩니다.
• 내부 구조로 변환 (BAdI FEB_BSIMP_BANK_STATEMENT): 이 단계는 은행 명세서 파일이 SAP의 내부 구조로 변환되어 FEBxx 버퍼에 저장되는 핵심 단계입니다. 이 BAdI는 프로세스의 '핵심'입니다.
• 자동 처리 (RFEBKA00): 버퍼에 저장된 후, RFEBKA00 프로그램이 자동으로 실행되어 명세서를 추가로 해석하고 전기합니다.

표준 구현이 없는 특정 텍스트 형식(XML, MT94x 또는 BAI와 달리)의 경우, BAdI FEB_BSIMP_BANK_STATEMENT_X 확장이 사용됩니다. 이 안에서 GET_BANK_STATEMENTS 및 SAVE_BANK_STATEMENTS 메서드가 순차적으로 호출됩니다.

• GET_BANK_STATEMENTS: 파일 내용을 분석하고, 개별 명세서로 분할하며, 주요 은행 정보(회사 코드, 주거래 은행, 계정 ID)를 식별합니다. XML 파일의 경우 BAdI FIEB_GET_BANK_STMTS_X를 통해 수행됩니다. 텍스트 형식의 경우 사용자 정의 로직이 필요합니다.
• SAVE_BANK_STATEMENTS: 데이터를 SAP의 내부 인터페이스 구조로 변환하고 FEBxx 테이블에 저장합니다. 저장을 위해 FIEB_SAVE_BANK_STMT(최종 명세서용) 및 FIEB_SAVE_INTRADAY_STMT(일중 명세서용) 모듈이 사용됩니다.

이 접근 방식은 Multicash를 제거하고 모든 명세서 유형을 단일 자동화 흐름으로 통합하여 처리를 통일합니다.

직접 텍스트 형식 변환을 위한 DMEE 통합

중간 Multicash 없이 텍스트 파일을 SAP의 내부 구조로 직접 변환하기 위해 DMEE(Data Medium Exchange Engine) 도구가 활용됩니다. Multicash 처리(트리 유형 MCSH)에 이미 사용되던 DMEE는 새로운 목적에 맞게 조정될 수 있습니다.

DMEE 작업 시 주요 단계:

• 새로운 DMEE 트리 유형 생성: BAdI FEB_BSIMP_BANK_STATEMENT에서 사용되는 내부 명세서 인터페이스 구조에 맞춰 새로운 트리 유형을 정의해야 합니다.
• 대상 구조: 새로운 DMEE 트리에서 라인 항목의 대상 구조는 FEBEP_IF(명세서 항목 인터페이스 구조)의 필드여야 하며, 헤더의 경우 FEBKO_IF(명세서 헤더 인터페이스 구조)의 필드여야 합니다.
• 추가 필드: DMEE 트리는 일반적으로 두 개의 대상 구조만 지원하므로, 예를 들어 지급 목적을 위한 추가 필드를 허용하는 것이 중요합니다.

명세서 라인 항목 대상 애플리케이션 구조를 FEBEP_IF 인터페이스 구조에 매핑하는 예시:

• 텍스트 파일의 필드는 전기일, 금액, 통화, 문서 번호 등 해당 FEBEP_IF 필드에 직접 매핑됩니다.
• 이를 통해 DMEE는 수신되는 텍스트 파일을 FEB_FILE_HANDLING이 직접 사용할 수 있는 형식으로 직접 변환할 수 있습니다.

이러한 방식으로 DMEE를 활용하면 시대에 뒤떨어진 Multicash를 완전히 우회하여 아키텍처를 크게 단순화하고 위험을 줄일 수 있습니다. DMEE는 다양한 국가별 텍스트 형식에 대한 매핑 구성에 유연성을 제공하여 변환 프로세스를 투명하고 관리하기 쉽게 만듭니다.

병렬 처리를 위한 통합 BAdI 구현 개발

XML, MT94x, BAI 및 특정 텍스트 형식 등 다양한 형식의 병렬 처리를 가능하게 하려면 BAdI FEB_BSIMP_BANK_STATEMENT의 사용자 정의 구현이 필요합니다. 이 구현은 알려진 형식에 대한 표준 메서드와 텍스트 파일 처리를 위한 사용자 정의 메서드를 모두 호출하는 중앙 허브 역할을 할 것입니다.

XML 및 텍스트 형식 처리를 위한 사용자 정의 BAdI FEB_BSIMP_BANK_STATEMENT 구현 스키마:

• GET_BANK_STATEMENTS 메서드:

* XML 파일의 경우: BAdI FIEB_GET_BANK_STMTS_X 구현의 표준 GET_BANK_STATEMENTS 메서드를 직접 호출합니다.

* 텍스트 파일의 경우: SPLIT_AND_PARSE_TXT_FILES와 같은 사용자 정의 메서드를 활용합니다. 이 메서드는 파일 라인을 분석하고, 파일을 논리적 명세서로 분할하며, 예비 XML 구문 분석과 유사하게 은행 정보(회사 코드, 주거래 은행, 계정 ID)를 식별하는 역할을 합니다.

* 결과: 외부 파일을 헤더(시스템 계정 정보 포함)와 파일 내용 라인 테이블을 포함하는 논리적 명세서로 변환합니다.

• SAVE_BANK_STATEMENTS 메서드: 이 메서드는 논리적 명세서 파일을 내부 인터페이스 구조로 변환하고 데이터 버퍼(FEBxx 테이블)에 저장하는 이중 기능을 가집니다.

* 병렬 변환:

* XML 형식의 경우: BAdI FIEB_GET_BANK_STMTS_X 구현에서도 사용되는 변환 모듈 FIEB_READ_MAPP_X 및 FIEB_MAPPING_X를 순차적으로 호출합니다.

* 텍스트 형식의 경우: CALL_DMEE_CONVERT와 같은 사용자 정의 메서드를 호출합니다. 이 메서드는 표준 주 변환 모듈 DMEE_PROCESS_INCOMING_FILE_ABA 및 수신 파일 처리를 위한 DMEE 메서드(PROCESS_INPUT_DME 변환 전, PROCESS_OUTPUT_DME 변환 후) 호출을 구현합니다.

* 변환 결과: 모든 명세서는 원래 형식에 관계없이 통합된 내부 인터페이스 구조(FEBxx_IF 구조)로 변환됩니다.

* 버퍼에 저장: 모든 명세서 형식에 대해 FEB_SAVE_BANK_STATEMENT와 같은 공통 메서드를 통해 버퍼에 저장합니다. 명세서 전기 매개변수에 따라 FIEB_SAVE_BANK_STMT(영역 0001에 전기된 최종 명세서용) 또는 FIEB_SAVE_INTRADAY_STMT(일중 명세서용)가 호출됩니다.

이 접근 방식은 모든 은행 명세서가 균일하게 처리되도록 보장하여 높은 수준의 자동화를 제공하고 수동 개입을 최소화합니다.

중앙 집중식 가져오기의 이점 및 향후 전망

텍스트 형식에 대한 DMEE 지원을 통해 FEB_FILE_HANDLING을 통한 통합 은행 명세서 가져오기 시스템을 구현하면 기업의 재무 운영에 상당한 이점을 제공합니다.

주요 이점:

• 단일 진입점: 형식(XML, MT94x, BAI, 국가별 텍스트) 및 출처에 관계없이 모든 은행 명세서가 단일 FEB_FILE_HANDLING 메커니즘을 통해 처리됩니다.
• Multicash 제거: 시대에 뒤떨어진 Multicash를 통한 중간 변환을 중단하여 아키텍처를 단순화하고 유지 관리 비용을 절감합니다.
• 자동화: 파일 수신부터 SAP 버퍼 저장 및 RFEBKA00을 통한 후속 전기까지 완전 자동화된 프로세스입니다.
• DMEE 유연성: 유연한 DMEE 도구를 사용하여 모든 텍스트 명세서 형식에 대한 임의의 매핑을 구성할 수 있는 기능.
• 민첩성 향상: 지급 처리 및 조정 속도 향상, 재무 정보 정확도 개선, 운영 위험 감소.

이 아키텍처는 기업이 다양한 은행 데이터를 효과적으로 관리하고, 재무 보고를 개선하며, 보다 정확하고 시기적절한 의사 결정을 보장할 수 있도록 합니다. 향후 개발 전망에는 문서 관리 시스템과의 추가 통합 및 수신 데이터를 기반으로 한 분석 기능 확장이 포함됩니다.

— Editorial Team