TechRefGuide EDI 905700

Epicor ERP
EDI / Demand Management

Technical Reference Guide
9.05.700
Disclaimer
This document is for informational purposes only and is subject to change without notice. This document and its
contents, including the viewpoints, dates and functional content expressed herein are believed to be accurate as of its
date of publication. However, Epicor Software Corporation makes no guarantee, representations or warranties with
regard to the enclosed information and specifically disclaims any applicable implied warranties, such as fitness for a
particular purpose, merchantability, satisfactory quality or reasonable skill and care. As each user of Epicor software is
likely to be unique in their requirements in the use of such software and their business processes, users of this document
are always advised to discuss the content of this document with their Epicor account manager. All information contained
herein is subject to change without notice and changes to this document since printing and other important information
about the software product are made or published in release notes, and you are urged to obtain the current release
notes for the software product. We welcome user comments and reserve the right to revise this publication and/or
make improvements or changes to the products or programs described in this publication at any time, without notice.
The usage of any Epicor software shall be pursuant to an Epicor end user license agreement and the performance of
any consulting services by Epicor personnel shall be pursuant to Epicor's standard services terms and conditions. Usage
of the solution(s) described in this document with other Epicor software or third party products may require the purchase
of licenses for such other products. Where any software is expressed to be compliant with local laws or requirements
in this document, such compliance is not a warranty and is based solely on Epicor's current understanding of such laws
and requirements. All laws and requirements are subject to varying interpretations as well as to change and accordingly
Epicor cannot guarantee that the software will be compliant and up to date with such changes. All statements of
platform and product compatibility in this document shall be considered individually in relation to the products referred
to in the relevant statement, i.e., where any Epicor software is stated to be compatible with one product and also
stated to be compatible with another product, it should not be interpreted that such Epicor software is compatible
with both of the products running at the same time on the same platform or environment. Additionally platform or
product compatibility may require the application of Epicor or third-party updates, patches and/or service packs and
Epicor has no responsibility for compatibility issues which may be caused by updates, patches and/or service packs
released by third parties after the date of publication of this document. Epicor® is a registered trademark and/or
trademark of Epicor Software Corporation in the United States, certain other countries and/or the EU. All other
trademarks mentioned are the property of their respective owners. Copyright © Epicor Software Corporation 2012.
All rights reserved. No part of this publication may be reproduced in any form without the prior written consent of
Epicor Software Corporation.
DOC0091E9
9.05.700
Revision: March 15, 2012 6:50 p.m.
Total pages: 247
sys.ditaval
EDI / Demand Management Technical Reference Guide Contents
Contents
Introduction............................................................................................................................9
Purpose of this Guide.......................................................................................................................................9
Intended Audience...........................................................................................................................................9
How It is Organized.........................................................................................................................................9
EDI / Demand Management Base Concepts.......................................................................11
What is Electronic Data Interchange (EDI)?.....................................................................................................12
Supported Inbound EDI Documents........................................................................................................12
Supported Outbound EDI Documents.....................................................................................................13
What is TIE KINETIX eVisionTM?.....................................................................................................................14
Importing Inbound EDI Transactions...............................................................................................................14
What is Demand Management?.....................................................................................................................15
Typical EDI / Demand Management Processing Flow.......................................................................................17
Defining the Trading Partner in Customer Maintenance..........................................................................17
Entering a Demand Contract..................................................................................................................18
Processing Inbound Transactions Using the Import EDI Demand Process..................................................19
Correcting Errors Using Demand Workbench...................................................................................20
Optional - Processing Inbound EDI Transactions Using Service Connect Workflows..................................20
Optional - Correcting Errors With the Service Connect Task Monitor................................................21
Automated and Manual Demand Entry Processing..................................................................................22
Generating Outbound EDI Transactions..................................................................................................24
Setup Components...............................................................................................................27
Prerequisite Installation and Setup Tasks - Direct EDI Import...........................................................................28
Optional Installation and Setup Tasks - Epicor Service Connect.......................................................................30
Company Configuration Maintenance...........................................................................................................32
Programs and Their Modifiers.................................................................................................................32
Customer Periodicity Maintenance.................................................................................................................35
Programs and Their Modifiers.................................................................................................................36
Defining Trading Partners in Customer Maintenance......................................................................................37
Customer > Demand Sheet.....................................................................................................................38
Programs and Their Modifiers..........................................................................................................39
Documents Sheet...................................................................................................................................52
Ship To > Demand Sheet........................................................................................................................57
Ship To > Documents Sheet....................................................................................................................59
Defining Outbound EDI Report Formats.........................................................................................................59
Report Data Maintenance.......................................................................................................................60
Report Style Maintenance.......................................................................................................................64
Business Activity Manager.......................................................................................................................68
Report Data Maintenance - Auto Print Rules...........................................................................................72
Processing Components.......................................................................................................74
Epicor ERP | 9.05.700 3

Contents EDI / Demand Management Technical Reference Guide
Entering Demand Contracts...........................................................................................................................74

Header Sheet..........................................................................................................................................75
Line > Detail Sheet..................................................................................................................................79
Header > Matching Sheet.......................................................................................................................82
Creating Demand Entries for Existing Orders..................................................................................................89
Inbound EDI Transaction File Mappings..........................................................................................................91
EDI File Requirements and Formatting Rules............................................................................................92
Record Hierarchy for Inbound EDI Files....................................................................................................93
Demand_Header Rows (Demand Header Record for DemandHead Table)...............................................94
Table Schematic for Demand_Header Row Sample..........................................................................95
User_Defined Rows...............................................................................................................................104
Table Schematic for User_Defined Row Sample..............................................................................105
Extra_Charges Rows (DemandMisc Table for DemandHeader and DemandDetail Records)....................107
Table Schematic for Extra_Charges Row Sample............................................................................108
Demand_Detail Rows (Demand Detail Record for DemandDetail Table).................................................110
Table Schematic for Demand_Detail Row Sample...........................................................................111
Demand_Schedule Rows (Demand Schedule Record for DemandSchedule Table)..................................117
Table Schematic for Demand_Schedule Row Sample......................................................................118
Smart String Rows (for Demand_Detail Table).......................................................................................125
Table Schematic for Smart String Row Sample...............................................................................126
Direct Inbound EDI Transaction Import.........................................................................................................127
Scheduling and Running the Import EDI Demand Process......................................................................127
Programs and Their Modifiers........................................................................................................127
Using the System Agent and Completing the Import EDI Demand Process.....................................128
Using the Demand Workbench for Error Correction..............................................................................129
Import EDI Demand and User Hook Programs.......................................................................................133
Understanding the User Hook Programs Flowchart........................................................................135
Optional - Service Connect Workflow Processing..........................................................................................137
Main Workflow....................................................................................................................................141
Main_DemandHeadUpdate Workflow..................................................................................................142
Main_DemandDetailUpdate Workflow..................................................................................................152
Main_DetailPartValidation.....................................................................................................................159
Main_DemandScheduleUpdate Workflow.............................................................................................162
Correcting Errors Using the Service Connect Task Monitor....................................................................164
Invalid Contract Task Error Example...............................................................................................165
Invalid Demand Data Error Correction Example..............................................................................165
Main_DemandHead Update Workflow Error Messages..................................................................167
Main_DemandDetail Update Workflow Error Messages.................................................................168
Main_DetailPartValidation Workflow Error Messages.....................................................................169
Main_DemandSchedule Update Workflow Error Messages............................................................170
Demand Entries Generated from Inbound EDI Transactions..........................................................................171
Demand Processing Logs and Error Resolution.............................................................................................172
Demand Log Entries Generated from Service Connect Workflows.........................................................174
Order Transactions Generated from Inbound EDI Demand............................................................................176
4 Epicor ERP | 9.05.700

Programs and Their Modifiers...............................................................................................................178

Forecast Transactions Generated from Inbound EDI Demand........................................................................179
EDI 855/865/ORDRSP Transactions (Outbound Purchase/Change Order Acknowledgements)........................180
EDI 856/DESADV Transactions (Outbound Advance Shipping Notices)..........................................................182
EDI 810/INVOIC Transactions (Outbound Invoices)........................................................................................184
Demand Review Report................................................................................................................................186
Demand to Sales Order Net Change Report.................................................................................................187
Modifiers.............................................................................................................................189
Accept Type.................................................................................................................................................189
Where Located.....................................................................................................................................190
Action (Add)................................................................................................................................................190
Where Located.....................................................................................................................................191
Action (Cancel)............................................................................................................................................191
Where Located.....................................................................................................................................192
Action (Change)...........................................................................................................................................192
Where Located.....................................................................................................................................193
Action (Check for Part).................................................................................................................................194
Where Located.....................................................................................................................................194
Action (Check Partial Shipments)..................................................................................................................195
Where Located.....................................................................................................................................195
Action (Check for Revision Level)..................................................................................................................196
Where Located.....................................................................................................................................196
Action (Cumulative Check Discrepancies).....................................................................................................197
Where Located.....................................................................................................................................197
Action (Date Change)..................................................................................................................................198
Where Located.....................................................................................................................................198
Action (New Line)........................................................................................................................................199
Where Located.....................................................................................................................................199
Action (Quantity Change)............................................................................................................................200
Where Located.....................................................................................................................................200
Add.............................................................................................................................................................201
Where Located.....................................................................................................................................201
Example................................................................................................................................................201
Allow Non Perfect Match.............................................................................................................................202
Where Located.....................................................................................................................................202
Allow Shipments for Orders on Hold............................................................................................................202
Where Located.....................................................................................................................................203
Alt Trading Partner.......................................................................................................................................203
Where Located.....................................................................................................................................203
Automatically Match All...............................................................................................................................204
Where Located.....................................................................................................................................204
Cancel.........................................................................................................................................................204
Where Located.....................................................................................................................................204
Example................................................................................................................................................205
Cancel Non Matched...................................................................................................................................205
Epicor ERP | 9.05.700 5

Where Located.....................................................................................................................................206
Cancel Schedules Action..............................................................................................................................206
Where Located.....................................................................................................................................206
Change........................................................................................................................................................207
Where Located.....................................................................................................................................207
Example................................................................................................................................................207
Check Forecast Schedules............................................................................................................................208
Where Located.....................................................................................................................................208
Check for Part..............................................................................................................................................208
Where Located.....................................................................................................................................208
Check Partial Shipments...............................................................................................................................209
Where Located.....................................................................................................................................209
Check for Revision Level...............................................................................................................................210
Where Located.....................................................................................................................................210
Close Rejected Schedules.............................................................................................................................211
Where Located.....................................................................................................................................211
Logic/Algorithms...................................................................................................................................212
Check Unfirm Schedules..............................................................................................................................212
Where Located.....................................................................................................................................212
Consider Working Days in the Delivery Days Calculation...............................................................................212
Where Located.....................................................................................................................................213
Cumulative Check Discrepancies..................................................................................................................213
Where Located.....................................................................................................................................213
Daily, Rules..................................................................................................................................................214
Where Located.....................................................................................................................................214
Daily, Include Saturdays and Sunday Shipments...........................................................................................215
Where Located.....................................................................................................................................215
Date Change...............................................................................................................................................215
Where Located.....................................................................................................................................215
Example................................................................................................................................................216
Date Type....................................................................................................................................................216
Where Located.....................................................................................................................................216
Delivery Days...............................................................................................................................................217
Where Located.....................................................................................................................................218
Example................................................................................................................................................218
Direction......................................................................................................................................................219
Where Located.....................................................................................................................................219
Exclude From / From (days)...........................................................................................................................219
Exclude Until / Until (days)............................................................................................................................220
Hold Orders for Review................................................................................................................................220
Where Located.....................................................................................................................................220
Import Folder (Company Maintenance)........................................................................................................221
Where Located.....................................................................................................................................221
6 Epicor ERP | 9.05.700

Import Folder...............................................................................................................................................222
Where Located.....................................................................................................................................222
Map ID........................................................................................................................................................222
Where Located.....................................................................................................................................223
Monthly Forward, Rules...............................................................................................................................223
Where Located.....................................................................................................................................224
Monthly Forward, First Day Ship...................................................................................................................224
Where Located.....................................................................................................................................224
Monthly Forward, Week Number in the Month............................................................................................224
Where Located.....................................................................................................................................224
New Line.....................................................................................................................................................225
Where Located.....................................................................................................................................225
Example................................................................................................................................................226
Nth Day of the Week, Rules.........................................................................................................................226
Where Located.....................................................................................................................................226
Nth Day of the Week, Day of the Week Shipment........................................................................................226
Where Located.....................................................................................................................................226
Options Available.........................................................................................................................................227
Where Located.....................................................................................................................................228
Options Selected..........................................................................................................................................228
Where Located.....................................................................................................................................229
Outbound Document...................................................................................................................................229
Where Located.....................................................................................................................................230
Periodicity....................................................................................................................................................230
Where Located.....................................................................................................................................230
Pricing.........................................................................................................................................................231
Where Located.....................................................................................................................................231
Quantity Change.........................................................................................................................................232
Where Located.....................................................................................................................................232
Example................................................................................................................................................232
Split Demand...............................................................................................................................................233
Where Located.....................................................................................................................................233
Test Record..................................................................................................................................................234
Where Located.....................................................................................................................................234
Tolerance.....................................................................................................................................................234
Where Located.....................................................................................................................................235
Trading Partner............................................................................................................................................235
Where Located.....................................................................................................................................235
Type............................................................................................................................................................236
Where Located.....................................................................................................................................237
Unit Price Difference....................................................................................................................................237
Where Located.....................................................................................................................................238
Example................................................................................................................................................238
Weekly Forward, Rules.................................................................................................................................238
Where Located.....................................................................................................................................239
Epicor ERP | 9.05.700 7

Weekly Forward, Ship Day...........................................................................................................................239

Where Located.....................................................................................................................................239
Appendices..........................................................................................................................240
Appendix A: EDI Demand Management / Order Management Pricing Flowcharts.........................................240
Appendix B: EDI / Demand Management Part Validation Processing Flowchart.............................................242
Appendix C: Part Lookup and UOM Determination Flowchart......................................................................243
Appendix D: EDI / Demand Management Plant Code Assignment Flowchart................................................244
8 Epicor ERP | 9.05.700

EDI / Demand Management Technical Reference Guide Introduction
Introduction
Purpose of this Guide
The EDI / Demand Management Technical Reference Guide examines, in detail, the primary components
that make up the Electronic Data Interchange (EDI) / Demand Management module interface. Many of the primary
components discussed in this guide perform more functions than what is described.
For more information about these features, review the related topics in the Application Help, contact your
consultant, or enroll in an appropriate Epicor course. When you finish reading this guide, you should better
understand the logic behind the EDI - Demand Management module interface.
Note This document only covers the functions found in the Demand Management module; this module
is designed for use with EDI in Epicor ERP, use. The EDI module was deprecated in the 9.04.xxx release and
contains legacy programs intended for use only with Vantage 8.0X; the functions found in the EDI module
are not covered in this document.
Intended Audience
This guide is intended for individuals within your company responsible or partially responsible for Information
Technology, Electronic Data Interchange (EDI) and demand management activities.
Individuals who have this responsibility:
• Are responsible for fulfilling and managing demand from your customer trading partners, from initially
negotiating demand contracts through creation of orders and outbound documents such as Advanced Shipping
Notices (ASNs), sales order acknowledgements, packing slips and invoices.
• Are typically personnel involved in Information System or Information Technology departments in your
organization who work with your customer trading partners to manage inbound and outbound data interchange
transactions. This includes mapping the data formats required for demand management processing in your
Epicor application to your customer trading partner's EDI formats.
How It is Organized
This guide first explores the concepts behind the Demand Management module interface and then details the
third-party and Epicor application components that affect this interface. Each subsequent section explores more
detailed information than the previous section. The following are the main sections of this guide:
1. EDI / Demand Management Introduction and Base Concepts - This section explores the underlying
concepts behind the EDI / Demand Management module interface. We recommend that you read this section
first, as the rest of the guide references the information contained in this section.
Epicor ERP | 9.05.700 9

Introduction EDI / Demand Management Technical Reference Guide
2. Setup Components - This section explores the main calculations and base values used for the setup of the
EDI / Demand Management module interface. Review this material to learn about defining customer trading
partner and document processing rules.
3. Processing Components - This section explores the main calculations and base values used in EDI / Demand
Management module interface processing. Review this material to learn about mapping the data formats
required for demand management processing in your Epicor application to your customer trading partner's
EDI processing formats, and how inbound EDI files are converted into actionable demand entries, demand
schedules, orders, shipping transactions and invoices.
4. Modifiers - This section documents any fields or functions that you can use to adjust/override the outcome
of the EDI / Demand Management module interface.
5. Appendices - This section includes supporting flowcharts related to pricing, part validation, part lookup
and plant code assignment processing.
Please note that to clarify how the EDI / Demand Management module interface works, the concepts behind
each item are often repeated within other items. This is done to show how the various components, calculations,
values, and modifiers work together to convert inbound EDI files received from your customer trading partners
into actionable demand entries, demand schedules, orders, forecasts, shipping transactions and invoices.
10 Epicor ERP | 9.05.700

EDI / Demand Management Technical Reference Guide EDI / Demand Management Base Concepts
EDI / Demand Management Base Concepts
The EDI / Demand Management module interface is designed to automate sales efforts and facilitate closer
supplier-customer partnerships. It allows you to receive inbound electronic demand information from your trading
partners into your Epicor application, process the information in an automated manner, generate the appropriate
sales order, acknowledgement, forecast, shipping and invoice documents, and in turn, send the required
information back to your trading partners via outbound EDI transactions.
It utilizes three major components:
• Electronic Data Interchange Processor (eVision™ by TIE KINETIX™ - Third-Party)
• Direct EDI Import or Epicor Service Connect
• Demand Management (Epicor application)
Epicor ERP | 9.05.700 11

EDI / Demand Management Base Concepts EDI / Demand Management Technical Reference Guide
What is Electronic Data Interchange (EDI)?
Electronic Data Interchange (or EDI) is a standardized computer interface that allows for electronic exchange of
business information using internationally recognized standards and formats. Hundreds of standardized document
types have been created throughout the world that form a universal language that companies using dissimilar
systems and processes can utilize to conduct business.
It allows for standardized transfer of files between you and your customer trading partners. Use of EDI allows
suppliers and their customers to manage their supply chains more efficiently by increasing efficiency and drastically
reducing their requirements for costly and error-prone manual data entry.
The Epicor application supports processing of the following types of standard EDI transactions. The descriptions
that follow are based on the formal descriptions issued by the Accredited Standards Committee (ASC) X12
(http://www.x12.org/). This international organization develops EDI transaction standards and related documents
for national and global markets. United Nations-sponsored EDIFACT transactions are another
internationally-recognized set of similar standards; both X12 and EDIFACT standards are reflected throughout
this document.
Supported Inbound EDI Documents
Epicor ERP and the Demand Management module support processing of the following types of inbound EDI
documents:
• 830/DELFOR (Inbound Planning Schedule) - This EDI document is used for the transfer of forecasting/material
release information from your customer trading partner. The planning schedule transaction can be used in a
combination of ways, such as:
• A simple forecast
• A forecast with the buyer's authorization for the seller to commit to resources, such as labor or material.
A forecast that is also used as an order release mechanism containing such elements as resource
authorizations, period-to-date cumulative quantities and specific ship/delivery patterns for requirements
that have been represented in "buckets," such as weekly, monthly, or quarterly. The order release forecast
may also contain all data related to purchase orders, as required, because the order release capability
eliminates the need for discrete generation of purchase orders.
• 850/ORDERS (Inbound Purchase Order) - This EDI document is an electronic version of a paper purchase
order you receive from a customer trading partners. Your customer trading partner uses it to communicate
to you, the supplier, the specific items, unit prices, and quantities they wish to have delivered. Shipping
instructions frequently accompany the purchasing information.
• 860/ORDCHG (Inbound Purchase Order Change) - This EDI document is used by your customer trading
partner to request a change to a previously submitted purchase order; or to confirm acceptance of a purchase
order change initiated by you the supplier or by mutual agreement of the two parties. Your customer trading
partner uses it to communicate to you, the supplier, the specific items, unit prices, and quantities they wish
to change.
• 862/DELJIT (Inbound Shipping Schedule) - This EDI document is used by your trading partner to
communicate precise shipping schedule requirements to you, the supplier, and is intended to supplement EDI
830/DELFOR inbound planning schedule transactions.
This type of EDI transaction facilitates the practice of Just-In-Time (JIT) manufacturing by providing your trading
partner with the ability to issue precise shipping schedule requirements on a more frequent basis than using
EDI 830/DELFOR planning schedule transactions (for example, daily versus weekly planning schedules). It also
provides the ability for a specific ship to customer location to issue shipping requirements independent of
12 Epicor ERP | 9.05.700

other customer locations when planning schedule transactions are issued by a consolidated scheduling
organization.
Supported Outbound EDI Documents
Epicor ERP and the Demand Management module support processing of the following types of outbound EDI
documents:
• 810/INVOIC (Outbound AR Invoices) - This EDI document is an electronic version of a paper invoice you
normally send to your customer. As a supplier, you use 810/INVOIC Invoices to communicate the payment
terns, specific items, price, and quantities you have delivered and which now must be paid for by your customer
trading partner. In the Epicor application, the foundation for this type of outbound EDI document is the text
or XML-based document record that it generates (either automatically or manually) in AR Invoice Entry based
on the standard AR Invoice form.
• 855/ORDRSP and 865/ORDRSP (Outbound Purchase Order Acknowledgements) - These EDI documents
are electronic version of a phone call or fax you use to inform your customer trading partner (who sent you
a purchase order or purchase order change) that you are fulfilling the transactions as requested. This informs
them that you are filling the order and shipping the goods by the requested date, or are not able to fulfill the
entire order as requested, possibly due to stockouts or disagreement about the purchase terms.
EDI 855/ORDRSP transactions are usually sent in response to an EDI 850/ORDERS or EDI 860/ORDCHG inbound
purchase order or purchase order change document you receive from your customer trading partner. In the
Epicor application, the foundation for this type of outbound EDI document is the text or XML-based document
record that it generates (either automatically or manually) in Sales Order Entry based on the standard
Sales Order Acknowledgement report.
• 856/DESADV (Outbound Order Advanced Shipping Notice/Manifest- ASN) - This EDI document is an
electronic version of a printed packing slip that tells your customer trading partner how you, the supplier, has
packed their items for shipment. The Advance Ship Notice, or ASN, also tells the buyer that the goods have
been shipped so they can be expecting the shipment. In the Epicor application, the foundation for this type
of outbound EDI document is the text or XML-based document record that it generates (either automatically
or manually) in Customer Shipment Entry or Master Pack Shipment Entry based on the standard Packing
Slip form.
This type of outbound EDI transaction lets the personnel working on the receiving dock of your trading partner
know what you have packed in shipping cartons, and eliminates the need for their receiving personnel open
the cartons.
Tip These are the "out-of-box" inbound and outbound EDI transaction types supported in the base
Epicor application. Other types of EDI transactions can be implemented as required, based on the
development of associated report data definitions. Contact your Epicor consultant or the Custom
Solution Group for assistance or for more details.
Epicor ERP | 9.05.700 13

What is TIE KINETIX eVisionTM?
eVision is a third-party software package provided by TIE KINETIX, and is the only XML/EDI solution that has
been formally certified by Epicor for use with the Epicor application.
It uses advanced data transformation, integration, and workflow applications that are easily scalable as the
number of trading partners you interact with increase, and your operations grow in size and transaction volume.
It allows you to easily exchange critical business data between and within organizations.
• In general, eVision receives inbound EDI 830/DELFOR, 850/ORDERS, 860/ORDCHG and 862/DELJIT files from
your customer trading partners, converts them into a pre-defined Epicor-compatible format files, and then
deposits them into a designated inbound folder on your Epicor server for processing.
• Conversely, eVision collects outbound Order Acknowledgement, Advanced Shipping Notice and AR Invoice
document record files (produced by the Epicor application) from the designated outbound file folder on your
Epicor server and directly converts them to outbound EDI 810/INVOIC, 855/ORDRSP, 865/ORDRSP and
856/DESADV files that are sent to your customer trading partners.
Tip Refer to the marketing publications and documentation produced by TIE KINETIX for more information
on what this application does and how it functions. eVision is a trademark of TIE KINETIX but appears
without the trademark symbol in the remainder of the document. It may also be referred to interchangeably
as TIE KINETIX or TIE KINETIX eVision.
Importing Inbound EDI Transactions
Inbound text-based EDI transactions received from your customer trading partners and passed by the eVision
third-party application directly link to the Epicor application using the Import EDI Demand Process or through
the use of Epicor Service Connect.
Users are on 9.05.607 or above are strongly encouraged to use the Import EDI Demand Process (direct EDI import),
however, you can (optionally) import EDI documents using Epicor Service Connect.
• The Import EDI Demand Process runs on a server code and it significantly improves the EDI performance.
Users manage the entire process using Epicor ERP menu items - Import EDI Demand Process and correct
any potentials errors using Demand Workbench.
Service Connect is an optional method that can be used for processing inbound EDI transactions passed by the
eVision third-party application. It generates records in the Epicor application (for further processing by the
Demand Management module) through the use of several pre-defined processing workflows.
• Referring to the Inbound EDI Transaction File Mappings section later in this document, Service Connect
processes the inbound EDI file row by row, and data position by data position.
• Service Connect then performs the data verification and validation tasks, as detailed in the Service Connect
Workflow Processing section of this document.
• If, after successfully performing all required data verification and validation checks, Service Connect determines
that an incoming EDI file is error-free, it immediately converts the data values in the inbound file into
corresponding records in the appropriate database tables (for example, the DemandHeader, DemandDetail
and DemandSchedule tables) within the Epicor application. The resulting information can be viewed in Demand
Entry.
Refer to the Processing Demand Entries section for more details.
14 Epicor ERP | 9.05.700

What is Demand Management?
The Demand Management module in the Epicor application allows you to more efficiently manage short and
long term customer demand contracts, converting demand from these contracts into sales orders and MRP
forecasts.
You can enter this demand information manually, or generate electronic information that passes both to and
from your customer trading partners. Demand Management handles creation, analysis, editing, and reconciliation
of cumulative totals for releases from your trading partners. The Demand Management module provides an
efficient process to manage the data from demand contracts. It can be used to process EDI files received from
customer trading partners, and provides the following functionality:
• Using the Customer Maintenance > Customer > Demand or Ship To > Demand sheets, you associate a
trading partner identification number with the customer. It is a universal code required on EDI transactions
that uniquely identifies the business entity. Using the Customer Maintenance > Documents or Ship To >
Documents sheets, you also create user-defined rules for each customer trading partner that specify acceptance
and matching criteria for demand transactions received on inbound EDI documents.
• You can specify if inbound EDI transactions should be automatically processed; if you elect to do this, the
Epicor application automatically generates order releases or forecasts for all (or just those that are found
to be error-free) inbound EDI transactions You can also create user-defined rules for each customer trading
partner that specify how and when outbound EDI order acknowledgement, Advanced Shipping Notice
and invoice transactions should be generated.
• These data and lead time validations specify how incoming demand should be treated when action requests
are received from your customer trading with insufficient lead times with respect to required shipping
dates. You also define delivery day and customer periodicity parameters used to calculate Ship By or NeedBy
dates for shipping schedules. You can also specify if extra validations (such as part number, part revision,
unit price and partial shipment tests) should be performed to determine if inbound demand transactions
received from your customer trading partner should be accepted or rejected.
Epicor ERP | 9.05.700 15

• You then enter demand contracts for these customers into Demand Contract Entry, using any length of
time (days, months, years) that you need for the length of the contact.
• The demand contract structure lets you attach multiple sales order releases to a single demand contract,
providing the ability to review the contract quantities with the actual incoming quantities.
• It also contains robust matching logic that allows you to receive and efficiently process changes (quantities,
prices and shipping dates) your customer trading partner requests to existing demand schedules and order
releases.
• A demand schedule is a schedule of order releases (processed against a demand contract) that defines both
the part quantities and the dates on which each release needs to be shipped to your customer trading partner.
• You can enter demand schedules for each demand contract manually, or
• If your customer trading partners sends you demand schedules via inbound EDI transactions, they are
automatically generated when the EDI transactions are successfully imported in the Epicor application
electronically through the direct EDI import or using Service Connect.
• The Direct EDI Import process runs using server-based code; it provides a Demand Import Workbench that
allows you to modify/correct possible errors during processing; this is as an efficient way to review and detect
errors on the received demand. This process exploits the scheduling and multiprocessor capabilities of the
Epicor 9 framework, and eliminates Service Connect from the EDI architecture (while keeping the layout of
the tilde delimited file); this significantly improves EDI inbound processing times.
• Optionally, the Demand Management module, in conjunction with Service Connect, provides an automated
verification and validation of incoming EDI data.
• This interface allows you to efficiently process and manage the large volumes of data that are possible
when using long term demand contracts.
• If invalid data is identified during inbound processing, you can correct it as required using the Service
Connect Task Monitor. Refer to Correcting Errors Using the Service Connect Task Monitor for details.
• Once inbound EDI transactions are received from your trading partners through Service Connect, the Epicor
application processes demand using a series of comprehensive workflows that in effect perform the same
tasks as Demand Entry or Demand Mass Review, but in a totally automated manner. However, you
can use these programs as necessary to review the demand lines and shipping schedule, letting you evaluate
their impact. Note: For this module to be fully functional with EDI, Service Connect must be installed. If
you use EDI to process your demand, you need to install and configure the third-party EDI functionality
on your Epicor server. Refer to the companion EDI TIE KINETIX Integration Guide and the Setup
Components section of this document for detailed information on how to configure and integrate the
Demand Management module with TIE KINETIX eVision.
• Demand Entry and Demand Mass Review both contain tools that let you manually reject and approve demand
schedules.
• This provides you with the ability to view the impact of incoming contract changes before accepting them.
The Epicor application also allows you to accept, revise, or reject these changes- and provides you with
the appropriate response to the trading partner.
• You can manually reject demand transactions if necessary.
• When you are satisfied with the schedule, you can then process the demand, converting it into firm releases,
unfirm releases, or MRP forecasts.
• The Epicor application can be configured to send automated EDI 855/ORDRSP and EDI 865/ORDRSP
Purchase Order Acknowledgements to your trading partner. It can also be configured to automatically
process shipping schedules and change requests to existing sales orders that have no lead time warnings,
immediately allowing quantity or date changes. Only transactions that have errors are displayed within
Demand Entry.
16 Epicor ERP | 9.05.700

• You can also manually override System Rejected demand entries that have not passed validations based
on user-defined rules you specify for the customer trading partner in the Customer Maintenance > Customer
> Demand or Ship To > Demand sheets. This allows you to efficiently manage differences between demand
contract and inbound demand.
• When the part quantity is shipped, customers can be notified electronically through an Advanced Shipping
Notification (ASN 856/DESADV). They, in turn, respond with the results of the shipment. The Epicor application
can also be configured to send automated EDI 810/INVOIC AR invoices to your trading partner.
• You can use the imported cumulative data (ACCUM) to adjust, or reconcile, the changes that occur during
shipping. The ACCUM Setting is used to reconcile the cumulative shipping part quantities (ACCUM) generated
through this contract. This setting helps you track the difference between the quantities shipped from your
company and the actual quantities received by your customers.
Typical EDI / Demand Management Processing Flow
The following section contains an example of a typical processing for flow for an inbound EDI transaction you
receive from a customer trading partner.
This workflow usually involves performing the following tasks:
• Defining the Trading Partner in Customer Maintenance
• Entering a Demand Contract
• Processing Inbound Transactions Using the (Direct) Import EDI Demand Process
• Processing Inbound EDI Transactions using Service Connect Workflows
• Correcting Errors using Demand Workbench or the Service Connect Task Monitor
• Automated and Manual Demand Entry Processing
• Generating Outbound EDI Transactions
Tip For detailed information about each of these processing steps, refer to the Setup Components and
Processing Components sections of this document.
Defining the Trading Partner in Customer Maintenance
A customer or business entity is identified in inbound and outbound EDI transactions by a unique trading partner
identification number. Prior to receiving inbound EDI transactions from a customer, you must assign and associate
the trading partner identification number with a specific customer record or ship to customer location in the
Customer Maintenance > Customer > Demand or Ship To > Demand sheets.
A customer or business entity is identified in inbound and outbound EDI transactions by a unique trading partner
identification number. Prior to receiving inbound EDI transactions from a customer, you must assign and associate
the trading partner identification number with a specific customer record or ship to customer location in the
Customer Maintenance > Customer > Demand or Ship To > Demand sheets.
• Using Customer Maintenance > Documents or Ship To > Documents sheets, you also create user-defined
rules that specify acceptance and matching criteria for demand transactions received on inbound EDI documents.
It also allows you to specify if inbound EDI transactions should be automatically processed; if you elect to do
this, the Epicor application automatically generates order releases or forecasts for all (or just error-free) inbound
EDI transactions.
Using the same sheets, you can also create user-defined rules for each customer trading partner that specify
how and when outbound EDI order acknowledgement, Advanced Shipping Notice and invoice transactions
should be generated.
Epicor ERP | 9.05.700 17

Entering a Demand Contract
Prior to receiving inbound EDI transactions from the customer trading partner, you must first use Demand
Contract Entry to manually enter demand contracts.
• The demand contract is the instrument against which the Epicor application receives and processes inbound
EDI files received from your customer trading partners.
The demand contract structure lets you attach multiple sales order releases to a single demand contract,
providing the ability to review the contract quantities with the actual incoming quantities. It also contains
robust matching logic that allows you to receive and efficiently process changes (quantities, prices and shipping
dates) your customer trading partner requests to existing demand schedules and order releases.
• Once inbound EDI transactions have been received, the Epicor application uses the demand contract records
to automatically generate demand for your parts, allowing you to set up a shipping schedule for order releases
or forecasts for MRP processing.
18 Epicor ERP | 9.05.700

Processing Inbound Transactions Using the Import EDI Demand Process
The Demand Management module in your Epicor application provides a capability to process inbound EDI flat
files passed by the TIE Commerce eVision third-party application directly into the Epicor application.
Direct EDI import is managed through use of the Import EDI Demand Process. Use this program to import files
based on a specified processing schedule, using an import folder where inbound EDI documents are deposited.
This menu item is found within the General Operations folder of the Demand Management module. It utilizes
Epicor ERP framework to process demand records received via EDI transactions from your trading partners.
Tip Use the Company Configuration > Modules > Sales > Demand sheet to set up the default location
of an Import process folder. To create a backup folder that archives files that have been processed, enable
the Backup Processed File check box. At the bottom of the Import EDI Demand Process, select a schedule
of your process.
Tip Use the Schedules sheets within System Agent Maintenance to add schedules to a specific system
agent and to review tasks assigned to the selected schedule. The schedule identifies how often the tasks
linked to the schedule will run.
Epicor ERP | 9.05.700 19

Correcting Errors Using Demand Workbench
If wrong data is identified during direct EDI import processing, you can correct it as required using the Demand
Workbench, found within the General Operations folder of the Demand Management module.
Data import errors occur primarily due to mismatches between the data sent by your customer trading partner
on an inbound EDI transaction and the corresponding data stored in your Epicor application.
Example If the demand contract specified on the inbound EDI transaction is not valid for the trading
partner, or cannot be found in the Epicor application database, a Demand Header Invalid Contract message
displays on the Detail > Header > Errors sheet.
First, search for any potential errors that occurred during the direct EDI import. Use the Errors sheets found on
the Header, Line and Schedule level to identify a reason for the error.
• After you correct invalid data on inbound EDI transactions, from the Actions menu, select Ready To Process.
Once you select this option, a document that first failed to be loaded into Demand Management is ready for
re-processing next time the Import EDI Demand Process is scheduled to run.
In order to process the corrected demand entries immediately, from the Actions menu, select Process IM
Demand. The Import EDI Demand Process window displays, allowing you to submit the process.
Note You cannot create new demand entries using Demand Workbench. This program is only used to
correct entries that failed to be processed using direct EDI import.
Optional - Processing Inbound EDI Transactions Using Service Connect Workflows
The Service Connect module in your Epicor application processes inbound EDI flat files passed by the TIE KINETIX
eVision third-party application into records stored in database tables that can be processed in the Epicor application.
Refer to the EDI Transaction File Mappings section for more details.
The main components Service Connect uses to process demand records received via EDI transactions from your
trading partners are a series of bundled, pre-defined workflows provided by Epicor.
• These workflows are designed to create, transform, manipulate and update data within the Epicor application.
They generate records in the appropriate database tables for further processing by the Demand Management
module.
• Service Connect uses these pre-defined workflows to process an inbound EDI file row by row. Each workflow
performs specific data verification and validation tasks, as detailed in the remainder of this section.
• If wrong data is identified during inbound processing, you can correct it as required using the Service Connect
Task Monitor.
Tip These pre-defined "out-of-box" workflows are very flexible and can be customized to fit your specific
business needs. Contact your Epicor consultant or the Custom Solution Group for assistance or for more
details.
20 Epicor ERP | 9.05.700

If, after successfully performing all required data verification and validation checks Service Connect determines
Entry. Refer to the Processing Demand Entries section for more details.
• Depending on the specific settings for the customer trading partner, these workflows also create order and
forecast transactions from the demand entries it creates. If the inbound EDI transaction file is error-free,
this takes place automatically without any required human intervention.
• Refer the Order Transactions Generated from Inbound EDI Demand and Forecast Transactions
Generated from Inbound EDI Demand sections for more detail.
Optional - Correcting Errors With the Service Connect Task Monitor
When the Service Connect EDI workflow package detects validation errors, it produces various error messages
that display in the Task Monitor. These errors occur primarily due to mismatches between the data sent by
your customer trading partner on an inbound EDI transaction and corresponding data stored in your
Epicor application.
Using the Task Monitor, you can either abort workflow processing, or easily correct invalid data on inbound EDI
transactions, and then resubmit the corrected data for reprocessing by the particular workflow that generated
the error message.
Epicor ERP | 9.05.700 21

For example, if the demand contract number specified on the inbound EDI transaction is not valid for the trading
partner, or cannot be found in the Epicor application database, an Invalid Contract Task error message appears
when you use the Service Connect Task Monitor.
• This means that your customer trading partner has either sent you an incorrect demand contract number, or
a corresponding demand contract record with that identifier number does not exist in the Epicor application
database (that is, has not been entered into Demand Contract Entry for that customer trading partner).
• To correct this error condition, you can either manually enter a valid demand contract (using the contract
identification number on the inbound EDI transaction) into Demand Contract Entry, or use the Task Monitor
to correct the demand contract number on the inbound EDI transaction to match one that exists in the Epicor
application, and then re-submit it for processing using the EDI workflows. You can also abort further processing
of the inbound EDI transaction.
Automated and Manual Demand Entry Processing
Using the Customer Maintenance > Documents or Ship To > Documents sheets, you can create user-defined
rules that designate if inbound demand should be automatically or manually processed for specific types of
inbound EDI transactions. The precise timing and method used by the Epicor application is dependent on the
setting of the Accept Type field for the customer (or ship to customer) trading partner associated with the
inbound EDI transaction.
• If set to Always Accept, the Epicor application automatically processes demand for this customer trading
partner, regardless of whether there are failed validations/rejections in the inbound EDI document. It immediately
generates sales order and forecast entries at the time the inbound EDI file is successfully processed. In cases
where the inbound EDI transaction contains failed validations/rejections (for example, a Date Change
action request is received with insufficient lead time, and a Stop or Warning condition would normally be
applied), the Epicor application automatically overrides any System Rejection flags, processes the demand
and subsequent sales order and forecast entries despite the error condition.
• If set to Accept If No Errors, the Epicor application automatically processes demand and immediately
generates sales order and forecast entries for this customer trading partner, regardless only if there are no
failed validations/rejections in the inbound EDI document. It handles rejected demand records in the same
manner as the Always Accept selection.
• If set to Manually Accept, you must manually process incoming demand on inbound EDI transactions using
the Process selection in the Demand Header section in the Demand Entry Actions menu. Order releases and
forecast entries are only created at the time you perform this manual processing. Rejected demand records
must be manually resolved.
The resulting order releases can be viewed or edited in Sales Order Entry.
22 Epicor ERP | 9.05.700

Likewise, the resulting forecast transactions viewed or edited in Forecast Entry:
Epicor ERP | 9.05.700 23

Refer to Order Transactions Generated from Inbound EDI Demand and Forecast Transactions Generated
from Inbound EDI Demand for more details.
Generating Outbound EDI Transactions
The Epicor application uses report data definitions you define to generate the following types of outbound EDI
transactions:
• EDI 855/865/ORDRSP- Outbound Order Acknowledgements
• EDI 856/DESADV- Outbound Advance Shipping Notices
• EDI 810/INVOIC- Outbound Invoices
For example, the EDI 855/865/ORDRSP (Outbound Purchase Order or PO Change Acknowledgement) document
is an electronic version of a phone call or fax you use to inform customer trading partner who sent you a purchase
order that you are fulfilling the purchase order or change as requested.
• This informs them that you are filling the order and shipping the goods by the requested date, or are not able
to fulfill the entire order as requested, possibly due to stockouts or disagreement about the purchase terms.
• EDI 855/865/ORDRSP transactions are usually sent in response to EDI 850/ORDERS (Inbound Purchase Order)
or EDI 860/ORDCHG (Inbound Purchase Order Change) documents you receive from your customer trading
partner.
• If the Automatic check box has been selected for the Sales Order Acknowledgement document type in
the Outbound Document section of the Customer Maintenance > Documents or Ship To > Documents
sheets (for this customer or ship to trading partner), the Epicor application automatically produces this
24 Epicor ERP | 9.05.700

document record at the same time it generates sales order release for inbound EDI demand requests received
from this customer trading partner.
• To manually generate this document record, you use the Print Sales Order Acknowledgement selection
on the Sales Order Entry Actions menu.
The Epicor application utilizes the user-customized version of the standard EDIOrdAck report data definition (as
designated in Report Style Maintenance for the Sales Order Acknowledgement) to generate the outbound Order
Acknowledgement EDI 855 document that confirms that a sales order is in process.
• In essence, the Epicor application sends the Sales Order Acknowledgement report to your customer trading
partner. It also uses the same report data definition to produce Reponses to a Sales Order Change and Order
Status documents.
• Whether processed automatically or manually, the Epicor application uses the EDIOrdAck report data definition
to generate the following Sales Order Acknowledgement document record:
Epicor ERP | 9.05.700 25

It generates and stores this Sales Order Acknowledgement document record in the designated destination folder
for outbound EDI files (for example, c:\epicordata\edi_data\outbound\SOAck).
• Refer to the Customer Maintenance > Documents and Defining Outbound EDI Report Formats sections
for more details on setting generation parameters and customizing the format and contents of the supporting
report data definition.
• Once the Epicor application has deposited this file in the designated destination folder on your server, the
third party TIE KINETIX eVision software retrieves the outbound Sales Order Acknowledgement document
record and transmits it as an EDI 855/ORDRSP transaction to your customer trading partner.
The manner in which the outbound the Epicor application processes EDI 856/DESADV (Advanced Shipping
Notice) and EDI 810/INVOIC (Invoice) transactions is similar in manner to this example.
26 Epicor ERP | 9.05.700

EDI / Demand Management Technical Reference Guide Setup Components
Setup Components
EDI / Demand Management module processing in your Epicor application is highly automated, and once set up
properly, greatly reduces the amount of time required for your company to efficiently manage customer demand
requests and subsequent order fulfilment activities. However, a great deal of initial thought and careful setup is
required to install all required software components and define exactly how TIE KINETIX, Epicor ERP and optionally,
Service Connect interact with each other to automate demand management and order fulfilment.
These initial setup tasks include:
1. Using the companion EDI TIE KINETIX Integration Guide as a starting point for the installation,
configuration and integration of the Demand Management module, Epicor application and optionally, Epicor
Service Connect with Epicor's EDI solution of choice, TIE KINETIX eVision. Refer to the Prerequisite
Installation and Setup Tasks sections for complete details.
2. Using Company Configuration > Modules > Sales > Demand sheet, define the parameters that determine
how the Demand Management module should operate in a specified company, and the Modules > Materials
> Shipping/Receiving sheet to define the parameters that determine how Demand Management should
impact shipping and receiving activities in a specified company.
3. When using EDI to receive and send electronic transactions, customers are identified in inbound and outbound
EDI transactions by trading partner identification numbers. In the Epicor application, you assign and associate
trading partner identification numbers with specific customer records established in Customer Maintenance.
Refer to the Defining Trading Partners in Customer Maintenance section for complete details.
• Use the Customer > Demand sheet to assign a trading partner identification number and define demand
processing parameters for a specific customer. This includes specifying the lead times required to evaluate
and process certain types of action requests on incoming EDI shipping schedules received from your
customer.
• Use the Customer > Documents sheet to define the rules that specify acceptance and matching criteria
for demand transactions received on inbound EDI documents. This allows you to specify if demand on
inbound transactions should be automatically processed; if you elect to do this, the Epicor application
automatically generates order releases and forecast entries. You can also create user-defined rules that
specify how and when outbound EDI order acknowledgement, Advanced Shipping Notice and invoice
transactions should be generated.
• Use the Ship To > Demand sheet as needed to assign trading partner identification numbers and override
demand processing parameters for specific customer ship to locations using the Ship To > Demand sheet.
• If you have assigned trading partner identification numbers and override demand processing parameters
to specific customer ship to locations in the Ship To > Demand To sheet, use the Ship To > Documents
sheet in a manner similar to the Customer > Documents sheet.
4. Defining outbound EDI report formats by doing the following:

• Use Report Data Maintenance to create customized report data definition records the Epicor application
uses to generate outbound document records that are sent via EDI to your customer trading partners.
• Once you have duplicated an existing report data definition, and have modified the duplicated record
to your satisfaction, you then associate it with a specific type of document (for example, Packing Slips)
using Report Style Maintenance.
• Use the Business Activity Manager to enable auto-generation of outbound EDI files when triggered
by specific processing actions or events that take place in within the Epicor application and database.
Refer to the Defining Outbound EDI Report Formats section for complete details.
Epicor ERP | 9.05.700 27

Setup Components EDI / Demand Management Technical Reference Guide
Prerequisite Installation and Setup Tasks - Direct EDI Import
If you are using the Import EDI Demand Process to directly import inbound EDI transactions into the Epicor
application, you must perform the following installation and setup tasks. The following graphic illustrates the
steps involved in accomplishing these required tasks:
Note The companion EDI TIE KINETIX Integration Guide is intended as a starting point for the installation,
configuration and integration of the Demand Management module. The remaining part of EDI setup is
performed directly in Epicor ERP.
Tip The EDI TIE KINETIX Integration Guide document does not describe the installation of the actual TIE
KINETIX eVision software; TIE KINETIX provides their own documentation for this purpose. You can use
sections of the EDI TIE KINETIX Integration Guide to configure the Demand Management module even
if you have chosen a different EDI solution.
The tasks you perform with guidance from the EDI TIE KINETIX Integration Guide include:
28 Epicor ERP | 9.05.700

1. Verifying prerequisite installations, including:

• Verifying you have completed the TIE KINETIX Planning Documentation.
• Verifying that the TIE KINETIX consultant has properly configured and tested your system. Configurations
include:
• Microsoft Internet Information Service (IIS)
• ODBC Drivers
• eVision server
• communication interface
• eVision client / Integrator Translation software
2. Configuring your Epicor application server.
3. Configuring Demand Management for EDI inbound and outbound processing.
4. Performing post- installation steps, including reviewing EDI file layouts, configuring outbound EDI automatic
generation.
Epicor ERP | 9.05.700 29

Optional Installation and Setup Tasks - Epicor Service Connect
If you are using Service Connect in place of the direct EDI import process (Import EDI Demand), you must perform
the following installation and setup tasks.
These tasks are similar to those outlined in the Prerequisite Installation and Setup Tasks - Direct EDI Import topic,
but require that you perform additional setup tasks. The following graphic illustrates the steps involved in
accomplishing these required tasks:
Tip The companion EDI TIE KINETIX Integration Guide is intended as a starting point for the installation,
configuration and integration of the Demand Management module and Epicor Service Connect with
30 Epicor ERP | 9.05.700

Epicor's EDI solution of choice, TIE KINETIX eVision. The EDI TIE KINETIX Integration Guide document does
not describe the installation of the actual TIE KINETIX eVision software; TIE KINETIX provides their own
documentation for this purpose. You can use sections of the EDI TIE KINETIX Integration Guide to
configure the Demand Management module even if you have chosen a different EDI solution. The remaining
part of EDI setup is performed directly in Epicor ERP.
The tasks you perform with guidance from the EDI TIE KINETIX Integration Guide include:
1. Verifying prerequisite installations, including:

• Verifying you have completed the TIE KINETIX Planning Documentation.
• Verifying that the TIE KINETIX consultant has properly configured and tested your system. Configurations
include:
• Microsoft Internet Information Service (IIS)
• ODBC Drivers
• eVision server
• communication interface
• eVision client / Integrator
2. Verifying that Epicor Service Connect 9.0, including any upgrade patches, is installed on your system. The
Epicor Service Connect program sets up the virtual directories, such as VantageServices, which is required
during the EDI installation. For assistance, contact the Customer Solutions Group, or a similarly qualified
party, and refer to the Epicor Service Connect Installation Guide for instructions.
3. Verifying the Microsoft Web Services Enhancements (WSE) 3.0 is installed on your system. This application
is available for download from the Microsoft web site.
4. Configuring your Epicor application server, including configuration of IIS v6-compatibility and Application
Server roles.
5. Configuring .NET Epicor Client and .NET References Import for Demand Management.
6. Verifying that Service Connect is installed and input channels have been configured.
7. Configuring Service Connect EDI Workflow.
8. Testing system validation, including testing/troubleshooting .NET References, (optional) Web Services
connectivity and Service Connect Workflow.
9. Configuring Demand Management for EDI inbound and outbound processing.
10. Performing post- installation steps, including reviewing EDI file layouts, configuring outbound EDI automatic
generation.
Epicor ERP | 9.05.700 31

Company Configuration Maintenance
Use the Company Configuration > Modules > Sales > Demand sheet to define the parameters that determine
how the Demand Management module should operate in a specified company.
This includes specifying if unfirm and forecast schedules should be included in demand management lead time
checking logic for this company, and if scheduled matching should automatically be performed for all orders. It
also allows you to specify the default location of the direct EDI import folder used by the Import EDI Demand
Process for specific companies.
Programs and Their Modifiers
The following section describes the Company Configuration Maintenance values you can change.
Menu Path
Navigate to this program from the Main Menu:
• System Management > Company Maintenance > Company
Important This program is not available
®
in the Epicor Web Access™ interface. You can launch this program
from an Epicor Smart Client (Windows ) interface.
32 Epicor ERP | 9.05.700

Select the Modules sheet, select the Sales sheet, and then select the Demand sheet. These are the values you
can modify for the item:
• Automatically Match All - Specifies if the Demand Matching selection on the Demand Entry > Actions menu
should automatically match all new demand schedules and eligible sales order releases candidates in this
company.
• Select the check box if the Demand Matching selection should automatically match all new demand
schedules and candidates. In this case, the Epicor application runs it in the background as a continuing
process and automatically matches new demand schedules. This eliminates the need for a user to open
the Demand Matching program and having to click the Match All button.
• Clear the check box to skip automatic matching of all new demand schedules and candidates in this
company. In this case, the user must invoke the Demand Matching selection and perform matching, either
by manually selecting sales order releases and then clicking the Match button or automatically matching
all eligible sales order releases against demand schedules by clicking the Match All button.
• Check Forecast Schedules - Specifies if forecast schedules should be included in demand management lead
time checking logic for this company. Select this check box to include forecast schedules in demand
management lead time checking logic for this company. Clear the check box to exclude forecast schedules.
• Check Unfirm Schedules - Specifies if TIE KINETIX schedules should be included in demand management
lead time checking logic for this company. Select this check box to include TIE KINETIX schedules in demand
management lead time checking logic for this company. Clear the check box to exclude TIE KINETIX schedules.
An order release that you are considering to ship to your customer. Unfirm releases cannot be turned into
jobs.
Note Refer to the Customer > Demand Sheet topic in Defining Trading Partners in Customer
Maintenance for more information on the use and processing of dates included in inbound EDI
transactions.
• Cancel Schedules Action - Specifies if the Epicor application should automatically close or delete cancelled
demand schedules received from customer trading partners in this company. Select the action that should be
taken for cancelled demand schedules in this company.
• Close - The Epicor application should automatically close all cancelled demand schedules received from
customer trading partners in this company.
• Delete - The Epicor application should automatically delete all cancelled demand schedules received from
• Consider Working Days in the Delivery Days Calculation - The Delivery Days fields in the Customer
Maintenance > Customer > Demand and Ship To > Demand sheets can be used to specify the number of
days required to ship a part quantity from your manufacturing center to the final destination for a customer
trading partner (or ship to customer trading partner). The Epicor application uses this date interval as a buffer
to calculate Ship By Dates when you use the Need By date type (as specified in the Date Type field).
The manner in which the Epicor application uses the specified delivery days factor for the delivery date
calculation is dependent on the setting of the Consider Working Days in the Delivery Days Calculation
check box.
• If the Consider Working Days in the Delivery Days Calculation check box is selected, this factor
represents actual working days.
To calculate a Ship By date, the Epicor application subtracts this actual working days factor from the Need
By date designated in a demand schedule received from the customer trading partner, taking into
consideration any dates that are designated as non-working days in the associated plant calendar.
• If the Consider Working Days in the Delivery Days Calculation check box is cleared, this factor
represents delivery days.
Epicor ERP | 9.05.700 33

To calculate a Ship By date, the Epicor application subtracts this delivery days factor from the Need By date
designated in a demand schedule received from the ship to customer trading partner, and then determines
if the calculated Ship By date is a working day.
Note Refer to Defining Trading Partners in Customer Maintenance for examples of how Ship
By dates are calculated for demand schedules using actual working days and delivery days factors.
Import Folder - Specifies the default location of the direct EDI import folder used by the Import EDI Demand
Process. This is the path to the import folder where EDI process expects to find .app documents deposited
by the TIE KINETIX eVision third-party program.
Note The specified folder path must use UNC-naming conventions, not a locally-mapped drive letter.
Use the Company Configuration > Modules > Materials > Shipping/Receiving sheet (not pictured) to define
parameters that determine how the Demand Management module should impact shipping and receiving activities
in a specified company. To access this sheet, select the Modules sheet, select the Materials sheet, and then select
the Shipping/Receiving sheet. These are the values you can modify for the item:
• Allow Shipments for Orders on Hold- Specifies if the Epicor application should allow processing of shipments
for sales orders that have been placed on hold, either manually or when generated from demand contracts.
This affects shipment programs such as Customer Shipment Entry and Master Pack Shipment Entry throughout
the Epicor application. Select the check box to allow processing of shipments for sales orders that have been
placed on hold. Clear this check box to prevent processing of shipments for sales orders that have been placed
on hold.
34 Epicor ERP | 9.05.700

Customer Periodicity Maintenance
Use the Customer Periodicity Maintenance to define valid periodicity rules (if any) for a specific customer or
ship to customer trading partner.
Periodicity rules defines the regular intervals at which at which deliveries to the customer or ship to location take
place (daily, specific day of the week, weekly or monthly).
• The Epicor application uses these periodicity interval values during demand processing to calculate the Ship
By dates for shipping schedules that are required for each order release or forecast generated from inbound
EDI files for the customer trading partner or ship to location.
• Shipping schedules indicate how often a customer wishes to receive shipments from you.
When you define periodicity intervals, you first create the periodicity rules by first selecting the customer (and
optionally ship to identifier) and then defining the delivery interval rules used for this customer.
• While you can define multiple periodicity rules for a customer (for example, you could define Weekly Forward
and Monthly, you use the Periodicity field in the Customer Maintenance > Customer > Demand sheet to
select the specific periodicity rule that the demand schedule creation process uses for the customer trading
partner.
• A specific periodicity rule can also be selected for a specific ship to customer location in the Periodicity
field in the Customer Maintenance > Ship To > Demand sheet. This allows you to assign differing periodicity
rules based on the specific shipping location for the customer trading partner. For example, you may ship
ordered items bi-weekly to their West Coast plant location, but only ship weekly to their East Coast location.
• By selecting different periodicity rules, you can schedule order releases and forecasts based on the requirements
of the specific customer and/or ship to locations.
Epicor ERP | 9.05.700 35

To calculate Ship By dates for a demand schedule, the Epicor application first looks for a periodicity rule linked
to a customer or ship to location in the Periodicity field in the Customer Maintenance > Demand sheet, or the
Customer Maintenance > Ship To Demand sheet.
• It then uses the selected rule to calculate the Ship By Date on each demand record.
• However, if periodicity rules have not been assigned to the customer or ship to location, the Epicor application
calculates Ship By dates for shipping schedules for the customer trading partner or ship to location based on
the Need By dates specified in incoming EDI transactions, and the time factor specified in the Delivery Days
field in the Customer Maintenance > Demand sheet, or the Customer Maintenance > Ship To Demand sheet.
The following section describes the Customer Periodicity Maintenance values you can change.
Menu Path
• Sales Management > Demand Management > Setup > Customer Periodicity
For CRM users, the Main Menu appears as:
• Customer Relationship Management > Demand Management > Setup > Customer Periodicity
These are the values you can modify for the item:
• Customer - Specifies the identifier for the customer for whom the periodicity rule is being defined.
• You can enter this identifier directly or click Customer to access Customer Search to select the specific
customer. The specified customer must have been established in Customer Maintenance.
• The field to the right allows you to enter a ship to identification number for the customer. This allows you
to create periodicity rules for a specific ship to location. The specified ship to identifier must have been
established in the Customer Maintenance > Ship To sheet.
• Customer Name - Displays the name of the customer or ship to located associated with the customer and
ship to identifiers entered or selected in the Customer field.
• Description - The ID assigned by the user which makes this record unique for the customer. When a customer
is created a ShipTo record is automatically created by the system for that customer with a ShipToNum equal
to NULL.
• Daily, Rules - Daily periodicity designates that shipments are made to this customer every weekday (Monday
through Friday).
• Select this check box to use Daily periodicity rules when calculating shipping schedule dates for this
customer.
• If you select this check box, you can also use the Include Saturday and Sunday Shipments check box
to indicate that deliveries are also required to this customer on Saturdays and Sundays.
• Daily, Include Saturdays and Sunday Shipments - If you selected the Daily Rules check box, select this
check box to include Saturdays and Sundays in the delivery schedule for this customer, or clear it to exclude
Saturdays and Sundays deliveries for this customer.
• Monthly Forward, Rules - Monthly Forward periodicity designates that all shipments to this customer are
only sent once per month.
• Select this check box to use Monthly Forward periodicity rules when calculating shipping schedule dates
for this customer.
• If you select this check box, you can then use the First Ship Day field to specify the day of the week on
which shipments to this customer must arrive.
36 Epicor ERP | 9.05.700

To further define this shipment interval, you can use the Week Number in the Month field to indicate
the week during the month (1-5) on which shipments to this customer need to be sent.
• Monthly Forward, First Day Ship - If you selected the Monthly Forward Rules check box, select the day
of the week this shipment must arrive to this customer.
• Monthly Forward, Week Number in the Month - If you selected the Monthly Forward Rules check box,
select the week during the month (1-5) in which shipments are sent to the customer.
• Weekly Forward, Rules - Weekly Forward periodicity designates that all deliveries to this customer are only
sent once per week.
• Select this check box to use Weekly Forward periodicity rules when calculating shipping schedule dates
for this customer.
• Optionally, you can use the Ship Day field to specify the day of the week on which shipments must arrive
to this customer.
• Weekly Forward, Ship Day - If you selected the Weekly Forward Rules check box, select the day of the
week on which shipments must arrive to this customer.
• Nth Day of the Week, Rules - Nth Day of the Week periodicity designates that shipments to this customer
can only arrive on a specific work day.
• Select this check box to use Nth Day of the Week periodicity rules when calculating shipping schedule
dates for this customer.
• If you select this check box, you can use the Day of the Week Shipment field to specify the day of the
week on which shipments must arrive to this customer.
• Nth Day of the Week, Day of the Week Shipment - If you selected the Nth Day of the Week check box,
select the specific day of the week (Monday-Sunday) on which shipments must arrive to this customer.
Defining Trading Partners in Customer Maintenance
When using EDI to receive and send electronic transactions, customers are identified in inbound and outbound
EDI transactions by trading partner identification numbers. In the Epicor application, you assign and associate
trading partner identification numbers with specific customer records established in Customer Maintenance.
• Use the Customer > Demand sheet to assign a trading partner identification number and define demand
processing parameters for a specific customer.
This includes specifying the lead times required to evaluate and process certain types of action requests (adding
new demand schedule lines, changing or cancelling existing demand schedule lines) on incoming EDI shipping
schedules received from your customer. For each request, you specify the actions that should take place in
the Epicor application (stop transaction or display a warning message) when incoming EDI transactions are
received with insufficient lead times with respect the parameters you have specified for that type of transaction.
• Use the Customer > Documents sheet to define the processing parameters for inbound EDI documents you
accept from this customer trading partner when sent to you, and the outbound documents you generate and
then send back to the customer trading partner via EDI.
Note Be sure to fill in the Alternate Trading Partner field for all outbound document types with the
appropriate ID value for each trading partner. This this is used by the TIE KINETIX mapping tool to
identify which outbound map to use.
The Demand Management functionality uses these definitions when generating Electronic Data Interchange
(EDI) documents that create and track unfirm order releases, firm order releases, and/or forecasts.
Epicor ERP | 9.05.700 37

• Use the Ship To > Demand sheet as needed to assign trading partner identification numbers and override
demand processing parameters to specific customer ship to locations using the Ship To > Demand sheet.
For example, if Customer ABC has several locations, each generating their own shipping schedules, you can
assign alternate trading partner identification numbers and define specific demand processing parameters
for each individual location. The shipping lead time parameters for their East Coast location may differ
significantly than from those for their West Coast or overseas locations.
• If you have assigned trading partner identification numbers and override demand processing parameters to
specific customer ship to locations in the Ship To > Demand sheet, use the Ship To > Documents sheet in
a manner similar to the Customer > Documents sheet.
It allows you to define the processing parameters for inbound EDI documents you accept from specific ship
to locations for the customer trading partner when sent to you, and the outbound EDI documents you generate
and then send to the ship to locations for the customer trading partner. If the particular document definition
does not exist at the ship to level, the Epicor application uses the document definition defined at the customer
level in the Customer > Documents sheet.
Customer > Demand Sheet
Use the Customer > Demand sheet to assign a trading partner identification number and define demand
processing parameters that specify how the Epicor application should evaluate incoming EDI shipping transactions
received from your customer.
38 Epicor ERP | 9.05.700

The demand processing parameters you enter for your customer trading partner in this sheet include:
• Assigning a trading partner identification number.
• Defining demand processing parameters for a specific customer. This includes assign periodicity, delivery days
and date type parameters for used by the Epicor application for calculating Ship By or Need By dates for
demand schedules.
• Indicating how differences in unit price and part records and revision levels should be evaluated by the Epicor
application during demand processing.
• Specifying the lead times required to evaluate and process certain types of action requests (for example,
adding new demand schedule lines, changing or cancelling existing demand schedule lines) on incoming EDI
transactions received from this customer trading partner. For each type of action request, you specify the
actions that should take place in the Epicor application (stop transaction or process transaction and display a
warning message) when incoming EDI transactions are received with insufficient lead times with respect to
the parameters you have specified for that type of transaction.
• Entering lead time values used with firm shipping schedules. Each lead time value defines a date range during
which the Epicor application notifies you when various actions occur on a firm shipping schedule currently
linked to this customer record.
The following section describes the Customer Maintenance values you can change.
Menu Path
• Financial Management > Accounts Receivable > Setup > Customer
• Financial Management > Deferred Revenue Accounting > Setup > Customer
• Financial Management > Multi-Site > Setup > Customer
• Production Management > Material Requirements Planning > Setup > Customer
• Sales Management > Customer Relationship Management > Setup > Customer
• Sales Management > Demand Management > Setup > Customer
• Sales Management > EDI > Setup > Customer
• Sales Management > Order Management > Setup > Customer
• Sales Management > Quote Management > Setup > Customer
• Service Management > Field Service > Setup > Customer
• Customer Relationship Management > Sales and Marketing Management > Setup > Customer
• Customer Relationship Management > Demand Management > Setup > Customer
• Customer Relationship Management > EDI > Setup > Customer
• Customer Relationship Management > Order Management > Setup > Customer
• Customer Relationship Management > Quote Management > Setup > Customer
To create a new customer, select New Customer and enter customer information as needed into the Customer
> Detail sheet. To enter trading partner demand parameters for a new customer or for an existing customer,
access the Customer > Demand sheet by selecting the Customer sheet, and then select the Demand sheet. These
are the values you can modify for the sheet:
• Trading Partner - Specifies the unique trading partner identifier for this customer. It is a universal code
required on EDI transactions that uniquely identifies the business entity. The trading partner identifier must
Epicor ERP | 9.05.700 39

be entered in this field exactly as it will appear in inbound EDI files received from this customer trading partner.
This identifier is used to validate EDI documents sent and received between your company and this customer
trading partner.
• Delivery Days - Specifies the number of days required to ship a part quantity from your manufacturing center
to this customer trading partner. The Epicor application uses this date interval as a buffer when calculating
Ship By dates when you have specified that you use the Need By date type in the Date Type field.
The manner in which the Epicor application uses the specified delivery days factor for the delivery date
calculation is dependent on the setting of the Consider Working Days ship to customer trading partner
Calculation check box for the associated company in the Company Configuration > Modules > Sales >
Demand sheet.
• If the Consider Working Days ship to customer trading partner Calculation check box has been
selected, this factor represents actual working days. To calculate a Ship By date, the Epicor application
subtracts this factor from the Need By date designated in a demand schedule received from the customer
trading partner, taking into consideration any dates that are designated as non-working days in the
associated plant calendar.
Note For this scenario, the Epicor application performs the following calculations:
• The associated plant calendar is configured for a standard Monday through Friday work schedule.
• The Delivery Days field is set to 5 for this customer trading partner.
• When a demand schedule is received from this customer trading partner with a Need By date of
11/17/11 (a Thursday), the Epicor application subtracts five actual working days to calculate
a Ship By date of 11/10/11 (a Thursday) when generating shipping schedules (demand entries)
for this customer trading partner.
• It calculates this Ship By date because Saturday 11/12 and Sunday 11/13 are both designated as
non-working days in the plant calendar.
• If the Consider Working Days ship to customer trading partner Calculation check box has been
cleared, this factor represents delivery days. To calculate a Ship By date, the Epicor application subtracts
this factor from the Need By date designated in a demand schedule received from the customer trading
partner, and then determines if the calculated Ship By date is a working day.
• The Delivery Days field is set to 5 for this customer trading partner.
• When a demand schedule is received from this customer trading partner with a Need By date of
11/17/11 (a Thursday), the Epicor application subtracts five delivery days to calculate a Ship
By date of 11/12/11 (a Saturday). However, since Saturday is a non-working day in the plant
calendar, it sets the final Ship By Date to 11/11/2011 (a Friday).
Tip If this customer trading partner also uses periodicity rules, and you specify a periodicity interval in
the Periodicity field, the Ship By date is further adjusted to match the shipping frequency set up within
the periodicity rule selected in the Periodicity field. For example, if an Nth Day of the Month periodicity
rule has been specified in the Periodicity field, and the periodicity rule (as defined in Customer Periodicity
Maintenance) has the 25th as the day of the month, a Ship By date of July 25 would be calculated
when generating shipping schedules.
• Periodicity - Specifies the periodicity interval for this customer trading partner. This designates how often
this customer trading partner wishes to receive shipments from you.
• Periodicity rules define the intervals for the deliveries (daily, weekly, specific day of the week, or monthly)
being used to calculate shipping schedules for this customer trading partner from inbound EDI transactions.
40 Epicor ERP | 9.05.700

• Select the specific periodicity rule that applies to this customer, or select Not Used if periodicity rules are
not being used to calculate Ship By dates for this customer trading partner. All periodicity intervals (or
rules) that have been previously defined in Customer Periodicity Maintenance for the current customer
trading partner appear on this list.
• If you select Not Used, the Epicor application calculates Ship By dates for shipping schedules for the
customer trading partner based on the Need By dates specified in incoming EDI transactions, and the time
factor specified in the Delivery Days field.
• Date Type - Specifies the default calculation method being used by the Epicor application to generate Need
By and Ship By dates on each order release schedule for this customer trading partner.
• Shipping - Creates Ship By Dates; these are the dates by which parts must be shipped in order to arrive
on the required (Need By) dates specified on shipping schedules generated from demand entries that have
been manually entered into Demand Entry.
• Need By - Creates Need By Dates; these are the dates on which the customer trading partner requires
the part quantities.
Selecting this option causes the Epicor application to subtract the delivery days factor specified in the
Delivery Days field from each Need By date to calculate the Ship By date on each release. If this customer
trading partner also uses periodicity rules, the Ship By date is further adjusted to match the shipping
frequency set up within the periodicity rule selected in the Periodicity field.
Example If the Date Type field is set to Need By, this trading partner needs parts on an order
release delivered to them by August 1 and you have specified 5 in the Delivery Date field, the
Epicor application subtracts five days from the August 1 Need By date to calculate a Ship By date
of July 27 when generating shipping schedules (demand entries) from inbound EDI transactions
received from this customer trading partner.
However, if an Nth Day of the Month periodicity rule has been specified in the Periodicity field, and
the periodicity rule (as defined in Customer Periodicity Maintenance) has the 25th as the day of the month,
a Ship By date of July 25 would be calculated when generating shipping schedules.
• Pricing - Specifies if internal or customer pricing should be used for demand entries generated from inbound
EDI transactions received from this customer trading partner. This becomes the default for this customer
trading partner in the Pricing field in the Demand Contract Entry > Line > Detail sheet and can be overridden
for specific demand contract lines.
• Customer Pricing - The customer price that appears on the inbound EDI document should be used to
populate the EDIUnitPrice field in the Demand_Detail file. In this scenario, the Epicor application uses the
customer price on demand entries (and sales order lines generated from the demand entries) generated
from demand contract lines for this customer trading partner.
Refer to Appendix A: Demand Management / Order Management Pricing Flowchart for a graphical
decision and processing flowchart for Demand Management pricing,
• Internal Pricing - The internal price calculated within the Epicor application should be used to populate
the EDIUnitPrice field in the Demand_Detail file. In this scenario, the Epicor application uses the internal
price on demand entries (and sales order lines generated from the demand entries) generated from demand
contract lines for this customer trading partner.
• Locked Demand Contract Pricing - Pricing determined manually on a demand contract can be used
instead of Customer or Internal Pricing
• Hold Orders for Review - Specifies if the Epicor application should place sales orders created for this customer
trading partner from demand contracts in Demand Entry on hold for review before being released for shipping.
• Select the check box to place sales orders created in Demand Entry for this customer trading partner on
hold for review.
Epicor ERP | 9.05.700 41

• Clear the check box to skip placing of sales orders on hold for this customer trading partner before they
are released for shipment.
The setting in this check box becomes the default value for the Hold Orders for Review check box in the
Demand Contact Entry Header and Summary sheets and can be overridden for individual demand contracts.
• The Epicor application places demand entries created against the demand contract on hold based on the
setting in the demand contract itself, not based on the Hold Orders for Review setting specified for
the customer trading partner in the Customer Maintenance > Customer > Demand sheet.
• An order placed on hold must usually be released before it can be shipped to the customer trading partner
using Customer Shipment Entry or Master Pack Shipment Entry.
• Close Rejected Schedules - Specifies if rejected demand schedules for this customer trading partner should
automatically be closed when you run the Process Demands selection (on the Actions menu in Demand Entry
or Demand Mass Review).
• Select the check box to automatically close demand schedules that have been rejected for this customer
trading partner.
• Clear the check box to skip automatic closure of rejected demand schedules for this customer trading
partner.
Important Care should be taken when you set this control. If you select the check box, the Epicor
application automatically closes rejected demand schedules received from this customer trading partner.
By clearing the check box, you can first review the reasons for rejection of a demand schedule, enter manual
adjustments as needed in Demand Entry, or simply close the demand schedule. For example, if a demand
schedule has been rejected because it contains a shipping date just outside of an allowable lead time, the
shipping date could be adjusted in Demand Entry, allowing the previously rejected demand schedule to be
processed into a sales order or forecast.
• Cancel Non Matched - Specifies if the Epicor application should automatically cancel all sales releases for
this customer trading partner that have not been matched by the Demand Schedule Matching process (located
on the Demand Schedule section of the Demand Entry Actions menu). This sets the default for the Cancel
Non Matched field in the Demand Contract Entry > Header > Matching sheet for this customer trading
partner; this can be overridden for specific demand contracts.
• Select the check box if the Epicor application should automatically cancel all sales releases for this customer
trading partner that have not been matched by the Demand Schedule Matching process.
• Clear the check box if the Epicor application should not automatically cancel all sales releases for this
customer trading partner that have not been matched by the Demand Schedule Matching process.
Refer to the Header > Matching Sheet section in Entering Demand Contracts for more information on
how the Demand Schedule Matching process matches update requests on inbound EDI transactions to existing
demand schedules and order releases.
• Unit Price Difference - Specifies if the Epicor application should validate if there is a difference between the
current unit price in your Epicor application database and the unit price in an incoming EDI file received from
this customer trading partner.
Example You receive an inbound EDI file from this trading partner, requesting you ship 100 units of
a widget at a unit price of $1.90. However, your current unit price in the Epicor application is set at
$2.00.
Using the Unit Price Difference check box, you can choose to perform this unit price validation for this
customer trading partner, or skip the validation.
• Select the check box if the Epicor application should perform this validation when you run the Process
Demands selection (on the Actions menu in Demand Entry). If you select this check box, use the associated
42 Epicor ERP | 9.05.700

Action field to specify how the Epicor application should process demand schedules when unit price
validations fail.
• Clear the check box to skip this validation when importing part demand from this customer trading partner.
• Tolerance - If the Unit Price Difference check box has been selected, specify the allowable price difference
tolerance percentage, if any. For example, enter 10.50 into this field for a 10.5% tolerance.
$2.00. If you set the Tolerance field to 10.00, the Epicor application would accept a unit price minus
10% of the internal price. In this example, it would consider $1.90 as an acceptable price, because
would be within 10% of the $2.00 internal price. Conversely, it would not consider $1.75 or $1.50
acceptable prices, because they are outside of the 10% tolerance range (from $1.80 to $2.00).
• Action (Unit Price Difference) - If the Unit Price Difference check box has been selected, specify the action
that should take place (when you run the Process Demands selection on the Demand Entry Actions menu) if
there is a difference between the current unit price in your Epicor application database and the unit price in
an incoming EDI file received from this customer trading partner:
• Stop - Designates that inbound demand received from this customer trading partner should not be
accepted and processed if there is a difference between the current unit price in your Epicor application
database and the unit price in the inbound EDI file.
The Epicor application marks the demand line as System Rejected in Demand Entry; however, you can
manually accept the incoming demand by selecting the Override System Reject check box if you wish.
This allows you to designate that the demand schedule/line/demand header can be processed to generate
an order or forecast in the Epicor application. Error messages appear on the Demand Log (on the Demand
Entry Actions menu) or on the Demand Review Report, explaining why the Epicor application rejected and
did not process the demand.
• Warning - Designates that inbound demand received from this customer trading partner should be
automatically accepted and processed even if there is a difference between the current unit price in your
Epicor application database and the unit price in the inbound EDI file. Warning messages display on the
Demand Log or on the Demand Review Report informing you that the incoming demand contains differences
in unit pricing from your current price.
• Check For Part - Specifies if the Epicor application should validate if corresponding part records exist in your
Epicor application database for inbound demand received from this customer trading partner. Using the Check
For Part check box, you can choose to perform this part number validation for this customer trading partner,
or skip the validation.
Refer to Appendix B: Demand Management Part Validation Processing Flowchart for a graphical
decision and processing flowchart for part validation processing in Demand Management.
• Select the check box if the Epicor application should perform this validation. If you select this check box,
use the associated Action field to specify how the Epicor application should process demand schedules
when part number validations fail. By performing this validation, it helps to ensure that the Epicor application
is not accepted invalid part numbers on inbound EDI transactions received from this customer trading
partner.
• If you clear the check box, all parts listed on an incoming shipping schedule are automatically included on
the shipping schedule. This lets you generate demand suggestions for parts that are "on the fly." However,
by skipping this validation, you cannot ensure that invalid part numbers on inbound EDI transactions are
not being accepted from this customer trading partner.
Epicor ERP | 9.05.700 43

• Action (Check For Part) - If the Check For Part check box has been selected, specify the action that should
take place (when you run the Process Demands selection on the Demand Entry Actions menu) if a part record
does not exist in your database for inbound demand received from this customer trading partner:
accepted and processed if it contains a part number for which a corresponding part record does not exist
within your Epicor application database.
The Epicor application marks the demand record as System Rejected in Demand Entry; however, you
can manually accept the incoming demand by selecting the Override System Reject check box if you
wish. This allows you to designate that schedule/line/demand header can be processed to generate an
order or forecast in the Epicor application. Error messages appear on the Demand Log (on the Demand
automatically accepted and processed even if it contains a part number for which a corresponding part
record does not exist within your Epicor application database. Warning messages display on the Demand
Log or on the Demand Review Report informing you that the incoming demand contains a part number
for which a corresponding part record does not exist within your Epicor application database.
• Check For Revision Level - Designates if the Epicor application should validate if a corresponding part revision
level exists in your database for inbound demand received from this customer trading partner.
Example You receive an inbound EDI file from this trading partner that contains a part number with
a revision level that not exist within your Epicor application database. Using the Check For Revision
Level check box, you can choose to perform this revision level validation for this customer trading
partner, or skip the validation.
• Select the check box if the Epicor application should perform this validation, or clear the check box to skip
this validation when inbound demand is processed for this customer trading partner. If you choose to
perform the validation, you use the corresponding Action field to designate how the Epicor application
should operate if the revision level validation fails.
• If you clear the check box, all parts listed on an incoming shipping schedule are automatically included on
the shipping schedule, regardless of the stated revision level.
• Action (Check For Revision Level) - If the Check For Revision check box has been selected, specify the
action that should take place (when you run the Process Demands selection on the Demand Entry Actions
menu) if the corresponding part revision does not exist in your database for inbound demand received from
this customer trading partner:
accepted and processed if the corresponding part revision does not exist in your Epicor application database.
The Epicor application marks the demand line as System Rejected in Demand Entry; however, you can
manually accept the incoming demand by selecting the Override System Reject check box if you wish.
This allows you to designate that the demand schedule/line/demand header can be processed to generate
an order or forecast in the Epicor application. Error messages appear on the Demand Log (on the Demand
automatically accepted and processed even if the corresponding part revision does not exist in your Epicor
application database. Warning messages display on the Demand Log or on the Demand Review Report
informing you that the incoming demand contains a part revision that does not exist in your database.
44 Epicor ERP | 9.05.700

• Check Partial Shipments - Designates if the Epicor application should match demand entries generated
from incoming EDI transaction files against sales order releases with partial shipments for this customer trading
partner.
• Select the check box if the Epicor application should perform this validation. If you choose to perform the
validation, you use the corresponding Action field to designate how the Epicor application should operate
if the partial shipment validation fails.
• Clear the check box to skip this validation. If you clear the check box, all demand schedule entries matched
against sales order releases (with partial shipments) for this customer trading partner are automatically
included on the shipping schedule.
• Action (Check Partial Shipments) - If the Check Partial Shipments check box has been selected, specify
the action that should take place (when you run the Process Demands selection on the Demand Entry Actions
menu) when demand schedule entries are matched against sales order releases with partial shipments for this
customer trading partner.
accepted and processed if demand schedule entries have been matched against sales order releases with
partial shipments.
wish. This allows you to designate that the demand schedule/line/demand header can be processed to
generate an order or forecast in the Epicor application. Error messages appear on the Demand Log (on
the Demand Entry Actions menu) or on the Demand Review Report, explaining why the Epicor application
rejected and did not process the demand.
automatically accepted and processed even if demand schedule entries have been matched against sales
order releases with partial shipments. Warning messages display on the Demand Log or on the Demand
Review Report informing you that the incoming demand has been matched against sales order releases
with partial shipments.
• Cumulative Check Discrepancies - Designates if the Epicor application should check for differences in
cumulative quantities between your Epicor application database and the cumulative quantities in the inbound
demand EDI transactions received from this customer trading partner.
validation, you use the corresponding Action field to designate how the Epicor application should operate
if the cumulative quantity validation fails.
• Clear the check box to skip this validation.
• Action (Cumulative Check Discrepancies) - If the Cumulative Check Discrepancies check box has been
selected, specify the action that should take place if there are differences in cumulative quantities between
your Epicor application database and the cumulative quantities in the inbound demand EDI transactions
received from this customer trading partner.
accepted and processed if differences in cumulative quantities exist between your Epicor application
database and inbound demand received from this customer trading partner.
Epicor ERP | 9.05.700 45

automatically accepted and processed even if differences in cumulative quantities exist between your
Epicor application database and inbound demand received from this customer trading partner. Warning
messages display on the Demand Log or on the Demand Review Report informing you that the incoming
demand has been matched against sales order releases with partial shipments.
• Configure First Time Only - A Smart String is a string of characters received from a customer trading partner
that configuration routines in the Epicor application are able to convert into the inputs required to configure
a part. Refer to the Configurator Technical Reference Guide for more details.
Select the check box if Smart Strings received on incoming EDI transaction for this customer should be processed
only when a new inbound transaction is first received. After it the Smart String has been processed and saved,
the Epicor application ignores any subsequent retransmission of the Smart String on subsequent inbound EDI
transactions. Clear the check box if the Epicor application should process Smart Strings whenever they are
received from the customer trading partner.
• Check Configuration Values - Specifies if configuration input values required for a configured part should
be validated in the Epicor application when received on incoming EDI transactions from this customer trading
partner. Select the check box if configuration input values required for a configured part should be validated
in the Epicor application. It performs validations that also ensure that required input values are not missing
in the EDI transaction. Clear the check box if configuration input values required for a configured part should
not be validated in the Epicor application.
• Action (Check Configuration Values) - If the Check Configuration Values check box has been selected,
specify the action that should be taken by the Epicor application when the configuration input values required
for a configured part are not valid (or missing) on EDI transactions received from this customer trading partner.
• Stop - Designates that EDI transactions received from this customer trading partner that contain invalid
(or missing) configuration input values for a configured part should should not be automatically accepted
by the Epicor application.
wish. This allows you to designate that the ED transaction can be processed in the Epicor application. Error
messages appear on the Demand Log (on the Demand Entry Actions menu) or on the Demand Review
Report, explaining why the Epicor application rejected and did not process the demand.
• Warning - Designates that EDI transactions received from this customer trading partner that contain
invalid (or missing) configuration input values for a configured part should should be accepted by the
Epicor application. It does not reject EDI transactions that meet these processing conditions but generates
a message that appears on the Demand Log.
• Add - Specifies the minimum number of days (ahead of the planned Ship By or Need By date) by which the
Epicor application should accept requests to add a new demand schedule from this customer trading partner.
You use this in conjunction with the associated Action field to specify how the Epicor application should
process demand schedule quantity change requests from your customer trading partner when received with
insufficient lead time notification.
Example The Add field is set to five days for Company ABC. They send you a request to add a new
demand schedule that they would like shipped only four days from now. Because the demand schedule
46 Epicor ERP | 9.05.700

change request was received with insufficient lead time notification, a Stop or Warning takes place,
depending on the setting of the Action (Add) field.
• Action (Add) - If this customer trading partner sends a request to add a new demand schedule, but with
insufficient lead time notification (based on the lead time factor defined in the Add field), specify the action
that should take place when you run the Process Demands selection on the Demand Entry Actions menu.
• Stop - Designates that requests to add new demand schedules that are received from this customer trading
partner with insufficient lead time notification should not be accepted and processed.
• Warning - Designates that requests to add new demand schedules that are received from this customer
trading partner with insufficient lead time notification should be automatically accepted and processed.
Warning messages display on the Demand Log or on the Demand Review Report informing you that the
request to add new demand schedules has been processed even though it was received from this customer
trading partner with insufficient lead time notification.
• Change - Specifies the minimum number of days ahead of (ahead of the planned Ship By or Need By date)
by which the Epicor application should accept change requests for a demand schedule from this customer
trading partner. You use this in conjunction with the associated Action field to specify how the Epicor
application should process demand schedule quantity change requests from your customer trading partner
when received with insufficient lead time notification.
Example The Change field is set to five days for Company ABC. They send you a change request for
a demand schedule that is being shipping four days from now. Because the demand schedule change
request was received with insufficient lead time notification, a Stop or Warning takes place, depending
on the setting of the Action (Change) field.
• Action (Change) - If this customer trading partner sends a change request for a demand schedule, but with
insufficient lead time notification (based on the lead time factor defined in the Change field), specify the
action that should take place when you run the Process Demands selection on the Demand Entry Actions
menu.
• Stop - Designates that demand schedule change requests received from this customer trading partner
with insufficient lead time notification should not be accepted and processed.
• Warning - Designates that demand schedule change requests received from this customer trading partner
with insufficient lead time notification should be automatically accepted and processed. Warning messages
display on the Demand Log or on the Demand Review Report informing you that the demand schedule
change request has been processed even though it was received from this customer trading partner with
Tip This setting does not apply to demand schedule quantity or date changes - refer to the Date
Change, Quantity Change and associated Action fields for details on how the Epicor application
manages these types of demand schedule changes.
Epicor ERP | 9.05.700 47

• Cancel - Specifies the minimum number of days (ahead of the planned Ship By or Need By date) by which
the Epicor application should accept cancellation requests for a demand schedule from this customer trading
partner. You use this in conjunction with the associated Action field to specify how the Epicor application
should process cancellation requests from your customer trading partner when received with insufficient lead
time notification.
Example The Cancel field is set to five days for Company ABC. They send you a cancellation request
for a demand schedule that is being shipping four days from now. Because the demand schedule
cancellation request was received with insufficient lead time notification, a Stop or Warning takes place,
depending on the setting of the Action (Cancel) field.
• Action (Cancel) - If this customer trading partner sends a demand schedule cancellation request, but with
insufficient lead time notification (based on the lead time factor defined in the Cancel field), specify the action
• Stop - Designates that demand schedule cancellation requests received from this customer trading partner
• Warning - Designates that demand schedule cancellation requests received from this customer trading
partner with insufficient lead time notification should be automatically accepted and processed. Warning
messages display on the Demand Log or on the Demand Review Report informing you that the demand
schedule cancellation request has been processed even though it was received from this customer trading
partner with insufficient lead time notification.
• New Line - Specifies the minimum number of days (ahead of the planned Ship By or Need By date) by which
the Epicor application should accept a request to add a new order line to a demand order from this customer
trading partner. You use this in conjunction with the associated Action field to specify how the Epicor
application should process requests to add a new line to a demand schedule when received from your customer
Example The New Line field is set to five days for Company ABC. They send you a request to add a
new line to a demand schedule that is being shipping four days from now. Because the request was
received with insufficient lead time notification, a Stop or Warning takes place, depending on the setting
of the Action (New Line) field.
• Action (New Line) - If this customer trading partner sends a request to add a new line to an existing demand
schedule, but with insufficient lead time notification (based on the lead time factor defined in the New Line
field), specify the action that should take place when you run the Process Demands selection on the Demand
Entry Actions menu.
• Stop - Designates that requests to add new lines to demand schedules received from this customer trading
generate an order or forecast. Error messages appear on the Demand Log (on the Demand Entry Actions
menu) or on the Demand Review Report, explaining why the Epicor application rejected and did not process
the demand.
• Warning - Designates that new demand schedule line addition requests received from this customer
48 Epicor ERP | 9.05.700

Warning messages display on the Demand Log or the Demand Review Report informing you that a request
that add new demand schedule lines has been processed even though it was received from this customer
• Quantity Change - Specifies the minimum number of days ahead of (ahead of the planned Ship By or Need
By date) by which the Epicor application should accept quantity change requests for a demand schedule from
this customer trading partner. You use this in conjunction with the associated Action field to specify how
the Epicor application should process demand schedule quantity change requests from your customer trading
partner when received with insufficient lead time notification.
Example The Quantity Change field is set to five days for Company ABC. They send you a quantity
change request for a demand schedule that is being shipping four days from now. Because the demand
schedule quantity change request was received with insufficient lead time notification, a Stop or Warning
takes place, depending on the setting of the Action (Quantity Change) field.
• Action (Quantity Change) - If this customer trading partner sends a quantity change request for a demand
schedule, but with insufficient lead time notification (based on the lead time factor defined in the Quantity
Change field), specify the action that should take place when you run the Process Demands selection on the
Demand Entry Actions menu.
• Stop - Designates that demand schedule quantity change requests received from this customer trading
• Warning - Designates that demand schedule quantity change requests received from this customer trading
schedule quantity change request has been processed even though it was received from this customer
• Date Change - Specifies the minimum number of days ahead of (ahead of the planned Ship By or Need By
date) by which the Epicor application should accept Ship By or Need By date change requests for a demand
schedule from this customer trading partner. You use this in conjunction with the associated Action field to
specify how the Epicor application should process date change requests from your customer trading partner
when received with insufficient lead time notification.
Example The Date Change field is set to five days for Company ABC. They send you a Ship By date
change request for a demand schedule that is being shipping four days from now. Because the demand
schedule date change request was received with insufficient lead time notification, a Stop or Warning
takes place, depending on the setting of the Action (Date Change) field.
• Action (Date Change) - If this customer trading partner sends a Ship By or Need By date change request for
a demand schedule, but with insufficient lead time notification (based on the lead time factor defined in the
Date Change field), specify the action that should take place when you run the Process Demands selection
on the Demand Entry Actions menu.
• Stop - Designates that demand schedule date change requests received from this customer trading partner
Epicor ERP | 9.05.700 49

• Warning - Designates that demand schedule date change requests received from this customer trading
schedule date change request has been processed even though it was received from this customer trading
• Capable to Promise Check Date - Specifies if the Demand Process procedure should execute Capable to
Promise processing for demand orders for this customer trading partner. Select the check box if the Demand
Process procedure should execute Capable to Promise processing for demand orders received from this
You use the accompanying field next to this checkbox to specify the exact type of dates (Ship By, Need By,
or Both) that should be validated. If the Check Date check box has been selected, use this field to specify
whether Need By, Ship By dates (or both) should be validated by the Demand Process procedure when it
performs CTP processing for demand orders for this customer trading partner.
• Ship By -- The Demand Process procedure validates Ship By dates in CTP processing. The Ship By date is
the date by which items should be shipped to arrive in time to meet the Need By date specified by the
When the Demand Process procedure runs, it compares the actual Ship By date on the demand schedule
to the calculated CTP Ship By date. If the calculated CTP Ship By date is later than the demand schedule
Need by date, the Epicor application performs the action (Stop or Warning) specified in the Action field.
• Both -- The Demand Process procedure validates Need By dates in CTP processing. The Need By date is
the date by which the customer trading partner requires delivery of part quantities.
When the Demand Process procedure runs, it compares the actual Need By date on the demand schedule
to the calculated CTP Need By date. If the calculated CTP Need by date is later than the demand schedule
Need by date, the Epicor application performs the action (Stop or Warning) specified in the Action field.
• Need By -- The Demand Process procedure validates both Ship By and Need By dates in CTP processing.
When the Demand Process procedure runs, it compares the actual Ship By and Need By dates on the
demand schedule to the calculated CTP Ship By and Need By dates. If both the calculated CTP Ship By
and Need By dates are later than the demand schedule Ship By and Need By dates, the Epicor application
performs the action (Stop or Warning) specified in the Action field.
• Action (Check Date) - If the Check Date check box has been selected, specify the action that should be
taken by the Epicor application when the designated CTP dates calculated by the Process Demand procedure
are later than the corresponding (Ship By or Need By) dates on demand schedules for this customer trading
partner.
• Stop - Designates the demand schedules that contain (Ship By or Need By) dates that are earlier than the
(Ship By or Need By) CTP dates calculated by the Process Demand procedure should not be automatically
accepted by the Epicor application.
• Warning - Designates the demand schedules that contain (Ship By or Need By) dates that are earlier than
the (Ship By or Need By) CTP dates calculated by the Process Demand procedure should be accepted by
the Epicor application. It does not reject the demand schedules that meet these processing conditions but
generates a message that appears on the Demand Log.
• Action (Update Date) - Specifies if the CTP dates calculated by the Demand Process procedure should replace
the Need By or Ship By dates on demand schedules for this customer trading partner. Select the check box if
the Demand Process procedure should replace the Need By or Ship By dates on demand schedules for this
customer trading partner. You use the accompanying field next to this checkbox to specify the exact type of
dates (Ship By, Need By, or Both) that should be updated.
50 Epicor ERP | 9.05.700

If the Update Dates check box has been selected, use this field to specify whether the Demand Process
procedure should update Need By, Ship By dates (or both) in demand schedules with calculated CTP dates
by when it performs CTP processing for demand orders for this customer trading partner.
• Ship By -- The Demand Process procedure should update Ship By dates in demand schedules with calculated
CTP Ship By dates. The Ship By date is the date by which items should be shipped to arrive in time to meet
the Need By date specified by the customer trading partner.
• Need By -- The Demand Process procedure should update Need By dates in demand schedules with
calculated CTP Ship By dates. The Need By date is the date by which the customer trading partner requires
delivery of part quantities.
• Both -- The Demand Process procedure should update Ship By and Need By dates in demand schedules
with calculated CTP Ship By and CTP Need By dates.
• Split Demand - Specifies if a demand schedule should be split when Capable To Promise (CTP) functions
indicate that there is not enough stock on hand for a part to satisfy demand. Select the check box if a demand
schedule should be split under these conditions. Clear the check box if a demand schedule should be not be
split under these conditions.
• Confirm - Specifies if purchase orders, PO suggestions or jobs linked to sales order releases should be confirmed
during CTP processing for this customer trading partner. Select the check box if purchase orders, PO suggestions
or jobs linked to sales order releases should be confirmed during CTP processing for this customer trading
partner. If the demand is for stockable items, the Confirm action also reserves stock for the demand so it
cannot be used for other order demand.
Epicor ERP | 9.05.700 51

Documents Sheet
Use the Documents sheet to define the processing parameters for inbound EDI documents you accept from this
customer trading partner when sent to you, and the outbound EDI documents you generate and then send back
to the customer trading partner.
The Demand Management functionality in the Epicor application uses these definitions to recognize the specific
Electronic Data Interchange (EDI) documents (such as Advanced Shipping Notices, sales order acknowledgements,
invoices) that are generated in the Epicor application. The document processing parameters you enter for your
customer trading partner in this sheet include:
• Assigning a unique identification number to the document.
• Specifying the type of document (for example, forecast, unfirm release, ASN, invoice) being defined.
• Specifying the Map ID number and whether this is an inbound document you receive from this customer
trading partner, or is an outbound document you send to this customer trading partner. If it is an outbound
document, you can specify if the Epicor application should automatically generate a document record that is
deposited in a destination folder (for transmission to the customer trading partner via EDI) with no manual
intervention required on the part of a user.
• Specifying the part hierarchy that the Epicor application should use to validate internal part, customer part,
manufacturer part, EAN, GTIN or UPC codes on the inbound demand document when received from this
Note Refer to Appendix C: Part Lookup and UOM Determination Flowchart for a graphical
flowchart of this process.
52 Epicor ERP | 9.05.700

• Specifying how incoming demand transactions for the document will be processed (Always Accept, Accept
If No Errors, Manually Accept).
• Identifying an alternate trading partner ID (if any) being used for the document.
The following section describes the Customer Maintenance values you can change.
To access the Documents sheet and create a new document for a customer trading partner, select New Customer
Document. These are the values you can modify for the sheet:
• Document - Specifies the identification number or name for this document. This is the number direct EDI
import process or optionally, Service Connect references when it retrieves this inbound EDI document from,
or sends to this outbound document through TIE KINETIX or another EDI application. This value should be
unique per trading partner.
Tip For inbound Forecast, Unfirm Release and Incoming Shipping documents, the entry in this field
must be the agreed upon document identifier used by both you and your customer trading partner for
this particular document. For example, your customer trading partner may refer to an incoming shipping
schedule as an ISS or a FIRM document on an inbound EDI transaction. You must enter the agreed
upon value (or identifier), or the value you decide to use in your TIE KINETIX mappings, in this field.
• Test Record - This check box is only used for custom programming. When selected, the data for this document
will not interact with your customer trading partner's data. This feature lets you test the document to ensure
it works with your custom program. Normally, you should leave this check box cleared.
• Type - Specifies the type of inbound/outbound document being defined. For inbound documents, it also
indicates the type of demand suggestion that the Epicor application will generate for the document. Select
the type that applies to this document. Note that there can only be one document per document type per
• Forecast - This inbound document allows you to receive projected quantities of parts from this customer
trading partner. You then review and accept/reject these forecasts using Demand Entry; when accepted,
the Epicor application creates forecast records in Forecast Entry. A forecast is a projected quantity of parts
needed to satisfy demand. They are first calculated by part, then by customer, and are used by the MRP
module to anticipate the demand from your customers.
• Unfirm Releases - This inbound document allows you to receive potential, or unfirm, order releases
from this customer trading partner. You then review and accept/reject these unfirm releases using Demand
Entry.
• Incoming Shipping Schedule - This inbound document allows you to receive firm order releases from
this customer trading partner. You will then review and accept/reject these firm releases using Demand
Entry. A firm order release is an order release that is definitely being shipped to your customer trading
partner. When a release is firm, its quantity can then be turned into a job that can used to manufacture
the parts, pull the parts from stock, or both.
• Advanced Shipping Notice - This outbound EDI 856/DESADV document is the Advanced Shipping
Notice (ASN) that you send to this customer trading partner via EDI. It is used to track the progress of your
shipments, and lets your customer trading partner know when order releases have been shipped from
your company. You can also use it to reconcile differences between your shipped quantities and the actual
quantities (received by your customer trading partner) using Demand Reconciliation. To learn more about
reconciling quantities, refer to the Demand Reconciliation topic in the Application Help.
• Invoice - An outbound EDI 810/INVOIC document that sends an AR invoice to the customer trading
partner. To learn more about invoicing, review the AR Invoice Entry topic in the Application Help.
• Sales Order Acknowledgement - An outbound EDI 855/ORDRSP document that confirms that the
sales order is in process. It sends the Sales Order Acknowledgement report to this customer trading partner.
Epicor ERP | 9.05.700 53

The Epicor application produces this when it generates a sales order for inbound demand received from
the customer trading partner.
• Response to a Sales Order Charge - An outbound document that allows you to respond to your
customer trading partner's request for a change to an existing sales order. The customer can accept the
sales order with the change, accept the sales order without the change, or reject the sales order. The
Epicor application produces this when it updates an existing sales order that was generated from inbound
demand received from the customer trading partner.
• Order Status - An outbound document that reports the current state of a sales order. The Epicor
application produces this when it generates a new sales order or updates an existing sales order created
from inbound demand received from the customer trading partner.
• Direction - Specifies whether this is an inbound document you receive from this customer trading partner,
or is an outbound document you send to this customer trading partner:
• Inbound - This is an inbound document you receive from this customer trading partner.
• Outbound - This is an outbound document you send to this customer trading partner.
• Options Available - Displays the options available for selection for use by the Epicor application when it
processes part number numbers and product codes this incoming EDI document when received from this
customer trading partner. Refer to Options Selected for directions on how you select options and construct
a hierarchical part number processing list.
• Check For Part - When selected, it denotes that the Epicor application should validate that corresponding
part records exist for the part numbers listed on this inbound demand document when received from this
customer trading partner. If a part record does not exist, a warning will automatically appear within the
Demand Log for your review.
By performing this validation, it helps to ensure that the Epicor application is not accepted invalid part
numbers on inbound EDI transactions received from this customer trading partner. However, by skipping
this validation, you cannot ensure that invalid part numbers on inbound EDI transactions are not being
accepted from this customer trading partner.
• Use Customer Part - When selected, this causes the Epicor application to search for and use customer
part numbers in order to retrieve the corresponding internal part numbers. You create this customer part
number cross reference using Customer Part Maintenance in the Epicor application.
• Manufacturer Part - When selected, this causes the Epicor application to search for and use manfacturer's
part numbers in order to retrieve the corresponding internal part numbers. You create this manufacturer
part number cross reference using Manufacturer Part Maintenance in the Epicor application.
• Use Part UPC - When selected, this causes the Epicor application to search for and use Universal Product
Codes (UPC) in order to retrieve the corresponding internal part. You create this cross reference between
UPC codes and internal part numbers in the Part Maintenance > Part - UOMs sheet.
Product codes are unique registered numbers that identify a specific part and UOM. An example of a
product code is the UPC-12 (Universal Product Code) bar code found on most consumer items purchased
in the USA and Canada. Other product codes (for example, GTIN-14, EAN-13) that can be entered in the
UOMs sheet are used in various circumstances in different regions but are all similar to the UPC bar code.
All part entry fields in the Epicor application allow entry or scanning of codes in lieu of entering an actual
part number. If one of the codes is entered or scanned in a part field, the Epicor application replaces it
with the part number and the correct UOM. The appropriate product code can also be printed on transaction
documents, such as a receiving transaction.
• UPC-12 - This option operates in the same manner as Use Part UPC, but instead processes only UPC
product codes of up to 12 digits in length.
• GTIN-14 - This option operates in the same manner as Use Part UPC, but instead processes GTIN-14
(Global Trade Item Number) product codes of up to 14 digits in length. It is the newest of the product
codes and is used for both standard bar codes and as part of the data encoded on RFID tags.
54 Epicor ERP | 9.05.700

• EAN-13 - This option operates in the same manner as Use Part UPC, but instead processes EAN-13
(European Article Number) product codes, 13 digits in length. It is referred to as a Japanese Article Number
(JAN) in Japan. These codes are used worldwide for marking retail goods.
• EAN-14 - This option operates in the same manner as EAN-13, but instead processes EAN product codes
14 digits in length.
eight digits in length.
• Options Selected - Specifies the hierarchical order in which the Epicor application should process part numbers
and product codes contained on EDI transactions received from this customer trading partner. You construct
the hierarchical processing list by selecting part options displayed in the Options Available field, and then
clicking the appropriate directional buttons.
• For example, if you would want the Epicor application to first perform a Check For Part validation process,
you select Check For Part in the Options Available field, then click the single right arrow button.
• If you want it to next perform a Use Customer Part validation process, you then select Use Customer
Part in the Options Available field, then click the single right arrow button.
Use the remaining buttons as follows:
• To move all options from the Options Available to Options Selected fields in the order in which they
appear, click the double right arrow button.
• To move a selected option up in the hierarchy, select the option being moved in the Options Selected
field, then click the up arrow button. For example, if Use Part UPC is the fifth option listed, but you wish
to make it the second option, select it, then click the up arrow button.
• To move a selected option down in the hierarchy, select the option being moved in the Options Selected
field, then click the down arrow button.
• To remove a single option from the Options Selected field, select the option being removed, then click
the single left arrow button. For example, if you selected GTIN-14 but wish to remove it, select it, then
click the single left arrow button.
• To remove all selected options from the Options Selected field, click the double left arrow button.
• Accept Type - Specifies if demand on this inbound EDI document should automatically be accepted or rejected
for this customer trading partner:
• Always Accept - The Epicor application should automatically process demand for this customer trading
partner, regardless of whether there are errors in the inbound EDI document.
This automatically creates demand entries in the Epicor application and immediately generates sales
order and forecast entries at the time the inbound EDI file is successfully processed. This eliminates the
need to manually use the Process selection in the Demand Header section of the Demand Entry Actions
menu to process the demand.
In cases where the inbound EDI transaction does contain errors (for example, a Date Change action
request is received with insufficient lead time, and a Stop or Warning condition would normally be applied),
the Epicor application automatically overrides any System Rejection flags, processes the demand
Refer to the Customer Maintenance > Customer > Demand section for more details on error conditions
are how they are handled for a customer trading partner.
Note The manner in which Epicor ERP handles rejections (error conditions) while processing inbound
EDI transactions depends on where the error occurs within the record:
• If it occurs at the Demand Header row level (for example, a duplicate PO error), the associated
sales order and all attached order lines/order ship schedules generated from the demand header
row are placed on hold.
Epicor ERP | 9.05.700 55

• If it occurs at the Demand Detail row level (for example, a price mismatch error), only the
associated order line and the attached order ship schedules generated from that demand detail
• If it occurs at the Demand Schedule row level (for example, a lead time error), only the order
ship schedule generated from that demand schedule row are placed on hold.
Refer to Inbound EDI Transaction File Mappings for more details.
• Accept If No Errors - The Epicor application should automatically process demand for this customer
trading partner only if there are no errors in the inbound EDI document. This eliminates the need to
manually use the Process selection in the Demand Header section of the Demand Entry Actions menu to
process the demand.
In the case of inbound EDI transactions, this automatically creates demand entries in the Epicor application
and immediately generates sales order and forecast entries at the time an error-free inbound EDI
file is successfully processed. This eliminates the need to manually use the Process selection in the Demand
Header section of the Demand Entry Actions menu.
In cases where the inbound EDI transaction does contain errors (for example, a Date Change action
request is received with insufficient lead time), the Epicor application handles in the normal manner - it
applies Stop (with System Rejection) or Warning conditions, depending on the settings for the customer
trading partner in the Customer Maintenance > Customer > Demand or Ship To > Demand sheets. It does
not immediately generate sales order and forecast entries in these situations.
Refer to the Customer Maintenance > Customer > Demand section for more details on error conditions
• Manually Accept - Demand from this incoming document for this customer trading partner should only
be manually processed. In this case, the Epicor application or Service Connect creates demand entries
but you must manually process them using the Process selection of the Demand Header section in the
Demand Entry Actions menu. Order releases and forecast entries are only created at the time you perform
this manual processing.
• Map ID - Specifies the program identifier for the document. This value is used during custom program
development; it identifies the document for use with a custom program. Otherwise, this is a display-only field.
• Outbound Document - If this is an outbound document, specify what processing should occur in the Epicor
application when the document is sent to this customer trading partner:
• Required / Document / Manual - These selections are not currently used and are reserved for future
use.
• Automatic - When selected, this check box indicates that the Epicor application should automatically
generate a supporting document record when the associated transaction is confirmed. If you select
automatic generation, you do not have to manually generate the supporting document record when you
process a transaction.
A document record similar to the following example is generated internally and supports subsequent
printing of the associated document. It contains schema information (top portion of the record) and the
actual information printed on the document (lower portion of the record). This is the information generated
for an Advanced Shipping Notice (EDI 856/DESADV):
56 Epicor ERP | 9.05.700

Example If you are defining the characteristics for the outbound Sales Order Acknowledgement document
and you select this check box:
• It designates that the Epicor application will automatically generate the Sales Order Acknowledgement
document record soon as a sales order release is generated for inbound demand received from this
customer trading partner. Refer to EDI 855/865/ORDRSP Transactions (Outbound Order
Acknowledgements) for more details.
• Correspondingly, if you do the same thing for an Advanced Shipping Notice (ASN), it designates
that the Epicor application will automatically generate the ASN document record as soon as a sales
order is marked as shipped. Refer to EDI 856/DESADV Transactions (Outbound Advanced Shipping
Notices) for more details.
• For an Invoice, it designates that the Epicor application will automatically generate the AR invoice
document record as soon it is successfully posted to the General Ledger. Refer to EDI 810/INVOIC
Transactions (Outbound Invoices) for more details.
Note: You must also use Business Activity Manager to enable auto-generation of outbound EDI files when
triggered by specific processing actions or events that take place in within the Epicor application and
database. Refer to Defining Outbound EDI Report Formats for more details.
• Alt Trading Partner - Specifies the trading partner identifier (ID) used with this document. Enter an alternate
trading partner identification number into this field if the trading partner associated with the document is
different than the identifier entered into the Trading Partner field on the Customer > Demand sheet. This
indicates that another trading partner can receive data from this document.
Important To enable automatic processing for a document using the Automatic check box, a value
must be entered into the Alt Trading Partner field! If an alternate trading partner is not associated
with your customer trading partner, simply enter the trading partner identifier for your customer in this
field.
Ship To > Demand Sheet
Use the Ship To > Demand sheet as needed to assign a trading partner identification number and define demand
processing parameters that specify how the Epicor application should evaluate incoming EDI shipping schedules
received from your ship to customer trading partner.
• This sheet is similar in function to the Customer > Demand sheet, but allows you to define override demand
processing parameters for specific ship to locations for a customer trading partner.
• For example, the trading partner may have West Coast, East Coast and off-shore ship to locations, each with
their own lead time and shipping requirements.
Epicor ERP | 9.05.700 57

The demand processing parameters you enter for your ship to customer trading partner in this sheet include:
• Assigning a trading partner identification number and defining demand processing parameters for a specific
ship to customer. This includes assign periodicity, delivery days and date type parameters for used by the
Epicor application for calculating Ship By or Need By dates for demand schedules.
• Indicating how differences in unit price and part records and revision levels should be evaluated by the Epicor
application during demand processing.
• Specifying the lead times required to evaluate and process certain types of action requests (for example,
adding new demand schedule lines, changing or cancelling existing demand schedule lines) on incoming EDI
transactions received from this ship to customer trading partner. For each type of action request, you specify
the actions that should take place in the Epicor application (stop transaction or process transaction and display
a warning message) when incoming EDI transactions are received with insufficient lead times with respect to
the parameters you have specified for that type of action request.
To create a new ship to ID for a customer, select New Ship To and enter information as needed into the Ship
To > Detail sheet.
To enter trading partner demand parameters for a new customer ship to ID or for an existing customer ship to
ID, access the Ship To > Demand sheet by selecting the Ship To sheet, and then select the Demand sheet. These
are the values you can modify for the sheet:
• Use Customer Values - Specifies that you want the fields located on this sheet to use the demand values
that are currently defined at the customer level in the Customer > Demand sheet. When selected, this check
box indicates that you want this sheet to use the demand values currently defined at the customer level in
the Customer > Demand sheet on the current ship to location. Clear the check box to skip use of demand
values defined at the customer level.
58 Epicor ERP | 9.05.700

Tip The remaining fields on the Ship To > Demand sheet are identical to, and function in the same
manner as those found on the Customer > Demand sheet. You specify the same types of parameters,
but the entries in each field would be simply be tailored to the specific processing requirements for the
customer ship to location. Refer to the preceding sections of this document and the Application Help
for detailed information on each field.
Note that the following fields or check boxes found in the Customer > Demand sheet do not have
counterpart fields or check boxes in the Ship To > Demand sheet (they can only be set at the customer
trading partner level and not at the ship-to customer level):
• Cancel Non Matched
• Cumulative Check Discrepancies / Action
• Hold Orders for Review
• Split Demand
Ship To > Documents Sheet
Use the Ship To > Documents sheet (not pictured) as needed to define the processing parameters for inbound
EDI documents you accept from this ship to customer trading partner when sent to you, and the outbound EDI
documents you generate and then send to the ship to customer trading partner. The Demand Management
functionality in the Epicor application uses these definitions to recognize the specific EDI documents that create
and track unfirm order releases, firm order releases, and/or forecasts.
• This sheet is similar in function to the Customer > Documents sheet, but allows you to define override
document processing parameters for specific ship to locations for a customer trading partner.
• For example, the trading partner may have West Coast, East Coast and off-shore ship to locations, each with
their own document processing requirements.
Tip The fields on the Ship To > Documents sheet are identical to, and function in the same manner as
those found on the Customer > Documents sheet. You specify the same types of parameters, but the
entries in each field would be simply be tailored to the specific processing requirements for the customer
ship to location. Refer to the preceding sections of this document and the Application Help for detailed
information on each field.
Defining Outbound EDI Report Formats
To outbound EDI report formats, you must do the following:

• Use Report Data Maintenance to create customized report data definition records the Epicor application
uses to generate outbound EDI 810 (AR Invoice), EDI 855 (Order Acknowledgement) and EDI 855 (Advance
Shipping Notice) document records that are sent via EDI to your customer trading partners. These report data
definitions contain detailed information that denotes the specific schema, database tables and fields that are
included in the resulting outbound EDI transactions.
Tip Epicor provides "out-of-box" standard report data definitions that can be used "as-is", but generally
most companies elect to duplicate and then customize them as needed to fit the requirements of their
business operations and their customer trading partners.
• Once you have duplicated an existing report data definition, and have modified the duplicated record to your
satisfaction, you then associate it with a specific type of document (for example, AR Invoices, Sales Order
Acknowledgements and Packing Slips) using Report Style Maintenance.
Epicor ERP | 9.05.700 59

• Use Business Activity Manager to enable auto-generation of outbound EDI files when triggered by specific
processing actions or events that take place in within the Epicor application and database. This works in
conjunction with the Automatic check box setting for certain types of documents in the Outbound Document
section of the Customer Maintenance > Documents or Ship To > Documents sheets (for a customer or ship
to trading partner).
• It causes the Epicor application to automatically produce Order Acknowledgement, Advanced Shipping
Notice or Invoice document records when you process sales orders, shipments and invoices that are a result
of demand requests on inbound EDI transactions received from a customer partner.
Refer to the following sections for details on how the Epicor application generates these supporting records:
• EDI 855/865/ORDRSP Transactions (Outbound Order or Change Acknowledgements)
• EDI 856/DESADV Transactions (Outbound Advance Shipping Notices)
• EDI 810/INVOIC Transactions (Outbound Invoices)
Report Data Maintenance
Report Data Maintenance is an administrative tool that lets you both create and/or edit data definitions for both
custom reports and existing reports. Through this program, you can define variations for each report that you
can then make available to specific companies.
Epicor supplies the following "out-of-box" report data definition formats for outbound EDI transactions; however,
you must copy and then customize them to print content specific to your company:
• EDIARFm - Report data definition used for the outbound EDI 810/INVOIC document that sends an AR
invoice to a customer trading partner.
• EDIOrdAck- Report data definition used for the outbound EDI 855/ORDRSP document that confirms that
the sales order is in process. It sends the Sales Order Acknowledgement report to a customer trading partner.
60 Epicor ERP | 9.05.700

The Epicor application produces this when it generates a sales order for inbound demand received from the
customer trading partner. It is also used to Reponses to a Sales Order Change and Order Status documents.
• EDIMstPk - Report data definition used for the outbound Advanced Shipping Notice (ASN) EDI
856/DESADV document that track the progress of master pack shipments; it lets your customer trading
partner know when order releases have been shipped from your company.
• EDIPckSI - Report data definition used for the outbound Advanced Shipping Notice (ASN) EDI 856/DESADV
packing slip document that track the progress of shipments; it lets your customer trading partner know
when order releases have been shipped from your company.
The four standard "out-of-box" EDI report data definitions have been designated as System Reports that cannot
be directly modified; they must first be duplicated, and then the duplicate can be modified. To customize
an existing report data definition, you first create a copy of the report; you can then add fields and tables to it,
or remove any fields and tables that you do not want.
• Any database table can be added to a new or existing report, letting you display the specific information you
need.
• Report Data Maintenance lets access all the tables within the database, as you can define relationships with
parent and child tables, letting you display related information pulled from any table you need. You can also
define criteria which limits the data that is displayed.
• This program does not make changes to the report's layout; it only defines the data contained in the outbound
EDI file.
Menu Path
• System Management > Company Maintenance > Report Data Definition
®
Use the Detail sheet to define the primary attributes of the customized report. The controls on this sheet let you
create a new custom report or find and select an existing report. These are the values you can modify for the
item:
• Code - Specifies the identifier for the report you wish to customize. Enter the identifier or click Code to search
for an existing report data definition (for example, EDIPckSI). The selected standard report data definition can
be duplicated and then modified to fit the specific requirements for your operations. The newly defined report
data definition can then designated in Report Style Maintenance for use in place of the standard report data
definition when generating outbound EDI documents. To edit the report data definition for an EDI document,
select one of the following:
• EDIARFm - "Out-of-box" report data definition used for the outbound EDI 810/INVOIC document that
sends an AR invoice to a customer trading partner.
• EDIOrdAck - "Out-of-box" report data definition used for the outbound EDI 855/ORDRSP document
that sends the Sales Order Acknowledgement report to a customer trading partner. The Epicor application
produces this when it generates a sales order for inbound demand received from the customer trading
partner. It is also used to Reponses to a Sales Order Change and Order Status documents.
• EDIMstPk - "Out-of-box" report data definition used for the outbound Advanced Shipping Notice
(ASN) EDI 856/DESADV document used to track the progress of master pack shipments.
• EDIPckSI - "Out-of-box" report data definition for the outbound Advanced Shipping Notice (ASN) EDI
856/DESADV packing slip document used to track the progress of shipments.
Epicor ERP | 9.05.700 61

• After selecting a report data definition code:

• It indicates if the selected report data definition is a standard System Report. The four "out-of-box" EDI
report data definitions have been designated as System Reports that cannot be directly modified; they
must first be duplicated, and then the duplicate can be modified.
• Displays the description and report type.
• It also indicates if the selected report data definition is a duplicate of another report data definition record
(for example, EDIPackSl is a duplicate of the standard PackSlip report data definition.
• In the Tree View, it displays the specific database tables and fields that current comprise the selected report
data definition.
To duplicate (copy) the selected report data definition and assign a new name so you can customize it with
content specific to your company, select the Duplicate Report selection on the Actions menu. When you do
this, the following dialog is displayed:
• Enter a unique Report Definition ID and description, then click OK.

• The duplicated report data definition is redisplayed in the Report Data Maintenance > Header sheet.
The Tree View displays the specific database tables and fields that current comprise the selected report data
definition.
• To view the fields that are currently included in the report data definition record for specific database table,
you click the desired table (for example, Company).
• In the Report Tables > Excluded Fields sheet, it displays the included report fields under Included Report
Fields, and the excluded fields under Excluded Report Fields.
62 Epicor ERP | 9.05.700

To add or remove fields from the current report data definition, do the following:
• To add a new field to the current report data definition, simply select the one you want to add (for example,
Calendar ID) in Excluded Report Fields, then click the Left Arrow button add it to Included Report Fields.
To add all fields, click the Double Left Arrow button.
• Conversely, to remove a field from the current report data definition, simply select the one you want to remove
in Included Report Fields, then click the Right Arrow button to add it to Excluded Report Fields. To
remove all fields, click the Double Right Arrow button.
• When you are finished adding or removing fields for selected database tables to the current report data
definition, click the Save icon.
Epicor ERP | 9.05.700 63

Report Style Maintenance
Once you have duplicated an existing report data definition (for example, EDIPckSl) in Report Data Maintenance,
and have modified the duplicated record to your satisfaction, you then associate it with a specific type of document
using Report Style Maintenance.
You use Report Style Maintenance to identify the different report styles that are available to a user when they
print user-customizable reports and forms. This lets you define variations on each report that you can then make
available for specific companies within the Epicor application.
When you are using EDI, you must associate customized EDI-compatible versions of the report data definitions
(you duplicated and modified in Report Data Maintenance) to a specific type of document to make them available
for selection when you use certain programs in the Epicor application. You also designate what type of output
(plain text or XML) should be generated, and the destination server folder in which the resulting output files
should be stored for transmission via EDI to your customer trading partner. For example,
• Report data definitions that cause the Epicor application to generate document records that support outbound
EDI 810 (AR Invoice) transactions would generally be associated with Invoices. The user-customized version
of these report data definitions should be added to the ARForm report. This makes them available for selection
when printing invoices in AR Invoice Entry.
EDI 855 (Order Acknowledgement) transactions would generally be associated with Sales Order
Acknowledgements. The user-customized version of these report data definitions should be added to the
OrderAck report. This makes them available for selection when printing sales order acknowledgements in
Sales Order Entry.
64 Epicor ERP | 9.05.700

EDI 856 (Advanced Shipping Notice) transactions would generally be associated with Packing Slips. The
user-customized version of these report data definitions should be added to the PackSlip or MastPack
reports. This makes them available for selection when you produce packing slips in Customer Shipment Entry
or Master Pack Shipment Entry (see below).
When selected, the report data definitions cause the Epicor application to generate text or XML-based document
records that support outbound EDI 856 (ASN) transactions. Refer to EDI 856 Transactions (Outbound Advance
Shipping Notices) for more details.
Menu Path
• System Management > Company Maintenance > Report Style
®
To associate a report data definition with a selected type of document, use the Report ID field to enter the
identification number for the report with which the report data definition is being associated (for example, Packing
Slip), or click Report ID to search for the report ID. To create a new report style and associate a report data
definition to the selected document or report, click New Report Style.
Use the Styles - Detail sheet to define the primary attributes of the customized report. The controls on this sheet
let you create a new custom report or find and select an existing report. These are the values you can modify for
the item:
• Style Number - Displays a system-assigned identification number for the report style. This is for display only.
• Description - Specifies an identification number (for example, ASN - Text) for the report style. Referring to
the example on the previous page, this is the description that appears when you print packing slips in Customer
Shipment Entry or Master Pack Shipment Entry.
• Report Type - Specifies the type of report style being defined. For outbound EDI transactions, select Outbound
EDI.
• Data Definition - Specifies the report data definition being associated with the selected document. Select
the report data definition you previously created in Report Data Maintenance (for example, EDIASN).
• Output Location - Identifies the pathname of the destination folder (for
example,c:\epicordata\edi_data\outbound\ASNs) on your server in which the Epicor application places
outbound EDI files it generates when this report style is selected in a program such as Customer Shipment
Entry or Master Pack Shipment Entry.
Once the Epicor application has deposited the file in the designated destination folder on your server, the
third party TIE KINETIX eVision software retrieves the outbound document record and transmits it as an EDI
transaction to your customer trading partner.
• Output EDI - Specifies the type of output (for example, Plain or XML File) that should be created when the
Epicor application generates the EDI document record when this report style is selected. You select an output
file type based on the mappings that will be used by TIE KINETIX eVision to create the actual EDI raw data.
• Plain Text - Specifies that the EDI output for this report style should be generated in plain text format
and stored in a .txt file, similar to the following:
Epicor ERP | 9.05.700 65

• XML File - Specifies that the EDI output for this report style should be generated in XML format and stored
in a .XML file. XML file formats contain the same output as in a plain text file, but in a more sophisticated
output complete with XML tags and associated schema, but are generally far larger than standard text files.
• Company List - Specifies the companies for which this is a valid report style. Select the Valid check box in
this grid if this is a valid report style for the corresponding company.
• Default - Indicates that this style is the default should be used when you print this form/report for the listed
company. Only one style can be selected as the default for a company.
The following is an example of EDI-compatible report styles that would be associated with Sales Order
Acknowledgements in Report Style Maintenance. The Epicor application uses them to generate document records
that support outbound EDI 855/865/ORDRSP (Order Acknowledgement) transactions:
66 Epicor ERP | 9.05.700

The following is an example of EDI-compatible report styles that would be associated with Invoices in Report
Style Maintenance. The Epicor application uses them to generate document records that support outbound EDI
810/INVOIC (AR Invoice) transactions:
Epicor ERP | 9.05.700 67

Business Activity Manager
Once you have associated report data definitions with specific type of documents in Report Style Maintenance,
you use Business Activity Manager to enable auto-generation of outbound EDI files when triggered by specific
processing actions or events that take place in within the Epicor application and database.
• This works in conjunction with the Automatic check box setting for certain types of documents in the
Outbound Document section of the Customer Maintenance > Documents or Ship To > Documents sheets
(for a customer or ship to trading partner).
• It causes the Epicor application to automatically produce Order Acknowledgement, Advanced Shipping
Notice or Invoice document records when you process sales orders, shipments and invoices that are a result
of demand requests on inbound EDI transactions received from a customer partner.
Tip Instead of using Business Activity Manager to set up triggered auto-printing of document records,
you can manually generate document records that support outbound EDI transactions. You must set
up a separate BAM record for each type of outbound EDI document. Refer to the following
sections for more details:
• EDI 855/865/ORDRSP Transactions (Outbound Order Acknowledgements)
• EDI 856/DESADV Transactions (Outbound Advance Shipping Notices)
• EDI 810/INVOIC Transactions (Outbound Invoices)
68 Epicor ERP | 9.05.700

The Business Activity Manager (also called the BAM) is a communication tool that you can use to track data
changes by monitoring fields in selected tables within the database. As users enter and update data, and changes
you define occur within the specific tables, it triggers an event such as auto-generation of document records that
support outbound EDI processing. You define when these BAM events are triggered by setting up a series of
rules. These rules define conditions that limit how often auto-printing is activated.
To launch this program from the Main Menu:
Executive Management > Setup > Business Activity Manager
Use the Events - Detail sheet to create an event record. This event record defines the table and the fields that
will be monitored by the Business Activity Manager. When any changes occur to the fields defined within the
event, the actions you define on the Actions sheet (in this instance, auto-generation) will occur. These are the
values you can modify for the item:
• Table - Specifies the database table that will be monitored by the Business Activity Manager. Enter the name
of the table or click Table to search for a table name. To set up auto-generation of document records that
support outbound EDI transactions, enter one of the following:
• InvcHed - Invoice Header table (for auto-generation of outbound EDI 810/INVOIC AR Invoice transactions)
• OrderHed - Order Header table (for auto-generation of outbound EDI 855/ORDRSP Order Acknowledgement
transactions)
• ShipHed - Shipment Header table (for auto-generation of EDI 856/DESADV Advanced Shipping Notice
transactions)
• Description - Specifies a brief explanation for the event (for example, Order Acknowledgement Auto
Generation)
Epicor ERP | 9.05.700 69

• Available Fields - Displays all of the fields within the selected table. To add a specific field to the current
event, highlight it and click the Right Arrow button.
For auto-generation of EDI 855/ORDRSP Order Acknowledgement transactions, select EDIReady by highlighting
it and clicking the Right Arrow button.
• Rules Validated - Indicates whether the associated rules on the Rules sheet have been validated. If the icon
is green, the rules are deemed to be valid. If the icon is red, the rules have not been validated, or the logic
has discerned an error. To test the rules, go to the Business Activity Manager - Rules sheet and click Test.
• Selected Fields - Displays the table fields that have been selected and are active in the current event. To
remove a specific field from the current event, highlight it and click the Left Arrow button. To remove all
the fields from the event, click the Double-Left Arrow button.
After using the Events - Detail sheet to create an event record, and selecting the table and the fields that will be
monitored by the Business Activity Manager, you use the Actions sheet to specify the action (such as
auto-generation) that will take place when any changes occur to the fields defined within the event.
• Auto-Print - Specifies that auto-generation of the outbound EDI transaction related to this event that will
take place when any changes occur to the fields selected in the Events - Detail sheet. Select the check box to
enable auto-generation for the outbound EDI transaction for this event.
• Report ID - Specifies the identification number of the report assigned to this table. Select the identifier for
the report style being used to automatically print a report from this data.
You create report style identifiers in Report Style Maintenance; these report data definitions cause the Epicor
application to generate text or XML-based document records that support outbound EDI 810/INVOIC (Invoice),
EDI 855/ORDRSP (Order Acknowledgement) or EDI 856/DESADV (ASN) transactions.
70 Epicor ERP | 9.05.700

For example, if you are defining an Auto-Printing action for the OrdHed (Order Header) table, and wish to
generate a text-based version of the document record, you would select the report style you defined for this
purpose in Report Style Maintenance.
• Data Definition ID - Specifies the identification number of the report data definition assigned to the report
for this table. This is the customized report that is printed when the current BAM event is activated. Select
the identifier for the report data definition being used; you create report data definitions in Report Data
Maintenance.
Use the Rules sheet to define the conditions, or criteria, that must occur before an action is launched from the
current BAM event. Use this sheet as a filter to prevent an action from running every time data within the table
is added or updated.
• For auto-generation of outbound EDI files, you use the Rules sheet to define a rule that compares the value
in the EDIReady field against a constant value of true.
• This means you only allow Auto-Printing for outbound EDI transaction when the EDIReady field in the
corresponding OrdHed (Order Header), ShipHed (Shipment Header) or InvcHed (Invoice Header) table record
is true. Auto-Printing occurs at the point that this field is "turned on" in the corresponding record, never
when it is "turned off" (set to false).
From the toolbar, select New BAM Rule. These are the values you can modify for the item:
• For Alert - Clear this check box when defining rules for auto-generation processing.
• For Log - Clear this check box when defining rules for auto-generation processing.
• For Print - When defining rules for auto-generation processing, select this check box. It designates that this
rule affects when auto-generation processing takes place for the Business Activity Management event previously
defined in the Events - Detail sheet.
• And/Or - Use this list to define how this rule will work in relationship with other rules for this event:
• And - This rule must be TRUE in addition to any other rule.
• Or - Either this rule must be TRUE, or another rule must be TRUE.
• <Blank> - This option must only be selected for the first rule. It causes all the other "And/Or" rules to run
after it. Since the rules you are defining for auto-generation processing are one-line rules, select this option.
Epicor ERP | 9.05.700 71

• Field Name (Evaluate) - Specifies the name of the field being evaluated by the rule. This is the first Field
Name on the grid row. The only fields displayed on this list are the fields selected on the Business Activity
Manager - Event sheet.
• Select the field that you want this rule condition to evaluate.
• For rules for auto-generation processing, select EDIReady.
• Operator - Select the equal (=) sign when defining rules for auto-generation of outbound EDI transaction
files.
• Constant - Select this check box to compare the entry in the Field Name (Evaluate) field against the value
specified in the Value field. When defining rules for auto-generation processing, always select this check box.
• Value - Specifies the constant value being used to compare against the value specified in the Field Name
(Evaluate) field.
• This field is only available if the Constant check box is selected and the Field Name (Evaluate) that is
being compared against is a value other than a date value.
• For auto-generation of outbound EDI transaction files, enter true.
• Test- Click this button to test the validity of the rule. Rules Validated turns to green if the rule is valid.
Report Data Maintenance - Auto Print Rules
Once you have used the Business Activity Manager to enable auto-generation processing of specific outbound
EDI documents (when triggered by specific processing actions or events that take place in within the Epicor
application and database), you must go back into the Report Data Maintenance - Auto-Print Rules sheet to
associate the parameters with each specific type of outbound EDI documents - EDI 810/INVOIC (AR Invoice), EDI
855/ORDRSP (Order Acknowledgement) and EDI 856/DESADV (Advanced Shipping Notice).
72 Epicor ERP | 9.05.700

From the toolbar, select New Report Rule. These are the values you can modify for the item:
• Rule ID - Specifies an identification number for the rule. Enter a user-defined identification number.
• Report - Specifies the report for which the Auto-Printing rule is being associated. Select the outbound EDI
document (Advanced Shipping Notice, Invoice or Sales Order Acknowledgement) for which the Auto-Printing
rule is being associated.
• Style - Specifies the report style being used for Auto-Printing rule for the outbound EDI document. Select the
report style you defined for EDI outbound transactions in Report Style Maintenance (either text or XML-based
output).
• Auto-Printer - Specifies the printer device being used for auto-generation processing. When you enable
auto-generation processing, the Epicor application simply generates a text or XML-based file, so no physical
output is produced on an attached printer; therefore, any valid printer device (previously defined in Printer
Maintenance in the Epicor application) can be selected in this field. Optionally, a dummy "EDI" printer could
be defined and then selected in this field.
Note This field cannot be blank.
Epicor ERP | 9.05.700 73

Processing Components EDI / Demand Management Technical Reference Guide
Processing Components
This section explores the main calculations and base values used in EDI / Demand Management module interface
processing. Review this material to learn about mapping the data formats required for demand management
processing in your Epicor application to your customer trading partner's EDI processing formats, and how inbound
EDI files are converted into actionable demand entries, demand schedules, orders, shipping transactions and
invoices.
Tip This section only covers those EDI / Demand Management functions directly related to automated
processing of inbound EDI transactions received from a customer trading partner. For detailed information
related to manual processing and reconciliation of demand, refer to the standard Demand Management
module topics in the Epicor Application Help.
Entering Demand Contracts
Prior to receiving inbound EDI transactions of any kind from a customer trading partner, you must first use
Demand Contract Entry to enter demand contracts.
• The demand contract is an instrument against which the Epicor application receives and processes inbound
EDI files received from your customer trading partners.
• Once inbound EDI transactions have been received and processed, the Epicor application uses the demand
contract records to automatically generate demand for your parts, allowing you to set up a shipping schedule
for order releases or forecasts for MRP processing.
The demand contract represents the contractual agreement for proposed sales to your customer trading partner
over a specified period of time.
• Using Demand Contract Entry, you specify the dates during which each demand contract is active. You can
enter any time frame (days, months, years) that you need for the length of the contact. The purchase order
number represents the specific customer purchases against the demand contract.
• You can also (optionally) enter the specific part numbers covered under the contract, specifying unit prices
and maximum purchase quantities. Each contract can be set up for multiple parts, so one contract can be
used to generate multiple shipping schedules for each part detailed on the contract. Entry of specific part
numbers on the demand contract is optional because the Epicor application automatically generates new
contract lines if you receive an inbound EDI file with a part number that is not on file.
• You can also set up several default values for the sales orders and/or forecasts that will be generated through
the contract. You can indicate the discounting method being used for the part quantities specified on the
contract, and whether or not each sales order will be shipped complete.
• You use the Header > Matching sheet to specify the parameters and processing hierarchy that the Epicor
application should use to match requests for updates to existing demand schedule releases that have already
been generated through this demand contract. These are schedule update requests received on subsequent
inbound EDI transactions sent by your customer trading partner.
The structure of the contract allows for multiple sales order releases to be attached to it. It provides an efficient
interface and process to manage the large volume of data that can collect through the length of long term
contracts. This gives you with the ability to review the contract quantities against actual incoming demand
quantities on inbound EDI transactions.
74 Epicor ERP | 9.05.700

EDI / Demand Management Technical Reference Guide Processing Components
Header Sheet
Use the Header sheet to enter or edit primary details for the demand contract. You use this sheet to define the
customer and default settings being used for sales orders generated through this contract.
You also use this sheet to indicate the length of the contract, cumulative setting, and other contract header
definitions.
In addition to the Header sheet, Demand Contract Entry contains the following sheets:
• You can use the Summary sheet as needed to review the main sections of a demand contract. It always you
to add or edit the primary items for the overall contract. You can also use this sheet to quickly add detail lines
to the contract; you will do this on the Demand Contract Detail Lines grid. This sheet is not covered in this
document; refer to the Epicor Application Help for more detailed information on its use.
• To view and edit the complete details on a contract line, use the Line sheet.
• Use the Header > Matching sheet to specify the parameters that the Demand Matching process should use
to match requests that are received on inbound EDI transactions sent by your customer trading partner for
updates to existing demand schedule releases that have already been generated through this demand contract.
You specify which matching criteria should be used, and the priority sequence in which they should be applied
during the matching process.
Epicor ERP | 9.05.700 75

The following section describes the Entering Demand Contracts values you can change.
Demand Contract Entry

Sales Management > Demand Management > General Operations > Demand Contract Entry
To access the Demand Contract Entry > Header sheet to create a new demand contract header, click New
Contract Header. These are the values you can modify:
Tip Only those fields that are of particular importance to demand processing are covered in this document.
Refer to the Epicor Application Help for complete details about the use of the Demand Contract Entry >
Header sheet.
• Contract - Enter the identification number for the demand contract. The demand contract number you enter
into this field must match the identifier your customer trading partner uses for this demand contract on
inbound EDI transactions. To edit an existing contract, click Contract to access the Contract Search to select
an existing record.
• Customer ID - Specifies the identifier for the sold to customer for whom you are entering this demand
contract. You can enter this customer identifier directly, or you can click the ID... button to access Customer
Search and select the customer you need. After entering the customer identifier, the customer's name, address,
phone and fax number are displayed.
• Trading Partner - Specifies the trading partner identifier for the customer. This identifier is used to send and
receive EDI documents between your company and this customer. If you use EDI, enter the trading partner
identifier in this field. The trading partner identification number you enter in this field must match the trading
partner identifier designated for the customer in the Customer Maintenance > Demand sheet or Customer
Maintenance > Ship To > Demand sheet. It must also match the trading partner identifier your customer
uses on inbound EDI transactions.
• Order - This block contains the following fields that become the default settings used for sales orders generated
through this contract:
• FOB - Specifies the point at which the ownership title for shipped goods changes.
• Terms - Specifies the conditions under which the customer pays for sales orders generated through this
contract. The default terms come from the customer record, but you can select different terms from the
list.
• Priority - Specifies allocation priority for the order. This priority code defines how the Advanced Material
Management module will prioritize reserving quantities for this customer in relationship with your other
customers.
• Currency - Defines the currency used for this transaction. If the Currency Management module is installed,
the currency selected on the customer record appears, but can be changed on a specific demand contract.
The currency you select is also used on any sales orders generated from this demand contract.
• Lock - This check box is available if the Currency Management module is installed. When selected, this
check box lets you lock in the currency exchange rate that is defined at the time transactions are run
through this contract. This exchange rate is then used for all later transactions (such as payment entry,
cash receipt entry, debit memo, or wire transfer), ignoring actual changes in the market rates.
• Ship Via - Identifies the means of shipment. The default Ship Via code comes from the customer record, but
you can select another Ship Via code from the list
• Project - Specifies the specific project associated with this demand contract. Projects organize the manufacturing
of large capital projects; they let you group related sales orders, jobs, purchase orders, and tasks at high level.
An optional field, you can either enter the Project ID directly or click the Project ID button to find and select
76 Epicor ERP | 9.05.700

the project identifier. It can also be set at the demand contract line level in the Project field in the Line > Detail
sheet.
• Apply Order Based Discounts Automatically - When selected, this checkbox activates the Epicor automatic
pricing system. This feature lets you apply discounts based on the quantity on each order line, the total value
of the order, or both.
• Ship Order Complete - When selected, this check box indicates that all the order lines on this order must
be shipped at the same time. This check box is only used if your company has an Advanced Material
Management license and you use auto-picking.
• Selecting this check box does not prevent you from shipping separate releases from the sales order.
• If this check box is cleared, then various releases on this order can ship at different times.
• Hold Orders for Review - Specifies if sales orders created from this demand contract in Demand Entry should
be held for review before being released for shipping.
• Select the check box to place sales orders created in Demand Entry for this demand contract on hold for
review.
• Clear the check box to skip placing of sales orders created for this demand contract on hold before they
are released for shipment.
• The setting in this check box comes from the setting of the Hold Orders for Review check box in the
Customer Maintenance > Customers > Demand sheet for the sold-to customer and can be overridden for
individual demand contracts.
• Lock By Line - Specifies if the purchase order or purchase order lines associated with this demand contract
should be locked in the process of updating the purchase order (based on inbound EDI transactions related
to the associated demand contract).
• Select the check box to only lock purchase order lines during this time. For example, if the inbound EDI
transaction only affects the second purchase order line, it will only lock that purchase order line during
the update.
• Clear the check box to lock the entire purchase order during this time. For example, if the inbound EDI
transaction only affects the second purchase order line, it locks the entire purchase order and demand
contract during the update.
• Bill To Customer - If this customer makes payments through another customer, select the alternate bill to
customer. This situation happens when the bill to customer is a leasing company or a head office that needs
to be charged instead of the receiving customer. Select Same as Sold To if the bill to customer is the same
as the sold to customer selected in the Customer field.
• Test Mode - When selected, this check box indicates that you are running this contract in test mode. Use
this option while you are creating a custom program in order to test the results. This mode lets you and your
trading partners verify that the data results are correct before going into production mode. When you are
satisfied that your custom program is working correctly, clear this check box.
• Cumulative Setting -
Specifies the setting used to reconcile cumulative shipping part quantities (CUMM) generated electronically
through this contract. When you process the demand, and ship releases to the customer trading partner, they
receive this information through an Advanced Shipping Notice (ASN) document. The customer then uses this
EDI document to indicate the actual amounts that the customer (trading partner) has received. This CUMM
total value is then electronically sent back as the actual received quantity.
Depending on the option you select, you can turn off cumulative tracking, reconcile cumulative quantities
using the part number, or reconcile them based on part number and customer purchase order used to order
the parts. Select one of the following:
• None - Turns off cumulative tracking.
• By Part - Allows tracking of cumulative quantities for this demand contract by part number.
Epicor ERP | 9.05.700 77

• By Part/PO - Allows tracking of cumulative quantities for this demand contract by part number, by
customer purchase order number.
Once you start processing inbound EDI transactions for this customer trading partner, you can view
cumulative quantities for this demand contract in the Demand Entry > Cumulative Info sheet. To adjust
the quantities on each order release to reflect the actual CUM values, you use Demand Reconciliation.
• Firm Days - Specifies the number of days from the current date that the Epicor application should consider
the contract's order releases as firm. If a change is made to the order releases during this period, a warning
message is displayed. Enter the number of days in this field. This field is informational only and not used in
formal demand contract processing.
• Minimum Call Off Quantity - Designates the minimum quantity you are able to receive as demand for this
contract.
• Contract Dates Start - Specifies the starting date of the demand contract. This is the beginning of the
contractual agreement between you and your customer trading partner. This field is informational only and
not used in formal demand contract processing.
• Contract Dates End - Specifies the ending date of the demand contract. This is the end of the contractual
agreement between you and your customer trading partner. This field is informational only and not used in
formal demand contract processing.
• Totals Invoiced Amount - Displays the total invoice amount of orders invoiced for this contract in base
currency. This is a display only field that is automatically updated by the Epicor application as the orders that
are generated from demand entries created by inbound EDI transactions are invoiced.
• Totals Ordered Amount - Displays the total amount that your company will receive from orders generated
through this contract. This is a display only field that is automatically updated by the Epicor application as
orders are generated from demand entries created by inbound EDI transactions.
78 Epicor ERP | 9.05.700

Line > Detail Sheet
Use the Line > Detail sheet to enter the agreed upon parameters for ordering a specific part on the demand
contract. Using this sheet, you can select the part number, define its price options and indicate how this contract
line will handle the ordered quantities.
To access the Demand Contract Entry > Line > Detail sheet to create a new demand contract line, click New
Contract Line. These are the values you can modify for this item:
Important Only those fields that are of critical importance to demand processing are covered in this
document. Refer to the Epicor Application Help for complete details about the use of the Demand Contract
Entry > Line > Detail sheet.
• Line - Specifies the contract line number. The Epicor application automatically generates the line number
when you create a new contract detail line.
• Part - Specifies the identification number for the internal part being ordered on this demand contract line.
You can enter this part number directly, or you can also click the Part button to display the Part Search
window; use this window to find and select the part you need. You can also enter (or in some cases scan)
cross reference numbers that you may have established in the following programs:
• Supplier part numbers defined in the Approved Supplier Maintenance - Supplier Parts sheet, and the
Supplier Price List - Parts - Supplier Parts sheet.
• Manufacturer's part numbers defined in the Qualified Manufacturer - Manufacturer Part sheet.
• Customer part cross references defined for the part in the Customer Part Maintenance - Detail sheet.
• Internal part cross references defined for the part in the Internal Part Cross Reference - Detail sheet.
• EAN-8, EAN-13, EAN-14, GTIN-14 or UPC-12 product codes defined for the part in the Part Maintenance
- Part - UOMs sheet.
Epicor ERP | 9.05.700 79

The Epicor application automatically translates the specified cross reference number to your internal base part
number and displays it in this field. If the specified cross reference number maps to multiple base internal part
numbers, a Cross References dialog appears and displays all mapped parts for the cross reference number.
You must select the mapped part number that is appropriate for the transaction.
• Description - Specifies a brief description of the part. The part description prints on order and invoice forms.
If multiple descriptions are available for this part (for example, a description in a different language), click
Description to view a list of all the current options. Select the alternate description that you need.
• Customer Part - Specifies the customer part number being ordered on this demand contract line. Customers
often have unique part numbers and revisions that they use to identify specific parts. If the current customer
has such a number for the internal part selected on this line, it appears in this field (for example, 002PLP), if
previously established in Customer Part Maintenance. You can also click the Customer Part button to display
the Customer Part Search window; use this window to find and select the customer part you need.
• Revision - Specifies the revision number (if any) required for the customer part being ordered on this demand
contract line.
• Total Contract Quantity - Specifies the total part quantity that you are expecting this customer to order
during the length of this contract. This value is displayed using your company's unit of measure.
• Select the UOM code that represents the unit of measure (for example, Each, Case, Cubic Centimeters)
in which the quantity is being expressed.
• For part master parts, the default is the base UOM code defined for the part in the Primary UOMs - Sales
field in Part Maintenance. For non-part master parts, select the applicable UOM code.
• Minimum Call Off Quantity - Specifies the smallest quantity allowed for each release or forecast generated
through the Create Demand Schedule process, or a demand schedule is manually entered in Demand Entry.
If a quantity is below this minimum value, a warning message similar to the following is displayed:
• Plant - Specifies the plant in which this part is manufactured.

• Pricing - Specifies if internal or customer pricing should be used for demand entries generated from inbound
EDI transactions received against this demand contract line. The default comes from the setting of Pricing
field in the Customer Maintenance > Customer > Demand or Ship To > Demand sheets for this customer
trading partner and can be overridden.
• Customer Pricing - The customer price that appears on the inbound EDI document should be used to
populate the EDIUnitPrice field in the Demand_Detail file. In this scenario, the Epicor application uses the
customer price on demand entries (and sales order lines generated from the demand entries) generated
from the demand contract line.
• Internal Pricing - The internal price calculated within the Epicor application should be used to populate
the EDIUnitPrice field in the Demand_Detail file. In this scenario, the Epicor application uses the internal
price on demand entries (and sales order lines generated from the demand entries) generated from the
demand contract line.
• Tolerance - Specify the allowable price difference tolerance percentage, if any, for the demand contract line.
For example, enter 10.50 into this field for a 10.5% tolerance.
$2.00. If you set the Tolerance field to 10.00, the Epicor application would accept a unit price minus
10% of the internal price. In this example, it would consider $1.90 as an acceptable price, because
80 Epicor ERP | 9.05.700

would be within 10% of the $2.00 internal price. Conversely, it would not consider $1.75 or $1.50
acceptable prices, because they are outside of the 10% tolerance range (from $1.80 to $2.00).
• Unit Price - Specifies the selling price per unit for the selected part. The application gets the customer price
or the internal price, depending on what is selected in the Pricing field. If the Use Price List check box is
selected, the Order Quantity may trigger a change due to a price break. This takes precedence over any
values you might manually enter into the Unit Price and Price Per fields. When this happens, the Epicor
application automatically recalculates the Unit Price field to display the updated price. This check box only
affects how the value in the Internal Price field is calculated. If this check box is clear, the internal price at
demand entry defaults from the demand contract.
Example: The Unit Price defined for Part XYZ is $500.00. You set up a price break for this part that has a
break quantity of 25 and a discount amount of 2%. You enter an order line quantity for 50 pieces. The default
unit price for Part XYZ is automatically adjusted to $490.
• Price Per - Specifies the unit by which the unit price is measured. The default value is pulled from the part
record, but you can select a different option from the list. If the part does not exist in the part master file,
however, the default value is Each. There are three options:
• /Each
• /100
• /1000
• Discount % - Specifies the default discount percentage applied to all purchases made by this customer. When
you create a sales order for this customer, this discount is taken by default for each line item. You can change
this discount percentage that is used.
• Use Price List - When selected, this check box indicates that the Unit Price will be calculated using any price
lists that have defined for this customer in the Epicor application. This takes precedence over any values
you might manually enter into the Unit Price and Price Per fields. If the quantity or value of the contract
line triggers a price break, the Epicor application automatically recalculates the Unit Price field to display the
updated price.
• Totals - This section displays the following total quantities and amounts:
• Ordered Quantity - Displays the total part quantity this customer will potentially purchase through orders
generated for this contract detail line. The Inventory UOM (Unit of Measure) code that represents the unit
of measure in which this quantity is expressed displays to its right.
• Ordered Amount - Displays the total extended amount that your company will potentially receive from
orders generated for this contract detail line.
• Shipped Quantity - Displays the total part quantity that has been shipped to-date from order releases
generated through this contract line. The Inventory UOM (Unit of Measure) code that represents the unit
• Invoiced Quantity - Displays the total part quantity that has been invoiced to-date from order releases
generated through this contract line. The Inventory UOM (Unit of Measure) code that represents the unit
• Invoiced Amount - Displays the total extended amount that has been invoiced to-date from order releases
generated through this contract line.
• Delete Current Releases - When selected, this check box causes all previous releases to be removed while
this contract line's schedule is generated again.
• Select this check box if you wish to completely refresh this line's release schedule each time you run the
Create Demand Schedule command within Demand Entry.
• If you leave this check box cleared, any new releases you generate will be added to the previous release
schedule.
Epicor ERP | 9.05.700 81

• Test Mode - When selected, this check box indicates that you are running this contract line in test mode.
Use this option while you are creating a custom program in order to test the results. This mode lets you and
your trading partners verify that the data results are correct before going into production mode. When you
are satisfied that your custom program is working correctly, clear this check box.
Header > Matching Sheet
Use the Header > Matching sheet to specify the parameters that the Demand Schedule Matching process (located
on the Demand Schedule section of the Demand Entry Actions menu) should use to match requests for updates
to existing demand schedule releases that have already been generated through this demand contract. These
are schedule update requests received on subsequent inbound EDI transactions sent by your customer trading
partner.
• You specify if a perfect match, or non-perfect match is being performed for the demand contract. A perfect
match is defined as one in which all criteria you select from the Options Available field (and appear in the
Options Selected field) match between the requests for demand schedule updates and existing demand
schedule releases that have already been generated through this demand contract. A non-perfect match is
defined as one in which at least one of the criteria (for example, shipping quantities or shipping dates) match.
• You specify if the Epicor application should automatically cancel all potential sales order releases that are
considered non-matches by the Demand Scheduling Matching program. These are requests for demand
schedule updates that do not match (perfect or non perfect) any existing demand schedule releases that have
already been generated through this demand contract.
You can also designate Cancel Non Match Options if needed. These allow you to specify a cancellation
exclusion date range (grace period) for non-matched sales releases. The Epicor application will skip cancellation
of non matched sales order releases with ship dates within this date range.
• You then specify which matching criteria should be used, and the hierarchical sequence in which they should
be applied during the matching process. These include reference number, Ship By date, quantity and Open/Close
status indicator.
• When it performs the actual demand matching, the Epicor application matches demand schedules according
to the parameters and hierarchy specified in this sheet. When it finds the matching demand schedule release,
it then automatically processes the request.
82 Epicor ERP | 9.05.700

The following are examples of perfect demand schedule matches (when the Allow Non Perfect Match check
box has been cleared for the associated demand contract):
Example 1: If your customer trading partner requests a change of the Need By date (for example, from August
15 to August 22) for a demand schedule release of 200, the Epicor application needs to find and match it to
the demand schedule release it applies to, based on the specified matching criteria, then update the quantities
and Ship By dates accordingly in the associated order release.
Referring to the following example, these order releases have already been created for demand schedules previously
generated for this customer trading partner:
• 100 with a Need By date of 11/27/09 and a Ship By date of 11/27/09,
• a release of 200 with a Need By date of 12/04/09 and a Ship By date of 12/01/09,
• and a release of 300 with a Need By date of 12/18/09 and a Ship By date of 12/15/09.
Epicor ERP | 9.05.700 83

You receive an inbound EDI transaction from your customer trading partner in which they request a change of
the Ship By date for the demand schedule release of 200. This is the demand schedule generated from that
change request:
According to the matching criteria you set up in the Header > Matching sheet for the demand contract against
which demand schedules were generated, it first matches by reference number, then by order quantity, then
by Ship By date, and finally by Open/Closed indicator. When demand for this new demand schedule is matched
by the Demand Schedule Matching process (located on the Demand Schedule section of the Demand Entry
Actions menu), this is the result:
84 Epicor ERP | 9.05.700

After performing this matching and running the Process selection (located on the Demand Header section of the
Demand Entry Actions menu), the Epicor application changes the order release for 200 (with an original Need
By date of 12/04/09 and a Ship By date of 12/01/09) to a new Need By date of 12/03/09 and a new Ship By
date of 11/24/09:
Example 2: If your customer trading partner requests a cancellation of the release with a Need By date of
12/03/09 and a Ship By date of 11/24/09, the Epicor application needs to find and match it to the demand
schedule release it applies to, based on the specified matching criteria, then update the quantities and Ship By
dates accordingly in the associated order release. It is a standard practice for your customer to send a zero
quantity change request for the original ship date. This is the demand schedule generated from that change
request:
Epicor ERP | 9.05.700 85

When demand for this new demand schedule is matched by the Demand Schedule Matching process (located
on the Demand Schedule section of the Demand Entry Actions menu), it closes (cancels) the matched schedule;
this is the result:
86 Epicor ERP | 9.05.700

After performing this matching and running the Process selection (located on the Demand Header section of the
Demand Entry Actions menu), the Epicor application changes the status of the order line from Open to Closed.
The Epicor application can also be configured to delete the order release instead of closing it. This can be designated
at the company level using the Cancel Schedules Action field in the Company Configuration > Modules > Sales
> Demand sheet.
These are the values you can modify for this item:
• Allow Non Perfect Match - Specifies if perfect or non-perfect matching is being performed by the Demand
Schedule Matching process (located on the Demand Schedule section of the Demand Entry Actions menu).
This program matches requests for demand schedule updates to existing demand schedule releases that have
already been generated through this demand contract. These are schedule update requests received on
subsequent inbound EDI transactions sent by your customer trading partner.
• Select the check box if non-perfect matching is being performed. A non-perfect match is defined as one
in which at least one of the criteria (for example, shipping quantities or shipping dates) you select from
the Options Available field (and appear in the Options Selected field) match between requests for
demand schedule updates and existing demand schedule releases.
Epicor ERP | 9.05.700 87

For example, if you have specified matching of schedule dates, order numbers and reference numbers, a
non perfect match is one in which only one of the criteria (for example, schedule dates) match between
the documents.
• Clear the check box if perfect matching is being performed. A perfect match is defined as one in which
all criteria you specify in the Options Selected field must match between the demand schedule updates
and existing demand schedule releases.
For example, if you have specified matching of schedule dates, order numbers and reference numbers, it
is considered a perfect match only if all of these parameters match exactly between documents. This is
the default value for this check box.
• Cancel Non Matched - Specifies if the Epicor application should automatically cancel all sales releases for
this demand contract that have not been matched by the Demand Schedule Matching process (located on
the Demand Schedule section of the Demand Entry Actions menu). The default comes from the Cancel Non
Matched field setting in the Customer Maintenance > Customer > Demand sheet for this customer trading
partner; this can be overridden for specific demand contracts.
• Select the check box if the Epicor application should automatically cancel all sales releases for this demand
contract that have not been matched by the Demand Schedule Matching process.
• Clear the check box if the Epicor application should not automatically cancel all sales releases for this
demand contract that have not been matched by the Demand Schedule Matching process.
• Exclude From / From (days) - If the Cancel Non Matched check box has been selected, use the Exclude
From check box and From (days) field as needed to specify a beginning date for a grace period for cancellation
non-matched sales releases. The Epicor application will skip cancellation of non matched sales order releases
within this date range.
• If you select this check box, and then enter 2 into the From (days) field, it designates that non matched
sales order releases with ship dates between the current system date and two days earlier than the current
date will not be cancelled by the Epicor application in the event of a non match (that is, when the associated
demand schedule update request does not match any existing demand schedule releases that have already
been generated through this demand contract).
For example, if the current system date is 1/25, the Epicor application will not cancel sales order releases
dated between 1/23 and 1/25 in the event of a non-match.
• Clear this check box if you do not wish to designate a grace period for cancellation of non-matched sales
releases.
• Exclude Until / Until (days) - If the Cancel Non Matched check box has been selected, use the Exclude
Until check box and Until (days) field as needed to specify an ending date for a grace period for cancellation
non-matched sales releases. The Epicor application will skip cancellation of non matched sales order releases
within this date range.
• If you select this check box, and then enter 2 into the Until (days) field, it designates that non matched
sales order releases with ship dates between the current system date and two days earlier than the current
date will not be cancelled by the Epicor application in the event of a non match (that is, when the associated
demand schedule update request does not match any existing demand schedule releases that have already
been generated through this demand contract).
For example, if the current system date is 1/25, the Epicor application will not cancel sales order releases
dated between 1/25 and 1/27 in the event of a non-match.
releases.
• Options Available - Displays the options available to match requests for updates to existing demand schedule
releases that have already been generated through this demand contract. These are schedule update requests
received on subsequent inbound EDI transactions sent by your customer trading partner. Refer to Options
88 Epicor ERP | 9.05.700

Selected for directions on how you select options and construct a hierarchical demand schedule matching
processing list.
• Quantity - Specifies that the order quantity should be used to match requests for updates to existing
demand schedule releases that have already been generated for this demand contract. The Epicor application
matches the Ship By date provided by your customer trading partner on the update requests to the order
quantity it finds on existing demand schedule releases.
• Ship By Date - Specifies that the Ship By Date should be used to match requests for updates to existing
demand schedule releases that have already been generated for this demand contract. The Epicor application
matches the Ship By date provided by your customer trading partner on the update requests to the Ship
By date it finds on existing demand schedule releases.
• Reference - Specifies that the unique reference number your customer supplies you should be used to
match requests for updates to existing demand schedule releases that have already been generated for
this demand contract. This is an agreed upon reference number you and your customer have agreed upon
that uniquely identified demand releases for the customer. It is the reference number entered or recorded
in the Reference field in the Demand Entry > Line > Detail sheet. The Epicor application matches the
reference number provided by your customer trading partner on the update requests to the reference
number it finds on existing demand schedule releases.
• Options Selected - Specifies the hierarchical order in which the Epicor application should match requests
(that are received on inbound EDI transactions sent by your customer trading partner) for updates to existing
demand schedule releases that have already been generated through this demand contract.
You construct the hierarchical processing list by selecting options displayed in the Options Available field,
and then clicking the appropriate directional buttons.
• For example, if you would want the Epicor application to first perform a Quantity match, you select
Quantity in the Options Available field, then click the single right arrow button.
• If you want it to next perform a Reference match, you then select Reference in the Options Available
field, then click the single right arrow button.
field, then click the up arrow button. For example, if Open is the fourth option listed, but you wish to
make it the second option, select it, then click the up arrow button.
• To remove a single option from the Options Selected field, select the option being removed, then click
the single left arrow button. For example, if you selected Ship By but wish to remove it, select it, then
click the single left arrow button.
• To remove all options from the Options Selected field, click the double left arrow button.
Creating Demand Entries for Existing Orders
Use the Create Demand Entries selection (on the Actions menus in Sales Order Entry or Customer Entry) as needed
during the initial EDI / Demand Management implementation to select existing sales orders and enable them so
they can be processed in the Demand Management module (using the Process Demands selections on the Demand
Entry and Demand Mass Review Actions menus). In effect, this allows you to enable existing sales for update in
Epicor ERP | 9.05.700 89

the future based on demand records you may receive from your trading partner via EDI. This selection can only
be accessed and used if the Demand Management module is licensed.
Note You must use Create Demand Entries (during initial implementation of EDI / Demand Management
processing) if you have been using the Epicor application to create existing sales orders and are now
planning on implementing and using the Demand Management module.
• When you use the Demand Management module, you can only process and update sales orders that were
originally created via the EDI / Demand Management functionality. This is a problem when you decide to start
using the Demand Management module to process demand records received via EDI and sales orders already
exist in the Epicor application.
• The Create Demand Entries selection allows you to select existing sales orders and enable them so they can
then be updatable based on EDI demand records imported using direct EDI import, Service Connect, or from
demand records manually entered into the Epicor application. In effect, the Create Demand Entries selection
reverses the Demand Processing procedure in that it creates demand records in the Epicor application from
existing sales orders.
Tip Once you have created initial demand entries for existing orders in your Epicor application database,
you would no longer use the Create Demand Entries option during ongoing EDI / Demand Management
processing. The Epicor application automatically generates demand entries for inbound EDI transactions
that have been successfully processed.
When you use Create Demand Entries, it creates demand records by populating the DemandHeader table using
the information stored in the OrderHed table, and the DemandDetail table using information stored in the OrderDtl
table.
• Prior to performing this processing, it validates that the bill to customer associated with the sales order has
been designated as a trading partner, and a demand contract has been created in Demand Contract Entry
for the customer/part combination on each sales order line. If these conditions are not satisfied, it simply
bypasses the selected sales order and does not create demand records.
• The Demand Management module must be licensed, and sales orders must exist in the Epicor application.
For each selected sales order, the associated bill to customer must be defined as a trading partner, and a
demand contract must have been created in the Demand Contract Entry program for the customer/part
combination for each sales order line.
To create demand entries for selected sales orders or customers:
• Click Select Orders to access the Sales Order Search window to select sales orders for processing.
• Click Process Orders to enable the selected sales orders for EDI / Demand Management processing.
90 Epicor ERP | 9.05.700

Inbound EDI Transaction File Mappings
When TIE KINETIX eVision receives an inbound EDI transaction from one of your trading partners, it generates a
text file with an .app file extension (see sample below). It then deposits this file in the destination directory on
your Epicor application server that was specified during configuration of TIE KINETIX eVision.
Through use of the Direct Import Process (or Service Connect), the Epicor application attempts to process the
inbound text file. Inbound EDI transaction are received by the EDI processor, mapped and converted into a tilde
delimited file that is stored in a shared folder that can directly imported into Epicor ERP, or can be read by Epicor
Service Connect. When successfully processed, this information becomes the basis for demand entries and
subsequent forecast, order, shipment and invoice transactions generated from the demand entries in the Epicor
application.
It is important that you gain familiarity with how these files are structured, and what information is contained
within them. Referring to the sample file above, we will break down this inbound file row by row, element by
element, describing what information is contained within it. Note that tildes (~) represent delimiters between
fields or data elements. The data descriptions that follow for the sample file are based on the latest version of
the approved Epicor Inbound EDI File Formats at the time of publication.
Note Epicor Software regularly updates the sequence and format of the inbound file layouts. This includes
added additional fields to support new functionality, as well as rearranging the sequence of the fields.
You must use the file remapping functions in TIE KINETIX eVision to ensure that the inbound EDI files you
receive from your customer trading partners are properly mapped to formats the Epicor application can
use. This applies to new users, as well as those users who are upgrading from previous versions
such as 9.04!
Epicor ERP | 9.05.700 91

Tip The content for the EDI / Demand Management Technical Reference Guide is updated for Service Pack
releases (for example, 9.05.608). For any file layout changes related to patch releases (for example
9.05.608A), refer to the Change List section of the appropriate Patch Guide.
EDI File Requirements and Formatting Rules
Use the following information to review the input file requirements for the EDI documents.
Your input files must follow this format exactly, or the EDI functionality will not run properly:
• Boolean values must be true or false. This must be in all lower case.
• Times must be expressed in one of these formats: 15:25:05, 15:25, 152505, 1525
• Dates must be in the format CCYYMMDD where:
• CC - Two digit century (for example, 20 for the 20th century, 21 for the 21st century)
• YY - Two digit year (for example, 11 for 2011, 12 for 2012)
• MM - Two digit month (for example, 01 for January, 12 for December)
• MM - Two digit day of the month
For example, January 25, 2012 would be expressed as 21120125.
Note For 9.05.607 and above, this is only date format that can be used for date entries on inbound
EDI files. This date format takes precedence over any other date format references (for example,
YYMMDD or DDMMYY) you may find in text or graphic examples in the remainder of this document.
Prior to 9.05.607, Service Connect successfully processed inbound EDI file containing dates expressed
in these older date formats. With the introduction of the Import EDI Demand Process in 9.05.607, only
the CCYYMMDD date format is acceptable for use; Service Connect and the Import EDI Demand Process
both generate errors if an inbound EDI file contains dates expressed in formats other than the
CCYYMMDD format.
• The file formats must exactly match the sample file Sample.txt, included as part of your Epicor application
installation. On a standard installation, the file is located in the
\\<server>\Epicor\MfgsysXXX\ESC\EDI\Demand directory, where XXX is the release version, such as 905.
92 Epicor ERP | 9.05.700

Record Hierarchy for Inbound EDI Files
Inbound EDI files that are processed must be expressed in the following row table hierarchy:
Table Type Key and Value
Demand Header (1) Mandatory Key: Landmark. Value = H
User_Defined for Demand_Header Optional Key: Landmark. Value = UD

(2-0)
Extra_Charges (2-1) Optional Key: Landmark. Value = EC (DemandMisc for

DemandHeader)
Demand_Detail (2-2) Mandatory Key: Landmark. Value = D (At least 1 record per
header)
User_Defined For Demand_Detail Optional Key: Landmark. Value = UD

(3-0)
Extra_Charges (3-1) Optional Key: Landmark. Value = EC (DemandMisc for

DemandDetail)
Smart String (3-1) Optional Key: Landmark. Value = SS (Smart String for
DemandDetail)
Demand_Schedule (3-2) Mandatory Key: Landmark. Value = SCH (At least 1 record
per detail)
User_Defined for Demand_Schedule Optional Key: Landmark. Value = UD

(4-0)
Epicor ERP | 9.05.700 93

Demand_Header Rows (Demand Header Record for DemandHead Table)
Demand Header rows in inbound EDI files contain descriptive header information that relates to the demand
detail rows linked to it. This is a mandatory; while an inbound EDI transaction file can contain multiple Demand
Header rows, at least one such row must exist in the inbound record.
• Demand Header rows contain header information that the Epicor application stores in a Demand Header
record in the DemandHead table, and uses to create or update demand entries that can be viewed in Demand
Entry.
• This information ultimately becomes the basis for order header records stored in the OrderHed table in the
Epicor application database, and are also used for forecast records stored in the Forecast table.
94 Epicor ERP | 9.05.700

Table Schematic for Demand_Header Row Sample
This is the table schematic for the Demand_Header row sample (H~1~0) illustrated above.
Note When Optional is listed in the Type column, it generally means you should select one of the available
options; leaving a Data Position blank is only allowed if specifically stated in the Sample Record Data
Element Description column. Leaving a Data Position blank when it is not explicitly allowed can lead to
possible problems or failures when the inbound EDI transaction record is being processed.
Row Example Plug-in Field or Type Sample Record Data Element Description
Data Record Data Dictionary
Position Value Name
1 H Record_Key Mandatory, The first character in each row of an inbound EDI

Character record denotes the record key and type of information
row.
Note Each record key is assigned to a specific
type of inbound EDI transaction row - each
record cannot be used interchangeably (for
example, you cannot use D (Demand Detail)
for a Header (H) type row):
• H - Header information stored in the Demand

Header record in the DemandHead table. This
contains descriptive header information that
relates to the demand detail rows linked to it.
• D - Demand detail information related to the
linked header, and is stored in the Demand_Detail
table. Refer to the sample data in the
Demand_Detail Rows section below for more
information.
• EC - Extra Charge information related to the linked
demand detail, and is stored in the Extra_Charges_
DemandMisc table. Refer to the sample data in
the Extra_Charges Rows section below for more
information.
• SCH - Demand schedule information related to
the linked demand detail, and is stored in the
Demand_Schedule table. Refer to the sample data
in the Demand_Schedule Rows section below
for more information.
• UD - User Defined information stored in the
User_Data (User data for Demand_Header record),
User_Detail (User Data for Demand_Detail record)
or User_Demand_Schedule tables.
Refer to the sample data in the User_Defined
Rows section below for more information.
2 1 Hierarchical Level Mandatory, Sequential row number in the inbound record (for
Numeric example, Row 1, Row 2, etc.); it must be unique per
file row. Used to keep track of data lines.
Epicor ERP | 9.05.700 95

Position Value Name
3 0 Hierarchical 0 (zero) for H Sequential hierarchical parent number to which this

Parent Number record row is linked. This denotes that the hierarchical
Mandatory,
parent to which it is linked is the first sequential row
Numeric for all
in the record.
types except H
Note This is a key data element in the
record - it indicates to the Epicor application
how the record rows are linked and how they
relate to each other.
Since Row 1 is the Header, it is assumed to be

the parent and must have a zero (0) in this
position. However, the second row of the sample
record is a User Defined row - it contains 1 in this
position.
• Referring to the third and forth rows in the sample
record, which are Extra Charge and Demand Detail
rows, they each contain a value of 1 in this
position. This denotes that the hierarchical parent
to which each is linked is the first sequential row
in the record (the Heading row).
• It denotes which the Demand rows relate to the
Header row, which the Schedule rows relate to
specific Demand rows, and which Extra Charge
rows relate to specific Header rows.
4 TDPDalton Tp_Id Mandatory, Identification number for the trading partner from
Character whom the EDI record has been received.
• The value that appears in this data position
must be a valid trading partner identification
number, as specified for the corresponding
customer number (identified in the CustNum
attribute - Data Position 8) in the Trading Partner
field in the Customer Maintenance > Customer >
Demand or Ship To > Demand sheets in the Epicor
application.
• It must also match the value of the trading partner
tied to the demand contract number specified in
the Contract_Nbr attribute (Data Position 7).
5 FIRM Tran_Type Mandatory, Specifies the type of transaction being processed. The
Character Epicor application only allows document transaction
types (assigned to the trading partner at the header
or ship to levels using the Documents > Detail sheet
in Customer Maintenance) as valid entries in this data
position.
• The transaction type specified in this data position
controls how the Epicor application will process
96 Epicor ERP | 9.05.700

Position Value Name
the corresponding documents, and if the
transaction will be processed to Sales Order and
Forecast tables.
• Refer to Defining Trading Partners in Customer
Maintenance for more details.
6 EPIC03 Company Mandatory, Identification number for the Epicor application

Character company into which the EDI transaction is being
received.
The value that appears in this data position must
be one of the valid company codes defined in
Company Maintenance in the Epicor application.
7 DALTONCON Contract_Nbr Mandatory, Identification number for the demand contract

Character associated with the EDI record.
must be a valid demand contract number,
previously entered into Demand Contract Entry in
the Epicor application.
• Refer to Entering Demand Contracts for more
details.
8 BUCKS CustID Mandatory, Identification number for the customer number

Character associated with the EDI record.
must be a valid customer identification
number, previously established in Customer
Maintenance in the Epicor application.
• Refer to Defining Trading Partners in Customer
9 No Value in BTCustNum Optional, Identification number for the bill to customer number
Example Character associated with the EDI record.
• If a value appears in this data position, it must
be a valid bill to customer identification
number, previously established in Customer
Maintenance in the Epicor application. Refer to
Defining Trading Partners in Customer
• If left blank, the default is the sold to customer.
If a value exists in this field, it should exist as an
alternate bill to number that is defined for the
customer.
Epicor ERP | 9.05.700 97

Position Value Name
10 PO:E905-001 PONum Mandatory, Identification number for the customer purchase order
Character associated with the demand contract. It denotes the
purchase order number your trading partner is using
to purchase the demand items from your company.
• For changes, the value that appears in this
data position must be a valid purchase order
number associated with the demand contract
number, as previously entered into Demand
Contract Entry in the Epicor application.
• Refer to Entering Demand Contracts for more
details.
Tip The concatenated demand contract
number and customer purchase order number
together form a primary key in the Epicor
application for resulting demand entry records.
11 No Value in ShipToCustID Optional, Ship to customer identification number. If blank, the

Example Character default is the sold to customer for the trading partner.
12 No Value in Ship_Code Optional, Indicates the ShipTo code for shipments generated
Example Character from this record.
• This should not be left blank; the value in this
position must exist in the ShipTo table for the sold
to customer in the Epicor application.
• The <blank> ship to references the main customer
address. This does not default to the ship to code
at the releases.
Denotes if a One Time Ship (OTS) address is being

13 No Value in UseOTS Optional,
used.
Example Boolean
14 No Value in DNS_Before Optional, Date Earliest date before which the order cannot be
Example shipped. Purchased items should not be shipped prior
to this date. This information is used in the Demand
Entry > Header sheet.
15 No Value in DNS_After Optional, Date Latest date after which the order cannot be shipped.
Example Purchased items should not be shipped after to this
date. This information is used in the Demand Entry
> Header sheet.
16 No Value in CancelAfterDate Optional, Date Latest date by which your trading partner wishes the
Example associated purchased items to be shipped to prevent
cancellation. Items that cannot be shipped prior to
this date should be cancelled.
98 Epicor ERP | 9.05.700

Position Value Name
17 No Value in FOB Optional, Indicates the Free On Board (FOB) point for shipments
Example Character generated from this record.
• Can be left blank, but if there is a value, it must
exist in the FOB table in the Epicor application.
• If left blank, the default value for transactions
generated from this record come from the
demand contract in the Epicor application.
18 BEST Ship_Via Optional, Indicates the ship via method for shipments generated
Character from this record.
exist in the ShipVia table in the Epicor application.
19 No Value in Terms_Code Optional, Indicates the sales terms for orders generated from
Example Character this record.
exist in the Terms table in the Epicor application.
20 No Value in Priority_Code Optional, Indicates the allocation priority for orders generated
Example Character from this record.
exist in the AllocationPriority table in the Epicor
application.
21 No Value in Ship_Complete Optional, Indicates if orders generated from this record must
Example Boolean be shipped complete. As an order release is selected
for picking during the Auto Pick process in the Order
Allocation program, all releases with a ship date less
than or equal to the given cutoff date also have to
be picked complete otherwise they will not be
selected.
• The default is true when the
Customer.ShippingQualifier is set to 0 (Ship Order
100% complete).
Epicor ERP | 9.05.700 99

Position Value Name
22 Ord Comm Order_Comment Optional, Contains comments for the overall order.
Character
These comments print on sales acknowledgements,
and also appear on the Order Comments sheets in
Demand Entry and Sales Order Entry after the Epicor
application generates demand entries and orders.
23 Inv Comm Invoice_Comment Optional, Contains invoice comments for the overall order. The
Character Epicor application copies them into the Invoice Detail
table as defaults.
These comments appear on the Invoice Comments
sheets in Demand Entry and Sales Order Entry after
the Epicor application generates demand entries and
invoices.
24 No Value in Order_Discount Optional, Indicates if order based discounting should be applied

Example Boolean automatically or manually triggered by the user as a
menu option.
If left blank, the default value comes from the
25 No Value in Test_Record Optional, Indicates if this row is being run in a test mode.
Example Boolean
26 No Value in PO_Type Optional, Indicates the purchase order type.

Example Character
27 No Value in Ack_Type Optional, Type of acknowledgement expected by the trading

Example Character partner.
28 No Value in Accept_Type Optional, Type of acceptance expected by the trading partner.

Example Character Valid types are as follows:
• Manual - The Epicor application or Service
Connect creates demand entries but you must
manually process them using the Process selection
in the Demand Header section in the Demand
Entry Actions menu. Order releases and forecast
entries are only created at the time you perform
this manual processing.
• Accept if no Errors - The Epicor application
should automatically process demand for this
customer trading partner only if there are no
errors in the inbound EDI document. This
eliminates the need to manually use the Process
100 Epicor ERP | 9.05.700

Position Value Name
selection in the Demand Header section of the
Demand Entry Actions menu to process the
demand.
• Always Accept - The Epicor application should
automatically process demand for this customer
trading partner, regardless of whether there are
errors in the inbound EDI document. This
automatically creates demand entries in the Epicor
application and immediately generates sales
order and forecast entries at the time the
inbound EDI file is successfully processed.
This is an override value for the Accept Type field
setting specified for the trading partner in the
Customer Maintenance > Document sheet.
Indicates if your customer trading partner would like

29 false ResetCums Optional,
to reset the cumulative quantities stored to-date for
Boolean
previous transactions related to this demand record.
If set to true, the Epicor application resets these
cumulative quantities.
Indicates if the resulting invoice for this demand

30 false ERSOrder Optional,
record should be flagged as an Evaluated Receipt
Boolean
Settlement invoice.
Indicates if the customer purchase order for this
31 false CancelPO Optional,
demand record should be cancelled.
Boolean
Transaction control number for the EDI message on

32 1 TCtrl_Number Optional,
which the demand was received. Used to track the
Character
document in the EDI processor.
Batch control number for the EDI message on which
33 1 Batch_Number Optional,
the demand was received. Used to track the
Character
document in the EDI processor.
34 73-11 Sched_Nbr Optional, Used as an EDI Reference of the inbound demand.

Character This value is used as the default schedule at the
schedules.
35 No Value in Cur_Code Optional, Indicates the currency code for orders and invoices
Example Character generated from this record.
exist in the Currency table in the Epicor
application.
Epicor ERP | 9.05.700 101

Position Value Name
36 No Value in Lock_Rate Optional, Used with the Currency module. When set to true,
Example Boolean the currency rate can be changed by the user and
cannot be changed by the Epicor application.
37 No Value in OTSName Optional, OTS customer name.

Example Character
Note If UseOTS (Data Position 13) is set to
true, this is a mandatory entry.
38 No Value in OTSAddress1 Optional, First address line of the OTS drop ship mailing
Example Character address.
39 No Value in OTSAddress2 Optional, Second address line of the OTS drop ship mailing
40 No Value in OTSAddress3 Optional, Third address line of the OTS drop ship mailing
41 No Value in OTSCity Optional, City for the OTS drop ship mailing address.
Example Character
42 No Value in OTSResaleID Optional, Resale identification number (if any) for the OTS drop
Example Character ship mailing address.
43 No Value in OTSState Optional, State or province name for the OTS drop ship mailing
44 No Value in OTSZip Optional, Zip or postal code for the OTS drop ship mailing
45 No Value in OTSCountry Optional, Country portion of the OTS drop ship mailing address.
Example Character
46 No Value in OTSFaxNum Optional, OTS fax number.

Example Character
47 No Value in OTSPhoneNum Optional, OTS telephone number.

Example Character
48 No Value in OTSContact Optional, OTS contact name.

Example Character
49 false OTSSaveCustID Optional, Denotes if OTS information is being saved as an actual

Boolean customer ID in the Epicor application.
102 Epicor ERP | 9.05.700

Position Value Name
50 No Value in OTSSaveAs Optional, Denotes the type of record in which OTS information
Example Character is being saved in the Epicor application.
• blank - No saved OTS information
• C - Saved in Customer record
• P- Saved in Prospect record
• S- Saved in Suspect record
• T- Saved in Ship To record
51 - 60 Custom1 EDI_Custom1 Optional, Fields reserved for EDI custom development.

Character
Custom10
Epicor ERP | 9.05.700 103

User_Defined Rows
User_Defined rows are designed to receive Date, Decimal, Integer, Character, Number, Date, Checkbox and Short
Character data from your trading partner. This information is stored in user-defined attributes in the Epicor
application.
These values support customizations within the Epicor application; refer to the Customization Guide for more
details about the specific use of user defined fields.
User_Defined rows can be linked to specific Demand_Header, Demand_Detail and Demand_Schedule rows in
inbound EDI records. This row type is Optional.
104 Epicor ERP | 9.05.700

Table Schematic for User_Defined Row Sample
This is the table schematic for the User_Defined row sample; it only covers the contents of the first User_Defined
row (UD~2~1) illustrated above. The other User_Defined rows follow the same format.
Row Data Example Plug-in Field or Type Sample Record Data Element
Position RecordData Dictionary Name Description
Value
1 UD Record_Key Mandatory, User Defined information related to

Character the linked record line, and is stored in
the User_Field table.
2 2 Hierarchical Level Mandatory, Sequential row number in the inbound

Numeric record (for example, Row 2); it must
be unique per file row. Used to keep
track of data lines.
3 1 Hierarchical Parent Mandatory, Sequential hierarchical parent number

Number Numeric to which this record line is linked.
The second line of the sample record
is a User_Defined line - it contains 1
in this position. This denotes that the
hierarchical parent to which it is linked
is the first sequential record line (in
this case, the Header record line).
User_Defined can also be linked to:
Demand_Detail rows - UD~5~4 is
linked to Demand Detail row 4.
Demand_Schedule rows - UD~8~7
is linked to Demand Schedule row 7.
4-7 No Value in UserChar1 -UserChar4 Character User defined Character field.

Example
8-11 No Value in UserDate1 - UserDate4 Date User defined Date field.

Example
No Value in
12-13 UserDecimal1 - Decimal User defined Decimal field.
Example
UserDecimal2
14-15 No Value in UserInteger1 - Integer User defined Integer field.

Example UserInteger2
16-25 No Value in Character01-Character10 Character User defined Character field.

Example
26-45 No Value in Number01 - Number20 Number User defined Number field.

Example
Epicor ERP | 9.05.700 105

Row Data Example Plug-in Field or Type Sample Record Data Element
Position RecordData Dictionary Name Description
Value
46-65 111029~ 111029 Date01 - Date20 Date User defined Date field. In this
example, 11/29/2010.
66-85 No Value in CheckBox01 - Boolean User defined Checkbox field.

Example CheckBox20
86-95 No Value in ShortChar01 - Character User defined Short Character field.

Example ShortChar10
106 Epicor ERP | 9.05.700

Extra_Charges Rows (DemandMisc Table for DemandHeader and DemandDetail Records)
Extra Charge rows in inbound EDI files contain extra charge data (such as rush or expedite fees) that relate to
the Demand Header or Demand Detail rows to which they are linked.
The Epicor application stores this information in the DemandMisc table and then uses it to generate invoice
charges for orders created from demand entries. This row type is Optional.
Epicor ERP | 9.05.700 107

Table Schematic for Extra_Charges Row Sample
This is the table schematic for the Extra_Charges row sample; it only covers the contents of the first Extra_Charge
row (EC~3~1) illustrated above. The other Extra_Charge row follows the same format.
Row Example Plug-in Field or Dictionary Type Sample Record Data Element Description
Data Record Name
Position Data
Value
1 EC Record_Key Mandatory, Extra Charge information related to the

Character linked Demand Header or Demand Detail,
which is stored in the DemandMisc table.

Numeric record (for example, Row 3); it must be
unique per file row. Used to keep track of
data lines.
3 1 Hierarchical Parent Number Mandatory, Sequential hierarchical parent number to

Numeric which this record line is linked.
• The third line of the sample record is an
Extra Charge line - it contains 1 in this
position.
• This denotes that the hierarchical parent
to which it is linked is the first sequential
record line (in this case, the Header record
line).
4 FRGT Ec_Code Mandatory, Code that identifies the extra charge. The
Character value must exist in the MiscCharges table in
5 Freight Ec_Desc Optional, Description of the extra charge.

Character
If left blank, the Epicor application uses the
description for the miscellaneous charge code
stored in the MiscCharges table.
6 E Freq_Code Optional, Denotes the frequency at which this extra

Character charge is assessed:
• F - First
• L - Last
• E - Every
• If left blank, the Epicor application uses
the value defined for the miscellaneous
code in the FrequencyCode table. This
field can be used to override this value.
108 Epicor ERP | 9.05.700

Row Example Plug-in Field or Dictionary Type Sample Record Data Element Description
Data Record Name
Position Data
Value
7 A Type Mandatory, Denotes the Extra Charge value type:

Character
• A -Amount
• P - Percentage
Designates if the extra charge value is an
8 No Value Percent Optional, If Data position 7 (Type) is set to P

in Numeric (Percentage). this is the percentage amount.
Example
• If Extra charge line is tied to a
Demand_Header line, when an invoice
is generated for the result demand order,
the Epicor application calculates the
invoice charge as a percentage of the
total invoice amount.
• If Extra charge line is tied to a
Demand_Detail line, when an invoice is
generated for the result demand order,
the Epicor application calculates the
charge as a percentage of the invoice
amount for the demand order line.
9 200 Doc_Ec_amount Optional, If Data position 7 (Type) is set to A (Amount),

Numeric this is the extra charge amount in the base
currency.
If left blank, the Epicor application uses the
value defined for the miscellaneous code in
the MiscCharges table.
10-17 Custom1, EDI_Custom01-EDI_Custom10 Optional, Not used. Reserved for future development.
Custom Character
10
Epicor ERP | 9.05.700 109

Demand_Detail Rows (Demand Detail Record for DemandDetail Table)
Demand Detail rows in inbound EDI files contain descriptive demand detail information that relates to the Demand
Header row to which it is linked.
• They contain detailed information that the Epicor application stores in Demand_Detail records in the
DemandDetail table and uses to create individual demand entries that can be viewed in Demand Entry.
• This information ultimately becomes the basis for order line detail records stored in the OrderDtl table in the
Epicor application database; these can be viewed in Order Entry.
110 Epicor ERP | 9.05.700

Table Schematic for Demand_Detail Row Sample
This is the table schematic for the Demand_Detail row sample; it only covers the contents of the first Demand_Detail
row (D~4~1) illustrated above. The other Demand_Detail row follows the same format.
Data Record Data Dictionary Name
Position Value
1 D Record_Key Mandatory, Demand detail information related to the linked

Character header, and is stored in the Demand_Detail table.
2 4 Hierarchical Level Mandatory, Sequential row number in the inbound record (for
Numeric example, Row 4); it must be unique per file row.
This is used to keep track of data lines.
3 1 Hierarchical Parent Mandatory, Sequential hierarchical parent number to which

Number Numeric this record row is linked.
• The fourth row of the sample record is a
Demand-Detail row - it contains 1 in this
position.
• The hierarchical parent to which it is linked is
the first sequential record row (in this case, the
Header record row).
4 No Value in PONum Optional, Identification number for the customer purchase

Example Character order associated with the demand contract. It
denotes the purchase order number your trading
partner is using to purchase the demand items
from your company.
• If the value in this data position is different than
data position 10 (PONum) in the associated
Demand Header row, the Epicor application
uses the PO number defined at the line level
as the PO number for the DemandDetail and
OrderDtl table records in the Epicor application
database.
• If left blank, the default value for the
DemandDetail and OrderDtl tables comes from
the PONumber data position in the Header
row.
Note It is best practice to ALWAYS
include the PONum value for each
Demand Detail line, even if it is the
same as in the Demand Header row.
Leaving the field blank may possibly
cause problems when processing
inbound EDI records.
Epicor ERP | 9.05.700 111

Position Value
5 No Value in POLine Optional, Your trading partner's purchase order line item
Example Character reference number.
6 No Value in Plant Optional, Identification number for the Epicor application

Example Character ShipFrom Plant. This data position is normally blank
- the Epicor application uses the value in the Plant
data position in the Header row.
Note Refer to Appendix D: Demand
Management Plant Code Assignment
Flowchart for details on how plant codes
are assigned to demand records generated
from inbound EDI transactions.
7 No Value in Tran_Type Mandatory, Document that initiated the demand. Will be blank
Example Character when the demand is manually entered. Used as a
default for the release.
TranType data position in the Header row.
Note It is best practice to ALWAYS
include the Tran_Type value for each
Demand Detail line, even if it is the
same as in the Demand Header row.
Leaving the field blank may possibly cause
problems when processing inbound EDI
records.
8 No Value in TestRecord Optional, Determines if this line is being run in a test mode.
Example Boolean
If left blank, the default value comes from the Test
Record data position in the Header row.
9 No Value in DNS_Before Optional, Date Earliest date on which trading partner wishes the
Example demand items on this line to be shipped.
Purchased items should not be shipped prior to
this date.
DNS_Before data position in the Header row.
10 No Value in DNS_After Optional, Date Latest date by which your trading partner wishes
Example the demand items on this line to be shipped.
Purchased items should not be shipped after this
date.
DNS_After data position in the Header row.
112 Epicor ERP | 9.05.700

Position Value
11 No Value in DemandReference Optional, Unique identifier to match incoming demand to

Example Character the Epicor application demand. Can be used to
locate other sales order detail records that have
been created by this demand.
12 1032X050 PartNum Optional, Your internal part number used to identify the line
Character item part.
• It can be left blank by your trading partner if
they are providing their own (different) part
number in Position 14.
• The part number that appears in this data
position does not have to exist in the Part table.
If it does not exist in the demand contract, the
Epicor application automatically creates a new
contract line in Demand Contract Entry.
• In order for the Epicor application to properly
recognize customer parts cross referenced to
your internal part number, the part validation
options for the customer document (transaction
type) should be configured properly at the
header or ship to levels using the Customer
Maintenance > Documents > Detail sheet.
• Refer to Defining Trading Partners in
Customer Maintenance for more details.
Note The PartNum (Position 12) and CustPn
(Position 14) data positions are the key data
elements in a Demand Detail row. If
XPartNum (Position 14) is being used
for a given Demand Detail row,
PartNum should not be used (and vice
versa.) Using both prevents XPartNum from
being considered by the Epicor application.
13 No Value in Rev_Level Optional, Denotes the revision number for the part. If a value
Example Character appears in this data position, it should be a valid
revision for the part, as defined in the Part Master
table in the Epicor application.
14 CUST1032 XPartNum Optional, Your trading partner provides their customer part
x050 Character number in this data position if they use a different
part number than your internal part number. The
XPartNum and PartNum provide defaults for each
other using the PartXref table.
• The XPartNum can be blank, and does not have
to exist in the PartXref table. If there is not a
Customer Part record for the value received in
Epicor ERP | 9.05.700 113

Position Value
this field, the Epicor application automatically
creates it.
• The same caveat about proper recognition of
customer parts in the Epicor application
(expressed in the PartNumber explanation
above) also applies to this data position.
Note The PartNum (Position 12) and CustPn
(Position 14) data positions are the key data
elements in a Demand Detail row.If
XPartNum is being used for a given
Demand Detail row, PartNum (Position
12) should not be used (and vice versa).
Using both prevents XPartNum from being
considered by the Epicor application.
15 No Value in XPartRevLevel Optional, Revision level number for the customer part
Example Character number.
16 No Value in Item_Desc Optional for Identifies the line item description.

Example Part Master
• If the part is a Part Master part, the default
Parts,
value comes from the description stored in the
Character
Part Master part.
Mandatory for • If this data position is not blank, the content
Non-Part overrides the description from the Parts Master
Master parts, in the Epicor application. If a value exists in this
Character data position, it replaces the Part Master
description on this demand entry ONLY.
•
17 EA SalesUM Optional, Unit Of Measure code that denotes how the item
Character is issued. If left blank, the default value comes
from the demand contract or from the Part Master
record.
18 No Value in Discount Percent Optional, Line item discount percent. It is not related to price
Example Numeric break discounts. If left blank, the default value
comes from the demand contract or from the Part
Master record.
19 10.00 UnitPrice Optional, Unit price that becomes the unit customer price
Numeric in Demand Entry.
Note This is a key data element in a
Demand Detail row.
20 false UsePriceList Optional, Indicates if the Customer Price List should be used
Boolean for order pricing for this Demand Detail row.
114 Epicor ERP | 9.05.700

Position Value
21 No Value in PricePerCode Mandatory, Indicates the Pricing Per quantity.

Example Character
• E - per Each
• C - per Hundred
• M - per Thousand
The Epicor application uses this to calculate the
extended unit price for the line item.
• It uses Part.PricePerCode as a default, but if
the Part record does not exist, it uses then
default is set to E.
• When used with Service Connect processing,
if left blank , the default value comes from the
contract. When using Direct Import processing,
it is a mandatory entry and cannot be left
blank!
22 No Value in ProjectID Optional, Identification number of the associated project (if

Example Character any).
• Valid values are the project codes defined in
• If left blank, the default value comes from the
demand contract.
23 No Value in PriceGroupCode Optional, Price Group ID used to price the order line. Valid
Example Numeric values are the price group codes defined in the
Epicor application.
24 No Value in POType Optional, Indicates the purchase order type. Reference only.
Example Character
25 No Value in Ack_Type Optional, Type of acknowledgement expected by the trading

Example Character partner for this demand contract line.
• OutSOAck - Outgoing Acknowledgement
• OutChgRsp - Outgoing Response to Change
• OutStatus - Outbound Order Status
26 No Value in ScheduleType Optional, Schedule type from the trading partner. Reference
Example Character only.
27 false Delete_Current Optional, Indicates if current open Order Releases that have
_Release Boolean not been shipped and do not have a job should
be deleted when processing the demand.
demand contract.
Epicor ERP | 9.05.700 115

Position Value
28 No Value in Mktg_Campaign_ID Optional, Link to the marketing event associated with this
Example Character record. Maintainable using Demand Entry if the
CRM module is installed.
demand contract.
29 No Value in MktgEvntSeq Optional, he related Marketing Event Sequence. It is a mirror

Example Numeric image of the QuoteHed MktgEventSeq, and is
maintainable using Demand Entry if the CRM
Module is installed.
demand contract.
30 No Value in Forecast_End_Date Optional, Date Date at which this forecast is no longer considered
Example effective. This is information purposes only, and
is reserved for future use in the Epicor application.
31 No Value in CumulativeQty Optional, Cumulative quantity that your trading partner

Example Numeric reports as being received to-date for this demand
line.
32 No Value in CumulativeDate Optional, Date Effective date for the cumulative quantity reported
Example in Position 31.
33 No Value in StartCumQty Optional, Starting cumulative quantity for this demand line.
Example Numeric
34 No Value in StartCumDate Optional, Date Starting date for the cumulative quantity reported
Example in Position 33.
35 No Value in LastShipmentQty Optional, Quantity received on the last shipment for this
Example Numeric demand line, as reported by your customer trading
partner.
36 No Value in LastShipmentDate Optional, Date Date on which the last shipment was received, as
Example reported by your customer trading partner.
37 No Value in LastShipmentID Optional, Last shipment identification number.

Example Character
38 No Value in LastMasterPack Optional, Last master pack identification number.

Example Character
39 - 48 Custom1 - EDI_Custom01 Optional, Not used. Reserved for future development.

Custom10 through Character
EDI_Custom10
116 Epicor ERP | 9.05.700

Demand_Schedule Rows (Demand Schedule Record for DemandSchedule Table)
Demand Schedule rows in inbound EDI files contain descriptive demand schedule information that relates to the
Demand Detail row to which it is linked. They contain detailed information that the Epicor application stores in
Demand_Schedule records in the DemandSchedule table and then uses to create release schedule lines for
individual demand entries.
• A demand schedule is a schedule of order releases. It defines both the part quantities and the dates on which
each release needs to be shipped to your customers.
• While demand schedules can be entered manually into Demand Entry, most of them will be generated from
Demand Schedule rows on the incoming document.
• This information ultimately becomes the basis for order release records stored in the OrderRel table in the
Epicor application database, and are also used for forecast records stored in the Forecast table.
Epicor ERP | 9.05.700 117

Table Schematic for Demand_Schedule Row Sample
This is the table schematic for the Demand_Schedule row sample; it only covers the contents of Demand_Schedule
row (SCH~12~11) illustrated above. The other Demand_Schedule row follows the same format.
Row Example Plug-in Field or Type Sample Record Data Element

Data Record Data Dictionary Name Description
Position Value
1 SCH Record_Key Mandatory, Demand schedule information related to

Character the linked Demand Detail line. The Epicor
application stores this data in the
Demand_Schedule table.

Numeric record (for example, Row 12); it must be
unique per file row. Used to keep track of
data lines.
3 11 Hierarchical Parent Mandatory, Hierarchical parent number to which this

Number Numeric record line is linked.
• The twelfth line of the sample record
is a Schedule line - it contains 11 in this
position.
• This denotes that the hierarchical
parent to which it is linked is the
eleventh sequential record line (in this
case, Demand Detail record line 11).
4 No Value in Plant Mandatory, Must be blank. Default value comes from

Example Character the Plant data position in the Header row.
5 FIRM Tran_Type Mandatory, Specifies the type of transaction being

Character processed. The Epicor application only
allows document transaction types
(assigned to the trading partner at the
header or ship to levels using the
Documents > Detail sheet in Customer
Maintenance) as valid entries in this data
position.
6 No Value in Demand_ Reference Optional, The Epicor application uses this for
Example Character informational purposes and to aid in
matching demand schedules with existing
records in the OrderRel table. Supplied by
EDI.
7 60 Quantity Optional, Quantity, expressed in Our U/M, that your

Numeric trading partner is requesting be shipped
118 Epicor ERP | 9.05.700


Position Value
for this release. This must either be null or
greater than zero.
• Precision: Explicit(2)
• PSign: None
• NSign: None.
Note This is a key data element
in a Demand Schedule row.
8 EA SalesUM Optional, Unit Of Measure code that denotes how

Character the item is issued.
• If this is a valid part, the Epicor
application uses the default Part.SUM
(defined for the internal part number
in the Sales UM field in Part
Maintenance).
• If left blank, the default value comes
from the demand line.
9 false Test_Record Optional, Indicates if the line is being used in a test

Boolean mode.
10 No Value in ShipToCustID Optional, Identification number for the customer

Example Character number for the ShipTo value in Position
11; the Epicor application uses this for the
scheduled release record.
• It must be a valid customer
identification number, previously
established in Customer Maintenance
in the Epicor application. Refer to
Defining Trading Partners in
Customer Maintenance for more
details.
• If left blank, the default value is the
main sold to customer, usually from
Customer data position in the Header
row.
Epicor ERP | 9.05.700 119


Position Value
11 No Value in Ship_Code Optional, Indicates the ShipTo code for the shipment
Example Character schedule release generated from this
record.
• Can be left blank, but if there is a
value, it must exist in the ShipTo table
in the Epicor application.
• If left blank, the default value for
schedule releases generated from this
record come from the Ship_Code in the
Header row.
Denotes if a One Time Ship (OTS) address

12 true UseOTS Optional,
is being used for the shipment.
Boolean
13 No Value in SubShipTo Optional, Sub ShipTo address if it is being used for

Example Character the shipment.
14 No Value in ShipRouting Optional, Sub routing address if it is being used for

Example Character the shipment.
Mark For customer identification number,

15 No Value in MFCusNum Optional,
if being used for the demand schedule.
Example Character
Mark For ship to identification number, if

16 No Value in MFShipToNum Optional,
being used for the demand schedule.
Example Character
Denotes if a One Time Mark For (OTMF)

17 false UseOTMF Optional,
address is being used for the shipment.
Boolean
18 No Value in ShipVia Optional, Indicates the ShipVia method for the

Example Character shipment schedule release generated from
this record.
• Can be left blank, but if there is a
value, it must exist in the ShipVia table
If left blank, the default value for schedule
releases generated from this record come
from the Ship_Code in the Header row.
19 20111015 NeedByDate Mandatory, Date Date by which your trading partner needs
the item to be delivered.
120 Epicor ERP | 9.05.700


Position Value
20 20111001 ShipByDate Optional, Date Date which the item needs to be shipped
in order to meet your trading partner's due
date.
If left blank, the Epicor application
calculates it based on the Delivery Days
defined for the ship to customer, and the
customer periodicity. If it exists, the import
process honors the date.
21 No Value in RAN Optional, Return Authorization Number. Used for

Example Character informational purposes and to aid in
matching demand schedules with existing
records in the OrderRel table. Supplied by
EDI.
22 No Value in Delivery_Days Optional, Integer Number of delivery days required for the
Example shipment to reach its destination. The
default for the Epicor application comes
from Customer.DemandDeliveryDays or
ShipTo.DemandDeliveryDays.
If left blank, the default value comes from
the Delivery Days parameter defined for
the customer ship to record. If it exists, the
import process honors the value.
23 No Value in Rejected_By_User Optional, Indicates if the DemandSchedule has been

Example Boolean rejected by the user.
24 No Value in Override_System_Reject Optional, Indicates if the system rejection should be

Example Boolean overridden so the record can be accepted.
25 No Value in Forecast_End_Date Optional, Date Date when this forecast is no longer

Example considered effective. For information
purposes only. Reserved for future use in
26 No Value in Dock_Code Optional, Dock_Code defined for the ship to address.

Example Character Reserved for future use in the Epicor
application.
27 No Value in Location Optional, Location within the customer ship to

Example Character address. Reserved for future use in the
Epicor application.
Epicor ERP | 9.05.700 121


Position Value
28 No Value in Transport_ID Optional, Code associated with the transport

Example Character routing. Reserved for future use in the
Epicor application.
29 No Value in Ship_By_Time Optional, Time of day by which the goods should be

Example Character shipped on this schedule release.
30 DALTON OTS OTSName Optional, Full name for the One Time Ship (OTS)
Character drop shipment.
Note If UseOTMF (Data Position 17)
is set to true, this is a mandatory
entry.
31 600 Main Rd OTSAddress1 Optional, First address line of the OTS address.
Character
32 No Value in OTSAddress2 Optional, Second address line of the OTS address.

Example Character
33 No Value in OTSAddress3 Optional, Third address line of the OTS address.

Example Character
34 Miami OTSCity Optional, City of the OTS address.

Character
35 Florida OTSState Optional, State or province for the OTS address.

Character
36 64460 OTSZip Optional, Zip or postal code for the OTS address.
Character
37 3 OTSCountry Optional, Country portion for the OTS mailing

Character address.
38 No Value in OTSFaxNum Optional, OTS fax number.

Example Character
234-1212 OTSPhoneNum OTS telephone number.

39 Optional,
Character
40 Jerry OTSResaleID Optional, OTS resale identification number.

Character
41 No Value in OTSContact Optional, OTS contact name.

Example Character
122 Epicor ERP | 9.05.700


Position Value
42 false OTSSaveCustID Optional, Denotes if the OTS information is being

Boolean saved as an actual customer ID in the
Epicor application.
43 No Value in OTSSaveAs Optional, Denotes the type of record in which OTS

Example Character information is being saved in the Epicor
application.
• blank - No saved OTS information
• C - Saved in Customer record
• P- Saved in Prospect record
• S- Saved in Suspect record
• T- Saved in Ship To record
44 false DropShip Optional, If set to true, designates the items on this

Boolean Demand Schedule should be drop shipped
by the supplier directly to the customer.
This marks the resulting sales order release
record (that will be generated for this
Demand Schedule) as "shipped" and also
marks the drop ship purchase order release
tied to it as "received".
45 No Value in OTMFName Optional, Full name for the One Time Mark For
Example Character (OTMF) drop shipment.
Note If UseOTS (Data Position 12)
is set to true, this is a mandatory
entry.
46 No Value in OTMFAddress1 Optional, First address line of the OTMF drop ship
Example Character mailing address.
47 No Value in OTMFAddress2 Optional, Second address line of the OTMF drop ship
48 No Value in OTMFAddress3 Optional, Third address line of the OTMF drop ship
49 No Value in OTMFCity Optional, City of the OTMF drop ship mailing

50 No Value in OTMFState Optional, State or province for the OTMF drop ship
51 No Value in OTMFZip Optional, Zip or postal code for the OTMF drop ship
Epicor ERP | 9.05.700 123


Position Value
52 No Value in OTMFContact Optional, OTMF contact name.

Example Character
53 No Value in OTMFFaxNum Optional, OTMF fax number.

Example Character
OTMFPhoneNum OTMF telephone number.

54 No Value in Optional,
Example Character
55 No Value in OTMFCountry Optional, Country portion for the OTMF drop

Example Character shipment mailing address.
EDI_Custom01- Fields reserved for EDI custom

56 - 65 Custom1 - Optional,
EDI_Custom10 development.
Custom10 Character
124 Epicor ERP | 9.05.700

Smart String Rows (for Demand_Detail Table)
Smart String rows pass the input parameters for configured parts. This is the Smart String that configuration
routines in the Epicor application are able to convert into the inputs required to configure a part.
Refer to the Configurator Technical Reference for more details about the use of Smart String parameters in
the Configurator.
Epicor ERP | 9.05.700 125

Table Schematic for Smart String Row Sample
This is the table schematic for the Smart String row sample; it only covers the contents of the first Smart String
row (SS~14~13) illustrated above.
Row Example RecordData Value Plug-in Type Sample Record Data Element
Data Field or Description
Position Dictionary
Name
1 SS Record_Key Mandatory Smart String information related

to the linked record line, and is
stored in the Smart_String table.
2 14 Hierarchical Mandatory, Sequential row number in the

Level Numeric inbound record (for example, Row
14); it must be unique per file row.
Used to keep track of data lines.
3 13 Hierarchical Mandatory, Sequential hierarchical parent

Parent Numeric number to which this record line
Number is linked.
• The fourteenth line of the
sample record is a
User_Defined line - it contains
13 in this position.
• This denotes that the
hierarchical parent to which it
is linked is the first sequential
record line (in this case, the
DemandDetail row 13).
4 CFG-CV.23.00Delrintrue23.00Silver234 Smart String Character Input parameters being passed for

configured parts. This is the Smart
String that configuration routines
in the Epicor application are able
to convert into the inputs required
to configure a part.
126 Epicor ERP | 9.05.700

Direct Inbound EDI Transaction Import
This section guides you through the process of directly importing inbound EDI transactions into Epicor ERP.
Inbound text-based EDI transactions received from your customer trading partners and passed by the eVision
third-party application directly link to the Epicor application using the Import EDI Demand Process.
These are the key features of the direct Import EDI Demand Process:
• The Import EDI Demand Process was introduced in 9.05.607, runs on server code and significantly improves
the speed of inbound EDI transaction importation by making use of the scheduling and multiprocessor
capabilities of Epicor ERP. You can still use Epicor Service Connect, but Epicor recommends using the direct
Import EDI Demand Process due to significantly improved processing performance.
• Users manage the entire importation and error correction process using standard Epicor ERP menu items. You
use the Import EDI Demand Process menu selection to perform the actual importation process. It honors
the layout of the tilde delimited source file, and allows for scheduling of inbound EDI transaction importation.
• The Demand Workbench can be used as required to efficiently detect and correct errors on inbound EDI
transactions you are attempting to import into Epicor ERP.
Scheduling and Running the Import EDI Demand Process
You manage the direct import of inbound EDI transactions using the Import EDI Demand Process. It utilizes
Epicor ERP framework to process demand records received via EDI transactions from your trading partners. It can
be used to import files based on a defined schedule and to specify the import folder where the inbound EDI
documents have been deposited by the TIE KINETIX eVision third-party program.
The following section describes the Import EDI Demand Process values you can change.
Import EDI Demand Process

Sales Management > Demand Management > General Operations > Import EDI Process
These are the values you can modify:
Epicor ERP | 9.05.700 127

Tip Only those fields that are of particular importance to demand processing are covered in this document.
Refer to the Epicor Application Help for complete details about the use of the Import EDI Demand Process.
• Import Folder - Specify the path to the import folder where EDI process expects to find .app documents
deposited by the TIE KINETIX eVision third-party program. The default value is defined in Import Folder field
in the Company Configuration > Modules > Sales > Demand sheet.
• Note The specified folder path must use UNC-naming conventions, not a locally-mapped drive letter.
• Backup processed file - Select this check box to create a backup folder within the import folder location;
all processed files are then backed up into the newly created folder.
• Continuous Processing - Select this check box if you want the process to run continuously.
• Continuous Processing Delay - Specify how frequently, in minutes, you want the Import EDI Demand
Process to retrieve inbound EDI transactional data from the specified import folder location.
• Log Filename - Specify the name of the file that lists the activity of transferred data.
• Schedule - From this list, select the schedule option during which you would like the process to run. Options
include Now, Startup Task Schedule and any other user-defined schedules created for your company.
• Recurring - Select this check box to indicate that the process should be run on a repeating basis. This check
box is available only if a schedule other than Now is selected.
Using the System Agent and Completing the Import EDI Demand Process
You can use the Schedules sheets within System Agent Maintenance to add schedules to a specific system agent.
Create a schedule that best satisfies your demand management requirements.
128 Epicor ERP | 9.05.700

To launch the process, click the Submit button. The status balloon displays by the System Monitor icon.
After you define a new schedule, you can select it in Import EDI Demand Process.
Tip The Import EDI Demand Process transforms EDI files (dropped into the import folder) one by one. To
speed up transaction importation, you can submit several processes at once. Any questions regarding the
system performance should be addressed to your System administrator.
Using the Demand Workbench for Error Correction
If erroneous data is identified during direct EDI import processing, you can correct it as required using Demand
Workbench, found within the General Operations folder of the Demand Management module.
Data import errors occur primarily due to mismatches between the data sent by your customer trading partner
on an inbound EDI transaction and corresponding data stored in your Epicor application.
Example If the demand contract specified on the inbound EDI transaction is not valid for the trading
partner, or cannot be found in the Epicor application database, a Demand Header Invalid Contract message
displays on the Detail > Header > Errors sheet.
First, search for any potential errors that occurred while running the Import EDI Demand Process.
Epicor ERP | 9.05.700 129

Use the Errors sheets found at the Header, Line and Schedule level to identify a reason for the error.
After you identify the error, correct the value that caused the import to fail.
130 Epicor ERP | 9.05.700

Note You cannot create new demand entries using Demand Workbench. This program is only used
to correct entries that failed to be processed using the Import EDI Demand Process.
After you correct invalid data on inbound EDI transactions, from the Actions menu, select Ready To Process.
Once you select this option, the inbound EDI transaction that failed to be loaded into the Demand Management
module ready for re-processing next time the Import EDI Demand Process is scheduled to run.
Epicor ERP | 9.05.700 131

To process the corrected demand entries immediately, from the Actions menu, select Process IM Demand. The
Import EDI Demand Process window displays, allowing you to submit the process.
Once the EDI transaction is completed successfully, a new demand record is created in Epicor ERP.
Note The Demand Workbench is a standard business object that supports using BPMs and BAMs. Use
these tools to refine the EDI process that best matches your company's needs.
132 Epicor ERP | 9.05.700

Import EDI Demand and User Hook Programs
You can create and use up to four external custom programs for manipulation of data contained in inbound EDI
.app files that have been deposited into the Direct Import folder and are being processed using the Import EDI
Demand program.
If used, these external programs contain custom code created by technically adept personnel for processing of
inbound EDI transactions in your enterprise. They must be named in the following manner, and once created,
placed into the \om\ud folder on your Epicor ERP server:
• omImportEDIb4tran.p - If it exists, the Epicor application runs this external program to manipulate inbound
EDI data stored in Intermediate Demand tables before the ImportEDI.r routine runs and processes translations
on the data.
• omImportEDIb4val.p - If it exists, the Epicor application runs this external program to manipulate translated
inbound EDI data stored in Intermediate Demand tables before the ImportEDI.r routine runs and performs
validations on the data.
• omImportEDIpreProcessDemand.p - If it exists, the Epicor application runs this external program to
manipulate validated inbound EDI data stored in the regular Demand tables before the ImportEDI.r routine
processes the demand data into actual sales orders or forecasts.
• omImportEDIpostProcessDemand.p - If it exists, the Epicor application runs this external program to
manipulate inbound EDI data after the ImportEDI.r routine processes the demand data into actual sales
orders or forecasts.
The flowchart that follows graphically illustrates how and where the Epicor application runs and uses these
external programs when processing inbound EDI files.
Epicor ERP | 9.05.700 133

134 Epicor ERP | 9.05.700

Understanding the User Hook Programs Flowchart
The flowchart reads as follows:
1. This is the inbound .app file deposited by the third-party program into the DirectImport folder; the location
for this folder is defined in the Import Folder field in the Company Configuration > Modules > Sales >
Demand sheet.
2. The Epicor application retrieves the deposited .app file, parses and processes the data on it, and places the
data into Intermediate Demand tables in Epicor ERP.
3. Once data has been placed into the Intermediate Demand tables, the Epicor application determines if an
external custom program with the name omImportEDIb4tran.p exists in the \om\ud folder on the Epicor
ERP server. If it does, it proceeds to Step 4; if not, it proceeds directly to Step 5.
4. If an external custom program named omImportEDIb4tran.p does exist, the Epicor application runs it
against the data stored in the Intermediate Demand tables. This programmatically alters this data, based on
the code contained in the external program.
5. The ImportEDI.r routine in the Epicor application processes any translations contained in the data in the
Intermediate Demand tables.
6. The Epicor application determines if a second external custom program with the name omImportEDIb4val.p
exists in the \om\ud folder. If it does, it proceeds to Step 7; if not, it proceeds directly to Step 8.
7. If an external custom program named omImportEDIb4val.p does exist, the Epicor application runs it against
the data stored in the Intermediate Demand tables. This programmatically alters this data, based on the
code contained in the external program.
8. The ImportEDI.r routine in the Epicor application processes validations on the data in the Intermediate
Demand tables. These are data validations performed on the inbound EDI data based on the parameters
you have designated for the customer trading partner in Customer Maintenance and other programs.
Note Refer to the Setup Components section, and the workflow topics contained in the Optional
- Service Connect Workflow Processing section for more details.
9. After completing all data validations, the ImportEDI.r routine moves the altered data from the Intermediate
Demand tables to the regular Demand tables for further processing.
10. The Epicor application reads the Accept Type field setting in the Customer Maintenance > Documents or
Customer Maintenance > Ship To > Documents sheet for the document type and customer trading partner
(or ship to customer trading partner) associated with the inbound EDI transaction. This field designates if
demand on an inbound EDI document should automatically be accepted or rejected. If set to Always Accept
or Accept If No Errors, it proceeds to Step 11. If set to Manually Accept it proceeds to Step 10a.
Note If the Accept Type field is set to Manually Accept, the Epicor application no longer searches
for or runs external programs on the inbound EDI data.
a. The Epicor application determines if a Business Process Management (BPM) record has been defined
for Demand.Entry.Process Demand; if so, it proceeds to Step 10b. The associated BPM can be defined
Epicor ERP | 9.05.700 135

for Pre-Processing or Post-Processing using the standard BPM functionality in the Epicor application. If
no BPM exists, it proceeds to Step 10c.
b. If a BPM exists, when you run the Process selection, located on the Actions menu in Demand Entry or
Demand Mass Review, the Epicor application runs the associated BPM on the inbound EDI demand
and converts it into actual sales orders or forecasts.
c. If a BPM does not exist, when you run the Process selection, located on the Actions menu in Demand
Entry or Demand Mass Review, the Epicor application converts the inbound EDI demand into actual
sales orders or forecasts.
11. The Epicor application determines if a third external custom program with the name
omImportEDIpreProcessDemand.p exists in the \om\ud folder. If it does, it proceeds to Step 12; if not,
it proceeds directly to Step 13.
12. If an external custom program named omImportEDIpreProcessDemand.p does exist, the Epicor application
runs it against the data stored in the regular Demand tables before the demand data is processing into
actual sales orders or forecasts. This programmatically alters this data, based on the code contained in the
external program.
13. The ImportEDI.r routine in the Epicor application processes the inbound EDI data stored in the regular
Demand tables and converts it into actual sales orders or forecasts.
14. The Epicor application determines if a fourth external custom program with the name
omImportEDIpostProcessDemand.p exists in the \om\ud folder. If it does, it proceeds to Step 15; if not,
inbound EDI demand processing is complete.
15. If an external custom program named omImportEDIpostProcessDemand.p does exist, the Epicor application
runs it against the actual sales orders or forecasts created from inbound EDI demand. This programmatically
alters this data, based on the code contained in the external program. After this, inbound EDI demand
processing is complete.
136 Epicor ERP | 9.05.700

Optional - Service Connect Workflow Processing
The Service Connect module in your Epicor application provides a powerful and flexible environment that supports
specific collaborative processes, connecting different business entities, applications, or users. Service Connect
harnesses the power of XML, electronic message transfer and transaction based processing. Refer to the Service
Connect Guide for details on its specific use.
Important Epicor recommends customers on 9.05.607 or later to use the direct EDI import process. All
the workflows Service Connect uses to process inbound documents are replaced by a server side logic,
which significantly improves EDI performance.
Service Connect processes data inbound text EDI transactions received from your customer trading partners and
passed by the eVision (or a similar provider) third-party application. Refer to the Service Connect Guide for
details on its specific use.
The main components Service Connect uses to process inbound EDI transactions are a series of bundled, pre-defined
workflows provided by Epicor. These workflows transform the data contained in the inbound EDI transaction
into another transactional format that can be processed by the Epicor application
• These workflows are designed to create, transform, manipulate and update data within the Epicor application.
They generate records in the appropriate database tables for further processing by the Demand Management
module.
• These workflows are included in the initial installation of your Epicor application. Refer to the Prerequisite
Installation and Setup Tasks section and the companion EDI TIE KINETIX Integration Guide for more
details. When updated by Epicor, new versions are included in the Epicor905\ESC\EDI\Demand folder with
service pack releases.
Referring to the preceding Inbound EDI Transaction File Mappings section, Service Connect uses these
pre-defined workflows to process an inbound EDI file row by row. Each workflow performs specific data verification
and validation tasks, as detailed in the remainder of this section.
• If, after successfully performing all required data verification and validation checks Service Connect determines
Epicor ERP | 9.05.700 137

Entry. Refer to the Processing Demand Entries section for more details.
• Depending on the specific settings for the customer trading partner, these workflows also create order and
forecast transactions from the demand entries it creates; refer the Order Transactions Generated from
Inbound EDI Demand and Forecast Transactions Generated from Inbound EDI Demand sections for
more detail.
• If the inbound EDI transaction file is error-free, this takes place automatically without any required human
intervention.
The comprehensive workflows Service Connect uses for this processing are bundled under a single EDI workflow
package, and consist of the following; they are listed in the general order sequence in which they are processed:
• Main - This is the top-level workflow; it creates a loop that converts an inbound EDI transaction into an XML
file, and then passes it to the lower-level workflows that comprise the EDI workflow package.
• Main_DemandHeadUpdate - This is the largest workflow in the EDI workflow package; it processes
Demand_Header rows (and associated Extra_Charge rows) in inbound EDI files and if successfully processed,
it creates new, or updates existing demand entries in the DemandHeader table in the Epicor application.
Within this particular workflow, it contains numerous sub-processing points that invoke each of the remaining
workflows. Once it completes, it passes control back to the Main workflow to process the remainder of the
(previously unprocessed) inbound EDI transactions stored in the designated input channel by TIE KINETIX
eVision.
• Main_DemandDetailUpdate - This is the second largest workflow in the EDI workflow package; it processes
Demand_Detail rows (and associated Extra_Charge rows) in inbound EDI files, and if successfully processed,
it creates new, or updates individual demand entries in the DemandDetail table in the Epicor application.
This workflow invokes the Main_DetailPartValidation and Main_DemandScheduleValidation workflows
at specific sub-processing points to perform part number and Demand_Schedule validations. When those
workflows complete, they in turn pass the validated data back to the Main_DemandDetailUpdate workflow.
Once the remainder of this workflow completes, it passes the Demand Detail data back to the
Main_DemandHeadUpdate workflow to process the remainder of that workflow.
138 Epicor ERP | 9.05.700

• Main_DetailPartValidation - This workflow validates each of the part numbers contained in the Demand
Detail rows in the inbound EDI file being processed. It passes parameters to the Epicor application, which in
turn validates internal part numbers, manufacturer part numbers, customer part numbers, and EAN/GTIN/UPC
product code cross references (if any) contained in the Demand_Detail rows. Once it has completed all of
these validations, it passes the validated part data back to the Main_DetailPartValidation workflow, which
in turns passes it back to the Main_DemandDetailUpdate workflow to process the remainder of that
workflow.
• Main_DemandScheduleValidation - This workflow processes Demand_Schedule rows in inbound EDI files,
and if successfully processed, it creates new, or updates individual demand schedule entries in the
DemandSchedule table in the Epicor application.
Once it completes, it passes the Demand Schedule data back to the Main_DemandDetailUpdate workflow
to process the remainder of that workflow.
You can view the progress of an inbound EDI transaction as it is progresses through each of these workflows
using the Service Connect Activity Progress Monitor.
You use the Service Connect Task Monitor to correct any data validation errors that occur during workflow
processing (refer to Correcting Errors Using the Service Connect Task Monitor for more details).
Service Connect workflows have been designed in a graphic format that contains a series of standardized icons
with explanatory labels that represent actions, processing and conditional decision points within a workflow:
Represents the starting point for the processing of the workflow.
Represents a processing point in the workflow; this is typically another workflow.

The Properties window for a processing point displays the parameters being used to perform the processing (for
example, the specific action, sub-process, program or workflow that is being invoked); it would appear as follows
when you click the icon in the Service Connect Workflow Designer:
Epicor ERP | 9.05.700 139

Represents a conditional point (Yes/No) or logic branch in the workflow.
Represents a point at which a file or data parameters are retrieved in the workflow.
Represents an error message displayed in the Service Connect Task Monitor.
Represents a point at which a specific action or data conversion occurs in the workflow.
Represents the ending point for the processing of the workflow.
140 Epicor ERP | 9.05.700

Main Workflow
The Main workflow is the top-level workflow in the EDI workflow package; it is a simple workflow creates a loop
that converts an inbound EDI transaction into an XML file, and then passes it to the lower-level workflows that
comprise the EDI workflow package.
This is the processing that takes place when the Main workflow runs in Service Connect. The labels for each icon
are presented with a detailed explanation of what specific processing takes place at that workflow step. Specifically,
the Main workflow performs the following tasks:
• Start DemandEntry Update by DropFile - The starting point for the processing of the workflow. Service
Connect picks up the inbound EDI flat file (as passed by TIE Commerce eVision) from the designated input
channel. This converts the inbound EDI flat file to an XML file stored in memory, and the workflow proceeds
to the ProcessDItoDemandEntryDatabyPO/Schedule step.
• ProcessDItoDemandEntryDatabyPO/Schedule - This passes the XML file on to the lower-level
Main_DemandHeadUpdate workflow for processing.
• Once the Finished Demand Process step in the Main_DemandHeadUpdate workflow runs, it passes a
message that it has completed processing of the Demand Header row in the inbound EDI transaction back
to the Start DemandEntry Update by DropFile step.
• The Start DemandEntry Update by DropFile step then back to the input channel and processes the
next (previously unprocessed) inbound EDI flat file, until it has completed processed all remaining inbound
EDI files, at which point it proceeds to the Finished EDI Batch step
• Finished EDI Batch - The ending point for the processing of the entire EDI workflow package. All previously
unprocessed inbound EDI flat files that were stored in the input channel have already been fully processed.
Note The Service Connect Workflows automatically create Demand Log entries both before and after you
invoke the Task Monitor to make corrections to invalid data contained in inbound EDI transactions. Refer
to Demand Log Entries Generated from Service Connect Workflows for more details.
Epicor ERP | 9.05.700 141

Main_DemandHeadUpdate Workflow
The Main_DemandHeadUpdate workflow is the largest workflow in the EDI workflow package; it processes
Demand_Header rows in inbound EDI files and if they are successfully processed, it creates or demand entries in
the DemandHeader table in the Epicor application.
• This workflow contains numerous processing points that invoke each of the remaining workflows.
• Once the entire workflow completes, it passes control back to the Start DemandEntry Update by DropFile
step in the Main workflow to process the remainder of the (previously unprocessed) inbound EDI transactions
stored in the designated input channel by TIE KINETIX eVision.
Tip The large size of this particular workflow makes it difficult to reproduce in whole and still contain
icons and labels of sufficient size for suitable readability. As such, it is broken down and presented as
several graphics in this section. This is the leftmost side of the workflow:
• Save Demand Head Input Data - Data conversion that retrieves the XML file that was generated from the
inbound EDI transaction by the Main workflow. Service Connect saves it in memory as an XML file (the data
is not physically stored) for use in data validation and update tasks as it progresses through the rest of the
Main_DemandHeadUpdate workflow.
• GetBy Dmd Cnt Trading Partner Conversion - Performs a data conversion using the trading partner and
demand contract ID numbers in the inbound EDI file, and sends the correct parameters to the GetBy Dmd
Cnt Trading Partner WebService.
• GetBy Dmd Cnt Trading Partner - Using the parameters passed to it by the previous workflow step, this
WebService call retrieves the demand contract for the trading partner ID from the Epicor application database,
and returns the data in the form of an XML file saved in memory. This must be a valid demand contract
entered for the specified trading partner in Demand Contract Entry.
• Contract Valid? - Conditional point that determines if the demand contract retrieved by the previous workflow
step is valid for the trading partner identified on the inbound EDI transaction. It performs a data validation
between the demand contract retrieved from the Epicor application against the corresponding values in the
demand header input data that is stored in physical memory from the inbound EDI transaction.
• No - The demand contract retrieved by the previous workflow step is not valid for the trading partner, or
cannot be found in the Epicor application database. Service Connect then performs the Invalid Contract
workflow step, which sends a call that displays as an Invalid Contract Task error message when you use
the Service Connect Task Monitor.
142 Epicor ERP | 9.05.700

Using the Task Monitor, you can either abort the Main_DemandHeadUpdate workflow, or manually correct
the demand contract number on the inbound EDI transaction that is causing the Invalid Contract Task
error, and then resubmit the corrected data for reprocessing by the Main_DemandHeadUpdate workflow.
As an alternative, you could also add the missing contract into Demand Contract Entry. Refer to Correcting
Errors Using the Service Connect Task Monitor for more details.
• If you abort the workflow in the Task Monitor, it performs the Abort Invalid Contract and Abort
before Updates workflow steps (not pictured), which prevents the Main_DemandHeadUpdate
workflow from proceeding and performing any further updates for this particular EDI transaction. It
proceeds directly to the workflow end point, goes back to the Main workflow, retrieves the next
unprocessed EDI transaction in the input channel and starts processing it.
• If you correct the invalid contract number, and then resubmit the corrected data for reprocessing, it
proceeds back to the Save Demand Head Input Data workflow step.
• Yes - The demand contract retrieved by the previous workflow step is valid for the trading partner. The
workflow then proceeds to the Prepare Customer GetRows step.
• Prepare Customer GetRows - Performs a data conversion using the customer number in the inbound EDI
file, and sends the correct parameters to the Customer GetRows WebService.
• Customer GetRows - Using the customer number parameter passed to it by the previous workflow step,
this WebService call retrieves the demand and document parameters defined for the customer number from
the Epicor application database, and returns the data in the form of an XML file saved in memory. These are
the demand and document parameters you specified for the customer in the Customer Maintenance >
Customer > Demand and Documents sheets. Refer to Defining Trading Partners in Customer Maintenance
for more details.
• Save Customer Data - Using the customer demand and documents data retrieved by the previous workflow
step, Service Connect saves it in memory as an XML file (the data is not physically stored) for use in data
validation and update tasks as it progresses through the rest of the Main_DemandHeadUpdate workflow.
• Check Tran Type and Part Numbers - Using the header input data stored in physical memory from the
inbound EDI transaction, this WebService validates the transaction type against the customer documents
parameters retrieved from the Epicor application in the previous workflow step demand. If the transaction
type in the inbound Header row is set to FIRM, this WebService validates that document parameters have
been defined for the FIRM transaction type for this customer trading partner in the Customer Maintenance
> Documents sheet.
• Valid Trans Type? - Conditional point that determines if valid document parameters have been defined in
the Customer Maintenance > Documents sheet for the retrieved customer number and transaction type in
the Header row of the inbound EDI transaction.
• Valid - The document parameters retrieved by the previous workflow step are valid for the transaction
type. The workflow then proceeds to the DemandEntry GetRows step.
• Invalid - The document parameters retrieved by the previous workflow step are not valid for the transaction
type, or cannot be found in the Epicor application database. Service Connect then performs the Invalid
Trans Type workflow step, which sends a call that displays as an Invalid Demand Data error message
when you use the Service Connect Task Monitor.
the transaction type on the inbound EDI transaction that is causing the Invalid Demand Data error, and
then resubmit the corrected data for reprocessing by the Main_DemandHeadUpdate workflow. As an
alternative, you can also enter document parameters for the transaction type and customer trading partner
into the Customer Maintenance > Documents or Ship To > Documents sheets. Refer to Correcting Errors
Using the Service Connect Task Monitor for more details.
• If you abort the workflow in the Task Monitor, it performs the Abort Invalid Tran Type workflow
step and Abort before Updates workflow step (not pictured), which prevents the
Main_DemandHeadUpdate workflow from proceeding and performing any further updates for this
Epicor ERP | 9.05.700 143

particular EDI transaction. It proceeds directly to the workflow end point, goes back to the Main
workflow, retrieves the next unprocessed EDI transaction in the input channel and starts processing it.
• If you correct the invalid transaction type, and then resubmit the corrected data for reprocessing, it
proceeds back to the Save Demand Head Input Data workflow step.
• DemandEntry GetRows - Performs a data conversion using the trading partner and purchase order numbers
in the inbound EDI file Header row, and sends the correct parameters to the Demand Entry GetRows
WebService.
• DemandEntry GetRows (WebService) - Using the parameters passed to it by the previous workflow step,
this WebService call attempts to retrieve any existing demand entries that may have been previously created
in the Epicor application database for the trading partner ID and purchase order number, and returns the
data in the form of an XML file saved in memory. It does not return any data if existing demand entries do
not current exist for the passed parameters.
• Demand Locked? - Conditional point that determines if the DemandHead lock is turned on for the existing
demand entries (if any) retrieved by the Demand Entry GetRows WebService. This denotes that the demand
header record being updated is currently locked.
• Yes - Denotes that the demand entry record is in use in the Epicor application and is currently locked to
prevent concurrent processing or updating of records by another source or program.
Service Connect performs the DemandLog Lock and DemandLogUpdate workflow steps, which create
a new record in the Demand Log. It then performs the SC Lock workflow step, which sends a call that
displays as an SC Demand Lock error message when you use the Service Connect Task Monitor.
Using the Task Monitor, you can either abort the Main_DemandHeadUpdate workflow, or manually remove
the Service Connect Lock on the demand entry record and then resubmit the corrected data for reprocessing
by the Main_DemandHeadUpdate workflow.
• If you abort the workflow in the Task Monitor, Service Connect performs the DemandLog Abort Lock
and DemandLogUpdate workflow steps, which create a new record in the Demand Log. It then
performs the Abort SC Lock workflow step, and Abort before Updates workflow step (not pictured),
which prevents the Main_DemandHeadUpdate workflow from proceeding and performing any further
updates for this particular EDI transaction. It proceeds directly to the workflow end point, goes back
to the Main workflow, retrieves the next unprocessed EDI transaction in the input channel and starts
processing it.
• If you manually remove the Service Connect Lock on the demand entry record in the Task Monitor,
and then resubmit the corrected data for reprocessing, Service Connect performs the DemandLog
Resubmit Lock and DemandLogUpdate workflow steps, which create a new record in the Demand
Log. It then performs the DemandLog Final SC Log workflow step, and proceeds directly to the
Main workflow, and resubmits it for processing.
• No - Denotes that the demand entry record that has been retrieved is not currently in use in the Epicor
application. The workflow then proceeds to the Store Existing Demand step.
• Store Existing Demand - Using the existing demand entry data retrieved by the DemandEntry Get Rows
workflow step, Service Connect saves it in memory as an XML file (the data is not physically stored) for use
in data validation and update tasks as it progresses through the rest of the Main_DemandHeadUpdate
workflow.
• DemandHead on File? - Conditional point that determines if a corresponding record exists in the DemandHead
table in the Epicor application for the existing demand entries (if any) retrieved by Demand Entry GetRows
WebService.
• No - Denotes that a corresponding record does not exist in the DemandHead table in the Epicor application
for the existing demand entries (if any) retrieved by Demand Entry GetRows WebService. The workflow
then proceeds to the Check Ship-To? step.
144 Epicor ERP | 9.05.700

• Yes - Denotes that a corresponding record does exist in the DemandHead table in the Epicor application
for the existing demand entries (if any) retrieved by Demand Entry GetRows WebService. The workflow
then proceeds to the Open Demand Schedule for this Schedule? step.
• Open Demand Schedules for this Schedule? - Conditional point that determines if any open (unshipped)
demand schedules exist for the existing demand entries retrieved in previous workflow steps. It determines
if records exist in the DemandSchedule table in the Epicor application, and if they contain a Posted flag set
to False.
• No - Denotes that open (unshipped) demand schedules do not exist for the demand entries retrieved in
previous workflow steps. The workflow then proceeds to the Check Ship-To? step.
• Yes - Denotes that at least one or more open (unshipped) demand schedules exist for the demand entries
retrieved in previous workflow steps. Service Connect then creates a new record in the Demand Log and
performs the Demand to XML Header workflow step, which sends a call that displays as an Unposted
Demand on File error message when you use the Service Connect Task Monitor.
Using the Task Monitor, you can either abort the Main_DemandHeadUpdate workflow, or delete the
unposted demand schedules and then resubmit the corrected data for reprocessing by the
Main_DemandHeadUpdate workflow. Refer to Correcting Errors Using the Service Connect Task
Monitor for more details. To remove this error condition, you can also process the unposted demand
schedules in the Epicor application using the Post selection on the Demand Entry Actions menu.
• If you abort the workflow in the Task Monitor, it performs the Abort Unposted Demand and Abort
before Updates workflow steps (not pictured), which prevents the Main_DemandHeadUpdate
• If you wish to resubmit the open schedule data for reprocessing, Service Connect performs the
DemandLog Resubmit Unposted and DemandLogUpdate workflow steps, which create a new
record in the Demand Log. It then performs the DemandLog Final Uposted workflow step, and then
proceeds back to the Check TranType and Part Numbers workflow step.
• Check Ship-To - Conditional point that determines if a ship-to customer number is stored in the inbound
EDI file demand contract retrieved in previous workflow steps.
• No - Denotes that a ship-to customer number is not stored in the inbound EDI file demand contract
retrieved in previous workflow steps. The workflow then proceeds to the DemandEntry Update Request
step.
• Yes - Denotes that a ship-to customer number is stored in the inbound EDI file demand contract. The
workflow then proceeds to the ShipTo GetList step.
• ShipTo GetList - Performs a data conversion using the ship to customer number in the inbound EDI file, and
sends the correct parameters to the ShipTo GetList WebService.
• ShipTo GetList (WebService) - Using the ship to customer number parameter passed to it by the previous
workflow step, this WebService call retrieves the demand and document parameters defined for the ship to
customer number from the Epicor application database, and returns the data in the form of an XML file saved
in memory. These are the demand and document parameters you specified for the customer in the Customer
Maintenance > Ship To > Demand and Ship To > Documents sheets. Refer to Defining Trading Partners
in Customer Maintenance for more details.
• Valid Ship-to at Header? - Conditional point that determines if the ship to customer (if any) retrieved in the
previous step is valid in the DemandHead record for the existing demand entries (if any) retrieved from the
Epicor application.
• Yes - Denotes that the ship to customer retrieved in the previous step is valid in the DemandHead record
for the existing demand entries retrieved from the Epicor application. The workflow then proceeds to the
Store Ship-to step.
Epicor ERP | 9.05.700 145

• No - Denotes that no ship to customer number was retrieved in the previous step, or if one was, it is invalid
in the DemandHead record for the existing demand entries retrieved from the Epicor application. Service
Connect creates a new record in the Demand Log and then performs the Demand to XML Header
workflow step, which sends a call that displays as an Invalid Ship-to at Header error message when you
use the Service Connect Task Monitor.
the invalid ship to customer number on the inbound EDI transaction that is causing the Invalid Ship-to
at Header error, and then resubmit the corrected data for reprocessing by the Main_DemandHeadUpdate
workflow. Refer to Correcting Errors Using the Service Connect Task Monitor for more details.
• If you abort the workflow in the Task Monitor, it performs the Abort Ship-to at Header and Abort
before Updates workflow steps (not pictured), which prevents the Main_DemandHeadUpdate workflow
from proceeding and performing any further updates for this particular EDI transaction. It proceeds
directly to the workflow end point, goes back to the Main workflow, retrieves the next unprocessed
EDI transaction in the input channel and starts processing it.
• If you correct the invalid ship to customer number and resubmit it for reprocessing, Service Connect
performs the DemandLog Resubmit Ship To and DemandLogUpdate workflow steps, which create
a new record in the Demand Log. It then proceeds back to the Check Ship To workflow step.
• Store Ship-To - Using the ship to customer demand and documents data retrieved by the previous workflow
step, Service Connect saves it in memory as an XML file (the data is not physically stored) for use in data
validation and update tasks as it progresses through the rest of the Main_DemandHeadUpdate workflow.
• DemandEntryUpdate Request - Performs a data conversion and collects the data from the inbound EDI
transaction that was validated in the previous workflow steps. Service Connect saves it in memory as an XML
file (the data is not physically stored) and prepares it to be sent to the Epicor application to update the
appropriate tables.
• DemandEntryUpdate - Using the parameters passed to it by the previous workflow step, this WebService
attempts to write new records to, or update records in the DemandHead table in the Epicor application
database. The Demand_Header rows in an inbound EDI transaction contains descriptive header information
that relates to the Demand_Detail rows linked to it.
• The Epicor application stores this information in the DemandHeader record it creates or updates; this
constitutes the header portion of the resulting demand entry records.
146 Epicor ERP | 9.05.700

• When it does this, it automatically locks the newly created demand header record in the DemandHeader
table. It does this to prevent concurrent processing or updating by another source or program. These are
locks are released by the Main_DemandHead Update workflow by the Final Demand Header Updates
step.
• DemandHead Update Successful? - Conditional point that determines if update of the DemandHead table
that was performed by the previous workflow set was successful (a new record was created, or an existing
record was successfully updated).
• Yes/No Charges - Denotes that the update of the DemandHead table that was performed by the previous
workflow set was successful, and there are no Extra_Charge rows on the inbound EDI transaction associated
with the demand header. The workflow then proceeds to the Prepare for Detail step.
• Yes/Charges - Denotes that the update of the DemandHead table that was performed by the previous
workflow set was successful and there are Extra_Charge rows on the inbound EDI transaction associated
with the demand header. The workflow then proceeds to the Header ExtraCharge Update Request
step.
• New - Denotes that this is a new demand header record. Service Connect then performs the Demand
Head Update Error workflow step, which sends a call that displays as a Demand Head Update Error
message when you use the Service Connect Task Monitor. You can either abort or resubmit the workflow
(see No below).
• No - Denotes that the update of the DemandHead table that was performed by the previous workflow
set was unsuccessful. Service Connect performs the DemandLog Header Update and DemandLog
Update workflow steps, which create a new record in the Demand Log. It then performs the Demand
Head Update Error workflow step, which sends a call that displays as a Demand Head Update Error
message when you use the Service Connect Task Monitor.
the condition that is causing the error, and then resubmit the corrected data for reprocessing by the
• If you abort the workflow in the Task Monitor, it performs the DemandLog Header Update and
DemandLog Update workflow steps, which create a new record in the Demand Log. It then performs
the Abort DemandEntry Update workflow step and the Abort before Updates workflow step (not
pictured), which prevents the Main_DemandHeadUpdate workflow from proceeding and performing
any further updates for this particular EDI transaction. It proceeds directly to the workflow end point,
goes back to the Main workflow, retrieves the next unprocessed EDI transaction in the input channel
and starts processing it.
• If you correct the demand header and resubmit it for reprocessing, Service Connect performs the
Resubmit DemandHeadUpdate workflow step and then proceeds back to the DemandEntry Update
workflow step.
• Header ExtraCharge Update Request - Performs a data conversion that saves the Extra Charge record
associated with the header in memory as an XML file (the data is not physically stored) and prepares it to be
sent to the DemandEntry Update workflow step.
• DemandEntry Update (WebService) - This WebService uses the data conversion parameters passed by the
previous step to update the associated DemandDetail table in the Epicor application database.
• Header ExtraCharges Update Successful? - Conditional point that determines if update that was performed
by the previous workflow set was successful.
• Yes - Denotes that the update that was performed by the previous workflow set was successful. The
workflow then proceeds to the Prepare for Detail step.
• No - Denotes that the update that was performed by the previous workflow set was unsuccessful. Service
Connect performs the Demand ExtraCharges Update and DemandLog Update workflow steps, which
create a new record in the Demand Log. It then performs the Demand ExtraCharges Update Error
Epicor ERP | 9.05.700 147

workflow step, which sends a call that displays as a Demand ExtraCharges Update Error message when
you use the Service Connect Task Monitor.
the condition that is causing the error, and then resubmit the corrected data for reprocessing by the
• If you abort the workflow in the Task Monitor, it performs the DemandLog Header Update and
DemandLog Update workflow steps, which create a new record in the Demand Log. It then performs
the Abort DemandEntry Update workflow step and the Abort before Updates workflow step (not
pictured), which prevents the Main_DemandHeadUpdate workflow from proceeding and performing
• If you correct the demand header extra charges and resubmit for reprocessing, Service Connect performs
the Resubmit DemandHeader ExtraCharges Update workflow step and then proceeds back to the
DemandEntry Update workflow step.
• Prepare For Detail - Performs a data conversion that takes a subset of the Demand_Detail, Extra_Charge,
User_Defined and Demand_Schedule line rows that are attached to the Demand_Header row on the inbound
EDI transaction. Service Connect saves it in memory as an XML file (the data is not physically stored) and
prepares it to be sent to the Blank Part Numbers? workflow step.
• Blank Part Numbers? - Conditional point that determines if the data subset passed by the Prepare for
Detail workflow step contains blank (missing) part numbers. This means that both the Part Number and
Customer Part in the Demand_Detail rows on the inbound EDI transaction are both blank. At least one of
these data positions must contain a value. Service Connect performs this step to ensure that the data set
passed to the Process Inbound DemandDetail workflow step is as complete as possible.
• No - Denotes that the data subset passed by the Prepare for Detail workflow step does not contain
blank (missing) part numbers in the Demand_Detail rows of the inbound EDI transaction. The workflow
then proceeds to the Process Inbound DemandDetail step.
• Yes - Denotes that the data subset passed by the Prepare for Detail workflow step contains blank
(missing) part numbers in the Demand_Detail rows of the inbound EDI transaction. Service Connect creates
a new record in the Demand Log and then performs the Invalid Parts workflow step, which sends a call
that displays as an Invalid Part Number in Detail error message when you use the Service Connect Task
Monitor.
Using the Task Monitor, you can either abort the Main_DemandDetailUpdate workflow, or manually
correct the condition that is causing the error (in this case, adding missing part numbers to the inbound
EDI transaction) and then resubmit the corrected data for reprocessing by the Main_DemandHeadUpdate
workflow.
• If you abort the workflow in the Task Monitor, it performs the Abort DemandEntry Update and
Abort before Updates workflow steps (not pictured), which prevents the Main_DemandHeadUpdate
• When you resubmit it, it performs the Resubmit Invalid Part step, which passes it to the Blank Part
Numbers? conditional step for re-evaluation.
• Process Inbound DemandDetail - Processing point that invokes the Main_DemandDetailUpdate workflow.
That workflow processes Demand_Detail rows in inbound EDI files. Demand_Detail rows in inbound EDI files
contain descriptive demand detail information that relates to the Demand_Header row to which it is linked.
This is performed at this point because the remaining workflow steps in Main_DemandHeadUpdate require
148 Epicor ERP | 9.05.700

validated Demand Detail information for successful processing. Refer to the Main_DemandDetailUpdate
Workflow section for more details.
• Store Detail Workflow Responses - Data conversion that retrieves the XML file that was generated from
the Store Detail Workflow Responses step in the Main_DemandDetailUpdate workflow for the demand
detail processed for the inbound EDI transaction. Service Connect saves it in memory as an XML file (the data
is not physically stored) for use in data validation and update tasks as it progresses through the rest of the
• These parameters report if processing of the Demand_Detail rows on the inbound EDI transaction were
successfully completed, or any were aborted due to unresolved errors.
• The Main_DemandHeadUpdate workflow uses this data to determine if processing of the entire workflow
should be abort, or if should continue, how the DemandHead status should be updated.
• DemandHead StoreStatus - Data conversion uses the parameters passed from the Store Detail Workflow
Responses step in the Main_DemandDetailUpdate workflow to determine if DemandDetail table processing
was successfully completed, of if it was aborted for any of the Demand_Detail rows on the inbound EDI
transaction.
• Abort or Finish? - Conditional point that uses the results from the DemandHead StoreStatus step to
determine if processing of the remaining Main_DemandHeadUpdate workflow should be aborted, or if it
should continue.
• Finish - Denotes that the update of the DemandDetail table that was performed by the previous workflow
set was successful. The workflow then proceeds to the Matching Required? step.
• Abort - Denotes that the update of the DemandDetail table that was performed by the previous workflow
set was unsuccessful and updates of the DemandHead table should be aborted. Service Connect then
performs the DemandEntry Delete By Schedule Error workflow step.
• DemandEntry DeleteBySchedule - If the Abort or Finish? step is set to Abort, this data conversion passes
parameters on to the DemandEntry DeleteBySchedule WebService to delete or reverse all associated record
updates in the DemandDetail and DemandSchedule tables in the Epicor application database.
• DemandEntry DeleteBySchedule (WebService) - This WebService uses the data conversion parameters
passed by the previous step to delete or reverse all associated record updates in the DemandDetail and
DemandSchedule tables in the Epicor application database.
• These are the new records, or updates to existing records that were processed by the
Main_DemandDetailUpdate and Main_DemandScheduleUpdate workflows for the inbound EDI
transaction.
• Service Connect performs this step to prevent corrupt data from being stored in these tables when
processing is aborted for the DemandHead table.
• DemandHead Update OrderComment - This data conversion passes comment text to the DemandHead
Update step.
• DemandHead Update (WebService) - This WebService uses the comments parameters passed by to update
the demand header record stored in the DemandHead table to denote that processing has been aborted for
the associated inbound EDI transaction. It then proceeds to the DemandHead Update Finished step.
• Matching Required? - Conditional point that determines if only new records are being created in the
DemandHead table for the Demand_Header row on the inbound EDI transaction, or existing records are stored
in the DemandHead table and require that matching be performed prior to update.
• Yes - Denotes that existing records are stored in the DemandHead table that require that matching be
performed prior to update. The workflow then proceeds to the DemandMassReview MatchAllforDemand
step.
• No - Denotes that only new records are being created in the DemandHead table. No existing records are
stored in the DemandHead table that require matching be performed. The workflow then proceeds to the
Process Demand step.
Epicor ERP | 9.05.700 149

• DemandMassReview MatchAll - Performs a data conversion using the trading partner, purchase order
number and demand contract numbers in the Header row in the inbound EDI file, and sends the correct
parameters to the
• DemandMassReview MatchAllforDemand (WebService) - Using the parameters passed to it by the previous
workflow step, this WebService call performs the same matching processing as does the Demand Mass Review
program when manually operated in the Epicor application.
• It reviews, evaluates, processes and updates multiple demand records (stored in the DemandHead table)
for the customer trading partner at the same time. It uses the demand matching criteria specified in the
demand contract (specified in the Demand_Header row in the inbound EDI transaction) to perform the
actual matching.
• Refer to the Application Help and the Enter Demand Contracts- Header > Matching Sheet section
in this document for complete details.
• Process Demand? - The Accept Type field in the Customer Maintenance > Documents or Ship To >
Documents sheets specifies if demand on an inbound EDI document should automatically be accepted or
rejected for this customer trading partner. This conditional point that determines if demand should be
automatically processed for the Demand_Header row on the inbound EDI transaction based on the setting
of the Accept Type field.
• Yes - The Accept Type field in the Customer Maintenance > Documents or Ship To > Documents sheets
is set to Always Accept or Accept If No Errors; this denotes that demand should be automatically
processed for the Demand_Header row on the inbound EDI transaction (refer to Defining Trading Partners
in Customer Maintenance for more details). The workflow then proceeds to the Prepare for
SetReadyToProcess step.
• No - The Accept Type field in the Customer Maintenance > Documents or Ship To > Documents sheets
is set to Manually Accept; this denotes that demand should not be automatically processed for the
Demand_Header row on the inbound EDI transaction (refer to Defining Trading Partners in Customer
Maintenance for more details). The workflow then proceeds to the DemandEntry UpdateRequest
step.
Instead, you must use the Demand Header - Process Demand selection on the Demand Entry Actions menu
to manually process demand and generate sales order and forecast records. The workflow then proceeds
to the DemandEntry UpdateRequest step.
• Prepare for SetReadyToProcess - If the Process Demand? step is set to Yes, this data conversion passes
the proper parameters on the Prepare for SetReadyToProcess WebService so it can set the Set Ready to
Process flag to True on the appropriate records in the DemandHead table.
150 Epicor ERP | 9.05.700

• SetReadyToProcess (WebService) - Using the parameters passed to it by the previous workflow step, this
WebService call performs sets the Set Ready to Process flag to True on the appropriate demand entry
records stored in the DemandHead table in the Epicor application database. This flag denotes that the demand
entry is ready processing into sales orders or forecast releases. Refer to the Demand Entry Application Help
for complete details.
• DemandEntry Process Demand (WebService) - Using the parameters passed to it by the previous workflow
step, this WebService call performs the same demand processing as does the Demand Header - Process
selection on the Demand Entry Actions menu when manually operated in the Epicor application. The specific
tasks performed in this step is dependent on the setting of the Accept Type field in the Customer Maintenance
> Documents or Ship To > Documents sheets for the type of inbound document being processed:
• If set to Automatically Accept, this workflow step automatically process demand for this customer trading
partner, regardless of whether there are errors in the inbound EDI document. This automatically creates
demand entries in the Epicor application and immediately generates sales order and forecast entries.
In cases where the inbound EDI transaction does contain errors (for example, a Date Change action request
is received with insufficient lead time, and a Stop or Warning condition would normally be applied), this
workflow step automatically overrides any System Rejection flags, processes the demand and subsequent
sales order and forecast entries despite the error condition.
• If set to Accept If No Errors, this workflow step automatically process demand for this customer trading
partner only if there are no errors in the inbound EDI document. In the case of inbound EDI transactions,
this automatically creates demand entries in the Epicor application and immediately generates sales order
and forecast entries.
In cases where the inbound EDI transaction does contain errors (for example, a Date Change action request
is received with insufficient lead time), the Epicor application handles it the normal manner - it applies
Stop (with System Rejection) or Warning conditions, depending on the settings for the customer trading
partner in the Customer Maintenance > Customer > Demand or Ship To > Demand sheets. It does not
immediately generate sales order and forecast entries in these situations.
Refer to the Demand Entry Application Help and following sections of this document for more details:
• Defining Trading Partners in Customer Maintenance
• Order Transactions Generated from Inbound EDI Demand
• Forecast Transactions Generated from Inbound EDI Demand
• Processing Results - Data conversion that contains the results of the demand entry updates performed by
the previous DemandEntry Process Demand step. This reports cumulative quantity update and other errors;
this data is then passed on to the DemandEntry UpdateRequest step.
• DemandEntryUpdate Request - Performs a data conversion that contains the data passed on by the
ProcessMatchingResults and Processing Results steps. This indicates that the Lock flag on the demand
header record in the DemandHead tab (in the Epicor application database) can now be unlocked; this data is
then passed on to the Demand Final Demand Header Updates WebService step.
• Final Demand Header Updates - This WebService uses the parameters passed on to it by the
DemandEntryUpdate Request step and unlocks the Lock flag on the demand header record in the
DemandHead table that was formally locked during the DemandEntryUpdate step; this prevented concurrent
processing or updating by another source or program.
• DemandEntry Update Response - Performs a data conversion that contains data passed on by the Final
Demand Header Updates step. This indicates that the Lock flag on the demand header record in the
DemandHead tab (in the Epicor application database) has been successfully unlocked.
• DemandEntryUpdate Finished - Performs a data conversion that contains data passed on by the
DemandEntry Update Response step. This indicates that processing of the demand header has been
successfully completed.
• Finished Demand Process - This is the ending point of this workflow; the Demand_Header row, and all
associated Demand_Detail and Demand_Schedule rows have now been fully processed for the inbound EDI
Epicor ERP | 9.05.700 151

transaction. Service Connect saves it in memory as an XML file (the data is not physically stored) to pass back
to the Start DemandEntry Update by DropFile step in the Main workflow.
Main_DemandDetailUpdate Workflow
The Main_DemandDetailUpdate workflow is the second largest workflow in the EDI workflow package; it
processes Demand_Detail rows (and associated Extra_Charge rows) in inbound EDI files (D in Data Position 1).
• Demand_Detail rows in inbound EDI files contain descriptive demand detail information that relates to the
Demand_Header row to which it is linked.
• If they are successfully processed, this workflow creates individual demand entries in the DemandDetail table
in the Epicor application. This workflow contains numerous processing points that invoke each of the remaining
workflows.
• Once the entire workflow completes, it passes the Demand_Detail data back to the
Main_DemandHeadUpdate workflow to process the remainder of that workflow.
Tip As was the case with Main_DemandHeadUpdate, the relative size of this particular workflow
makes it difficult to reproduce in whole and still contain icons and labels of sufficient size for suitable
readability. As such, it is broken down and presented as two graphics in the document; split in the
middle of the workflow design. This is the leftmost side of the workflow:
152 Epicor ERP | 9.05.700

This is the processing that takes place when the Main_DemandDetailUpdate workflow runs in Service Connect.
The labels for each icon are presented with a detailed explanation of what specific processing takes place at that
workflow step:
• Save Demand Detail Input Data - Data conversion that retrieves the XML file that was generated from the
inbound EDI transaction by the Prepare For Detail step in the Main_DemandHeadUpdate workflow.
This is a subset of the Demand_Detail, Extra_Charge, User_Defined and Demand_Schedule rows that are
attached to the Demand_Header row on the inbound EDI transaction. Service Connect saves it in memory as
an XML file (the data is not physically stored) for use in data validation and update tasks as it progresses
through the rest of the Main_DemandDetailUpdate workflow.
• Submit Detail for Part Validation - Data conversion that collects the XML file that was generated from the
inbound EDI transaction by the Prepare For Detail step in the Main_DemandHeadUpdate workflow, and
submits it to the Main_DetailPartValidation workflow for validation of the part numbers contained in the
Demand_Detail rows in the inbound EDI transaction file.
• Validate Part Data - Processing point that invokes the Main_DetailPartValidation workflow. It validates
each of the part numbers contained in the Demand_Detail rows in the inbound EDI file; this includes internal
part numbers, customer part numbers, manufacturer part numbers and EAN/GTIN/UPC product code cross
references contained in inbound EDI transactions. Note: Refer to the Main_DetailPartValidation Workflow
section for more details.
• Backup Validated Data - Data conversion that backs up the data returned by the Part Validation ByPart
Finished step in the Main_DetailPartValidation workflow.
• This data includes internal valid/invalid status flags that were set for each of the internal part numbers.
• These flags indicate if the respective internal part number is valid or invalid, and if invalid, indicates if the
user had elected to abort validation processing in the Task Monitor.
• Continue or Abort? - Conditional point that reads the internal valid/invalid status flags (in the data set
provided by the previous workflow step) that indicate if the respective internal part number is valid, or if
invalid, indicates if the user had elected to abort processing in the Task Monitor.
• Continue - The internal valid/invalid status flag indicates that respective internal part number is valid. The
workflow then proceeds to the DemandEntry GetRows step.
• Abort - The internal valid/invalid status flag indicates that respective internal part number is invalid and
the user had elected to abort processing in the Task Monitor. Service Connect performs the DemandLog
Lock and DemandLogUpdate workflow steps, which create a new record in the Demand Log. It then
performs the Abort Demand (Invalid Part) and Abort before Updates workflow steps (not pictured),
which prevents the Main_DemandHeadUpdate workflow from proceeding and performing any further
updates for this particular EDI transaction. It proceeds directly to the workflow end point, goes back to
the Main workflow, retrieves the next unprocessed EDI transaction in the input channel and starts processing
it.
• DemandEntry GetRows - Performs a data conversion using the trading partner, purchase order number
and internal part numbers found in the Demand_Detail rows in the inbound EDI transaction, and sends these
parameters to the Demand Entry GetRows Request WebService.
• DemandEntry GetRows Request - Using the parameters passed to it by the previous workflow step, this
WebService call attempts to retrieve any existing demand detail lines that may have been previously created
in the Epicor application database for the trading partner ID, purchase order number and internal part number,
and returns the data in the form of an XML file saved in memory.
• These are existing demand lines that may have been manually entered into Demand Entry, or created
when the EDI workflow was run in an earlier session.
• This workflow step does not return any data if existing demand lines do not current exist in the Epicor
application database for the passed parameters.
Epicor ERP | 9.05.700 153

• Backup Demand Detail By Part - Data conversion that backs up the data (if any) returned by the Restore
Detail DemandEntry GetRows Request step and creates an XML file in memory
• Update Existing or New Demand Line? - Conditional point that reads the data returned by the Restore
Detail DemandEntry GetRows Request step and determines if an existing demand detail line can be
updated or if new demand line must be created in the Epicor application.
• Update Existing Detail - A demand detail line already exists for the trading partner, purchase order
number and internal part numbers that can be updated by the DemandEntry Update FoundLine step
using the Demand_Detail row data sent by the customer trading partner in the inbound EDI transaction.
• New Part for Contract - A demand entry exists for the trading partner and purchase order number, and
a demand contract line exists for the internal part number, but a demand detail line does not exist for the
internal part number. A new record must be created in the DemandDetail table in the Epicor application
(by the DemandEntry Update New Detail and Part for PO/Contract step) using the Demand_Detail
row data sent by the customer trading partner in the inbound EDI transaction.
• NewLine for Part - A demand entry exists for the trading partner and purchase order number, the demand
contract line is for the same internal part number but with a different demand reference (part number,
reference or PO line number), and no demand detail line exists for the internal part number.
A new demand line must be created (by the DemandEntry Get New Demand Detail step, using
parameters passed by the SamePart DifferentRef Demand Entry GetNewDemandDetail step). The
demand contract line is then updated based on the newly created demand line (by the DemandEntry
Change DetailContract Line step) using the Demand_Detail row data sent by the customer trading
partner in the inbound EDI transaction.
• DemandEntry Update FoundLine - If the Update Existing or New Demand Line? step is set to Update
Existing, this data conversion step attempts to update the demand detail line that already exists in the
DemandDetail table in the Epicor application database using the Demand_Detail row data sent by the customer
trading partner in the inbound EDI transaction.
• Line Locked or Unposted Demand On File? - Conditional point that determines if the DemandDetail line
lock is turned on, or unposted demand is on file for the existing demand detail line that the Demand Entry
UpdateFoundLine WebService is attempting to update.
• Yes - Denotes that the demand detail line record is in use in the Epicor application and is currently locked
to prevent concurrent processing or updating by another source or program, or unposted demand exists
for it. Service Connect performs the DemandLog Line Locked and DemandLogUpdate workflow steps,
which create a new record in the Demand Log. It then performs the Send Detail to Task Monitor
workflow step, which sends a call that displays as a Demand Detail Update Error message when you
remove the lock on the demand detail record and then resubmit the corrected data for reprocessing by
the Main_DemandDetailUpdate workflow. Refer to Correcting Errors Using the Service Connect Task
Monitor for more details.
• If you abort the workflow in the Task Monitor, Service Connect performs the DemandLog Abort Lock
and DemandLogUpdate workflow steps, which create a new record in the Demand Log. It then
performs the Abort Demand - Detail Update Error and Abort before Updates workflow steps (not
pictured), which prevents the Main_DemandDetailUpdate workflow from proceeding and performing
• No - Denotes that the demand detail line record that the Demand Entry UpdateFoundLine WebService
is attempting to update is not currently locked, nor does unposted demand exist for it. The workflow then
proceeds to the DemandEntry Update Detail step.
154 Epicor ERP | 9.05.700

• DemandEntry Update (New Detail and Part for PO/Contract) - If the Update Existing or New Demand
Line? step is set to New Part for Contract, this data conversion step creates a demand detail line in the
DemandDetail table for the internal part number based on the Demand_Detail row data in the inbound EDI
transaction.
• SamePart DifferentRef Demand Entry GetNewDemandDetail - If the Update Existing or New Demand
Line? step is set to NewLine for Part, this performs a data conversion that prepares parameters that are
passed to the DemandEntry Get New Demand Detail WebService.
• DemandEntry Get New DemandDetail - (WebService- This creates a demand detail line in the DemandDetail
table for the internal part number, based on the Demand_Detail row data sent by the customer trading
partner.
• DemandEntry Update ContractLine to Demand Detail - If the Update Existing or New Demand Line?
step is set to NewLine for Part, this data conversion step passes data parameters to the DemandEntry
Change DetailContractLine step, which it uses to update the demand reference in the existing demand
contract line, based on the demand line data created in the DemandDetail table in the previous DemandEntry
Get New DemandDetail step.
• DemandEntry Change DetailContractLine (WebService) - Updates the demand reference in the existing
demand contract line based on the demand line data passed by the previous DemandEntry Update
ContractLine to Demand Detail step.
• DemandEntry Update NewLineForPart - Data conversion step that passes data parameters to the
DemandEntry Update Detail step.
• DemandEntry Update Detail - This WebService attempts to formally update the (newly created) or existing
demand detail line in the DemandDetail table in the Epicor application database using the data sent by the
customer trading partner in the inbound EDI transaction.
When it does this, it automatically locks demand detail lines in the DemandDetail table. It does this to prevent
concurrent processing or updating by another source or program. These are locks are released by the
Main_DemandDetail Update workflow by the Demand Detail Final Update step.
• Update Successful? - Conditional point that determines if the update of the existing demand line in the
DemandDetail table performed by DemandEntry Update Detail WebService was successful.
• Yes - Denotes that the update of the existing demand line in the DemandDetail table was successful. The
workflow then proceeds to the Save Detail Updates step.
• No - Denotes that the update of the existing demand line in the DemandDetail table was unsuccessful.
The demand detail line record is either in use in the Epicor application and is currently locked to prevent
concurrent processing or updating by another source or program, or unposted demand exists for it. Service
Connect creates a new entry in the Demand Log and then performs the Send Detail to Task Monitor
workflow step, which sends a call that displays as a Demand Detail Update Error message when you
remove the lock on the demand detail record and then resubmit the corrected data for reprocessing by
the Main_DemandDetailUpdate workflow. Refer to Correcting Errors Using the Service Connect Task
• If you abort the workflow in the Task Monitor, it performs the Abort Demand - Detail Update Error
and Abort before Updates workflow steps (not pictured), which prevents the
Main_DemandDetailUpdate workflow from proceeding and performing any further updates for this
• Save Detail Updates - Using the DemandDetail table information updated by the DemandEntry Update
WebService, Service Connect saves it in memory as an XML file (the data is not physically stored) for use in
data validation and update tasks as it progresses through the rest of the Main_DemandDetailUpdate workflow.
Epicor ERP | 9.05.700 155

• Contains SmartString? - Conditional point that validates if the DemandDetail line contains a configurable
part with a SmartString.
• Yes - The DemandDetail record contains a configurable part with a SmartString. The workflow then
proceeds to the Save Demand Configuration step.
• No - The DemandDetail record does not a configurable part with a SmartString. The workflow then
proceeds to the Prepare for Schedule step.
• Save Demand Configuration - This data conversion saves the demand configuration (part number,
DemandHead sequence and DemandDetail sequence) in memory as an XML file (the data is not physically
stored) for use by the Configuration EDIDemand Configuration workflow step.
• Configuration EDIDemand Configuration - This WebService splits the Smart String into individual
configuration inputs, tests them and then saves the configuration parameters until demand is formally processed
later in the workflow.
• Configuration Successful? - Conditional point that determines if the configuration processing performed
by the Configuration EDIDemand Configuration was successful.
• Yes - The configuration processing performed by the Configuration EDIDemand Configuration was
successful.The workflow then proceeds to the Prepare for Schedule step.
• No - The configuration processing performed by the Configuration EDIDemand Configuration was
unsuccessful. Service Connect performs the EDI Configuration Errors and DemandLogUpdate workflow
steps, which create a new record in the Demand Log. It then performs the Send EDI Configuration
Errors workflow step, which sends a call that displays as a EDI Configuration Errors message when you
• If you abort the workflow in the Task Monitor, Service Connect performs the DemandLog Update
CFG Errors and DemandLogUpdate workflow steps, which create a new record in the Demand Log.
It then performs the Abort EDI Configuration workflow step, and Abort before Updates workflow
step (not pictured), which prevents the Main_DemandDetailUpdate workflow from proceeding and
performing any further updates for this particular EDI transaction. It proceeds directly to the workflow
end point, goes back to the Main workflow, retrieves the next unprocessed EDI transaction in the input
channel and starts processing it.
• If you manually correct the Smart String input values on the inbound EDI transaction in the Task Monitor,
and then resubmit the corrected data for reprocessing, Service Connect performs the Resubmit EDI
Configuration and DemandLogUpdate workflow steps, which create a new record in the Demand
Log. It then performs the Save Demand Configuration workflow step, and proceeds directly to the
Configuration EDIDemand Configuration workflow step for configuration reprocesssing.
156 Epicor ERP | 9.05.700

• Prepare for Schedule - Performs a data conversion that takes a subset of the Demand_Schedule rows that
are attached to the Demand_Header row on the inbound EDI transaction. Service Connect saves it in memory
as an XML file (the data is not physically stored) and prepares it to be sent to the Process Inbound Demand
Schedules workflow step.
• Process Inbound Demand Schedules - Processing point that invokes the Main_DemandScheduleUpdate
workflow. This workflow processes and validates Demand_Schedule rows in inbound EDI transactions. Refer
to the Main_DemandScheduleUpdate Workflow section for more details.
• Return Schedule Complete Validated - Data conversion that retrieves the XML file that was generated by
the Demand Schedule Finished step in the Main_DemandSchedule Update workflow. This contains the
results of the validations of the Demand_Schedule rows for the inbound EDI transaction. Service Connect
saves it in memory as an XML file (the data is not physically stored) for use in data validation in the rest of the
Main_DemandDetail Update workflow.
• Continue with Demand Schedule Update? - Conditional point that determines if demand schedules were
successfully validated and processed by the Main_DemandSchedule Update workflow, and designates that
demand schedule updating should continue for the associated Demand_Detail rows in the inbound EDI
transaction.
• Yes - Denotes that processing of the Demand_Detail rows in the inbound EDI transaction should continue
because the associated demand schedules were successfully validated and processed by the
Main_DemandSchedule Update workflow. The workflow then proceeds directly to the DemandEntry
Update Schedules step.
Epicor ERP | 9.05.700 157

• Abort - Denotes that processing of the Demand_Detail rows in the inbound EDI transaction should be
aborted because the associated demand schedules were unsuccessfully validated and processed by the
Main_DemandSchedule Update workflow. The workflow then proceeds directly to the Finish Detail
Update step.
• DemandEntry Update Schedules - Data conversion that prepares the validated Demand_Schedule row
data to be sent to the Epicor application for updating of the DemandSchedule table. This prepares the validated
demand schedule data to be sent to the Epicor application for updating of the DemandSchedule table. Service
Connect saves it in memory as an XML file (the data is not physically stored) for use in data validation by the
DemandEntry Update Schedules WebService.
• DemandEntry Update Schedules (WebService) - Using the parameters passed to it by the previous workflow
step, this WebService creates new, or updates existing records in the DemandSchedule table in the Epicor
application database.
• Schedule Update Successful? - Conditional point that determines if the update of records in the
DemandSchedule table performed by the DemandEntry Update Schedules WebService were successful.
• Yes - Denotes that the update of records in the DemandSchedule table performed by the DemandEntry
Update Schedules WebService were successful. The workflow then proceeds to the Return Detail Date
Update Successful step.
• No - Denotes that the update of records in the DemandSchedule table performed by the DemandEntry
Update Schedules WebService were unsuccessful. Service Connect performs the DemandLog Update
Schedule and DemandLogUpdate workflow steps, which create a new record in the Demand Log. It
then performs the Demand Detail Update Errors workflow step, which sends a call that displays as a
Demand Schedules for Detail Update Errors error when you use the Service Connect Task Monitor.
Using the Task Monitor, you can either abort the Main_DemandDetailUpdate workflow, or correct the
error and then resubmit the corrected data for reprocessing by the Resubmit Demand Schedules workflow
step. Refer to Correcting Errors Using the Service Connect Task Monitor for more details.
If you abort the workflow in the Task Monitor, Service Connect performs the Abort DemandSchedules
for Update Errors and DemandLog Det Update workflow steps, which create a new record in the
Demand Log. It then performs the DemandLog Abort Det Update workflow step, which prevents the
particular EDI transaction. It proceeds directly to the Demand Detail Final Update step.
If you resubmit the corrected data for reprocessing, Service Connect performs the DemandLog Resubmit
DetUpdate and DemandLogUpdate workflow steps, which create a new record in the Demand Log. It
then performs the DemandLog F DetUpdate workflow step, and proceeds directly to the Prepare for
Schedule workflow step for reprocesssing.
• Demand Detail Final Update - Data conversion that contains the results of the demand schedule updates
for the associated demand line. This indicates that the demand detail lines can now be unlocked; this data is
then passed on to the Demand Detail Update WebService step.
• Demand Detail Update - This WebService uses the parameters passed on to it by the Demand Detail Final
Update step and unlocks demand detail lines in the DemandDetail table that were formally locked during
the DemandEntry Update Detail step. This occurred when the DemandDetail table was being updated
during the DemandEntry Update Detail step; this prevented concurrent processing or updating by another
source or program.
• Demand Update Successful? - Conditional point that determines if update of the DemandDetail table that
was performed by the previous workflow set was successful (a new record was created, or an existing record
was successfully updated).
• Yes/No Charges - Denotes that the update of the DemandDetail table that was performed by the previous
workflow set was successful, and there are no Extra_Charge rows on the inbound EDI transaction associated
with the Demand_Detail rows processed. The workflow then proceeds to the Finish Detail Update step.
158 Epicor ERP | 9.05.700

• Yes/Charges - Denotes that the update of the DemandDetail table that was performed by the previous
workflow set was successful and there are Extra_Charge rows on the inbound EDI transaction associated
with the Demand_Detail rows processed. The workflow then proceeds to the Detail ExtraCharge Update
Request step.
• No - Denotes that the update of the DemandDetail table that was performed by the previous workflow
set was unsuccessful. The workflow then proceeds to the Finish Detail Update step.
• Detail ExtraCharge Update Request - Performs a data conversion that saves the Extra_Charge record
associated with the Demand_Detail row that was processed in memory as an XML file (the data is not physically
stored) and prepares it to be sent to the Demand Entry Update workflow step.
• Demand Entry Update (WebService) - This WebService uses the data conversion parameters passed by the
previous step to update the associated DemandDetail table in the Epicor application database.
• Detail ExtraCharges Update Successful? - Conditional point that determines if update that was performed
by the previous workflow set was successful.
• Yes - Denotes that the update that was performed by the previous workflow set was successful. The
workflow then proceeds to the Finish Detail Update step.
• No - Denotes that the update that was performed by the previous workflow set was unsuccessful. Service
Connect performs the DemandLog Detail ExtraCharges Update and DemandLog Update workflow
steps, which create a new record in the Demand Log. It then performs the DemandDetail ExtraCharges
Update Error workflow step, which sends a call that displays as a DemandDetail ExtraCharges Update
Error message when you use the Service Connect Task Monitor.
correct the condition that is causing the error, and then resubmit the corrected data for reprocessing by
the Main_DemandDetailUpdate workflow. When you resubmit it, it performs the Resubmit DemandDetail
ExtraCharges Update step, which passes it to the Demand Detail Update step for reprocessing.
• If you abort the workflow in the Task Monitor, it performs the Abort DemandEntry Update workflow
step and the Abort before Updates workflow step (not pictured), which prevents the
• Finish Detail Update - This is the ending point of this workflow; all DemandDetail rows have now been
processed for the inbound EDI transaction. Using the results of the validations of the Demand_Detail rows
processed by the previous workflow steps, Service Connect saves it in memory as an XML file (the data is not
physically stored) to pass back to the Store Detail Workflow Responses step in the
• These parameters report if processing of the Demand_Detail rows on the inbound EDI transaction were
successfully completed, or any were aborted due to unresolved errors.
• The Main_DemandHeadUpdate workflow uses this data to determine if processing of the entire workflow
should be abort, or if should continue, how the DemandHead status should be updated.
Main_DetailPartValidation
The Main_DetailPartValidation workflow validates each of the part numbers contained in the Demand_Detail
rows in the inbound EDI file being processed. It passes this data to the Epicor application to perform validations
of internal part numbers, customer part numbers, manufacturer part numbers and EAN/GTIN/UPC product code
cross references.
Once it has completed performing all of these validations, it passes the validated part data back to the
Main_DemandDetailUpdate workflow to process the remainder of that workflow.
Epicor ERP | 9.05.700 159

This is the processing that takes place when the Main_DetailPartValidation workflow runs in Service Connect.
workflow step:
• Save Input Data - Data conversion that retrieves the XML file that was generated from the inbound EDI
transaction by the Validate Part Data step in the Main_DemandDetailUpdate workflow.
This is a listing of the internal part numbers, customer part numbers, manufacturer part numbers and
EAN/GTIN/UPC product code cross references on Demand_Detail rows in the inbound EDI transaction. Service
Connect saves it in memory as an XML file (the data is not physically stored) for use in data validation in the
rest of the Main_DetailPartValidation workflow.
• Part Validation - Data conversion prepares data passed from the Save Input step and saves it in memory
as an XML file (the data is not physically stored) to pass on to the Epicor application to perform part and
product code cross reference validations. This data includes the company ID, contract number, header sequence,
internal part number, customer part number, Unit of Measure code and document name.
• Part Validation - WebService that passes part number and UOM data to the Epicor application to perform
part and product code cross reference validations. Based on the hierarchical selections made for the customer
trading partner (or ship to location) in the Options Selected field in Customer Maintenance > Documents
or Ship To > Documents sheets, the Epicor appication performs the following validations:
• Check For Part - The Epicor application validates that corresponding part records exist for the part numbers
contained on Demand_Detail rows. If a part record does not exist, a warning will automatically appear in
the Demand Log for your review. By performing this validation, it helps to ensure that the Epicor application
is not accepted invalid part numbers on inbound EDI transactions received from this customer trading
partner.
• Use Customer Part - The Epicor application searches for and uses customer part numbers (if any) stored
in Demand_Detail rows on the inbound EDI transaction to retrieve the corresponding internal part numbers.
You create this customer part number cross reference using Customer Part Maintenance in the Epicor
application.
• Manufacturer Part - The Epicor application searches for and uses manufacturer part numbers (if any)
stored in Demand_Detail rows on the inbound EDI transaction to retrieve the corresponding internal part
160 Epicor ERP | 9.05.700

numbers. You create this manufacturer part number cross reference using Manufacturer Part Maintenance
• Use Part UPC - The Epicor application searches for and uses Universal Product Codes (UPC) (if any) stored
in Demand_Detail rows on the inbound EDI transaction to retrieve the corresponding internal part numbers.
An example of a product code is the UPC-12 (Universal Product Code) bar code found on most consumer
items purchased in the USA and Canada. Other product codes (for example, GTIN-14, EAN-13) are used
in various circumstances in different regions but are all similar to the UPC bar code. You create these
product code cross references for an internal part number in the Part Maintenance > Part > UOMs sheet.
• UPC-12 - This option operates in the same manner as Use Part UPC, but instead processes only UPC
product codes of up to 12 digits in length.
• GTIN-14 - This option operates in the same manner as Use Part UPC, but instead processes GTIN-14
(Global Trade Item Number) product codes of up to 14 digits in length.
• EAN-13 - This option operates in the same manner as Use Part UPC, but instead processes EAN-13
(European Article Number) product codes, 13 digits in length. It is referred to as a Japanese Article Number
(JAN) in Japan. These codes are used worldwide for marking retail goods.
14 digits in length.
eight digits in length.
• Valid Part? - Conditional point that determines if the part number contained on Demand_Detail row is valid,
based on the part and product code cross reference processing performed by the Epicor application.
• Yes - The part number contained on Demand_Detail row is valid. The workflow then proceeds to the
Continue Valid Part step.
• Send and By Pass - Denotes that the Check for Part, Check for Customer Part and Check for Revision
check boxes have been cleared for the customer trading partner in the Customer Maintenance > Customer
> Demand or Ship To > Demand sheets, and Use Part UPC has not been selected in the Options Selected
field in the Customer Maintenance > Documents and Customer Maintenance > Ship To > Documents.
This designates that Service Connect should skip validation of the part number; it instead invokes the Send
and By Pass step.
• No - The part number or product code contained on Demand_Detail row in the inbound EDI transaction
is invalid. Service Connect performs the DemandLog Invalid Part and DemandLogUpdate workflow
steps, which create a new record in the Demand Log. It then performs the Demand_Detail to Task
Monitor - Invalid Part workflow step, which sends a call that displays as an Invalid Part Task error
message when you use the Service Connect Task Monitor.
the part number or product code on the inbound EDI transaction that is causing the Invalid Part Task
error, and then resubmit the corrected data for reprocessing by the Main_DetailPartValidation workflow.
Refer to Correcting Errors Using the Service Connect Task Monitor for more details.
• If you abort the workflow in the Task Monitor, it performs the DemandLog Abort Invalid Part and
DemandLogUpdate steps, which create a Demand Log record. It then performs the Abort Valid
Part workflow step and Abort before Updates step (not pictured), which prevents the
Main_DetailPartValidation workflow from proceeding and performing any further updates for this
• If you manually correct the part number in the Task Monitor, and then resubmit the corrected data for
reprocessing, Service Connect performs the DemandLog Submit Invalid Part and DemandLogUpdate
workflow steps, which create a new record in the Demand Log. It then performs the Demand Resubmit
Invalid Part workflow step, and proceeds directly to the Part Validation workflow step, and resubmits
it for part validation processing.
Epicor ERP | 9.05.700 161

• Send And By Pass - Data conversion that stores the part number or product code cross reference that does
not require validation by the Epicor application. Service Connect saves it in memory as an XML file (the data
is not physically stored) for use in data validation in the rest of the Main_DetailPartValidation workflow. It
then performs the DemandLogUpdate and DemandLog ByPass workflow steps, which create a new record
in the Demand Log. It then proceeds to Continue Valid Part workflow step.
• Continue Valid Part - Data conversion that collects validated part numbers, and part numbers/product code
cross references that do not require validation. It marks them as validated, or not requiring validation, and
saves it in memory as an XML file (the data is not physically stored) for use in the Part Validation ByPart
Finished workflow step.
• PartValidation By Part Finished - Data conversion that collects validated part numbers, and part
numbers/product code cross references that do not require validation, and saves it in memory as an XML file
(the data is not physically stored) and returns it to the Backup Validated Data workflow step in the
Main_DemandDetailUpdate workflow.
Main_DemandScheduleUpdate Workflow
The Main_DemandScheduleUpdate workflow processes Demand_Schedule rows in inbound EDI files (S in

Data Position 1).
• Demand_Schedule rows in inbound EDI files contain descriptive demand schedule information that relates to
the Demand_Detail row to which it is linked.
• If they are successfully processed, this workflow creates individual demand schedule entries in the
DemandSchedule table in the Epicor application.
• Once the entire workflow completes, it passes the Demand Schedule data back to the
Main_DemandDetailUpdate workflow to process the remainder of that workflow.
This is the processing that takes place when the Main_DemandScheduleUpdate workflow runs in Service Connect.
workflow step:
• Save Schedule Date Set Defaults - Data conversion that retrieves the XML file that was generated from
the inbound EDI transaction by the Prepare for Schedule step in the Main_DemandDetailUpdate workflow.
This is a subset of the Demand_Schedule rows that are attached to the Demand_Header row on the inbound
EDI transaction. Service Connect saves it in memory as an XML file (the data is not physically stored) for use
in data validation and update tasks as it progresses through the rest of the Main_DemandScheduleUpdate
workflow.
162 Epicor ERP | 9.05.700

• Check Ship-To - Conditional point that determines if a ship to customer number exists in the Demand_Schedule
rows of the inbound EDI transaction, and if it does, is valid for the customer trading partner. It determines if
demand parameters have been defined for the ship to customer number in the Customer Maintenance >
Ship To > Demand sheet in the Epicor application. It then performs a data validation against the corresponding
values in the Demand_Schedule row data that is stored in physical memory from the inbound EDI transaction.
• Yes - The ship to customer on the Demand_Schedule rows is valid for the trading partner. The workflow
then proceeds to the Shipto GetRows step.
• No - There is no ship to customer number on the Demand_Schedule rows in the inbound EDI transaction.
Service Connect performs the DemandLog Submit Blank Ship workflow step, which creates a new
record in the Demand Log. It then proceeds to the Calculate Delivery Days workflow step.
• ShipTo GetRows - Performs a data conversion using the ship to customer number stored in the inbound EDI
file, and sends the correct parameters to the ShipTo GetRows WebService.
• ShipTo GetRows (WebService) - Using the ship to customer number parameter passed to it by the previous
workflow step, this WebService call retrieves the Demand_Schedule rows on the inbound EDI transaction that
contain the ship to customer number passed to it by the previous workflow step. Service Connect then
proceeds to the Calculate Delivery Days workflow step.
• Calculate Delivery Dates - Using the ship to customer number parameter passed to it by the previous
workflow steps, this data conversion calculates delivery dates for the demand schedules, based on the Ship
or Need By dates specified in the Demand_Schedule rows (on the inbound EDI transaction) and the Delivery
Days, Date Type and Periodicity field settings in the Customer Maintenance > Customer > Demand or Ship
To > Demand sheets. Refer to Defining Trading Partners in Customer Maintenance for more details on
how delivery dates are calculated.
• Valid Ship-to and Dates? - Conditional point that determines if the ship to customer number or the delivery
dates calculated by the previous Calculate Delivery Dates workflow step are valid.
• Yes - Denotes that the ship to customer number and delivery dates calculated by the previous Calculate
Delivery Dates workflow step are valid. The workflow then proceeds to the Continue - Valid Schedule
Update step.
• Invalid Date - The delivery dates calculated for the demand schedules by the previous Calculate Delivery
Dates workflow step are invalid or blank.
Service Connect performs the DemandLog Invalid Dates and DemandLogUpdate workflow steps,
which create a new record in the Demand Log. It proceeds to the Blank Ship By and Need By Dates
workflow step, which displays a corresponding error message in the Task Monitor. It then proceeds to the
Blank ShipBy and NeedBy Dates step.
• Invalid ShipTo - Ship to customer number calculated for the demand schedules by the previous Calculate
Delivery Dates workflow step is invalid. If the calculated delivery dates are invalid, workflow then proceeds
to the Blank ShipBy and NeedBy Dates step. Service Connect performs the DemandLog Invalid Release
Shipto and DemandLogUpdate workflow steps, which create a new record in the Demand Log. It then
performs the Invalid Shipto to Demand_Schedule workflow step, which sends a call that displays as
an Invalid Ship-to at Release error message when you use the Service Connect Task Monitor.
Using the Task Monitor, you can either abort the Main_DemandScheduleUpdate workflow, bypass
processing of this demand schedule release, or manually correct the invalid ship to customer number that
is causing the Invalid Ship-to at Header error, and then resubmit the corrected data to the Resubmit
Invalid Ship-To step for reprocessing by the Main_DemandScheduleUpdate workflow. Refer to Correcting
Errors Using the Service Connect Task Monitor for more details.
• If you abort the workflow in the Task Monitor, it performs the Abort Document Update workflow
step, which prevents the Main_DemandScheduleUpdate workflow from proceeding and performing
any further updates for this particular demand schedule. It proceeds directly to the Demand Schedule
Finished step.
Epicor ERP | 9.05.700 163

• If you bypass processing of the schedule release, it performs the Bypass Schedule Update step, which
bypasses processing of this demand schedule release and proceeds to the Demand Schedule Finished
step.
• If you correct the invalid ship to date in the Task Monitor, Service Connect performs the DemandLog
Abort Invalid Ship To and DemandLogUpdate workflow steps, which create a new record in the
Demand Log. It then performs the DemandLog Abort F Invalid Ship To and Resubmit Invalid Ship
To workflow steps, which resubmits the corrected dates to the Check Ship To? step.
• Blank ShipBy and NeedBy Dates - Invalid delivery date conditions are usually due to blank Ship By or Need
By dates stored in the Demand_Schedule rows in the inbound EDI transaction. This data conversion validates
that the Ship By or Need By dates in the Demand_Schedule rows in the inbound EDI transaction are blank. It
then sends a call that displays as a Blank ShipBy and NeedBy Dates error message when you use the Service
Connect Task Monitor.
Using the Task Monitor, you can either abort the Main_DemandScheduleUpdate workflow, or manually correct
the blank Ship By or Need By dates on the inbound EDI transaction that are causing the Blank ShipBy and
NeedBy Dates error, and then resubmit the corrected data for reprocessing by the
Main_DemandScheduleUpdate workflow. Refer to Correcting Errors Using the Service Connect Task
• If you abort the workflow in the Task Monitor, Service Connect performs the DemandLog Schedule
Blank Ship To and DemandLogUpdate workflow steps, which create a new record in the Demand Log.
It then performs the Abort Schedule Update workflow step, which prevents the
Main_DemandScheduleUpdate workflow from proceeding and performing any further updates for this
particular demand schedule. It proceeds directly to the Demand Schedule Finished step.
• If you manually correct the blank date in the Task Monitor, and then resubmit the corrected data for
reprocessing, Service Connect performs the DemandLog Resubmit Blank Ship and DemandLogUpdate
workflow steps, which create a new record in the Demand Log. It then performs the DemandLog Submit
Blank Ship workflow step, proceeds directly to the Main workflow, and resubmits it for processing to
the Resubmit Blank Ship By and Need By Dates workflow step.
• Demand Schedule Finished - Using the results of the validations of the demand schedule data for the
inbound EDI transaction processed by the previous workflow steps, Service Connect saves it in memory as an
XML file (the data is not physically stored) to pass back to the Return Schedule Complete Validated step
in the Main_DemandDetailUpdate workflow for required data validation and update tasks as it progresses
through the remainder of that workflow.
Correcting Errors Using the Service Connect Task Monitor
As described in the Service Connect Workflow Processing section, when the Service Connect EDI workflow
package detects validation errors, it produces various error messages that display in the Task Monitor. These
errors occur primarily due to mismatches between the data sent by your customer trading partner on an
inbound EDI transaction and corresponding data stored in your Epicor application.
• Using the Task Monitor, you can either abort workflow processing, or easily correct invalid data on inbound
EDI transactions, and then resubmit the corrected data for reprocessing by the particular workflow that
generated the error message.
• Refer to the Service Connect Guide for detailed information how to operate the Task Monitor.
Note The Service Connect Workflows automatically create Demand Log entries both before and after
you invoke the Task Monitor to make corrections to invalid data contained in inbound EDI transactions.
Refer to Demand Log Entries Generated from Service Connect Workflows for more details.
164 Epicor ERP | 9.05.700

Invalid Contract Task Error Example
In our first example, if the demand contract number specified on the inbound EDI transaction is not valid for the
trading partner, or cannot be found in the Epicor application database, an Invalid Contract Task error message
appears when you use the Service Connect Task Monitor.
In our first example, if the demand contract number specified on the inbound EDI transaction is not valid for the
trading partner, or cannot be found in the Epicor application database, an Invalid Contract Task error message
appears when you use the Service Connect Task Monitor.
• This means that your customer trading partner has either sent you an incorrect demand contract number, or
a corresponding demand contract record with that identifier number does not exist in the Epicor application
database (that is, has not been entered into Demand Contract Entry for that customer trading partner).
• To correct this error condition, you can either manually enter a valid demand contract (using the contract
identification number on the inbound EDI transaction) into Demand Contract Entry, or use the Task Monitor
to correct the demand contract number on the inbound EDI transaction to match one that exists in the Epicor
application, and then re-submit it for processing using the EDI workflows. You can also abort further processing
of the inbound EDI transaction. To correct the EDI transaction, you perform a series of actions in the
Task Monitor similar to what follows in the next example.
Invalid Demand Data Error Correction Example
In our second example, if document parameters have not been defined in the Customer Maintenance > Documents
sheet for the transaction type and customer trading number specified on an inbound EDI transaction, an Invalid
or Missing Data in DemandHead error message appears when you use the Task Monitor.
In our second example, if document parameters have not been defined in the Customer Maintenance > Documents
sheet for the transaction type and customer trading number specified on an inbound EDI transaction, an Invalid
or Missing Data in DemandHead error message appears when you use the Task Monitor.
• This means your customer trading partner has either sent an inbound EDI transaction with an incorrect
transaction type (FIRM4 instead of FIRM), or document parameters have not been defined for the transaction
type in the Customer Maintenance > Documents sheet and should be.
• To correct this error condition, you can either enter document parameters into the Customer Maintenance >
Documents sheet for the transaction type (in this case, FIRM4) and customer trading number specified on an
inbound EDI transaction, or use the Task Monitor to correct the transaction type on the inbound EDI transaction
itself, and then re-submit it for processing using the EDI workflows.
• You can also abort further processing of the inbound EDI transaction.
Epicor ERP | 9.05.700 165

If you choose to correct the transaction type on the inbound EDI transaction, you would do the following:
1. Select Active Tasks in the Task Monitor (refer to the Task Monitor graphic above). It displays all active tasks,
including inbound EDI transactions with reported errors. These errors are generated by the Service Connect
EDI workflow package discussed earlier in this document.
2. Select the error you wish to correct, and the click Show XML Editor.
3. When the XML Editor appears, the bottom portion of the editor displays a listing of the validation errors
that require correction in the selected inbound EDI transaction.
4. Click
on the line that contains the error condition. This places the cursor in the Value field.
5. In the Value field, correct the current incorrect value with the correct value you wish to use. In this example,
you would overwrite FIRM4 with FIRM.
6. When you have finished correcting the value, click
to save the newly entered value.
7. After correcting any remaining errors in the same fashion, click Save to save all updated values to the XML
record.
8. Click Process to process all changes made to the XML record. The following dialog is displayed:
166 Epicor ERP | 9.05.700

9. Select Resubmit Invalid Demand Data to reprocess the newly updated EDI transaction. This resubmits
the record for reprocessing through the Service Connect EDI workflow package. Select Abort Invalid
Demand Data to abort further processing of the inbound EDI transaction. Click Process to perform the
selected action using the updated EDI transaction.
Main_DemandHead Update Workflow Error Messages
The following errors are produced by the Main_DemandHead Update workflow in the Service Connect EDI
Workflow Package:
• Demand ExtraCharges Update Error - Denotes that Extra_Charge rows exist that are associated with the
Demand_Header row, and that update of the DemandHead table was unsuccessful.
Using the parameters passed to it by previous workflow steps, the DemandHead Update workflow step
that relates to the Demand_Detail rows linked to it. The Epicor application stores this information in the
DemandHead record it creates or updates; this constitutes the header portion of the resulting demand entry
records. Using the Task Monitor, you can either:
• Abort the DemandHeadUpdate workflow, or
• Manually correct the demand header extra charges condition that is causing the error, and then resubmit
the corrected data for reprocessing by the DemandHeadUpdate workflow.
• DemandHead Update Error - Denotes that the update of the DemandHead table was unsuccessful.
Using the parameters passed to it by previous workflow steps, the DemandHead Update workflow step
that relates to the Demand_Detail rows linked to it. The Epicor application stores this information in the
DemandHead record it creates or updates; this constitutes the header portion of the resulting demand entry
records. Using the Task Monitor, you can either:
• Manually correct the condition that is causing the error, and then resubmit the corrected data for
reprocessing by the DemandHeadUpdate workflow.
• Invalid Contract Task - Mismatch between the contract identification number on the inbound EDI transaction
and the demand contract identification number in the Epicor application. The demand contract number
specified on the inbound EDI transaction is not valid for the trading partner, or cannot be found in the Epicor
application database. Refer to the Invalid Contract Task Error Example section.
Epicor ERP | 9.05.700 167

• Invalid Demand Data - Mismatch between the transaction type on the inbound EDI transaction and the
document parameters defined for the transaction type in the Customer Maintenance > Documents or Ship
To > Documents sheets in the Epicor application. This means the transaction type is invalid because document
parameters do not exist for it in the Epicor application. Refer to the Invalid Demand Data Error Correction
Example section.
• Invalid Part Number in Detail - Denotes that the Part Number and Customer Part data positions in the
Demand_Detail rows on the inbound EDI transaction are blank. At least one of these data positions must
contain a value. This error prevents data from being passed from the Main_DemandDetailUpdate workflow
to the Main_DemandDetailUpdate workflow for comprehensive processing of the Demand_Detail rows
on the inbound EDI transaction. Using the Task Monitor, you can either:
• Abort the Main_DemandDetailUpdate workflow, or
• Manually correct the condition that is causing the error (in this case, adding the missing internal part or
customer part numbers in the Demand_Detail rows on the inbound EDI transaction) and then resubmit
the corrected data for reprocessing by the DemandHeadUpdate workflow.
Unposted Demand on File - Denotes that open (unshipped) demand schedules exist for the existing demand
entries retrieved in previous workflow steps. Using the Task Monitor, you can either:
• Delete the unposted demand schedules and then resubmit the corrected data for reprocessing by the
• Invalid Ship To at Demand Header - Mismatch between the ship to customer number on the inbound EDI
transaction and the parameters defined for the ship to customer in the Customer Maintenance > Ship To >
Demand sheet in the Epicor application. This means the ship to customer number is invalid because document
parameters do not exist for it in the Epicor application. Using the Task Monitor, you can either:
• Abort the Main_DemandHeadUpdate workflow, or
• Correct the ship to customer number on the inbound EDI transaction and resubmit the corrected data for
reprocessing by the DemandHeadUpdate workflow.
• As an alternative, you could also enter parameters (for the ship to customer number on the inbound EDI
transaction) into the Customer Maintenance > Ship To > Demand sheet.
• SC Demand - The demand entry record is in use in the Epicor application and is currently locked to prevent
concurrent processing or updating by another source or program. Using the Task Monitor, you can either:
• Abort the Main_DemandHeadUpdate workflow, or
• Manually remove the Service Connect Lock on the demand entry record and then resubmit the corrected
data for reprocessing by the DemandHeadUpdate workflow.
• As an alternative, you can also process the unposted demand schedules in the Epicor application itself
using the Post selection on the Demand Entry Actions menu.
Main_DemandDetail Update Workflow Error Messages
The following errors are produced by the Main_DemandDetail Update workflow in the Service Connect EDI
Workflow Package:
• DemandDetail ExtraCharges Update Error - Denotes that Extra_Charge rows exist that are associated
with the Demand_Detail row, and that update of the DemandDetail table was unsuccessful.
Using the parameters passed to it by previous workflow steps, the Demand Entry Update workflow step
attempts to write new records to, or update records in the DemandDetail table in the Epicor application
database. Using the Task Monitor, you can either:
• Abort the DemandDetailUpdate workflow, or
168 Epicor ERP | 9.05.700

• Manually correct the demand DETAIL extra charges condition that is causing the error, and then resubmit
the corrected data for reprocessing by the DemandDetailUpdate workflow.
• Demand Detail Update Error - Denotes that the DemandDetail lock is turned on, or unposted demand is
on file for the existing demand detail line that the Demand Entry UpdateFoundLine WebService is attempting
to update. Using the Task Monitor, you can either:
• Manually remove the lock on the demand detail record and then resubmit the corrected data for
reprocessing by the Main_DemandDetailUpdate workflow.
• Demand Schedules for Detail Update Error - Denotes that the update of records in the DemandSchedule
table performed by the DemandEntry Update Schedules WebService were unsuccessful. Using the Task
Monitor, you can either:
• Abort the Main_DemandDetailUpdate, or
• Correct the report error that is preventing the update of demand schedule records in the DemandSchedule
table (in the Epicor application database).
• EDI Configuration Errors - Denotes that after the Main_DemandDetailUpdate workflow has split a
configuration Smart String received on an inbound EDI transaction into individual configuration inputs, and
has tested them, it has determined that it is not valid (that is, cannot be processed into a valid configuration).
Using the Task Monitor, you can either:
•
• Manually correct the Smart String input values on the inbound EDI transaction, and then resubmit the
corrected data for reprocessing by the Main_DemandDetailUpdate workflow.
Main_DetailPartValidation Workflow Error Messages
The following error is produced by the Main_DetailPartValidation workflow in the Service Connect EDI Workflow
Package:
• Invalid Part Task - Denotes that the internal part number, customer part number, manufacturer part number
or EAN/GTIN/UPC product code cross reference is invalid in the Epicor application. When an Invalid Part
Task message appears in the Task Monitor, check the Demand Log or Demand Review Report for additional
information about the exact nature of the part validation problem.
Note Error messages appear on the Demand Log (on the Demand Entry Actions menu) or on the
Demand Review Report that explain why the Epicor application rejected and did not process demand.
These errors are generated by the Service Connect Workflows when they attempt to process demand
received on inbound EDI transaction from your customer trading partner, or when you manually process
demand records using Demand Entry or Demand Mass Review. This includes reporting invalid customer
part, manufacturer part and invalid EAN/GTIN/UPC product code reference errors.

• Abort the Main_DetailPartByPart workflow, or
• Manually correct the invalid internal part number on the inbound EDI transaction that is causing the error,
and then resubmit the corrected data for reprocessing by the Main_DetailPartValidationByPart workflow,
or
• If the inbound EDI transaction contains an invalid customer part number, you can add the missing
internal part number into Part Maintenance, and then resubmit the inbound EDI transaction for reprocessing
by the Main_DetailPartValidationByPart workflow.
Epicor ERP | 9.05.700 169

• If the inbound EDI transaction contains an invalid customer part number, this means that the customer
part number does not cross-reference to a valid internal part number in the Epicor application. To resolve
this, you can add the customer part number into Customer Part Maintenance, making sure it cross-references
to a valid internal part number, and then resubmit the inbound EDI transaction for reprocessing.
• If the inbound EDI transaction contains an invalid manufacturer part number, this means that the
manufacturer part number does not cross-reference to a valid internal part number in the Epicor application.
To resolve this, you can add the customer part number into Manufacturer Part Maintenance, making sure
it cross-references to a valid internal part number, and then resubmit the inbound EDI transaction for
reprocessing.
• If the inbound EDI transaction contains an invalid EAN/CTIN or UPC product code, this means that the
product code stored in the inbound EDI transaction does not cross-reference to a valid internal part number
in the Epicor application. To resolve this, you can cross reference the applicable product code using the
Part Maintenance > Part - UOMs sheet, making sure it cross-references to a valid internal part number,
and then resubmit the inbound EDI transaction for reprocessing.
Main_DemandSchedule Update Workflow Error Messages
The following errors are produced by the Main_DemandSchedule Update workflow in the Service Connect EDI
Workflow Package:
• Blank ShipBy and NeedBy dates - Denotes that the Ship By and Need By date positions on the
Demand_Schedule rows are blank, causing invalid delivery date calculations for the inbound EDI transaction.
• Abort the Main_DemandScheduleUpdate workflow, or
• Manually correct the blank Ship By or Need By dates on the inbound EDI transaction that are causing the
error, and then resubmit the corrected data for reprocessing by the Main_DemandScheduleUpdate
workflow.
• Invalid ShipTo at Release - Denotes that the ship to customer on the Demand_Schedule row of the inbound
EDI transaction is invalid for the trading partner, or cannot be found in the Epicor application database. Using
the Task Monitor, you can either:
• Abort the Main_DemandScheduleUpdate workflow.
• Manually correct the ship to customer on the inbound EDI transaction that is causing the error condition,
and then resubmit the corrected data for reprocessing by the Main_DemandScheduleUpdate workflow,
or
• Bypass processing of this demand schedule release.
• As an alternative, you could also add the missing parameters for the ship to customer number into the
Customer Maintenance > Ship To > Demand sheet in the Epicor application.
170 Epicor ERP | 9.05.700

Demand Entries Generated from Inbound EDI Transactions
When inbound EDI transactions are received from your customer trading partners, the Epicor application processes
demand using EDI workflows that in effect perform the same tasks as Demand Entry or Demand Mass Review,
but in a totally automated manner.
If the Epicor application is configured to do so, the workflows automatically generate records in the following
tables in the Epicor application database from inbound EDI transactions:
• DemandHead - Contains demand header information that can be viewed or edited in the Demand Entry -
Header sheet. This record is generated from the Demand Header row on the inbound EDI transaction.
• DemandDetail - Contains demand detail line information that can be viewed or edited in the Demand Entry
- Lines sheet. These records are generated from the Demand Detail rows on the inbound EDI transaction.
Demand Detail rows in inbound EDI files contain descriptive demand detail information that relates to the
Demand Header row to which it is linked.
• DemandSchedule - Contains demand schedule information that can be viewed or edited in the Demand
Entry - Lines sheet. These records are generated from the Demand Schedule rows on the inbound EDI
transaction. Demand Schedule rows in inbound EDI files contain descriptive demand schedule information
that relates to the Demand Detail row to which it is linked.
You can then use Demand Entry as necessary to review the demand lines and shipping schedule, letting you
evaluate their impact.
• It contains tools that let you to manually accept, revise, or manually reject demand entries, lines and schedules.
This provides you with the ability to view the impact of incoming contract changes before accepting them.
• You can also manually override System Rejected demand entries that have not passed validations based on
user-defined rules you specify for the customer trading partner in the Customer Maintenance > Customer >
Epicor ERP | 9.05.700 171

Demand or Ship To > Demand sheets. Refer to Demand Processing Logs and Error Resolution for more
details.
• You can also override or enter new part numbers and prices as necessary; when this is done, the Epicor
application automatically updates the linked demand contract and any associated sales orders accordingly. If
the demand contract does not contain that part, the Epicor application creates a new contract line for the
new part and price. If the demand contract does contain an existing line with that part number, only the price
is updated.
• When you are satisfied with a demand schedule, you can then use the Process selection (on the Demand
Header section of the Actions menu) to manually process the demand. Depending on the demand type, the
Demand Entry process either creates unfirm order releases, firm order releases, or MRP forecasts. You can do
this if the Epicor application is not configured to do so automatically through workflow processing for the
customer trading partner. You can then use either Sales Order Entry or Forecast Entry to further refine the
resulting data.
• To complete the functionality, process the demand. Demand Entry has additional functions that help analyze
the incoming demand. Schedule Review allows you to examine the shipping schedule that results. Delete by
Schedule Number allows you to remove an individual shipping schedule. The Match program allows you to
combine a new release with any previous releases generated through this demand record.
• Refer to the Application Help for complete details on how to use Demand Entry.
Demand Processing Logs and Error Resolution
Error messages appear on the Demand Log (on the Demand Entry Actions menu) or on the Demand Review
Report that explain why the Epicor application rejected and did not process demand. These errors are generated
when they attempt to process demand received on inbound EDI transaction from your customer trading partner,
or when you manually process demand records using Demand Entry or Demand Mass Review.
For example, the Customer Maintenance > Customer > Demand and Ship To > Demand sheets allow you to
define demand processing parameters that specify how differences in unit price, partial shipments, part records
and revision levels should be evaluated by the Epicor application during demand processing. They also allow you
to specify the lead times required to evaluate and process the following types of action requests on incoming
EDI transactions received from this customer trading partner:
• Add a new demand schedule.
• Change requests for a demand schedule. This does not apply to demand schedule quantity or date changes.
• Cancellation requests for a demand schedule.
• Add a new order line to a demand order.
• Quantity change requests for a demand schedule.
• Date change requests for a demand schedule.
For each type of action request, you specify the actions that should take place in the Epicor application (stop
transaction or process transaction and display a warning message) when incoming EDI transactions are received
with insufficient lead times with respect to the parameters you have specified for that type of transaction.
If set to Stop, the Epicor application marks the demand line as System Rejected in Demand Entry; however,
you can manually accept the incoming demand by selecting the Override System Reject check box. This allows
you to designate that the demand schedule/line/demand header can be processed to generate an order or forecast
172 Epicor ERP | 9.05.700

Error messages appear on the Demand Log (on the Demand Entry Actions menu) or on the Demand Review
Report, explaining why the Epicor application rejected and did not process the demand.
Epicor ERP | 9.05.700 173

If set to Warning, it designates that the Epicor application should accept and process these types of transaction.
Warning messages display on the Demand Log or on the Demand Review Report informing you that the incoming
demand contains differences in unit pricing from your current price.
Example The Add field is set to four days for Company ABC. They send you a request to add a new
demand schedule that they would like shipped in the next day.
• Because the demand schedule change request was received with insufficient lead time notification, a Stop or
Warning takes place, depending on the setting of the Action (Add) field.
• Referring to the above graphic, the error condition appears on the Demand Log.
• If it is a Stop condition, you can override the System Rejected condition in Demand Entry and then reprocess
the demand entry using the Process selection on the Demand Header section in the Actions menu.
Demand Log Entries Generated from Service Connect Workflows
When you process EDI documents using the Service Connect Workflows, they automatically generate Demand
Log entries both before and after you invoke the Task Monitor to make corrections to invalid data contained in
inbound EDI transactions
For example, when the Main_DemandHeadUpdate Workflow determines that a demand entry record is in use
in the Epicor application and is currently locked to prevent concurrent processing or updating of records by
another source or program, it creates LockedDemand error on the Demand Log. When you use the Task Monitor
to abort the workflow, it generates an Abort error on the Demand Log; if you correct the problem and resubmit
it for reprocessing, it generates an Resubmit error on the Demand Log.
The following table contains a listing of these generated error codes, and a description of each one:
Error Code Description
Abort Log entry generated when a user aborts processing of

an inbound EDI transaction file using the Service
BlankDates Log entry generated when blank Need By and Ship By

dates are identified in the
Main_DemandScheduleUpdate workflow.
CTPDates Log entry generated when an attempt is made to

update CTP Ship By or Need By dates.
DemandDetUpdate Log entry generated for errors identified when updating

the DemandDetail table in the Epicor application cannot
be updated by the Main_DemandDetailUpdate
workflow.
DemandHedUpdate Log entry generated when the DemandHead table in

the Epicor application cannot be updated by the
DemandSchUpdate Log entry generated for errors identified when updating

the DemandSchedule table in the Epicor application
cannot be updated by the
Main_DemandScheduleUpdate workflow.
174 Epicor ERP | 9.05.700

InvalidContract Log entry generated when an invalid contract is

identified in the Main_DemandHeadUpdate workflow.
InvalidDocument Log entry generated when an invalid document is

InvalidPart Log entry generated when an invalid part is identified

in an inbound EDI transaction file by the
Main_DetailPartValidation workflow.
InvalidRevision Log entry generated when an invalid part revision is

identified an inbound EDI transaction file.
InvalidShipTo Log entry generated when an invalid ship to customer

code is identified in the Main_DemandScheduleUpdate
workflow.
LeadTimeAdd Log entry generated when a request is received on an

inbound EDI transaction to add a demand schedule and
it falls within the Add lead time window.
LeadTimeCancel Log entry generated when a request is received on an

inbound EDI transaction to change a demand schedule
and it falls within the Change lead time window.
LeadTimeChange Log entry generated when a request is received on an

inbound EDI transaction to cancel a demand schedule
and it falls within the Cancel lead time window.
LeadTimeDateChange Log entry generated when a request is received on an

delivery date and it falls within the Date Change lead
time window.
LeadTimeNewLine Log entry generated when a request is received on an

inbound EDI transaction to add a new demand line and
it falls within the New Line lead time window.
LeadTimeQtyChange Log entry generated when a request is received on an

quantity and it falls within the Quantity Change lead
time window.
LockedDemand Log entry generated when locked demand is identified

in the Main_DemandHeadUpdate workflow.
PartialShipments Log entry generated when an attempt is made to

update a sales order release that has been been partially
shipped.
Epicor ERP | 9.05.700 175

PriceDiscrepancy Log entry generated when comparing the price received

on an inbound EDI transaction file, when compared to
the Internal price.
Resubmit Log entry generated when a user resubmits an inbound

EDI transaction file for reprocessing using the Service
UnpostedDemandOnFile Log entry generated when unposted demand is

Order Transactions Generated from Inbound EDI Demand
As part of Demand Management processing, order transactions are automatically generated by (or manually
created in) the Epicor application from inbound EDI demand. The resulting order transactions can be viewed or
edited in Sales Order Entry.
These order transactions consist of records in the following main database tables:
• OrderHed - Contains order header information that can be viewed or edited in the Header or Summary
sheets. When an order is generated from demand entries, this information is based on the data contained in
the DemandHead table record, which itself is generated from the Demand Header row on the inbound EDI
transaction.
176 Epicor ERP | 9.05.700

• OrderDtl - Contains order line detail information that can be viewed or edited in the Lines sheet. When an
order is generated from demand entries, this information is based on the data contained in the DemandDetail
table record, which itself is generated from Demand Detail rows on the inbound EDI transaction.
• OrderRel - Contains order release information that can be viewed or edited in the Releases sheet. When an
order is generated from demand entries, this information is based on the data contained in the DemandSchedule
table record, which itself is generated from Demand Schedule rows on the inbound EDI transaction.
• Firm or unfirmed order releases are created, depending on the demand type (FIRM or UNFIRM) associated
with the transaction type stored in Data Position 5 on the Demand Header row in the inbound EDI
transaction.
• This status is indicated by the Not Firm or Firm Release indicators in the Releases sheet.
Tip The Epicor application also generates unfirm order releases if a Material Requirements
Planning license is not installed and you process an inbound EDI transaction that contains a transaction
type associated with a FORECAST demand type. If you have an installed Material Requirements
Planning license, the Epicor application generates a normal forecast transaction that can be viewed
in Forecast Entry. Refer to Forecast Transaction Generated from Inbound EDI Demand for more
details.
The precise timing and method used by the Epicor application to generate an order transaction from inbound
demand is dependent on the setting of the Accept Type field in the Customer Maintenance > Documents or
Ship To > Documents sheet for the customer (or ship to customer) trading partner associated with the inbound
Epicor ERP | 9.05.700 177

EDI transaction. The Accept Type field specifies if inbound EDI documents should automatically be accepted or
rejected for this customer trading partner:
• If set to Always Accept, the Epicor application automatically processes demand for this customer trading
partner, regardless of whether there are errors in the inbound EDI document.
• When Service Connect runs the EDI workflow, the DemandEntry Process Demand WebService step
(in the Main_DemandHead Update workflow) automatically creates demand entries in the Epicor
application and immediately generates sales order and forecast entries at the time the inbound EDI
file is successfully processed by Service Connect. This eliminates the need to manually use the Process
selection in the Demand Header section of the Demand Entry Actions menu to process the demand.
• In cases where the inbound EDI transaction does contain errors (for example, a Date Change action
request is received with insufficient lead time, and a Stop or Warning condition would normally be applied),
the Epicor application automatically overrides any System Rejection flags, processes the demand
• If set to Accept If No Errors, the DemandEntry Process Demand WebService step (in the
Main_DemandHead Update workflow) automatically processes demand and immediately generates
sales order and forecast entries for this trading partner only if there are no errors in the inbound EDI
document. This eliminates the need to manually use the Process selection in the Demand Header section of
the Demand Entry Actions menu to process the demand.
• In cases where the inbound EDI transaction does contain errors (for example, a Date Change action request
is received with insufficient lead time), the Epicor application handles it in the normal manner- it applies
Stop (with System Rejection) or Warning conditions, depending on the settings for the customer trading
partner in the Customer Maintenance > Customer > Demand or Ship To > Demand sheets.
• It does not immediately generate sales order and forecast entries in these situations.
• Manually Accept - Demand from this incoming document for this ship to customer trading partner should
only be manually processed.
• In this case, Service Connect creates demand entries but you must manually process them using the Process
selection of the Demand Header section in the Demand Entry Actions menu.
• It only creates order releases at the time you do this manual processing. Refer to the Application Help for
more details.
• Hold- When selected, this check box indicates that this order is currently not in process and will not be
displayed on various reports. The Hold indicator appears as green if the order is manually placed on hold.
• A Hold Order by Demand indicator appears next to the Hold indicator if the order has been generated
from a demand contract in Demand Entry and the Hold Orders for Review check box has been selected
for the demand contract in the Demand Contract Entry Header or Summary sheets. This indicator does
not appear for orders that are manually placed on hold.
Tip If the Allow Shipments for Orders on Hold check box has been cleared for this company in
the Company Configuration > Modules > Materials > Shipping/Receiving sheet, this prevents
processing of shipments for sales orders that have been placed on hold. This affects shipment
programs such as Customer Shipment Entry and Master Pack Shipment Entry throughout the Epicor
application. Sales order holds must first be removed in order to process shipments.
178 Epicor ERP | 9.05.700

Forecast Transactions Generated from Inbound EDI Demand
If you have an installed Material Requirements Planning license, forecast transactions are automatically by (or
manually created in) the Epicor application for inbound EDI transactions. This occurs if a FORECAST demand type
is associated with the transaction type (stored in Data Position 5 on the Demand Header row) in the inbound EDI
transaction.
The resulting forecast transactions can be viewed or edited in Forecast Entry.
Forecast transactions consist of a single record stored in the Forecast table in the Epicor application database. It
contains information that is based on a combination of data contained in the following tables:
• DemandHead - Contains demand header information, which itself is generated from Demand Detail rows
on the inbound EDI transaction.
• DemandSchedule - Contains demand schedule information, which itself is generated from Demand Schedule
rows on the inbound EDI transaction.
Tip The Epicor application generates unfirm order releases in place of forecast transactions if a Material
Requirements Planning license is not installed and you process an inbound EDI transaction that contains a
transaction type associated with a FORECAST demand type.
Epicor ERP | 9.05.700 179

The precise timing and method used by the Epicor application to generate an order transaction from inbound
demand is identical to the manner in which it determines how order transactions are generated.
• It is dependent on the setting of the Accept Type field in the Customer Maintenance > Documents or Ship
To > Documents sheet for the customer (or ship to customer) trading partner associated with the inbound
EDI transaction.
• The Accept Type field specifies if inbound EDI documents should automatically be accepted or rejected for
this customer trading partner.
• Refer to Order Transactions Generated from Inbound EDI Demand for more details.
EDI 855/865/ORDRSP Transactions (Outbound Purchase/Change Order

Acknowledgements)
The EDI 855/865 (Outbound Purchase/Change Order Acknowledgements) document is an electronic version
of a phone call or fax you use to inform customer trading partner who sent you a purchase order that you are
fulfilling the purchase order as requested.
• This informs them that you are filling the order and shipping the goods by the requested date, or are not able
to fulfill the entire order as requested, possibly due to stockouts or disagreement about the purchase terms.
• EDI 855/865/ORDRSP transactions are usually sent in response to an EDI 850/ORDERS inbound purchase order
document you receive from your customer trading partner.
The Epicor application utilizes the user-customized version of the standard EDIOrdAck report data definition (as
designated in Report Style Maintenance for the Sales Order Acknowledgement) to generate the EDI 855/865
(Order Acknowledgement) document that confirms that a sales order is in process. In essence, the Epicor
application sends the Purchase Order Acknowledgement report to your customer trading partner. It also uses
the same report data definition to produce Responses to a Sales Order Change and Order Status documents.
• If the Automatic check box has been selected for the Sales Order Acknowledgement document type in
the Outbound Document section of the Customer Maintenance > Documents or Ship To > Documents
sheets (for this customer or ship to trading partner), the Epicor application automatically produces this document
record at the same time it generates sales order release for inbound EDI demand requests received from this
customer trading partner. In this case, no manual intervention is required on the part of a user.
You can use the Mass Print Packing Slips selection on the Demand Management Reports menu to print
automatically generated ASN documents en mass.
• To manually generate this document record, you use the Print Sales Order Acknowledgement selection
on the Sales Order Entry Actions menu.
180 Epicor ERP | 9.05.700

Whether processed automatically or manually, the Epicor application uses the report data definition specified in
Report Style Maintenance to generate the following Sales Order Acknowledgement document record:
It generates and stores this Sales Order Acknowledgement document record in the designated destination folder
for outbound EDI files (for example, c:\epicordata\edi_data\outbound\SOAck).
• Once the Epicor application has deposited this file in the designated destination folder on your server, the
third party TIE KINETIX eVision software retrieves the outbound Sales Order Acknowledgement document
record and transmits it as an EDI 855/865/ORDRSP transaction to your customer trading partner.
Epicor ERP | 9.05.700 181

EDI 856/DESADV Transactions (Outbound Advance Shipping Notices)
The EDI 856/DESADV (Outbound Order Advanced Shipping Notice/Manifest - ASN) document is an
electronic version of a printed packing slip that tells your customer trading partner how you, the supplier, has
packed their items for shipment.
• The Advance Ship Notice, or ASN, also tells the buyer that the goods have been shipped so they can be
expecting the shipment.
• This type of outbound EDI transaction, along with a UCC-128 bar code label, lets your customer trading
partner's receiving dock know what you have packed in shipping cartons, and eliminates the need for their
receiving personnel open the cartons. The UCC-128 bar code label contains your assigned supplier number,
ASN number, and carton number. The receiving dock can scan the bar code label and then check the EDI
transaction that they previously received electronically from you to know the contents of the cartons.
The Epicor application utilizes the user-customized version of the standard EDIPckSI or EDIMstPk report data
definitions (as specified in Report Style Maintenance) to generate the outbound Advanced Shipping Notice
(ASN) EDI 856/DESADV document used to track the progress of master pack shipments. This document lets
your customer trading partner know when order releases have been shipped from your company. The Epicor
application produces this document record when you process a shipment in Customer Shipment Entry or Master
Pack Entry; the specific report data definition it uses is dependent on where you process the order release shipment.
• If the Automatic check box has been selected for Advanced Shipping Notice (ASN) document type in the
Outbound Document section of the Customer Maintenance > Documents or Ship To > Documents sheets
Customer Maintenance > Documents or Ship To > Documents sheets (for this customer or ship to trading
partner), the Epicor application automatically produces this document record as soon as a sales order is
marked as shipped in Customer Shipment Entry or Master Pack Shipment Entry. In this case, no manual
intervention is required on the part of a user.
You can use the Mass Print Packing Slips selection on the Demand Management Reports menu to print
automatically generated ASN documents en mass.
• To manually generate this document record in Customer Shipment Entry, you use the Print selection on
the Actions menu.
182 Epicor ERP | 9.05.700

Report Style Maintenance to generate the following Advanced Shipping Notice (ASN) packing slip document
record. Correspondingly, if you ship an order release using Master Pack Shipments Entry and use the Print
selection on its Actions menu, it uses the EDIMstPk record definition to generate a similar ASN Master Pack
document record.
It generates and stores the ASN document record in the designated destination folder for outbound EDI files (for
example, c:\epicordata\edi_data\outbound\ASNs). For the ASN Master Pack document record, it stores it in
the designated destination folder (c:\epicordata\edi_data\outbound\MasterPack).
• Once either of these ASN document records has been deposited in one of the designated destination folders
on your server, the third party TIE Commerce eVision software retrieves the outbound ASN packing slip or
Epicor ERP | 9.05.700 183

Master Pack document record and transmits it as an EDI 856/DESADV transaction to your customer trading
partner.
EDI 810/INVOIC Transactions (Outbound Invoices)
The EDI 810/INVOIC (Outbound AR Invoices) document is an electronic version of a paper invoice you normally
send to your customer. As a supplier, you use 810/INVOIC Invoices to communicate the payment terns, specific
items, price, and quantities you have delivered and which now must be paid for by your customer trading partner.
In the Epicor application, the foundation for this type of outbound EDI document is the text or XML-based
document record that it generates (either automatically or manually) in AR Invoice Entry based on the standard
AR Invoice form.
The Epicor application utilizes the user-customized version of the standard EDIARFm report data definition (as
specified in Report Style Maintenance) to generate the outbound EDI 810/INVOIC Invoice document that you
send to bill your customer trading partner. The Epicor application produces this when you generate an invoice
from the order release shipment record in AR Invoice Entry.
• If the Automatic check box has been selected for Invoice document type in the Outbound Document
section of the Customer Maintenance > Documents or Ship To > Documents sheets (for this customer or ship
to trading partner), the Epicor application automatically produces this document record when the Epicor
application successfully posts the AR invoice to the General Ledger. In this case, no manual intervention
is required on the part of a user.
You can use the Mass Print AR Invoices selection on the Demand Management Reports menu to print
automatically generated AR invoices en mass.
• To manually generate this document record, you use the Print selection on the Get section of the AR Invoice
Entry Actions menu.
184 Epicor ERP | 9.05.700

Report Style Maintenance to generate the following AR Invoice document record:
It generates and stores this AR Invoice document record in the designated destination folder for outbound EDI
files (for example, c:\epicordata\edi_data\outbound\Invoices).
• Once the Epicor application has deposited this record in the designated destination folder on your server, the
third party TIE Commerce eVision software retrieves the outbound AR Invoice document record and transmits
it as an EDI 810/INVOIC transaction to your customer trading partner.
Epicor ERP | 9.05.700 185

Demand Review Report
The Demand Review Report provides information on demand that was entered manually or imported via direct
EDI import or using Service Connect. This report is based on the DemandSchedule table and contains the
information that is used to update sales order releases.
You can enter demand manually or import it automatically. Once you create demand records, you can automatically
process them to create or update sales orders. During this process various validations are performed on the data.
Any records that do not pass are rejected, and you must correct them manually before resubmitting them. This
can be a time-consuming process if you are processing a large volume of data. The Demand Review Report
displays this information from the demand perspective, that is, what demand has been processed, what orders
were updated, what demand was rejected or unprocessed.
The report provides you with the following information:
• Whether demand has been processed.
• The date and time demand was processed.
• Which sales orders were updated.
• Values on the sales orders before the update.
• Whether demand was rejected during the validation process and if so, why.
• Whether there is demand waiting to be processed.
• Whether some demand was processed but did not update any sales orders.
By default, all demand information is displayed, and you can exclude various types of information as necessary.
The following filtering options are available:
• By date - The From Date and To Date default to today's date, but you can change them as necessary.
• By customer - By default, the report displays information on all customers, but you can select one or more
customers as necessary.
• By part - By default, the report displays information on all parts, but you can select one or more parts as
necessary.
• By purchase order - By default, the report displays information on all purchase orders, but you can select
one or more purchase orders as necessary.
• By sales order - By default, the report displays information on all sales orders, but you can select one or
more sales orders as necessary.
• Exclude rejected demand - By default, rejected demand records are included in the report, but you can
exclude them if necessary.
• Exclude items with no changes - These are the items where new demand did not change the associated
order or where order releases exist that do not have associated demand and therefore were not updated.
• Exclude processed records - By default, the demand records that have been processed previously are included
in the report, but you can exclude them if necessary.
• Exclude posted records - By default, posted demand records are included in the report, but you can exclude
them if necessary.
• Exclude closed records - By default, closed demand records are included in the report, but you can exclude
them if necessary.
Below is an example of the Demand Review Report:
186 Epicor ERP | 9.05.700

The report includes the following data:
1. Information from the demand header and line plus lookup information from the part and customer records.
2. If the demand has already been posted, this is the sales order data as it was before the update. If the demand
has not been processed yet or has been rejected, the information is current.
3. Date when the demand schedule was processed. If there is no date, it means the demand has not been
processed.
4. This indicates whether the demand schedule has been posted and whether the sales order has been updated.
Demand to Sales Order Net Change Report
Users processing release changes from demand to sales orders need a way of knowing exactly what details of
an order release have been changed. For a user dealing with demand records that have a large number of releases,
it is practically impossible to find out exactly what has been changed and it is therefore difficult to take the
appropriate action. The Demand to Sales Order Net Change Report informs you what information changed on
the sales order after demand was processed.
For example, in the case of a delivery being required earlier than originally planned, the job producing the stock
may need to be expedited in order to meet this new delivery date. Alternatively, a job to manufacture a custom
part may need to be stopped due to the cancellation of the order by the customer. The Demand to Sales Order
Net Change Report provides all this information.
The following filtering options are available on this report:
• By transaction date - You must select the From and To dates.
• By sales order number - By default, the report includes data on all sales orders, but you can enter a sales
order number if necessary.
• By trading partner name - By default, the report includes data on all trading partners, but you can enter a
trading partner name if necessary.
• By part - By default, the report includes data on all parts, but you can select one or more parts as necessary.
• By customer - By default, the report includes data on all customers, but you can select one or more customers
as necessary.
Below is an example of the Demand to Sales Order Net Change Report:
Epicor ERP | 9.05.700 187

This report shows two changes to the same order release. The first shows an increase to the quantity of twenty
and the second moving back the Need By and Ship By Dates by one day.
188 Epicor ERP | 9.05.700

EDI / Demand Management Technical Reference Guide Modifiers
Modifiers
This section details the various fields and tools you can use to adjust primary the EDI / Demand Management
module interface calculations. It contains descriptive information, the program in which the modifier is located,
logic/algorithms and examples for many of the modifiers.
Note that this section is not all-inclusive; it only includes fields, check boxes or combo boxes that actually have
some effect on the behavior of the EDI / Demand Management module interface. It does not include data entry
fields that simply update literals that do not impact of EDI / Demand Management functionality.
Accept Type
Specifies if inbound EDI documents should automatically be accepted or rejected for this customer trading partner:
• Always Accept - The Epicor application should automatically process demand for this customer trading
partner, regardless of whether there are errors in the inbound EDI document. This automatically creates
demand entries in the Epicor application and immediately generates sales order and forecast entries at
the time the inbound EDI file is successfully processed. This eliminates the need to manually use the Process
selection in the Demand Header section of the Demand Entry Actions menu to process the demand.
• In cases where the inbound EDI transaction does contain errors (for example, a Date Change action request
is received with insufficient lead time, and a Stop or Warning condition would normally be applied), the
Epicor application automatically overrides any System Rejection flags, processes the demand and
subsequent sales order and forecast entries despite the error condition.
• Refer to the Customer Maintenance > Customer > Demand section for more details on error conditions
Note The manner in which Epicor ERP handles rejections (error conditions) while processing inbound
EDI transactions depends on where the error occurs within the record:
• If it occurs at the Demand Header row level (for example, a duplicate PO error), the associated
sales order and all attached order lines/order ship schedules generated from the demand header
• If it occurs at the Demand Detail row level (for example, a price mismatch error), only the associated
order line and the attached order ship schedules generated from that demand detail row are placed
on hold.
• If it occurs at the Demand Schedule row level (for example, a lead time error), only the order ship
schedule generated from that demand schedule row are placed on hold.
Refer to Inbound EDI Transaction File Mappings for more details.
• Accept If No Errors - The Epicor application should automatically process demand for this customer trading
partner only if there are no errors in the inbound EDI document. This eliminates the need to manually use
the Process selection in the Demand Header section of the Demand Entry Actions menu to process the demand.
• In the case of inbound EDI transactions, this automatically creates demand entries in the Epicor application
and immediately generates sales order and forecast entries at the time an error-free inbound EDI
file is successfully processed. This eliminates the need to manually use the Process selection in the Demand
Header section of the Demand Entry Actions menu.
• In cases where the inbound EDI transaction does contain errors (for example, a Date Change action
request is received with insufficient lead time), the Epicor application handles in the normal manner - it
Epicor ERP | 9.05.700 189

Modifiers EDI / Demand Management Technical Reference Guide
applies Stop (with System Rejection) or Warning conditions, depending on the settings for the customer
trading partner in the Customer Maintenance > Customer > Demand or Ship To > Demand sheets. It does
not immediately generate sales order and forecast entries in these situations.Refer to the Customer
Maintenance > Customer > Demand section for more details on error conditions are how they are
handled for a customer trading partner.
• Manually Accept - Demand from this incoming document for this ship to customer trading partner should
only be manually processed. In this case, the system creates demand entries but you must manually process
them using the Process selection of the Demand Header section in the Demand Entry Actions menu. Order
releases and forecast entries are only created at the time you perform this manual processing.
Where Located
The Accept Type field is located on the Customer Maintenance > Documents and Customer Maintenance >
Ship To > Documents sheets.
Menu Path
Action (Add)
If this customer trading partner sends a request to add a new demand schedule, but with insufficient lead time
notification (based on the lead time factor defined in the Add field), specify the action that should take place
when you run the Process Demands selection on the Demand Entry Actions menu.
• Stop - Designates that requests to add new demand schedules that are received from this customer trading
The Epicor application marks the demand record as System Rejected in Demand Entry; however, you can
manually accept the incoming demand by selecting the Override System Reject check box if you wish. This
190 Epicor ERP | 9.05.700

allows you to designate that the demand schedule/line/demand header can be processed to generate an order
or forecast in the Epicor application. Error messages appear on the Demand Log (on the Demand Entry Actions
the demand.
• Warning - Designates that requests to add new demand schedules that are received from this customer
Warning messages display on the Demand Log or on the Demand Review Report informing you that the
request to add new demand schedules has been processed even though it was received from this customer
Where Located
The Action (Add) field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
> Ship To > Demand sheets.
Menu Path
Action (Cancel)
If this customer trading partner sends a demand schedule cancellation request, but with insufficient lead time
notification (based on the lead time factor defined in the Cancel field), specify the action that should take place
• Stop - Designates that demand schedule cancellation requests received from this customer trading partner
Epicor ERP | 9.05.700 191

the demand.
• Warning - Designates that demand schedule cancellation requests received from this customer trading partner
display on the Demand Log or on the Demand Review Report informing you that the demand schedule
cancellation request has been processed even though it was received from this customer trading partner with
Where Located
The Action (Cancel) field is located on the Customer Maintenance > Customer > Demand and Customer
Maintenance > Ship To > Demand sheets.
Menu Path
Action (Change)
If this customer trading partner sends a change request for a demand schedule, but with insufficient lead time
notification (based on the lead time factor defined in the Change field), specify the action that should take place
• Stop - Designates that demand schedule change requests received from this customer trading partner with
insufficient lead time notification should not be accepted and processed.
192 Epicor ERP | 9.05.700

the demand.
• Warning - Designates that demand schedule change requests received from this customer trading partner
display on the Demand Log or on the Demand Review Report informing you that the demand schedule change
request has been processed even though it was received from this customer trading partner with insufficient
lead time notification.
Tip This setting does not apply to demand schedule quantity or date changes- refer to the Date
Change, Quantity Change and associated Action fields for details on how the Epicor application
manages these types of demand schedule changes.
Where Located
The Action (Change) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Epicor ERP | 9.05.700 193

Action (Check for Part)
If the Check For Part check box has been selected, specify the action that should take place (when you run the
Process Demands selection on the Demand Entry Actions menu) if a part record does not exist in your database
for inbound demand received from this customer trading partner:
• Stop - Designates that inbound demand received from this customer trading partner should not be accepted
and processed if it contains a part number for which a corresponding part record does not exist within your
Epicor application database.
the demand.
automatically accepted and processed even if it contains a part number for which a corresponding part record
does not exist within your Epicor application database. Warning messages display on the Demand Log or on
the Demand Review Report informing you that the incoming demand contains a part number for which a
corresponding part record does not exist within your Epicor application database.
Where Located
The Action (Check for Part) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
194 Epicor ERP | 9.05.700

Action (Check Partial Shipments)
If the Check Partial Shipments check box has been selected, specify the action that should take place (when
you run the Process Demands selection on the Demand Entry Actions menu) when demand schedule entries are
matched against sales order releases with partial shipments for this customer trading partner.
and processed if demand schedule entries have been matched against sales order releases with partial
shipments.
the demand.
automatically accepted and processed even if demand schedule entries have been matched against sales order
releases with partial shipments. Warning messages display on the Demand Log or on the Demand Review
Report informing you that the incoming demand has been matched against sales order releases with partial
shipments.
Where Located
The Action (Check Partial Shipment) field is located on the Customer Maintenance > Customer > Demand and
Customer Maintenance > Ship To > Demand sheets.
Menu Path
Epicor ERP | 9.05.700 195

Action (Check for Revision Level)
If the Check For Revision check box has been selected, specify the action that should take place (when you run
the Process Demands selection on the Demand Entry Actions menu) if the corresponding part revision does not
exist in your database for inbound demand received from this customer trading partner:
and processed if the corresponding part revision does not exist in your Epicor application database.
the demand.
automatically accepted and processed even if the corresponding part revision does not exist in your Epicor
application database. Warning messages display on the Demand Log or on the Demand Review Report
informing you that the incoming demand contains a part revision that does not exist in your database.
Where Located
The Action (Check for Revision Level) field is located on the Customer Maintenance > Customer > Demand and
Menu Path
196 Epicor ERP | 9.05.700

Action (Cumulative Check Discrepancies)
If the Cumulative Check Discrepancies check box has been selected, specify the action that should take place
if there are differences in cumulative quantities between your Epicor application database and the cumulative
quantities in the inbound demand EDI transactions received from this customer trading partner.
and processed if differences in cumulative quantities exist between your Epicor application database and
inbound demand received from this customer trading partner.
the demand.
automatically accepted and processed even if differences in cumulative quantities exist between your Epicor
application database and inbound demand received from this customer trading partner. Warning messages
display on the Demand Log or on the Demand Review Report informing you that the incoming demand has
been matched against sales order releases with partial shipments.
Where Located
The Action (Cumulative Check Discrepancies) field is located on the Customer Maintenance > Customer >
Demand sheet.
Menu Path
Epicor ERP | 9.05.700 197

Action (Date Change)
If this customer trading partner sends a Ship By or Need By date change request for a demand schedule, but with
insufficient lead time notification (based on the lead time factor defined in the Date Change field), specify the
action that should take place when you run the Process Demands selection on the Demand Entry Actions menu.
• Stop - Designates that demand schedule date change requests received from this customer trading partner
the demand.
• Warning - Designates that demand schedule date change requests received from this customer trading
schedule date change request has been processed even though it was received from this customer trading
Where Located
The Action (Date Change) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
198 Epicor ERP | 9.05.700

Action (New Line)
If this customer trading partner sends a request to add a new line to an existing demand schedule, but with
insufficient lead time notification (based on the lead time factor defined in the New Line field), specify the action
• Stop - Designates that requests to add new lines to demand schedules received from this customer trading
the demand.
messages display on the Demand Log or on the Demand Review Report informing you that a request that
add new demand schedule lines has been processed even though it was received from this customer trading
Where Located
The Action (New Line) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Epicor ERP | 9.05.700 199

Action (Quantity Change)
If this customer trading partner sends a quantity change request for a demand schedule, but with insufficient
lead time notification (based on the lead time factor defined in the Quantity Change field), specify the action
• Stop - Designates that demand schedule quantity change requests received from this customer trading partner
the demand.
schedule quantity change request has been processed even though it was received from this customer trading
Where Located
The Action (Quantity Change) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
200 Epicor ERP | 9.05.700

Add
Specifies the minimum number of days ahead of (ahead of the planned Ship By or Need By date) by which the
Epicor application should accept requests to add a new demand schedule from this customer trading partner.
You use this in conjunction with the associated Action field to specify how the Epicor application should process
demand schedule quantity change requests from your customer trading partner when received with insufficient
Where Located
The Add field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance >
Ship To > Demand sheets.
Menu Path
Example
The Add field is set to five days for Company ABC. They send you a request to add a new demand schedule that
they would like shipped only four days from now. Because the demand schedule change request was received
with insufficient lead time notification, a Stop or Warning takes place, depending on the setting of the Action
(Add) field.
Epicor ERP | 9.05.700 201

Allow Non Perfect Match
Specifies if perfect or non-perfect matching is being performed by the Demand Schedule Matching process
(located on the Demand Schedule section of the Demand Entry Actions menu). This program matches requests
for demand schedule updates to existing demand schedule releases that have already been generated through
this demand contract. These are schedule update requests received on subsequent inbound EDI transactions sent
by your customer trading partner.
• Select the check box if non-perfect matching is being performed. A non-perfect match is defined as one in
which at least one of the criteria (for example, shipping quantities or shipping dates) you select from the
Options Available field (and appear in the Options Selected field) match between requests for demand
schedule updates and existing demand schedule releases.
For example, if you have specified matching of schedule dates, order numbers and reference numbers, a non
perfect match is one in which only one of the criteria (for example, schedule dates) match between the
documents.
• Clear the check box if perfect matching is being performed. A perfect match is defined as one in which all
criteria you specify in the Options Selected field must match between the demand schedule updates and
existing demand schedule releases.
For example, if you have specified matching of schedule dates, order numbers and reference numbers, it is
considered a perfect match only if all of these parameters match exactly between documents. This is the
default value for this check box.
Where Located
The Allow Non Perfect Match check box is located on the Demand Contract > Header > Matching sheet.
Menu Path
• Sales Management > Demand Management > General Operations > Demand Contract Entry
• Customer Relationship Management > Demand Management > General Operations > Demand Contract
Entry
Allow Shipments for Orders on Hold
Specifies if the Epicor application should allow processing of shipments for sales orders that have been placed
on hold, either manually or when generated from demand contracts. This affects shipment programs such as
Customer Shipment Entry and Master Pack Shipment Entry throughout the Epicor application.
• Select the check box to allow processing of shipments for sales orders that have been placed on hold.
• Clear this check box to prevent processing of shipments for sales orders that have been placed on hold.
202 Epicor ERP | 9.05.700

Where Located
The Allow Shipments for Orders on Hold check box is located on the Company Maintenance > Modules >
Materials > Shipping/Receiving sheet.
Menu Path
®
Alt Trading Partner
Specifies the trading partner identifier (ID) used with this document. Enter an alternate trading partner identification
number into this field if the trading partner associated with the document is different than the identifier entered
into the Trading Partner field on the Customer > Demand sheet. This indicates that another trading partner can
receive data from this document.
Tip To enable automatic processing for a document using the Automatic check box, a value must be
entered into the Alt Trading Partner field! If an alternate trading partner is not associated with your customer
trading partner, simply enter the trading partner identifier for your customer in this field.
Where Located
The Alt Trading Partner field is located on the Customer Maintenance > Documents and Customer Maintenance
> Ship To > Documents sheets.
Menu Path
Epicor ERP | 9.05.700 203


Automatically Match All
Designates if the Demand Matching selection on the Demand Entry > Actions menu should automatically match
all new demand schedules and eligible sales order releases candidates in this company.
• Select the check box if the Demand Matching selection should automatically match all new demand schedules
and candidates. In this case, the Epicor application runs it in the background as a continuing process and
automatically matches new demand schedules. This eliminates the need for a user to open the Demand
Matching program and having to click the Match All button.
• Clear the check box to skip automatic matching of all new demand schedules and candidates in this company.
In this case, the user must invoke the Demand Matching selection and perform matching, either by manually
selecting sales order releases and then clicking the Match button or automatically matching all eligible sales
order releases against demand schedules by clicking the Match All button.
Where Located
The Automatically Match All check box is located on the Company Maintenance > Modules > Sales > Demand
sheet.
Menu Path
®
Cancel
Specifies the minimum number of days (ahead of the planned Ship By or Need By date) by which the Epicor
application should accept cancellation requests for a demand schedule from this customer trading partner. You
use this in conjunction with the associated Action field to specify how the Epicor application should process
cancellation requests from your customer trading partner when received with insufficient lead time notification.
Where Located
The Cancel field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
204 Epicor ERP | 9.05.700

Example
The Cancel field is set to five days for Company ABC. They send you a cancellation request for a demand schedule
that is being shipping four days from now. Because the demand schedule cancellation request was received with
insufficient lead time notification, a Stop or Warning takes place, depending on the setting of the Action (Cancel)
field.
Cancel Non Matched
Specifies if the Epicor application should automatically cancel all sales releases for this customer trading partner
that have not been matched by the Demand Schedule Matching process (located on the Demand Schedule section
of the Demand Entry Actions menu). This sets the default for the Cancel Non Matched field in the Demand
Contract Entry > Header > Matching sheet for this customer trading partner; this can be overridden for specific
demand contracts.
• Select the check box if the Epicor application should automatically cancel all sales releases for this customer
• Clear the check box if the Epicor application should not automatically cancel all sales releases for this customer
Refer to the Header > Matching Sheet section in Entering Demand Contracts for more information on how
the Demand Schedule Matching process matches update requests on inbound EDI transactions to existing demand
schedules and order releases.
Epicor ERP | 9.05.700 205

Where Located
The Close Non Matched check box is located on the Customer Maintenance > Customer > Demand sheet.
Menu Path
Cancel Schedules Action
Specifies if the Epicor application should automatically close or delete all cancelled demand schedules received
from customer trading partners in this company. Select the action that should be taken for cancelled demand
schedules in this company.
• Close - The Epicor application should automatically close all cancelled demand schedules received from
• Delete - The Epicor application should automatically delete all cancelled demand schedules received from
Where Located
The Cancel Schedules Action field is located on the Company Maintenance > Modules > Sales > Demand sheet.
Menu Path
206 Epicor ERP | 9.05.700


®
Change
Epicor application should accept change requests for a demand schedule from this customer trading partner.
demand schedule quantity change requests from your customer trading partner when received with insufficient
Where Located
The Change field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
Example
The Change field is set to five days for Company ABC. They send you a change request for a demand schedule
that is being shipping four days from now. Because the demand schedule change request was received with
insufficient lead time notification, a Stop or Warning takes place, depending on the setting of the Action (Change)
field.
Epicor ERP | 9.05.700 207

Check Forecast Schedules
Designates if forecast schedules should be included in demand management lead time checking logic for this
company.
• Select this check box to include forecast schedules in demand management lead time checking logic for this
company.
• Clear the check box to exclude forecast schedules.
Where Located
The Check Forecast Schedules check box is located on the Company Maintenance > Modules > Sales > Demand
sheet.
Menu Path
®
Check for Part
Specifies if the Epicor application should validate if corresponding part records exist in your Epicor application
database for inbound demand received from this customer trading partner. Using the Check For Part check box,
you can choose to perform this part number validation for this customer trading partner, or skip the validation.
• Select the check box if the Epicor application should perform this validation. If you select this check box, use
the associated Action field to specify how the Epicor application should process demand schedules when
part number validations fail. By performing this validation, it helps to ensure that the Epicor application is not
accepted invalid part numbers on inbound EDI transactions received from this customer trading partner.
• If you clear the check box, all parts listed on an incoming shipping schedule are automatically included on the
shipping schedule. This lets you generate demand suggestions for parts that are "on the fly." However, by
skipping this validation, you cannot ensure that invalid part numbers on inbound EDI transactions are not
being accepted from this customer trading partner.
Where Located
The Check for Part check box is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
208 Epicor ERP | 9.05.700


Check Partial Shipments
Designates if the Epicor application should match demand entries generated from incoming EDI transaction files
against sales order releases with partial shipments for this customer trading partner.
validation, you use the corresponding Action field to designate how the Epicor application should operate if
the partial shipment validation fails.
• Clear the check box to skip this validation. If you clear the check box, all demand schedule entries matched
against sales order releases (with partial shipments) for this customer trading partner are automatically included
on the shipping schedule.
Where Located
The Check Partial Shipments field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Epicor ERP | 9.05.700 209


Check for Revision Level
Designates if the Epicor application should validate if a corresponding part revision level exists in your database
for inbound demand received from this customer trading partner.
Example You receive an inbound EDI file from this trading partner that contains a part number with a
revision level that not exist within your Epicor application database. Using the Check For Revision Level
check box, you can choose to perform this revision level validation for this customer trading partner, or
skip the validation.
• Select the check box if the Epicor application should perform this validation, or clear the check box to skip
this validation when inbound demand is processed for this customer trading partner. If you choose to perform
the validation, you use the corresponding Action field to designate how the Epicor application should operate
if the revision level validation fails.
• If you clear the check box, all parts listed on an incoming shipping schedule are automatically included on the
shipping schedule, regardless of the stated revision level.
Where Located
The Check for Revision Level check box is located on the Customer Maintenance > Customer > Demand and
Menu Path
210 Epicor ERP | 9.05.700

Close Rejected Schedules
Specifies if rejected demand schedules for this customer trading partner should automatically be closed when
you run the Process Demands selection (on the Actions menu in Demand Entry or Demand Mass Review).
• Select the check box to automatically close demand schedules that have been rejected for this customer
trading partner.
• Clear the check box to skip automatic closure of rejected demand schedules for this customer trading partner.
Where Located
The Close Rejected Schedules check box is located on the Customer Maintenance > Customer > Demand and
Menu Path
Epicor ERP | 9.05.700 211

Logic/Algorithms
Care should be taken when you set this control. If you select the check box, the Epicor application automatically
closes rejected demand schedules received from this customer trading partner.
By clearing the check box, you can first review the reasons for rejection of a demand schedule, enter manual
adjustments as needed in Demand Entry, or simply close the demand schedule. For example, if a demand schedule
has been rejected because it contains a shipping date just outside of an allowable lead time, the shipping date
could be adjusted in Demand Entry, allowing the previously rejected demand schedule to be processed into a
sales order or forecast.
Check Unfirm Schedules
Designates if unfirmed schedules should be included in demand management lead time checking logic for this
company.
• Select this check box to include unfirmed schedules in demand management lead time checking logic for this
company.
• Clear the check box to exclude unfirmed schedules.
Where Located
The Check Unfirm Schedules check box is located on the Company Maintenance > Modules > Sales > Demand
sheet.
Menu Path
®
Consider Working Days in the Delivery Days Calculation
The Delivery Days fields in the Customer Maintenance > Customer > Demand and Ship To > Demand sheets
can be used to specify the number of days required to ship a part quantity from your manufacturing center to
the final destination for a customer trading partner (or ship to customer trading partner). The Epicor application
uses this date interval as a buffer to calculate Ship By Dates when you use the Need By date type (as specified
in the Date Type field).
The manner in which the Epicor application uses the specified delivery days factor for the delivery date calculation
is dependent on the setting of the Consider Working Days in the Delivery Days Calculation check box.
• If the Consider Working Days in the Delivery Days Calculation check box is selected, this factor represents
actual working days.
212 Epicor ERP | 9.05.700

To calculate a Ship By date, the Epicor application subtracts this actual working days factor from the Need By
date designated in a demand schedule received from the customer trading partner, taking into consideration
any dates that are designated as non-working days in the associated plant calendar.
• If the Consider Working Days in the Delivery Days Calculation check box is cleared, this factor represents
delivery days.
To calculate a Ship By date, the Epicor application subtracts this delivery days factor from the Need By date
designated in a demand schedule received from the ship to customer trading partner, and then determines
if the calculated Ship By date is a working day.
Note Refer to Defining Trading Partners in Customer Maintenance for examples of how Ship By
dates are calculated for demand schedules using actual working days and delivery days factors.
Where Located
The Consider Working Days in the delivery Dates Calculation check box is located on the Company
Maintenance > Modules > Sales > Demand sheet.
Menu Path
®
Cumulative Check Discrepancies
Designates if the Epicor application should check for differences in cumulative quantities between your Epicor
application database and the cumulative quantities in the inbound demand EDI transactions received from this
validation, you use the corresponding Action field to designate how the Epicor application should operate if
the cumulative quantity validation fails.
• Clear the check box to skip this validation.
Where Located
The Cumulative Check Discrepancies field is located on the Customer Maintenance > Customer > Demand
sheet.
Menu Path
Epicor ERP | 9.05.700 213

Daily, Rules
Daily periodicity designates that shipments are made to this customer every weekday (Monday through Friday).
• Select this check box to use Daily periodicity rules when calculating shipping schedule dates for this customer.
• If you select this check box, you can also use the Include Saturday and Sunday Shipments check box to indicate
that deliveries are also required to this customer on Saturdays and Sundays.
Where Located
The Daily Rules check box is located on Customer Periodicity Maintenance.
Menu Path
214 Epicor ERP | 9.05.700

Daily, Include Saturdays and Sunday Shipments
If you selected the Daily Rules check box, select this check box to include Saturdays and Sundays in the delivery
schedule for this customer, or clear it to exclude Saturdays and Sundays deliveries for this customer.
Where Located
The Daily, Include Saturdays and Sunday Shipments check box is located on Customer Periodicity Maintenance.
Menu Path
Date Change
Epicor application should accept Ship By or Need By date change requests for a demand schedule from this
Where Located
The Date Change field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Epicor ERP | 9.05.700 215


Example
The Date Change field is set to five days for Company ABC. They send you a Ship By date change request for
a demand schedule that is being shipping four days from now. Because the demand schedule date change request
was received with insufficient lead time notification, a Stop or Warning takes place, depending on the setting of
the Action (Date Change) field.
Date Type
Specifies the default calculation method being used by the Epicor application to generate Need By and Ship By
dates on each order release schedule for this customer trading partner.
• Shipping - Creates Ship By Dates; these are the dates by which parts must be shipped in order to arrive on
the required (Need By) dates specified on shipping schedules generated from demand entries that have been
manually entered into Demand Entry.
• Need By - Creates Need By Dates; these are the dates on which the customer trading partner requires the
part quantities.
• Selecting this option causes the Epicor application to subtract the delivery days factor specified in the Delivery
Days field from each Need By date to calculate the Ship By date on each release. If this customer trading
partner also uses periodicity rules, the Ship By is further adjusted to match the shipping frequency set up
within the periodicity rule selected in the Periodicity field.
Where Located
The Date Type field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
216 Epicor ERP | 9.05.700


Delivery Days
Specifies the number of days required to ship a part quantity from your manufacturing center to this customer's
location. The Epicor applications uses the date interval as a buffer to calculate Ship By Dates when you use the
Need By date type (as specified in the Date Type field).
The manner in which it uses the specified delivery days factor for the delivery date calculation is dependent on
the setting of the Consider Working Days in the Delivery Dates Calculation check box for the associated
company in the Company Maintenance > Modules > Sales > Demand sheet.
• If the Consider Working Days in the Delivery Dates Calculation check box has been selected, this factor
represents actual working days. To calculate a Ship By date, the Epicor application subtracts this factor from
the Need By date designated in a demand schedule received from the ship to customer trading partner, taking
into consideration any dates that are designated as non-working days in the associated plant calendar.
• The Delivery Days field is set to 5 for this ship to customer trading partner.
• When a demand schedule is received from this ship to customer trading partner with a Need By
date of 11/17/11 (a Thursday), the Epicor application subtracts five actual working days to
calculate a Ship By date of 11/10/11 (a Thursday) when generating shipping schedules (demand
entries) for this ship to customer trading partner.
• It calculates this Ship By date because Saturday 11/12 and Sunday 11/13 are both designated as
non-working days in the plant calendar.
• If the Consider Working Days in the Delivery Dates Calculation check box has been cleared, this factor
represents delivery days. To calculate a Ship By date, the Epicor application subtracts this factor from the
Need By date designated in a demand schedule received from the ship to customer trading partner, and then
determines if the calculated Ship By date is a working day.
• The Delivery Days field is set to 5 for this ship to customer trading partner.
• When a demand schedule is received from this ship to customer trading partner with a Need By
date of 11/17/11 (a Thursday), the Epicor application subtracts five delivery days to calculate a
Ship By date of 11/12/11 (a Saturday). However, since Saturday is a non-working day in the plant
calendar, it sets the final Ship By Date to 11/11/2011 (a Friday).
Tip If this ship to customer trading partner also uses periodicity rules, and you specify a periodicity interval
in the Periodicity field, the Ship By date is further adjusted to match the shipping frequency set up within
the periodicity rule selected in the Periodicity field. For example, if an Nth Day of the Month periodicity
rule has been specified in the Periodicity field, and the periodicity rule (as defined in Customer Periodicity
Epicor ERP | 9.05.700 217

Maintenance) has the 25th as the day of the month, a Ship By date of July 25 would be calculated when
generating shipping schedules.
Where Located
The Delivery Days field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Logic/Algorithms
Ship By Date = Need By Date - Delivery Days (or Actual Working Days), adjusted by any applicable Periodicity
rules specified for the customer trading partner.
Example
If the Date Type field is set to Need By, this trading partner needs parts on an order release delivered to them
by August 1 and you have specified 5 in the Delivery Date field, the Epicor application subtracts five days from
the August 1 Need By date to calculate a Ship By date of July 27 when generating shipping schedules (demand
entries) from inbound EDI transactions received from this customer trading partner.
Tip If this customer trading partner also uses periodicity rules, and you specify a periodicity interval in the
Periodicity field, the Ship By date is further adjusted to match the shipping frequency set up within the
periodicity rule selected in the Periodicity field. For example, if an Nth Day of the Month periodicity rule
has been specified in the Periodicity field, and the periodicity rule (as defined in Customer Periodicity
Maintenance) has the 25th as the day of the month, a Ship By date of July 25 would be calculated when
generating shipping schedules.
218 Epicor ERP | 9.05.700

Direction
Specifies whether this is an inbound document you receive from this customer trading partner, or is an outbound
document you send to this customer trading partner:
• Inbound - This is an inbound document you receive from this customer trading partner.
• Outbound - This is an outbound document you send to this customer trading partner.
Where Located
The Direction field is located on the Customer Maintenance > Documents and Customer Maintenance > Ship
To > Documents sheets.
Menu Path
Exclude From / From (days)
If the Cancel Non Matched check box has been selected, use the Exclude From check box and From (days)
field as needed to specify a beginning date for a grace period for cancellation non-matched sales releases. The
Epicor application will skip cancellation of non matched sales order releases within this date range.
• If you select the Exclude From check box, and then enter 2 into the From (days) field, it designates that
non matched sales order releases with ship dates between the current system date and two days earlier than
the current date will not be cancelled by the Epicor application in the event of a non match (that is, when the
associated demand schedule update request does not match any existing demand schedule releases that have
already been generated through this demand contract).
Epicor ERP | 9.05.700 219

For example, if the current system date is 1/25, the Epicor application will not cancel sales order releases dated
between 1/23 and 1/25 in the event of a non-match.
releases.
Exclude Until / Until (days)
If the Cancel Non Matched check box has been selected, use the Exclude Until check box and Until (days)
field as needed to specify an ending date for a grace period for cancellation non-matched sales releases. The
Epicor application will skip cancellation of non matched sales order releases within this date range.
• If you select the Exclude Until check box, and then enter 2 into the Until (days) field, it designates that non
matched sales order releases with ship dates between the current system date and two days earlier than the
current date will not be cancelled by the Epicor application in the event of a non match (that is, when the
associated demand schedule update request does not match any existing demand schedule releases that have
already been generated through this demand contract).
For example, if the current system date is 1/25, the Epicor application will not cancel sales order releases dated
between 1/25 and 1/27 in the event of a non-match.
releases.
Hold Orders for Review
Specifies if the Epicor application should place sales orders created for this customer trading partner from demand
contracts in Demand Entry on hold for review before being released for shipping.
• Select the check box to place sales orders created in Demand Entry for this customer trading partner on hold
for review.
• Clear the check box to skip placing of sales orders on hold for this customer trading partner before they are
released for shipment.
Where Located
The Hold Orders for Review check box is located on the Customer Maintenance > Customer > Demand sheet.
Menu Path
220 Epicor ERP | 9.05.700


Logic/Algorithms
The setting in this check box becomes the default value for the Hold Orders for Review check box in the
Demand Contact Entry Header and Summary sheets and can be overridden for individual demand contracts.
• The Epicor application places demand entries created against the demand contract on hold based on the
setting in the demand contract itself, not based on the Hold Orders for Review setting specified for the
customer trading partner in the Customer Maintenance > Customer > Demand sheet.
• An order placed on hold must usually be released before it can be shipped to the customer trading partner
using Customer Shipment Entry or Master Pack Shipment Entry.
Import Folder (Company Maintenance)
Specifies the default location of the direct EDI import folder used by the Import EDI Demand Process. This is
the path to the import folder where EDI process expects to find .app documents.
Note The specified folder path must use UNC-naming conventions, not a locally-mapped drive letter.
Where Located
The Import Folder field is located on the Company Maintenance > Modules > Sales > Demand sheet.
Menu Path
®
Epicor ERP | 9.05.700 221

Import Folder
Specify the path to the import folder where EDI process expects to find .app documents. The default value is
defined in Import Folder field in the Company Configuration > Modules > Sales > Demand sheet.
Where Located
The Import Folder field is located in the Import EDI Demand Process.
Menu Path
• Sales Management > Demand Management > General Operations > Import EDI Process
• Customer Relationship Management > Demand Management > General Operations > Import EDI Process
Map ID
Specifies the program identifier for the document. This value is used during custom program development; it
identifies the document for use with a custom program.
Where Located
The Map ID field is located on the Customer Maintenance > Documents and Customer Maintenance > Ship To
> Documents sheets.
Menu Path
222 Epicor ERP | 9.05.700

Where Located
The Map ID field is located on the Customer Maintenance > Documents and Customer Maintenance > Ship To
> Documents sheets.
Menu Path
Monthly Forward, Rules
Monthly Forward periodicity designates that all shipments to this customer are only sent once per month.
• Select this check box to use Monthly Forward periodicity rules when calculating shipping schedule dates for
this customer.
• If you select this check box, you can then use the First Ship Day field to specify the day of the week on which
shipments to this customer must arrive.
• To further define this shipment interval, you can use the Week Number in the Month field to indicate the
week during the month (1-5) on which shipments to this customer need to be sent.
Epicor ERP | 9.05.700 223

Where Located
The Monthly Forward, Rules check box is located on Customer Periodicity Maintenance.
Menu Path
Monthly Forward, First Day Ship
If you selected the Monthly Forward Rules check box, select the day of the week this shipment must arrive to
this customer.
Where Located
The Monthly Forward, First Day Ship field is located on Customer Periodicity Maintenance.
Menu Path
Monthly Forward, Week Number in the Month
If you selected the Monthly Forward Rules check box, select the week during the month (1-5) in which shipments
are sent to the customer.
Where Located
The Monthly Forward, Week Number in the Month field is located on Customer Periodicity Maintenance.
Menu Path
224 Epicor ERP | 9.05.700

New Line
Specifies the minimum number of days (ahead of the planned Ship By or Need By date) by which the Epicor
application should accept a request to add a new order line to a demand order from this customer trading partner.
requests to add a new line to a demand schedule when received from your customer trading partner with
Where Located
The New Line field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
Epicor ERP | 9.05.700 225

Example
The New Line field is set to five days for Company ABC. They send you a request to add a new line to a demand
schedule that is being shipping four days from now. Because the request was received with insufficient lead time
notification, a Stop or Warning takes place, depending on the setting of the Action (New Line) field.
Nth Day of the Week, Rules
Nth Day of the Week periodicity designates that shipments to this customer can only arrive on a specific work
day.
• Select this check box to use Nth Day of the Week periodicity rules when calculating shipping schedule dates
for this customer.
• If you select this check box, you can use the Day of the Week Shipment field to specify the day of the week
on which shipments must arrive to this customer.
Where Located
The Nth Day of the Week, Rules check box is located on Customer Periodicity Maintenance.
Menu Path
Nth Day of the Week, Day of the Week Shipment
If you selected the Nth Day of the Week check box, select the specific day of the week (Monday-Sunday) on
which shipments must arrive to this customer.
Where Located
The Nth Day of the Week, Day of the Week Shipment field is located on Customer Periodicity Maintenance.
Menu Path
226 Epicor ERP | 9.05.700

Options Available
Displays the options available for selection for use by the Epicor application when it processes part number
numbers and product codes this incoming EDI document when received from this customer trading partner.
Refer to Options Selected for directions on how you select options and construct a hierarchical part number
processing list.
• Check For Part - When selected, it denotes that the Epicor application should validate that corresponding
part records exist for the part numbers listed on this inbound demand document when received from this
customer trading partner. If a part record does not exist, a warning will automatically appear within the
Demand Log for your review.
By performing this validation, it helps to ensure that the Epicor application is not accepted invalid part numbers
on inbound EDI transactions received from this customer trading partner. However, by skipping this validation,
you cannot ensure that invalid part numbers on inbound EDI transactions are not being accepted from this
• Use Customer Part - When selected, this causes the Epicor application to search for and use customer part
numbers in order to retrieve the corresponding internal part numbers. You create this customer part number
cross reference using Customer Part Maintenance in the Epicor application.
• Manufacturer Part - When selected, this causes the Epicor application to search for and use manfacturer's
part numbers in order to retrieve the corresponding internal part numbers. You create this manufacturer part
number cross reference using Manufacturer Part Maintenance in the Epicor application.
• Use Part UPC - When selected, this causes the Epicor application to search for and use Universal Product
Codes (UPC) in order to retrieve the corresponding internal part. You create this cross reference between UPC
codes and internal part numbers in the Part Maintenance > Part - UOMs sheet.
Product codes are unique registered numbers that identify a specific part and UOM. An example of a product
code is the UPC-12 (Universal Product Code) bar code found on most consumer items purchased in the USA
and Canada. Other product codes (for example, GTIN-14, EAN-13) that can be entered in the UOMs sheet
are used in various circumstances in different regions but are all similar to the UPC bar code.
All part entry fields in the Epicor application allow entry or scanning of codes in lieu of entering an actual part
number. If one of the codes is entered or scanned in a part field, the Epicor application replaces it with the
part number and the correct UOM. The appropriate product code can also be printed on transaction documents,
such as a receiving transaction.
• UPC-12 - This option operates in the same manner as Use Part UPC, but instead processes only UPC product
codes of up to 12 digits in length.
• GTIN-14 - This option operates in the same manner as Use Part UPC, but instead processes GTIN-14 (Global
Trade Item Number) product codes of up to 14 digits in length. It is the newest of the product codes and is
used for both standard bar codes and as part of the data encoded on RFID tags.
• EAN-13 - This option operates in the same manner as Use Part UPC, but instead processes EAN-13 (European
Article Number) product codes, 13 digits in length. It is referred to as a Japanese Article Number (JAN) in
Japan. These codes are used worldwide for marking retail goods.
• EAN-14 - This option operates in the same manner as EAN-13, but instead processes EAN product codes 14
digits in length.
• EAN-8 - This option operates in the same manner as EAN-13, but instead processes EAN product codes eight
digits in length.
Epicor ERP | 9.05.700 227

Where Located
The Options Available field is located on the Customer Maintenance > Documents and Customer Maintenance
Menu Path
Options Selected
Specifies the hierarchical order in which the Epicor application should process part numbers and product codes
contained on EDI transactions received from this customer trading partner. You construct the hierarchical processing
list by selecting part options displayed in the Options Available field, and then clicking the appropriate directional
buttons.
• For example, if you would want the Epicor application to first perform a Check For Part validation process,
you select Check For Part in the Options Available field, then click the single right arrow button.
• If you want it to next perform a Use Customer Part validation process, you then select Use Customer Part
in the Options Available field, then click the single right arrow button.
field, then click the up arrow button. For example, if Use Part UPC is the fifth option listed, but you wish to
make it the second option, select it, then click the up arrow button.
228 Epicor ERP | 9.05.700

• To remove a single option from the Options Selected field, select the option being removed, then click the
single left arrow button. For example, if you selected GTIN-14 but wish to remove it, select it, then click the
single left arrow button.
• To remove all selected options from the Options Selected field, click the double left arrow button.
Where Located
The Options Selected check box is located on the Customer Maintenance > Documents and Customer
Maintenance > Ship To > Documents sheets.
Menu Path
Outbound Document
If this is an outbound document, specify what processing should occur in the Epicor application when the
document is sent to this customer trading partner:
• Required- This selection is reserved for future use.
• Document- This selection is reserved for future use.
• Manual- This selection is reserved for future use.
• Automatic- When selected, this check box indicates that the Epicor application should automatically generate
a supporting document record when the associated transaction is confirmed. If you select automatic generation,
you do not have to manually generate the supporting document record when you process a transaction.
This document record is generated internally and supports subsequent printing of the associated document.
It contains schema information (top portion of the record) and the actual information printed on the document
(lower portion of the record).
Epicor ERP | 9.05.700 229

Tip To enable automatic processing for a document using the Automatic check box, a value must be
entered into the Alt Trading Partner field!
Where Located
The Outbound Document field is located on the Customer Maintenance > Documents and Customer Maintenance
Menu Path
®
Periodicity
Specifies the periodicity interval for this customer trading partner. This designates how often this customer trading
partner wishes to receive shipments from you.
• Periodicity rules define the intervals for the deliveries (daily, weekly, specific day of the week, or monthly)
being used to calculate shipping schedules for this customer trading partner from inbound EDI transactions.
• Select the specific periodicity rule that applies to this customer, or select Not Used if periodicity rules are not
being used to calculate Ship By dates for this customer trading partner. All periodicity intervals (or rules) that
have been previously defined in Customer Periodicity Maintenance for the current customer trading partner
appear on this list.
• If you select Not Used, the Epicor application calculates Ship By dates for shipping schedules for the customer
trading partner based on the Need By dates specified in incoming EDI transactions, and the time factor specified
in the Delivery Days field.
Where Located
The Periodicity field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
230 Epicor ERP | 9.05.700


Pricing
Specifies if internal or customer pricing should be used for demand entries generated from inbound EDI transactions
received from this customer trading partner. This becomes the default for this customer trading partner in the
Pricing field field in the Demand Contract Entry > Line > Detail sheet and can be overridden for specific demand
contract lines.lines.
• Customer Pricing - The customer price that appears on the inbound EDI document should be used to populate
the EDIUnitPrice field in the Demand_Detail file. In this scenario, the Epicor application uses the customer
price on demand entries (and sales order lines generated from the demand entries) generated from demand
contract lines for this customer trading partner.
• Internal Pricing - The internal price calculated within the Epicor application should be used to populate the
EDIUnitPrice field in the Demand_Detail file. In this scenario, the Epicor application uses the internal price on
demand entries (and sales order lines generated from the demand entries) generated from demand contract
lines for this customer trading partner.
Where Located
The Pricing field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
Epicor ERP | 9.05.700 231

Quantity Change
Epicor application should accept quantity change requests for a demand schedule from this customer trading
partner. You use this in conjunction with the associated Action field to specify how the Epicor application should
process demand schedule quantity change requests from your customer trading partner when received with
Where Located
The Quantity Change field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Example
The Quantity Change field is set to five days for Company ABC. They send you a quantity change request for
a demand schedule that is being shipping four days from now. Because the demand schedule quantity change
request was received with insufficient lead time notification, a Stop or Warning takes place, depending on the
setting of the Action (Quantity Change) field.
232 Epicor ERP | 9.05.700

Split Demand
Specifies if a demand schedule should be split when Capable To Promise (CTP) functions indicate that there is
not enough stock on hand for a part to satisfy demand. Select the check box if a demand schedule should be
split under these conditions. Clear the check box if a demand schedule should be not be split under these
conditions.
Where Located
The Split Demand check box is located on the Customer Maintenance > Customer > Demand sheet.
Menu Path
Epicor ERP | 9.05.700 233

Test Record
This check box is only used for custom programming. When selected, the data for this document will not interact
with your customer trading partner's data. This feature lets you test the document to ensure it works with your
custom program. Normally, you should leave this check box cleared.
Where Located
The Test Record check box is located on the Customer Maintenance > Documents and Customer Maintenance
Menu Path
Tolerance
If the Unit Price Difference check box has been selected, specify the allowable price difference tolerance
percentage, if any. For example, enter 10.50 into this field for a 10.5% tolerance.
Example You receive an inbound EDI file from this trading partner, requesting you ship 100 units of a
widget at a unit price of $1.90. However, your current unit price in the Epicor application is set at $2.00.
If you set the Tolerance field to 10.00, the Epicor application would accept a unit price plus or minus 10%
of the internal price. In this example, it would consider $1.90 or $2.10 as acceptable prices, because would
be within 10% of the $2.00 internal price. Conversely, it would not consider $1.75 or $2.25 as acceptable
prices, becuase they are both outside of the 10% tolerance range (from $1.80 to $2.20).
234 Epicor ERP | 9.05.700

Where Located
The Tolerance field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
Trading Partner
Specifies the unique trading partner identifier for this customer. It is a universal code required on EDI transactions
that uniquely identifies the business entity.
The trading partner identifier must be entered in this field exactly as it will appear in inbound EDI files received
from this customer trading partner. This identifier is used to validate EDI documents sent and received between
your company and this customer trading partner.
Where Located
The Trading Partner field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Epicor ERP | 9.05.700 235

Type
Specifies the type of demand suggestion that will be generated based for this document. Select the type that
applies to this document:
• Forecast - This inbound document allows you to receive projected quantities of parts from this customer
trading partner. You then review and accept/reject these forecasts using Demand Entry; when accepted, the
Epicor application creates forecast records in Forecast Entry. A forecast is a projected quantity of parts needed
to satisfy demand. They are first calculated by part, then by customer, and are used by the MRP module to
anticipate the demand from your customers.
• Unfirm Releases - This inbound document allows you to receive potential, or unfirm order releases from
this customer trading partner. You then review and accept/reject these unfirm releases using Demand Entry.
• Incoming Shipping Schedule - This inbound document allows you to receive firm order releases from this
customer trading partner. You will then review and accept/reject these firm releases using Demand Entry.
• A firm order release is an order release that is definitely being shipped to your customer trading partner.
When a release is firm, its quantity can then be turned into a job that can used to manufacture the parts, pull
the parts from stock, or both.
• Advanced Shipping Notice - This outbound EDI 856/DESADV document is the Advanced Shipping Notice
(ASN) that you send to this customer trading partner via EDI. It is used to track the progress of your shipments,
and lets your customer trading partner know when order releases have been shipped from your company.
• You can also use it to reconcile differences between your shipped quantities and the actual quantities (received
by your customer trading partner) using Demand Reconciliation. To learn more about reconciling quantities,
refer to the Demand Reconciliation topic in the Application Help.
• Invoice - An outbound EDI 810/INVOIC document that sends an AR invoice to the customer trading
partner. To learn more about invoicing, review the AR Invoice Entry topic in the Application Help.
• Sales Order Acknowledgement - An outbound EDI 855/865/ORDRSP document that confirms that the
sales order is in process. It sends the Sales Order Acknowledgement report to this customer trading partner.
The Epicor application produces this when it generates a sales order for inbound demand received from the
• Response to a Sales Order Charge - An outbound document that allows you to respond to your customer
trading partner's request for a change to an existing sales order. The customer can accept the sales order
with the change, accept the sales order without the change, or reject the sales order. The Epicor application
236 Epicor ERP | 9.05.700

produces this when it updates an existing sales order that was generated from inbound demand received
from the customer trading partner.
• Order Status - An outbound document that reports the current state of a sales order. The Epicor application
produces this when it generates a new sales order or updates an existing sales order created from inbound
demand received from the customer trading partner.
Where Located
The Type field is located on the Customer Maintenance > Documents and Customer Maintenance > Ship To >
Documents sheets.
Menu Path
Unit Price Difference
Specifies if the Epicor application should validate if there is a difference between the current unit price in your
Epicor application database and the unit price in an incoming EDI file received from this customer trading partner.
• Select the check box if the Epicor application should perform this validation when you run the Process Demands
selection (on the Actions menu in Demand Entry). If you select this check box, use the associated Action field
to specify how the Epicor application should process demand schedules when unit price validations fail.
• Clear the check box to skip this validation when importing part demand from this customer trading partner.
Epicor ERP | 9.05.700 237

Where Located
The Unit Price Difference check box is located on the Customer Maintenance > Customer > Demand and
Menu Path
Example
You receive an inbound EDI file from this trading partner, requesting you ship 100 units of a widget at a unit
price of $1.90. However, your current unit price in the Epicor application is set at $2.00. Using the Unit Price
Difference check box, you can choose to perform this unit price validation for this customer trading partner, or
skip the validation. .
Weekly Forward, Rules
Weekly Forward periodicity designates that all deliveries to this customer are only sent once per week.
• Select this check box to use Weekly Forward periodicity rules when calculating shipping schedule dates for
this customer.
• Optionally, you can use the Ship Day field to specify the day of the week on which shipments must arrive
to this customer.
Where Located
238 Epicor ERP | 9.05.700

The Weekly Forward, Rules check box is located on Customer Periodicity Maintenance. To launch Customer
Periodicity Maintenance from the Main Menu:
• Demand Management > Setup > Periodicity
Where Located
The Weekly Forward, Rules check box is located on Customer Periodicity Maintenance.
Menu Path
Weekly Forward, Ship Day
If you selected the Weekly Forward Rules check box, select the day of the week on which shipments must
arrive to this customer.
Where Located
The Weekly Forward, Ship Day field is located on Customer Periodicity Maintenance. The Weekly Forward,
Ship Day field is located on Customer Periodicity Maintenance.
Menu Path
Epicor ERP | 9.05.700 239

Appendices EDI / Demand Management Technical Reference Guide
Appendices
Appendix A: EDI Demand Management / Order Management Pricing

Flowcharts
240 Epicor ERP | 9.05.700

EDI / Demand Management Technical Reference Guide Appendices
Epicor ERP | 9.05.700 241

Appendix B: EDI / Demand Management Part Validation Processing Flowchart
242 Epicor ERP | 9.05.700

EDI / Demand Management Technical Reference Guide Appendices
Appendix C: Part Lookup and UOM Determination Flowchart
Epicor ERP | 9.05.700 243

Appendix D: EDI / Demand Management Plant Code Assignment Flowchart
244 Epicor ERP | 9.05.700

EDI / Demand Management Technical Reference Guide Index
Index
A demand_header rows (demand header record for demandhead
table) 94
accept type 189 demand_header rows (demand header record for demandhead
action (add) 190 table) table schematic 95
action (cancel) 191 demand_schedule rows (demand schedule record for
action (change) 192 demandschedule table) 117
action (check for part) 194 demand_schedule rows (demand schedule record for
action (check for revision level) 196 demandschedule table) table schematic 118
action (check partial shipments) 195 direction 219
action (cumulative check discrepancies) 197
action (date change) 198
action (new line) 199
E
action (quantity change) 200 edi / demand management base components overview flowchart
add 201 11
allow non perfect match 202 EDI / Demand Management base concepts 11
allow shipments for orders on hold 202 edi 810/INVOIC transactions (outbound invoices) 184
alt trading partner 203 edi 855/865/ORDRSP transactions (outbound order
automatically match all 204 acknowledgements) 180
edi 856/DESADV transactions (outbound advance shipping
C notices) 182
edi file requirements and formatting rules 92
cancel 204 electronic data interchange (edi) 12
cancel non matched 205 entering demand contracts 74
cancel schedules action 206 evision 14
change 207 example 201, 205, 207, 216, 226, 232, 238
check for part 208 exclude from / from (days) 219
check for revision level 210 exclude until / until (days) 220
check forecast schedules 208 extra_charges rows (demandmisc table for demandheader and
check partial shipments 209 demanddetail records) 107
check unfirm schedules 212 extra_charges rows (demandmisc table for demandheader and
close rejected schedules 211 demanddetail records) table schematic 108
company configuration maintenance 32
consider working days in the delivery dates calculation 212
correcting errors using the service connect task monitor 164
F
creating demand entries for existing orders 90 forecast transactions generated from inbound edi demand 179
cumulative check discrepancies 213
customer periodicity maintenance 35
H
D header > matching sheet 82
hold orders for review 220
daily, include saturdays and sunday shipments 215 how it is organized 9
daily, rules 214
date change 215
date type 216 I
defining outbound edi report formats 59
defining trading partners in customer maintenance 37 import folder 221, 222
delivery days 217 inbound edi transaction file mappings 91
demand entries generated from inbound edi transactions 171 intended audience 9
demand management part validation processing flowchart 242 introduction 9
demand management plant code assignment flowchart 244 invalid contract task error case study 165
demand management pricing flowchart 240 invalid demand data error correction case study 165
demand processing logs and error resolution 172
demand_detail rows (demand detail record for demanddetail L
table) 110
demand_detail rows (demand detail record for demanddetail line > detail sheet 79
table) table schematic 111 logic/algorithms 212, 218, 221
Epicor ERP | 9.05.700 245

Index EDI / Demand Management Technical Reference Guide
M Q
main workflow 141 quantity change 232
main_demanddetail update workflow error messages 168
main_demanddetailupdate workflow 152
main_demandhead update workflow error messages 167
R
main_demandheadupdate workflow 142 record hierarchy for inbound edi files 93
main_demandschedule update workflow error messages 170
main_demandscheduleupdate workflow 162
main_detailpartvalidation 159 S
main_detailpartvalidationbypart workflow error messages 169
map id 222 service connect workflow processing 137
modifiers 189 setup components 27
monthly forward, first day ship 224 smart string row table schematic 126
monthly forward, rules 223 smart string rows 125
monthly forward, week number in the month 224 split demand 233
N T
new line 225 test record 234
nth day of the week, day of the week shipment 226 Tolerance 234
nth day of the week, rules 226 trading partner 235
type 236
typical edi / demand management processing flow 17
O
options available 227 U
options selected 228
order management pricing flowchart 242 unit price difference 237
order transactions generated from inbound edi demand 176 user_defined rows (for demand_header, demand_detail and
outbound document 229 demand_schedule tables) 104
user_defined rows (for demand_header, demand_detail and
demand_schedule tables) table schematic 105
P
part, part lookup and UOM determination flowchart 243 W
periodicity 230
prerequisite installation and setup tasks 30 weekly forward, rules 238
Pricing 231 weekly forward, ship day 239
processing components 74 what is Demand Management? 15
programs and their modifiers 178 where located 190, 191, 192, 193, 194, 195, 196, 197, 198,
purpose of this guide 9 199, 200, 201, 202, 203, 204, 206, 207, 208, 209, 210, 211,
212, 213, 214, 215, 216, 218, 219, 220, 221, 222, 223, 224,
225, 226, 228, 229, 230, 231, 232, 233, 234, 235, 237, 238,
239
246 Epicor ERP | 9.05.700

Additional information is available at the Education and
Documentation areas of the EPICweb Customer Portal. To access
this site, you need a Site ID and an EPICweb account. To create an
account, go to http://support.epicor.com.

TechRefGuide EDI 905700

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TechRefGuide EDI 905700

Uploaded by

Copyright:

Available Formats

Epicor ERP

EDI / Demand Management

Epicor ERP | 9.05.700 3

Entering Demand Contracts...........................................................................................................................74

4 Epicor ERP | 9.05.700

Programs and Their Modifiers...............................................................................................................178

Epicor ERP | 9.05.700 5

6 Epicor ERP | 9.05.700

Epicor ERP | 9.05.700 7

Weekly Forward, Ship Day...........................................................................................................................239

8 Epicor ERP | 9.05.700

Purpose of this Guide

Epicor ERP | 9.05.700 9

10 Epicor ERP | 9.05.700

EDI / Demand Management Base Concepts

Epicor ERP | 9.05.700 11

What is Electronic Data Interchange (EDI)?

Supported Inbound EDI Documents

12 Epicor ERP | 9.05.700

Supported Outbound EDI Documents

Epicor ERP | 9.05.700 13

What is TIE KINETIX eVisionTM?

Importing Inbound EDI Transactions

14 Epicor ERP | 9.05.700

What is Demand Management?

Epicor ERP | 9.05.700 15

16 Epicor ERP | 9.05.700

Typical EDI / Demand Management Processing Flow

Defining the Trading Partner in Customer Maintenance

Epicor ERP | 9.05.700 17

Entering a Demand Contract

18 Epicor ERP | 9.05.700

Processing Inbound Transactions Using the Import EDI Demand Process

Epicor ERP | 9.05.700 19

Correcting Errors Using Demand Workbench

Optional - Processing Inbound EDI Transactions Using Service Connect Workflows

20 Epicor ERP | 9.05.700

Optional - Correcting Errors With the Service Connect Task Monitor

Epicor ERP | 9.05.700 21

Automated and Manual Demand Entry Processing

22 Epicor ERP | 9.05.700

Likewise, the resulting forecast transactions viewed or edited in Forecast Entry:

Epicor ERP | 9.05.700 23

Generating Outbound EDI Transactions

24 Epicor ERP | 9.05.700

Epicor ERP | 9.05.700 25

26 Epicor ERP | 9.05.700

4. Defining outbound EDI report formats by doing the following:

Epicor ERP | 9.05.700 27

Prerequisite Installation and Setup Tasks - Direct EDI Import

28 Epicor ERP | 9.05.700

1. Verifying prerequisite installations, including:

2. Configuring your Epicor application server.

3. Configuring Demand Management for EDI inbound and outbound processing.

Epicor ERP | 9.05.700 29

Optional Installation and Setup Tasks - Epicor Service Connect

30 Epicor ERP | 9.05.700

1. Verifying prerequisite installations, including:

7. Configuring Service Connect EDI Workflow.

9. Configuring Demand Management for EDI inbound and outbound processing.

Epicor ERP | 9.05.700 31

Company Configuration Maintenance

Programs and Their Modifiers

32 Epicor ERP | 9.05.700