cv060 ap invoices conversion1d

AIM for Business Flows

CV.060 CONVERSION PROGRAM DESIGNS

Motherson SUMI Systems Limited

AP Invoices Conversion

Author: Siddharth Deshpande

Creation Date: December 29, 2009

Last Updated: March 19, 2010

Document Ref: \06.Conversion\1.4 Design Documents

Version: DRAFT 1CD

Approvals:

Siddharth Kumar Project Manager, MSSL

Vandana Avantsa CIO, Project Head, MSSL

CV.060 Conversion Program Designs

Document Control

Change Record

6

Date Author Version Change Reference

29-Dec-09 Siddharth Deshpande Draft 1a No Previous Document07-Jan-10 Dhiraj Kumar Pathak Draft 1b Updated in Existing format08-Jan-10 Dhiraj Kumar Pathak Draft 1c Formatted the document format as per suggestion18-Feb-10 Dhiraj Kumar Pathak Draft 1d Updated the documents as per changes suggested by

functional team and modified template.

Reviewers

Name Position

Gaurav Ratta OracleSreenivasu KudipudiSudhir Sharma OracleOracleSudhir Sharma Oracle

Distribution

Copy No. Name Location

1 Library Master Project Library2 Project Manager34

Note To Holders:

If you receive an electronic copy of this document and print it out, please write your name on the equivalent of the cover page, for document control purposes.

If you receive a hard copy of this document, please write your name on the front cover, for document control purposes.

AP Invoices Conversion File Ref: document.doc (v. DRAFT 1 )

Conversion Assumptions 7 of 18

Doc Ref: \06.Conversion\1.4 Design DocumentsMarch 19, 2010


Contents

Document Control .......................................................................................... ii

Introduction .................................................................................................... 4

Century Date Compliance .........................................................................4

Conversion Assumptions ................................................................................. 6

Scope ........................................................................................................ 7Clean-Up Criteria ...................................................................................... 7

Approach ........................................................................................................ 8

Conversion Tables ..................................................................................... 8Ordering of Tables ....................................................................................8Dependencies ............................................................................................8

Processing Rules ........................................................................................... 10

Filter Rules ................................................................................................... 13

Derivation Rules ...........................................................................................14

Default Values ..............................................................................................15

Download Program Logic .............................................................................16

Interface/Validation Program Logic ..............................................................17

Upload Program Logic ..................................................................................18

Conversion Program Modules .......................................................................20

Conversion Programs ..............................................................................20Automated Conversion Tool Files ...........................................................20

Open and Closed Issues ................................................................................. 21

Open Issues ............................................................................................. 21Closed Issues ........................................................................................... 21

Document Control .......................................................................................... ii

Introduction .................................................................................................... 4

Century Date Compliance .........................................................................4





Conversion Assumptions ................................................................................. 6

Scope ........................................................................................................ 7Clean-Up Criteria ...................................................................................... 7

Approach ........................................................................................................ 9

Conversion Tables ..................................................................................... 9Ordering of Tables ....................................................................................9Dependencies ............................................................................................9

Processing Rules ........................................................................................... 11

Filter Rules ................................................................................................... 13

Derivation Rules ...........................................................................................14

Default Values ..............................................................................................15

Download Program Logic .............................................................................16

Interface/Validation Program Logic ..............................................................17

Upload Program Logic ..................................................................................18

Conversion Program Modules .......................................................................19

Conversion Programs ..............................................................................19Automated Conversion Tool Files ...........................................................19

Open and Closed Issues ................................................................................. 20

Open Issues ............................................................................................. 20Closed Issues ........................................................................................... 20




Introduction

This Conversion Program Design defines the key assumptions, rules, and logic that are needed to create the conversion programs. The conversion program code is not included in this document. The Develop Conversion Programs (CV.080) task contains the actual code that is written and debugged to perform the conversion. The conversion design document is intended to provide the developer with the necessary information for writing accurate conversion programs.

The Conversion Program Design is used to document and communicate the conversion program design specifications for the conversion of an individual business object to the Oracle Applications.

Distribute the Conversion Program Design to:

developers who are responsible for writing the various pieces of conversion code

conversion project staff

client staff member responsible for signing off on the completeness of this program design

overall project manager

conversion project manager

Use the following criteria to ensure the quality of this work product:

Is the conversion data mapping complete? Are there any application setup decisions that have not been finalized which directly impact the data mapping and the accuracy of the conversion code?

Are all of the rules which impact conversion documented so that they can be written in the conversion code?

Is the program logic required to write the conversion code documented?

Century Date Compliance

In the past, two character date coding was an acceptable convention due to perceived costs associated with the additional disk and memory storage requirements of full four character date encoding. As the year 2000 approached, it became evident that a full four character coding scheme was more appropriate.

In the context of AIM for Business Flows, the convention Century Date or C/Date support rather than Year2000 or Y2K support is used. Coding for any future Century Date is now considered the modern business and technical convention.

File Ref: document.doc (v. )


Doc Ref:

Every applications implementation team needs to consider the impact of the century date on their implementation project. As part of the implementation effort, all customizations, legacy data conversions, and custom interfaces need to be reviewed for Century Date compliance.

Programmatically converted legacy data must be translated to the appropriate century date state before being uploaded to the production tables. Manually converted legacy data must be keyed into the data entry forms using 4 digits for the year, where supported.



Doc Ref:

Conversion Assumptions

The following are the AP Invoices conversion criteria assumptions:

The MSSL team will provide data of all Open AP Invoices for conversion from legacy system as per the agreed format.

AP Invoices extract data will be provided in 2 separatefollowing files:-

1) AP_Invoices data.csv

2) AP_Invoice_lines data.csv

Operating Unit detail will be provided by MSSL team in data extract. For testing and developing code developer can Use “SBU5-OU”

Invoice Type will be Standard/Credit Memo/Debit Memo/Prepayment. Functional Team needs to map legacy Invoice Type to oracle Invoice Type. For testing developer can use Standard.

GL Date will be cut off date. Developer can use Sysdate for testing.

Payment Currency and Invoice Currency will be same for all AP Invoices.

Payment Terms needs to be mapped with the Oracle Payment Terms. Mapping will be provided by Functional team. Developer can use ‘NET 30’

Payment Method will be ‘CHECK’ for all Invoices.

Source “Open Invoice Conversion” must be defined before AP Invoice Conversion.

Category D). Developer can leave this field blank.

– TBD). Developer can leave this field blank.

In case of Partial paid invoices only outstanding amount will be converted in Oracle. But we will capture the original amount of the invoice in the invoice header description field.

“Actual Invoice amount – “|| actual_amount

Liability account will be picked up from supplier site level.

For each invoice there will be only one line which will be created.

Distribution account will be provided by the functional team. for Prepayments should be picked up from supplier site’s PREPAY_CODE_COMBINATION_ID. Functional team will provide the account information in case of Invoice/Credit Memo/Debit Memo .For testing developer can use 4122 code_combination.

Invoice amount will be sum of line amounts for each invoice.

In Case of Foreign Currency rate type will be ‘User’ and exchange rate will be provided by MSSL team. This will be used for both Invoice currency as well as payment currency.

For Prepayments payment term will be always “Immediate”, Settlement date will be same as GL date and prepayment type will be “Temporary”.



Doc Ref:

For Credit Memo and Debit Memo the amount will be negative.

Voucher Number in oracle will be decided later (TBD).

Invoice Line Type will be always “ITEM”

Paygroup will be provided by Business and it will be mapped by Functional team in oracle (TBD). For testing developer can use “EMPLOYEE”.

In case of Invoice paygroup will be provided by Business and it will be mapped by Functional team in oracle (TBD). In case of prepayment, paygroup will be “Prepay –Conv”

Scope

The following boundaries are specific to the conversion of the AP Invoices.

Data Selection Criteria

All valid/open invoice list provided by MSSL IT team are considered for conversion.

Data Manipulation Criteria

All the WHO columns in the interface tables will be populated with the system profile values and sysdate.

Data Production Criteria

All the AP Invoices extracted will be validated at the source legacy system before moving it into the Oracle tables. Only the valid records, which clear the validation rules, will be inserted into the standard interface tables for import.

Data Exclusion Criteria

Those records will be excluded from being imported, which failed in the validation process.

Clean-Up Criteria

Below is a list of clean-up criteria for the conversion of AP Invoices.

Pre-Conversion Clean-Up Criteria

Purge existing error records in interface tables of AP Invoices before any new iteration of conversions (AP_INVOICES_INTERFACE, AP_INVOICE_LINES_INTERFACE).



Doc Ref:

Post-Conversion Clean-Up Criteria

No cleanup activity will take place



Doc Ref:

Approach

This section describes the:

Oracle tables that will be populated during the conversion of AP Invoices

Order in which the tables need to be populated

Dependencies between the tables that need to be populated and any other tables in the Oracle system

Conversion Tables

The following staging tables are going to be populated in the Oracle application for the conversion of AP Invoices:

XXMSL_XXMSSL_AP_INVOICES_STG

XXMSL_AP_INVOICE_LINES_STG

XXMSL_XXMSSL_AP_INV_CONV_ERRORS

Ordering of Tables

Below is the order in which the interface tables need to be populated for the conversion of AP Invoices:

XXMSL_XXMSSL_AP_INVOICES_STG


AP_INVOICES_INTERFACE

AP_INVOICE_LINES_INTERFACE

Dependencies

Foreign Key Dependencies

XXMSL_XXMSSL_AP_INVOICES_STG.INVOICE_NUMBER ->


XXMSL_XXMSSL_AP_INV_CONV_ERRORS



Doc Ref:

INVOICE_NUMBER will be unique and common for XXMSL_XXMSSL_AP_INVOICES_STG ,XXMSL_AP_INVOICE_LINES_STG and XXMSL_XXMSSL_AP_INV_CONV_ERRORS

Parent/Child Dependencies

(Parent) XXMSL_AP_INVOICES_STG. INVOICE_NUMBER=(child) XXMSL_AP_INVOICE_LINES_STG. INVOICE_NUMBERNA

Quick Code Dependencies

TBD, if exists for the mapping or any standard lookup detailsQuick codes .are as follows:-

PAYMENT_METHOD_LOOKUP_CODE

INVOICE TYPE

PAY GROUP

Use of Sequence Generators

AP_INVOICES_INTERFACE_S sequence to be used for populating invoice_id in AP_INVOICES_INTERFACE table.

AP_INVOICE_LINES_INTERFACE_S sequence to be used for populating invoice_line_id in AP_INVOICE_LINES_INTERFACE table



Doc Ref:

Processing Rules

This section lists the processing rules which are to be used in the conversion of AP Invoices:

Rules:

API_PR1: Validation of “Suppplier Number”AP_INVOICES_INTERFACE. VENDOR_IDThis is the unique number used to identify the vendor site in legacy system. Vendor id is mandatory column and can be derived from “Supplier name” as provided. This can be validated from AP_SUPPLIERS.VENDOR_NAME.Validated With : PO_VENDOR_SITES_ALL.PROVINCE Where

VENDOR_SITE_CODE should be derived from Rule API_PR2

Derive : PO_VENDOR_SITES_ALL.VENDOR_IDMapped With Interface : AP_INVOICES_INTERFACE.VENDOR_ID

API_PR2: Validation of “Address Name”AP_INVOICES_INTERFACE. VENDOR_SITE_ID

Validated With : PO_VENDOR_SITES_ALL.VENDOR_SITE_CODE Where PROVINCE should be derived from Rule API_PR1

Derive : PO_VENDOR_SITES_ALL.VENDOR_SITE_IDMapped With Interface : AP_INVOICES_INTERFACE.VENDOR_SITE_ID This is unique number used to identify the vendor site. Vendor site id is mandatory and can be derived from “Supplier Site Name “ as provided in the extract. This can be validated from AP_SUPPLIER_SITES_ALL.VENDOR_SITE_CODE (TBD). For testing developer can use vendor_id =3 and vendor_Site_id =3.

API_PR3: Validation of “Currency”, “Payment Currency”AP_INVOICES_INTERFACE.INVOICE_CURRENCY CODE, AP_INVOICES_INTERFACE.PAYMENT_CURRENCY CODEIt should exist in FND_CURRENCIES table in CURRENCY_CODE column. Payment and Invoice both currencies will be same.

Validate With : FND_CURRENCIES.CURRENCY_CODE Where ENABLED_FLAG = “Y”

Derive : FND_CURRENCIES.CURRENCY_CODEMapped with Interface : AP_INVOICES_INTERFACE.INVOICE_CURRENCY

CODE, AP_INVOICES_INTERFACE.PAYMENT_CURRENCY_CODE

API_PR4: Validation of “Payment Terms”



Doc Ref:

Validate payment terms and derive AP_INVOICES_INTERFACE.TERMS_NAME of the transaction and can be validated from AP_TERMS table. For Prepayment it will be “Immediate”

Validate With : AP_TERMS. NAMEDerive : AP_TERMS. NAMEMapped with Interface : AP_INVOICES_INTERFACE.TERMS_NAME

API_PR5: Validation of “Dist Code Concatenated”AP_INVOICE_LINES_INTERFACE. DIST_CODE_COMBINATION_ID. In case of prepayment, it should be picked up from supplier site’s prepayment account (PO_VENDOR_SITES_ALL .PREPAY_CODE_COMBINATION_ID). This column give the expense accounts of the transaction and need to be validated from GL_CODE_COMBINATIONS table. These column value is provided by Functional team (TBD).Validate With : GL_CODE_COMBINATIONS_KFV.

CONCATENATED_SEGMENTS Where CHART_OF_ACCOUNTS_ID should be derived from ORG_ORGANIZATION_DEFINITIONS for operating unit.

Derive : GL_CODE_COMBINATIONS_KFV. CODE_COMBINATION_ID

Mapped with Interface : AP_INVOICE_LINES_INTERFACE. DIST_CODE_COMBINATION_ID

API_PR6: Validation of “Pay Method” AP_INVOICE_LINES_INTERFACE.LINE_NUMBER

Validate With : AP_LOOKUP_CODES. LOOKUP_CODE Where LOOKUP_TYPE='PAYMENT METHOD'

Derive : AP_LOOKUP_CODES. LOOKUP_CODEMapped with Interface : AP_INVOICE_LINES_INTERFACE. PAYMENT_METHOD_LOOKUP_CODE

API_PR6: Validation of “Tax Code”This column gives the tax code of the transaction and can be validated from AP_TAX_CODES_ALL table. (TBD). For testing developer can pass Null.

API_PR7: Validation of AP_INVOICE_LINES_INTERFACE.LINE_NUMBERThis will bePass always “1” as all open AP Invoice will be migrated to Apps with open balance only with one transaction line.

API_PR8: Validation of TERMS_DATE This should be the payment_due_date – AP_TERMS_LINES. DUE_DAYS (Supplier’s Payment term due days)

API_PR9: Validation of “INVOICE TYPE “



Doc Ref:

Validated with : AP_LOOKUP_CODES.DISPLAYED_FIELD Where AP_LOOKUP_CODES.LOOKUP_TYPE = “INVOICE TYPE”

Derive : AP_LOOKUP_CODES.LOOKUP_CODEValid values are as follows:-Legacy code -> Oracle lookup CodePrepayment -> PREPAYMENTDebit Memo -> DEBIT Standard -> STANDARD Credit Memo -> CREDIT This lookup coded will be used to derive Mapped With : AP_INVOICES_INTERFACE.

INVOICE_TYPE_LOOKUP_CODE

API_PR10: Validation of “Amount”Validation must be as follows “Credit Memo” -> Amount must be negative.

“Debit Memo” -> Amount must be negative. “Standard” -> Amount must be positive“Prepayment” -> Amount must be positive

API_PR11: Validation of “OU” Validated with : HR_ALL_ORGANIZATION_UNITS.NAME Derive : HR_ALL_ORGANIZATION_UNITS.

ORGANIZATION_IDInterface Value : RA_CUSTOMERS_INTERFACE_ALL.ORG_ID

API_PR12: Validation of “Invoice Number” It should be unique for supplier. In case of Prepayment, Pass Prepayment number from data extract as Invoice number.

API_PR13: Validation of AP_INVOICES_INTERFACE.PAY_GROUP_LOOKUP_CODEIt should be “PREPAY-CONV” for Prepay conversion. Validated with : PO_LOOKUP_CODES.DISPLAYED_FIELD Where

PO_LOOKUP_CODES.LOOKUP_TYPE = “PAY GROUP”

Derive : PO_LOOKUP_CODES. LOOKUP_CODEMapped With : AP_INVOICES_INTERFACE.

PAY_GROUP_LOOKUP_CODE

Processing Rule Legacy Data Source* Legacy Data Element* Data Size/Type Target Table. Column* Data Size/Type

API_PR1 XXMSL_XXMSSL_AP_INVOICES_STG

SUPPLIER_NAME VARCHAR2(120)

AP_INVOICES_INTERFACE . VENDOR_ID

NUMBER


VENDOR_SITE_CODESUPPLIER_SITE_NAME

VARCHAR2(25)

AP_INVOICES_INTERFACE . VENDOR_SITE_ID

NUMBER



Doc Ref:

Processing Rule Legacy Data Source* Legacy Data Element* Data Size/Type Target Table. Column* Data Size/Type


INVOICE_CURRENCY_CODE ,

PAYMENT_CURRENCY

VARCHAR2(15)

AP_INVOICES_INTERFACE . INVOICE_CURRENCY_CODE,

AP_INVOICES_INTERFACE . PAYMENT_CURRENCY_CODE

VARCHAR2(15)


PAYMENT_TERM VARCHAR2(50)

AP_INVOICES_INTERFACE.TERMS_NAME

VARCHAR2(50)

API_PR5 XXMSL_XXMSSL_AP_INVOICES_STGXXMSL_AP_INVOICE_LINES_STG

DIST_CODE_COMBINATIONDIST_CODE_COMBINATION_ID

VARCHAR2(240)

AP_INVOICE_LINES_INTERFACE.DIST_CODE_COMBINATION_ID

NUMBER

API_PR6 XXMSL_XXMSSL_AP_INVOICES_STGXXMSL_AP_INVOICE_LINES_STG

PAYMENT_METHODTAX_CODE

VARCHAR2(120)

AP_INVOICES_INTERFACEAP_INVOICE_LINES_INTERFACE . PAYMENT_METHOD_LOOKUP_CODETAX_CODE_ID

VARCHAR2(25) NUMBER

API_PR7 XXMSL_AP_INVOICE_LINES_STG

LINE_NUMBER AP_INVOICE_LINES_INTERFACE. LINE_NUMBER

NUMBER


TERMS_DATE DATE AP_INVOICES_INTERFACE. TERMS_DATE

DATE


INVOICE_TYPE VARCHAR2(25)

AP_INVOICES_INTERFACE. INVOICE_TYPE_LOOKUP_CODE

VARCHAR2(20)


INVOICE_AMOUNT NUMBER AP_INVOICES_INTERFACE.. INVOICE_AMOUNT,AP_INVOICE_LINES_INTERFACE. AMOUNT

NUMBER


OPERATING_UNIT VARCHAR2(50)

AP_INVOICES_INTERFACE.. ORG_ID,AP_INVOICE_LINES_INTERFACE. ORG_ID

NUMBER


INVOICE_NUMBER VARCHAR2(50)

AP_INVOICES_INTERFACE.. INVOICE_NUM

VARCHAR2(50)

API_PR13 AP_INVOICES_INTERFACE.. PAY_GROUP_LOOKUP_CODE

VARCHAR2(25)

Legacy Data Source* <Oracle Staging table name>

Legacy data element* <Oracle staging table column name>

Target table column* <oracle_interface_table_name>.<column_name>



Doc Ref:

Filter Rules

This section lists the filter rules that are to be used in the conversion of AP Invoices:

The record will be automatically excluded if any mandatory column is not populated e.g. source, vendor_id, vendor_site_id, org_id etc.

Rules:

API_FR1: SOURCE column must not be null.

API_FR2: VENDOR_ID, VENDOR_SITE_ID columns must not be null.

API_FR3: INVOICE_DATE/GL_DATE must not be null.

API_FR4: PAYMENT_METHOD_LOOKUP_CODE must not be null.

API_FR5: ORG_ID must not be null.



Doc Ref:

Derivation Rules

NA



Doc Ref:

Default Values

This section lists the default value rules that are to be used in the conversion of AP Invoices. The default value rules explain the logic behind why a certain default value has been selected.

Rules:

API_ DV1: Valid AP_INVOICES_INTERFACE.EXCHANGE_RATE_TYPE, AP_INVOICES_INTERFACE.PAYMENT_CROSS_RATE_TYPEThis column indicates the conversion type of the transaction for foreign currency. The default value should be ‘User’.

API_ DV2: GL_DATE will be SYSDATE-1

API_ DV3: Invoice Description = “Actual Invoice amount – “|| actual_amount. This will be provided in data extract.

API_ DV4: Payment Method = ‘CHECK’

API_ DV5: SOURCE = ‘OPEN INV CONVOPEN INVOICE CONVERSION’

API_ DV6: Line Type = “ITEM”

API_ DV7: INVOICE_ID, Use sequence AP_INVOICES_INTERFACE_S.NEXTVAL for each invoice. For Invoice line it will be AP_INVOICES_INTERFACE_S.CURRVAL.

API_ DV8: INVOICE_LINE_ID, Use sequence AP_INVOICE_LINES_INTERFACE_S.NEXTVAL for each new line of invoice.



Doc Ref:

Download Program Logic

This section describes the logic for the conversion download programs that will be built to support the conversion of AP Invoices. Following are the template files, where the required data conversion would be extracted.

Create the following concurrent programs to upload data from .csv files (legacy system’s data extract) into Oracle Staging Tables.

o Concurrent Program “XXMSL AP Load Open Invoice XXMSSL: AP Open Invoices Uploadheader” will be created to upload data from “AP_Invoices Data.csv” file to “XXMSL_XXMSSL_AP_INVOICES_STG” table

o Concurrent Program “XXMSL AP Load Open Invoice lines” will created to upload data from “Ap_Invoice_Lines Data.csv” file to “XXMSL_AP_INVOICE_LINES_STG” table

The concurrent program type will be “SQL Loader”.

Following table provides the details of source file to the corresponding staging table to which it has to be migrated:

AP_Invoices Data.csv XXMSL_XXMSSL_AP_INVOICES_STG

Ap_Invoice_Lines Data.csv XXMSL_AP_INVOICE_LINES_STG

Errors of the loader program will be available in the corresponding sql loader concurrent program.



Doc Ref:

Interface/Validation Program Logic

This section describes the logic for the conversion interface table creation programs that will be built to support the conversion of AP Invoices.

Staging table to interface table mapping has been provided in “APInv_Interface_table_mapping_with_staging.zip” file. The corresponding rules are mentioned w.r.t each column wherever available.

Create Concurrent Program “XXMSL AP Invoice ConversionXXMSSL: AP Invoices Conversion” will be created with a parameter “Load into Interface Table” with two options 1) Validate and 2) Import

Step 1: Execute program “XXMSL AP Invoice ConversionXXMSSL: AP Invoices Conversion” with Parameter: “Load into Interface Table” and Value: Validate

Step 2: Error data to be re-processed (If necessary)

Step 3: After successful completion of the validation process, execute the program with parameter “Load into Interface Table” and Value: Import

Based upon the rules mentioned in the above sections, data would be processed or defaulted or filtered before populating the interface tables. This will be done by the concurrent program (XXMSL AP Invoice ConversionXXMSSL: AP Invoices Conversion).

After successful validation of invoice header and line data, information will be imported using Standard AP invoice import program as mentioned in next section “Upload Program Logic”.



Doc Ref:

Upload Program Logic

This section describes the logic for the conversion upload programs that will be built to support the conversion of AP Invoices.

Interface Import Program Logic

Run “Payables Open Interface Import” Program if valid records are populated into interface table by “XXMSL AP Invoice ConversionXXMSSL: AP Invoices Conversion” program.

o Parameters

Operating Unit

Source: “Open Invoice ConversionOPEN INV CONV”

Delete from Interface: No

Log Error Messages into program LOG of the Import Program. It can also be tracked from table AP_INTERFACE_REJECTIONS.

For AP Invoices

o Query to select count from AP Invoice Table (Staging Table)

SELECT count(*)“Data received”

FROM XXMSL_XXMSSL_AP_INVOICES_STG;

o Query to select count from AP Invoice Lines Table (Staging Table)

SELECT Count(*)“Data received”

FROM XXMSL_AP_INVOICE_LINES_STG;

o Query to select count from AP Invoice Table (Base Table)

SELECT count(*)“Data Converted”

FROM ap_invoices_all

WHERE source ='OPEN INV CONVOPEN INVOICE CONVERSION';

o Query to select count from AP Invoice Lines Table (Base Table)

SELECT Count(*) “Data Converted”

FROM ap_invoice_lines_all

WHERE invoice_id IN (SELECT invoice_id

FROM ap_invoices_all

WHERE source ='OPEN INV CONV');

In case there is difference between “Data received” and “Data Converted”, investigation needs to be performed on the data not processed.



Doc Ref:



Doc Ref:

Conversion Program Modules

Conversion Programs

The following table lists each program created for the conversion of AP Invoices:

Program Type Program Name Description/Purpose Program Location Developer Flat File: File Name and Location (if any)

Automated Conversion Tool Files

Sequence <Conversion Tool> Template Name

<Conversion Tool>Map File Name

Script Name

Data File Name

Location of Template & Maps

Target Oracle Table

Developer Comments



Doc Ref:

Open and Closed Issues

Open Issues

ID Issue Resolution Responsibility Target Date Impact Date

1 Document Category name is yet to be decided.

2 Document Sequence name for AP Invoice Conversion is yet to be finalized.

3 India Localization Tax information is yet to be decided by functional team.

4 Voucher Number in oracle will be decided later by Functional team.

15 Paygroup will be provided by Business and it will be mapped by Functional team in oracle (TBD). This field should be updated in template if required to be captured from legacy system

6 Supplier Site is still not frozen in supplier conversion (TBD).

7 Tax code for AP Invoice will be decided later by functional team.

Closed Issues

ID Issue Resolution Responsibility Target Date Impact Date

1 India Localization Tax information is yet to be decided by functional team.

Not in AP Invoice Conversion Scope

2 Tax code for AP Invoice will be decided later by functional team.

Not in AP Invoice Conversion Scope

3 Not in AP Invoice Conversion Scope

MSSL Team will provide voucher number in sample data

4 Supplier Site is still not frozen in supplier conversion (TBD).

MSSL Team will provide legacy supplier site number in “Province” field and address name in “Supplier site code” column

5 Document Category name is yet to be decided.

As we are capturing legacy voucher number, this field not required.

6 Document Sequence name for AP Invoice Conversion is yet to be finalized.

As we are capturing legacy voucher number, this field not required.



Doc Ref:

cv060 ap invoices conversion1d

Documents

document format

document ref

controlled document

conversion program code

copy number label

copy number space

document control purposes

distributed copy