Functional Specification Template

SAP Functional Specification v 2.3(for Enhancements, Reports, Configuration, Interfaces)

1. Administrative Details all fields MUST be completedOriginator:

Juergen Schaffert

Date:

04. May 2006

Change Request Number(s):CN3312

Functional Area (Purchasing, Trading, Projects or Finance):Purchasing

SAP Business Centre BPC Name:

N/A

Medas SAP Apps Team Manager:Paul Smith

2. Version History of Specification version history must updated following any updates.Version NumberAuthorDateReason for Update/Comments

0.1Juergen Schaffert04.05.2006First draft

0.2Juergen Schaffert25.05.2006Update after initial comments

0.3Juergen Schaffert26.05.2006Further update after further comments.

0.4Juergen Schaffert26.05.2006Incorporating additional comments

0.5Juergen Schaffert07.06.2006Update after additional detailed analysis. Chapters updated:

10.2 , 10.7, 10.8 removed, 10.9 renumbered to 10.8 and changed

0.6Juergen Schaffert16.06.2006Update of chapter 10 after comments regarding validations

0.7Juergen Schaffert29.06.2006Update of chapter 10 after feedback from first tests.

0.8Juergen Schaffert11.07.2006Update of OB10 file definition

0.9Juergen Schaffert13.07.2006 Update VAT handling

1.0Juergen Schaffert18.07.2006PO lines only once on the same invoice

1.1Fiona Hobbs18.08.2006Update to chapter 10.7-Further processing

3. Business Requirement for Change 3.1 Direct to SAP for OB10 E-Invoices

One of the deliverables of APIPE08 - Accounts Payable Enhancements Project Scope is to provide a systematic solution for matching multiple line E-invoices against corresponding multiple line purchase orders. Kofax does not handle multiple line data; therefore, as a precondition for the multi-line matching, a solution is required to enable the invoice data data for multi-line purchase orders to be loaded to SAP and the corresponding Image to be loaded to Commonstore, to enable this matching process to happen.

3.2Matching of E-Invoice multi line data to multi line purchase order data

Broadly speaking, there are two types of purchasing activity that generate E-Invoices. Quick Order plus purchasing (Q+) and non Quick Order plus (normal) purchasing.

The BBC are undergoing a program of vendor rationalisation and are moving more and more of their external purchasing sourcing to Q+. With this comes a greater number of invoices with multiple lines on them that also have corresponding multiple line purchase orders.

The current APIPS Auto Post Transaction does not cater for posting to multiple line purchase orders. Auto Post is much easier to achieve with E-Invoices as all of the data is present in the data file, combine this with the trend in purchasing highlighted above; it makes sense to extend the Auto Post Functionality to cater for multiple lines.

4. Authorisation Checks Required (if none, state None)

5. Frequency of running

Whenever medas have received files from OB10 via Cyclone, these files will be transferred to a SAP facing server at Stockley Park. The file upload process will then collect those files from that server and attempt to load them to SAP and Commonstore between 7 am and 9.30 am every working day. ZICMS can only read .SAP files, and therefore at approx 6.45 am every working day, the XML files on the In folder are renamed to .SAP files. The timing of this renaming process has to be amended so that it happens every 15 minutes, the last time at 9 am. This ensures that incoming XML files after the 6.45 run will also be picked up to be loaded until 9.30 am.6. Customers 7. Testing Points

Ensure files are only loaded when matching TIFF and XML file available

Ensure files are not loaded if COMMONSTORE is not available

Test check for mandatory fields on XML file

Test file checks for other formal requirements (see below)

Test all aspects of Pre-post checks as detailed below

Test line item matching, both with vendor part number and line item number, as detailed below

Test robustness of line item matching by mixing correct line item no with wrong VPN and vice versa

Test correct posting of MIRO invoice with one item and multiple items

Check correct population of APIPS tables for posted unblocked invoices, rejected (no post) invoices, posted blocked invoices and errored invoices

Test DASHBOARD functionality for all four categories of invoices

Test correct handling of delivery charges as detailed below. Test LUW of MIRO (if applicable), APIPS and COMMONSTORE.8. Timeliness Considerations

9. Inputs (where applicable)

OB10 will continuously (as soon as they are available on OB10) send two files with identical names (except the file extension) as encrypted emails through Lotus Notes to Cyclone Activator Series 5.3, which will in future, as currently, reside on server GBLOVHWS07. One of the files will be an image file (TIFF), whereas the other will be a data file, holding invoice data for further processing (XML file). Here the files will be decoded. Having the files encoded during the transport process is a security requirement, which is also in force currently. Each file contains data for one invoice (the same invoice in both files). The layout for the XML file is as follows:Level LevelLevelCurrent TagMandatory/OptionalAmend Name or New Tag Permissible EntriesValue if BlankDescription

HeaderMAlways a 'AAA############'

Alpha Numeric.

Can not be Blank.Unique OB10 transaction number assigned to each document.

HeaderMSequential Numeric Value of variable length.Can not be Blank.Unique sequence number assigned to each document.

HeaderMI or CCan not be BlankShort code for either Invoice or Credit Note.

HeaderMVariable length alpha & numeric - to 16.Can not be BlankVendors Invoice Number.

HeaderMYYYYMMDDCan not be BlankInvoice Date

HeaderN/AN/AN/AN/ANot required at header level now.

HeaderMChar 10Can not be BlankSAP Invoicing Vendor number.

HeaderM if Doc contains VAT.Char 20'0' if BlankInvoicing Vendors VAT registration number.

HeaderMChar 3 - GBP only.Can not be BlankInvoice Currency

HeaderMChar 16'0' if BlankTotal Net Value of an Invoice.

HeaderMChar 16'0' if BlankTotal Vat Value of an Invoice.

HeaderMChar 16'0' if BlankTotal Gross Value of an Invoice

HeaderOAlpha Numeric - Char 10.'0' if Blank or can not be determined.Post code from the Invoicing Address..

LineMNumber length to 5Sequential Starting from '00001' and incrementing by 1, per document line level provided.Invoice Line Number provided by the Vendor.

LineO43nnnnnnnn, 44nnnnnnnn, 45nnnnnnnn, MRnnnnnnnn, Monnnnnnnn,

M0nnnnnnnn

= 'I':To be filled from Header if not provided by the vendor.

= 'C': Same as above or can be '0' if blank. Can not be Blank for = I.

= C value will be '0'.Purchase Order Number from the Invoice at a line level.

LineONumber length to 6.'0' if Blank.Purchase Order Line Number from the Invoice at a line level.

LineOChar 16

'0' if Blank.Part Number from the Invoice at a line level.

LineMChar 16Can not be Blank.Quantity from the Invoice at a line level.

LineMChar 16Can not be Blank. Net Total from the Invoice at a line level.

LineMChar 16Can not be Blank.VAT Amount for each line.

MChar 2Can not be Blank. Allowable values are:

V1, V4 & V6.SAP short code that identifies the rate of VAT being charged on a document.

There is no limit on the number of items segments passed through.

An invoice will cover only one purchase order. However, to enable future developments for an invoice to cover multiple purchase orders, the po number will be sent through on item level.From GBLOVHWS07, via ftp the files will be sent over to a SAP facing Unix server at Stockley Park. The files will be transferred separately through the already existing WAN link. In a location to be named, there will be three folders: In Folder

Archive Folder

Error Folder

At first, the two files will be sent to the In Folder. The presence of a file in this folder indicates that this file has still to be processed.

The ftp script will run throughout the day. Prior to 7am a script will run to rename the XML to SAP .

Between 7 am and 9.30 am each day, transaction ZICMS will be used to read the XML file data from the In folder on the SP Server into SAP, but only if the folder contains a TIFF and an XML file with identical names ( a date tolerance will be used to avoid unnecessary errors due to timing). The interaction of ZICMS with the three folders is a process currently in use for other purposes, but needs to be amended for the two files solution. Here a file validation takes place, checking the availability of mandatory fields. If the validation check fails, then both the TIFF and XML files will be moved from the In to the Error folder. Otherwise the system will carry on with invoice processing. If there is an error, eg update termination, during invoice processing, the XML and TIFF files will again be moved to the Error folder, otherwise they will be loaded onto the Archive folder.10. Processing RequirementsThe work resulting from this specification will only start from the ZICMS process onwards. Receiving of the files from OB10, storing them in Cyclone and subsequently transferring them to the SP Windows server is not a concern of this specification. However, these processes are also briefly described here to give the full picture.This specification also does not include details regarding the decommissioning of the existing E-Invoice process. This will be detailed in a separate Decommissioning plan.10.1.Infrastructure re Direct to SAP for OB10 E-Invoices10.1.1Current infrastructure

10.1.2Proposed Infrastructure

10.2.

Checks during load of files via ZICMS

During the loading of the TIFF and XML files various checks need to be carried out to ensure that the files comply with various formal requirements.As a general rule, if a file can-not be loaded because it fails a pre-load validation then

both the data file and corresponding Image file should be placed in an error folder and

an alert sent by ZICMS to the SAP logistics team for further investigation. The placement of files in the error folder will generally mean that new files will be

required from OB10.No functionality will be developed to cater for the instance where an invoice has been posted but it subsequently transpires that the Image was not converted properly. This risk will be mitigated by the fact that Medas can request a copy Image from OB10's Image Archive, should it be required. 1. Duplicate . i.e. the Unique 'AAA**' number. OB10 have been known to send multiple invoices where this number is duplicated. This number is stored in zap_elog. There will need to be a ZICMS validation step, to check the number received in the data file against ZAP_ELOG-ZAPTRANSNO, and if a duplicate is found, then do not load the file, but place it in the error folder on the SP server. The follow on process will depend on the circumstances of how this number was allocated by OB10. If the invoice is genuine but OB10 have re-used an already provided Trans.number, then SAP logistics will ask OB10 for a new data file and Image to replace this file. Once received, then, delete the original files. If the original files received from OB10 are genuine duplicates, then SAP logistics will remove the original files as duplicates.2. Duplicate .Validations and procedures should be the same as for duplicate .3. File missing

One of the paired files is missing (either the data file or the Image file) at the time

of the ZICMS upload. This may occur due to the FTP process having to send

across files of the same type separately from the Cyclone server to the Unix server

at Stockley Park or OB10 not sending across paired files.

If this happens an alert should be triggered by ZICMS to SAP Logistics if the files

in question have not been able to be loaded after 2 days from the date and time

stamp derived from the files at a Unix level.

These files will not go into an error folder automatically as the missing file may

be sourced either in subsequent collections from OB10 or as part of the SAP

logistics follow-up from post 2 day files above.

4. Check for mandatory fields

A pre-load validation check should be made to determine that as a minimum that a data file contains entries in the mandatory fields as indicated by an 'M' in the file schema (see section 9). If an entry is missing in a mandatory field, that data file should be placed in the error folder.5. System not up

A check should be made to determine if Commonstore is up and running whilst

files are attempting to load. If it is down, then the load process should be

suspended until it is back up and running.

In this instance files should not be placed in the error folder, as once the

applications are back up and running, loading should commence after business

approval has been gained to do so.6. Only one purchase order

It needs to be ensured that an invoice covers only one purchase order. All fields on the incoming invoice need to be the same.

7. Document type

Field can only be either I or C. Any other value should result in the file placed into the error folder.

8. Purchase Order Number

If is I, then the must be available on all items. If this is not the case, then the file should go into the error folder.

Files will be loaded as a logical unit of work, so that there is no chance of only

one file in the pair being loaded to one application and not the other.

10.3

Pre-post processing error handling Before an attempt is made to post an invoice, various checks with regard to the invoice have to be made. These checks can have either of the following two outcomes:

In Scope

( An attempt is made to post the document into MIRO No post

( No attempt should be undertaken to post the document. Instead, it

should be moved to the dashboard, which means, a

ZAP_DOC_REGISTER record, and a first record of

ZAP_DOC_HISTORY need to be written (Standard Dashboard).

In this case, ZAP_DOC_HISTORY-ZAPLTXT needs to be updated

(comma separated) with a reason, which is mentioned individually in

each section.

RECAT will pick up the document and present to AP clerks for

processing.

The checks to be applied are:

1. Invoice type

Invoices (document type I) are In Scope, including stock invoices (indicated by the corresponding purchase order item showing no auxiliary account assignment). However, VAT only Invoices, which are indicated by an invoice line item quoting a purchase order number, but neither a purchase order line item number nor a vendor part number, are No Post, as are IPTF or DPRS invoices, which are exclusively linked to Independents and therefore are filtered out via a check on the vendor. Credit notes (document type C) are a No post.A fail will result in ZAP_DOC_HISTORY-LTXT to be updated with Document Type Not Invoice.

2. Vendor typeThe Following Vendor Types are In Scope:

-External Vendors account group Z002 (field LFA1-KTOKK)

-Freelancers account group Z009

-Either of the above Vendors who have Alternative Payees. Look-up via P.O. (field EKKO-LIFNR) to obtain the posting Vendor to determine if any Alternate Payees are linked to it. The alternative payee defined for the vendor master on client level can be found on field LFA1-LNRZA. The alternative payee for the vendor defined on company code level can be found on field LFB1-LNRZB. The alternative payee for the vendor defined on purchasing organization level can be accessed via partner function AZ. For this purpose, table WYT3 needs to be accessed for vendor purchasing organization partner function combination in question. If a record is found and field WYT3-LIFN2 is populated, then an alternative payee has been defined on porg level.The Following Vendor Types are not in Scope and would therefore fail the Pre-Check and be treated as a No Post.-Vendors in scope who have Permitted Payees - Look-up via P.O. to obtain the posting Vendor to determine if any Permitted Payees (field

LFZA-EMPFK) are linked to it.

-Independents - Look-up via P.O. to obtain posting vendor, then to Industry Code (field LFA1-BRSCH). If this is value 0600, then the vendor is an Independent.-Artists - P.O Raised on vendor in Account Group Z008.

-One Time - P.O. raised on Vendor in Account Group Z001.-Construction Industry Scheme Vendors. Look-up via P.O. to determine posting Vendor, then look at 'Withholding Tax' field (LFB1-QSSKZ) in the vendor record. If the field is not initial, then the vendor is not in scope.

A fail will result in ZAP_DOC_HISTORY-LTXT to be updated with Vendor Type not in Scope.

3. Down payment

If there is a down payment for any line of the originating po, then the invoice is to be treated as a No Post. Down payments can be recognized on the po history table, where EKBE-VGABE = 4 and EKBE-BEWTP = A.A fail will result in ZAP_DOC_HISTORY-LTXT to be updated with Downpayment on PO.

4. No identification of the po line possibleIf any line item on the incoming invoice is missing both the and , then the whole invoice is a No Post.

This scenario will include VAT only invoices (see below).A fail will result in ZAP_DOC_HISTORY-LTXT to be updated with PO Line/Part Number Missing.

5. Foreign currencyIf either the currency on the P.O. (field EKKO-WAERS) being non GBP or the received in the Data file being non GBP, the invoice is treated as a No Post.

A fail will result in ZAP_DOC_HISTORY-LTXT to be updated with Batch Type not normal.

6. Invoicing vendor = Purchase Order VendorThe on the invoice header should match either the vendor number on the po (field EKKO-LIFNR) or one of its alternative payees (see above).A fail will result in ZAP_DOC_HISTORY-LTXT to be updated with Address Check Fail.

7. Number of line items

The item number field on the accounting document is a three digit field, and as a result, the accounting document can contain a maximum of 999 items. This in turn restricts the very maximum of items to be posted on a MIRO invoice to 998 items (resulting in one vendor line item and 998 GR/IR line items), provided no VAT needs to be posted. In the very rare event that an invoice from OB10 exceeds 998 items, then no attempt to post this invoice should be made, and the invoice should be treated as a No Post.A fail will result in ZAP_DOC_HISTORY-LTXT to be updated with Invoice > 998 line items.

8. Post code match

We are now asking OB10 to provide the Invoicing Vendors Post code in the data file at a header level field . Processing for this should be treated as follows:

If a value is received in , then attempt to match it to the corresponding post code of the Posting vendor (via the Purchase Order). The comparison should only consider letters from A to Z and numbers from 0 to 9. Anything else should be converted to a SPACE. Subsequently the post codes to be compared need to be condensed, leaving out all SPACES, and adjusted to the left of the corresponding post code fields.

A fail will result in ZAP_DOC_HISTORY-LTXT to be updated with Post Code Mismatch (see 10.8.4 below).Only the header level data from the data file is read into ZAP_DOCUMENT_REGISTER, plus the addition of the from line item level. Other item line level data for these documents will not be used for further processing in these instances.

Once a document is returned to the APIPS Dashboard, it will still be possible for that document to Auto Post using the current functionality.

The first update of field ZAP_DOC_HISTORY-ZAPLTXT will fill the first three characters of this field with the value OBE, but without a subsequent comma to separate this value from the error text. 10.4Invoice/purchase order matching processIn order to find the relevant purchase order item for which to post the MIRO invoice, various matching criteria have to be used. If both of Open PO Quantity, then, No Post

-If the Open PO Quantity, then, No Post

-If the