Custom Development Request

Section 1 Request Administration

Request Details

Request ID: <Use ABAP Object List to fill in this field>5100

Request Title: <Use ABAP Object List to fill in this field>
EDI 850 Inbound Customer Purchase Order
Activity Profile No:
System: RD0
Business Process Team: ITC

Document History
Document Status: Status Key:
P In Progress
D Draft Complete
Date Created: A Approved
Configuration Specialist: Telephone:
Approved By Business Date Approved:
Specialist:
Approved By Business Date Approved:
Process Director:
Approved By Technology Date Received:
Leadership:
Received by Date Received:
Xx Technology Owner:

Cross-Functional Dependences

Process Impacted Comments Initial

Area
ITC X
ATI X
SCM (FTP)
SCM (LES)
FCR
HR
PLM

1.1 Document Activity

Interface/Conversion Activity Expected By (Name) Date
Working Copy as of
-1 -
 Custom Development Request

Completion Completed
Date
Functional Specification
Technical Specification
Developer Unit Test
Development Code Review (QA)
Business Unit Test/Sign Off
Business Integration Test
Moved to Production

1.2 Open Issues

Issue No Issue Date Issue Title / Description Priority Resolved Any Other
Date Comments
002 6/26/02 Decision not complete on Low 7/10/02 The 850 blanket
how we will handle the EDI orders will be
Order Report (MKW processed as
ORDCHG
messages from the
EDI subsystem
instead of
ORDERS. The
specification for
the inbound EDI
860 will be used to
govern processing.
A custom process
code will need to
be developed for
860 processing for
an order report.
003 6/26/02 The handling of blanket Low 7/10/02 Blanket orders will
orders could change be processed with
depending on final decisions an ORDCHG
for the EDI Order Report message type and
(MKW) will be governed by
the EDI 860
specification.
004 7/8/02 Who is responsible for Low 7/10/02 Gap – Send to EDI
editing and posting failed and CSR. CSR
inbound 850 documents? If assignment will be
this will involve the order done with partner
entry personnel, we need to function
outline that in the change assignment to the
management section of the sold-to or ship-to
document and include that in with the “Y1”,
the role definitions. “Y2”, “Y3”, and
“Y4” partner
function codes.

Working Copy as of
-2 -
 Custom Development Request

1.3 Change History

Date Modified Modified By Brief Description of Change
6/26/ Added issues 002 – 003
7/8/ Added issues 004, moved requirements to requirements section.
7/8/ Modified issues after EDI meeting today
7/31/ Included additional comments on open issues, included sections
on technical specification.
8/2/ Added issues 016-018, added the information about extending
the idoc for the additional fields, put new links in for the text
fields and put in notes about the description going to text instead
of the actual description

Working Copy as of
-3 -
 Custom Development Request

Section 2 Business Requirements

{This section is to be completed by the Process Team.}

2.1 Requirements Description

{Briefly describe the development request for the enhancement / report / output form (layout set) / interface /
conversion / batch job.}
Allow the processing of inbound customer 850 purchase orders so that an IDOC can be created in R/3 and
loaded as a sales order. If an error occurs during document posting, notification will be provided via workflow
so order entry personnel can manually edit it and successfully load it as a sales order. A separate
enhancement request may be created to format the IDOC data into a readable format (text report) to assist in
reprocessing incomplete inbound 850 orders.

2.2 Business Driver

{Discuss the business need, benefits/alternatives or justification for this development request.}
Xx must be able to process inbound 850 purchase orders as they are the primary method of customer order
transmission for national and large industrial customer accounts.

2.3 General Requirements

2.3.1 Risks
{Describe the risks involved in implementing this development as well as the risks and problems that will be
faced if the development is not done.}
Inability to process inbound 850 purchase orders will severely impact Xx’s service level and competitive edge.

2.3.2 Priority
{Enter a priority for the development according to the following criteria. Enter a description of why this priority
has been assigned.}
Critical Critical part of a process, we cannot go-live without it
High Important parts of a process, Impact functionality, but not go-live
Medium Supports a process; it will save time and effort
Low Nice to have, if there’s time}

Priority Cycle
Critical X Baseline X
High Cycle1
Medium Cycle2
Low

2.3.3 Impacted Software Packages / Business

{Place an ‘X’ next to the appropriate software package or business, to indicate all of the software packages or
business that will be impacted with this development requirement. For example, an interface between SAP R/3
Working Copy as of
-4 -
 Custom Development Request

and Legacy would require an ‘X’ next to both SAP R/3 and Legacy. Likewise, an SAP User Exit (e.g.
enhancement) would require an ‘X’ next to only SAP R/3.}

Impacted? Software Package or Business

X SAP R/3
SCM
WM
Legacy
X EDI Sub-system
BW
TAX Software
X CRM
Portal
{Other – Please Specify}

2.3.4 Change Management Considerations

{List any considerations associated with implementing this objects (e.g. training, communication etc.)}
Customer service representatives will have to be educated on processing IDOCs. Key Changes to the
customer master data will need to be communicated to the Customers. Following teams needs to be re-trained
and communicated with the new procedures :
Xx Customer Care
Xx Branches
FINDMRO Customer Service Agents
GISO On-Site Customer Service Agents
GISO Technical team
Xx Parts

2.3.5 Comments
{This section can be used for any comments that may help with the understanding of the business
requirements for this development.}

2.4 Related Documents

{List all related documents}.
Attach any Workshop notes, email messages on key directions provided by the process team

Working Copy as of
-5 -
 Custom Development Request

Section 3 Functional Specification

{This section is to be completed by the Process Team with assistance from the Technical Teams}

3.1 General Requirements

3.1.0 Baseline Reference
{All: If there is an existing standard functionality or existing custom development which may be leveraged to
complete this custom development requirement request, please list those references here. Examples are:
existing reports, existing enhancements, interfaces, standard delivered BW business content, standard
delivered Portal business package content, standard transaction, existing legacy development, existent SAP
delivered workflow etc.}
Xx is currently doing EDI 850 to receive inbound orders from some of its customers, the map and processing
logic can be used an accelerator/guide to enhance/develop newer maps. The development team also needs to
investigate if the processing ABAP logic can also be enhanced to handle the new customer transactions.
Currently Customer orders are sent to Gentran in the following formats:
 ANSIx12 – 850
 Positional File – (File Specifications agreed upon)
 Xml – ie, UW Madison, State of FL, State of Indiana
 EDIFACT – Orders ie, FORD
 Xcbl – ie, Freeport

3.1.1 Requirements
{All: Provide an overview of the functional design. This section provides a detailed narrative of what process /
business requirements will be fulfilled by the custom development as described at high level in section 2.1
Requirements Description. List here the business rules that govern the custom development as well as any
regulatory, control or process constraint that the technical team should be aware off. In the case of Workflow
provide details the business events, processes, roles that will be integrated through this enhancement}

• Search description for Xx stock number

• Purchase Orders sent into SAP with line level ship to address
• Additional Fields for customer data at the header and line levels. We would need to be able to accommodate
it inbound to SAP and outbound on invoice.
• Better and accurate process for Collect Carriers & Consignment ability in SAP.
• Ad Hoc into SAP, 8&9 item numbers
• Workflow needs to be configured to handle EDI failures. The workflow error resolution should look at
the ship-to partner and find the attached CSR references. If no references are found, the error resolution
procedure should look for any CSR assignments at the sold-to level. If CSR entries are found, the partner
profile notification groups will be removed from notification of the workflow. If no CSR is found, the error
will flow to the group defined on the partner profile.

Working Copy as of
-6 -
 Custom Development Request

• Process orders & items for FINDMRO electronically w/o manual intervention.
Ability to send data into Special Handling field at the header and line level

• All incoming standard orders should be processed as normal order. Blanket orders should not be
inserted into the system, they should be processed as an EDI Order Report (see spec 000_R_O_EO_020-
040 EDI Order Report).
• The system that originates the inbound 850 must be captured and transferred to the sales order in
SAP as the customer purchase order type. Some examples of order types are: Ariba, I-Procure,
Standard EDI, etc.
• EDI will need all partner ids for EDI customers (customer, ship-to, bill-to & sold-to)
• Copy rules from the order to the delivery and invoice will need to be set up for text at header and line item.
• EDI orders and line items on EDI orders should be blocked from deletion by CSR. The CSR should
only be able to cancel so that issues can be tracked.
• Customer material number cross-reference records will be stored according to sold-to and ship-to
parties since they can be received for either partner type. The inbound order processing should determine
the correct Xx material number according to the information stored for the ship-to, if the master data
indicates it has material information records stored for it, or by the sold-to or if not found.

3.1.2 Type of Custom Development

{All: Indicate if this is a User Exit, Screen Modification, Workflow, Custom Transaction, Portal, EDI, BW,
Security, Conversions, Operational Reporting or any other customization to be developed. For reports indicate
if this is an Operational Report or an Analytical Report and why the decision was made for one or another}
Type : EDI Development involving Orders IDOC, the development team will need to extend the standard IDoc
to incorporate new fields and mapping as detailed in the mapping document in the later sections.

3.1.3 Overview Diagram

{All: Insert a diagram giving a conceptual overview of the custom development design (interface model,
conversion model, form layout, report layout, etc. The diagram should display at high level the data sources,
data destinations, and the systems involved. Processing blocks should be at high level as well as detailed
enough to express how the requirements listed at section 3.1.3 are fulfilled.}

Working Copy as of
-7 -
 Custom Development Request

Purchase Order process Flow

PO: VAN
Customer
Positional Data SFTP GENTRAN
850 ANSIx12
xml
HTTPS
xcbl MODEM

Connect
Genesis

Lotus Notes

GISO SAP

GIS SAP/Parts
SAP

3.1.4 External Systems, Files, Other Infrastructure

{All: List the systems (external to SAP R/3, APO, BW, CRM, etc), any intermediate files and data formats that
will be part of this custom development. Provide a brief description of the type of systems / files (e.g. an
intermediate Excel spreadsheet file). Provide a description of any other infrastructure needs that must be
fulfilled to meet the requirements of this development.}
Connect Genesis – GIS & XX PARTS
Lotus Notes – GIS, XX PARTS, FINDMRO

3.1.5 Frequency
{All: Describe how often this custom development will run or be used. Indicate whether or not frequency is real
time, batch, near real time or on demand. Indicate if this is a real-time or batch program, Operational Report,
Analytical Report, interface, etc. Indicate the time of day it would normally be run. If this is a batch run, indicate
if the user needs to request it, or whether it will be part of a scheduled run overnight. For real time interfaces,
specify the technical / business events that will trigger the interface to run. For all other interfaces than real
time this information should be provided.}
Daily ad-hoc

3.1.6 Security
{All: If this is a new Custom Transaction, or Custom Workflow describe the security requirements in terms of
level of information and sensitivity. For Portal Custom Development, Analytical Reporting and Operational
Reporting, provide a list or roles that will have iView access. For all other custom development, describe any
impact that implementing the requirements could have on authorizing access to data. If this is an automated
transaction or interface, then indicate security development necessary for system access. Describe any
encryption/decryption solutions already existent or recommended for developing the requirements}
Working Copy as of
-8 -
 Custom Development Request

Security authorization profile should include ability to create/change Sales order, document flow, view and
process orders IDoc etc,.

3.1.7 Data Volume and Performance

{Describe the expected volume of data that will be processed by this custom development. Establish
requirements for response times and performance. Detail business and technical constraints with regard to
data volume and performance. In addition below are specific recommendations per custom development type:

EDI: Provide details about the number of EDI transactions to be processed, by transaction type and major EDI
partner / business area. Detail benchmarks in the current systems for similar processing.
On the current system, approximately 1200, 850s are processed daily.
Interfaces: Provide current statistics and expected performance results for processing interface data.
Measurements should be in records per unit of time and / or KB per unit of time. Refer back to section 3.1.5
Frequency to determine if there are any constraints imposed by overlapping.
Conversions: Complete this section for Custom Conversions only. Provide an estimate of the overall volume
of data to be extracted across business units / processes. Provide an estimate of the overall volume of data to
be loaded in SAP across business units / processes.
Operational Reporting: Provide details about expected volume of data to be extracted and displayed.
Estimate a typical run and expected maximum / minimum number of pages. Refer to section 4.4.3 Selection
Criteria to understand how selections will impact the output.}

3.1.8 Dependencies / Touch-points

{Describe any dependencies that this enhancement will have upon other processes, systems, business events,
etc.}

3.1.8.1 Process Dependencies

{Document here all dependencies on process activities that need to happen for the custom development to run.
Specification of process dependencies translate into technical requirements referring to checking of statuses,
flags, conditions, events, etc. In all cases document if the dependency should be resolved through error
processing or automatically. Process dependencies are a dynamic component of implementing technical
requirements. In addition, below are specific recommendations per custom development type:

Portal: Document at high level the processes and the corresponding applications used in iViews. Provide high
level details about how these applications will interact and what are the expectations from the Portal
application. For example alerts displayed on a Portal iView may depend on timely running of reports and
availability of specific business data on report layouts.
EDI: Document at high level all the process prerequisites and post-requisite to an EDI transactions. For
example an 850 PO to a vendor may depend on forecast, stock availability and already reserved inventory.
Document if the dependency should be resolved through error processing or automatically.
• All PO approvals will be obtained at the requisition level, and move to central Purchasing when
subject to release.
• New functionality related to Auto-release of PO by business rule need to be implemented.
• Purchase requisitions will be generated by APO or MRP for stock or backordered material. A 3rd
Party Sales Order that has been entered by a CSA will also generate requisitions. Other
requisitions can be created either manually or via a CSA sales order vendor to Branch (sales
order stock). Before a requisition is converted to a purchase order for a supplier it may be subject
to review/release based on established criteria.
The system will convert released requisitions meeting the following requirements:
• Must be able to differentiate requisition origin
• For 3rd party direct, one requisition to one PO is standard (many requisitions
to one PO per shipping address is non-standard SAP and will not be required)
Ensure that a requisition conversion job completes before a job with the same variables is started.
Working Copy as of
-9 -
 Custom Development Request

Prevent access to convert requisitions to purchase orders unless specifically authorized.

Assumption: No field employees will have access to ME59N including conversion of requisitions to STOs.

• Note: Determine include/exclude faulty and conversion schedules during realization.

Interfaces: Document at high level all the process prerequisite and post-requisite to an Interface. For example
a pricing interface may require prices to be approved before they are taken into the destination system. Similar
requisitions must be approved before being turned in to a B2B vendor.
Conversions: Document if the custom conversion is dependent on previous loads. There may be manual
activities that must be carried out before a conversion is run. For example closing of balances in the legacy
system might be required before we load GL accounts in SAP.
Security: Document here all the manual / automated procedures that are required to assign / deny the custom
role / custom authorization being developed. For example a custom authorization associated with an AR report
may be assigned only if there is a certain type of approval.
User Exits: Document here all the active processes that may be impacted by the exit. Provide high level detail
about how the dependency should be resolved. For example a user exit for work orders may be used in both
PP and PM.
Screen Exits/Custom Transactions: Screen exits may be activated depending on certain process activities.
For example a customer order entry screen exit may be prompted to the user only if the customer has been
previously pre-approved or has responded in a specific way to a marketing campaign. Custom transaction may
behave differently, depending on flags, statuses, events that mark the end or start of processes. For example a
WEB based transaction that allows employees to purchase office supplies, may not be allowed to run if a
catalogue update is in process.
Workflow: Provide high level details about the conditions that may start a workflow. Describe at high level the
interaction between processes and how this interaction is resolved through workflow. For example, for turn in
products a customer order may trigger an approval process from a Sales Representative. The Sales
Representative may schedule the quantities over a chosen period of time. This process could trigger a
Purchasing process where a Purchasing agent will use B2B transactions to find the supplier with the best deal
and availability.
Operational Reporting: Meaningful operational reporting depends on proper sequencing of processes.
Specify here the processes and conditions that need to be met for information to be displayed on a list. For
example a custom back order report may group separately the orders that wait on customer specifications.}

3.1.8.2 Functional Dependencies

{Document here all dependencies on functional activities. List the expected functional activities to be performed
in support of the custom development. Functional dependencies are generally a static component of
implementing technical requirements. In addition, below are specific recommendations per custom
development type:

Portal: Detail at high level any specific Portal configuration needed to meet the business requirements.
EDI: Provide high level details about what partner profiles / output determination should be configured as a
prerequisite to a successful EDI transaction. Describe any specific conditions that may be required for
particular profiles by EDI transaction. Describe any other configuration dependencies if known or expected. For
example a customer may need a fax for validation of order data in addition to the EDI order confirmation
transaction.
• The description field should be put into text and not in the actual description field
• The EDI delivery block needs to be put on the order if one or more materials cannot be
confirmed, and none of the GATP locations plan the material (MARC-DISMM = ZD or ND). This
will require a user exit and will be accomplished in another specification.
• The sold-to partner should be found during IDOC processing from the ship-to partner sent to SAP
and will override the ship-to identifier found on the IDOC header record. If a sold-to partner is sent on
the inbound order, that sold-to identifier will be used instead.

Working Copy as of
- 10 -
 Custom Development Request

Interfaces, Workflow: Describe any configuration dependencies if known or expected. Describe at high level
how the interface should act on each dependency. For example an order interface or a workflow may produce
different results for different order types.
Conversions: Describe at high level all the configuration dependencies that are required for data to be
converted correctly. For example customer master data load may need correct account groups and
reconciliation accounts to successfully run. Describe any other functional dependencies known in the legacy
systems.
Security: Provide high level details about the configuration items needed to create roles / authorizations. For
example order types, purchasing groups must be established first before custom roles can be designed and
created.
User Exits: Provide high level details about what configuration will impact the functionality of a user exit /
BADI. For example when delivering an order, depending on the order type certain promotional activities could
be included.
Screen Exits/Custom Transactions: Document at high level the conditions and behaviour of custom screens
when they depend on configuration. For example a custom screen may have fields hidden if the order type has
a certain value.

3.1.8.3 Data Dependencies

{Document here all known dependencies on master, transaction data and data formatting. Data dependencies
are a dynamic component of implementing technical requirements}

Portal: Detail at high level master and transaction data that may influence the behaviour of portal
development.
EDI: Data on EDI inbound and outbound transactions may influence the behaviour. For example qualifiers may
be used to implement specific business requirements.
• SAP standard pricing can be overridden for all inbound orders except for those with a customer
purchase order type code of “ZZED”, “ZZEE”, and “ZZEV”. A “ZMNS” condition record will be used to
specify the pricing override.
• If the shipping address is sent for the ship-to partner, overlay the original.
Interfaces: Master data may influence the selection criteria when running an interface. For example the
presence of bank data on the vendor master as well as a proper payment method may allow an interface to
export payment transactions data to a bank for electronic payments. Transaction data may influence an
interface through its nature and format. Promotional items described earlier may be awarded based on the
order value or order quantities. Promotional codes entered in a Web application may also be used to determine
the behaviour of an order entry interface.
Conversions: The format of a G/L account in a legacy system may determine how the custom conversion
program will create G/L accounts in the new system.
User Exits: User exits may read transaction or master data do determine flow of processing.
Screen Exits/Custom Transactions: An online custom transaction creating an order has dependencies on
pricing conditions valid at the time of entry.
Workflow: Master data may influence workflow processing. Vendors may be assigned to purchasing groups
that do not trigger workflow any further}

3.1.8.4 Technical / Tool Dependencies

{Portal, EDI, Interfaces, Conversions, User Exits, Screen Exits/Custom Transactions, Workflow,
Operational Reporting: Document dependencies on tools like BackOffice, Role Manager, Infopac, Test
Director, LSMW, mail packages, workflow packages, document management packages, archiving solutions,
B2B solutions, B2C solutions,…etc}
Gentran mapping tool, SAP XI development toolkit, Internet sales modules/features, GXS supplier testing
vendor.

Working Copy as of
- 11 -
 Custom Development Request

3.1.9 Planned Development Items

{Portal, EDI, Interfaces, Conversions, User Exits, Screen Exits/Custom Transactions, Workflow,
Operational Reporting: To the extent of available knowledge, document the names of known development
(enhancements, transactions, forms, maps, etc) that are envisaged to be used in technical development. This
section will be used by the application development team to further investigate the tools and baseline
components as described in 3.1.0 Baseline Reference}
The Development team will be filling up this section with all the associated development objects,
enhancements or programs that will be developed to support the EDI team. We can add our part of maps,
pre/post processor logic, flows, scripts etc.

Standard / Custom Name and Description

Development Item
IDOC Map EDI 850 Inbound map for customers
Custom IDOC development Enhancement of the Standard EDI 850 IDoc
Functional module/ABAP IDoc processing module
program
Partner profile EDI Customers
Inbound Order flow Inbound Gentran flow and preprocessor
XCBL 3.5 map Customer order map in XML

3.1.10 EDI Message Versions / Messaging Formats and Standards / XML

{EDI, XML: Provide details about the EDI message used, its version and any known compatibility issues. If
applicable provide details about any other known messaging formats, XML standards used, etc.}
X12 ORDERS version 2001
IDOC: ORDERS05, MESSAGE: ORDERS, PROCESS CODE: ORDE

3.1.11 Comments
{Portal, EDI, Interfaces, Conversions, User Exits, Custom Transactions, Workflow, Operational
Reporting: Provide any additional comments regarding the custom development. Collect here all the details
that may not be categorized in the sections above.}

3.2 Screens (Custom Transactions, Screen Exits and Portal)

3.2.1 Screen Flow Overview / iView Flow Overview
{Screen Exits/Custom Transactions, iViews: If this custom development involves a user dialogue, insert a
diagram giving an overview of the screen flow. The screen flow should be presented as a Visio diagram that
shows how data moves between screens and how commands transfer the user interface from one screen to
another. For example when pressing the “Shopping Cart” button on a web screen, the application prompts with
a new web page that presents all order lines. When entering a work order, the Tools button/tab brings a screen
that allows entering of details about tools used for the work.}

3.2.2 Screen Details – Screen 1 / iView Details

{Screen Exits/Custom Transactions, iViews: For each screen that needs to be modified or created, enter the
screen layout, field lists, validation rules and push-buttons/pull-down menus required. Details for each screen
should be grouped together. For example if there are two screens, section 3.2.2… would be for the first
screen, Section 3.2.3… for the second screen. In a similar fashion proceed with sub-screens and screen tabs.
For example the payment data section of a customer entry screen may have two tabs, one for banking data
and another for credit card data. Both tabs should be listed.}
Working Copy as of
- 12 -
 Custom Development Request

Screen Layout / IView Layout

{Screen Exits/Custom Transactions, iViews: If there are to be changes to an existing screen or new screens
created, enter the layout in this section. If the screen layouts have been saved as a separate file, then specify
the file location here.}

Screen Fields / iView Fields

{Screen Exits/Custom Transactions, iViews: List the required screen fields that will be modified or created in
the table below.}

Field Title Type Size Characteristics SAP Source Field

{Customer Name} {C} {30} {M} {KNA1-NAME1}

Legend Type: A Alpha only, N Numeric, C Alphanumeric, X Check box, R Radio Button, D Date
Legend Characteristics: M Mandatory, O Optional, D Display only

Field Validation / Protection

{Screen Exits/Custom Transactions: Indicate any special field validations required for the screen fields listed
above. For example on an order entry transaction quantities may be validated against availability and the
requested delivery date. Fields that are passwords, credit cards, social security numbers, etc should be
protected. Indicate here if this is necessary and what are the expectations for filed encryption / protection.}

Group Validation
{Screen Exits/Custom Transactions: Indicate any group validations that would be done for any groups of
screen fields listed above. For example on a custom transaction that creates a vendor, credit card information
would be validated together with the name and address to ensure that future payments would be accepted.}

Push Button / Menu Option / Other Screen Controls

{Screen Exits/Custom Transactions: List the new push buttons, function keys or menu options that need to
be created. If known, present at high level the controls that are expected and their business function within the
custom development. For example, while shopping on a website, the customer has always the option to press
the shopping cart button and view the total of his/her purchases. After the order is complete, the user presses
the “Save” button to confirm the order and is prompted with an order confirmation screen that he may further
print by using a “Print” button.}

Help Functions / Links

{Screen Exits/Custom Transactions, iViews: Present at high level what help functions should be available
for any of the fields specified above or collectively at the screen level. Detail at high level what are the
expectations in regards to producing the help content. Provide any known links or indicate how the link
information could be obtained to meet the requirements for the custom development. For example when
entering an order on a web site, after the product is selected, the custom application displays a link to
information about the product. If the customer is not sure about the product code, by pressing a “help button”,
the application prompts with s selection screen where products or product categories may be selected.}

Search Functions
{Screen Exits/Custom Transactions, iViews: Present at high level what search functions should be available
for any of the fields specified above or collectively at the screen or transaction level. Detail at high level any
knowledge management requirements and expectations regarding search engines, indexing, response time,
Working Copy as of
- 13 -
 Custom Development Request

presentation formats, etc. Explain if Portal search functions are to be used in conjunction with help functions
presented at the previous section.}

3.3 Workflow (Workflow Requirements)

3.3.1 Work Flow Overview
{Please give a brief overview of functionality required. Provide an assessment of the gaps between existent
standard SAP workflows and the custom development requirements. For example if a custom workflow is
required for purchase requisitions and authorizations, analyse the gaps between the existent SAP functionality
and the new requirements}}

3.3.2 Work Flow Route

{Where is the workflow going to? Please give a detailed description of the routing laying out each level with
examples if necessary. Provide details about roles, agents, organizations, delegation and activities to be
performed at each level}

3.3.3 Work Flow Route Exceptions

{What are the exceptions to the above routing? Document error processing and escalation at each step in the
workflow. If modifying a standard workflow, provide details about existent functionality and how it should be
changed to meet the new requirements.}

3.3.4 User Action/Notification

{Does this work flow require any user action, for example: approving a request, releasing a flag, etc, or
notification, for example, SAP office email message or Internet eMail message}

3.3.5 Work Flow Criteria

{Are there instances when the work flow should not be initiated? For example, work flow only initiates for
product xxx; work flow is only initiated for certain employees?}

3.3.6 Transaction Codes

{Please list all transaction codes that apply to the work flow. Provide detail about how they will integrate with
the workflow process. Fill in if known else complete during Implementation Phase}

3.3.7 Relevant Documents

{Please list all relevant BPP’s that apply to the work flow. Fill in if known else complete during Implementation
Phase}

3.4 Analytical Reporting (BW/BI Requirements)

3.4.1 General Report Information
Please select from the following:
New Report: List any Standard Business Content that exists for this report.
Title: _________________________________________________
Technical Name: ________________________________________
Current Xx Report: Are these requirements based on an existing report?
Title: _________________________________________________
Technical Name: ________________________________________

Report Name: <enter a suggested Business name>

Working Copy as of
- 14 -
 Custom Development Request

How often is this report run?

Real-time (Source system) Daily Weekly Bi-Weekly Monthly Quarterly Yearly
Other (Please Specify) ______________________________________________________________________

Report Medium: how do you want users to see/access your report.

On-line (Source system) Internet/Intranet Hard copy E-mail Text File Excel File
Other: ___________________________________________________________________________________

Report Volume: How many lines, on an average, are on the report? ___________________________________

3.4.2 Type/Number of Users

{What type of users and how many in each type expected?}
User Type This user will predominantly …
Executive ... view predefined and static reports. KPIs and Dashboards.

InfoConsumer ... navigate within reports, do slicing and dicing at a summary level.

Power User ... developers of reports and queries, OLAP analysis, Planning and simulation, data mining, etc.

Number of Number of

Internal Users External Users

Executives ________ Customer: _______

InfoConsumers ________ Supplier: _______
Power Users ________ Legal: _______
Other (Please Specify) ______________________________________________________________________

3.4.3 Report Properties

{Examples of report properties are shown below. You may include more as needed}
Report Properties Property Description
Report type (i.e. Tabular, bar graph, pie chart, combined …)
Report composition: (i.e. list, comparison …)
Alignment (current or historical)
Time Frame needed (Current and Prior year, 12 rolling months …)
Decimal places (0.0, 0.00 …)
Percentages (Format) (0.0%, 0.00% …)
Unit of measure required (lb., inches …)
Scaling (i.e. figures shown in thousands …)
Currency type required ($, CAN$ …)
Alerts needed (Only send report if sales < $10,000 …)
Variant (needed to run report in source system)

Working Copy as of
- 15 -
 Custom Development Request

3.4.4 Report / Sources of Data

{Provide this information if available. Please note: **“Source” in this section indicates the original location or creation
place of the data, i.e., R/3, CRM, APO, WM, External, etc..}

Source System SAP Functional Area SAP Tables

3.4.5 Filters (Characteristics)

{List here characteristics that are used as report filters only. It is not available in the columns, rows, or for drilldown.
However, such characteristics can be used to limit the data appearing in a report on a global basis. For instance, if you
want to see data for a single company code and only want the company code to appear in the header, you could
identify it as a filter and limit the output to the company code you choose.}
Technical Name of
Individual values, intervals,
Characteristics that Characteristic Object Source Data Source
hierarchy nodes or variables that
are used as a filter Description Technical Names Technical Names
the report will be limited to
only (BW)

3.4.6 Selection Criteria

{Report Prompts at run time, include a sample / prototype if possible}
Technical Object Mandatory (M) or
Prompt Description Range (R) or Value (V)
Name (BW) Optional (O)

3.4.7 Columns / Key Figures

{Please put in order needed on report: Columns from left to right. Add lines as needed. Key figures are numeric values.
They can stand alone, be summed or used as a value in another calculation. Often, they are accompanied by a
currency or unit of measure (e.g. gross sales, committed quantity, net postings, etc.}
Technical
Seq Column Object Source Data Source Calculation or Format
Column Name
Num Description Technical Names Technical Names restriction required? (D4.2, A24..)
(BW)
1
2

3.4.8 Calculations / Formulas (Columns)

{Sequence number is based on above columns as well. For example, you may want to have a calculation placed to the
right of a column listed above. The column listed above is number 4. The sequence number in this section would have
a 5 in it}
Seq
Calculated Field Description Required Calculation and Source Fields Format (D4.2, A24..)
Num
1

3.4.9 Rows / Master Data / Characteristics

{Please explain sequence needed on report layout: Rows from top to bottom. Add lines as needed. Characteristics are
business dimensions and are often considered master data. Some examples of characteristics are cost centers,
accounts, material groups, company codes, plants, order types, etc. A “Key” is information such as a customer number
Working Copy as of
- 16 -
 Custom Development Request

(0808907703) that uniquely identifies an entry in a table. A “Description” describes the “Key”, a name such as
“American Airlines”. If both “Key” and “Description” (0808907703 American Airlines) were selected, you would be able
to sort on both the elements on the report, i.e., by name and then by customer number.}
Attribute
Key &
Limit to: Technical
Seq Row Data Source Description,
Object Source specific value Name
Nu Technical Row Description Technical Key Only, or
Technical Names or variable Navigation
m Name (BW) Names Description
option (N) / Display
Only
(D)
1
2

3.4.10 “Drill Down” Levels (Free Characteristics)

{If a characteristic is defined as a drilldown / free characteristic, it will not be displayed in a row or column, but in a
section above the report results area. However, you will be able to have it appear in a row or column by drilling into it.
For instance, if cost center is a characteristic in the row area of the report and cost element is a drilldown / free
characteristic, you will be able to select a single cost center and then drilldown to all the cost elements that make up
that cost center.}
Limit to:
Technical Name of
Key & Description, specific
Characteristics that Characteristic Object Source Data Source
Key Only, or value or
are available for Description Technical Names Technical Names
Description Only variable
drilldown (BW)
option

3.4.11 Report Layout

{Please attach a copy of the layout you want. Make sure to include information described in the above sections. (Rows,
Free Characteristics, Columns, Calculations. Please attach an Excel report sample here.}

3.4.12 Comments
{List any other comments relating to the above information. For example: Current report what to keep, what to remove,
what enhancements are needed, Performance issues or concerns, Issues that might not be apparent at first glance
when developing report, Timing / run considerations, Security concerns, etc.}

3.4.13 Additional Contacts / Subject Matter Experts

Contact Telephone Comment

Working Copy as of
- 17 -
 Custom Development Request

Section 4 Data Requirements and Mapping

{If applicable, this section is to be completed at high level by the Process Teams with assistance form the Application
Development Team}

4.1 Logical Data Elements

{Refer to section 3.1.3 Overview Diagram. Describe by system / enterprise application and at logical level the data
elements that are required for this custom development and their role in the overall data flow.

EDI: For new inbound EDI transactions identify the main data elements / data segments that will be used in the context
of the messaging standard chosen (ANSI X12, EDIFACT, etc.)
850 – Customer Purchase Order
22 Maps, 11 Programs, 358 Partners – Generic Maps. Volume: 12000 / Month
Message type: ORDERS, IDOC Type: ORDERS05, IDOC Extension: None, Process Code: ORDE

Interfaces, Workflow: Provide a high level, logical description of the data elements that will be extracted / used by an
interface or workflow. For example an FI interface may use line item invoice amounts or aggregated total invoice
amount when taking data from an external A/R system to G/L. A custom workflow for purchase requisitions may use
purchasing officer, total requisition amount, expected delivery date as data items to be transmitted at various steps in
the workflow. These data items may be needed as part of the decision process for an approver at a subsequent step in
the workflow.
Conversions: Describe at high level the data elements that will be loaded from a legacy system for a conversion
object. For example a customer master conversion would need, customer name, customer address, customer ship to,
customer contact, etc
Operational Reporting: Describe at logical level the data elements that would be listed in a report.}

4.2 Logical Data Groups / Formats

{Refer to section 3.1.3 Overview Diagram. Describe at logical level how the logical data elements defined previously
are grouped in master data or transaction data objects. Provide details about where these logical groups reside and
how they are maintained.

EDI: For new inbound EDI transactions identify the main groupings of standard chosen (ANSI X12, EDIFACT, etc.) that
will be used in the custom development.
Interfaces, Workflow: Group the data elements identified previously in logical units. For example, invoices, orders,
document header, document line, etc. Identify destination logical groupings where the source data will be mapped to.
For the case of workflow this groupings would translate in specific workflow container requirements.
Conversions: Group the data elements described previously in logical units to be able to map later into master data or
transaction data structures. For example HR master data loads require the load of a specific number of tabs for each
employee, depending on the functionality turned on.
Operational Reports: If possible determine the logical groupings within the system where the data may be located.}

4.2.1 Input Formats

{Table formats, file formats, manual input formats, workflow input formats, EDI inbound transaction formats, etc}

4.2.2 Output Formats

{Form layouts, Report Layout, output file formats, EDI outbound transaction formats, Printing Requirements, Output
Medium Requirements (special paper, stationary) etc}

Working Copy as of
- 18 -
 Custom Development Request

4.3 Logical Data Mapping

{EDI, Interfaces, Workflow, Conversions: Refer to section 3.1.3 Overview Diagram. Using the table below as a
template, provide a conceptual mapping between data elements / groups at various points in the process flow / data
flow. For example a FI interface works in inbound with one common entry called journal entry. The destination formats
are document header and document line. The mapping will be used by the application development team to further
investigate and technically determine the physical mapping when building the technical spec.}
The following enhancements need to be developed within the IDoc by the development team to support the required
functionality ;

The enhancement ID in the following table is a user defined key that references a particular required enhancement to
standard processing.

Enhancement Enhancement Description

ID
MATLSUB A material (SUB_INVALID_MAT) will need to be substituted for any material that
does not either exist in the database, does not have a customer material cross-
reference, is deleted in the database, or is not defined for the associated sales
organization.
CUSTMAT The customer material cross-reference will be stored by sold-to and ship-to. The
table should be searched by ship-to first if the customer attribute 1 flag (KNA1-
KATR1) has been set to a value of “Z1”, then by sold-to in an attempt to find a valid
Client material number.
ROLERES IDOC error role resolution needs to be changed to look at the CSR assigned to the
ship-to (partner ZC) for error notifications in addition to the notification set on the
partner profile records. If multiple ZC partners, a notification should go to all. If the
CSR is not found for the ship-to partner, an attempt is made to find the CSR based
on the sold-to party in the IDOC header.
RELNUM The IDOC needs to be extended to include the release number in addition to 5
customer reference fields that are not currently being used for EDI.
PRICON The EDI subsystem will generate a condition record for the condition ZMNS if the
customer purchase order type is not ZZED, ZZEE, or ZZEV.
DUPPO Validation lookup on the customer purchase order number in combination with the
purchase order release number. This check will be written in a separate
specification since the check should be done at order entry time in addition to EDI
IDOC posting.
ADDRESS Ship-To address information can be sent on the inbound order by the EDI
subsystem. During order posting, the address details will be overlayed with the
address fields provided by EDI but any address information that already existed in
the master data but not provided with a new value by EDI will retain the value from
the master data. A user exit is needed to blank out the address information then
overlay the data provided by the EDI subsystem.
OLDDELDATE If the customer requested delivery date specified on the inbound sales order is less
than the current day, a delivery block will be set with a value of “ZD”.
CONTACT The contact name and telephone number should be recorded in the ship-to
information on the “Additional Data B” screen of the sales order. Gentran will send
the contact information in the ship-to partner record and a user exit is required to
pull that information from the ship-to partner to the information associated with the
sold-to contact information.
CUSTBLOCK For some customers, a master data flag will be set to indicate all inbound orders for
that customer are to be blocked with a delivery block value of “ZR”.
SOLDTO The ship-to identifier should be used to look at the customer partner functions and
Working Copy as of
- 19 -
 Custom Development Request

Enhancement Enhancement Description

ID
determine the correct sold-to party. If more than one sold-to party is found for the
ship-to, the sold-to partner at the header of the IDOC will be used, otherwise, the
found sold-to party will override the header partner id. If a specific sold-to partner is
sent on the inbound order, that sold-to id will be used instead.

Source Logical Data Element Type Length Destination Logical Data Element Type Length
Group Group

4.4 Data Processing Requirements

{EDI, Interfaces, User Exits, Screen Exits/Custom Transactions, Workflow, Conversions, Operational Reports:
Define at high level data processing requirements as specified below}
The Development team will need to perform the following development to support the EDI 850 transaction :
1) Finalize the IDoc mapping fields and the conversion rules
2) Extend/create IDoc to accommodate new enhancements
3) Create message type and port definition
4) Develop/enhance the function module/program to process the IDoc
5) Maintain the partner profile, RFC destination and workflow setup
6) Maintain the userexit to support IDoc processing.

Part of the inbound loading process will require that the system check to see if an existing sales order exists that has
the same customer purchase order and release number. With the exception of the CEMAS (DLA) customer, if this
happens the IDOC should not be loaded as a sales order. Instead, it should error out, and SAP must notify the
appropriate personnel via workflow that a potential duplicate customer order has been received. CEMAS will need
unique release numbers to be generated by SAP, because they always send the same contract number. The actual
checking of the possible order number duplication will be specified in a separate specification
4.4.1 Sorting / Merging / Grouping Requirements
{Document at high level how data should be sorted, grouped or merged. For example grouping is required if an FI
interface takes GL Journals and post them into the destination system as document header and document line. The
interface would need to know how to group many journal entry lines to one document header in the destination system}

4.4.2 Calculation / Formulas / Summarization

{Describe any calculations that need to be performed to input / output the data. Provide detail about the conditions
under which calculations will be triggered.}
• Customer material information records can be stored by either sold-to or ship-to. The field to check if
the sold-to has the info records is “KNA1-KATR1” (customer attribute 1) with a value of “Z1”.
• Delivery block value for normal suspended orders (Any time you have an item that is not cross-
referenced) = ZE
• Delivery block value for orders where the customer master flag (KNVV-KVGR3) is set to a value of
“02” for the ship-to, or if the ship-to is blank, the sold-to partner = ZR
• Delivery block value for orders where the requested delivery date is earlier that the current date = ZD
Working Copy as of
- 20 -
 Custom Development Request

• Pricing Condition = EDI1 (Unit Price)

• ZMNS (Price Override)
Note: ZMNS is valid for all but ZZED, ZZEE and ZZEV
• VBAK-AUART (Sales Document Type) = ZOR (Standard Order)
Blanket orders to be reported with the same report as the 860 change order
• VBKD-BSARK (Purchase Order Type) = ZZEA (Ariba)
ZZEC (Commerce One)
ZZED (EDI)
ZZEE (Other E-Commerce)
ZZEG (ICG)
ZZEI (I-Procure)
ZZES (SiteStuff)
ZZET (TPN Register)
ZZEV (EDI Event Driven)
ZZEW (Web Order)
• VBKD-ZZRELEASE_NUM (See spec 3800) = Customer Release Number
• VBAK-ZZCUST_REF1 = Additional Customer PO Number
• VBAK-ZZCUST_REF2 = Not used but extend idoc for future use
• VBAK-ZZCUST_REF3 = Not used but extend idoc for future use
• VBAK-ZZCUST_REF4 = Not used but extend idoc for future use
• VBAK-ZZCUST_REF5 = Not used but extend idoc for future use
• Use text id ZEHC (header) and ZEIC (item) for any data not handled by R/3 that we are currently
loading to fields on the mainframe but will have to load to text in R/3.

4.4.3 Selection Criteria

{If applicable, describe in the table below the selection items that will be used when running the custom development.
Provide a brief description of criteria validation if needed for each of the selection items. For example the customer
number supplied on the selection screen could be validated against the customer master}
Field Title Type Size Mandatory Wild Range Source Criteria Validation
Field Name
Cards? Required?
{Customer Name} {C} {30} {Y} {Y} {N} {KNA1-
NAME1}

Working Copy as of
- 21 -
 Custom Development Request

Legend Type: A Alpha only, N Numeric, C Alphanumeric, X Checkbox, R Radio Button, D Date

4.4.4 Variants
{Are any Variants required for the report? If so, what are they? The variants should reflect various scenarios and
business rules outlined in section 3.1. For example an interface might behave differently according to the order type
supplied in the selection criteria. Document the variants sufficiently to allow for the successful creation of test cases.
Unless otherwise specified the variants should comprehensively cover all the business / process requirements. When
describing variants, refer back to selection criteria specified in section 3.10}

4.4.5 Highlighting and Special Formatting / Help Functions

{Describe any fields/text/rows that will need highlighting or other special formatting. For example string fields might
need special formatting when processed in a User Exit. Screen fields in a Custom Transaction or Screen Exit may
need special formatting when displayed. Document here any need for drop down search helps and if Custom “Search
Help”’s should be created.}

Working Copy as of
- 22 -
 Custom Development Request

Section 5 Technical Specification

{This section is to be completed by the Application Development team. There may be more than one program or
development item per technical specification. Where multiple development items are needed please indicate
specifications fore each item separately as indicated in the example below:
Component 1: User Exit Enhancement
Component 2: Custom Validation Table
Component 3: Report
All technical specifications and coding design must adhere to Xx Development Standards and Guidelines. Please see
these separate guideline documents for specific coding, instructions and procedures}

5.0 Baseline Reference

{All: Refer to section 3.1.0 Base Line Reference that lists at high level standard delivered functionality. Describe in
detail how standard delivered software components or existent (legacy or otherwise) custom application development
will be used in the technical design}

Development Items Technical Identification

{All: List here the technical names, brief descriptions and system platforms of both custom development and standard
components to be used in the technical design. Refer to section 3.1.9 Planned Development Items Update the
category column to be Custom (for existent custom development), Standard (for existent standard components), and
New (for development specified in this document)

A suggested list of development items types is as follows: SAP Screen, Report, Form, Table, User Exit, Screen Exit,
BADI, Business Object, BAPI, BDC, BI, ALE, IDOC, Security Role, xApp, iView, Search Help, Function Module,
Classes, Interfaces, Package, Workflow, Archive, Batch Program, Job, JCL, Schedule, Map, Variant, etc. Please refer
to corresponding Programming Standards for Legacy, SAP, Middleware, EDI, XML or other as appropriate. Fill in the
contact details with names of staff that work on / administer the objects. Update this table as the development of the
technical spec is progressing}

Development Development Item Name and Category(Custom, System / Contacts

Item Type Description Standard, New) Platform
IDOC Map EDI 850 Inbound map for customers Custom Gentran Cathy Ekstrom
Custom IDOC Enhancement of the Standard EDI 850 Custom Development Dave Mack
development IDoc team/SAP
Functional IDoc processing module Custom Development Dave Mack
module/ABAP team/SAP
program
Partner profile EDI Customers Standard SAP Cathy Ekstrom
Inbound Order Inbound Gentran flow and preprocessor New Gentran Bob Farr
flow
XCBL 3.5 map Customer order map in XML New Gentran Ryan Paradiso
Etc…

5.2 Dependencies / Touch Points

{All: Describe in technical terms any dependencies that this custom development will have on other processes,
systems, business events, etc, for all items outline in section 3.1.9 Planned Development Items If new dependencies
are identified or existent documented dependencies are not applicable, mark that in your narrative accordingly.}
Working Copy as of
- 23 -
 Custom Development Request

The EDI team will depend on the Development team to provide the formats, field layout and any
Technical/Configuration tasks associated with SAP system to EDI enable the 850 transaction. The EDI team will also
have to work with the Security team to gain appropriate access to display/execute Sales order and Order related
transaction required during the development and testing of the transaction. This will be in additional to the common IDoc
processing and display access that the EDI team will have.

5.2.1 Process Dependencies

{By business process, event, specify in technical terms the objects (statuses, flags, events, triggers, other data)
that will be used to resolve the dependency. If applicable, technically outline the logic that will resolve the
process dependency and the expected outcome}

Process / Event: <…>

{By business process,/ event describe technically using pseudo-code the required logic for resolving the
dependency}
• Create entries to convert external partner numbers to internal partners using transaction VOE4.
• Create entries to assign the correct sales organization data to a customer (sales organization,
distribution channel, division, and default order type) using transaction VOE2. If only one
organization will be used or the EDI translator will provide the organization, this table is not
necessary.
• Create customer material information records for all materials that will be received in EDI
documents as customer material numbers using transaction VD51. This will allow the conversion
of customer material numbers to Client material numbers.
• Inclusion of the EDI1 and EDI2 conditions for pricing procedures used for inbound customer orders.
This will allow the customer expected price to be stored and value to be stored.

5.2.2 Functional Dependencies

{For each configuration item / functional area identified as a dependency, describe technically the standard or
baseline objects that will be used to resolve the dependency. If applicable technically describe the logic that
represents the dependency.}

Configuration Object / Functional Area: <…>

{By each configuration Object / Functional Area describe technically using pseudo-code, the required logic for
resolving the dependency}
From the EDI team standpoint the Orders IDoc and the corresponding message type will be the object the
team will use to resolve any overlapping functionality with other teams, processes etc. Also if some other
process requires to use this IDoc and message type, the EDI team needs to be informed and involved in
meetings to understand the impact of the enhancement/changes to the IDoc and message type. The
development team also needs to stay in loop with any involvement of the IDOC and message type usage.

5.2.3 Data Dependencies

{For each data dependency, describe in technical detail the master data, transaction data, other data
formatting, data coding conventions etc, that will be used to resolve the dependency. If applicable technically
describe the logic that will be used.}

Master Data / Transaction Data: <…>

{By each data object identified, describe technically using pseudo-code, the required logic for resolving the
dependency}
The ABAP program/Function module developed should incorporate the following data validation and
conversion rules :

Working Copy as of
- 24 -
 Custom Development Request

• Customer material information records can be stored by either sold-to or ship-to. The field to check if
the sold-to has the info records is “KNA1-KATR1” (customer attribute 1) with a value of “Z1”.
• Delivery block value for normal suspended orders (Any time you have an item that is not cross-
referenced) = ZE
• ZMNS (Price Override)
Note: ZMNS is valid for all but ZZED, ZZEE and ZZEV
• VBAK-AUART (Sales Document Type) = ZOR (Standard Order)
Blanket orders to be reported with the same report as the 860 change order
• VBKD-BSARK (Purchase Order Type) = ZZEA (Ariba)
ZZEC (Commerce One)
ZZED (EDI)
ZZEE (Other E-Commerce)
ZZEG (ICG)
ZZEI (I-Procure)
ZZES (SiteStuff)
ZZET (TPN Register)
ZZEV (EDI Event Driven)
ZZEW (Web Order)
• VBKD-ZZRELEASE_NUM (See spec 3800) = Customer Release Number
• VBAK-ZZCUST_REF1 = Additional Customer PO Number
• VBAK-ZZCUST_REF2 = Not used but extend idoc for future use
• VBAK-ZZCUST_REF3 = Not used but extend idoc for future use
• VBAK-ZZCUST_REF4 = Not used but extend idoc for future use
• VBAK-ZZCUST_REF5 = Not used but extend idoc for future use
• Use text id ZEHC (header) and ZEIC (item) for any data not handled by R/3 that we are currently
loading to fields on the mainframe but will have to load to text in R/3.
• TDID (Text ids for header and detail) = Text ID Matrix
• Delivery block value for orders where the customer master flag (KNVV-KVGR3) is set to a value of
“02” for the ship-to, or if the ship-to is blank, the sold-to partner = ZR
• Delivery block value for orders where the requested delivery date is earlier that the current date = ZD
• Pricing Condition = EDI1 (Unit Price)

5.3 Development Integration / Technical Diagram / Data Model

{All: Provide a logical diagram that details technically how each developed component works. If multiple components,
provide an overall diagram that details how components will work together and how data will flow. Provide narrative
that refers to section 3.1.3 Overview Diagram. Diagrams may be built in Visio and attached as links to this document.
If applicable describe inheritance, interfaces and classes and how methods interact with each other.}

Working Copy as of
- 25 -
 Custom Development Request

Development team may provide a diagram if applicable.

5.4 Logic Flow / Processing Required / Update Logic

{EDI, Interfaces, User Exits, Screen Exits/Custom Transactions, Workflow, Conversions, Operational Reports:
Using the sections below describe, in pseudo-code, all the components that are part of the technical design. Use
corresponding application development standards when naming the components Update the table is section 5.1 with
the names and brief details of new created objects.}
The standard IDOC processing will occur and a section of code will be executed to process the E1EDK02 IDOC
segment records. A user exit will be called at that point and program logic will be inserted to process the release
number and customer reference qualifiers in the EXIT_SAPLVEDA_001 user exit to save the qualifier information. This
information will be used in the EXIT_SAPLVEDA_003 user exit to populate the fields on the “Additional data B” screen
of the sales order processing screen.
If we have a release number from the inbound IDOC, execute the customcode to put the data on the
additional data B screen.
Look at the last line in the BDC table that is being built to store
the inbound order to determine if all of the screens have been
processed and the order is about to be stored. If the save button is
being pressed, insert a call to the additional data B screen and fill
in the customer release number and customer release date.
After that Only process the line items that do not have additional information
segments in the IDOC data. There should never be additional information records in the current
configuration.
1) If the material number and customer material number are not
supplied, it is an invalid material.
2) If the material number is not supplied and the customer material
number is not in the material information records for either the
sold-to or ship-to partner, it is an invalid material.
* Check the customer master record for the ship-to to see if it
* should be used to determine the Client material number from the
* supplied customer material number
A new task, ZORDERS_Err (TS90000006) was created to link to the new role resolution procedure for use
in CSR notification. It was copied from the existing task assigned to the inbound order errors, TS00008046.
The standard role definition attached was modified to the new role defined for the role resolution function
module, 90000001.

A new standard role definition, zedi_process (90000001) was created and linked to the function module
created for the CSR notification.

The new task was linked to the object type and event for the inbound order error processing and activated
(Object: IDOCORDERS, Event: INPUTERROROCCURRED). The standard task delivered in the system,
TS00008046, was deactivated.

5.4.1 Data Extraction

{Refer to sections 4.2.1 Input Formats, 5.7 Data Layouts / Data Mapping and 4.4.3 Selection Criteria.
Provide a technical description of the methods used to extract the information. If SQL will be used to
extract the data, describe the tables where the information is stored and the key relationships. Provide
pseudo-code for the SQL statement. If another software component is used to extract the data then
ensure that is listed in the table at section 5.1 Development Items Technical Identification Use
pseudo-code to describe how the software component will be called and how the information will be
retrieved.} OLDDELDATE
Following are some hints to the development team to extract data from the various data source when
filling up an IDoc structure , which may prove useful :

Working Copy as of
- 26 -
 Custom Development Request

The customer requested delivery date is retrieved from the IDOC header date segment, E1EDK03, when the
date qualifier indicated it was the customer requested delivery date (“002”). The date is then compared with
the current system date and if it is less, a delivery block is set in the document header with a value of “ZD”.

CONTACT
The contact name and phone number will be sent by the EDI subsystem in the E1EDKA1 ship-to partner
segment in the BNAME and TELF1 fields. The user exit will read the contact information and move that into
the contact information for the sold-to of the sales order “Additional Data B” screen.

CUSTBLOCK
Select the master data sales information for the ship-to party.
If the customer group 3 (KNVV-KVGR3) field contains a value of “02” meaning to block all inbound EDI orders,
a delivery block should be set.
If the customer group 3 field does not contain a block value, select the master data sales information for the
sold-to party.
If the customer group 3 (KNVV-KVGR3) field of the sold-to contains a value of “02” meaning to block all
inbound EDI orders, a delivery block should be set.

SOLDTO
Use the ship-to identifier to read the KNVP customer partner table where the partner id is the ship-to identifier
and the partner function is “ship-to” for the sales area sent on the order.
If more than one entry is found, do not override the sold-to partner identifier.
If only one entry is found, override the sold-to partner identifier with the sold-to identifier found in the partner
table.
Note: Default partner processing of the sold-to will cause the sold-to to override the above processing as long
as the sold-to partner record occurs after the ship-to.
the enhancement

5.4.2 Data Transportation / Data Communications / Events

{Data may be transported using middleware, files (through FTP), workflow, messaging, XML, etc. Provide a
technical specification of how data will be moved using the selected transportation method. For middleware
provide a description of the maps, queues, pipes, business processes…etc. For workflow provide a description
of containers, parameters…etc. For FTP specify the scripts. For messages describe the message formats. For
XML, provide the definitions and standards employed. Refer to section 5.7 Data Layouts / Data Mapping}
Customer has to be able to transmit data to Xx via a method that Xx eBusiness Operations (EDI) supports.
• VAN
• HTTPS
• SFTP
• Modem
• FTP

5.4.3 Data Transformation / Data Processing / Methods

{Refer to sections 4.4.1 Sorting Requirements and 4.4.2 Calculation Formulas to technically describe in
pseudo-code how the newly created programming objects will fulfil the requirements. Provide details for any
utilities or standard / existent development components that will be leveraged.}

5.4.4 Data Update / Data Staging

{Provide narrative in pseudo-code about how the updates will occur. List the databases / tables that will be
updated and the specific fields. If new custom tables are created, provide the description of these objects here.
If using standard / existent software components to perform the updates describe how they are used. Update
section 5.1 with software component details.}

5.4.5 Data Security

Working Copy as of
- 27 -
 Custom Development Request

{If applicable, provide details about how data will be encrypted, decrypted and secured. Refer to the
appropriate Application Development Standards or Security Standards. Describe in pseudo-code any needed
logic to be used for this purpose.}

5.4.6 Messaging / IDOC / Workflow Parameters

{EDI, Workflow: Identify various parameters that may be required for the custom application to work. For
example IDOC process codes, IDOC message types, Email parameters, etc.}

5.5 Application Controls

{EDI, Interfaces, User Exits, Screen Exits/Custom Transactions, Workflow, Conversions, Operational Reports:
Through the sections below, describe in pseudo-code and all development components that will be used to provide
audit trail, error recovery, validations and reconciliations}

5.5.1 Audit Trail

{If applicable, provide a description of the audit trail at all points in the flow. Describe in pseudo-code any new
application components that will log the completion of various steps in the process as well as errors. Specify
the tools and procedures by which users will analyse the audit trail. If using standard / existent software
components to perform the audit trail describe how they are used. Update section 5.1 with software component
details}

5.5.2 Validations / Error Handling / Correction and Recovery

{Provide a list of all captured errors and validations that are specific to the new custom development. Provide in
pseudo-code a description of the conditions that are trapped as errors and detail any recovery steps
necessary. Document both automated and manual recovery steps. Describe the notification process.}
Standard IDOC error handling and audit trails will be used

• If a customer material number cannot be resolved into a valid Xx material number or an invalid Xx
material number is sent on an inbound order, the material named SUB_INVALID_MAT should be used in
the Xx material number field and all data regarding the customer supplied material information should be
retained. If the SUB_INVALID_MAT material is used for a line item, the delivery block should be set
to a value of “ZE” (EDI Blocked Order).
• IDOC error messages should be sent to the Customer Service Representatives (CSR) attached to the
ship-to or sold-to partner on an inbound order. CSRs will be assigned to the partners with a partner
function of “Y1” through “Y4”.

5.5.3 Error Notifications

{Describe the notification process. Explain if any reports, email, workflow or messages will be issued to
document the errors. List recipients and roles assigned for resolution. Describe in pseudo-code any new
software components that need to be created for error notifications.}
Workflow should be send to the appropriate positions in the organization structure when errors are
encountered during the IDoc processing.
 If the SUB_INVALID_MAT material is used for a line item, the delivery block should be set to a
value of “ZE” (EDI Blocked Order).
 IDOC error messages should be sent to the Customer Service Representatives (CSR) attached to the
ship-to or sold-to partner on an inbound order. CSRs will be assigned to the partners with a partner
function of “Y1” through “Y4”.

5.5.4 Reconciliation
{If applicable describe the reconciliation process. Describe any existent or new software components used for
reconciliation. Specify the criteria for which reconciliation is considered successful or failure. Specify any
required further steps in the case of reconciliation failure}

Working Copy as of
- 28 -
 Custom Development Request

5.5.5 Segregation of Duties

{If applicable describe in pseudo code the logic used to ensure segregation of duties between roles, users.
Describe the conditions and the actions in each case}

5.6 Comments
{Provide any other technical information that is applicable to this development}.

5.7 Data Layouts / Data Mapping (Interfaces, Conversions, Transactions)

{EDI, Interfaces, User Exits, Screen Exits/Custom Transactions, Workflow, Conversions, Operational Reports:
Provide detail mapping for files, BDC’s, BAPI calls, IDOC’s, XI, and other. If applicable provide mapping documents
using other tools and include links as appropriate.}

5.7.1 File Formats

Field name Description Type Length Data Source
{e.g. DBMS field name}

5.7.2. Source System to BDC (Inbound Interfaces) / Custom Transactions

{Interfaces, Screen Exits/Custom Transactions: Insert a Visio diagram giving an overview of the BDC
screen flow}
SAP Screen Name & Number: ________________/_____________
SAP Table SAP Field SAP Field SAP Field SAP Field Source System / Source Field Source Field Comments / Data Transformation
Name Name Description Type Length Table / File Name Name Description Requirements / Data Validation
Requirements

5.7.3. Source System to BAPI / Function Module / Method (Inbound Interfaces)

{Interfaces, Conversions, Workflow: Insert a Visio diagram giving an overview of the BAPI / Function Module
/ Methods calls flow}
BAPI / Function Module/Method/Interface: ________________/_____________
SAP Table SAP Field SAP Field SAP Field SAP Field Source System / Source Field Source Field Comments / Data Transformation
Name Name Description Type Length Table / File Name Name Description Requirements / Data Validation
Requirements

5.7.4. Destination System to BAPI / Function Module / Method (Outbound Interfaces)

{Interfaces, Conversions, Workflow: Provide mapping details for outbound interfaces. Map the SAP
structures as described in the subtitle of this section to the destinations system. Provide a Visio diagram
for the flow.}

BAPI / Function Module/Method/Interface: ________________/_____________

SAP Table SAP Field SAP Field SAP Field SAP Field Source System / Source Field Source Field Comments / Data Transformation
Name Name Description Type Length Table / File Name Name Description Requirements / Data Validation
Requirements

5.7.5. Source  Target Mapping (Inbound Interfaces / Outbound Interfaces / XML)

{EDI, Interfaces: Provide general mapping details for inbound / outbound interfaces and formats. Include XML
formats as well.}

Working Copy as of
- 29 -
 Custom Development Request

Target Target Field Target Field Target Target Source System / Source Field Source Field Comments / Data Transformation
Table / Name Description Field Type Field Table / File Name Name Description Requirements / Data Validation
File Name Length Requirements

5.7.6 IDOC / Messaging Attachments / XML

{EDI: Provide additional details about mapping by attaching mapping spreadsheets that consolidate all used
fields. XML maps and definitions may be attached her,}

5.7.7. IDOC Mapping (Inbound / Outbound EDI Interfaces)

{EDI: Provide details about IDOC outbound mapping}
IDOC IDOC Field Qualifier Literal X12 Field X12 Static Field Description X12 Field Comments / Data
Segment Qualifier Description Transformation Requirements /
Data Validation Requirements

EDI_DC40 TABNAM

MANDT

DOCNUM

EDI team will attach the mapping document here :

5.7.8 Operational Reporting Layouts

{Operational Reports: Through a sample example, provide a description of the report layout. Specify at each
level what fields will be used and what fields will be summarized.}

Page Header

Header

Detail

Summary

Report Summary

Page Footer

Working Copy as of
- 30 -
 Custom Development Request

5.8 Analytical Data Processing and Reporting (BI, BW, Data Warehousing)
{Analytical Reports: Complete this section for analytical reporting the requires development around a star schema}

5.8.1 Data Sources / Master Data Attributes / Info-Objects

{Provide a detailed description of all custom / business content data sources that will be used and their definitions.
Use section 5.4.1 Data Extraction to describe any particular extraction development necessary. Use pseudo-code to
describe functionality. Include descriptions of layouts and formats.}

Data Source Name Description

Info Object Name Description Navigation Attribute (Y/N)

5.8.2 Info- Sources

{Provide a detailed description of all custom / business content info-sources that will be used and their definitions.
Provide detailed narrative about each info-source and use pseudo-code to describe functionality. Include descriptions
of layouts and formats.}
Info Source Name Description

5.8.3 Info- Providers

{Describe in detail the custom info-providers using the table below}
Object type Name Source Field Technical name
Characteristics

Key figures

Time characteristics

Units

5.8.4 Transfer / Update Rules

{Describe the transfer / Update Rules, using pseudo-code in the table below.}
Rule Type Name Info-Object Rule/Pseudo-Code

Working Copy as of
- 31 -
 Custom Development Request

Section 6 Testing

{This section is to be used by the Process and Application Development teams.}

6.1 Unit Testing

6.1.1 Environment / Configuration

{All: Describe the environment in which unit testing will occur, and any required or special configuration
settings that are needed in order for testing to take place.}
EDI Maps will be tested in the EDI Gentran environment.
All ABAP development will be tested in the SAP development box. Please add any specific test environment,
timings, settings required.

6.1.2 Data Requirements

{All: Describe any master data, historical data, or transactional data that is required in order to conduct unit
testing.}
All configurations for customer order processing should be complete in the test system.

6.1.3 Unit Test Plan

{All: Describe / list the individual unit test scenarios that will be executed. In the case of complex applications
unit tests must be created for each individual component as well as all components linking together.}

Test Scenarios/Description Systems Teams

Test EDI POPs orders and check the

markup is not included in the price billed. R/3, EDI SM, EDI

Send a Net order to SAP and verify that: 1)

the order is flagged as a Net order, 2) the
price is taken from the PO and not
overridden by SAP, 3) the dictated
mortgaging locations are used as an
override to APO GATP 4) appropriate
customer reference fields are populated. R/3, EDI SM, EDI
Send a Net order to SAP with a ship
schedule code for Will Call. Verify order is
marked as a Will Call order. R/3, EDI SM, EDI

Working Copy as of
- 32 -
 Custom Development Request

Send an EDI PO into SAP with most of the

possible text fields and verify the notes are
visible online. Verify specific notes are
printed on the pick/ship ticket. Send PO
Acknowledgment, Advance Ship Notice and
Invoice via EDI. Verify EDI hold text is
returned on all associated outbound
documents sent via EDI. R/3, EDI SM, EDI
Send an EDI PO into SAP with a customer
part number and ensure it cross references
appropriately in SAP. R/3, EDI SM, EDI
Send an EDI PO into SAP with a UPC
number and ensure it cross references
appropriately in SAP. R/3, EDI SM, EDI
Send a PO Acknowledgment via EDI
reflecting changes to order after the original
PO Acknowledgment has already been
transmitted to the customer. R/3, EDI SM, EDI

6.1.4 Unit Test Expected Results

{All: Describe / list the results expected from the unit tests to be executed.}

6.1.5 Unit Test Actual Results

{All: Describe / list the actual results from the completed unit tests.}
Test Case Description Status Systems Teams
Receive EDI PO for POPS (DLA Lamp)
order. Bill the PO, send EDI invoice. Verify
that contract number and call number are
loaded in SAP. Verify the 3.9% DSCP
markup is not included in the price billed. R/3, EDI SM, EDI

Send a Net order to SAP and verify that: 1)

the order is flagged as a Net order, 2) the
price is taken from the PO and not
overridden by SAP, 3) the dictated
mortgaging locations are used as an
override to APO GATP 4) appropriate
customer reference fields are populated. R/3, EDI SM, EDI
Send a Net order to SAP with a ship
schedule code for Will Call. Verify order is
marked as a Will Call order. R/3, EDI SM, EDI

Working Copy as of
- 33 -
 Custom Development Request

Send an EDI PO into SAP with most of the Notes visible online, not
possible text fields and verify the notes are on pick/ship ticket and
visible online. Verify specific notes are don't plan to be for
printed on the pick/ship ticket. Send PO general. TP specific
Acknowledgment, Advance Ship Notice and prints on pick/ship ticket.
Invoice via EDI. Verify EDI hold text is Outbound hold data is
returned on all associated outbound returned on
documents sent via EDI. 855,810s,and 856s. R/3, EDI SM, EDI

Send an EDI PO into SAP, ensure address

on Ship-to in SAP is overridden by address
in EDI data. Create a PO Acknowledgment
and ensure it contains the correct address.
Create another order against the same
Ship-To before the first order is shipped and
billed. Ship and bill the first order, ensure
the correct (overridden) address is on both
documents (Advance Ship Notice and Tested, all works
Invoice). Check taxability of the order (taxability is being tested
based on the ship-to address. by SM) R/3, EDI SM, EDI
Send an EDI PO into SAP with a customer
part number and ensure it cross references Works if cross reference
appropriately in SAP. exists R/3, EDI SM, EDI
Send an EDI PO into SAP with a UPC Don't have customer
number and ensure it cross references that sends UPC, should
appropriately in SAP. work fine R/3, EDI SM, EDI
Send a Cemas Request for Quote into SAP
and ensure all data loads appropriately.
Create response to quote and ensure all
needed data is contained on IDOC sent to
EDI.
Send a Cemas PO into SAP and ensure all
data loads appropriately. Create PO
Acknowledgment and ensure all needed
data is contained on IDOC sent to EDI. R/3, EDI SM, EDI

Send 3M EDI change order into SAP. If

original PO was received, and no changes
made, should have been picked and
shipped. If changes were made, PO
Acknowledgment goes back to 3M. Should
allocate product, but should not pick/pack or
ship until Change order is received
confirming changes made. R/3, EDI SM, EDI
Send EDI PO into SAP with block flag set, Tested, works if CSR set
verify order is blocked and CSR is alerted. up correctly R/3, EDI SM, EDI
Send a PO Acknowledgment via EDI that
has multiple changes to the line item date.
Ensure IDOC captures/flags changes
appropriately. Tested, works R/3, EDI SM, EDI

Working Copy as of
- 34 -
 Custom Development Request

Send a PO Acknowledgment via EDI

reflecting changes to order after the original
PO Acknowledgment has already been
transmitted to the customer. Tested works R/3, EDI SM, EDI

6.1.6 Unit Test Follow-up Required

{All: List any follow up actions required as a result of the testing}
Follow Up Action Item Assigned to Status

6.2 String Testing

6.2.1 Environment / Configuration

{All: Describe the environment in which testing will occur, and any required or special configuration settings
that are needed in order for string testing to take place.}

6.1.2 Data Requirements

{All: Describe any master data, historical data, or transactional data that is required in order to conduct string
testing.}

6.1.3 String Test Plan

{All: Describe / list the individual string test scenarios that will be executed. Clearly describe the context and
the dependencies that will be validated through each string test. Through string tests, application components
are tested within the framework of the whole system}

6.1.4 String Test Expected Results

{All: Describe / list the results expected from the string tests to be executed.}

6.1.5 String Test Actual Results

{All: Describe / list the actual results from the completed string tests.}

6.1.6 String Test Follow-up Required

{All: List any follow up actions required as a result of the string testing}

Follow Up Action Item Assigned to Status

Working Copy as of
- 35 -
 Custom Development Request

Section 7 Custom Development Review

{This section is to be completed by the Application Development team.}

7.1 Documentation
{All: Review whether Code Comments completed, Program Header completed, Change History Template
used Maintained, Development Specification Updated, On-line Change Request Documentation updated, On-
Line business Oriented documentation completed.}

7.2 Programming Standards

{All: Review if naming conventions used, standard program header used, security setup addressed,
transaction code created and linked to report tree, check extended syntax checks and review correct program
attributes are used.}

7.3 Fundamentals Followed

{All: Review whether Modularity used where appropriate, error and exception handling where addressed,
selection screen standards where followed.}

7.4 Performance Tuning

{All: Review whether SQL Trace performed, run time analysis performed, SAP R/ tuning check list performed}

7.5 Program Execution

{All: Review whether uniformity of selection screen and report appreance, report header checked, message
output where zero records found, end of report output line.}

7.6 Comments
{All: Any additional comments to assist with the custom development design}.

Working Copy as of
- 36 -