| Status | |
| Owner | Bernard Ng |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
The purpose of this document is to define the conversion approach to post AP open items without special GL indicator in S/4 HANA.
AP open items are related to vendor line items that have not been cleared and remains as open status during migration cut-off date.
Amounts in legacy involve document currency, local currency and group currency. All currencies will be loaded accordingly unless there is a change in company design where local / group currency changes. Rates are as per the historical postings unless specific requirement calls for a fixed rate eg. group currency rate for consolidation purposes. Offsetting gl accounts in legacy documents will not be considered in this migration scope, they will be migrated in other objects scope eg. GL open item or GL balances.
The scope of this document covers the approach for converting active AP open items from Legacy Source Systems into S/4HANA following the AP open items Master Data Design Standard.
The data from legacy system includes:
The data from legacy system excludes:
| Source | Scope | Source Approx No. of Records | Target System | Target Approx No. of Records |
|---|---|---|---|---|
| PF2 | AP open item | 1000 | 1000 | |
| WP2 | AP open item | 1000 | 1000 | |
| PI2 | AP open item | 500 | 500 | |
Summarize Multi-language Requirement/s, if any
Summarize Document Management requirement, if any
Summarize Legal Requirement/s, if any
Specify any special requirements or considerations that may impact the data conversion process based on specific locations, regulatory compliance or system limitations. Clearly outline any regional or localization requirements such as country-specific data formats, legal reporting obligations or industry standards that must be adhered to (e.g., localization rules for countries like China).
If the data conversion involves third-party systems or external data sources, such as Icertis, describe any additional requirements related to data mapping, transformation logic, validation rules or security measures that must be followed.
With Functional input, document the technical design of the target fields that are in the scope of this document.
The technical design of the target for this conversion approach.
Table | Field | Data Element | Field Description | Data Type | Length (Decimals) | Requirement |
BKPF | BUKRS | Company Code | CHAR | 4 | Mandatory | |
ACDOCA | LIFNR | Vendor | CHAR | 16 | Mandatory | |
BKPF | XBLNR | Reference Document Number | CHAR | 16 | Mandatory | |
BKPF | BLDAT | Document Date | DATE | 10 | Mandatory | |
BKPF | BUDAT | Posting Date | DATE | 10 | Mandatory | |
BKPF | BKTXT | Header Text | CHAR | 50 | Conditional Based on Source Data | |
BKPF | SGTXT | Item Text | CHAR | 50 | Conditional Based on Source Data | |
BSIK | UMSKZ | Special G/L Indicator | CHAR | 1 | Conditional Based on Source Data | |
ACDOCA | WSL | Amount in Document Currency | CURR | 23(2) | Mandatory | |
ACDOCA | HSL | Amount in Local Currency | CURR | 23(2) | Mandatory | |
ACDOCA | KSL | Amount in Group Currency | CURR | 23(2) | Mandatory | |
BKPF | WAERS | Document Currency | Text | 4 | Mandatory | |
BKPF | HWAER | Local Currency | Text | 4 | Mandatory | |
ACDOCA | BZDAT | Value Date | Date | 8 | Conditional Based on Source Data | |
ACDOCA | PRCTR | Profit Centre | Text | 10 | Mandatory | |
BSIK | ZLSPR | Payment Block Key | Text | 1 | Conditional Based on Source Data | |
BSIK | ZLSCH | Payment Method | Text | 1 | Conditional Based on Source Data | |
BSIK | ZTERM | Payment Term | Text | 4 | Conditional Based on Source Data | |
BSIK | ZFBDT | Baseline Date | Date | 8 | Mandatory | |
ACDOCA | RASSC | Company ID of Trading Partner | Text | 6 | Conditional based on Intercompany account used in source and target | |
ACDOCA | ZUONR | Assignment Number | Text | 18 | Conditional Based on Source Data | |
BSEG | LZBKZ | SCB Indicator | CHAR | 3 | Conditional Based on Source Data | |
BKPF | XREF1_HD | Reference field 1 (header) | CHAR | 20 | Conditional Based on Source Data | |
BKPF | 20 | Conditional Based on Source Data | ||||
BSIK | KIDNO | Payment reference | CHAR | 30 | Conditional Based on Source Data | |
BSIK | EBELN | Purchasing document | CHAR | 10 | Conditional Based on Source Data | |
BSIK | EBELP | Purchasing document item | NUMC | 5 | Conditional Based on Source Data |
All data cleansing should take place in the data source system as defined in this document, unless system limitations prevent it.
If data cleansing is managed outside of the source system (e.g. Syniti Migrate, 3rd Party Vendor, DCT), the necessary documentation must be produced and appended to this deliverable for sign-off.
ID | Criticality | Error Message/Report Description | Rule | Output | Source System |
1. | Can load, but business process will fail | Open Item is overdue and aged | Rule 1: Company must be in scope; Rule 2: Rule 3: ;Posting Date is 365 days or longer than current system date; Rule 4: Due Date is prior report execution date. Due Date calculation: o Credit posting to vendor account (BKPF.GLVOR = RFBU and BSIK.SHKZG = H) Due Date = Baseline Date + Number Days as per specified in payment terms defined in line item o Debit posting to vendor account (BKPF.GLVOR = RFBU and BSIK.SHKZG = S) Due Date = Baseline Date | ||
2. | Can load, but business process will fail | Open Items for Employees Vendors
| Rule 1: Company must be in scope; Rule 2: Line item is not having a clearing date; Rule 3: Vendors is with Employee Vendor Account | ||
3. | Can load, but business process will fail | Open items posted to alternative GL | Rule 1: Company must be in scope; Rule 2: Line item is not having a clearing date; Rule 3: The Special GL Indicator field is not initial | ||
4. | Cannot load | Open Items posted for One-Time Vendor | Rule 1: Company must be in scope; Rule 2: Line item is not having a clearing date; Rule 3: Vendors is with One-time Vendor account
| ||
5. | Can load, but business process will fail | Parked Items need to be cleanse | Rule 1: Company must be in scope; Rule 2: Document is parked (document status = “V”) | ||
6. | Can load, but business process will fail | Unapproved Noted Items to cleanse | Rule 1: Company must be in scope; Rule 2: Document is noted (document status = “S”) | ||
7. | Can load, but business process will fail | Monitor documents without payment terms and payment method | Rule 1: Company must be in scope; Rule 2: Document is missing payment terms and / or payment method
|
The high-level process is represented by the diagram below:
Summarize High-Level Process. Include diagrams, where applicable. Include information supporting details of Extract, Transform and Load specific to the Data Object
Extract data from a source into Syniti Migrate. There are 2 possibilities:
The agreed Relevancy criteria is applied to the extracted records to identify the records that are applicable for the Target loads
Req # | Requirement description | Team responsible |
1. | Ensure source tables BKPF, BSIK, BSAK, BFOK_A are extracted in DSP according to the agreed cut-off date in the project plan | Data team |
2. | Perform preliminary completeness check documented in section 5.2.8.1.1 | Data team |
3. | Raise issues as defects if Req # 1 to 2 are not met | Data team |
4. | Repeat Req # 1 to 3 if required | Data team |
5. | Report extraction result to person in charge of APOI conversion | Data team |
| Selection Ref Screen | Parameter Name | Selection Type | Requirement | Value to be entered/set |
|---|---|---|---|---|
<Object> DCT Rules
| Field Name | Field Description | Rule |
|---|---|---|
Field Name | Field description | Rule |
region_group | ORICA region of operation | Region code derived from Company code DCT based on entered Company code. No user input required. |
BKPF-BUKRS | Company Code | Drop down value from company code DCT (only with active for finance indicator) |
ACDOCA-LIFNR | Vendor Account | Drop down value from Business Partner DCT as FI Vendor on required company code level |
ACDOCA-UMSKZ | Special G/L Indicator | Business to determine if document should be reflected as sn special G/L transaction. Special G/L indicator is provided in the mapping table. |
BKPF-XBLNR | Reference Document Number | Business to enter content as per data type and length permitted |
BKPF-BLDAT | Document Date | Business to enter content as per data type and length permitted |
BKPF-BUDAT | Posting Date | Default to Conversion date as per section 2 |
BKPF-BKTXT | Header Text | Business to enter content as per data type and length permitted |
ACDOCA-SGTXT | Item Text | Business to enter content as per data type and length permitted |
BKPF-WAERS | Document Currency Key | Drop down value. Exist as valid 4S Currency Key (TCURT.WAERS) |
ACDOCA-WSL | Amount in Document Currency | |
BKPF-HWAER | Local Currency Key | Default to target Company Code Currency (T001-WAERS) |
ACDOCA-HSL | Amount in Local Currency | Business to enter content. Values should be checked with decimal points for Local currency (TCURX-CURDEC) |
ACDOCA-BZDAT | Value Date | Business to enter content as per data type and length permitted |
ACDOCA-PRCTR | Profit Centre | Drop down value. Exist in Profit Centre DCT and assigned with the same company code |
BSIK-ZLSPR | Payment Block Key | Default value to be used. |
BSIK-ZLSCH | Payment Method | Drop down value. Exist as valid 4S Payment Method (T042Z-ZLSCH where T042Z-LAND1 = T001-LAND1) |
BSIK-ZTERM | Payment Term | Drop down value. Exist as valid 4S Payment Term (T052-ZTERM where T052-KOART = Blank or ‘K’) |
BSIK.ZFBDT | Baseline Date | Business to enter content as per data type and length permitted as per section 3. The Baseline Date will determine the calculation of Payment Due Date (Days in Payment Term + Baseline Date = Payment Due Date) |
ACDOCA-RASSC | Company ID of Trading Partner | Drop down value. Exist as valid 4S Trading Partner (T880-RCOMP) |
ACDOCA-ZUONR | Assignment Number | Business to enter content as per data type and length permitted |
BSEG-LZBKZ | SCB Indicator | Business to enter content as per data type and length permitted |
BKPF- XREF1_HD | Reference field 1 (header) | Business to enter content as per data type and length permitted |
BKPF- XREF2_HD | Reference field 2 (header) | Business to enter content as per data type and length permitted |
BSIK – KIDNO | Payment reference | Business to enter content as per data type and length permitted |
Suggestion to add:
Decimal validation - Check table TCURX for the document currency key and if Decimals (TCURX-CURRDEC) is ‘0’, validate that no decimal value is populated.
List the steps that need to occur before extraction can commence
Item # | Step description | Team responsible |
1. | Any period / year end close activities have been fully completed | Business |
2. | Reconciliation for intercompany payables have been completed, and adjustment made in legacy SAP system | Business |
3. | Reconciliation of migrated Purchase Order is completed before the extraction of Accounts Payable Open Items | Business and Data |
The Target fields are mapped to the applicable Legacy field that will be its source, this is a 3-way activity involving the Business, Functional team and Data team. This identifies the transformation activity required to allow Syniti Migrate to make the data Target ready:
Item # | Step description | Team responsible |
1. | Ensure all the fields that require value mapping, as stipulated Mapping tables, have the latest signed-off mapping files imported into dspMigrate. | Data team |
2. | In tool, select the AP Open Items object. | Data team |
3. | Go to Process Area Launch and Process the Object - AP Open Items - R3 AP Open Items. | Data team |
4. | Launch the Objects to execute transformation. | Data team |
5. | Monitor the transformation progress and ensure performance and completion is within allowed timeframe | Data team |
6. | Generate Pre-Load reports . | Data team |
7. | Generate data load count. | Data team |
8. | Log errors as defects, if any and address resolutions. Close defects. | Data team |
9. | Re-transform and re-validate the Pre-load reports if necessary. | Data team |
10. | Validate the transformed file as part of pre-load validation, raise data defects or provide the pre-load sign-off. | Business |
11. | Analyse and resolve any pre-load defects logged by business. | Data team |
12. | Repeat steps 6 to 11 if necessary | Data team |
13. | Proceed to pre-load validations | Data team |
Transformation Rules
Rule # | Source system | Source Table | Source Field | Source description | Target system | Target Table | Target Field | Target description | Transformation logic |
1. | N/A | N/A | N/A | N/A | S/4HANA | BKPF | BELNR | Document Number | Automatic determination of the Document number in target system. Document Date from source system is migrated into field SGTXT – see transformation rule for Line Item text field below. |
2. | Legacy | BKPF | BUKRS | Company Code | S/4HANA | BKPF | BUKRS | Company Code | Map from source to target using company code mapping table |
3. | Legacy | BSIK | LIFNR | Vendor Account | S/4HANA | ACDOCA | LIFNR | Vendor Account | Map from source to target using Business Partner mapping table. For Vendors, identified as Employee vendors (using Employee Vendor DCT) – post to GL account xxxxxx without any vendor. |
4. | Legacy | BSIK | HKONT | GL Account | S/4HANA | ACDOCA | HKONT | GL Account | Map from source to target using G/L Account mapping table |
5. | Legacy | BKPF | XBLNR | Reference Document Number | S/4HANA | BKPF | XBLNR | Reference Document Number | Copy source value. For Vendors, identified as Employee vendors (using Employee Vendor DCT) – replace legacy value with constant “related” |
6. | Legacy | BKPF | BLDAT | Document Date | S/4HANA | BKPF | BLDAT | Document Date | Copy source value |
7. | Legacy | BKPF | BUDAT | Posting Date | S/4HANA | BKPF | BUDAT | Posting Date | Posting date = Conversion date (last day of month prior go-live) |
8. | Legacy | BKPF | BKTXT | Header Text | S/4HANA | BKPF | BKTXT | Header Text | Copy source value. For Vendors, identified as Employee vendors (using Employee Vendor DCT) – replace legacy value with constant “Empl related” |
9. | Legacy | BSIK | SGTXT | Item Text (For offset posting to conversion take-on G/L account) | S/4HANA | ACDOCA | SGTXT | Item Text | FY+CoCode+DocNumber (example – 2018ECAU3001102743) will be used as Prefix (SGTXT). If source SGTXT is longer than 32 chars, it’ll be cut to fit. Example in S4 will be posted with SGTXT= “2018ECAU3001102743MILLER MINING”. For Vendors, identified as Employee vendors(using Employee Vendor DCT) – replace legacy value with constant “Empl related” |
10. | Legacy | BSIK | WRBTR | Amount in Document Currency | S/4HANA | ACDOCA | WSL | Amount in Document Currency | Copy source value, split by profit centers if required. |
11. | Legacy | BSIK | DMBTR | Amount in Local Currency | S/4HANA | ACDOCA | HSL | Amount in Local Currency | Copy source value if source currency is equal to target currency, |
12. | Legacy | BSIK | DMBE3 | Amount in 3rd Local Currency | S/4HANA | ACDOCA | KSL | Copy source value as the group currency does not change. | |
13. | Legacy | BKPF | WAERS | Document Currency | S/4HANA | BKPF | WAERS | Document Currency | Mapping table - When conversion from ‘old’ Local currency to ‘new’ Local currency applies – refer to section 2. Conversion scope of this document for more details |
14. | Legacy | T001 | WAERS | Local Currency | S/4HANA | BKPF | HWAER | Local Currency | Mapping table - When conversion from ‘old’ Local currency to ‘new’ Local currency applies – refer to section 2. Conversion scope of this document for more details |
15. | Legacy | BSIS | VALUT | Value Date | S/4HANA | ACDOCA | BZDAT | Value Date | Copy source value |
16. | Legacy | BSIS | PRCTR | Profit Centre | S/4HANA | ACDOCA | PRCTR | Profit Centre | Profit centers should be populated on the offset item - conversion take-on G/L account |
17. | Legacy | BSIS | VBUND | Company ID of Trading Partner | S/4HANA | ACDOCA | RASSC | Company ID of Trading Partner | Map from source to target using Trading Partner mapping table |
18. | Legacy | BSIS | ZUONR | Assignment Number | S/4HANA | ACDOCA | ZUONR | Assignment Number | Copy source value. For Vendors, identified as Employee vendors(using Employee Vendor DCT) – replace legacy value with constant “Empl related” |
19. | Legacy | BSIK | UMSKZ | Special G/L Indicator | S/4HANA | BSIK | UMSKZ | Special G/L Indicator | Map from source to target using Special G/L Indicator mapping table. |
20. | Legacy | BSIK | ZLSPR | Payment Block Key | S/4HANA | BSIK | ZLSPR | Payment Block Key | Map from source to target using Payment Block Key mapping table |
21 | Legacy | BSIK | ZLSCH | Payment method | S/4HANA | BSIK | ZLSCH | Payment method | Map from source to target |
22. | BSIK | ZTERM | Payment Term | S/4HANA | BSIK | ZTERM | Payment Term | Map from source to target using Payment term mapping table | |
23. | Legacy | BSIK | ZFBDT | Baseline Date | S/4HANA | BSIK | ZFBDT | Baseline Date | Copy source value |
24. P | Legacy | BSIK | KIDNO | Payment reference | S/4HANA | BSIK | KIDNO | Payment reference | Copy source value |
25. | Legacyor DCT | BSIK | EBELN | Purchasing document | S/4HANA | BSIK | EBELN | Purchasing document | Map it to PO. Open PO cross reference table is used for mapping in both cases. |
26. | Legacy or DCT | BSIK | EBELP | Purchasing document item | S/4HANA | BSIK | EBELN | Purchasing document item | Map it to PO item. Open PO cross reference table is used for mapping. |
| Mapping Table Name | Mapping Table Description |
|---|---|
| Item # | Step Description | Team Responsible |
|---|---|---|
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
The load process includes:
| Item # | Step Description | Team Responsible |
|---|---|---|
Load Phase and Dependencies
Identify the phase as to “when” the load for this object will occur. <Pre-Cutover, Cutover, Post Cutover> and list the steps that need to occur before the load can commence
List the Configurations required before loading can commence
| Item # | Configuration Item |
|---|---|
| Object # | Preceding Object Conversion Approach |
|---|---|
| list the exact title of the conversion object of only the immediate predecessor – this will then confirm the DDD (Data Dependency Diagram) | |
The table below depicts some possible system errors for this data object during data load. All data load error is to be logged as defect and managed within the Defect Management
| Error Type | Error Description | Action Taken |
|---|---|---|
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
| Task | Action |
|---|---|
| title | specific details of what and how the task needs to be performed e.g. which reports are being used etc. |
Any additional key assumptions.