Object ID

P2P-I-005

Object Type

Interface

Process Team

P2P

Process Owner

Om Chitale

Document Title

ECC to Origami Vendor Interface

Date

9/15/14

FS Document Version

V1.0

Table of Contents
1.

Document History..................................................................................................................

2.

Approvals...............................................................................................................................

3.

Executive Summary...............................................................................................................
3.1 Requirement Overview.......................................................................................................
3.2 Business Driver..................................................................................................................
3.3 Impacted Systems...............................................................................................................
3.4 Change Management Considerations.................................................................................
3.4.1 As-is process................................................................................................................
3.4.2 To-be process...............................................................................................................
3.5 Business Risks/Issues.........................................................................................................
3.5.1 Risks/issues if development is not completed.............................................................
3.5.2 Risks/issues if interface run fails.................................................................................

4.

Process Information...............................................................................................................
4.1 Process Description............................................................................................................
4.2 Business Process Flow.......................................................................................................
4.3 Processing Options.............................................................................................................
4.4 Dependencies......................................................................................................................
4.4.1 Environment / Configuration.......................................................................................
4.4.2 Development Dependencies........................................................................................
4.4.3 Run/Execution Dependencies......................................................................................
4.5 Assumptions.......................................................................................................................

5.

Additional Interface Information.........................................................................................

5.1 Summarize Business Rules..............................................................................................
5.2 Mapping and Transformation...........................................................................................
5.3 Triggers and Other Process Requirements.......................................................................
5.3.1 Triggers.........................................................................................................................
5.3.2 SAP Transaction Information........................................................................................
5.3.3 Legacy Transaction Information...................................................................................
5.4 Data Selection and Run Criteria.......................................................................................
5.5 Performance Requirements..............................................................................................
5.6 Additional Information.....................................................................................................

6.

Security and Controls..........................................................................................................

6.1 Security Requirements.....................................................................................................
6.2 Auditing and Controls Requirements...............................................................................
6.2.1 Special Processing Requirements.................................................................................
6.2.2 Routing Rules............................................................................................................
6.2.3 Error Handling...........................................................................................................
6.2.3.1 Possible reasons for failure.....................................................................................
6.2.3.2 How to handle various errors.................................................................................
6.2.3.3 Notification of Errors.............................................................................................

7.

Unit Test Requirements.......................................................................................................

7.1
7.2

Data Requirements...........................................................................................................
Test Cases.........................................................................................................................

1. Document History
Version

Change Description

Author

Date Released

Original

Om Chitale

9/15/14

Updates after Team Review

Om Chitale

10/8/14

Updates

Om Chitale

10/14/14

2. Approvals
The individuals listed here will be required to review and approve this document.
Role

Name

Signature

Date

P2P Project Lead

Shelley Skinner

10/16/14

Vendor Master

Preet Dhillon

10/14/14

3. Executive Summary
Origami is the Districts Medical Vendor database for Risk Management. Since the business
decision has been made to create and maintain all vendors in ECCs Vendor Master, there
must be an interface that sends data entered into the Vendor Master to Origami.

3.1

Requirement Overview
Data must be passed to Origami from Vendor Master for Origami-relevant vendors. If
changes are made to an Origami vendor in ECC, and that vendor already exists in Origami,
the interface must update the vendor in Origami. If a vendor is added in ECC and deemed
Origami-relevant, the interface must create this vendor in Origami.

3.2

Business Driver
Medical vendors are maintained in Origami. The best practice for vendor maintenance is to
have a single source of input. Therefore, the decision has been made to create and edit basic
data for all vendors in SAP ECC. Since Origami is still maintained as the payables source for
medical claims, it needs vendors in its database. Therefore, this interface is needed to pass
vendor information from the source of entry to the Origami database.

3.3

3.4

Impacted Systems
SAP R/3 (ECC)

Sales and Marketing / SAP CRM

SAP BI

Procurement / SRM

Portal

Middleware

Supply Chain / SCM

Others / Legacy (List Name/Function) _____Origami_________

Change Management Considerations

The Vendor Master team will have to choose the indicator OC or OP in the Vendor
Master, as this will be the systematic indicator to create or edit the vendor in Origami as
a child or parent (Payee or W9) contact.

Role
Vendor Master Maintenance

Estimated Run Frequency

Once per night in batch and available to push
manually

3.4.1 As-is process

All data is processed in Origami. Everything is manually input directly into Origami.
3.4.2 To-be process
The new owner of the interface will be the Vendor Master Maintenance team. This interface
will be run automatically, every night, as a batch run.
Only complete vendor records should pass through the interface (vendors with all requisite
interface mapping fields). If a vendor record is incomplete, the interface should not pass the

data over; in these exception cases, the interface will be run manually after the errors are
addressed.

3.5

Business Risks/Issues
3.5.1 Risks/issues if development is not completed
If we do not develop this object, data will not be transferred to Origami. Checks will have to
be sent via Origami, which goes against Project ONE principles.
3.5.2 Risks/issues if interface run fails
If this interface is not developed, it will impact the Origami Invoice Interface. SnoPUD
would be required to issue the medical claim payments outside of Finance within the Origami
application, decreasing the financial internal controls. There would also be downstream
impact to the IRS 1099 reporting, if the payment details are not housed within SAP. 1099
data would have to be manually extracted from Origami and manually consolidated with the
SAP 1099 data leaving room for human error and potential incorrect reporting to the IRS.

4. Process Information

4.1

Process Description
1) Request comes in to Vendor Master Team to create an Origami-relevant Vendor.
2) Vendor Master Team creates vendor with necessary fields in ECC, including marking
that vendor as Origami Relevant in the custom field created in P2P-E-018.
3) During the Batch Run, the interface picks up all vendors marked as Origami-relevant
and compares them with what exists in Origami.
a. A cross reference table will have to be built to ensure that the interface does
not create duplicates in Origami*. The order in which this duplicate-check
should occur is:
i. SAP Vendor Number (Field is SAP Vendor # in Origami)
ii. Vendor Name & Vendor Address Combination (Fields in Origami are:
Company Name, Street 1, Street 2, City, State, Postal)
4) If that ECC vendor does not exist in Origami, all of the interface data will be
transferred to Origami and a new vendor will be created in the destination system.
5) If, using the cross reference table, the interface determines that the vendor already
exists in the destination system (Origami), it will compare existing Origami data with
what is in Vendor Master. If there are any differences, the Vendor Master data must
override the Origami data.
*Explanation: if Vendor already exists in Origami with the SAP Vendor Number 10000555,
the interface will check a cross-reference table to see if any of the vendors its sending to
Origami have that SAP Vendor Number. If so, the interface knows to overwrite the existing
10000555 Vendor in Origami. If no Vendor Number is maintained in Origami, the interface
will check to see if the combination of SAP Vendor Name and Vendor Address currently exist
in Origami. If that combination exists, the interface will override that Origami vendor. If no
SAP Vendor Number is maintained, and the interface does not find the combination of SAP
Vendor Name and Vendor Address in the Origami cross-reference table, this interface will
create a new Origami vendor.

4.2

Business Process Flow

4.3

Processing Options
Processing Mode (Check all that apply)
Batch

Online via Transaction Code

Online via Menu Path

Frequency (check all that apply)

Annually

Quarterly

Monthly

Weekly

Daily

As needed

Other (If other, describe here)___________________________________

The interface should be run Daily

Volume of execution

Low volume

4.4

Dependencies
4.4.1 Environment / Configuration

SAP Configuration
o Company Code
o Purchasing Organization
o Account Group
o Payment Terms
o Reconciliation Account
o Purchasing Group

SAP Master Data

o GL Master (Reconciliation Accounts)

4.4.2 Development Dependencies

1) P2P-E-018 Vendor Master Enhancement to add Custom Field

4.4.3 Run/Execution Dependencies

4.5

Assumptions

Only Origami-specific fields will be updated in Origami directly.

If any interface-relevant fields are updated in Origami directly, those fields will be
overwritten by this interface. There will be additional fields maintained in Origami
that will not be influenced by this interface.

All employees will come directly from Success Factors (not as part of this interface).

5. Additional Interface Information

5.1

Summarize Business Rules

.
1) Interface all vendors in ECC with the Origami-relevant indicator to Origami
a. If vendor doesnt exist in Origami, transfer all interface data
b. If vendor already exists, compare data in Origami with ECC Vendor Master
and, if there are discrepancies (which would indicate that vendor has been
updated in ECC), override with ECC values

5.2

Mapping and Transformation

ECC to Origami
Interface.xlsx

5.3

Triggers and Other Process Requirements

5.3.1

Triggers
Transaction Name or Batch Job:
List all transaction codes and batch jobs
that would trigger the interface. See
sample text.

Transaction

File Appearing
List name of file and server it would
appear on.

5.3.2

SAP Transaction Information (N/A OPTIONAL)

5.3.3

Legacy Transaction Information (N/A OPTIONAL)

5.4

Data Selection and Run Criteria

Field
Title/Screen
Label

Type

Size

Mandatory

Range
Required

Reference
Field Name

Criteria
Validations

5.5

Performance Requirements
None. Required volume is low and will be run daily.

5.6

Additional Information
None

6. Security and Controls

6.1

Security Requirements
None
Role
Vendor Master Maintenance

Level of Security
Low

None

6.2

Auditing and Controls Requirements

6.2.1

Special Processing Requirements

Application Post Processing:

none

A trigger is initiated after the message has been

processed.
Close Loop Processing:

none

Close Loop Processing is an end to end process

where there are a series of triggers at source and
target which completes the end to end cycle
Audit Trail / Logging

Yes. Only if any fail indicate in batch log

Is Audit Trail or Logging necessary?

Is a check required that all records have been
received? What are the criteria for logging?
Data Encryption / Decryption
Requirements

All Vendor data will be secure (encryption may not

be necessary)

Mention any special requirements for enhanced

security (e.g. Salary, SSN etc.,)

6.2.2 Routing Rules

None - the file will be small and not require splitting.
6.2.3 Error Handling
6.2.3.1

Possible reasons for failure

Reason for
Failure

Incomplete file

Error Message

File is not complete

Special Characters

File not readable

Format or Length
not compatible with
Destination Field

Format or Length not compatible with Destination Field

6.2.3.2

How to handle various errors

Interface
Allow partial entries

Yes

No

Allow partial run

Yes

No

Partial records should not go through (if information for one vendor is incomplete). Partial
runs are allowed (e.g. 9/10 vendors are sent through, and 1 vendor is held).
Users

Drill-down capability within results report

Yes

No

Single line re-run capability

Yes

No

Other Error Handling Considerations:

6.2.3.3

Notification of Errors

A log file should be created with results of the interface. The file should indicate which
vendor records were updated in Origami, which vendor records were created as new Origami
contacts, and which vendor records faced errors and therefore did not interface through. This
log should be sent to clmartin@snopud.com

7. Unit Test Requirements

7.1

Data Requirements

7.2

Test Cases
S.No

Business Requirement

Data to be used for

the test case

Expected Results

New Vendor Created in ECC

Vendor Master without Origami
indicator

This vendor is not

interfaced to
Origami

New Vendor Created in ECC

Vendor Master with Origami
indicator set to O

Vendor is
interfaced to
Origami

Vendor that already had been

interfaced to Origami is edited
(Origami interface-relevant
fields changed)

Data in Origami is
overridden with
ECC data