데이터 변환 전략 수액
SAP 프로젝트의 데이터 변환 & # 8211; 레거시 시스템에서 SAP ECC 로의 변환.
데이터 변환 프로세스에 대한 경험을 SAP 커뮤니티와 공유하고 싶습니다. 데이터 변환은 성공적인 SAP 구현 프로젝트에서 가장 중요한 프로세스 중 하나입니다. 이 프로세스는 & # 8220; 최대한 빨리 실행 & # 8221;의 실현 단계의 일부입니다. 방법론 (1 단계 : 프로젝트 준비, 2 단계 : 청사진, 3 단계 : 실현, 4 단계 : 최종 준비, 5 단계 : 실제 진행). 레거시 시스템에서 SAP ECC 로의 데이터 변환은 SAP 고문 및 현지 구현 업체가 담당합니다. Basis 팀이이 프로세스를 수행 한 SAP 프로젝트에 대해서도 들어 봤습니다.
변환 된 데이터는 마스터 데이터를 ECC로 설정하기 위해서만 사용됩니다. 레거시 시스템에서 이력 트랜잭션 데이터를 설정하는 데 사용되지 않습니다.
데이터를 변환하는 다양한 도구가 있습니다 : 1. SAP ECC는 LSMW 트랜잭션 코드를 통해 도구에 내장되어 있습니다. 2. ECC와 쉽게 통신하는 Process runner라는 외부 도구. 우리 회사에서 구입 한 Process runner를 사용했습니다.
이 과정에서 성공하기 위해 필요한 가장 중요한 두 가지 자질은 다음과 같습니다. 1. 철저 함 2. 의사 소통 & amp; 고객의 요구 사항을 이해합니다.
위에서 언급했듯이 데이터 변환 프로세스는 실현 단계의 일부입니다. 실현 단계는 고문 (또는 현지 구현 업체)이 고객의 승인을 위해 청사진 문서를 작성하고 제출 한 후에 시작됩니다. 승인 후, 구현자는 ECC의 개발 영역에서 새로운 개발을위한 사양 문서를 사용자 정의하고 작성하기 시작합니다. 그래야만 데이터 변환 프로세스를 시작할 수 있습니다.
데이터 전환에는 다음과 같은 단계가 있습니다.
1. 데이터로 채워지는 ECC 객체의 필수 필드 매핑 (I. E : PM 모듈의 장비 객체)
여기서 SAP 객체와 관련하여 청사진 문서에 작성된 내용을 잘 알고 있어야합니다.
이 개체의 가치 필수 입력란과 가치가 아닌 입력란을 구분하는 것이 좋습니다. 어떤 때는 객체 분류가 필요합니다. 이것은 오브젝트 일반 필드가 레거시 시스템의 전체 데이터를 저장하기에 충분하지 않을 때 발생합니다. 나는 전기 발전기를 대표하는 장비 객체에 분류를 사용했다.
이 단계의 목적은 구현자가 기록을 수행하기 전에 수동으로 마스터 데이터를 생성 할 수 있는지 확인하는 것입니다.
3. 프로세스 러너 (또는 LSMW)를 통해 마스터 데이터를 기록합니다.
녹음이 정확하지 않거나 녹음 후 마스터 데이터 설정 변경이 필요할 경우 녹음을 다시 시작해야합니다. 따라서 개체 마스터 데이터를 올바르게 설정하는 방법을 확실히 알아야합니다. 녹화가 정확하고 저장 한 경우 Process runner는 입력 한 필드에 따라 채울 적절한 열이있는 EXCEL 파일을 만듭니다 녹음 중)을 사용하여 여러 인스턴스를 자동으로 설정합니다.
예 : 특정 데이터가있는 장비의 마스터 데이터 설정을 기록했습니다. 레코딩을 저장 한 후에 프로세스 러너는 추후 레코딩을 위해 EXCEL에서 적절한 구조를 생성합니다. 그런 다음 필요에 따라 많은 양의 장비 데이터로 EXCEL 파일의 적절한 열을 채우고 해당 부분을 설정할 때 다시 녹음을 실행할 수 있습니다. 이러한 방식으로 Process Runner를 통해 여러 장비가 생성됩니다.
4. 레거시 시스템에서 데이터를 추출하는 추출 프로그램 작성.
이 단계에서는 레거시 시스템 관리자 (그는 보통 MF 프로그래머)에게 어떤 필드와 데이터가 필요한 테이블을 정확하게 지정해야합니다. 두 번째 고려해야 할 사항 : 추출 할 데이터 집단은 무엇입니까 (I. E : 특정 날짜 이후에 생성 된 장비 / 데이터의 활성 부분 만 고객이이 질문에 대한 답변을 알 수 있음). 시스템 관리자는 나중에 사용할 수 있도록 레거시 시스템에서 프로그램을 준비해야합니다. 내 프로젝트에서 레거시 시스템은 ADABAS NATURAL로 작성된 MF 시스템이었습니다. 추출 할 필드와 추출 할 데이터를 지정하는 관리자에게 사양 문서를 보냈습니다.
데이터 조작 (IE : 1. 레거시의 장비 유형에는 A, B, C 값이 들어 있지만 ECC 장비 유형은 각각 AA, BB, CC 값을 포함하도록 사용자 정의되었습니다.) 2. 날짜 값의 형식 변경 등 ..), 관리자는 프로그램에서 코드를 작성해야합니다.
이 프로그램은 이전 단계에서 EXCEL 파일의 열 순서와 동일하게 출력 열을 정렬하는 것이 좋습니다. 관리자는 올바른 방법으로 열을 정렬해야합니다. 결국, 추출 프로그램은 이전 단계의 EXCEL 파일 구조와 형식에 맞는 추출 데이터로 가득 찬 EXCEL 파일을 작성합니다.
5. 오류 로그 파일 분석 및 추출 프로그램 고정.
이 단계에서 EXCEL 파일에는 SAP ECC에로드 할 데이터가 가득 찼습니다. 파일의 모든 행의 50 %를로드하십시오. 프로세스 러너가 출력 결과를 생성합니다. 프로그램이 마스터 데이터를 만들려고 할 때 실수가 있으면 그 이유를 나타냅니다. 프로그램을 분석하고 수정해야합니다.
6. SAP ECC에서 삭제 및 보관 프로그램 준비.
결국 어떤 이유로 인해로드 된 데이터를 삭제해야 할 수 있습니다. 먼저 사용자가 수동으로 생성 한 다른 데이터에서 SAP ECC 영역으로 변환 및로드 된 데이터를 구별해야합니다. 이를 수행하는 가장 좋은 방법은 SAP 표준 보고서를 사용하고 데이터를 만든 SAP 사용자가 보고서의 선택 화면에 지정하는 것입니다. 예를 들어, 내 프로젝트에서 특정 프로그래머는 Process runner를 사용하여 데이터를로드했습니다. 로드 한 전체 데이터는 사용자 코드에 따라 작성되었습니다. 따라서 데이터를 쉽게 구별 할 수있었습니다. 보고서에서 해당 데이터를 추출한 후 삭제에 필요한 항목을 표시하고 SARA tcode를 사용하여 데이터를 보관하십시오 (SARA tcode를 사용하여 SAP에서 데이터를 보관하는 방법에 대해 별도로 안내 할 예정).
이 정보가 SAP 작업에 도움이되기를 바랍니다. 이 과정에 관한 질문이 있으면 저에게 물어보십시오.
4 개의 댓글.
게시물에 댓글을 달거나 회신하려면 로그인해야합니다.
공개 포럼에서 개인 정보를 공유하지 마십시오. 개인 정보를 공유하려면 프로필에 표시하고 다른 사용자에게 프로필의 정보를 가져 오도록합니다.
토론 / 블로그 / 문서에 그러한 정보를 게시하지 마십시오.
Daniel Gontar 작성자 2014 년 8 월 16 일 1:40 pm.
나는 전환 단계에서 꽤 임시적인 프로젝트를 타고 있었고, 나는이 블로그 포스트가 전환에 대한 아주 좋은 소개 였다고 말해야 만한다.
데이터 변환 전략 수액
이 문서에서는 레거시 시스템에서 데이터 전송을 구성하고 수행하는 데 도움이되는 절차를 제공합니다.
그것은 다른 구현에서 성공적으로 사용한 데이터 마이그레이션을위한 방법론을 설명합니다. 그것은 이전 경험을 바탕으로합니다. 콘텐츠 나 결과에 대해 어떠한 보증도하지 않습니다. 이 가이드는 당신에게 제안을 제공합니다. 힌트를 얻고 자신의 방법론을 구성하는 것은 당신에게 달려 있습니다.
마이그레이션 프로젝트의 일반적인 용어 및 약어 :
주 : SAP W R / 3라는 용어는 모두 SAP R / 3 시스템을 지칭하기 위해 상호 교환 가능하게 사용됩니다.
Big Five : Big Five를 언급 할 때, 그것은 Material Master, Customer Master, Vendor Master, Bill of Materials (BOM) 및 Routing을 의미합니다.
Business Objects : 분석 및 전송 프로세스를 돕기 위해 데이터는 테이블 또는 필드 내용으로 처리되는 것이 아니라 비즈니스 운영 측면에서 개체로 처리됩니다. 이를 Business Objects라고합니다.
DC 책임 비즈니스 개체 : 변환 프로세스 (레거시 데이터 원본 및 무결성, 매핑, 변환 규칙 등)에 책임이 있으며 비즈니스 개체에 대한 계획 일정을 존중해야합니다.
Business Object Owner : 일상 업무에서 정보를 소유하고있는 사람. 이것은 비즈니스 객체의 기능 요구 사항에 대한 전략적 선택을하고 변환 된 데이터의 최종 유효성 검사를 수행하는 사람입니다. & # 8220; 비즈니스 오브젝트가 작동하지 않는 경우 직접 영향을 많이받을 수있는 가장 높은 계층 적 사용자 & rdquo;
데이터 변환 & amp; 데이터 마이그레이션 : 데이터 변환 프로세스. & # 8220; 데이터 변환 & rdquo; & # 8220; 데이터 이전 & rdquo; 용어는 문서에서 상호 교환 가능하게 사용됩니다.
DC : 데이터 변환 프로세스의 약자.
도메인 : 프로젝트 내의 기능 도메인 (예 : Finance, Sales, Production 등)
플랫 파일 : SAP로 데이터를 가져 오는 데 사용되는 파일 형식입니다. 플랫 파일은 필드 사이에 탭 구분자가있는 일반 텍스트 파일입니다. Excel 또는 Access에서 쉽게 생성 할 수 있습니다.
중간 파일 : Excel, Access 또는 다른 유형의 파일로, LS 추출과 플랫 파일 생성 사이의 프로세스에서 수동으로 조작됩니다.
LSMW : 레거시 시스템 마이그레이션 워크 벤치 레거시 시스템에서 추출한 플랫 파일을 사용하여 데이터로드를 허용하는 SAP 변환 도구입니다.
상호 참조 테이블 또는 X-Ref 테이블 : 한 값이 상위 필드와 관련된 경우 필드 간의 관계를 보여주는 테이블입니다. 예를 들어 & # 8220; 영업 조직 & # 8221; 자재 유형에 따라 설정됩니다.
WBS : 작업 분류 체계.
SAP 구현은 리소스 (사람, 돈, 시간)와 비즈니스 프로세스 측면에서 모두 중요한 과제입니다. 대부분의 문제는 위험에 처해 있으며, 대부분의 경우 실패는 선택할 수있는 옵션이 아닙니다. 당신 편에 모든 가능성을두기 위해서는 좋은 방법론이 필요합니다. 현실적인 계획, 견고한 조직, 프로세스를 관리하는 방법 및 문제가되기 전에 미끄러짐을 감지하고 수정하는 도구를 제공하는 도구.
스펙 작업을 시작하기 전에 먼저 구성해야합니다. 좋은 계획과 조직 구조를 얻는 데는 첫 번째 초안을 작성하는 데 약 2 주가 소요되므로 프로젝트 조직에 대한 몇 가지 질문이 남습니다. 완전하고 최종적인 계획을 세우려면 적어도 한 주 이상 걸릴 것입니다. 이것들에 관한 어떤 미해결 쟁점이 프로젝트 전체에서 당신을 괴롭힐 것이므로, 다른 단계를 언급하기 전에 이것을 완전히 끝내십시오.
데이터 변환에는 대부분의 부서의 기능 및 기술 자원이 필요합니다. 이 같은 자원은 프로젝트의 다른 부분에 포함될 것입니다. 이러한 이유로 업무 상충의 위험이 높으며 핵심 인력에 과부하가 걸리는 경우 병목 현상이 발생할 수 있습니다. 이러한 이유로 데이터 변환을 프로젝트 내의 프로젝트로 간주해야합니다. 이는 프로세스를 수행하는 데 도움이되며 병목 현상이 발생하기 전에 충돌하는 리소스 사용을 예견하고 해결할 수있는 완벽한 변환 계획을 준비하는 것으로 해석됩니다.
데이터 변환의 주요 단계는 다음과 같습니다.
데이터 변환 구성 (프로젝트 관리자 및 데이터 변환 코디네이터)
데이터 변환 계획 작업 부하가있는 WBS 리소스가로드되는 일정 계획.
Business Objects 데이터 변환 (Business Object DC의 책임 리소스)
데이터 퍼지 및 클렌징 매핑 및 변환 규칙 규칙에서 프로그램 추출 및로드 데이터 및 규칙 적용 (테스트 후 규칙 및 프로그램 조정)로드 단위 테스트 (단일 테스트 및 수동 데이터 소량) 추출 및로드 전체 크기 테스트 (데이터 테스트 및 검증 - 실제 추출 된 데이터로 대량 생산) ACCEPTANCE SYSTEM에 전체 데이터로드 PRE PRODUCTION SYSTEM에 전체 데이터로드 변환 된 데이터 및 주요 사용자 + Business Objects 소유자 확인 Signoff PRODUCTION SYSTEM 및 최종 Signoff 로의 완전한 변환.
데이터 변환 계획.
비즈니스 개체.
Business Object는 자재 마스터, 공급 업체 마스터, 재고, 주문, 구매 요청 또는 조직 구성 단위와 같은 항목을 정의하는 데이터의 일반 범주입니다. 첫 번째 단계는 SAP 구현에서 어떤 비즈니스 객체 (객체)가 필요한지 식별하는 것입니다.
SAP 시스템에는 마스터 데이터, 트랜잭션 데이터 및 기록 데이터의 세 가지 유형의 데이터가 있습니다.
마스터 데이터. 응용 프로그램 마스터 데이터는 일단 정의되면보다 정적 인 경향이 있습니다. 대부분의 마스터 데이터는 레거시 애플리케이션에 의해 구동 될 수 있습니다. 예를 들면 공급 업체, 고객, 계좌 차트, 자산, BOM, 자재 마스터, 정보 레코드 등이 있습니다. 거래 데이터. 트랜잭션 데이터는 레거시 시스템에서 캡처하여 비즈니스 프로세스 완료를 위해 SAP R / 3 응용 프로그램에 정의해야하는 현재의 미처리 트랜잭션 데이터입니다. 회계 문서, 미결 구매 오더, 미 판매 주문, 역 오더 등이 그 예입니다. 과거 데이터. 레퍼런스 시스템에서는 과거 데이터를 참조 용으로 SAP R / 3 시스템으로 가져와야합니다. 예제에는 마감 구매 주문, 마감 판매 주문, 요약 일반 원장 정보 등이 포함됩니다.
전환 계획을 완료하기위한 정보.
What : 레거시 시스템에서 SAP로 변환 될 비즈니스 개체. 어디에서 데이터를 추출 할 수 있습니까? 얼마나 SAP에 궁극적으로로드 될 레코드 수를 예측합니다. 어떻게 고려해야 할 두 가지 측면이 있습니다 : 레거시 시스템에서 데이터를 추출하는 방법 수동으로 개입하지 않고 레거시 시스템에서 자동으로 추출합니다. 수동으로 채워진 스프레드 시트 자동 레거시 시스템 추출 + 수동 입력을 스프레드 시트에 결합 SAP에 데이터를 주입하는 방법 : 플랫 파일에서 SAP 로의 자동 데이터 전송 온라인 트랜잭션을 사용하여 SAP에 수동으로 데이터 입력 둘의 조합.
선택한 데이터 전송 방법에 따라 필요한 리소스 유형이 결정됩니다. 예를 들어 수동 데이터 입력에는 임시 직원이 필요하고 추출 프로그램을 작성하는 프로그래머는 필요할 수 있습니다. 레거시 시스템에있는 데이터와 전송할 Business Object에 해당하는 SAP 응용 프로그램을 모두 알아야합니다. 한 사람은이 모든 것을 알 필요는 없지만이 정보를 아는 사람들은 서로 긴밀히 협력해야합니다.
컨설턴트 레거시 시스템에서의 데이터 정리 및 제거에 대한 책임 추출의 책임 SAP 비즈니스에서 데이터 로딩 책임자 (각 부서의 책임) 객체 관리자 (하루 단위의 정보 사용 및 데이터 무결성을 책임지고있는 계층 적 소유자 및 데이터 수락을 위해 서명하는 계층 소유자)
주요 비즈니스 개체 변환 순서 :
비즈니스 개체 변환 :
데이터 퍼지 및 클렌징.
레거시 시스템을 제거하고 정리하면 다음 변환 단계에서 많은 시간과 노력을 절약 할 수 있습니다. 가능한 한 빨리 시작하고 가능한 한 많이하십시오. 이는 SAP에 대한 특별한 지식 없이도 가능합니다.
기존 시스템에서 데이터를 전송하기 전에 오래된 데이터와 쓸모없는 데이터를 모두 삭제하십시오. 예를 들어, 지난 2 년 동안 일회성 고객이나 거래가없는 고객은 모두 삭제하고 사용하지 않은 재료는 삭제할 수 있습니다.
이 프로세스는 데이터 불일치를 수정하고 마이그레이션 프로세스 중에 기존 데이터의 무결성을 보장합니다. 예를 들어 고객 및 공급 업체 주소 필드에는 종종 불일치가 많이 있습니다. SAP가 깨끗하게하지 않는 한 SAP는 주소 필드를로드 할 수 없도록 신속하게 알게됩니다.
매핑 및 변환 규칙.
각 비즈니스 오브젝트의 문서에는 다음을 포함하는 데이터 변환 규칙 (또는 스펙)이 들어 있습니다.
* 기존 소스 및 추출 절차.
기존 시스템에서 데이터를 추출하는 방법과 방법. 취할 필요가있는 구체적인 단계를 문서화하십시오.
취할 수있는 청소 단계 및 사용할 추출 필터는 무엇입니까?
적용 지침 또는 여러 필드에서 사용되는 규칙 (따라서 한 번만 입력하면 다시 입력하거나 더 쉽게 업데이트 할 수 있습니다).
사용할 SAP 필드와 각 SAP 필드의 최종 값을 얻는 방법
일반 규칙은 필드 값에 직접적으로 적용되지 않습니다. 예를 들어 레거시 시스템에서 자료 유형을 차별화하는 방식이 그러한 규칙입니다. 필드 규칙은 특정 필드에 값을 제공하는 규칙입니다.
이것은 중요한 것입니다. 메모를 토론하거나 쓸 때 항상 TABLE-FIELD 형식의 필드를 참조하십시오. 프로젝트가 진행됨에 따라 다른 사람들이 동일한 필드에 대해 다른 이름을 사용하기 시작한다는 것을 빨리 알게 될 것입니다. 또한 다른 필드에 대해 동일한 이름을 사용할 수도 있습니다.
또한 일부 필드는 SAP 마스터 데이터의 다른 뷰에 존재합니다. 언젠가 그것은 2 개의 장소에서 보여지는 동일한 분야이며 다른 때는 두 개의 다른 분야입니다. 어떤 경우에 적용되는지를 아는 가장 좋은 방법은 TABLE + FIELD 정보를 얻는 것입니다.
Material Master에서 & # 171; 가용성 점검 & raquo; & # 8220; MRP2 & # 8221; & # 8220; Sales Gen & # 8221; 조회수. 얻을 수있는 각 뷰의 TABLE-FIELD를 보면 :
판매원 : MARC-MTVFP.
두 경우 모두 TABLE-FIELD 이름은 동일하므로 동일한 필드입니다.
고객 마스터에서 필드 & # 8221; 지불 조건 & # 8217; & # 8221; 지불 거래 & # 8221; & # 8220; 결제 & # 8221; 조회수. 얻을 수있는 각 뷰의 TABLE-FIELD를 보면 :
지불 거래 : KNVV - ZTERM.
결제보기 : KNB1- ZTERM.
그것은 같은 분야가 아닙니다. 지급보기에서 필드는 회사 코드에 연결되고 청구서보기에는 영업 조직에 연결됩니다 (테이블 키를 보면이 필드가 나타납니다). 따라서이 두 필드는 서로 다른 값을 가질 수 있습니다.
기술적 방법론.
Material Master를위한 특별한 경우.
Material Master는 모든 도메인을 포함하며 구현의 복잡성에 따라 20 개에서 수백 개까지의 영역을 필요로 할 수 있습니다. 일부 도메인은 다른 도메인에서 사용되고 다른 도메인은 하나의 도메인에서만 사용되지만 그 값은 다른 도메인에서 사용하는 기능에 영향을 미칩니다.
이것은 문서화 할 수있는 가장 복잡한 비즈니스 오브젝트이며, 동시에 변환 프로세스에서 시작해야하는 비즈니스 오브젝트입니다.
첫 번째 단계 : 각 도메인별로 필드를 선택합니다.
컨설턴트와 함께 각 도메인을 가져 와서 매핑 파일을 살펴보고 각 자료 유형의 필드를 살펴보십시오. 여기서 중요한 것은 중요한 모든 필드를보고이를 이해하는 질문을하는 것입니다. 이 작업은 각 도메인별로 별도로 수행되며 서로 다른 매핑 파일에 문서화되어 있습니다. 이 시점에서 우리는 가치가 어디에서 비롯 될 것이며 어떻게 얻을 것인가에 대해서는 관심이 없습니다. 매핑을 마치고 재료 마스터가 무엇인지 이해하도록 노력하십시오. 도메인이 특정 재료 유형에 대한 필드를 선택할 때마다 목록에 도메인 유형을 입력해야합니다. 다음은 MM, PP 및 SD에서 매핑하는 몇 가지 (이론적 인) 예제입니다.
Material Master에서 일부 필드는 다른보기로 입력 / 수정할 수 있습니다. 예를 들어, '입고 일 처리 일수 (MARC-WEBAZ) & rdquo; 구매, MRP2 및 품질 관리보기에 존재합니다. 규칙과로드 프로그램을 수행 할 때 동일한 필드가 다른보기에있을 수 없습니다. 이를 해결하려면 다음과 같이 진행하십시오.
분야의 선두 주자 인 모든 관련 도메인을 확인하고 필드가 포함되어야하는보기를 결정하십시오.
필드에 일주일 (MARC-WEBAZ)의 입고 처리 시간 (예 : MARC-WEBAZ)을 예로 들면 도메인간에 구매보기 (및 다른 곳)를 지정할 수 있습니다.
자재 마스터 변환 :
높은 수준의 공정 설계.
다음은 Material Master Object와 관련된 모든 주요 관점입니다.
기본 데이터 대체 UOM 검사 텍스트 분류 판매 조직 판매 일반 플랜트 구매 대외 무역 수입 & amp; APO 마스터 데이터 내보내기 MRP1 & amp; 2 품질 관리 회계.
일반적으로 함수 스펙 소유자는 위의 뷰에있는 모든 필드를 캡처하고 매핑 논리를 준비하기 위해 기록 방법을 수행합니다.
가장 복잡한 디자인은 Plant merging과 Classification Merging에 포함됩니다. (고위 프로세스 문서 참조)
고객 세그먼트 그룹 유형의 구성원 그룹은 공통 관심사를 공유하는 판매자 또는 판매자가 정의한 사용자 콜렉션입니다.
예 : 채광 회사는 CSG에 Cerro Matoso (CMSA), Metcoal (MTCO), Base Metals (BASE) 등이 있으며,
CSG의 기준에 따라 평가를 위해 LSMW를 통해로드하기 전에 데이터를 분할해야합니다.
분할 논리는 Business Objects 데이터 서비스의 루프 구성 요소를 통해 수행 할 수 있습니다.
데이터 흐름에서 고유 한 CSG를 가져옵니다. 초기 값에서 최대 값과 루프에 대한 순차 번호에 대한 변수를 지정하십시오.
기타 비즈니스 개체 변환 :
다른 BO의 경우 Material Master보다 간단하고 더 적은 인력을 필요로하기 때문에 변환 규칙 문서로 직접 시작할 것입니다. 이 문서에서 우리는 둘 다 필요하며 어떤 필드를 필요로하는지 결정하고 두 번째 단계에서 규칙 작업을 시작합니다.
다음은 BO 변환 규칙의 샘플입니다.
BOM 변환 규칙 샘플.
채권 변환 규칙 샘플을 엽니 다.
공급 업체 마스터 변환 규칙 샘플.
SAP 용어 인 & nbsp; 보증금 & rdquo; 평등 & # 8220; 보유 & rdquo; PRMS.
거래 유형.
PRMS의 TYPE 필드 :
다른 모든 유형은 오류입니다.
추출 및로드 할 때 적용되는 유효성 검사.
부분 PMT & hellip; & hellip; & hellip; ERROR가 아닌 경우 PRMS에서 음수 여야합니다.
신용 메모 & hellip; & hellip; & hellip;이 아니라면 PRMS에서 음수 여야합니다.
차변 메모 & hellip; & hellip; & hellip;은 PRMS에서 양수 여야합니다 (ERROR가 아닌 경우).
다른 유형은 ERROR입니다.
LSM로드 매개 변수.
KTOPL & # 8211; 계좌 차트 : CA00.
BUKRS & # 8211; 회사 코드 : 0070.
GSBER & # 8211; 사업 분야 : 0040.
BUDAT & # 8211; 게시일 : & # 8220; 05-31-02 & rdquo; 또는 마지막 마감 시간의 마지막 날.
오프셋 & # 8211; 계정 (2) : REPRISECL.
SKPERR & # 8211; 스킵 오류 : X.
LSMW (LSMW) :
LSMW는 레거시 시스템에서 SAP 시스템으로 또는 한 SAP 시스템에서 다른 시스템으로 데이터를 마이그레이션하는 데 사용됩니다.
표준 일괄 처리 / 직접 입력 및 녹음 외에도 BAPI 및 IDoc은 기존 데이터 처리를위한 추가 가져 오기 방법으로 사용할 수 있습니다.
LSMW는 다음과 같은 주요 단계로 구성됩니다.
데이터 (스프레드 시트 테이블 및 / 또는 순차 파일의 기존 데이터)를 읽습니다. 데이터를 소스에서 목표 형식으로 변환하십시오. 데이터를 R / 3 응용 프로그램에서 사용하는 데이터베이스로 가져옵니다.
그러나이 단계를 수행하기 전에 다음 단계를 수행해야합니다.
소스 구조 정의 : 소스 파일의 데이터 구조. 목표 구조 정의 : 데이터를받는 SAP의 구조. 필드 매핑 : 변환이있는 원본 및 대상 구조 사이의 매핑 (있는 경우). file : 소스 파일의 위치를 지정하십시오.
BDC, LSMW 및 호출 트랜잭션과 같은 데이터 마이그레이션에 사용되는 방법.
세 가지 방법 모두 데이터를 마이그레이션하는 데 사용됩니다. 이러한 방법의 선택은 시나리오, 전송해야하는 데이터의 양에 따라 다릅니다. LSMW는 SAP에서 제공하는 준비 도구이므로 마스터 데이터를 마이그레이션하는 데 17 단계를 따라야합니다. BDC 세션 메서드는 호출 트랜잭션보다 몇 가지 이점 때문에 더 나은 선택입니다. 그러나 통화 트랜잭션은 소량의 데이터를 즉시 업데이트하는 데 매우 유용합니다. (통화 거래 개발자는 오류를 처리해야합니다.)
SO 결론은 실시간 요구 사항에 따라 이러한 방법을 선택하는 것입니다.
이러한 방법은 현재 상황에 따라 완전히 선택됩니다. 직접 입력 방법은 일부 시나리오에서만 사용할 수있는 것은 아니며 가장 간단한 방법입니다. 배치 입력 방법에서는 관련 트랜잭션에 대한 레코드를 수행해야합니다. 이와 유사하게 IDoc W BAPI가 있으 G로 요구 사항에 따라 이들의 사용을 결정해야합니다.
이 네 가지 방법에 대한 자료를 검토하고 구현하십시오. 그런 다음 어느 것을 사용해야하는지에 대한 올바른 생각을 갖게됩니다.
BDC & # 8211; 배치 데이터 통신입니다. 레거시 시스템에서 SAP 시스템으로 데이터를 변환하는 데 사용됩니다. 기술자 만이 할 수 있습니다. Tcode는 SHDB입니다.
LSMW & # 8211; 레거시 시스템 마이그레이션 워크 벤치입니다. 레거시 시스템에서 SAP 시스템으로의 데이터 변환에도 사용됩니다. 그러나 그것은 기능 컨설턴트의 역할이다.
LSMW에는 14 단계가 있습니다. 한 단계를 완료하면 자동으로 다음 단계로 넘어갑니다.
일반적으로 LSMW를 사용할 수 있습니다. 그러나 40,000 개 이상의 데이터를 전송하려는 경우 LSMW에서는 불가능합니다. 그 때 BDC의 도움을받을 수 있습니다.
판매 주문 VA01 / XD01 고객에 대한 LSMW 데이터 마이그레이션.
8 개의 댓글.
게시물에 댓글을 달거나 회신하려면 로그인해야합니다.
SAP는 SAP (ERP, CRM 등)의 데이터 마이그레이션을 지원하는 무료 컨텐츠를 제공합니다. websmp103.sap-ag. de/rds-dm2erpcrm을 참조하십시오.
이것은 실제로 데이터 마이그레이션 프로세스에 대한 좋은 설명입니다.
매우 유익한 기사 (아마 최고). 게시 유지.
멋지고 구조적이며 잘 쓰여진 문서.
훌륭한 문학 작품.
지식을 공유해 주셔서 감사합니다.
좋은 기사 존 폴!
와우 존 폴이 훌륭한 기사입니다! 매우 유익하고 성공적인 마이그레이션을 위해 필요한 많은 것을 수행합니다. Method360에서 우리는 많은 사람들이 마이그레이션을 위해 필요한 시간을 할애하지 않고 훨씬 일찍 완료 되었어야 할 작업을 되돌리고 많은 시간을 할애해야한다는 것을 알게되었습니다. 특히 데이터 퍼지 및 클린징 단계 클라이언트는 일단 새로운 시스템으로 이전하면 모든것이 수정되지만 오류가 많은 느린 시스템으로 끝납니다. 변경되었거나 더 이상 필요하지 않은 기록 및 마스터 데이터를 검토하는 데 시간을 투자하면 실제로 시스템 속도를 향상시킬 수 있습니다. 고객이 성공하기 위해 필요한 모든 것을 고객이 이해할 수 있도록 무료 워크샵을 만들었습니다. 자유롭게 한 번 봐봐!
기재.
SAP 커뮤니티가 제공하는 혜택을 완전히 누리기 위해서는 다음 사이트에서 등록하십시오 :
SAP 커뮤니티 팀.
Создал (а) Preeti Yadav, редактировал (а) Craig Cmehilмая 2008 년 6 월호.
1. 소개.
이 문서는 한 ERP 시스템에서 다른 ERP (SAP R / 3) 시스템으로 이동할 준비가 된 제조 업계에서 사용할 수있는 데이터 변환 프로세스와 방법론에 대한 개요를 제공합니다.
이 문서의 목적은 전환 프로세스에 대한 자세한 설명을 요약하는 것입니다.
데이터 변환은 응용 프로그램 상호 운용성 또는 비즈니스 사용자의 적극적인 참여가 요구되는 새로운 시스템의 기능을 사용할 수있는 기능을 위해 컴퓨터 데이터 형식을 다른 형식으로 변환하는 것입니다. 조직이 레거시 시스템에서 새 시스템으로 완전히 이동하거나 부분적으로 이동하고 이전 시스템에서 데이터를 수정하려고 할 때 일반적으로 권장됩니다.
2. 개요.
기존 시스템의 새로운 시스템 구현에서 데이터 변환은 필수적이고 중요합니다.
변환 프로세스의 범위에있는 SAP (PTP, OTC 및 PME)의 모든 측면을 다루는 엔티티 / 비즈니스 객체를 준수합니다.
품목 마스터 공급 업체 마스터 고객 마스터 프로그램 번호.
오픈 일정 계약 / 구매 오더 가격 오픈 일정 계약 / 구매 오더 오픈 판매 오더 가격 오픈 영업 오더 표준 원가 데이터 재고 잔고 은행 및 벤더 뱅킹 회사 간 거래 아웃풋 결정 Open AP Open AR.
재무 및 통제 데이터 :
CostCenter 자산 마스터 및 자산 거래 G / L 계정 내부 오더 잔액.
3. 변환 프로세스.
개요 섹션에서 정의 된 복잡성과 여러 이해 관계자를 기반으로 데이터 변환 프로세스는 4 단계로 분류되었습니다.
사전 클렌징 추출 클렌징, 강화 및 변환 사전 및 사후로드 검증, 로드 및 사후로드 지원 사인 오프.
3.1. 사전 클렌징.
이름에서 알 수 있듯이, 사전 정화는 정화되기 전에 시작되며 중대하고 중요한 활동 중 하나입니다. 새로운 시스템에 대한 데이터 추출을 시도하기도 전에 기존 / 기존 시스템에서 수행 된 활동을 다룹니다.
이 프로세스를 추진하는 데 사용 된 IT 리더십 (기존 ERP 시스템의 1 ~ 2 명의 개발자와 함께)과 함께 비즈니스 사용자 (플랜트 컨트롤러, 플랜트 관리자, 구매 커뮤니티, 영업 커뮤니티, 중앙 원가 계산 및 금융, 공급망 관리 등)
이 프로세스의 의도는 다른 단위의 데이터 소유자를 공통 플랫폼으로 가져 와서 변환 할 데이터의 양과 품질에 동의하게 만드는 것입니다.
전 과정에서 스테이크 소지자는 두려운 일이나 SAP에 들어가야 할 것, 또는해야 할 일에 대해 토론하지 않습니다. 이들 비즈니스 오브젝트들, 즉 아이템, PO, SO 등에 관한 데이터베이스 테이블에서, "GOSAP" 만들어졌습니다. PO / SO 및 그 관련 부분에 관한 결정이 이루어지면, 이 필드는 "GOSAP"으로 채워 지곤했다. 또는 "NOSAP"이다. & quot; GOSAP & quot; 값의 광고 항목 추가 처리만을 요구했습니다.
지정된 배치에서 각 플랜트에 대해 실행되어 특정 시점의 데이터 스냅 샷을 찍습니다. 이것은 관련 참가자 또는 참가자 그룹에 대한 작업 항목을 표시하는 데 사용되는 주간 활동이었습니다.
보고서에는 다음 내용이 포함됩니다.
비즈니스 개체 및 관련 중요 특성
레코드 - 연결 끊김 횟수.
Percentage - 주어진 비즈니스 오브젝트에 대한 모든 레코드 수와 비교하여 연결 해제 된 데이터의 부분.
대부분의 비즈니스 관련 질문은이 보고서를 기반으로 답변되었습니다.
전환해야 할 부품 수 확인 사용하지 않는 부품을 식별하지만 표준 PO가 0 인 활성 PO / SO 부품 있음 활성 PO / SO 's이지만 해당 조건 레코드가 없습니다. 즉, 가격 활성 공급 업체는 있지만 거래가 없습니다 (예 : PO). 그들과 관련된 거래 (예 : SO) 활성 고객이지만 해당 공급 업체는 더 이상 필요하지 않습니다. SO`s는 활성화되었지만 해당 고객은 판매 가격 통화와 구매 가격 통화 간의 불일치가 더 이상 필요하지 않습니다.
이는 회사 간 거래를 개별적으로 처리하는 사전 정리 보고서와 같은 방식입니다.
이 보고서를 바탕으로 회사 간 관련 질문의 대부분이 답변되었습니다.
동일한 부품이 다른 공장에서 다르게 설명됩니다. 즉, 동일한 세부 부품 번호 또는 부품 설명이 다르지만 부품 번호가 다릅니다 (예 : 설명 일치) 두 플랜트간에 동일한 부품에 대한 가격 불일치가 있음 판매 플랜트는 하나의 판매 가격을 말합니다. 가격 즉 가격 불일치 한 플랜트와 같은 플랜트 간의 부품 불일치는 판매하고 있다고 말하지만 다른 플랜은 플랜트의 PO 라인 수가 구매자의 SO 번호와 일치하지 않습니다. (UoM) 불일치 Hard Match - 구매 플랜트에서 일치하는 PO, 라인 번호 및 부품이 판매 플랜트의 SO, 라인 번호 및 부품과 일치하는 경우 Soft Match - PO 및 부품 만 구매와 일치하는 경우 식물을 파는 것으로부터 SO와 줄 번호가있는 식물.
All the above mentioned analysis either for 3 rd party or intercompany were discussed in detail with the concerned data owner to arrive at a common platform so that putting junk/garbage into new system could be avoided.
The decisions based on the data owner analysis were as follows.
Convert PO/SO`s only for identified active parts Convert Vendor/Customer based on these active PO/SO`s thus making master data dependent on the transaction data Maintain standard costs for the active items Maintain condition records i. e. Pricing for every PO/SO`s except for future or release orders to customer Resolve selling and buying currency issues and adjusting the prices accordingly For intercompany, Resolve price, parts, currency, UoM discrepancies by doing workshop with both plant controller and central costing and finance team.
3.2. Extract.
After pre-cleansing was done or reaching at the final stages, Data pertaining to each business objects used to be extracted from the legacy system. The extract program was designed with the help of data and process owner considering the correct mapping of fields from legacy system to SAP system. It was developed by the existing system developer in the existing system language and was stored in the central repository called Livelink. For any deployment, the program used to be exported to respective plant database and was executed. The extracts for all the business objects used to be taken at the same time to avoid any discrepancies among the master data and transaction data. Atleast for every legacy field, a new SAP field had been added in the program so that while cleansing/enrichment, data owner compares the values without going into the existing system.
Data used to be extracted in its entirety from the old system which means no business logic in the extraction program/scripts thus reducing one level of complexities. During the pre-cleansing all the data which needed to be converted in the target system was flagged with "GOSAP/NOSAP" status. The cleansing team used to filter the relevant data based on this flag. Data were always extracted and put into flat files for further processing.
3.3. Cleansing, Enrichment and Transform.
As the title suggests, it describes 3 steps in the conversion process.
- Cleansing - Modify/make corrections in the existing data.
- Enrichment - Provide Information which are not present in the existing system but are needed by SAP system.
- Transform - Transform the cleansed/enriched data into load format using a tool called "Trillium"
Though the definition seems quite simple, it was as exhaustive as pre-cleansing cleansing. During this process of conversion completeness, correctness and accuracy of the data is one of the critical tasks which were done during this process.
After Extraction of the data for all the business objects, the data used to be formatted based on pre-defined formatting rules using Trillium and sent to business users/data owners to validate the existing information and provide the additional information (called enrichment) needed by SAP e. g. Vendors have name, address, city, zip code, Phone etc were already present in the existing system which the purchasing community were asked to validate for correctness but they were also asked to fill the information like Sales contact, Commodity that these vendors are supplying, Inco terms, Whether the vendor is minority vendor etc etc which formed the enrichment part. There were data owners for each process areas like PTP, PME and OTC and one had to follow up constantly to get the correct and accurate data from these owners.
Once the cleansed and enriched were sent back, it used to be run again in Trillium to prepare the LSMW input flat file.
For data transformation i. e. cleansing or static enrichment, Trillium was used. A lot of customization has been done in Trillium to get the data file in the format as needed by LSMW tool.
Trillium was preferred as compared to Microsoft access as the formatting tool because of the following reason:
De-duplication and identifying relationships are inbuilt features in Trillium so no manual effort for de-duplication Data Cleansing and Standardization are inbuilt again features in Trillium. So customization to certain extent would give maximum output. Handle multi plants and huge volume of data efficiently and comfortably.
During this process of conversion, data were loaded into SAP system using the upload tool from SAP called LSMW. The LSMW was customized to validate business needs especially for mandatory value attributes, dependencies, sequences and format. Hence it used to serve as the last validation juncture to identify the correctness of the data.
Every business objects had their own customized program.
3.5. Validation after Load.
Reports were developed and run in the SAP system and compare the results against what were extracted/cleansed/enriched and what got loaded to validate the correctness of the data and thus create the credibility between the data owner with the new system.
3.6. Signoff.
This exercise is done before and after the production load so that issues could be resolved before the data gets loaded in production and before the plants go live in SAP.
1 комментарий.
I notice that you do not mention open production orders in your transactional data. What is your suggestion here? My client cannot close all open production order prior to cutover so we need to find an adequate conversion method. We already have a strain on development resources which threatens to push the date, so I want to avoid any more custom code. Are you aware of any standard LSMW objects - direct input, batch input, IDoc or BAPI - that would help here?
성공적인 퓨전 데이터 변환을 계획하는 방법.
Jon Wakefield는 Velocity의 Oracle Business Line 선임 컨설턴트이며 PeopleSoft, Fusion 및 Taleo를 포함한 Oracle 제품에서 16 년 이상의 기능 및 기술 경험을 보유하고 있습니다. Velocity의 전문 서비스 팀의 일원 인 Jon은 Oracle 솔루션의 새로운 개발 및 구현을 담당합니다. jonathan. wakefieldvelocity. cc에서 연락 할 수 있습니다.
많은 기업들이 Oracle Fusion 클라우드 서비스로 전환하고 있으며, 지원 수준이 향상되고 제품이 제공하는 총 소유 비용이 절감됩니다. 귀하의 조직이 퓨전을 구현할 준비를하고 있다면 (여기에서 결정을 내리는 데 도움이되는 정보를 보려면 여기를 클릭하십시오), 고려해야 할 많은 요소가 있습니다. 이 글에서는 오라클 데이터 변환과 같이 과소 평가 될 수있는 큰 문제 중 하나에 집중할 것입니다.
Fusion은 SaaS 제품이기 때문에 테이블을 직접 업데이트 할 수는 없으며 조직의 데이터로 Fusion을 채우기 위해 Oracle이 제공하는 데이터 변환 도구를 활용해야합니다. 주요 작업 툴은 FBL (File-Based Loader)이므로 도구가 작동하는 방식과 지원되는 비즈니스 객체를 이해하는 데 시간을 많이 들일 필요가 있습니다. (Oracle의 사용자 가이드와 개체 목록).
Oracle Fusion에 데이터로드.
퓨전에 데이터를 성공적으로로드하는 열쇠는 기존 시스템에서 데이터를 추출하는 방법입니다. FBL을 사용하려면 Oracle 사양에 따라 형식이 지정된 Fusion에로드 할 모든 데이터가 포함 된 일련의 파이프 구분 파일 (.dat 또는. csv)을 만들어야합니다 (지원되는 모든 필드 및 형식의 스프레드 시트를 보려면 여기를 클릭하십시오) . 그런 다음 FBL은 해당 파일을 가져 와서 각 필드에 포함 된 값에 따라 Fusion 테이블을 채 웁니다. 필요한 것으로 생각되는 파일을 신중하게 채우는 프로세스를 설계해야하며 각 필드 값의 형식이 올바르게 지정되었는지 확인해야합니다. 그렇게하면 잠재적 인로드 오류를 크게 줄이고 데이터 변환 프로세스에서 많은 위험과 스트레스를 제거 할 수 있습니다.
원하는대로 여러 가지 옵션을 사용할 수 있지만, 시작하기에 적합한 세 가지 방법을 제공합니다. 그것들은 PeopleSoft 지향적인데, Fusion을 배우기 전에 필자의 주요 전문 지식 이었지만, 각각을 주도하는 기본 개념은 다른 ERP 시스템에도 적용 가능합니다.
3 Oracle Fusion 데이터로드를위한 데이터 변환 전략 옵션.
쿼리가 조직의 변환 노력을 수용 할 수 있다고 생각하지 않고 SQR을 만들고 싶지 않으면 좋은 대안이 될 수 있습니다.
제출해 주셔서 감사합니다.
&부; 2017 Velocity Technology Solutions, Inc. 판권 소유.
이 문서에서는 레거시 시스템에서 데이터 전송을 구성하고 수행하는 데 도움이되는 절차를 제공합니다.
그것은 다른 구현에서 성공적으로 사용한 데이터 마이그레이션을위한 방법론을 설명합니다. 그것은 이전 경험을 바탕으로합니다. 콘텐츠 나 결과에 대해 어떠한 보증도하지 않습니다. 이 가이드는 당신에게 제안을 제공합니다. 힌트를 얻고 자신의 방법론을 구성하는 것은 당신에게 달려 있습니다.
마이그레이션 프로젝트의 일반적인 용어 및 약어 :
주 : SAP W R / 3라는 용어는 모두 SAP R / 3 시스템을 지칭하기 위해 상호 교환 가능하게 사용됩니다.
Big Five : Big Five를 언급 할 때, 그것은 Material Master, Customer Master, Vendor Master, Bill of Materials (BOM) 및 Routing을 의미합니다.
Business Objects : 분석 및 전송 프로세스를 돕기 위해 데이터는 테이블 또는 필드 내용으로 처리되는 것이 아니라 비즈니스 운영 측면에서 개체로 처리됩니다. 이를 Business Objects라고합니다.
DC 책임 비즈니스 개체 : 변환 프로세스 (레거시 데이터 원본 및 무결성, 매핑, 변환 규칙 등)에 책임이 있으며 비즈니스 개체에 대한 계획 일정을 존중해야합니다.
Business Object Owner : 일상 업무에서 정보를 소유하고있는 사람. 이것은 비즈니스 객체의 기능 요구 사항에 대한 전략적 선택을하고 변환 된 데이터의 최종 유효성 검사를 수행하는 사람입니다. & # 8220; 비즈니스 오브젝트가 작동하지 않는 경우 직접 영향을 많이받을 수있는 가장 높은 계층 적 사용자 & rdquo;
데이터 변환 & amp; 데이터 마이그레이션 : 데이터 변환 프로세스. & # 8220; 데이터 변환 & rdquo; & # 8220; 데이터 이전 & rdquo; 용어는 문서에서 상호 교환 가능하게 사용됩니다.
DC : 데이터 변환 프로세스의 약자.
도메인 : 프로젝트 내의 기능 도메인 (예 : Finance, Sales, Production 등)
플랫 파일 : SAP로 데이터를 가져 오는 데 사용되는 파일 형식입니다. 플랫 파일은 필드 사이에 탭 구분자가있는 일반 텍스트 파일입니다. Excel 또는 Access에서 쉽게 생성 할 수 있습니다.
중간 파일 : Excel, Access 또는 다른 유형의 파일로, LS 추출과 플랫 파일 생성 사이의 프로세스에서 수동으로 조작됩니다.
LSMW : 레거시 시스템 마이그레이션 워크 벤치 레거시 시스템에서 추출한 플랫 파일을 사용하여 데이터로드를 허용하는 SAP 변환 도구입니다.
상호 참조 테이블 또는 X-Ref 테이블 : 한 값이 상위 필드와 관련된 경우 필드 간의 관계를 보여주는 테이블입니다. 예를 들어 & # 8220; 영업 조직 & # 8221; 자재 유형에 따라 설정됩니다.
WBS : 작업 분류 체계.
SAP 구현은 리소스 (사람, 돈, 시간)와 비즈니스 프로세스 측면에서 모두 중요한 과제입니다. 대부분의 문제는 위험에 처해 있으며, 대부분의 경우 실패는 선택할 수있는 옵션이 아닙니다. 당신 편에 모든 가능성을두기 위해서는 좋은 방법론이 필요합니다. 현실적인 계획, 견고한 조직, 프로세스를 관리하는 방법 및 문제가되기 전에 미끄러짐을 감지하고 수정하는 도구를 제공하는 도구.
스펙 작업을 시작하기 전에 먼저 구성해야합니다. 좋은 계획과 조직 구조를 얻는 데는 첫 번째 초안을 작성하는 데 약 2 주가 소요되므로 프로젝트 조직에 대한 몇 가지 질문이 남습니다. 완전하고 최종적인 계획을 세우려면 적어도 한 주 이상 걸릴 것입니다. 이것들에 관한 어떤 미해결 쟁점이 프로젝트 전체에서 당신을 괴롭힐 것이므로, 다른 단계를 언급하기 전에 이것을 완전히 끝내십시오.
데이터 변환에는 대부분의 부서의 기능 및 기술 자원이 필요합니다. 이 같은 자원은 프로젝트의 다른 부분에 포함될 것입니다. 이러한 이유로 업무 상충의 위험이 높으며 핵심 인력에 과부하가 걸리는 경우 병목 현상이 발생할 수 있습니다. 이러한 이유로 데이터 변환을 프로젝트 내의 프로젝트로 간주해야합니다. 이는 프로세스를 수행하는 데 도움이되며 병목 현상이 발생하기 전에 충돌하는 리소스 사용을 예견하고 해결할 수있는 완벽한 변환 계획을 준비하는 것으로 해석됩니다.
데이터 변환의 주요 단계는 다음과 같습니다.
데이터 변환 구성 (프로젝트 관리자 및 데이터 변환 코디네이터)
데이터 변환 계획 작업 부하가있는 WBS 리소스가로드되는 일정 계획.
Business Objects 데이터 변환 (Business Object DC의 책임 리소스)
데이터 퍼지 및 클렌징 매핑 및 변환 규칙 규칙에서 프로그램 추출 및로드 데이터 및 규칙 적용 (테스트 후 규칙 및 프로그램 조정)로드 단위 테스트 (단일 테스트 및 수동 데이터 소량) 추출 및로드 전체 크기 테스트 (데이터 테스트 및 검증 - 실제 추출 된 데이터로 대량 생산) ACCEPTANCE SYSTEM에 전체 데이터로드 PRE PRODUCTION SYSTEM에 전체 데이터로드 변환 된 데이터 및 주요 사용자 + Business Objects 소유자 확인 Signoff PRODUCTION SYSTEM 및 최종 Signoff 로의 완전한 변환.
데이터 변환 계획.
비즈니스 개체.
Business Object는 자재 마스터, 공급 업체 마스터, 재고, 주문, 구매 요청 또는 조직 구성 단위와 같은 항목을 정의하는 데이터의 일반 범주입니다. 첫 번째 단계는 SAP 구현에서 어떤 비즈니스 객체 (객체)가 필요한지 식별하는 것입니다.
SAP 시스템에는 마스터 데이터, 트랜잭션 데이터 및 기록 데이터의 세 가지 유형의 데이터가 있습니다.
마스터 데이터. 응용 프로그램 마스터 데이터는 일단 정의되면보다 정적 인 경향이 있습니다. 대부분의 마스터 데이터는 레거시 애플리케이션에 의해 구동 될 수 있습니다. 예를 들면 공급 업체, 고객, 계좌 차트, 자산, BOM, 자재 마스터, 정보 레코드 등이 있습니다. 거래 데이터. 트랜잭션 데이터는 레거시 시스템에서 캡처하여 비즈니스 프로세스 완료를 위해 SAP R / 3 응용 프로그램에 정의해야하는 현재의 미처리 트랜잭션 데이터입니다. 회계 문서, 미결 구매 오더, 미 판매 주문, 역 오더 등이 그 예입니다. 과거 데이터. 레퍼런스 시스템에서는 과거 데이터를 참조 용으로 SAP R / 3 시스템으로 가져와야합니다. 예제에는 마감 구매 주문, 마감 판매 주문, 요약 일반 원장 정보 등이 포함됩니다.
전환 계획을 완료하기위한 정보.
What : 레거시 시스템에서 SAP로 변환 될 비즈니스 개체. 어디에서 데이터를 추출 할 수 있습니까? 얼마나 SAP에 궁극적으로로드 될 레코드 수를 예측합니다. 어떻게 고려해야 할 두 가지 측면이 있습니다 : 레거시 시스템에서 데이터를 추출하는 방법 수동으로 개입하지 않고 레거시 시스템에서 자동으로 추출합니다. 수동으로 채워진 스프레드 시트 자동 레거시 시스템 추출 + 수동 입력을 스프레드 시트에 결합 SAP에 데이터를 주입하는 방법 : 플랫 파일에서 SAP 로의 자동 데이터 전송 온라인 트랜잭션을 사용하여 SAP에 수동으로 데이터 입력 둘의 조합.
선택한 데이터 전송 방법에 따라 필요한 리소스 유형이 결정됩니다. 예를 들어 수동 데이터 입력에는 임시 직원이 필요하고 추출 프로그램을 작성하는 프로그래머는 필요할 수 있습니다. 레거시 시스템에있는 데이터와 전송할 Business Object에 해당하는 SAP 응용 프로그램을 모두 알아야합니다. 한 사람은이 모든 것을 알 필요는 없지만이 정보를 아는 사람들은 서로 긴밀히 협력해야합니다.
컨설턴트 레거시 시스템에서의 데이터 정리 및 제거에 대한 책임 추출의 책임 SAP 비즈니스에서 데이터 로딩 책임자 (각 부서의 책임) 객체 관리자 (하루 단위의 정보 사용 및 데이터 무결성을 책임지고있는 계층 적 소유자 및 데이터 수락을 위해 서명하는 계층 소유자)
주요 비즈니스 개체 변환 순서 :
비즈니스 개체 변환 :
데이터 퍼지 및 클렌징.
레거시 시스템을 제거하고 정리하면 다음 변환 단계에서 많은 시간과 노력을 절약 할 수 있습니다. 가능한 한 빨리 시작하고 가능한 한 많이하십시오. 이는 SAP에 대한 특별한 지식 없이도 가능합니다.
기존 시스템에서 데이터를 전송하기 전에 오래된 데이터와 쓸모없는 데이터를 모두 삭제하십시오. 예를 들어, 지난 2 년 동안 일회성 고객이나 거래가없는 고객은 모두 삭제하고 사용하지 않은 재료는 삭제할 수 있습니다.
이 프로세스는 데이터 불일치를 수정하고 마이그레이션 프로세스 중에 기존 데이터의 무결성을 보장합니다. 예를 들어 고객 및 공급 업체 주소 필드에는 종종 불일치가 많이 있습니다. SAP가 깨끗하게하지 않는 한 SAP는 주소 필드를로드 할 수 없도록 신속하게 알게됩니다.
매핑 및 변환 규칙.
각 비즈니스 오브젝트의 문서에는 다음을 포함하는 데이터 변환 규칙 (또는 스펙)이 들어 있습니다.
* 기존 소스 및 추출 절차.
기존 시스템에서 데이터를 추출하는 방법과 방법. 취할 필요가있는 구체적인 단계를 문서화하십시오.
취할 수있는 청소 단계 및 사용할 추출 필터는 무엇입니까?
적용 지침 또는 여러 필드에서 사용되는 규칙 (따라서 한 번만 입력하면 다시 입력하거나 더 쉽게 업데이트 할 수 있습니다).
사용할 SAP 필드와 각 SAP 필드의 최종 값을 얻는 방법
일반 규칙은 필드 값에 직접적으로 적용되지 않습니다. 예를 들어 레거시 시스템에서 자료 유형을 차별화하는 방식이 그러한 규칙입니다. 필드 규칙은 특정 필드에 값을 제공하는 규칙입니다.
이것은 중요한 것입니다. 메모를 토론하거나 쓸 때 항상 TABLE-FIELD 형식의 필드를 참조하십시오. 프로젝트가 진행됨에 따라 다른 사람들이 동일한 필드에 대해 다른 이름을 사용하기 시작한다는 것을 빨리 알게 될 것입니다. 또한 다른 필드에 대해 동일한 이름을 사용할 수도 있습니다.
또한 일부 필드는 SAP 마스터 데이터의 다른 뷰에 존재합니다. 언젠가 그것은 2 개의 장소에서 보여지는 동일한 분야이며 다른 때는 두 개의 다른 분야입니다. 어떤 경우에 적용되는지를 아는 가장 좋은 방법은 TABLE + FIELD 정보를 얻는 것입니다.
Material Master에서 & # 171; 가용성 점검 & raquo; & # 8220; MRP2 & # 8221; & # 8220; Sales Gen & # 8221; 조회수. 얻을 수있는 각 뷰의 TABLE-FIELD를 보면 :
판매원 : MARC-MTVFP.
두 경우 모두 TABLE-FIELD 이름은 동일하므로 동일한 필드입니다.
고객 마스터에서 필드 & # 8221; 지불 조건 & # 8217; & # 8221; 지불 거래 & # 8221; & # 8220; 결제 & # 8221; 조회수. 얻을 수있는 각 뷰의 TABLE-FIELD를 보면 :
지불 거래 : KNVV - ZTERM.
결제보기 : KNB1- ZTERM.
그것은 같은 분야가 아닙니다. 지급보기에서 필드는 회사 코드에 연결되고 청구서보기에는 영업 조직에 연결됩니다 (테이블 키를 보면이 필드가 나타납니다). 따라서이 두 필드는 서로 다른 값을 가질 수 있습니다.
기술적 방법론.
Material Master를위한 특별한 경우.
Material Master는 모든 도메인을 포함하며 구현의 복잡성에 따라 20 개에서 수백 개까지의 영역을 필요로 할 수 있습니다. 일부 도메인은 다른 도메인에서 사용되고 다른 도메인은 하나의 도메인에서만 사용되지만 그 값은 다른 도메인에서 사용하는 기능에 영향을 미칩니다.
이것은 문서화 할 수있는 가장 복잡한 비즈니스 오브젝트이며, 동시에 변환 프로세스에서 시작해야하는 비즈니스 오브젝트입니다.
첫 번째 단계 : 각 도메인별로 필드를 선택합니다.
컨설턴트와 함께 각 도메인을 가져 와서 매핑 파일을 살펴보고 각 자료 유형의 필드를 살펴보십시오. 여기서 중요한 것은 중요한 모든 필드를보고이를 이해하는 질문을하는 것입니다. 이 작업은 각 도메인별로 별도로 수행되며 서로 다른 매핑 파일에 문서화되어 있습니다. 이 시점에서 우리는 가치가 어디에서 비롯 될 것이며 어떻게 얻을 것인가에 대해서는 관심이 없습니다. 매핑을 마치고 재료 마스터가 무엇인지 이해하도록 노력하십시오. 도메인이 특정 재료 유형에 대한 필드를 선택할 때마다 목록에 도메인 유형을 입력해야합니다. 다음은 MM, PP 및 SD에서 매핑하는 몇 가지 (이론적 인) 예제입니다.
Material Master에서 일부 필드는 다른보기로 입력 / 수정할 수 있습니다. 예를 들어, '입고 일 처리 일수 (MARC-WEBAZ) & rdquo; 구매, MRP2 및 품질 관리보기에 존재합니다. 규칙과로드 프로그램을 수행 할 때 동일한 필드가 다른보기에있을 수 없습니다. 이를 해결하려면 다음과 같이 진행하십시오.
분야의 선두 주자 인 모든 관련 도메인을 확인하고 필드가 포함되어야하는보기를 결정하십시오.
필드에 일주일 (MARC-WEBAZ)의 입고 처리 시간 (예 : MARC-WEBAZ)을 예로 들면 도메인간에 구매보기 (및 다른 곳)를 지정할 수 있습니다.
자재 마스터 변환 :
높은 수준의 공정 설계.
다음은 Material Master Object와 관련된 모든 주요 관점입니다.
기본 데이터 대체 UOM 검사 텍스트 분류 판매 조직 판매 일반 플랜트 구매 대외 무역 수입 & amp; APO 마스터 데이터 내보내기 MRP1 & amp; 2 품질 관리 회계.
일반적으로 함수 스펙 소유자는 위의 뷰에있는 모든 필드를 캡처하고 매핑 논리를 준비하기 위해 기록 방법을 수행합니다.
가장 복잡한 디자인은 Plant merging과 Classification Merging에 포함됩니다. (고위 프로세스 문서 참조)
고객 세그먼트 그룹 유형의 구성원 그룹은 공통 관심사를 공유하는 판매자 또는 판매자가 정의한 사용자 콜렉션입니다.
예 : 채광 회사는 CSG에 Cerro Matoso (CMSA), Metcoal (MTCO), Base Metals (BASE) 등이 있으며,
CSG의 기준에 따라 평가를 위해 LSMW를 통해로드하기 전에 데이터를 분할해야합니다.
분할 논리는 Business Objects 데이터 서비스의 루프 구성 요소를 통해 수행 할 수 있습니다.
데이터 흐름에서 고유 한 CSG를 가져옵니다. 초기 값에서 최대 값과 루프에 대한 순차 번호에 대한 변수를 지정하십시오.
기타 비즈니스 개체 변환 :
다른 BO의 경우 Material Master보다 간단하고 더 적은 인력을 필요로하기 때문에 변환 규칙 문서로 직접 시작할 것입니다. 이 문서에서 우리는 둘 다 필요하며 어떤 필드를 필요로하는지 결정하고 두 번째 단계에서 규칙 작업을 시작합니다.
다음은 BO 변환 규칙의 샘플입니다.
BOM 변환 규칙 샘플.
채권 변환 규칙 샘플을 엽니 다.
공급 업체 마스터 변환 규칙 샘플.
SAP 용어 인 & nbsp; 보증금 & rdquo; 평등 & # 8220; 보유 & rdquo; PRMS.
거래 유형.
PRMS의 TYPE 필드 :
다른 모든 유형은 오류입니다.
추출 및로드 할 때 적용되는 유효성 검사.
부분 PMT & hellip; & hellip; & hellip; ERROR가 아닌 경우 PRMS에서 음수 여야합니다.
신용 메모 & hellip; & hellip; & hellip;이 아니라면 PRMS에서 음수 여야합니다.
차변 메모 & hellip; & hellip; & hellip;은 PRMS에서 양수 여야합니다 (ERROR가 아닌 경우).
다른 유형은 ERROR입니다.
LSM로드 매개 변수.
KTOPL & # 8211; 계좌 차트 : CA00.
BUKRS & # 8211; 회사 코드 : 0070.
GSBER & # 8211; 사업 분야 : 0040.
BUDAT & # 8211; 게시일 : & # 8220; 05-31-02 & rdquo; 또는 마지막 마감 시간의 마지막 날.
오프셋 & # 8211; 계정 (2) : REPRISECL.
SKPERR & # 8211; 스킵 오류 : X.
LSMW (LSMW) :
LSMW는 레거시 시스템에서 SAP 시스템으로 또는 한 SAP 시스템에서 다른 시스템으로 데이터를 마이그레이션하는 데 사용됩니다.
표준 일괄 처리 / 직접 입력 및 녹음 외에도 BAPI 및 IDoc은 기존 데이터 처리를위한 추가 가져 오기 방법으로 사용할 수 있습니다.
LSMW는 다음과 같은 주요 단계로 구성됩니다.
데이터 (스프레드 시트 테이블 및 / 또는 순차 파일의 기존 데이터)를 읽습니다. 데이터를 소스에서 목표 형식으로 변환하십시오. 데이터를 R / 3 응용 프로그램에서 사용하는 데이터베이스로 가져옵니다.
그러나이 단계를 수행하기 전에 다음 단계를 수행해야합니다.
소스 구조 정의 : 소스 파일의 데이터 구조. 목표 구조 정의 : 데이터를받는 SAP의 구조. 필드 매핑 : 변환이있는 원본 및 대상 구조 사이의 매핑 (있는 경우). file : 소스 파일의 위치를 지정하십시오.
BDC, LSMW 및 호출 트랜잭션과 같은 데이터 마이그레이션에 사용되는 방법.
세 가지 방법 모두 데이터를 마이그레이션하는 데 사용됩니다. 이러한 방법의 선택은 시나리오, 전송해야하는 데이터의 양에 따라 다릅니다. LSMW는 SAP에서 제공하는 준비 도구이므로 마스터 데이터를 마이그레이션하는 데 17 단계를 따라야합니다. BDC 세션 메서드는 호출 트랜잭션보다 몇 가지 이점 때문에 더 나은 선택입니다. 그러나 통화 트랜잭션은 소량의 데이터를 즉시 업데이트하는 데 매우 유용합니다. (통화 거래 개발자는 오류를 처리해야합니다.)
SO 결론은 실시간 요구 사항에 따라 이러한 방법을 선택하는 것입니다.
이러한 방법은 현재 상황에 따라 완전히 선택됩니다. 직접 입력 방법은 일부 시나리오에서만 사용할 수있는 것은 아니며 가장 간단한 방법입니다. 배치 입력 방법에서는 관련 트랜잭션에 대한 레코드를 수행해야합니다. 이와 유사하게 IDoc W BAPI가 있으 G로 요구 사항에 따라 이들의 사용을 결정해야합니다.
이 네 가지 방법에 대한 자료를 검토하고 구현하십시오. 그런 다음 어느 것을 사용해야하는지에 대한 올바른 생각을 갖게됩니다.
BDC & # 8211; 배치 데이터 통신입니다. 레거시 시스템에서 SAP 시스템으로 데이터를 변환하는 데 사용됩니다. 기술자 만이 할 수 있습니다. Tcode는 SHDB입니다.
LSMW & # 8211; 레거시 시스템 마이그레이션 워크 벤치입니다. 레거시 시스템에서 SAP 시스템으로의 데이터 변환에도 사용됩니다. 그러나 그것은 기능 컨설턴트의 역할이다.
LSMW에는 14 단계가 있습니다. 한 단계를 완료하면 자동으로 다음 단계로 넘어갑니다.
일반적으로 LSMW를 사용할 수 있습니다. 그러나 40,000 개 이상의 데이터를 전송하려는 경우 LSMW에서는 불가능합니다. 그 때 BDC의 도움을받을 수 있습니다.
판매 주문 VA01 / XD01 고객에 대한 LSMW 데이터 마이그레이션.
8 개의 댓글.
게시물에 댓글을 달거나 회신하려면 로그인해야합니다.
SAP는 SAP (ERP, CRM 등)의 데이터 마이그레이션을 지원하는 무료 컨텐츠를 제공합니다. websmp103.sap-ag. de/rds-dm2erpcrm을 참조하십시오.
이것은 실제로 데이터 마이그레이션 프로세스에 대한 좋은 설명입니다.
매우 유익한 기사 (아마 최고). 게시 유지.
멋지고 구조적이며 잘 쓰여진 문서.
훌륭한 문학 작품.
지식을 공유해 주셔서 감사합니다.
좋은 기사 존 폴!
와우 존 폴이 훌륭한 기사입니다! 매우 유익하고 성공적인 마이그레이션을 위해 필요한 많은 것을 수행합니다. Method360에서 우리는 많은 사람들이 마이그레이션을 위해 필요한 시간을 할애하지 않고 훨씬 일찍 완료 되었어야 할 작업을 되돌리고 많은 시간을 할애해야한다는 것을 알게되었습니다. 특히 데이터 퍼지 및 클린징 단계 클라이언트는 일단 새로운 시스템으로 이전하면 모든것이 수정되지만 오류가 많은 느린 시스템으로 끝납니다. 변경되었거나 더 이상 필요하지 않은 기록 및 마스터 데이터를 검토하는 데 시간을 투자하면 실제로 시스템 속도를 향상시킬 수 있습니다. 고객이 성공하기 위해 필요한 모든 것을 고객이 이해할 수 있도록 무료 워크샵을 만들었습니다. 자유롭게 한 번 봐봐!
기재.
SAP 커뮤니티가 제공하는 혜택을 완전히 누리기 위해서는 다음 사이트에서 등록하십시오 :
SAP 커뮤니티 팀.
Создал (а) Preeti Yadav, редактировал (а) Craig Cmehilмая 2008 년 6 월호.
1. 소개.
이 문서는 한 ERP 시스템에서 다른 ERP (SAP R / 3) 시스템으로 이동할 준비가 된 제조 업계에서 사용할 수있는 데이터 변환 프로세스와 방법론에 대한 개요를 제공합니다.
이 문서의 목적은 전환 프로세스에 대한 자세한 설명을 요약하는 것입니다.
데이터 변환은 응용 프로그램 상호 운용성 또는 비즈니스 사용자의 적극적인 참여가 요구되는 새로운 시스템의 기능을 사용할 수있는 기능을 위해 컴퓨터 데이터 형식을 다른 형식으로 변환하는 것입니다. 조직이 레거시 시스템에서 새 시스템으로 완전히 이동하거나 부분적으로 이동하고 이전 시스템에서 데이터를 수정하려고 할 때 일반적으로 권장됩니다.
2. 개요.
기존 시스템의 새로운 시스템 구현에서 데이터 변환은 필수적이고 중요합니다.
변환 프로세스의 범위에있는 SAP (PTP, OTC 및 PME)의 모든 측면을 다루는 엔티티 / 비즈니스 객체를 준수합니다.
품목 마스터 공급 업체 마스터 고객 마스터 프로그램 번호.
오픈 일정 계약 / 구매 오더 가격 오픈 일정 계약 / 구매 오더 오픈 판매 오더 가격 오픈 영업 오더 표준 원가 데이터 재고 잔고 은행 및 벤더 뱅킹 회사 간 거래 아웃풋 결정 Open AP Open AR.
재무 및 통제 데이터 :
CostCenter 자산 마스터 및 자산 거래 G / L 계정 내부 오더 잔액.
3. 변환 프로세스.
개요 섹션에서 정의 된 복잡성과 여러 이해 관계자를 기반으로 데이터 변환 프로세스는 4 단계로 분류되었습니다.
사전 클렌징 추출 클렌징, 강화 및 변환 사전 및 사후로드 검증, 로드 및 사후로드 지원 사인 오프.
3.1. 사전 클렌징.
이름에서 알 수 있듯이, 사전 정화는 정화되기 전에 시작되며 중대하고 중요한 활동 중 하나입니다. 새로운 시스템에 대한 데이터 추출을 시도하기도 전에 기존 / 기존 시스템에서 수행 된 활동을 다룹니다.
이 프로세스를 추진하는 데 사용 된 IT 리더십 (기존 ERP 시스템의 1 ~ 2 명의 개발자와 함께)과 함께 비즈니스 사용자 (플랜트 컨트롤러, 플랜트 관리자, 구매 커뮤니티, 영업 커뮤니티, 중앙 원가 계산 및 금융, 공급망 관리 등)
이 프로세스의 의도는 다른 단위의 데이터 소유자를 공통 플랫폼으로 가져 와서 변환 할 데이터의 양과 품질에 동의하게 만드는 것입니다.
전 과정에서 스테이크 소지자는 두려운 일이나 SAP에 들어가야 할 것, 또는해야 할 일에 대해 토론하지 않습니다. 이들 비즈니스 오브젝트들, 즉 아이템, PO, SO 등에 관한 데이터베이스 테이블에서, "GOSAP" 만들어졌습니다. PO / SO 및 그 관련 부분에 관한 결정이 이루어지면, 이 필드는 "GOSAP"으로 채워 지곤했다. 또는 "NOSAP"이다. & quot; GOSAP & quot; 값의 광고 항목 추가 처리만을 요구했습니다.
지정된 배치에서 각 플랜트에 대해 실행되어 특정 시점의 데이터 스냅 샷을 찍습니다. 이것은 관련 참가자 또는 참가자 그룹에 대한 작업 항목을 표시하는 데 사용되는 주간 활동이었습니다.
보고서에는 다음 내용이 포함됩니다.
비즈니스 개체 및 관련 중요 특성
레코드 - 연결 끊김 횟수.
Percentage - 주어진 비즈니스 오브젝트에 대한 모든 레코드 수와 비교하여 연결 해제 된 데이터의 부분.
대부분의 비즈니스 관련 질문은이 보고서를 기반으로 답변되었습니다.
전환해야 할 부품 수 확인 사용하지 않는 부품을 식별하지만 표준 PO가 0 인 활성 PO / SO 부품 있음 활성 PO / SO 's이지만 해당 조건 레코드가 없습니다. 즉, 가격 활성 공급 업체는 있지만 거래가 없습니다 (예 : PO). 그들과 관련된 거래 (예 : SO) 활성 고객이지만 해당 공급 업체는 더 이상 필요하지 않습니다. SO`s는 활성화되었지만 해당 고객은 판매 가격 통화와 구매 가격 통화 간의 불일치가 더 이상 필요하지 않습니다.
이는 회사 간 거래를 개별적으로 처리하는 사전 정리 보고서와 같은 방식입니다.
이 보고서를 바탕으로 회사 간 관련 질문의 대부분이 답변되었습니다.
동일한 부품이 다른 공장에서 다르게 설명됩니다. 즉, 동일한 세부 부품 번호 또는 부품 설명이 다르지만 부품 번호가 다릅니다 (예 : 설명 일치) 두 플랜트간에 동일한 부품에 대한 가격 불일치가 있음 판매 플랜트는 하나의 판매 가격을 말합니다. 가격 즉 가격 불일치 한 플랜트와 같은 플랜트 간의 부품 불일치는 판매하고 있다고 말하지만 다른 플랜은 플랜트의 PO 라인 수가 구매자의 SO 번호와 일치하지 않습니다. (UoM) 불일치 Hard Match - 구매 플랜트에서 일치하는 PO, 라인 번호 및 부품이 판매 플랜트의 SO, 라인 번호 및 부품과 일치하는 경우 Soft Match - PO 및 부품 만 구매와 일치하는 경우 식물을 파는 것으로부터 SO와 줄 번호가있는 식물.
All the above mentioned analysis either for 3 rd party or intercompany were discussed in detail with the concerned data owner to arrive at a common platform so that putting junk/garbage into new system could be avoided.
The decisions based on the data owner analysis were as follows.
Convert PO/SO`s only for identified active parts Convert Vendor/Customer based on these active PO/SO`s thus making master data dependent on the transaction data Maintain standard costs for the active items Maintain condition records i. e. Pricing for every PO/SO`s except for future or release orders to customer Resolve selling and buying currency issues and adjusting the prices accordingly For intercompany, Resolve price, parts, currency, UoM discrepancies by doing workshop with both plant controller and central costing and finance team.
3.2. Extract.
After pre-cleansing was done or reaching at the final stages, Data pertaining to each business objects used to be extracted from the legacy system. The extract program was designed with the help of data and process owner considering the correct mapping of fields from legacy system to SAP system. It was developed by the existing system developer in the existing system language and was stored in the central repository called Livelink. For any deployment, the program used to be exported to respective plant database and was executed. The extracts for all the business objects used to be taken at the same time to avoid any discrepancies among the master data and transaction data. Atleast for every legacy field, a new SAP field had been added in the program so that while cleansing/enrichment, data owner compares the values without going into the existing system.
Data used to be extracted in its entirety from the old system which means no business logic in the extraction program/scripts thus reducing one level of complexities. During the pre-cleansing all the data which needed to be converted in the target system was flagged with "GOSAP/NOSAP" status. The cleansing team used to filter the relevant data based on this flag. Data were always extracted and put into flat files for further processing.
3.3. Cleansing, Enrichment and Transform.
As the title suggests, it describes 3 steps in the conversion process.
- Cleansing - Modify/make corrections in the existing data.
- Enrichment - Provide Information which are not present in the existing system but are needed by SAP system.
- Transform - Transform the cleansed/enriched data into load format using a tool called "Trillium"
Though the definition seems quite simple, it was as exhaustive as pre-cleansing cleansing. During this process of conversion completeness, correctness and accuracy of the data is one of the critical tasks which were done during this process.
After Extraction of the data for all the business objects, the data used to be formatted based on pre-defined formatting rules using Trillium and sent to business users/data owners to validate the existing information and provide the additional information (called enrichment) needed by SAP e. g. Vendors have name, address, city, zip code, Phone etc were already present in the existing system which the purchasing community were asked to validate for correctness but they were also asked to fill the information like Sales contact, Commodity that these vendors are supplying, Inco terms, Whether the vendor is minority vendor etc etc which formed the enrichment part. There were data owners for each process areas like PTP, PME and OTC and one had to follow up constantly to get the correct and accurate data from these owners.
Once the cleansed and enriched were sent back, it used to be run again in Trillium to prepare the LSMW input flat file.
For data transformation i. e. cleansing or static enrichment, Trillium was used. A lot of customization has been done in Trillium to get the data file in the format as needed by LSMW tool.
Trillium was preferred as compared to Microsoft access as the formatting tool because of the following reason:
De-duplication and identifying relationships are inbuilt features in Trillium so no manual effort for de-duplication Data Cleansing and Standardization are inbuilt again features in Trillium. So customization to certain extent would give maximum output. Handle multi plants and huge volume of data efficiently and comfortably.
During this process of conversion, data were loaded into SAP system using the upload tool from SAP called LSMW. The LSMW was customized to validate business needs especially for mandatory value attributes, dependencies, sequences and format. Hence it used to serve as the last validation juncture to identify the correctness of the data.
Every business objects had their own customized program.
3.5. Validation after Load.
Reports were developed and run in the SAP system and compare the results against what were extracted/cleansed/enriched and what got loaded to validate the correctness of the data and thus create the credibility between the data owner with the new system.
3.6. Signoff.
This exercise is done before and after the production load so that issues could be resolved before the data gets loaded in production and before the plants go live in SAP.
1 комментарий.
I notice that you do not mention open production orders in your transactional data. What is your suggestion here? My client cannot close all open production order prior to cutover so we need to find an adequate conversion method. We already have a strain on development resources which threatens to push the date, so I want to avoid any more custom code. Are you aware of any standard LSMW objects - direct input, batch input, IDoc or BAPI - that would help here?
성공적인 퓨전 데이터 변환을 계획하는 방법.
Jon Wakefield는 Velocity의 Oracle Business Line 선임 컨설턴트이며 PeopleSoft, Fusion 및 Taleo를 포함한 Oracle 제품에서 16 년 이상의 기능 및 기술 경험을 보유하고 있습니다. Velocity의 전문 서비스 팀의 일원 인 Jon은 Oracle 솔루션의 새로운 개발 및 구현을 담당합니다. jonathan. wakefieldvelocity. cc에서 연락 할 수 있습니다.
많은 기업들이 Oracle Fusion 클라우드 서비스로 전환하고 있으며, 지원 수준이 향상되고 제품이 제공하는 총 소유 비용이 절감됩니다. 귀하의 조직이 퓨전을 구현할 준비를하고 있다면 (여기에서 결정을 내리는 데 도움이되는 정보를 보려면 여기를 클릭하십시오), 고려해야 할 많은 요소가 있습니다. 이 글에서는 오라클 데이터 변환과 같이 과소 평가 될 수있는 큰 문제 중 하나에 집중할 것입니다.
Fusion은 SaaS 제품이기 때문에 테이블을 직접 업데이트 할 수는 없으며 조직의 데이터로 Fusion을 채우기 위해 Oracle이 제공하는 데이터 변환 도구를 활용해야합니다. 주요 작업 툴은 FBL (File-Based Loader)이므로 도구가 작동하는 방식과 지원되는 비즈니스 객체를 이해하는 데 시간을 많이 들일 필요가 있습니다. (Oracle의 사용자 가이드와 개체 목록).
Oracle Fusion에 데이터로드.
퓨전에 데이터를 성공적으로로드하는 열쇠는 기존 시스템에서 데이터를 추출하는 방법입니다. FBL을 사용하려면 Oracle 사양에 따라 형식이 지정된 Fusion에로드 할 모든 데이터가 포함 된 일련의 파이프 구분 파일 (.dat 또는. csv)을 만들어야합니다 (지원되는 모든 필드 및 형식의 스프레드 시트를 보려면 여기를 클릭하십시오) . 그런 다음 FBL은 해당 파일을 가져 와서 각 필드에 포함 된 값에 따라 Fusion 테이블을 채 웁니다. 필요한 것으로 생각되는 파일을 신중하게 채우는 프로세스를 설계해야하며 각 필드 값의 형식이 올바르게 지정되었는지 확인해야합니다. 그렇게하면 잠재적 인로드 오류를 크게 줄이고 데이터 변환 프로세스에서 많은 위험과 스트레스를 제거 할 수 있습니다.
원하는대로 여러 가지 옵션을 사용할 수 있지만, 시작하기에 적합한 세 가지 방법을 제공합니다. 그것들은 PeopleSoft 지향적인데, Fusion을 배우기 전에 필자의 주요 전문 지식 이었지만, 각각을 주도하는 기본 개념은 다른 ERP 시스템에도 적용 가능합니다.
3 Oracle Fusion 데이터로드를위한 데이터 변환 전략 옵션.
쿼리가 조직의 변환 노력을 수용 할 수 있다고 생각하지 않고 SQR을 만들고 싶지 않으면 좋은 대안이 될 수 있습니다.
제출해 주셔서 감사합니다.
&부; 2017 Velocity Technology Solutions, Inc. 판권 소유.
No comments:
Post a Comment