TechRefGuide EDI Demand 100700

Epicor ERP
EDI / Demand Management

Technical Reference Guide
10.0.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 2014.
All rights reserved. No part of this publication may be reproduced in any form without the prior written consent of
Epicor Software Corporation.
10.0.700
Revision: July 03, 2014 12:07 p.m.
Total pages: 212
sys.ditaval
EDI / Demand Management Technical Reference Guide Contents
Contents
Introduction............................................................................................................................8
Purpose of this Guide.......................................................................................................................................8
Intended Audience...........................................................................................................................................8
How It is Organized.........................................................................................................................................9
EDI / Demand Management Base Concepts.......................................................................10
What is Electronic Data Interchange (EDI)?.....................................................................................................11
Supported Inbound EDI Documents........................................................................................................11
Supported Outbound EDI Documents.....................................................................................................12
What is TIE KINETIX eVisionTM?.....................................................................................................................13
Importing Inbound EDI Transactions...............................................................................................................13
What is Demand Management?.....................................................................................................................14
Typical EDI / Demand Management Processing Flow.......................................................................................16
Defining the Trading Partner in Customer Maintenance..........................................................................16
Entering a Demand Contract..................................................................................................................17
Processing Inbound Transactions Using the Import EDI Demand Process..................................................18
Correcting Errors Using Demand Workbench...................................................................................20
Automated and Manual Demand Entry Processing..................................................................................20
Generating Outbound EDI Transactions..................................................................................................22
Setup Components...............................................................................................................24
Prerequisite Installation and Setup Tasks........................................................................................................25
Company Configuration Maintenance...........................................................................................................27
Programs and Their Modifiers.................................................................................................................27
Customer Periodicity Maintenance.................................................................................................................30
Programs and Their Modifiers.................................................................................................................31
Defining Trading Partners in Customer Maintenance......................................................................................32
Customer > Demand..............................................................................................................................34
Programs and Their Modifiers..........................................................................................................35
Documents.............................................................................................................................................47
Ship To > Demand..................................................................................................................................52
Ship To > Documents..............................................................................................................................54
Defining Outbound EDI Report Formats.........................................................................................................55
Create Report Data Definition.................................................................................................................56
Associate Report Data Definition with a Specific Document Type............................................................59
EDI 856/DESADV (Outbound Order ASN/Manifest) Example.............................................................64
EDI 810/INVOIC (AR Invoice) Example..............................................................................................66
EDI 855/865/ORDRSP (Order Acknowledgement) Example...............................................................67
Define Auto Print Data Directive.............................................................................................................67
Create the Standard Auto Print Data Directive.................................................................................68
Define the Conditional Expression............................................................................................69
Epicor ERP | 10.0.700 3

Contents EDI / Demand Management Technical Reference Guide
Define the Auto Print Action....................................................................................................72

Processing Components.......................................................................................................78
Entering Demand Contracts...........................................................................................................................78
Header...................................................................................................................................................79
Line > Detail...........................................................................................................................................83
Header > Matching.................................................................................................................................86
Demand Scheduling Matching Example 1........................................................................................89
Demand Scheduling Matching Example 2........................................................................................91
Creating Demand Entries for Existing Orders..................................................................................................93
Inbound EDI Transaction File Mappings..........................................................................................................95
EDI File Requirements and Formatting Rules............................................................................................96
Record Hierarchy for Inbound EDI Files....................................................................................................97
Demand_Header Rows (Demand Header Record for DemandHead Table)...............................................98
Table Schematic for Demand_Header Row Sample..........................................................................99
User_Defined Rows...............................................................................................................................108
Table Schematic for User_Defined Row Sample..............................................................................109
Extra_Charges Rows (DemandMisc Table for DemandHeader and DemandDetail Records)....................111
Table Schematic for Extra_Charges Row Sample............................................................................112
Demand_Detail Rows (Demand Detail Record for DemandDetail Table).................................................114
Table Schematic for Demand_Detail Row Sample...........................................................................115
Demand_Schedule Rows (Demand Schedule Record for DemandSchedule Table)..................................121
Table Schematic for Demand_Schedule Row Sample......................................................................122
Smart String Rows (for Demand_Detail Table).......................................................................................129
Table Schematic for Smart String Row Sample...............................................................................130
Direct Inbound EDI Transaction Import.........................................................................................................131
Scheduling and Running the Import EDI Demand Process......................................................................131
Programs and Their Modifiers........................................................................................................132
Using the System Agent and Completing the Import EDI Demand Process.....................................133
Using the Demand Workbench for Error Correction..............................................................................134
Import EDI Demand and User Hook Programs.......................................................................................137
Understanding the User Hook Programs Flowchart........................................................................139
Demand Entries Generated from Inbound EDI Transactions..........................................................................141
Demand Processing Logs and Error Resolution.............................................................................................142
Order Transactions Generated from Inbound EDI Demand............................................................................144
Programs and Their Modifiers...............................................................................................................146
Forecast Transactions Generated from Inbound EDI Demand........................................................................146
EDI 855/865/ORDRSP Transactions (Outbound Purchase/Change Order Acknowledgements)........................148
EDI 856/DESADV Transactions (Outbound Advance Shipping Notices)..........................................................149
EDI 810/INVOIC Transactions (Outbound Invoices)........................................................................................151
Demand Review Report................................................................................................................................153
Demand to Sales Order Net Change Report.................................................................................................155
Modifiers.............................................................................................................................157
Accept Type.................................................................................................................................................157
4 Epicor ERP | 10.0.700

Where Located.....................................................................................................................................158
Action (Add)................................................................................................................................................158
Where Located.....................................................................................................................................159
Action (Cancel)............................................................................................................................................159
Where Located.....................................................................................................................................160
Action (Change)...........................................................................................................................................160
Where Located.....................................................................................................................................161
Action (Check for Part).................................................................................................................................161
Where Located.....................................................................................................................................162
Action (Check Partial Shipments)..................................................................................................................162
Where Located.....................................................................................................................................163
Action (Check for Revision Level)..................................................................................................................163
Where Located.....................................................................................................................................164
Action (Cumulative Check Discrepancies).....................................................................................................164
Where Located.....................................................................................................................................165
Action (Date Change)..................................................................................................................................165
Where Located.....................................................................................................................................166
Action (New Line)........................................................................................................................................166
Where Located.....................................................................................................................................167
Action (Quantity Change)............................................................................................................................167
Where Located.....................................................................................................................................168
Add.............................................................................................................................................................168
Where Located.....................................................................................................................................168
Example................................................................................................................................................169
Allow Non Perfect Match.............................................................................................................................169
Where Located.....................................................................................................................................170
Allow Shipments for Orders on Hold............................................................................................................170
Where Located.....................................................................................................................................170
Alt Trading Partner.......................................................................................................................................170
Where Located.....................................................................................................................................171
Automatically Match All...............................................................................................................................171
Where Located.....................................................................................................................................172
Cancel.........................................................................................................................................................172
Where Located.....................................................................................................................................172
Example................................................................................................................................................172
Cancel Non Matched...................................................................................................................................173
Where Located.....................................................................................................................................173
Cancel Schedules Action..............................................................................................................................174
Where Located.....................................................................................................................................174
Change........................................................................................................................................................174
Where Located.....................................................................................................................................174
Example................................................................................................................................................175
Check Forecast Schedules............................................................................................................................175
Where Located.....................................................................................................................................175
Check for Part..............................................................................................................................................175
Epicor ERP | 10.0.700 5

Contents EDI / Demand Management Technical Reference Guide
Where Located.....................................................................................................................................176
Check Partial Shipments...............................................................................................................................176
Where Located.....................................................................................................................................176
Check for Revision Level...............................................................................................................................177
Where Located.....................................................................................................................................177
Close Rejected Schedules.............................................................................................................................178
Where Located.....................................................................................................................................178
Logic/Algorithms...................................................................................................................................179
Check Unfirm Schedules..............................................................................................................................179
Where Located.....................................................................................................................................179
Consider Working Days in the Delivery Days Calculation...............................................................................179
Where Located.....................................................................................................................................180
Cumulative Check Discrepancies..................................................................................................................180
Where Located.....................................................................................................................................180
Daily, Rules..................................................................................................................................................181
Where Located.....................................................................................................................................181
Daily, Include Saturdays and Sunday Shipments...........................................................................................181
Where Located.....................................................................................................................................181
Date Change...............................................................................................................................................182
Where Located.....................................................................................................................................182
Example................................................................................................................................................182
Date Type....................................................................................................................................................182
Where Located.....................................................................................................................................183
Delivery Days...............................................................................................................................................183
Where Located.....................................................................................................................................184
Example................................................................................................................................................185
Direction......................................................................................................................................................185
Where Located.....................................................................................................................................185
Exclude From / From (days)...........................................................................................................................186
Exclude Until / Until (days)............................................................................................................................186
Hold Orders for Review................................................................................................................................187
Where Located.....................................................................................................................................187
Import Folder (Company Maintenance)........................................................................................................188
Where Located.....................................................................................................................................188
Import Folder...............................................................................................................................................188
Where Located.....................................................................................................................................188
Map ID........................................................................................................................................................188
Where Located.....................................................................................................................................189
Monthly Forward, Rules...............................................................................................................................189
Where Located.....................................................................................................................................190
Monthly Forward, First Day Ship...................................................................................................................190
Where Located.....................................................................................................................................190
Monthly Forward, Week Number in the Month............................................................................................190
6 Epicor ERP | 10.0.700

Where Located.....................................................................................................................................190
New Line.....................................................................................................................................................191
Where Located.....................................................................................................................................191
Example................................................................................................................................................192
Nth Day of the Week, Rules.........................................................................................................................192
Where Located.....................................................................................................................................192
Nth Day of the Week, Day of the Week Shipment........................................................................................192
Where Located.....................................................................................................................................192
Options Available.........................................................................................................................................192
Where Located.....................................................................................................................................193
Options Selected..........................................................................................................................................194
Where Located.....................................................................................................................................195
Outbound Document...................................................................................................................................195
Where Located.....................................................................................................................................196
Periodicity....................................................................................................................................................196
Where Located.....................................................................................................................................196
Pricing.........................................................................................................................................................197
Where Located.....................................................................................................................................197
Quantity Change.........................................................................................................................................198
Where Located.....................................................................................................................................198
Example................................................................................................................................................198
Split Demand...............................................................................................................................................198
Where Located.....................................................................................................................................199
Test Record..................................................................................................................................................199
Where Located.....................................................................................................................................199
Tolerance.....................................................................................................................................................200
Where Located.....................................................................................................................................200
Trading Partner............................................................................................................................................201
Where Located.....................................................................................................................................201
Type............................................................................................................................................................201
Where Located.....................................................................................................................................202
Unit Price Difference....................................................................................................................................203
Where Located.....................................................................................................................................203
Example................................................................................................................................................203
Weekly Forward, Rules.................................................................................................................................204
Where Located.....................................................................................................................................204
Weekly Forward, Ship Day...........................................................................................................................204
Where Located.....................................................................................................................................204
Appendices..........................................................................................................................205
Appendix A: EDI Demand Management / Order Management Pricing Flowcharts.........................................205
Appendix B: EDI / Demand Management Part Validation Processing Flowchart.............................................207
Appendix C: Part Lookup and UOM Determination Flowchart......................................................................208
Appendix D: EDI / Demand Management site Code Assignment Flowchart...................................................209
Epicor ERP | 10.0.700 7

Introduction EDI / Demand Management Technical Reference Guide
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.
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 acknowledgments, 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.
8 Epicor ERP | 10.0.700

EDI / Demand Management Technical Reference Guide Introduction
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.
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 site 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.
Epicor ERP | 10.0.700 9

EDI / Demand Management Base Concepts EDI / Demand Management Technical Reference Guide
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)
10 Epicor ERP | 10.0.700

EDI / Demand Management Technical Reference Guide EDI / Demand Management Base Concepts
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
Epicor ERP | 10.0.700 11

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 Acknowledgments) - 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 Acknowledgment 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.
12 Epicor ERP | 10.0.700

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 Acknowledgment, 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. This process
server code for significantly improved EDI performance.
File importation occurs based on a processing schedule that you designate in the Import EDI Demand Process. If
erroneous data is identified during direct EDI import processing, you can correct it as required using the Demand
Workbench
Note Service Connect can no longer be used for importation of inbound EDI records in Epicor ERP.
Epicor ERP | 10.0.700 13

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 Need
By 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.
14 Epicor ERP | 10.0.700

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 Import EDI Demand process.
The Import EDI Demand 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.
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.
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.
Note 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 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.
Epicor ERP | 10.0.700 15

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
Correcting Errors using Demand Workbench
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.
16 Epicor ERP | 10.0.700

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.
Epicor ERP | 10.0.700 17

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.
18 Epicor ERP | 10.0.700

You manage Direct EDI import 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.
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 | 10.0.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.
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.
20 Epicor ERP | 10.0.700

Likewise, the resulting forecast transactions viewed or edited in Forecast Entry:
Refer to Order Transactions Generated from Inbound EDI Demand and Forecast Transactions Generated
from Inbound EDI Demand for more details.
Epicor ERP | 10.0.700 21

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 Acknowledgments
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
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.
22 Epicor ERP | 10.0.700

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:
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.
Epicor ERP | 10.0.700 23

Setup Components EDI / Demand Management Technical Reference Guide
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 and Epicor ERP 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 and Epicor application 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.
24 Epicor ERP | 10.0.700

EDI / Demand Management Technical Reference Guide Setup Components
Prerequisite Installation and Setup Tasks
When 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:
Epicor ERP | 10.0.700 25

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, including manually creating Epicor3Data > EDIData > In >
Demand and accompanying folders that support inbound and outbound EDI processing. It must contain
the following file structure:
26 Epicor ERP | 10.0.700

3. Performing post-installation steps, including reviewing EDI file layouts, configuring Demand Management
for EDI inbound and outbound EDI automatic generation.
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.
You also 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 Setup > Company/Site Maintenance > Company Configuration
Epicor ERP | 10.0.700 27

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 site calendar.
If the Consider Working Days in the Delivery Days Calculation check box is cleared, this factor
represents delivery days.
28 Epicor ERP | 10.0.700

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 (located on the Epicor application
server) 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.
Example The recommended path, as per the file structure setup designated in Prerequisite Installation
and Setup Tasks topic, is c:\Epicor3Data > EDIData > In > Demand. The specified folder path must
use UNC-naming conventions, not a locally-mapped drive letter.
Use the Company Configuration > Modules > Materials > Shipping/Receiving sheet to define parameters
that determine how the Demand Management module should impact shipping and receiving activities in a
specified company. 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.
Epicor ERP | 10.0.700 29

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.
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.
30 Epicor ERP | 10.0.700

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 site 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.
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
Use the Detail sheet to define the primary attributes of the customized report. You use the controls on this sheet
to create a new custom report or find and select an existing report. 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.
Epicor ERP | 10.0.700 31

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.
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.
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.
32 Epicor ERP | 10.0.700

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 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.
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.
Epicor ERP | 10.0.700 33

Customer > Demand
processing parameters that specify how the Epicor application should evaluate incoming EDI shipping transactions
received from your customer.
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.
34 Epicor ERP | 10.0.700

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 > EDI > Setup > Customer
Sales Management > Order Management > Setup > Customer
Sales Management > Quote Management > Setup > Customer
Service Management > Field Service > Setup > Customer
For CRM users, the Main Menu appears as:
Customer Relationship Management > Sales and Marketing 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
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 site calendar.
Note For this scenario, the Epicor application performs the following calculations:
The associated site calendar is configured for a standard Monday through Friday work schedule.
The Delivery Days field is set to 5 for this customer trading partner.
Epicor ERP | 10.0.700 35

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 site 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 site
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.
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.
36 Epicor ERP | 10.0.700

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.
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.
Epicor ERP | 10.0.700 37

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
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.
38 Epicor ERP | 10.0.700

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.
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
Epicor ERP | 10.0.700 39

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.
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
40 Epicor ERP | 10.0.700

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.
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.
Epicor ERP | 10.0.700 41

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
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
42 Epicor ERP | 10.0.700

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.
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
Epicor ERP | 10.0.700 43

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
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
44 Epicor ERP | 10.0.700

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
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
Epicor ERP | 10.0.700 45

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.
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.
46 Epicor ERP | 10.0.700

Documents
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 acknowledgments,
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.
Epicor ERP | 10.0.700 47

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.
48 Epicor ERP | 10.0.700

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.
Epicor ERP | 10.0.700 49

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.
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.
50 Epicor ERP | 10.0.700

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.
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.
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):
Epicor ERP | 10.0.700 51

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
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.
52 Epicor ERP | 10.0.700

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.
Epicor ERP | 10.0.700 53

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
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.
54 Epicor ERP | 10.0.700

Defining Outbound EDI Report Formats
To define 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
Acknowledgments and Packing Slips) using Report Style Maintenance.
Use the Business Process 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).
Epicor ERP | 10.0.700 55

It causes the Epicor application to automatically produce Order Acknowledgment, 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 Acknowledgments)
EDI 856/DESADV Transactions (Outbound Advance Shipping Notices)
EDI 810/INVOIC Transactions (Outbound Invoices)
Create Report Data Definition
Report Data Maintenance is an administrative tool you use to both create and/or edit data definitions for both
custom reports and existing reports. 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.
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.
56 Epicor ERP | 10.0.700

Note 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.
You can add any database table to a new or existing report to display the specific information you need.
You can access all tables within the database, as you can define relationships with parent and child
tables, and display related information pulled from any table you need. You can also define criteria
which limits the data that displays.
This program does not make changes to the report's layout; it only defines the data contained in the
outbound EDI file.
The following section describes the Report Data Maintenance values you can change.
Menu Path
System Management > Reporting > Report Data Definition
Important This program is not available in the Epicor Web Access.
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.
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.
Epicor ERP | 10.0.700 57

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 redisplays 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 excluded 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 excluded report fields in the Report Table Exclusion
grid.
58 Epicor ERP | 10.0.700

All fields in a selected table are considered as excluded. To include a field and label in the current report data
definition, do the following:
To include a previously excluded field in the current report data definition, simply select the one you want
to include (for example, Country Code), and click the Delete icon on the Standard Toolbar. This deletes it
from the exclusion list.
When you are finished including fields in selected database tables to the current report data definition, click
the Save icon.
Associate Report Data Definition with a Specific Document Type
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. You can define variations on each report you 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.
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).
Epicor ERP | 10.0.700 59

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 > Reporting > 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 to access the Styles > Detail sheet.
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:
60 Epicor ERP | 10.0.700

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:
Epicor ERP | 10.0.700 61

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:
62 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 63

EDI 856/DESADV (Outbound Order ASN/Manifest) Example
Use the Styles > Style Detail sheet to define the primary attributes of the customized report. You use controls on
this sheet to create a new custom report or find and select an existing report.
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.
64 Epicor ERP | 10.0.700

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:
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.
Epicor ERP | 10.0.700 65

EDI 810/INVOIC (AR Invoice) Example
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:
66 Epicor ERP | 10.0.700

EDI 855/865/ORDRSP (Order Acknowledgement) Example
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:
Define Auto Print Data Directive
Once you have associated report data definitions with specific type of documents in Report Style Maintenance,
you use Data Directives Maintenance to create standard Auto Print data directives.
Epicor ERP | 10.0.700 67

The EDI/Demand Management functions use these data directives to enable auto-generation of outbound EDI
files (for example, EDI 810 (Invoice), 855 (ASN) and 856 (Order Acknowledgements)) when triggered by specific
processing actions or events that take place 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.
A standard data directive not affect data in the database. In the case of EDI/Demand Management, it executes
after you save a sales order, shipment or invoice data transaction to the database. The data directive processes
multiple dirty rows modified in the database at once, and are intended for audit purposes (for example they can
write some information to log). A data directive is similar to a method directive, but instead of being launched
by a business object method, you link a data directive to a database table (for example the Shipment Header
(ShipHead) table). By applying the directive to a specific table, you use data directives to control data that may
be affected by several business objects.
Menu Path: System Management > Business Process Management > Data Directives Maintenance
These are the values you can modify in the Detail sheet:
Table - To set up auto-generation of document records that support outbound EDI transactions, enter or
select of the following:
ShipHead - Shipment Header table, used for auto-generation of outbound EDI 856/DESADV Advanced
Shipping Notice) transactions.
InvcHead - Invoice Header table, used for auto-generation of outbound EDI 810/INVOIC AR Invoice)
transactions.
OrderHed - Order Header table, used for auto-generation of outbound EDI 855/ORDRSP Order
Acknowledgement) transactions.
To create a standard directive for the selected database table, from the New menu, select New Standard
Directive to access the Standard sheet.
Create the Standard Auto Print Data Directive
Use the Standard sheet to create the standard data directives. In the standard mode, all database changes
incurred by the table during the call to the server are processed per single directive execution. When the standard
directives are used, the changes made in the temp-table affect data submitted to subsequent actions and directives
with the standard mode. Usually, execution of the standard data directives is fast.
In a standard data directive, you define conditions under which the data directive operates, and designate the
workflow actions associated with it; one of these is automatic printing of a specified report with specified options.
This is the type of data directive condition and workflow action you define for the selected database table.
Directive Name - Specifies the name of the directive (for example, EDI_856_E10). For ease of maintaining
and tracking EDI-related data directives, a best practice would be to include the EDI transaction type (EDI 856,
EDI 810 or EDI 855) in the name.
Group - Specifies the group to which the current directive belongs (for example, EDI). This field is optional,
but can help you to organize directives for searches, and it is used when exporting directives. The application
allows only directives that are part of a group to be exported.
68 Epicor ERP | 10.0.700

Define the Conditional Expression
After using the Standard sheet to assign a directive name and group to the selected database table, click Design
to invoke the BPM (Business Practice Management) Workflow Designer.
To design an Auto-Print BPM workflow for the data directive, do the following:
1. Drag the Condition and Auto Print icons from the selection panel on the left to the upper workspace area.
The positioning of the icons is not critical.
2. Create a link from the Start icon to the Condition icon. To do this, click Start, click one of the outward
pointing arrows around the outside of the icon, and drag the cursor to one of the outward pointing arrows
around the outside of the Condition icon.
Epicor ERP | 10.0.700 69

3. Click the Condition icon, then click the New icon
( )
in the Condition pane.
4. Using the down arrow, select 'The specified field of the changed row is equal to the specified expression'.
5. Click the first specified clause in the selected expression to access the Select Table Field(s) window.
6. The Select Table Field(s) window displays the fields associated with the temporary ShipHead table. Enter edi
into the Fields field to find the EDIReady field. To select it, select the check box to the left of the field
number, then click OK.
7. After you select the EDIReady field, the expression now reads as 'The ttShipHead.Ready field of the
changed rows is equal to the specified expression'.
8. Click the down arrow to the right of the changed rows clause and select all changed rows.
70 Epicor ERP | 10.0.700

9. Click the last specified clause in the expression to access the Specify an expression window.
10. In the Specify an expression window, enter true, and click OK.
11. When you finish defining the conditional expression, it reads as follows:
When you process an ASN shipment, the Epicor application reads the record created in the EDIReady field
in the temporary ShipHead table. If the value of the field is true, the condition is satisfied.
Epicor ERP | 10.0.700 71

Define the Auto Print Action
After using the BPM Workflow Design to define the conditional expression, you must define the Auto Print action
that takes place if the expression is satisfied (true) during the processing of a transaction, this case a shipment
to your customer. The Auto Print action is what actually produces the outbound EDI transaction, in this case the
EDI 856 ASN you send to your customer.
To design an Auto-Print BPM workflow for the data directive, do the following:
1. Create a link from the Condition icon to the Auto Print icon. To do this, click Start, click the left outward
pointing arrow on the outside of the icon, and drag the cursor to one of the outward pointing arrows around
the outside of the Auto Print icon.
Important You must connect the link from the left outward pointing arrow; this represents a True
condition. If you connect the link from the right outward arrow, it is incorrect because it represents
a False condition.
72 Epicor ERP | 10.0.700

2. Click the Auto Print icon. The following expression appears in the Actions pane:
'Automatically print specified report with specified conditions'
3. Click the first specified clause in the expression; the AutoPrint Report Search window displays.
4. In the Report Options sheet, enter the following:

In the Run Schedule field, select Immediate.
In the Print Action field, select Auto Preview to auto preview the outbound EDI transaction, or Auto
Print to simply process the outbound EDI transaction.
Click Apply.
5. Select the Report Parameters sheet.
Epicor ERP | 10.0.700 73

Do the following:
Select the grid line with PackNum listed in the Parameter Name column.
Click the down arrow to the right of 'The 0 constant.
Select 'The specified table and field value'.
Click specified to access the Select Table Field(s) window.
74 Epicor ERP | 10.0.700

6. The Select Table Field(s) window displays the fields associated with the temporary ShipHead table. Enter
pack into the Fields field to find the PackNum field. To select it, select the check box to the left of the field
number, then click OK.
7. After you select the PackNum field, the action expression now reads as follows.
8. Click Apply, then click OK to return to the BPM Workflow Designer.
Epicor ERP | 10.0.700 75

9. The BPM Workflow Designer displays the completed Auto Print action expression; do the following:
Click Validate to validate the completed Auto Print action expression.
Click Save and Exit to return to Data Directive Maintenance.
76 Epicor ERP | 10.0.700

10. Data Directives Maintenance displays the graphical workflow you just designed; to enable the workflow for
use, do the following
Click Save on the Standard toolbar.
Select the Enabled check box.
Click Save again.
Epicor ERP | 10.0.700 77

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 create 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.
78 Epicor ERP | 10.0.700

EDI / Demand Management Technical Reference Guide Processing Components
Header
Use the Header sheet to enter or edit primary details for the demand contract. This defines the customer and
default settings 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. Using it, you
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 | 10.0.700 79

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

To launch this program from the Main Menu:
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
80 Epicor ERP | 10.0.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 | 10.0.700 81

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.
82 Epicor ERP | 10.0.700

Line > Detail
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.
Epicor ERP | 10.0.700 83

EAN-8, EAN-13, EAN-14, GTIN-14 or UPC-12 product codes defined for the part in the Part Maintenance
- Part - UOMs sheet.
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 displays stating that the Quantity Per is less
than the specified Minimum Call Off Quantity.
Site - Specifies the site 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
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).
84 Epicor ERP | 10.0.700

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.
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
Epicor ERP | 10.0.700 85

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
Use the Header > Matching sheet to specify 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.
These are the demand schedule matching parameters you define:

You specify if a perfect match, or non-perfect match should be 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.
86 Epicor ERP | 10.0.700

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.
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.
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
Epicor ERP | 10.0.700 87

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
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.
88 Epicor ERP | 10.0.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 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.
Demand Scheduling Matching Example 1
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 Your customer trading partner requests changes of quantities and Need By Dates for ordered
items after sending an initial request via EDI. In order to process these changes, the Epicor application
needs to find and match them to the demand schedule releases to which they apply, based on the specified
matching criteria. Once found, the Epicor application then updates the quantities and Ship By dates
accordingly in the associated order releases.
Referring to the following graphics, these order releases have already been created for demand schedules previously
generated for this customer trading partner, and contain the following quantities and dates:
A release of 10 units, with a Need By date of 5/15/14 and a Ship By date of 5/10/14,
A release of 20 units, with a Need By date of 6/15/14 and a Ship By date of 6/10/14.
A release of 50 units, with a Need By date of 10/15/14 and a Ship By date of 10/10/14,
These are the order and demand schedules the Epicor application generated when this EDI request was initially
received:
These are the order and Need By date changes you subsequently received from your customer trading partner
after the initial EDI request:
A release of 15 units, with a Need By date of 5/21/14,
A release of 25 units, with a Need By date of 6/21/14,
A release of 55 units, with a Need By date of 10/21/14.
Epicor ERP | 10.0.700 89

These are the order and demand schedules the Epicor application generated when this EDI request was initially
received:
These are the demand schedules the Epicor application generated from new 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, and then by Ship By date.
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:
90 Epicor ERP | 10.0.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 following information in the order releases:
Changes initial release of 10 units to 15, changes the Need By date of 5/15/14 to 5/21/14, with a Ship By
date of 5/16/14 (based on a five day shipping lead time).
date of 6/16/14.
date of 10/16/14.
Demand Scheduling Matching Example 2
If your customer trading partner requests a cancellation of the release with a Need By date of 9/15/14 and a
Ship By date of 9/1110/14, 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 | 10.0.700 91

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:
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.
92 Epicor ERP | 10.0.700

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 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
Epicor ERP | 10.0.700 93

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.
94 Epicor ERP | 10.0.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. Before it does this, the third-party EDI processor (for example, TIE KINETIX eVision) receives the
inbound EDI transaction, maps it and converts it 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!
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.
Epicor ERP | 10.0.700 95

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
YY - Two digit year (for example, 14 for 2014, 15 for 2015)
MM - Two digit month (for example, 01 for January, 12 for December)
MM - Two digit day of the month
For example, January 25, 2014 would be expressed as 20140125.
Note For 9.05.607 and above, this is the 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; the Import EDI Demand Process generates 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>\Erp.ysXXX\ESC\EDI\Demand
directory, where XXX is the release version, such as 100.
96 Epicor ERP | 10.0.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 | 10.0.700 97

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.
98 Epicor ERP | 10.0.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 interface file is being processed.
Note In this row schematic, and the ones that follow, the data positions representing Company (in the
Demand_Header row, Row Data Position #6) always contain a value of Epic03. In certain training situations,
the sample file you may be using may contain Epic06 instead.
Row Example Record Plug-in Field or Type Sample Record Data Element Description
Data Data Value Dictionary
Position Name
1 H Record_Key Mandatory, The first character in each row of an inbound

Character EDI demand interface file 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.
Epicor ERP | 10.0.700 99

Position Name
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 demand

Numeric interface file (for example, Row 1, Row 2, etc.);
it must be unique per file row. Used to keep
track of data lines.
3 0 Hierarchical 0 (zero) for

Sequential hierarchical parent row number to
Parent Number H which this record row is linked. This denotes
that the hierarchical parent to which it is linked
Mandatory,
is the first sequential row in the record.
Numeric
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 Header row).
It denotes which Demand rows relate to the
Header row, which Schedule rows relate to
specific Demand rows, and which Extra
Charge rows relate to specific Header rows.
4 DALTON Tp_Id Mandatory, Identification number for the trading partner

Character from 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
100 Epicor ERP | 10.0.700

Position Name
specified in the Contract_Nbr attribute (Data
Position 7).
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.
The transaction type specified in this data
position controls how the Epicor application
will process 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 DALTON-CONTRACT Contract_Nbr Mandatory, Identification number for the demand contract

Character associated with the EDI record.
position 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 DALTON CustID Mandatory, Identification number for the customer number

Character associated with the EDI record.
position must be a valid customer
identification number, previously
established in Customer Maintenance in the
Epicor application.
Epicor ERP | 10.0.700 101

Position Name
9 No Value in BTCustNum Optional, Identification number for the bill to customer

Example Character number associated with the EDI record.
If a value appears in this data position,
it must be a valid bill to customer
established in Customer Maintenance in the
Epicor application. If a value exists in this
field, it should exist as an alternate bill to
number that is defined for the customer.
If left blank, the default is the sold to
customer in Field #8.
10 E100500-51 PONum Mandatory, Identification number for the customer purchase

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.
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,

Example Character the default is the sold to customer for the
trading partner.
12 P1 Ship_Code Optional, Indicates the ShipTo code for shipments

Character generated 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.
102 Epicor ERP | 10.0.700

Position Name
Denotes if a One Time Ship (OTS) address is
13 false UseOTS Optional,
being used.
Boolean
14 No Value in DNS_Before Optional, Earliest date before which the order cannot be
Example Date 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, Latest date after which the order cannot be
Example Date shipped. 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, Latest date by which your trading partner

Example Date wishes the associated purchased items to be
shipped to prevent cancellation. Items that
cannot be shipped prior to this date should be
cancelled.
17 No Value in FOB Optional, Indicates the Free On Board (FOB) point for
Example Character shipments 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
Character generated from this record.
must exist in the ShipVia table in the Epicor
application.
Epicor application.
19 No Value in Terms_Code Optional, Indicates the sales terms for orders generated
Example Character from this record.
must exist in the Terms table in the Epicor
application.
Epicor ERP | 10.0.700 103

Position Name
Epicor application.
20 No Value in Priority_Code Optional, Indicates the allocation priority for orders

Example Character generated from this record.
must exist in the AllocationPriority table in
the Epicor application.
Epicor application.
21 false Ship_Complete Optional, Indicates if orders generated from this record

Boolean must 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 application.
22 Ord Comm Order_Comment Optional, Contains comments for the overall order.
Character
These comments print on sales
acknowledgments, 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
Character order. The 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 false Order_Discount Optional, Indicates if order based discounting should be

Boolean applied automatically or manually triggered by
the user as a menu option.
104 Epicor ERP | 10.0.700

Position Name
If left blank, the default value comes from the
demand contract in the Epicor application.
25 false Test_Record Optional, Indicates if this row is being run in a test mode.
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

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

Example Character partner. 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 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

29 false ResetCums Optional,
like to reset the cumulative quantities stored
Boolean
to-date for previous transactions related to this
demand record.
If set to true, the Epicor application resets these
cumulative quantities.
Epicor ERP | 10.0.700 105

Position Name
Indicates if the resulting invoice for this demand
30 false ERSOrder Optional,
record should be flagged as an Evaluated
Boolean
Receipt 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

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

Character demand. 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
Example Character invoices generated from this record.
must exist in the Currency table in the Epicor
application.
Epicor application.
36 false Lock_Rate Optional, Used with the Currency module. When set to
Boolean true, 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
Example Character mailing address.
40 No Value in OTSAddress3 Optional, Third address line of the OTS drop ship mailing
106 Epicor ERP | 10.0.700

Position Name
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
Example Character drop ship mailing address.
43 No Value in OTSState Optional, State or province name for the OTS drop ship
Example Character mailing address.
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
Note If UseOTS (Data Position 13) is set
to true, this is a mandatory entry.
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 blank OTSSaveCustID Optional, OTS ship to customer identifier.

Character
50 blank OTSSaveAs Optional, Denotes the type of record in which OTS

Character information is being saved in the Epicor
application.
blank (no value) - 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 | 10.0.700 107

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.
108 Epicor ERP | 10.0.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 Example Record Data Plug-in Field or Type Sample Record Data Element
Data Value Dictionary Name Description
Position
1 UD Record_Key Mandatory, User Defined information related

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

Numeric inbound 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 Numeric number 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 Example UserChar1 -UserChar4 Character User defined Character field.
8-11 No Value in Example UserDate1 - UserDate4 Date User defined Date field.
No Value in Example
12-13 UserDecimal1 - Decimal User defined Decimal field.
UserDecimal2
14-15 No Value in Example UserInteger1 - Integer User defined Integer field.

UserInteger2
16-25 Head_E10_Character01 Character01-Character10 Character User defined Character field.

Head_E10_Character10
26-45 0101 Number01 - Number20 Number User defined Number field.

2020
Epicor ERP | 10.0.700 109

Row Example Record Data Plug-in Field or Type Sample Record Data Element
Data Value Dictionary Name Description
Position
46-65 20140909 Date01 - Date20 Date User defined Date field. In this
example, 09/09/2013, 09/10/2013
20140910
and 12/31/2013.
20141231
66-85 true CheckBox01 - Boolean User defined Checkbox field.

CheckBox20
86-95 ShortChar01 ShortChar01 - Character User defined Short Character field.

ShortChar10
ShortChar10
110 Epicor ERP | 10.0.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 | 10.0.700 111

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.
2 3 Hierarchical Level Mandatory, Sequential row number in the inbound

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.
112 Epicor ERP | 10.0.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.
Character
Custom
10
Epicor ERP | 10.0.700 113

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.
114 Epicor ERP | 10.0.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.
Row Example Plug-in Field or Type Sample Record Data Element Description
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 E100500-51 PONum Optional, Identification number for the customer purchase

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 | 10.0.700 115

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

Example Character ShipFrom site. This data position is normally blank.
Note Refer to Appendix D: Demand
Management site Code Assignment
Flowchart for details on how site codes are
assigned to demand records generated from
inbound EDI transactions.
7 FIRM Tran_Type Mandatory, Document that initiated the demand. Will be blank
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 false TestRecord Optional, Determines if this line is being run in a test mode.
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.
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.
116 Epicor ERP | 10.0.700

Position Value
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.
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
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.
Epicor ERP | 10.0.700 117

Position Value
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 in
Numeric Demand Entry.
Note This is a key data element in a
Demand Detail row.
20 true UsePriceList Optional, Indicates if the Customer Price List should be used
Boolean for order pricing for this Demand Detail row.
21 E PricePerCode Mandatory, Indicates the Pricing Per quantity.

Character
E - per Each
C - per Hundred
M - per Thousand
118 Epicor ERP | 10.0.700

Position Value
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, then the 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
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.
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.
Epicor ERP | 10.0.700 119

Position Value
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.

through Character
Custom10
EDI_Custom10
120 Epicor ERP | 10.0.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 | 10.0.700 121

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 Record Plug-in Field or Type Sample Record Data Element
Data Data Value Dictionary Name Description
Position
1 SCH Record_Key Mandatory, Demand schedule information related

Character to the linked Demand Detail line. The
Epicor application stores this data in
the Demand_Schedule table.
2 12 Hierarchical Level Mandatory, Sequential row number in the inbound

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

Number Numeric this 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 site Mandatory, Must be blank.

Example Character
Note Refer to Appendix D:
Demand Management site
Code Assignment Flowchart
for details on how site codes are
assigned to demand records
generated from inbound EDI
transactions.
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 E100500-51-002-001 Demand_ Reference Optional, The Epicor application uses this for
Character informational purposes and to aid in
matching demand schedules with
122 Epicor ERP | 10.0.700

Position
existing records in the OrderRel table.
Supplied by EDI.
7 60 Quantity Optional, Quantity, expressed in Our U/M, that

Numeric your trading partner is requesting be
shipped 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

Character how 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

Boolean test 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
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.
row.
Epicor ERP | 10.0.700 123

Position
11 No Value in Ship_Code Optional, Indicates the ShipTo code 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 ShipTo
schedule releases generated from
this record come from the
Ship_Code in the Header row.
Denotes if a One Time Ship (OTS)

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

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

Example Character for the shipment.
Mark For customer identification

15 No Value in MFCusNum Optional,
number, if being used for the demand
Example Character
schedule.
Mark For ship to identification number,
16 No Value in MFShipToNum Optional,
if being used for the demand schedule.
Example Character
Denotes if a One Time Mark For

17 false UseOTMF Optional,
(OTMF) address is being used for the
Boolean
shipment.
18 BEST ShipVia Optional, Indicates the Ship Via method for the
Character shipment schedule release generated
from this record.
Can be left blank, but if there is a
value, it must exist in the ShipVia
schedule releases generated from this
record come from the Ship_Code in
the Header row.
19 20141015 NeedByDate Mandatory, Date by which your trading partner

Date needs the item to be delivered.
row.
124 Epicor ERP | 10.0.700

Position
20 20141001 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.
row.
21 No Value in RAN Optional, Return/Release Authorization Number.

Example Character Used for 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, Number of delivery days required for

Example Integer the 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 false Rejected_By_User Optional, Indicates if the DemandSchedule has

Boolean been rejected by the user.
24 false Override_System_Reject Optional, Indicates if the system rejection should

Boolean be 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 the Epicor application.
26 No Value in Dock_Code Optional, Dock_Code defined for the ship to

Example Character address. Reserved for future use in the
Epicor application.
Epicor ERP | 10.0.700 125

Position
27 No Value in Location Optional, Location within the customer ship to

Example Character address. Reserved for future use in the
Epicor application.
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

Example Character be shipped on this schedule release.
30 DALTON OTS OTSName Optional, Full name for the One Time Ship (OTS)
Character drop shipment.
Note If UseOTS (Data Position
12) 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

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 USA OTSCountry Optional, Country portion for the OTS mailing

Character address.
Note If UseOTS (Data Position
mandatory entry.
38 No Value in OTSFaxNum Optional, OTS fax number.

Example Character
126 Epicor ERP | 10.0.700

Position
234-1212 OTSPhoneNum OTS telephone number.
39 Optional,
Character
40 No Value in OTSResaleID Optional, OTS resale identification number.

Example Character
41 Jerry OTSContact Optional, OTS contact name.

Character
42 blank OTSSaveCustID Optional, OTS ship to customer identifier.

Character
43 No Value in OTSSaveAs Optional, Denotes the type of record in which

Example Character OTS information is being saved in the
Epicor application.
blank (no value) - 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 Mandatory, If set to true, designates the items on

Boolean (Direct this Demand Schedule should be drop
Import) shipped by the supplier directly to the
customer. This marks the resulting sales
Optional,
order release record (that will be
Boolean
generated for this Demand Schedule)
(Service
as "shipped" and also marks the drop
Connect)
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 UseOTMF (Data Position
mandatory entry.
46 No Value in OTMFAddress1 Optional, First address line of the OTMF drop

Example Character ship mailing address.
47 No Value in OTMFAddress2 Optional, Second address line of the OTMF drop

Epicor ERP | 10.0.700 127

Position
48 No Value in OTMFAddress3 Optional, Third address line of the OTMF drop

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

51 No Value in OTMFZip Optional, Zip or postal code for the OTMF drop
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 Mandatory, Country portion for the OTMF drop

Example Character (If shipment mailing address. If OTMF is
OTMF is being used, this field is Mandatory and must
used) be a valid Country Code defined in the
Epicor application.
Optional,
Character (if
OTMF is not
being used)
Custom01-Custom10 Fields reserved for EDI custom

56 - 65 Custom1 - Optional,
development.
Custom10 Character
128 Epicor ERP | 10.0.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 | 10.0.700 129

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 Record Data Value Plug-in Type Sample Record Data
Data Field or Element 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

Level Numeric the 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 Numeric parent number to which
Number this record line 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-CVR1_23.00_Delrin_true_23.00_Silver_234 Smart Character Input parameters being

String 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.
130 Epicor ERP | 10.0.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. 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.
Use the Demand Workbench 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
the 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.
Epicor ERP | 10.0.700 131

The following section describes the Import EDI Demand Process values you can change.
Import EDI Demand Process

To launch this program from the Main Menu:
Sales Management > Demand Management > General Operations > Import EDI Process
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 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.
132 Epicor ERP | 10.0.700

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.
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.
To launch the process, click the Submit button. You can access the System Monitor to view the processing status
of the program by clicking the System Monitor icon located on the Windows taskbar.
Epicor ERP | 10.0.700 133

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.
Use the Errors sheets found at the Header, Line and Schedule level to identify a reason for the error.
134 Epicor ERP | 10.0.700

After you identify the error, correct the value that caused the import to fail.
Note You cannot create new demand entries using Demand Workbench. You can only use this program
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 is
ready for re-processing next time the Import EDI Demand Process is scheduled to run.
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.
Epicor ERP | 10.0.700 135

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.
136 Epicor ERP | 10.0.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 | 10.0.700 137

138 Epicor ERP | 10.0.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.cs 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.cs 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.cs 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.cs
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.cs 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.cs 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.cs 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 | 10.0.700 139

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.cs 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.cs 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.cs 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.cs 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.cs 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.
140 Epicor ERP | 10.0.700

Demand Entries Generated from Inbound EDI Transactions
When you receive inbound EDI transactions 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 you use 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 >
Demand or Ship To > Demand sheets. Refer to Demand Processing Logs and Error Resolution for more
details.
Epicor ERP | 10.0.700 141

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 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
in the Epicor application.
142 Epicor ERP | 10.0.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.
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.
Epicor ERP | 10.0.700 143

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.
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.
144 Epicor ERP | 10.0.700

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
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.
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
Epicor ERP | 10.0.700 145

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.
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.
146 Epicor ERP | 10.0.700

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.
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.
Epicor ERP | 10.0.700 147

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.
148 Epicor ERP | 10.0.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:\epicor3data\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.
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.
Epicor ERP | 10.0.700 149

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.
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.
150 Epicor ERP | 10.0.700

It generates and stores the ASN document record in the designated destination folder for outbound EDI files (for
example, c:\epicor3data\edi_data\outbound\ASNs). For the ASN Master Pack document record, it stores it
in the designated destination folder (c:\epicor3data\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
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.
Epicor ERP | 10.0.700 151

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:\epicor3data\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.
152 Epicor ERP | 10.0.700

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.
Epicor ERP | 10.0.700 153

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:
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.
154 Epicor ERP | 10.0.700

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 | 10.0.700 155

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.
156 Epicor ERP | 10.0.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.
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.
request is received with insufficient lead time), the Epicor application handles in the normal manner - it
Epicor ERP | 10.0.700 157

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
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
158 Epicor ERP | 10.0.700

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
the demand.
Epicor ERP | 10.0.700 159

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.
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
160 Epicor ERP | 10.0.700

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
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.
Epicor ERP | 10.0.700 161

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
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
162 Epicor ERP | 10.0.700

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
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.
Epicor ERP | 10.0.700 163

Where Located
The Action (Check for Revision Level) field is located on the Customer Maintenance > Customer > Demand and
Menu Path
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.
164 Epicor ERP | 10.0.700

Where Located
The Action (Cumulative Check Discrepancies) field is located on the Customer Maintenance > Customer >
Demand sheet.
Menu Path
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
Epicor ERP | 10.0.700 165

Where Located
The Action (Date Change) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
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
166 Epicor ERP | 10.0.700

Where Located
The Action (New Line) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
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
Epicor ERP | 10.0.700 167

Where Located
The Action (Quantity Change) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
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
168 Epicor ERP | 10.0.700


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.
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.
Epicor ERP | 10.0.700 169

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
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.
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.
170 Epicor ERP | 10.0.700

Where Located
The Alt Trading Partner field is located on the Customer Maintenance > Documents and Customer Maintenance
> Ship To > Documents sheets.
Menu Path
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.
Epicor ERP | 10.0.700 171

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
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
172 Epicor ERP | 10.0.700

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.
Where Located
The Close Non Matched check box is located on the Customer Maintenance > Customer > Demand sheet.
Menu Path
Epicor ERP | 10.0.700 173

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
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
174 Epicor ERP | 10.0.700


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.
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.
Epicor ERP | 10.0.700 175

Where Located
The Check for Part check box is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
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
176 Epicor ERP | 10.0.700


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
Epicor ERP | 10.0.700 177


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
178 Epicor ERP | 10.0.700

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.
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 site calendar.
If the Consider Working Days in the Delivery Days Calculation check box is cleared, this factor represents
delivery days.
Epicor ERP | 10.0.700 179

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
180 Epicor ERP | 10.0.700


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
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
Epicor ERP | 10.0.700 181

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
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.
182 Epicor ERP | 10.0.700

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
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 site calendar.
Epicor ERP | 10.0.700 183

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 site 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 site
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
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
184 Epicor ERP | 10.0.700

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.
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
Epicor ERP | 10.0.700 185


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).
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.
186 Epicor ERP | 10.0.700

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
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.
Epicor ERP | 10.0.700 187

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
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
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
188 Epicor ERP | 10.0.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.
Epicor ERP | 10.0.700 189

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.
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
190 Epicor ERP | 10.0.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 | 10.0.700 191

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
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.
192 Epicor ERP | 10.0.700

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.
Where Located
The Options Available field is located on the Customer Maintenance > Documents and Customer Maintenance
Menu Path
Epicor ERP | 10.0.700 193

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.
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.
194 Epicor ERP | 10.0.700

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).
Tip To enable automatic processing for a document using the Automatic check box, a value must be
entered into the Alt Trading Partner field!
Epicor ERP | 10.0.700 195

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
196 Epicor ERP | 10.0.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 | 10.0.700 197

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.
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.
198 Epicor ERP | 10.0.700

Where Located
The Split Demand check box is located on the Customer Maintenance > Customer > Demand sheet.
Menu Path
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
Epicor ERP | 10.0.700 199


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).
Where Located
The Tolerance field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
200 Epicor ERP | 10.0.700

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
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.
Epicor ERP | 10.0.700 201

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
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
202 Epicor ERP | 10.0.700

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.
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. .
Epicor ERP | 10.0.700 203

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
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
204 Epicor ERP | 10.0.700

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

Flowcharts
Epicor ERP | 10.0.700 205

Appendices EDI / Demand Management Technical Reference Guide
206 Epicor ERP | 10.0.700

Appendix B: EDI / Demand Management Part Validation Processing Flowchart
Epicor ERP | 10.0.700 207

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

Appendix D: EDI / Demand Management site Code Assignment Flowchart
Epicor ERP | 10.0.700 209

Index EDI / Demand Management Technical Reference Guide
Index
A demand_header rows (demand header record for demandhead
table) 98
accept type 157 demand_header rows (demand header record for demandhead
action (add) 158 table) table schematic 99
action (cancel) 159 demand_schedule rows (demand schedule record for
action (change) 160 demandschedule table) 121
action (check for part) 161 demand_schedule rows (demand schedule record for
action (check for revision level) 163 demandschedule table) table schematic 122
action (check partial shipments) 162 direction 185
action (cumulative check discrepancies) 164
action (date change) 165
action (new line) 166
E
action (quantity change) 167 edi / demand management base components overview flowchart
add 168 10
allow non perfect match 169 EDI / Demand Management base concepts 10
allow shipments for orders on hold 170 edi 810/INVOIC transactions (outbound invoices) 151
alt trading partner 170 edi 855/865/ORDRSP transactions (outbound order
automatically match all 171 acknowledgements) 148
edi 856/DESADV transactions (outbound advance shipping
C notices) 149
edi file requirements and formatting rules 96
cancel 172 electronic data interchange (edi) 11
cancel non matched 173 entering demand contracts 78
cancel schedules action 174 evision 13
change 174 example 169, 172, 175, 182, 192, 198, 203
check for part 175 exclude from / from (days) 186
check for revision level 177 exclude until / until (days) 186
check forecast schedules 175 extra_charges rows (demandmisc table for demandheader and
check partial shipments 176 demanddetail records) 111
check unfirm schedules 179 extra_charges rows (demandmisc table for demandheader and
close rejected schedules 178 demanddetail records) table schematic 112
company configuration maintenance 27
consider working days in the delivery dates calculation 179
creating demand entries for existing orders 93
F
cumulative check discrepancies 180 forecast transactions generated from inbound edi demand 146
customer periodicity maintenance 30
H
D
header > matching sheet 86, 89, 91
daily, include saturdays and sunday shipments 181 hold orders for review 187
daily, rules 181 how it is organized 9
date change 182
date type 182
defining outbound edi report formats 55 I
defining trading partners in customer maintenance 32
delivery days 183 import folder 188
demand entries generated from inbound edi transactions 141 inbound edi transaction file mappings 95
demand management part validation processing flowchart 207 intended audience 8
demand management pricing flowchart 205 introduction 8
demand management site code assignment flowchart 209
demand processing logs and error resolution 142 L
demand_detail rows (demand detail record for demanddetail
table) 114 line > detail sheet 83
demand_detail rows (demand detail record for demanddetail logic/algorithms 179, 185, 187
table) table schematic 115
210 Epicor ERP | 10.0.700

EDI / Demand Management Technical Reference Guide Index
M R
map id 188 record hierarchy for inbound edi files 97
modifiers 157
monthly forward, first day ship 190
monthly forward, rules 189
S
monthly forward, week number in the month 190 setup components 24
smart string row table schematic 130
N smart string rows 129
split demand 198
new line 191
nth day of the week, day of the week shipment 192
nth day of the week, rules 192
T
test record 199
O Tolerance 200
trading partner 201
options available 193 type 201
options selected 194 typical edi / demand management processing flow 16
order management pricing flowchart 207
order transactions generated from inbound edi demand 144
outbound document 195
U
unit price difference 203
P user_defined rows (for demand_header, demand_detail and
demand_schedule tables) 108
part, part lookup and UOM determination flowchart 208 user_defined rows (for demand_header, demand_detail and
periodicity 196 demand_schedule tables) table schematic 109
Pricing 197
processing components 78
programs and their modifiers 146
W
purpose of this guide 8 weekly forward, rules 204
weekly forward, ship day 204
Q what is Demand Management? 14
where located 158, 159, 160, 161, 162, 163, 164, 165, 166,
quantity change 198 167, 168, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179,
180, 181, 182, 183, 184, 185, 187, 188, 189, 190, 191, 192,
193, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204
Epicor ERP | 10.0.700 211

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 Demand 100700

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

TechRefGuide EDI Demand 100700

Caricato da

Copyright:

Formati disponibili

Epicor ERP

EDI / Demand Management

Epicor ERP | 10.0.700 3

Define the Auto Print Action....................................................................................................72

4 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 5

6 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 7

Purpose of this Guide

8 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 9

EDI / Demand Management Base Concepts

10 Epicor ERP | 10.0.700

What is Electronic Data Interchange (EDI)?

Supported Inbound EDI Documents

Epicor ERP | 10.0.700 11

Supported Outbound EDI Documents

12 Epicor ERP | 10.0.700

What is TIE KINETIX eVisionTM?

Importing Inbound EDI Transactions

Epicor ERP | 10.0.700 13

What is Demand Management?

14 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 15

Typical EDI / Demand Management Processing Flow

Defining the Trading Partner in Customer Maintenance

16 Epicor ERP | 10.0.700

Entering a Demand Contract

Epicor ERP | 10.0.700 17

Processing Inbound Transactions Using the Import EDI Demand Process

18 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 19

Correcting Errors Using Demand Workbench

Automated and Manual Demand Entry Processing

20 Epicor ERP | 10.0.700

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

Epicor ERP | 10.0.700 21

Generating Outbound EDI Transactions

22 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 23

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

24 Epicor ERP | 10.0.700

Prerequisite Installation and Setup Tasks

Epicor ERP | 10.0.700 25

1. Verifying prerequisite installations, including:

26 Epicor ERP | 10.0.700

Company Configuration Maintenance

Programs and Their Modifiers

Epicor ERP | 10.0.700 27

28 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 29

Customer Periodicity Maintenance

30 Epicor ERP | 10.0.700

Programs and Their Modifiers

Epicor ERP | 10.0.700 31

Defining Trading Partners in Customer Maintenance

32 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 33

Customer > Demand

34 Epicor ERP | 10.0.700

Programs and Their Modifiers

Epicor ERP | 10.0.700 35

36 Epicor ERP | 10.0.700

Epicor ERP | 10.0.700 37