Epicor10 techrefEDIDemandMgmt 102700

Epicor ERP
EDI Demand Management

Technical Reference Guide
10.2.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 2020.
All rights reserved. Not for distribution or republication. Information in this document is subject to Epicor license
agreement(s).
DOC0091E9
10.2.700
Revision: October 16, 2020 5:37 a.m.
Total pages: 236
sys.ditaval
EDI Demand Management Technical Reference Guide Contents
Contents
Introduction............................................................................................................................9
Purpose of this Guide.......................................................................................................................................9
Intended Audience...........................................................................................................................................9
How It is Organized.......................................................................................................................................10
EDI / Demand Management Base Concepts.......................................................................11
What is Electronic Data Interchange (EDI)?.....................................................................................................12
Supported Inbound EDI Documents........................................................................................................12
Supported Outbound EDI Documents.....................................................................................................13
What is TIE KINETIX eVisionTM?.....................................................................................................................14
Inbound EDI Transactions Import....................................................................................................................14
What is Demand Management?.....................................................................................................................15
Typical EDI / Demand Management Processing Flow.......................................................................................17
Define Trading Partner in Customer Maintenance...................................................................................17
Enter a Demand Contract.......................................................................................................................18
Process Inbound EDI Transactions...........................................................................................................19
Correct Errors Using the Demand Workbench..................................................................................20
Automated and Manual Demand Entry Processing..................................................................................20
Generate 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
Customer Maintenance..................................................................................................................................32
Customer > Demand..............................................................................................................................33
Programs and Their Modifiers..........................................................................................................34
Documents.............................................................................................................................................48
Ship To > Demand..................................................................................................................................54
Ship To > Documents..............................................................................................................................55
Outbound EDI Report Formats.......................................................................................................................57
Create Report Data Definition.................................................................................................................58
Associate Report Data Definition with a Specific Document Type............................................................61
EDI 856/DESADV (Outbound Order ASN/Manifest) Example.............................................................65
EDI 810/INVOIC (AR Invoice) Example..............................................................................................67
EDI 855/865/ORDRSP (Order Acknowledgement) Example...............................................................68
Auto Print Outbound EDI........................................................................................................................68
Create the Data Directive.................................................................................................................69
Define the Condition................................................................................................................70
Epicor ERP | 10.2.700 3

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

Processing Components.......................................................................................................78
Enter Demand Contracts................................................................................................................................78
Header...................................................................................................................................................79
Line > Detail...........................................................................................................................................82
Header > Matching.................................................................................................................................85
Demand Scheduling Matching Example 1........................................................................................88
Demand Scheduling Matching Example 2........................................................................................91
Create 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
Demand Header Row Sample Table Schematic.................................................................................99
User Defined Rows (Linked to Demand Header, Demand Detail and Demand Schedule Rows)...............109
User Defined Row Sample Table Schematic....................................................................................110
Extra Charges Rows (Linked to Demand Header and Demand Detail Rows)...........................................112
Extra Charges Row Sample Table Schematic..................................................................................113
Demand Detail Rows (Demand Detail Record for DemandDetail Table)..................................................115
Table Schematic for Demand Detail Row Sample...........................................................................116
Demand Schedule Rows (Demand Schedule Record for DemandSchedule Table)...................................122
Demand_Schedule Row Sample Table Schematic...........................................................................123
Smart String Rows (for DemandDetail Table).........................................................................................130
Smart String Row Sample Table Schematic.....................................................................................131
Package Control Rows (Linked to Demand Contract/Purchase Order)....................................................132
Package Control Row Sample Table Schematic..............................................................................133
Direct Inbound EDI Transaction Import.........................................................................................................135
Schedule and Run the Import EDI Demand Process...............................................................................136
Programs and Their Modifiers........................................................................................................136
Use the System Agent and Complete the Import EDI Demand Process...........................................137
Use the ImportEDI Log and Demand Workbench for Error Correction....................................................138
ImportEDI.log................................................................................................................................138
Demand Workbench.....................................................................................................................138
Import EDI Demand Processing and User Hook BPMs............................................................................141
Understanding the User Hook BPMs Flowchart..............................................................................143
Demand Entries Generated from Inbound EDI Transactions..........................................................................145
Demand Processing Logs and Error Resolution.............................................................................................147
Order Transactions Generated from Inbound EDI Demand............................................................................149
Programs and Their Modifiers...............................................................................................................151
Forecast Transactions Generated from Inbound EDI Demand........................................................................151
Package Control Label Value Maintenance...................................................................................................152
Customer.............................................................................................................................................154
EDI 855/865/ORDRSP Transactions (Outbound Purchase/Change Order Acknowledgements)........................155
EDI 856/DESADV Transactions (Outbound Advance Shipping Notices)..........................................................158
4 Epicor ERP | 10.2.700

EDI 810/INVOIC Transactions (Outbound Invoices)........................................................................................161

Demand Review Report................................................................................................................................164
Demand to Sales Order Net Change Report.................................................................................................166
Modifiers.............................................................................................................................168
Accept Type.................................................................................................................................................168
Where Located.....................................................................................................................................169
Action (Add)................................................................................................................................................169
Where Located.....................................................................................................................................170
Action (Cancel)............................................................................................................................................170
Where Located.....................................................................................................................................171
Action (Change)...........................................................................................................................................171
Where Located.....................................................................................................................................172
Action (Capable to Promise).........................................................................................................................172
Where Located.....................................................................................................................................172
Action (Check for Part).................................................................................................................................173
Where Located.....................................................................................................................................173
Action (Check Partial Shipments)..................................................................................................................174
Where Located.....................................................................................................................................174
Action (Check for Revision Level)..................................................................................................................175
Where Located.....................................................................................................................................175
Action (Check for Run Out Part)...................................................................................................................175
Where Located.....................................................................................................................................176
Action (Cumulative Check Discrepancies).....................................................................................................177
Where Located.....................................................................................................................................177
Action (Date Change)..................................................................................................................................178
Where Located.....................................................................................................................................178
Action (New Line)........................................................................................................................................179
Where Located.....................................................................................................................................179
Action (Quantity Change)............................................................................................................................180
Where Located.....................................................................................................................................180
Add.............................................................................................................................................................180
Where Located.....................................................................................................................................181
Example................................................................................................................................................181
Allow Non Perfect Match.............................................................................................................................181
Where Located.....................................................................................................................................182
Allow Shipments for Orders on Hold............................................................................................................182
Where Located.....................................................................................................................................182
Alt Trading Partner.......................................................................................................................................182
Where Located.....................................................................................................................................183
Automatically Match All...............................................................................................................................183
Where Located.....................................................................................................................................183
Cancel.........................................................................................................................................................184
Where Located.....................................................................................................................................184
Example................................................................................................................................................184
Cancel Non Matched...................................................................................................................................184
Epicor ERP | 10.2.700 5

Where Located.....................................................................................................................................185
Cancel Schedules Action..............................................................................................................................185
Where Located.....................................................................................................................................185
Change........................................................................................................................................................186
Where Located.....................................................................................................................................186
Example................................................................................................................................................186
Check Forecast Schedules............................................................................................................................186
Where Located.....................................................................................................................................187
Check Date (Capable to Promise).................................................................................................................187
Where Located.....................................................................................................................................188
Check for Part..............................................................................................................................................188
Where Located.....................................................................................................................................188
Check Partial Shipments...............................................................................................................................189
Where Located.....................................................................................................................................189
Check for Revision Level...............................................................................................................................190
Where Located.....................................................................................................................................190
Check For Run Out Part...............................................................................................................................190
Where Located.....................................................................................................................................191
Check Unfirm Schedules..............................................................................................................................191
Where Located.....................................................................................................................................191
Close Rejected Schedules.............................................................................................................................192
Where Located.....................................................................................................................................192
Logic/Algorithms...................................................................................................................................192
Consider Working Days in the Delivery Days Calculation...............................................................................192
Where Located.....................................................................................................................................193
Cumulative Check Discrepancies..................................................................................................................193
Where Located.....................................................................................................................................194
Customer.....................................................................................................................................................194
Where Located.....................................................................................................................................194
Daily, Rules..................................................................................................................................................194
Where Located.....................................................................................................................................195
Daily, Include Saturdays and Sunday Shipments...........................................................................................195
Where Located.....................................................................................................................................195
Date Change...............................................................................................................................................195
Where Located.....................................................................................................................................195
Example................................................................................................................................................196
Date Type....................................................................................................................................................196
Where Located.....................................................................................................................................196
Delivery Days...............................................................................................................................................197
Where Located.....................................................................................................................................198
Example................................................................................................................................................198
Direction......................................................................................................................................................199
Where Located.....................................................................................................................................199
Exclude From / From (days)...........................................................................................................................199
6 Epicor ERP | 10.2.700

Exclude Until / Until (days)............................................................................................................................200

Hold Orders for Review................................................................................................................................200
Where Located.....................................................................................................................................200
Import Folder (Company Maintenance)........................................................................................................201
Where Located.....................................................................................................................................201
Import Folder...............................................................................................................................................201
Where Located.....................................................................................................................................201
Label Values (1 - 30)....................................................................................................................................202
Where Located.....................................................................................................................................202
Map ID........................................................................................................................................................202
Where Located.....................................................................................................................................203
Monthly Forward, Rules...............................................................................................................................203
Where Located.....................................................................................................................................203
Monthly Forward, First Day Ship...................................................................................................................204
Where Located.....................................................................................................................................204
Monthly Forward, Week Number in the Month............................................................................................204
Where Located.....................................................................................................................................204
New Line.....................................................................................................................................................204
Where Located.....................................................................................................................................205
Example................................................................................................................................................205
Nth Day of the Week, Rules.........................................................................................................................205
Where Located.....................................................................................................................................205
Nth Day of the Week, Day of the Week Shipment........................................................................................206
Where Located.....................................................................................................................................206
Options Available.........................................................................................................................................206
Where Located.....................................................................................................................................207
Options Selected..........................................................................................................................................207
Where Located.....................................................................................................................................208
Outbound Document...................................................................................................................................208
Where Located.....................................................................................................................................209
Part..............................................................................................................................................................209
Where Located.....................................................................................................................................209
Periodicity....................................................................................................................................................210
Where Located.....................................................................................................................................210
Pricing.........................................................................................................................................................210
Where Located.....................................................................................................................................211
Quantity Change.........................................................................................................................................211
Where Located.....................................................................................................................................211
Example................................................................................................................................................212
Ship To (Package Control Label Value Maintenance)....................................................................................212
Where Located.....................................................................................................................................212
Split Demand (Capable to Promise)..............................................................................................................212
Where Located.....................................................................................................................................212
Test Record..................................................................................................................................................213
Epicor ERP | 10.2.700 7

Where Located.....................................................................................................................................213
Tolerance.....................................................................................................................................................213
Where Located.....................................................................................................................................214
Trading Partner............................................................................................................................................214
Where Located.....................................................................................................................................214
Type............................................................................................................................................................215
Where Located.....................................................................................................................................216
Update Dates (Capable to Promise)..............................................................................................................216
Where Located.....................................................................................................................................217
Unit Price Difference....................................................................................................................................217
Where Located.....................................................................................................................................217
Example................................................................................................................................................218
Weekly Forward, Rules.................................................................................................................................218
Where Located.....................................................................................................................................218
Weekly Forward, Ship Day...........................................................................................................................219
Where Located.....................................................................................................................................219
EDI / Demand Management Flowcharts...........................................................................220
Order Management Pricing - EDI / Demand Management............................................................................220
Part Lookup and UOM Determination - EDI / Demand Management.............................................................222
Part Validation Processing - EDI / Demand Management...............................................................................223
Site Code Assignment - EDI / Demand Management....................................................................................224
EDI/Demand Management Troubleshooting....................................................................225
Error Message Log.......................................................................................................................................225
Customer Maintenance > Demand - Lead Time Parameters..........................................................................226
Demand Contract Matching Parameters.......................................................................................................227
Inbound EDI Transaction Errors Troubleshooting..........................................................................................228
One Time Ship (OTS) Addresses in Demand Management............................................................................230
8 Epicor ERP | 10.2.700

EDI Demand Management Technical Reference Guide Introduction
Introduction
Purpose of this Guide
The EDI / Demand Management Technical Reference Guide examines, in detail, the primary components
that make up the Electronic Data Interchange (EDI) / Demand Management module interface. Many of the primary
components discussed in this guide perform more functions than what is described.
For more information about these features, review the related topics in the Application Help, contact your
consultant, or enroll in an appropriate Epicor course. When you finish reading this guide, you should better
understand the logic behind the EDI - Demand Management module interface.
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.
Epicor ERP | 10.2.700 9

Introduction EDI Demand Management Technical Reference Guide
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. EDI / Demand Management Flowcharts - This section includes supporting flowcharts related to pricing,
part validation, part lookup and site code assignment processing.
6. EDI / Demand Management Troubleshooting - This section contains topics related to troubleshooting
issues with a program or process in the Demand Management module, or related to EDI processing.
Please note that to clarify how the EDI / Demand Management module interface works, the concepts behind
each item are often repeated within other items. This is done to show how the various components, calculations,
values, and modifiers work together to convert inbound EDI files received from your customer trading partners
into actionable demand entries, demand schedules, orders, forecasts, shipping transactions and invoices.
10 Epicor ERP | 10.2.700

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

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

other customer locations when planning schedule transactions are issued by a consolidated scheduling
organization.
Supported Outbound EDI Documents
Epicor ERP and the Demand Management module support processing of the following types of outbound EDI
documents:
• 810/INVOIC (Outbound AR Invoices) - This EDI document is an electronic version of a paper invoice you
normally send to your customer. As a supplier, you use 810/INVOIC Invoices to communicate the payment
terns, specific items, price, and quantities you have delivered and which now must be paid for by your customer
trading partner. In the Epicor application, the foundation for this type of outbound EDI document is the text
or XML-based document record that it generates (either automatically or manually) in AR Invoice Entry based
on the standard AR Invoice form.
• 855/ORDRSP and 865/ORDRSP (Outbound Purchase Order 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.
Epicor ERP | 10.2.700 13

What is TIE KINETIX eVisionTM?
eVision is a third-party software package provided by TIE KINETIX, and is the only XML/EDI solution that has
been formally certified by Epicor for use with the Epicor application.
It uses advanced data transformation, integration, and workflow applications that are easily scalable as the
number of trading partners you interact with increase, and your operations grow in size and transaction volume.
It allows you to easily exchange critical business data between and within organizations.
• In general, eVision receives inbound EDI 830/DELFOR, 850/ORDERS, 860/ORDCHG and 862/DELJIT files from
your customer trading partners, converts them into a pre-defined Epicor-compatible format files, and then
deposits them into a designated inbound folder on your Epicor server for processing.
• Conversely, eVision collects outbound Order 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.
Inbound EDI Transactions Import
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 As of Epicor 10 Service Connect is no longer used for importation of inbound EDI records in Epicor
ERP.
14 Epicor ERP | 10.2.700

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

• You then enter demand contracts for these customers into Demand Contract Entry, using any length of
time (days, months, years) that you need for the length of the contact.
• The demand contract structure lets you attach multiple sales order releases to a single demand contract,
providing the ability to review the contract quantities with the actual incoming quantities.
• It also contains robust matching logic that allows you to receive and efficiently process changes (quantities,
prices and shipping dates) your customer trading partner requests to existing demand schedules and order
releases.
• A demand schedule is a schedule of order releases (processed against a demand contract) that defines both
the part quantities and the dates on which each release needs to be shipped to your customer trading partner.
• You can enter demand schedules for each demand contract manually, or
• If your customer trading partners sends you demand schedules via inbound EDI transactions, they are
automatically generated when the EDI transactions are successfully imported in the Epicor application
electronically through the 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.
16 Epicor ERP | 10.2.700

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.
Define Trading Partner in Customer Maintenance
A customer or business entity is identified in inbound and outbound EDI transactions by a unique trading partner
identification number. Prior to receiving inbound EDI transactions from a customer, you must assign and associate
the trading partner identification number with a specific customer record or ship to customer location in the
Customer Maintenance > Customer > Demand or Ship To > Demand sheets.
A customer or business entity is identified in inbound and outbound EDI transactions by a unique trading partner
identification number. Prior to receiving inbound EDI transactions from a customer, you must assign and associate
the trading partner identification number with a specific customer record or ship to customer location in the
Customer Maintenance > Customer > Demand or Ship To > Demand sheets.
• Using Customer Maintenance > Documents or Ship To > Documents sheets, you also create user-defined
rules that specify acceptance and matching criteria for demand transactions received on inbound EDI documents.
It also allows you to specify if inbound EDI transactions should be automatically processed; if you elect to do
this, the Epicor application automatically generates order releases or forecasts for all (or just error-free) inbound
EDI transactions.
Using the same sheets, you can also create user-defined rules for each customer trading partner that specify
how and when outbound EDI order acknowledgement, Advanced Shipping Notice and invoice transactions
should be generated.
Epicor ERP | 10.2.700 17

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

Process Inbound EDI Transactions
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.
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.
Epicor ERP | 10.2.700 19

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.
Correct Errors Using the 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.
20 Epicor ERP | 10.2.700

• 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.
Likewise, the resulting forecast transactions viewed or edited in Forecast Entry:
Epicor ERP | 10.2.700 21

Refer to Order Transactions Generated from Inbound EDI Demand and Forecast Transactions Generated
from Inbound EDI Demand for more details.
Generate 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.2.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.2.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.2.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:
1. Verifying prerequisite installations, including:

• Verifying you have completed the TIE KINETIX Planning Documentation.
Epicor ERP | 10.2.700 25

• 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:
3. Performing post-installation steps, including reviewing EDI file layouts, configuring Demand Management
for EDI inbound and outbound EDI automatic generation.
26 Epicor ERP | 10.2.700

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.2.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 unfirm schedules should be included in demand management lead
time checking logic for this company. Select this check box to include unfirm schedules in demand management
lead time checking logic for this company. Clear the check box to exclude unfirm 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.2.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.
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
Epicor ERP | 10.2.700 29

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 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.2.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.2.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.
Customer Maintenance
When using EDI to receive and send electronic transactions, customers are identified in inbound and outbound
EDI transactions by trading partner identification numbers. In the Epicor application, you assign and associate
trading partner identification numbers with specific customer records established in Customer Maintenance.
• Use the Customer > Demand sheet to assign a trading partner identification number and define demand
processing parameters for a specific customer.
This includes specifying the lead times required to evaluate and process certain types of action requests (adding
new demand schedule lines, changing or cancelling existing demand schedule lines) on incoming EDI shipping
schedules received from your customer. For each request, you specify the actions that should take place in
the Epicor application (stop transaction or display a warning message) when incoming EDI transactions are
received with insufficient lead times with respect the parameters you have specified for that type of transaction.
• Use the Customer > Documents sheet to define the processing parameters for inbound EDI documents you
accept from this customer trading partner when sent to you, and the outbound documents you generate and
then send back to the customer trading partner via EDI.
32 Epicor ERP | 10.2.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.
Customer > Demand
Use the Customer > Demand sheet to assign a trading partner identification number and define demand
processing parameters that specify how the Epicor application should evaluate incoming EDI shipping transactions
received from your customer.
Epicor ERP | 10.2.700 33

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.
Note For additional information about customer demand lead time parameters, refer to the Customer
Maintenance > Demand - Lead Time Parameters topic in the EDI / Demand Management
Troubleshooting section.
The following section describes the Customer Maintenance values you can change.
Menu Path
• Financial Management > Accounts Receivable > Setup > Customer
• Financial Management > Deferred Revenue Accounting > Setup > Customer
• Financial Management > Multi-Site > Setup > Customer
• Production Management > Material Requirements Planning > Setup > Customer
• Sales Management > Customer Relationship Management > Setup > Customer
• Sales Management > Demand Management > Setup > Customer
• Sales Management > Order Management > Setup > Customer
• Sales Management > Quote Management > Setup > Customer
• Service Management > Field Service > Setup > Customer
• Service Management > Field Service Automation > 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.
34 Epicor ERP | 10.2.700

• 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 in Delivery Days Calculation check
box for the associated company in the Company Configuration > Modules > Sales > Demand sheet.
• If the Consider Working Days in Delivery Days 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.
• 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 in Delivery Days 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.
Epicor ERP | 10.2.700 35

• 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 - Designates the default calculation method used to generate Need By and Ship By dates on each
order release schedule for this customer trading partner.
• Ship By - Creates Need By Dates based on Ship By dates; these are the dates on which this customer
trading partner needs to receive the quantity listed on a demand schedule.
Logic Need By Date = Ship By Date + Delivery Days
• Need By - Generates the Ship By dates needed on each schedule entry for this customer trading partner.
On each release, the Need By date field also uses this same date.
Logic Ship By Date = Need By Date - Delivery Days, optionally factoring in customer periodicity
settings defined in Customer Periodicity Maintenance when calculating the final Ship By Date.
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.
Note For a detailed explanation of how the Ship By and Need By dates are calculated for a demand
schedule, refer to the Demand Entry > Schedule > Detail field help.
• 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 table. 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 Flowchart A: Demand Management / Order Management Pricing 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 table. 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.
• 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.
36 Epicor ERP | 10.2.700

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

• Tolerance - If the Unit Price Difference check box has been selected, specify the allowable price difference
tolerance percentage, if any, for this customer trading partner. For example, enter 10.50 into this field for a
10.5% tolerance.
$2.00. If you set the Tolerance field to 10.00, the Epicor application would accept a unit price minus
10% of the internal price. In this example, it would consider $1.90 as an acceptable price, because
would be within 10% of the $2.00 internal price. Conversely, it would not consider $1.75 or $1.50
acceptable prices, because they are outside of the 10% tolerance range (from $1.80 to $2.00).
• Action (Unit Price Difference) - If the Unit Price Difference check box has been selected, specify the action
that should take place (when you run the Process Demands selection on the Demand Entry Actions menu) if
there is a difference between the current unit price in your Epicor application database and the unit price in
an incoming EDI file received from this customer trading partner:
• Stop - Designates that inbound demand received from this customer trading partner should not be accepted
and processed if there is a difference between the current unit price in your Epicor application database
and the unit price in the inbound EDI file.
The Epicor application marks the demand line as System Rejected in Demand Entry; however, you can
manually accept the incoming demand by selecting the Override System Reject check box if you wish.
This allows you to designate that the demand schedule/line/demand header can be processed to generate
an order or forecast in the Epicor application. Error messages appear on the Demand Log (on the Demand
Entry Actions menu) or on the Demand Review Report, explaining why the Epicor application rejected and
did not process the demand.
• Warning - Designates that inbound demand received from this customer trading partner should be
automatically accepted and processed even if there is a difference between the current unit price in your
Epicor application database and the unit price in the inbound EDI file. Warning messages display on the
Demand Log or on the Demand Review Report informing you that the incoming demand contains differences
in unit pricing from your current price.
• Check For Part - Specifies if the Epicor application should validate if corresponding part records exist in your
Epicor application database for inbound demand received from this customer trading partner. Using the Check
For Part check box, you can choose to perform this part number validation for this customer trading partner,
or skip the validation.
Refer to Flowchart B: Demand Management Part Validation Processing 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:
and processed if it contains a part number for which a corresponding part record does not exist within
your Epicor application database.
38 Epicor ERP | 10.2.700

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

• Action (Check For Run Out Part) - If the Check For Run Out 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 part records on inbound demand received from this customer trading partner have been designated
as run out parts or has been placed on hold in your database:
and processed if it contains a part number that is designated as a run out part within your Epicor application
database.
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 that has been designated as a run
out part 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 that has
been designated as a run out part.
Note Incoming demand for parts placed on hold within your Epicor application database are never
processed into sales orders. These are parts for which the Hold check box has been selected, and
a hold reason and hold date have been entered in the Part Maintenance > Part > Detail sheet.
• 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.
and processed if demand schedule entries have been matched against sales order releases with partial
shipments.
wish. This allows you to designate that the demand schedule/line/demand header can be processed to
generate an order or forecast in the Epicor application. Error messages appear on the Demand Log (on
the Demand Entry Actions menu) or on the Demand Review Report, explaining why the Epicor application
rejected and did not process the demand.
automatically accepted and processed even if demand schedule entries have been matched against sales
order releases with partial shipments. Warning messages display on the Demand Log or on the Demand
Review Report informing you that the incoming demand has been matched against sales order releases
with partial shipments.
40 Epicor ERP | 10.2.700

• 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
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.
wish. This allows you to designate that the ED transaction can be processed in the Epicor application. Error
Epicor ERP | 10.2.700 41

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 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
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.
42 Epicor ERP | 10.2.700

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

• 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
• 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.
44 Epicor ERP | 10.2.700

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
• Check Date (Capable to Promise) - Specifies if the Import EDI Demand Process should execute Capable to
Promise processing for demand orders received from this customer trading partner.
• Select the check box if the Import EDI Demand Process should execute Capable to Promise processing for
demand orders received from this customer trading partner. You must use the accompanying fields in the
Capable to Promise pane to specify:
• the exact type of dates (Ship By, Need By, or Both) that should be validated.
• the action that should be taken by the Epicor application when the designated CTP dates calculated
by Capable to Promise are later than the corresponding (Ship By or Need By) dates on demand schedules
for this customer trading partner.
• if dates on demand schedules should be updated with calculated CTP dates when CTP processing is
performed on demand orders for this customer trading partner.
• Clear the check box to skip CTP processing for this customer trading partner. When you clear the check
box, you cannot access any of the other fields in the Capable to Promise pane; they are cleared and
disabled.
• If the Check Date check box is selected, you must use the accompanying unlabeled drop down field to specify
whether Need By, Ship By dates (or both) should be validated when calculating Capable to Promise for demand
orders received from this customer trading partner.
• Ship By - Capable to Promise validates Ship By dates in CTP processing. The Ship By date is the date by
which items must be shipped to arrive in time to meet the Need By date specified by the customer trading
partner.
When Capable to Promise 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 Ship by
date, the Epicor application performs the action (Stop or Warning) specified in the Action field.
• Need By - Capable to Promise 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.
Epicor ERP | 10.2.700 45

When Capable to Promise 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.
• Both - Capable to Promise validates both Ship By and Need By dates in CTP processing.
When Capable to Promise runs, it compares the actual Ship By and Need By dates on the demand schedule
to the calculated CTP Ship By and Need By dates. If both the calculated CTP Ship By and Need By dates
are later than the demand schedule Ship By and Need By dates, the Epicor application performs the action
(Stop or Warning) specified in the Action field.
Note You cannot access this field if the Check Date check box has been cleared.
• Action (Capable to Promise) - If the Check Date check box has been selected, you must specify the action
that should be taken by the Epicor application when the designated dates calculated by Capable to Promise
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) dates calculated by Capable to Promise 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) dates calculated by Capable to Promise 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.
• Update Dates (Capable to Promise) - Specifies if CTP dates calculated by Capable to Promise should replace
the Need By or Ship By dates on demand schedules for this customer trading partner.
• Select the check box if Capable to Promise 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.
• Clear the check box if Capable to Promise should skip updating of the Need By or Ship By dates on demand
schedules for this customer trading partner. If you clear this check box, the accompanying field cannot be
accessed; it is cleared and disabled.
Note You cannot access this check box if the Check Date check box has been cleared.
If the Update Dates check box is selected, you must use the accompanying drop down list to specify whether
Capable to Promise should update Need By, Ship By dates, or both, in demand schedules with calculated CTP
dates when it performs CTP processing for demand orders received from this customer trading partner.
• Ship By - Capable to Promise should update Ship By dates in demand schedules with calculated CTP Ship
By dates. The Ship By date is the date by which items must be shipped to arrive in time to meet the Need
By date specified by the customer trading partner.
• Need By - Capable to Promise should update Need By dates in demand schedules with calculated CTP
Need By dates. The Need By date is the date by which the customer trading partner requires delivery of
part quantities.
• Both - Capable to Promise should update Ship By and Need By dates in demand schedules with calculated
CTP Ship By and CTP Need By dates.
46 Epicor ERP | 10.2.700

Note In all cases, the Epicor application performs demand schedule date updates only when the
calculated CTP dates are later than the actual demand schedule dates.
Note You cannot access this field if the Check Date or Update Dates check boxes have been cleared.
Note In all cases, the Epicor application performs demand schedule date updates only when the
calculated CTP dates are later than the actual demand schedule dates.
• Split Demand (Capable to Promise) - Specifies if a demand schedule for this customer trading partner
should be split when the Capable to Promise calculation indicates 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.
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 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).
Epicor ERP | 10.2.700 47

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 Flowchart C: Part Lookup and UOM Determination for a graphical flowchart of this
process.
• 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.
48 Epicor ERP | 10.2.700

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 the Import
EDI Demand Process references when it retrieves this inbound EDI document from, or sends to this outbound
document through TIE KINETIX or another EDI application.
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.
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 ERP | 10.2.700 49

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

• 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
and subsequent sales order and forecast entries despite the error condition.
Refer to the Customer Maintenance > Customer > Demand section for more details on error conditions
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.
• 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.
Epicor ERP | 10.2.700 51

Refer to Inbound EDI Transaction File Mappings for more details.
• Accept If No Errors - The Epicor application should automatically process demand for this customer
trading partner only if there are no errors in the inbound EDI document. This eliminates the need to
manually use the Process selection in the Demand Header section of the Demand Entry Actions menu to
process the demand.
In the case of inbound EDI transactions, this automatically creates demand entries in the Epicor application
and immediately generates sales order and forecast entries at the time an error-free inbound EDI
file is successfully processed. This eliminates the need to manually use the Process selection in the Demand
Header section of the Demand Entry Actions menu.
In cases where the inbound EDI transaction does contain errors (for example, a Date Change action
request is received with insufficient lead time), the Epicor application handles in the normal manner - it
applies Stop (with System Rejection) or Warning conditions, depending on the settings for the customer
trading partner in the Customer Maintenance > Customer > Demand or Ship To > Demand sheets. It does
not immediately generate sales order and forecast entries in these situations.
Refer to the Customer Maintenance > Customer > Demand section for more details on error conditions
• Manually Accept - Demand from this incoming document for this customer trading partner should only
be manually processed. In this case, the Epicor application 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):
52 Epicor ERP | 10.2.700

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

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

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.
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 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.
Epicor ERP | 10.2.700 55

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.
56 Epicor ERP | 10.2.700

Outbound EDI Report Formats
To define outbound EDI report formats, you must do the following:

• Use the Report Data Definition program 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.
• In Report Style Maintenance, use the Generate EDI Definition action from the Actions menu to manually
create an create a definition file for the EDI report based on the Report Data Definition. You can then modify
the file using Microsoft Excel. In Microsoft Excel you can adjust the order of the columns as well as exclude
any unwanted columns from the definition file which will then be used to generate the EDI report. The
definition keeps the output of the EDI report consistent even if the Report Data definition is updated.
• 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).
• 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)
Epicor ERP | 10.2.700 57

Create Report Data Definition
Report Data Definition 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 tracks 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.
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.
58 Epicor ERP | 10.2.700

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 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.
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:
Epicor ERP | 10.2.700 59

• 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.
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.
60 Epicor ERP | 10.2.700

Associate Report Data Definition with a Specific Document Type
Once you have duplicated an existing report data definition (for example, EDIPckSl) in Report Data Definition,
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 Definition) 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).
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
Epicor ERP | 10.2.700 61

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 Definition (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:
• 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.
62 Epicor ERP | 10.2.700

• 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:
The following is an example of EDI-compatible report styles that would be associated with Invoices in Report
Style Maintenance. The Epicor application uses them to generate document records that support outbound EDI
810/INVOIC (AR Invoice) transactions:
Epicor ERP | 10.2.700 63

64 Epicor ERP | 10.2.700

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
• Output EDI - Specifies the type of output (for example, Plain or XML File) that should be created when the
Epicor application generates the EDI document record when this report style is selected. You select an output
file type based on the mappings that will be used by TIE KINETIX eVision to create the actual EDI raw data.
• Plain Text - Specifies that the EDI output for this report style should be generated in plain text format
and stored in a .txt file, similar to the following:
Epicor ERP | 10.2.700 65

• XML File - Specifies that the EDI output for this report style should be generated in XML format and stored
in a .XML file. XML file formats contain the same output as in a plain text file, but in a more sophisticated
output complete with XML tags and associated schema, but are generally far larger than standard text files.
• Company List - Specifies the companies for which this is a valid report style. Select the Valid check box in
this grid if this is a valid report style for the corresponding company.
• Default - Indicates that this style is the default should be used when you print this form/report for the listed
company. Only one style can be selected as the default for a company.
66 Epicor ERP | 10.2.700

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:
Epicor ERP | 10.2.700 67

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:
Auto Print Outbound EDI
Once you have associated report data definitions with specific type of documents in Report Style Maintenance,
you use Data Directives Maintenance to set up Auto Printing. You do this by creating Standard data directives.
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 Acknowledgments)) 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 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.
A standard data directive does 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
68 Epicor ERP | 10.2.700

Modify these values 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
Acknowledgment) 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 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.
Epicor ERP | 10.2.700 69

Define the Condition
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.
3.
Click the Condition icon, then click the New icon ( ) in the Condition pane.
4. Using the down arrow, select 'The specified field has been changed from any to another expression'.
5. Click the first specified clause in the selected expression to access the Select Table Field(s) window.
70 Epicor ERP | 10.2.700

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.
7. To select it, select the check box to the left of the field number, then click OK.
After you select the EDIReady field, the expression now reads as 'The ttShipHead.Ready field has been
changed from any to another expression'.
8. Click the any link. In the Specify a Value window, clear the Any value check box, and from the Value
drop-down list, select False.
9. Click the another link. In the Specify a Value window, clear the Any value check box, and from the Value
drop-down list, select True.
10. When you finish defining the conditional expression, it reads as follows:
Tip To enable auto-generation of other outbound EDI files, use the following conditions:
• EDI 856 (Order Acknowledgments): The ttOrderHed.EDIReady field of the added row is equal
to the true expression.
• EDI 855 (ASN): The ttShipHead.EDIReady field has been changed from False to True.
• EDI 810 (Invoice): The ttInvcHead.EDIReady field has been changed from False to True.
Epicor ERP | 10.2.700 71

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.
72 Epicor ERP | 10.2.700

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 the left (True) 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.
2. Click the Auto Print icon.

The following expression appears in the Actions pane:
• 'Automatically print specified report with specified options with rule'
3. Click the first specified clause in the expression.
Epicor ERP | 10.2.700 73

The AutoPrint Report Search window displays.
4. From the Report Type drop-down list, select Outbound EDI.
5. Click Search.
6. Select the Packing Slip report and click OK. You return to the BPM Workflow Designer.
7. Now click the second specified link.

The Setup Auto Print window displays.
8. In the Report Options sheet, enter the following:
a. In the Run Schedule field, select Immediate.
b. In the Print Action field, select Auto Preview to display the outbound EDI transaction in a preview
window, or select Auto Print to process the outbound EDI transaction.
c. Click Apply.
9. Select the Report Parameters sheet.
10. Define the following parameter:
a. Select the grid line with PackNum listed in the Parameter Name column.
b. Click the down arrow to the right of 'The 0 constant.
74 Epicor ERP | 10.2.700

c. Select 'The specified table and field value'.
d. Now click specified to access the Select Table Field(s) window.
The Select Table Field(s) window displays the fields associated with the temporary ShipHead table.
e. Enter pack into the Fields field to find the PackNum field.
f. To select it, select the check box to the left of the field number, then click OK.
Epicor ERP | 10.2.700 75

g. After you select the PackNum field, the action expression now reads as follows.
11. Click Apply, then click OK to return to the BPM Workflow Designer.
12. Now click the with rule link.

The Execution Rule window displays. Use the options on this window to determine how rows will update
for a selected table.
13. Verify both the For each matching radio button option and the ttShipHead temporary table are selected.
14. Click OK.
15. The BPM Workflow Designer displays the completed Auto Print action expression; do the following:
76 Epicor ERP | 10.2.700

a. Click Validate to validate the completed Auto Print action expression.
b. Click Save and Exit to return to Data Directive Maintenance.
16. Data Directives Maintenance displays the graphical workflow you just designed; to enable the workflow,
do the following:
a. Click Save on the Standard toolbar.
b. Select the Enabled check box.
c. Click Save again.
The Outbound EDI documents now automatically generate using the options you defined on the Auto Print
action.
For more information on how to create Auto Print data directives, review the BPM Workflow Designer topics in
the application help and the Business Process Management chapter within the Tools User Guide. For details on
how to customize reports, review the Reporting Tools chapter within the Implementation User Guide.
Epicor ERP | 10.2.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.
Enter 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.2.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.
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
Epicor ERP | 10.2.700 79

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
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.
80 Epicor ERP | 10.2.700

• 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.
• 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.
Epicor ERP | 10.2.700 81

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

• Part - Specifies the identification number for the internal part being ordered on this demand contract line.
You can enter this part number directly, or you can also click the Part button to display the Part Search
window; use this window to find and select the part you need. You can also enter (or in some cases scan)
cross reference numbers that you may have established in the following programs:
• Supplier part numbers defined in the Approved Supplier Maintenance - Supplier Parts sheet, and the
Supplier Price List - Parts - Supplier Parts sheet.
• Manufacturer's part numbers defined in the Qualified Manufacturer - Manufacturer Part sheet.
• Customer part cross references defined for the part in the Customer Part Maintenance - Detail sheet.
• Internal part cross references defined for the part in the Internal Part Cross Reference - Detail sheet.
• EAN-8, EAN-13, EAN-14, GTIN-14, UPC-12 or HIBC 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.
Epicor ERP | 10.2.700 83

• 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).
• 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.
Note If the Currency Management module is installed, Demand Contract Entry supports use of the
Multi-Currency drop-down list on the Standard Toolbar. This enables you to review the impacts of
selected base, document and reporting currencies on the valuation and pricing of a demand contract
line. To learn about this module and its functionality, refer to the topics located in the Working with
Currency Management section of the Currency Management Application Help.
• 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:
• /1
• /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 Pricing Logic - 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
84 Epicor ERP | 10.2.700

• 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
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:
Epicor ERP | 10.2.700 85

Note For additional information about demand contract matching parameters, refer to the Demand
Contract Matching Parameters topic in the EDI / Demand Management Troubleshooting section.
• 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.
• 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.
86 Epicor ERP | 10.2.700

• Clear the check box if the Epicor application should not automatically cancel all sales releases for this
demand contract that have not been matched by the Demand Schedule Matching process.
• Exclude From / From (days) - If the Cancel Non Matched check box has been selected, use the Exclude
From check box and From (days) field as needed to specify a beginning date for a grace period for cancellation
non-matched sales releases. The Epicor application will skip cancellation of non matched sales order releases
within this date range.
• If you select this check box, and then enter 2 into the From (days) field, it designates that non matched
sales order releases with ship dates between the current system date and two days earlier than the current
date will not be cancelled by the Epicor application in the event of a non match (that is, when the associated
demand schedule update request does not match any existing demand schedule releases that have already
been generated through this demand contract).
For example, if the current system date is 1/25, the Epicor application will not cancel sales order releases
dated between 1/23 and 1/25 in the event of a non-match.
• Clear this check box if you do not wish to designate a grace period for cancellation of non-matched sales
releases.
• Exclude Until / Until (days) - If the Cancel Non Matched check box has been selected, use the Exclude
Until check box and Until (days) field as needed to specify an ending date for a grace period for cancellation
non-matched sales releases. The Epicor application will skip cancellation of non matched sales order releases
within this date range.
• If you select this check box, and then enter 2 into the Until (days) field, it designates that non matched
sales order releases with ship dates between the current system date and two days earlier than the current
date will not be cancelled by the Epicor application in the event of a non match (that is, when the associated
demand schedule update request does not match any existing demand schedule releases that have already
been generated through this demand contract).
For example, if the current system date is 1/25, the Epicor application will not cancel sales order releases
dated between 1/25 and 1/27 in the event of a non-match.
releases.
• Options Available - Displays the options available to match requests for updates to existing demand schedule
releases that have already been generated through this demand contract. These are schedule update requests
received on subsequent inbound EDI transactions sent by your customer trading partner. Refer to Options
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
Epicor ERP | 10.2.700 87

reference number provided by your customer trading partner on the update requests to the reference
number it finds on existing demand schedule releases.
• Options Selected - Specifies the hierarchical order in which the Epicor application should match requests
(that are received on inbound EDI transactions sent by your customer trading partner) for updates to existing
demand schedule releases that have already been generated through this demand contract.
You construct the hierarchical processing list by selecting options displayed in the Options Available field,
and then clicking the appropriate directional buttons.
• For example, if you would want the Epicor application to first perform a Quantity match, you select
Quantity in the Options Available field, then click the single right arrow button.
• If you want it to next perform a Reference match, you then select Reference in the Options Available
field, then click the single right arrow button.
field, then click the up arrow button. For example, if Open is the fourth option listed, but you wish to
make it the second option, select it, then click the up arrow button.
• To remove a single option from the Options Selected field, select the option being removed, then click
the single left arrow button. For example, if you selected Ship By but wish to remove it, select it, then
click the single left arrow button.
• To remove all options from the Options Selected field, click the double left arrow button.
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:
88 Epicor ERP | 10.2.700

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.
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:
Epicor ERP | 10.2.700 89

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.
90 Epicor ERP | 10.2.700

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/11/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:
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:
Epicor ERP | 10.2.700 91

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

Create 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 that
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 the Import EDI Demand Process, or from
demand records manually entered into the Epicor application. In effect, the Create Demand Entries selection
reverses the Demand Processing procedure in that it creates demand records in the Epicor application from
existing sales orders.
Tip Once you have created initial demand entries for existing orders in your Epicor application database,
you would no longer use the Create Demand Entries option during ongoing EDI / Demand Management
processing. The Epicor application automatically generates demand entries for inbound EDI transactions
that have been successfully processed.
Epicor ERP | 10.2.700 93

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.2.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 Import EDI Demand Process. 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. 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!
Tip The content for the EDI / Demand Management Technical Reference Guide is updated for Service Pack
releases. For any file layout changes related to patch releases, refer to the Change List section of the
appropriate Patch Guide.
Epicor ERP | 10.2.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 the formats: 15:25 or 1525
• Unless stated otherwise in the table schematics in this section, dates must be expressed 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)
• DD - Two digit day of the month
For example, January 25, 2015 would be expressed as 20150125.
• The file formats must exactly match the sample file Sample.APP, 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.2.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 (3-0) Optional Key: Landmark. Value = UD
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)
Package Control (5-0) Optional Key: Landmark. Value = PC
Epicor ERP | 10.2.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.2.700

Demand Header Row Sample Table Schematic
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

Char(01) EDI demand interface file denotes the row ID
and type of information row.
Note Each row ID is assigned to a
specific type of inbound EDI transaction
row - each row 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
DemandDetail 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 DemandSchedule table. Refer to the
sample data in the Demand Schedule Rows
section below for more information.
• UD - User Defined information stored in the
UserData (User data for Demand Header
record), UserDetail (User Data for Demand
Detail record) or UserDemandSchedule
tables.
Epicor ERP | 10.2.700 99

Position Name
Refer to the sample data in the User
Defined Rows section below for more
information.
• PC - Package Control information stored in
the PCID (Package Control ID) table.
Refer to the sample data in the Package
Control Rows section below for more
information.
2 1 Hier_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 Hier_Prnt_Nmbr 0 (zero) for Sequential hierarchical parent row number to

H which this row is linked. This denotes that the
hierarchical parent to which it is linked is the
Mandatory,
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

Char(15) 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.
100 Epicor ERP | 10.2.700

Position Name
• This is identified in the CustNum attribute
(Data Position 8) in the Trading Partner field
in the Customer Maintenance > Customer
> Demand or Ship To > Demand sheets in
the Epicor application.
• It must also match the value of the trading
partner tied to the demand contract number
specified in the Contract_Nbr attribute (Data
Position 7).
5 FIRM Tran_Type Mandatory, Specifies the type of transaction being

Char(15) processed. The Epicor application only allows
document transaction types (assigned to the
trading partner at the header or ship to levels
in the Document ID field in the Customer
Maintenance > Customer > Document sheet)
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

Char(08) 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
the Company Maintenance > Detail sheet in the
Epicor application.
7 DALTON-CONTRACT Contract_Nbr Mandatory, Identification number for the demand contract

Char(30) associated with the EDI record.
must be a valid demand contract number,
previously entered into Contract ID field in
the Demand Contract Entry > Summary sheet
in the Epicor application.
• Refer to Entering Demand Contracts for
more details.
Epicor ERP | 10.2.700 101

Position Name
8 DALTON Cust_Nbr Mandatory, Identification number for the trading partner

Char(08) customer number associated with the EDI record.
must be a valid customer identification
number, previously established in Customer
ID field in the Customer Maintenance >
Detail sheet in the Epicor application.
9 No Value in BT_Cust_Nbr Optional, Identification number for the bill to trading

Example Char(08) partner customer number associated with the
EDI record.
• If a value appears in this data position, it
must be a valid bill to customer identification
number, previously established in Customer
ID field in the Customer Maintenance >
Detail sheet 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. Refer to Defining Trading
Partners in Customer Maintenance for
more details.
• If left blank, the default is the sold to
customer in Position 8.
10 E100500-51 PO_Nbr Mandatory, Identification number for the customer purchase

Char(50) 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.
102 Epicor ERP | 10.2.700

Position Name
11 No Value in ShipToCustID Optional, Ship to customer identification number. If a

Example Char(14) value appears in this data position, it must be a
valid bill to customer identification number,
previously established in Customer ID field in
the Customer Maintenance > Detail sheet in the
Epicor application.
If blank, the default is the sold to customer for
the trading partner.
12 P1 Ship_Code Optional, Indicates the ShipTo code for shipments

Char(14) 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.
• If a value appears in this data position, it
must be a valid ship to customer
identification number, previously established
in Ship To ID field in the Customer
Maintenance > Ship To > Detail sheet in the
Epicor application.
• A <blank> ship to references the main
customer address. This does not default to
the ship to code at the releases.
Denotes if a One Time Ship (OTS) address is

13 false UseOTS Optional,
being used.
Boolean
14 No Value in DNS_Before Optional, Earliest date before which the order cannot be
Example Date(08) shipped. Purchased items should not be shipped
prior to this date. This information is used in the
Demand Entry > Header sheet.
This date must be expressed in CCYYMMDD
format.
15 No Value in DNS_After Optional, Latest date after which the order cannot be
Example Date(08) shipped. Purchased items should not be shipped
after to this date. This information is used in the
Demand Entry > Header sheet.
format.
16 No Value in Cancel_Date Optional, Latest date by which your trading partner wishes
Example Date(08) the associated purchased items to be shipped
to prevent cancellation. Items that cannot be
shipped prior to this date should be cancelled.
Epicor ERP | 10.2.700 103

Position Name
format.
17 No Value in FOB Optional, Indicates the Free On Board (FOB) point for
Example Char(15) shipments generated from this record.
• Can be left blank, but if there is a value, it
must be defined in the FOB ID field in the
FOB Maintenance > Details sheet.
• 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
Char(04) generated from this record.
must be defined in the Ship Via ID field in
the Ship Via Maintenance > Details sheet.
19 No Value in Terms_Code Optional, Indicates the sales terms for orders generated
Example Char(04) from this record.
must be defined in the Terms field in the
Terms Maintenance > Details sheet.
20 No Value in Priority_Code Optional, Indicates the allocation priority for orders

Example Char(06) generated from this record.
must be defined in the Priority ID field in
the Priority Maintenance > Details sheet.
21 false Ship_Complete Optional, true/false - Indicates if orders generated from

Boolean this record 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
104 Epicor ERP | 10.2.700

Position Name
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).
22 Ord Comm Order_Comment Optional, Contains free form comment text for the overall
Char(1000) order.
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 free form invoice comment text for the
Char(1000) overall 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, true/false - Indicates if order based discounting

Boolean should be applied automatically or manually
triggered by the user as a menu option.
If left blank, the default value comes from the
25 false Test_Record Optional, true/false - Indicates if this row is being run in a

Boolean test mode.
26 No Value in PO_Type Optional, Indicates the purchase order type.

Example Char(30)
27 No Value in Ack_Type Optional, Type of acknowledgement expected by the

Example Char(12) trading partner.
• OutSOAck - Outgoing Acknowledgement
• OutChgRsp - Outgoing Response to Change
• OutStatus - Outbound Order Status
Epicor ERP | 10.2.700 105

Position Name
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 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.
29 false ResetCums Optional, true/false - Indicates if your customer trading

Boolean partner would like to reset the cumulative
quantities stored to-date for previous
transactions related to this demand record.
If set to true, the Epicor application resets these
cumulative quantities.
30 false ERSOrder Optional, true/false - Indicates if the resulting invoice for

Boolean this demand record should be flagged as an
Evaluated Receipt Settlement invoice.
31 false CancelPO Optional, true/false - Indicates if the customer purchase

Boolean order for this demand record should be
cancelled.
32 1 TCtrl_Number Optional, Transaction control number for the EDI message

Char(25) on which the demand was received. Used to
track the document in the EDI processor.
106 Epicor ERP | 10.2.700

Position Name
33 1 Batch_Number Optional, Batch control number for the EDI message on

Char(25) which the demand was received. Used to track
the document in the EDI processor.
34 13-03 Sched_Nbr Optional, Used as an EDI Reference of the inbound

Char(30) 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.
36 false Lock_Rate Optional, true/false - Indicates if currency rate can be

Boolean changed by the user and cannot be changed by
the Epicor application. Used with the Currency
module.
When set to true, the currency rate can be
changed by the user and cannot be changed by
37 No Value in OTSName Optional, Full customer name for the One Time Ship (OTS)
Example Char(50) drop shipment.
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 Char(50) address.
39 No Value in OTSAddress2 Optional, Second address line of the OTS drop ship mailing
40 No Value in OTSAddress3 Optional, Third address line of the OTS drop ship mailing
41 No Value in OTSCity Optional, City for the OTS drop ship mailing address.
Example Char(50)
42 No Value in OTSResaleID Optional, Resale identification number (if any) for the OTS
Example Char(20) drop ship mailing address.
Epicor ERP | 10.2.700 107

Position Name
43 No Value in OTSState Optional, State or province name for the OTS drop ship
Example Char(50) 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
Example Character address.
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 Char(20)
47 No Value in OTSPhoneNum Optional, OTS telephone number.

Example Char(20)
48 No Value in OTSContact Optional, OTS contact name.

Example Char(50)
49 false OTSSaveCustID Optional, true/false - Indicates if the OTS ID should be

Boolean saved as a customer ID.
50 false 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, Do not use; these fields are reserved for EDI
through Character custom development.
Custom10
EDI_Custom10
108 Epicor ERP | 10.2.700

User Defined Rows (Linked to Demand Header, Demand Detail and Demand Schedule
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.
Note In Release 10.1.400.12 and above, an inbound EDI transaction map can include more than 95 UD
fields; these can be imported using the Import EDI Demand Process if you have defined a BPM that is
associated with the ImportEDIonUDImport method directive. Refer to Import EDI Demand Processing and
User Hook BPMs.
Epicor ERP | 10.2.700 109

User Defined Row Sample Table Schematic
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 to

Char(02) the linked record line, and is stored in
the UserField table.
2 2 Hier_Level Mandatory, Sequential row number in the inbound

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

Numeric to which this row 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). A User
Defined row 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 through Optional, User defined Character fields.
UserChar4 Char(30)
8 - 11 No Value in Example UserDate1 through Optional, User defined Date fields; must be
UserDate4 Date(08) expressed in CCYYMMDD format.
No Value in Example
12 -13 UserDecimal1 Optional, User defined Decimal fields.
through Decimal
UserDecimal2
14 -15 No Value in Example UserInteger1 Optional, User defined Integer fields.

through Integer
UserInteger2
16 -25 Head_E10_Character01 Character01 Optional, User defined Character fields.

through Character
Head_E10_Character10
Character10
110 Epicor ERP | 10.2.700

Row Example Record Data Plug-in Field or Type Sample Record Data Element
Data Value Dictionary Name Description
Position
26 -45 0101 Number01 through Optional, User defined Number fields.

Number20 Numeric
2020
46 -65 20130909 Date01 through Optional, User defined Date fields; must be
Date20 Date(08) expressed in CCYYMMDD format.
20130910
20131231
66 -85 false CheckBox01 Optional, User defined Checkbox fields.

through Boolean
true
CheckBox20
86 -95 ShortChar01 ShortChar01 Optional, User defined Short Character field.

through Character
ShortChar10 Note In Release 10.1.400.12
ShortChar10
and above, an inbound EDI
transaction map can include
more than 95 UD fields; these
can be imported using the
Import EDI Demand Process if
you have defined a BPM that is
associated with the
ImportEDIonUDImport method
directive. Refer to Import EDI
Demand Processing and User
Hook BPMs.
Epicor ERP | 10.2.700 111

Extra Charges Rows (Linked to Demand Header and Demand Detail Rows)
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.
112 Epicor ERP | 10.2.700

Extra Charges Row Sample Table Schematic
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 Type Sample Record Data Element Description
Data Record or Dictionary
Position Data Value Name
1 EC Record_Key Mandatory, Extra Charge information related to the linked Demand

Char(02) Header or Demand Detail, which is stored in the
DemandMisc table.
2 3 Hier_Level Mandatory, Sequential row number in the inbound record (for

Numeric example, Row 3); it must be unique per file row. Used
to keep track of data lines.
3 1 Hier_Prnt_Nmbr Mandatory, Sequential hierarchical parent number to which this

Numeric row 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. If a value exists
Char(04) in this position. The value that appears in this data
position must be a valid miscellaneous charge code,
previously established in Code ID field in the
Miscellaneous Charge Code Maintenance > Detail sheet
5 Freight Ec_Desc Optional, Description of the extra charge.

Char(30)
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 charge is

Char(01) 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.
Epicor ERP | 10.2.700 113

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

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

in Example Numeric the percentage amount.
• 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_Amt Optional, If Data position 7 (Type) is set to A (Amount), this is the
Numeric 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 -19 Custom1 EDI_Custom01 Customer Do not use; these fields are reserved future EDI
through development.
Custom 10
EDI_Custom10
114 Epicor ERP | 10.2.700

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.
Epicor ERP | 10.2.700 115

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

Char(01) header, and is stored in the DemandDetail table.

Numeric example, Row 4); it must be unique per file row.
This is used to keep track of data lines.
3 1 Hier_Prnt_Nmbr Mandatory, Sequential hierarchical parent number to which

Numeric this 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

Char(50) 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.
116 Epicor ERP | 10.2.700

Position Value
5 0001 PO_Line_Nbr Optional, Your trading partner's purchase order line item
Character(20) reference number.
6 No Value in Plant (Site) Optional, Identification number for the Epicor application
Example Character ShipFrom site. This data position is normally blank.
Note Refer to Flowchart D: Demand
Management Site Code Assignment for
details on how site codes are assigned to
demand records generated from inbound
EDI transactions.
7 FIRM Tran_Type Mandatory, Specifies the type of transaction that initiated the
Char(15) demand. Will be blank 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 Mandatory, true/false - Determines if this line is being run in a

Boolean test mode.
If left blank, the default value comes from the Test
Record data position in the Header row.
9 No Value in DNS_Before Optional, Earliest date on which trading partner wishes the
Example Date(08) demand items on this line to be shipped. Purchased
items should not be shipped prior to this date. This
date must be expressed in CCYYMMDD format.
DNS_Before data position in the Header row.
10 No Value in DNS_After Optional, Latest date by which your trading partner wishes
Example Date(08) the demand items on this line to be shipped.
Purchased items should not be shipped after this
date. This date must be expressed in CCYYMMDD
format.
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
Epicor ERP | 10.2.700 117

Position Value
locate other sales order detail records that have
been created by this demand.
12 1032X050 PartNum Optional, Your internal part number used to identify the line
Char(50) 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 Char(12) 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 Char(50) 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.
118 Epicor ERP | 10.2.700

Position Value
• The same caveat about proper recognition of
customer parts in the Epicor application
(expressed in the PartNumber explanation
above) also applies to this data position.
Note The PartNum (Position 12) and CustPn
(Position 14) data positions are the key data
elements in a Demand Detail row.If
XPartNum is being used for a given
Demand Detail row, PartNum (Position
12) should not be used (and vice versa).
Using both prevents XPartNum from being
considered by the Epicor application.
15 No Value in XPartRevLevel Optional, Revision level number for the customer part
Example Char(12) 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
Char(06) is issued. If left blank, the default value comes from
the demand contract or from the Part Master
record.
18 No Value in DiscountPercent 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, true/false - Indicates if the Customer Price List

Boolean should be used for order pricing for this Demand
Detail row.
Epicor ERP | 10.2.700 119

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

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

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

Example Character partner for this demand contract line.
• OutSOAck - Outgoing Acknowledgement
• OutChgRsp - Outgoing Response to Change
• OutStatus - Outbound Order Status
26 No Value in ScheduleType Optional, Schedule type from the trading partner. Reference
Example Character only.
27 false Delete_Current Mandatory, true/false - Indicates if current open Order Releases

_Release Boolean that have not been shipped and do not have a job
should be deleted when processing the demand.
demand contract.
120 Epicor ERP | 10.2.700

Position Value
28 No Value in Mktg_Campaign_ID Optional, Link to the marketing event associated with this
Example Character record. Maintainable using Demand Entry if the
CRM module is installed.
demand contract.
29 No Value in Mktg_Event_Seq Optional, The 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 CumulativeQty Optional, Cumulative quantity that your trading partner

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

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

Example Character
38 - 47 Custom1 EDI_Custom01 Optional, Do not use; these fields are reserved future EDI
through Character development.
Custom10
EDI_Custom10
Epicor ERP | 10.2.700 121

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.
122 Epicor ERP | 10.2.700

Demand_Schedule Row Sample Table Schematic
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

Char(03) to the linked Demand Detail line. The
Epicor application stores this data in
the DemandSchedule table.
2 12 Hier_Level Mandatory, Sequential row number in the inbound

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

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

Example Character
Note Refer to Flowchart 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 Optional, Specifies the type of transaction being

Char(15) processed. The Epicor application only
allows document transaction types
(assigned to the trading partner at the
header or ship to levels in the
Document ID field in the Customer
Maintenance > Customer > Document
sheet) as valid entries in this data
position.
6 E100500-51-002-001 Demand_ Reference Optional, The Epicor application uses this for
Char(30) informational purposes and to aid in
Epicor ERP | 10.2.700 123

Position
matching demand schedules with
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

Char(06) 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 TestRecord Optional, true/false - Indicates if the line is being

Boolean used in a 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
identification number, previously
established in Customer
Maintenance in the Epicor
application. Refer to Defining
Trading Partners in Customer
Maintenance for more details.
• If left blank, the default value is the
main sold to customer, usually from
Customer data position in the
Header row.
124 Epicor ERP | 10.2.700

Position
row.
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
table in the Epicor application.
• If left blank, the default value for
schedule releases generated from
this record come from the
Ship_Code in the Header row.
true/false - Denotes if a One Time Ship

12 false UseOTS Mandatory,
(OTS) address is being used for the
Boolean
shipment.
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 MFCustNum 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
true/false - Denotes if a One Time Mark

17 false UseOTMF Mandatory,
For (OTMF) address is being used for
Boolean
the shipment.
18 BEST ShipVia Optional, Indicates the ship via method for

Character shipments generated from this record.
• Can be left blank, but if there is a
value, it must be defined in the
Ship Via ID field in the Ship Via
Maintenance > Details sheet.
• If left blank, the default value for
schedule releases generated from
this record come from the
Ship_Code in the Header row.
Epicor ERP | 10.2.700 125

Position
19 20131015 NeedByDate Mandatory, Date by which your trading partner

Date(08) needs the item to be delivered. This
date must be expressed in the format
CCYYMMDD.
row.
20 20131001 ShipByDate Optional, Date which the item needs to be

Date(08) shipped in order to meet your trading
partner's due date. This date must be
expressed in the format CCYYMMDD.
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 Mandatory, true/false - Indicates if the

Boolean DemandSchedule has been rejected by
the user.
24 false Override_System_Reject Mandatory, true/false - Indicates if the system

Boolean rejection should be overridden so the
record can be accepted.
126 Epicor ERP | 10.2.700

Position
25 No Value in Forecast_End_Date Optional, Date when this forecast is no longer

Example Date(08) considered effective. For information
purposes only. If entered, the date must
be expressed in the format
CCYYMMDD. Reserved for future use
26 No Value in Docking_Station Optional, Docking_Station defined for the ship

Example Character to address. Reserved for future use in
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 customer name for the One Time
Char(50) Ship (OTS) 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.
Char(50)
32 No Value in OTSAddress2 Optional, Second address line of the OTS address.

Example Char(50)
33 No Value in OTSAddress3 Optional, Third address line of the OTS address.

Example Char(50)
34 Miami OTSCity Optional, City of the OTS address.

Char(50)
35 Florida OTSState Optional, State or province for the OTS address.

Char(50)
36 64460 OTSZip Optional, Zip or postal code for the OTS address.
Char(10)
Epicor ERP | 10.2.700 127

Position
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 Char(20)
OTS telephone number.

39 No Value in OTSPhoneNum Optional,
Example Char(20)
234-12121
40 OTSResaleID Optional, OTS resale identification number.
Char(20)
41 Jerry OTSContact Optional, OTS contact name.

Char(50)
42 false OTSSaveCustID Optional, true/false - Indicates if the OTS ID

Boolean should be saved as a customer ID.
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 Obsolete Optional, This field is obsolete as of release

Character 10.1.300.2.
45 No Value in OTMFName Optional, Full name for the One Time Mark For
Example Char(50) (OTMF) drop shipment.
Note If UseOTMF (Data Position
mandatory entry.
46 No Value in OTMFAddress1 Optional, First address line of the OTMF drop ship
Example Char(50) mailing address.
128 Epicor ERP | 10.2.700

Position
47 No Value in OTMFAddress2 Optional, Second address line of the OTMF drop

Example Char(50) ship mailing address.
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 Char(50)
53 No Value in OTMFFaxNum Optional, OTMF fax number.

Example Char(20)
OTMF telephone number.

54 No Value in OTMFPhoneNum Optional,
Example Char(20)
55 No Value in OTMFCountry Optional, Country portion for the OTMF drop

Example Character (if shipment mailing address. If OTMF is
OTMF is not used, this field is Mandatory and must
being used) be a valid Country Code defined in the
Epicor application.
Mandatory,
Character (If
OTMF is being
used)
56 - 65 Custom1 - EDI_Custom01 Optional, Do not use; these fields are reserved

Custom10 through Character future EDI development.
EDI_Custom10
Epicor ERP | 10.2.700 129

Smart String Rows (for DemandDetail 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 Guide for more details about the use of Smart String parameters
in the Configurator.
130 Epicor ERP | 10.2.700

Smart String Row Sample Table Schematic
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.
Data Record Data Dictionary
Position Value Name
1 SS Record_Key Mandatory Smart String information related to the linked

record line, and is stored in the Smart_String table.

Numeric example, Row 13); it must be unique per file row.
Used to keep track of data lines.
3 13 Hier_Prnt_Nmbr Mandatory, Sequential hierarchical parent number to which

• 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 CVR1 23.00 Smart String Character Input parameters being passed for configured
Delrin true parts. This is the Smart String that configuration
23.00 Silver routines in the Epicor application are able to
234 convert into the inputs required to configure a
part.
Epicor ERP | 10.2.700 131

Package Control Rows (Linked to Demand Contract/Purchase Order)
If Package Control functionality is in use in the Epicor application, Package Control rows contain Package Control
ID (PCID) label values for the inbound EDI record; the row itself is linked to the associated ship to customer
number, demand contract and purchase order.
The PCID label data contained in this row creates a record that can be viewed and edited in Package Control
Label Value Maintenance.
132 Epicor ERP | 10.2.700

Package Control Row Sample Table Schematic
This is the table schematic for the Package Control row sample.
Row Example Plug-in Type Sample Record Data Element Description

Data Record Data Field or
Position Value Dictionary
Name
1 PC Record_Key Mandatory, Package Control information stored in the PCID (Package

Char(02) Control ID) table.

Numeric example, Row 14); it must be unique per file row. Used
to keep track of data lines.
3 1 Hier_Prnt Mandatory, Sequential hierarchical parent number to which this row

Numeric is linked. For PC rows, this is simply a placeholder value;
the row itself is linked to the to the associated ship to
customer number, demand contract and purchase order.
4 MfgSys Plant (Site) Optional, Identification number for the Epicor application ShipFrom
Character site. This data position is normally blank.
Note Refer to Flowchart D: Demand
Management Site Code Assignment for details
on how site codes are assigned to demand records
generated from inbound EDI transactions.
5 DALTON ShipToCustID Optional, Ship to customer identification number. If a value appears

Char(14) in this data position, it must be a valid bill to customer
identification number, previously established in Customer
ID field in the Customer Maintenance > Detail sheet in
If blank, the default is the sold to customer for the trading
partner.
Package Control ID assigned to this demand order.
6 P1 Ship_Code Optional, Indicates the ShipTo code for shipments generated from
Char(14) this record.
• This should not be left blank; the value in this position
must exist in the ShipTo table for the sold to customer
• If a value appears in this data position, it must be a
valid ship to customer identification number,
previously established in Ship To ID field in the
Customer Maintenance > Ship To > Detail sheet in
• A <blank> ship to references the main customer
address. This does not default to the ship to code at
the releases.
Epicor ERP | 10.2.700 133

Row Example Plug-in Type Sample Record Data Element Description

Data Record Data Field or
Position Value Dictionary
Name
7 1032X050 PartNum Optional, Your internal part number used to identify the line item
Char(50) part.
• It can be left blank by your trading partner if they are
providing their own (different) part number in Position
14.
• The part number that appears in this data position
does not have to exist in the Part table. If it does not
exist in the demand contract, the Epicor application
automatically creates a new contract line in Demand
Contract Entry.
• In order for the Epicor application to properly
recognize customer parts cross referenced to your
internal part number, the part validation options for
the customer document (transaction type) should be
configured properly at the header or ship to levels
using the Customer Maintenance > Documents >
Detail sheet.
• Refer to Defining Trading Partners in Customer
Maintenance for more details.
17 - 47 CustomLabel1 Label01 Optional, Package Control label values.

through Character
CustomLabel1
Label30
134 Epicor ERP | 10.2.700

Direct Inbound EDI Transaction Import
This section guides you through the process of directly importing inbound EDI transactions into Epicor ERP. These
are 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 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.
Note If the Currency Management module is installed, Demand Entry and the Import EDI Demand
Process support use of the Multi-Currency drop-down list on the Standard Toolbar. This enables you to
review the impacts of selected base, document and reporting currencies on the valuation and pricing of a
demand line.
• The Epicor application always performs price tolerance comparisons between the internal and customer
prices on demand lines at base currency. It uses the price tolerance percentage defined for the associated
demand contract in the Tolerance field in the Demand Contract Entry > Line > Detail sheet; its
default comes from the price tolerance percentage defined for the associated customer trading partner
or ship to trading partner in the Tolerance field in the Customer Maintenance > Customer > Demand
and Ship To > Demand sheets.
• To learn about this module and its functionality, refer to the topics located in the Working with
internal price.
Epicor ERP | 10.2.700 135

Schedule and Run 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.
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.
136 Epicor ERP | 10.2.700

• 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.
Use the System Agent and Complete 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.
Epicor ERP | 10.2.700 137

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.
Use the ImportEDI Log and Demand Workbench for Error Correction
When you run the Import EDI Demand Process, it produces an ImportEDI.log that lists the results of the processing
session. You can also view and resolve error conditions using the Demand Workbench, found within the General
Operations folder of the Demand Management module.
ImportEDI.log
The ImportEDI.log displays the following information:

• Time taken to retrieve the list of inbound EDI 856 transaction (.app) files that require processing.
• Time taken to import the inbound EDI 856 transaction (.app) file into IM tables.
• Time taken to generate demand records in the IM tables.
• Time taken to create demand header, demand detail, and demand schedule records in the IM tables.
• If demand orders were successfully created from the IM table records, it lists the assigned demand order IDs,
number of demand detail lines and number of demand releases created.
Demand Workbench
If erroneous data is identified during direct Import EDI Demand processing, you can correct it as required using
Demand Workbench. 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.
138 Epicor ERP | 10.2.700

Use the Errors sheets found at the Header, Line and Schedule level to identify a reason for the error.
After you identify the error, correct the value that caused the import to fail.
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.
Epicor ERP | 10.2.700 139

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

Import EDI Demand Processing and User Hook BPMs
You can use several pre-defined method directives for further manipulation of data contained in inbound text-based
EDI .app files (inbound EDI transactions) you receive from your customer trading partners that is being processed
using the Import EDI Demand Process.
If used, these method directives, which you select in Method Directives Maintenance, can be associated with
Business Process Managers (BPMs) that contain custom code, developed by technically adept personnel, for
custom processing of inbound EDI transactions in your enterprise. In Method Directives Maintenance, do the
following:
• Click the Method Code button to access the Method Search window.
• In Method Search, in the Business Object field, select DemandImportEntry.
• In the Where Method Name Starts at field, enter ImportEDI.
• Click Search.
The method directives used in Import EDI Demand processing are as follows:
• ImportEDIb4tran - If it exists, the Import EDI Demand Process runs the custom BPM code you associate with
this method directive to manipulate inbound EDI data stored in Intermediate Demand tables before the
ImportEDI routine runs and processes translations on the data.
• ImportEDIb4val - If it exists, the Import EDI Demand Process runs the custom BPM code you associate with
this method directive to manipulate translated inbound EDI data stored in Intermediate Demand tables before
the ImportEDI routine runs and performs validations on the data.
• ImportEDIpreProcessDemand - If it exists, the Import EDI Demand Process runs the custom BPM code you
associate with this method directive to manipulate validated inbound EDI data stored in the regular Demand
tables before the ImportEDI routine processes the demand data into actual sales orders or forecasts.
• ImportEDIpostProcessDemand - If it exists, the Import EDI Demand Process runs the custom BPM code you
associate with this method directive to manipulate inbound EDI data after the ImportEDI routine processes
the demand data into actual sales orders or forecasts.
• ImportEDIonUDImport - If it exists, the Import EDI Demand Process runs the custom BPM code you associate
with this method directive when more than 95 User Defined (UD) fields exist on an inbound EDI transaction
map you are importing. The ImportEDIonUDImport method directive is only available in Release 10.1.400.12
and above.
Note For details on how to create BPMs and associate them with these pre-defined method directives,
refer to Business Process Management section of the System Management Application Help.
The following flowchart graphically illustrates how and where the Import EDI Demand Process runs and uses
these method directives when processing inbound EDI files.
Note ImportEDIonUDImport is not pictured in this flowchart; it only runs if the BPM has been defined,
and when more than 95 User Defined (UD) fields exist on an inbound EDI transaction map you are importing.
Epicor ERP | 10.2.700 141

142 Epicor ERP | 10.2.700

Understanding the User Hook BPMs 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 method
directive ImportEDIb4tran exists and has BPM code associated with it. If it does, it proceeds to Step 4; if
not, it proceeds directly to Step 5.
4. If method directive ImportEDIb4tran exists and has BPM code associated with it, 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 routine in the Epicor application processes any translations contained in the data in the
Intermediate Demand tables.
6. The Epicor application determines if method directive ImportEDIb4val exists and has BPM code associated
with it. If it does, it proceeds to Step 7; if not, it proceeds directly to Step 8.
7. If method directive ImportEDIb4val exists and has BPM code associated with it, 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 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.
9. After completing all data validations, the ImportEDI 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 DemandEntry.Process Demand; if so, it proceeds to Step 10b. The associated BPM can be defined
for Pre-Processing or Post-Processing using the standard BPM functionality in the Epicor application. If
no BPM exists, it proceeds to Step 10c.
Epicor ERP | 10.2.700 143

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 method directive ImportEDIpreProcessDemand exists and has BPM
code associated with it. If it does, it proceeds to Step 12; if not, it proceeds directly to Step 13.
12. If method directive ImportEDIpreProcessDemand exists and has BPM code associated with it, 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 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 method directive ImportEDIpostProcessDemand exists and has BPM
code associated with it. If it does, it proceeds to Step 15; if not, inbound EDI demand processing is complete.
15. If method directive ImportEDIpostProcessDemand exists and has BPM code associated with it, 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.
144 Epicor ERP | 10.2.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 >
Epicor ERP | 10.2.700 145

Demand or Ship To > Demand sheets. Refer to Demand Processing Logs and Error Resolution for more
details.
• You can also override or enter new part numbers and prices as necessary; when this is done, the Epicor
application automatically updates the linked demand contract and any associated sales orders accordingly. If
the demand contract does not contain that part, the Epicor application creates a new contract line for the
new part and price. If the demand contract does contain an existing line with that part number, only the price
is updated.
• When you are satisfied with a demand schedule, you 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.
Note If the Currency Management module is installed, Demand Entry and the Import EDI Demand
Process support use of the Multi-Currency drop-down list on the Standard Toolbar. This enables you to
review the impacts of selected base, document and reporting currencies on the valuation and pricing of a
demand line.
• The Epicor application always performs price tolerance comparisons between the internal and customer
prices on demand lines at base currency. It uses the price tolerance percentage defined for the associated
demand contract in the Tolerance field in the Demand Contract Entry > Line > Detail sheet; its
default comes from the price tolerance percentage defined for the associated customer trading partner
or ship to trading partner in the Tolerance field in the Customer Maintenance > Customer > Demand
and Ship To > Demand sheets.
• To learn about this module and its functionality, refer to the topics located in the Working with
internal price.
146 Epicor ERP | 10.2.700

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, you use the Customer Maintenance > Customer > Demand and Ship To > Demand sheets 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. You also 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
Epicor ERP | 10.2.700 147

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.
148 Epicor ERP | 10.2.700

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.
Epicor ERP | 10.2.700 149

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 you run the Import EDI Demand Process, it 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.
• 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.
is received with insufficient lead time), the Epicor application handles it in the normal manner- it applies
Stop (with System Rejection) or Warning conditions, depending on the settings for the customer trading
partner in the Customer Maintenance > Customer > Demand or Ship To > Demand sheets.
• It does not immediately generate sales order and forecast entries in these situations.
150 Epicor ERP | 10.2.700

• Manually Accept - Demand from this incoming document for this ship to customer trading partner should
only be manually processed.
• In this case, the Import EDI Demand process 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.
Epicor ERP | 10.2.700 151

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
• Refer to Order Transactions Generated from Inbound EDI Demand for more details.
Package Control Label Value Maintenance
Use Package Control Label Value Maintenance to view, modify, or delete existing Package Control ID (PCID)
label values stored in the PkgControlLabelValue and PkgControlLabelValueImport tables. You can also use it to
152 Epicor ERP | 10.2.700

manually create new PCID label value records in these tables for a specific customer, ship to identifier and part
number.
The Epicor application initially creates, and later updates PCID label values stored in these tables after an inbound
EDI transaction file that contains a Package Control (PC) type row (see below) is fully processed using the Import
EDI Demand Process, or when you correct any error conditions preventing import of the inbound EDI transaction
file and the file is successfully reprocessed using the Demand Workbench.
Epicor ERP | 10.2.700 153

The PCID labeling values stored in the PkgControlLabelValue and PkgControlLabelValueImport tables reflect
customer-specific PCID labeling requirements for EDI 856/DESADV Transactions (Outbound Advance Shipping
Notice) transactions that are generated for the items they ordered on the inbound EDI transaction file. When you
process demand, the Epicor application copies the values stored in the tables, pairs them with demand records
for the specified customer/ship to/part number, and uses them to associate PCID label values with shipping
transactions generated for the ordered items. This labels each shipping transaction with the appropriate PCID
numbers requested on the inbound EDI transaction file. If you are manually creating a PC label record, enter the
PCID label values; up to 30 individual label values can be added or modified. Label values can also be deleted as
needed.
Customer
The following section describes the Package Control Label Value Maintenance values you can change.
Menu Path: Material Management > Advanced Material Management > General Operations > Package Control
Label Values
To create a Package Control label value record, click New on the Standard toolbar. To edit an existing Package
Control label value record generated by the Import EDI Demand Process from a PC type row on an inbound EDI
856 transaction, click Search (binoculars) on the Standard toolbar. In Package Control Label Value Search,
search for and select an existing PCID label value record stored in the PkgControlLabelValue and
PkgControlLabelValueImport tables.
These are the values you can modify for the sheet:
• Customer - Specifies the identifier for the customer associated with the PC label record.
• If you are manually creating a PC label record, enter the customer number for which PCID label values
should be displayed, modified or created, or click Customer to access Customer Search to search for, and
select a customer number.
• If the PC label record was generated from an inbound EDI 856 transaction, this field displays the associated
customer number and cannot be modified.
154 Epicor ERP | 10.2.700

• Ship To - Specifies the identifier for the customer ship to number (if any) associated with the PC label record.
• If you are manually creating a PC label record, enter the customer ship to number (if any) for which PCID
label values should be displayed, modified or created, or click Customer to access Customer Ship To
Search to search for, and select a customer ship to number. You can leave the field blank if you are using
the address for the associated customer as the ship to address.
customer ship to number (if any) and cannot be modified.
• Part - Specifies the identifier for the part number associated with the PC label record.
• If you are manually creating a PC label record, enter the part number for which PCID label values should
be displayed, modified or created, or click Part to access Part Search to search for, and select a part number.
The associated part description displays.
part number and cannot be modified.
• In the Label Values section, add, edit or delete specific PCID label values.
• If you are manually creating a PC label record, enter the PCID label values; up to 30 individual label values
can be added or modified.
If the PC label record was generated from an inbound EDI 856 transaction, this field displays the associated
label values. You can modify or delete them as needed.
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.
Automatic Generation
The Epicor application automatically produces the outbound EDI Order Acknowledgement file as soon as it
generates sales order release for inbound EDI demand requests received from this customer trading partner. This
takes place if the Automatic check box has been selected for Sales Order Acknowledgement document type
in the Outbound Document section in the:
• Customer Maintenance > Documents sheet (for ths associated customer trading partner) or
• Customer Maintenance > Ship To > Documents sheet (for the associated ship to trading partner).
Epicor ERP | 10.2.700 155

In this case, no manual intervention is required on the part of a user. You can use the Mass Print Sales Orders
selection (on the Demand Management Reports menu) to print automatically generated Order Acknowledgement
documents en mass.
Manual Generation
To manually generate the outbound EDI Order Acknowledgement file, you use the Print Sales Order
Acknowledgement selection on the Actions menu in Sales Order Entry.
156 Epicor ERP | 10.2.700

Resulting Outbound Order Acknowledgement Document File

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 file:
It generates and stores the Sales Order Acknowledgement document file in the destination folder designated 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 file and transmits it as an EDI 855/865/ORDRSP
Note For more details on setting generation parameters and customizing the format and contents of the
supporting report data definition, refer to the Customer Maintenance > Documents and Defining
Outbound EDI Report Formats sections.
Epicor ERP | 10.2.700 157

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, informs personnel on your
customer trading partner's receiving dock about 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 informs you
customer trading partner when order releases have been shipped from your company. The Epicor application
produces this document file 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.
(Email from Amy 8/24) The PC line maps to its very own table and only cares about Customer and Ship To in
terms of 'matching'
What will become a sales order line has nothing to do with what exists on the PC line in this mapping
Later in the PCID work flow, when containers/pallets/boxes are getting ready to be shipped, validation between
what exists on the PkgControlLabelValue table is done against PkgControHeader table and the Ship To and
Customer between the two tables must match the order being shipped (must match with order and shipping
tables).
The Epicor application automatically produces the outbound EDI ASN document file as soon as you mark a sales
order as shipped in Customer Shipment Entry or Master Pack Shipment Entry. This takes place if the Automatic
check box has been selected for Advanced Shipping Notice (ASN) document type in the Outbound Document
section in the:
In this case, no manual intervention is required on the part of a user. You can use the Mass Print Packing Slips
selection selection (on the Demand Management Reports menu) to print automatically generated ASN documents
en mass.
158 Epicor ERP | 10.2.700

Manual Generation
To manually generate the outbound EDI ASN document file, you use the Print selection on the Actions menu in
Customer Shipment Entry.
Epicor ERP | 10.2.700 159

Resulting Outbound ASN Document File

Report Style Maintenance to generate the following outbound EDI ASN packing slip document file. 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 file. The printed document
and the outbound EDI file also contain the date and time at which the ASN document was generated. The date
is in the format YYYY-MM-DD.
It generates and stores the ASN document file in the destination folder designated for outbound EDI files (for
example, c:\epicor3data\edi_data\outbound\ASNs). For the ASN Master Pack document file, it stores it in
the designated destination folder (c:\epicor3data\edi_data\outbound\MasterPack). Once either of these ASN
document files 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 file and
transmits it as an EDI 856/DESADV transaction to your customer trading partner.
160 Epicor ERP | 10.2.700

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 file 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.
The Epicor application automatically produces the outbound EDI AR Invoice file when it successfully posts the AR
invoice to the General Ledger. This takes place if the Automatic check box has been selected for Invoice
document type in the Outbound Document section in the:
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.
Epicor ERP | 10.2.700 161

Manual Generation
To manually generate the outbound EDI AR Invoice file, you use the Print Invoices selection in the Get section
of the AR Invoice Entry Actions menu.
162 Epicor ERP | 10.2.700

Resulting Outbound AR Invoice Document File

Report Style Maintenance to generate the following outbound EDI AR Invoice document file:
It generates and stores the AR Invoice document file in the destination folder designated 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 file and transmits it as an EDI 810/INVOIC transaction to your customer
trading partner.
Epicor ERP | 10.2.700 163

Demand Review Report
The Demand Review Report provides information on demand that was entered manually or imported using the
Import EDI Demand Process. This report is based on the DemandSchedule table and contains the information
that is used to update sales order releases.
You can enter demand manually or import it automatically. Once you create demand records, you can automatically
process them to create or update sales orders. During this process various validations are performed on the data.
Any records that do not pass are rejected, and you must correct them manually before resubmitting them. This
can be a time-consuming process if you are processing a large volume of data. The Demand Review Report
displays this information from the demand perspective, that is, what demand has been processed, what orders
were updated, what demand was rejected or unprocessed.
The report provides you with the following information:
• Whether demand has been processed.
• The date and time demand was processed.
• Which sales orders were updated.
• Values on the sales orders before the update.
• Whether demand was rejected during the validation process and if so, why.
164 Epicor ERP | 10.2.700

• 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:

• Information from the demand header and line plus lookup information from the part and customer records.
• 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.
• Date when the demand schedule was processed. If there is no date, it means the demand has not been
processed.
• This indicates whether the demand schedule has been posted and whether the sales order has been updated.
Epicor ERP | 10.2.700 165

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, you may need to stop a job to
manufacture a custom part 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:
166 Epicor ERP | 10.2.700

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.
Epicor ERP | 10.2.700 167

Modifiers EDI Demand Management Technical Reference Guide
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.
is received with insufficient lead time, and a Stop or Warning condition would normally be applied), the
Epicor application automatically overrides any System Rejection flags, processes the demand and
subsequent sales order and forecast entries despite the error condition.
• Refer to the Customer Maintenance > Customer > Demand section for more details on error conditions
Note The manner in which Epicor ERP handles rejections (error conditions) while processing inbound
EDI transactions depends on where the error occurs within the record:
• If it occurs at the Demand Header row level (for example, a duplicate PO error), the associated
sales order and all attached order lines/order ship schedules generated from the demand header
• If it occurs at the Demand Detail row level (for example, a price mismatch error), only the associated
order line and the attached order ship schedules generated from that demand detail row are placed
on hold.
• If it occurs at the Demand Schedule row level (for example, a lead time error), only the order ship
schedule generated from that demand schedule row are placed on hold.
Refer to Inbound EDI Transaction File Mappings for more details.
• Accept If No Errors - The Epicor application should automatically process demand for this customer trading
partner only if there are no errors in the inbound EDI document. This eliminates the need to manually use
the Process selection in the Demand Header section of the Demand Entry Actions menu to process the demand.
• In the case of inbound EDI transactions, this automatically creates demand entries in the Epicor application
and immediately generates sales order and forecast entries at the time an error-free inbound EDI
file is successfully processed. This eliminates the need to manually use the Process selection in the Demand
Header section of the Demand Entry Actions menu.
• In cases where the inbound EDI transaction does contain errors (for example, a Date Change action
request is received with insufficient lead time), the Epicor application handles in the normal manner - it
168 Epicor ERP | 10.2.700

EDI Demand Management Technical Reference Guide Modifiers
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
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
Epicor ERP | 10.2.700 169

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

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
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.
Epicor ERP | 10.2.700 171

Where Located
The Action (Change) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Action (Capable to Promise)
If the Check Date check box has been selected, you must specify the action that should be taken by the Epicor
application when the designated dates calculated by Capable to Promise are later than the corresponding (Ship
By or Need By) dates on demand schedules for this ship to 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) dates calculated by Capable to Promise 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) dates calculated by Capable to Promise 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.
Where Located
The Action (Capable to Promise) field is located on the Customer Maintenance > Customer > Demand and
Customer Maintenance > Ship To > Demand sheets.
Menu Path
172 Epicor ERP | 10.2.700


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:
and processed if it contains a part number for which a corresponding part record does not exist within your
Epicor application database.
the demand.
automatically accepted and processed even if it contains a part number for which a corresponding part record
does not exist within your Epicor application database. Warning messages display on the Demand Log or on
the Demand Review Report informing you that the incoming demand contains a part number for which a
corresponding part record does not exist within your Epicor application database.
Where Located
The Action (Check for Part) field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Epicor ERP | 10.2.700 173


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

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

received from this customer trading partner (or ship to customer trading partner) has been designated as a run
out part or has been placed on hold in your database:
• Stop - Designates that inbound demand received from this customer trading partner (or ship to customer
trading partner) should not be accepted and processed if it contains a part number that is designated as a
run out part within your Epicor application database.
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 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 (or ship to customer
trading partner) should be automatically accepted and processed even if it contains a part number that has
been designated as a run out part 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 that has been designated as a run out part.
Note Incoming demand for parts placed on hold within your Epicor application database are never
processed into sales orders. These are parts for which the Hold check box has been selected, and a
hold reason and hold date have been entered in the Part Maintenance > Part > Detail sheet.
Where Located
The Action (Check for Run Out Part) field is located on the Customer Maintenance > Customer > Demand and
Menu Path
176 Epicor ERP | 10.2.700

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

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

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

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

demand schedule quantity change requests from your customer trading partner when received with insufficient
Where Located
The Add field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance >
Ship To > Demand sheets.
Menu Path
Example
The Add field is set to five days for Company ABC. They send you a request to add a new demand schedule that
they would like shipped only four days from now. Because the demand schedule change request was received
with insufficient lead time notification, a Stop or Warning takes place, depending on the setting of the Action
(Add) field.
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.
Epicor ERP | 10.2.700 181

For example, if you have specified matching of schedule dates, order numbers and reference numbers, it is
considered a perfect match only if all of these parameters match exactly between documents. This is the
default value for this check box.
Where Located
The Allow Non Perfect Match check box is located on the Demand Contract > Header > Matching sheet.
Menu Path
• Sales Management > Demand Management > General Operations > Demand Contract Entry
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.
182 Epicor ERP | 10.2.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.
Where Located
The Automatically Match All check box is located on the Company Maintenance > Modules > Sales > Demand
sheet.
Menu Path
Epicor ERP | 10.2.700 183

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
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
184 Epicor ERP | 10.2.700

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
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
Epicor ERP | 10.2.700 185

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

Where Located
The Check Forecast Schedules check box is located on the Company Maintenance > Modules > Sales > Demand
sheet.
Menu Path
Check Date (Capable to Promise)
Specifies if the Import EDI Demand Process should execute Capable to Promise processing for demand orders
• Select the check box if the Import EDI Demand Process should execute Capable to Promise processing for
demand orders received from this customer trading partner. You must use the accompanying fields in the
Capable to Promise pane to specify:
• the exact type of dates (Ship By, Need By, or Both) that should be validated.
• the action that should be taken by the Epicor application when the designated CTP dates calculated by
Capable to Promise are later than the corresponding (Ship By or Need By) dates on demand schedules for
• if dates on demand schedules should be updated with calculated CTP dates when CTP processing is
performed on demand orders for this customer trading partner.
• Clear the check box to skip CTP processing for this customer trading partner. When you clear the check box,
you cannot access any of the other fields in the Capable to Promise pane; they are cleared and disabled.
If the Check Date check box is selected, you must use the accompanying unlabeled drop down field to specify
whether Need By, Ship By dates (or both) should be validated when calculating Capable to Promise for demand
orders received from this customer trading partner.
• Ship By - Capable to Promise validates Ship By dates in CTP processing. The Ship By date is the date by which
items must be shipped to arrive in time to meet the Need By date specified by the customer trading partner.
When Capable to Promise 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 Ship By date, the Epicor
application performs the action (Stop or Warning) specified in the Action field.
• Need By - Capable to Promise 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 Capable to Promise 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.
• Both - Capable to Promise validates both Ship By and Need By dates in CTP processing.
When Capable to Promise runs, it compares the actual Ship By and Need By dates on the demand schedule
to the calculated CTP Ship By and Need By dates. If both the calculated CTP Ship By and Need By dates are
later than the demand schedule Ship By and Need By dates, the Epicor application performs the action (Stop
or Warning) specified in the Action field.
Epicor ERP | 10.2.700 187

Where Located
The Check Date (Capable to Promise) check box and accompanying unlabeled drop down list are located on
the Customer Maintenance > Customer > Demand and Customer Maintenance > Ship To > Demand sheets.
Menu Path
Check for Part
Specifies if the Epicor application should validate if corresponding part records exist in your Epicor application
database for inbound demand received from this customer trading partner. Using the Check For Part check box,
you can choose to perform this part number validation for this customer trading partner, or skip the validation.
• Select the check box if the Epicor application should perform this validation. If you select this check box, use
the associated Action field to specify how the Epicor application should process demand schedules when
part number validations fail. By performing this validation, it helps to ensure that the Epicor application is not
accepted invalid part numbers on inbound EDI transactions received from this customer trading partner.
• If you clear the check box, all parts listed on an incoming shipping schedule are automatically included on the
shipping schedule. This lets you generate demand suggestions for parts that are "on the fly." However, by
skipping this validation, you cannot ensure that invalid part numbers on inbound EDI transactions are not
being accepted from this customer trading partner.
Where Located
The Check for Part check box is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
188 Epicor ERP | 10.2.700


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

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
Check For Run Out Part
Designates if the Epicor application must validate if part records on inbound demand received from this customer
trading partner have been designated as a run out parts, Run out parts are those you want to phase part out of
your business; they are designated as such by selecting the Run Out check box in the Part Maintenance > Part
> Detail sheet.
Select this check box if the Epicor application must perform this validation, or clear the check box to skip this
validation when importing part demand from this customer trading partner. If you clear the check box, all parts
190 Epicor ERP | 10.2.700

listed on an incoming shipping schedule are automatically included on the shipping schedule, regardless of
whether they have been designated as run out parts.
Where Located
The Check For Run Out Part check box is located on the Customer Maintenance > Customer > Demand and
Menu Path
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 Configuration > Modules > Sales > Demand
sheet.
Menu Path
Epicor ERP | 10.2.700 191

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

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.
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.
Epicor ERP | 10.2.700 193

Where Located
The Cumulative Check Discrepancies field is located on the Customer Maintenance > Customer > Demand
sheet.
Menu Path
Customer
Specifies the identifier for the customer associated with the PC label record.
• If you are manually creating a PC label record, enter the customer number for which PCID label values should
be displayed, modified or created, or click Customer to access Customer Search to search for, and select a
customer number.
customer number and cannot be modified.
Where Located
The Customer field is located on the Package Control Label Value Maintenance > Detail sheet.
Label Values
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.
194 Epicor ERP | 10.2.700

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
Date Change
Epicor application should accept Ship By or Need By date change requests for a demand schedule from this
Where Located
The Date Change field is located on the Customer Maintenance > Customer > Demand and Customer
Menu Path
Epicor ERP | 10.2.700 195


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 Need By Dates based on Ship By dates; these are the dates on which this customer trading
partner needs to receive the quantity listed on a demand schedule.
Logic Need By Date = Ship By Date + Delivery Days
• Need By - Generates the Ship By dates needed on each schedule entry for this customer trading partner. On
each release, the Need By date field also uses this same date.
Logic Ship By Date = Need By Date - Delivery Days, optionally factoring in customer periodicity settings
defined in Customer Periodicity Maintenance when calculating the final Ship By Date.
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.
Note For a detailed explanation of how the Ship By and Need By dates are calculated for a demand
schedule, refer to the Demand Entry > Schedule > Detail field help.
Where Located
The Date Type field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
196 Epicor ERP | 10.2.700


Delivery Days
Specifies the number of days required to ship a part quantity from your manufacturing center to this customer's
location. The Epicor applications uses the date interval as a buffer to calculate Ship By Dates when you use the
Need By date type (as specified in the Date Type field).
The manner in which it uses the specified delivery days factor for the delivery date calculation is dependent on
the setting of the Consider Working Days in the Delivery Dates Calculation check box for the associated
company in the Company Maintenance > Modules > Sales > Demand sheet.
• If the Consider Working Days in the Delivery Dates Calculation check box has been selected, this factor
represents actual working days. To calculate a Ship By date, the Epicor application subtracts this factor from
the Need By date designated in a demand schedule received from the ship to customer trading partner, taking
into consideration any dates that are designated as non-working days in the associated site calendar.
• The Delivery Days field is set to 5 for this ship to customer trading partner.
• When a demand schedule is received from this ship to customer trading partner with a Need By
date of 11/17/11 (a Thursday), the Epicor application subtracts five actual working days to
calculate a Ship By date of 11/10/11 (a Thursday) when generating shipping schedules (demand
entries) for this ship to customer trading partner.
• It calculates this Ship By date because Saturday 11/12 and Sunday 11/13 are both designated as
non-working days in the 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).
Epicor ERP | 10.2.700 197

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

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

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

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

Label Values (1 - 30)
In the Label Values section, add, edit or delete specific PCID label values.
Where Located
The Label Values (1 - 30) fields are located on the Package Control Label Value Maintenance > Detail sheet.
Label Values
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
202 Epicor ERP | 10.2.700

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

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

Where Located
The New Line field is located on the Customer Maintenance > Customer > Demand and Customer Maintenance
Menu Path
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
Epicor ERP | 10.2.700 205

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.
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.
206 Epicor ERP | 10.2.700

• 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
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.
Epicor ERP | 10.2.700 207

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.
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!
208 Epicor ERP | 10.2.700

Where Located
The Outbound Document field is located on the Customer Maintenance > Documents and Customer Maintenance
Menu Path
Part
Specifies the identifier for the part number associated with the PC label record.
• If you are manually creating a PC label record, enter the part number for which PCID label values should be
displayed, modified or created, or click Part to access Part Search to search for, and select a part number.
The associated part description displays.
part number and cannot be modified.
• If you are manually creating a PC label record, enter the customer ship to number (if any) for which PCID label
values should be displayed, modified or created, or click Customer to access Customer Ship To Search to
search for, and select a customer ship to number. You can leave the field blank if you are using the address
for the associated customer as the ship to address for the PC label record.
• Ship To -
• Part -
• In the Label Values section, add, edit or delete specific PCID label values.
Where Located
The Part field is located on the Package Control Label Value Maintenance > Detail sheet.
Label Values
Epicor ERP | 10.2.700 209

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
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 table. 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.
210 Epicor ERP | 10.2.700

• Internal Pricing - The internal price calculated within the Epicor application should be used to populate the
EDIUnitPrice field in the Demand_Detail table. 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
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
Epicor ERP | 10.2.700 211


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.
Ship To (Package Control Label Value Maintenance)
Specifies the identifier for the customer ship to number (if any) associated with the PC label record.
• If you are manually creating a PC label record, enter the customer ship to number (if any) for which PCID label
values should be displayed, modified or created, or click Customer to access Customer Ship To Search to
search for, and select a customer ship to number. You can leave the field blank if you are using the address
for the associated customer as the ship to address for the PC label record.
Where Located
The Ship To field is located on the Package Control Label Value Maintenance > Detail sheet.
Label Values
Split Demand (Capable to Promise)
Specifies if a demand schedule should be split when Capable To Promise (CTP) functions indicate that there is
not enough stock on hand for a part to satisfy demand. Select the check box if a demand schedule should be
split under these conditions. Clear the check box if a demand schedule should be not be split under these
conditions.
Where Located
The Split Demand check box is located on the Customer Maintenance > Customer > Demand sheet.
Menu Path
212 Epicor ERP | 10.2.700


Test Record
This check box is only used for custom programming. When selected, the data for this document will not interact
with your customer trading partner's data. This feature lets you test the document to ensure it works with your
custom program. Normally, you should leave this check box cleared.
Where Located
The Test Record check box is located on the Customer Maintenance > Documents and Customer Maintenance
Menu Path
Tolerance
If the Unit Price Difference check box has been selected, specify the allowable price difference tolerance
percentage, if any. For example, enter 10.50 into this field for a 10.5% tolerance.
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
Epicor ERP | 10.2.700 213

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
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
214 Epicor ERP | 10.2.700


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

Where Located
The Type field is located on the Customer Maintenance > Documents and Customer Maintenance > Ship To >
Documents sheets.
Menu Path
Update Dates (Capable to Promise)
Specifies if CTP dates calculated by Capable to Promise should replace the Need By or Ship By dates on demand
schedules for this ship to customer trading partner.
• Select the check box if Capable to Promise 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.
• Clear the check box if Capable to Promise should skip updating of the Need By or Ship By dates on demand
schedules for this customer trading partner. If you clear this check box, the accompanying field cannot be
accessed; it is cleared and disabled.
Note You cannot access this check box if the Check Date check box has been cleared.
If the Update Dates check box is selected, you must use the accompanying drop down list to specify whether
Capable to Promise should update Need By, Ship By dates, or both, in demand schedules with calculated CTP
dates when it performs CTP processing for demand orders received from this customer trading partner.
• Ship By - Capable to Promise should update Ship By dates in demand schedules with calculated CTP Ship By
dates. The Ship By date is the date by which items must be shipped to arrive in time to meet the Need By
date specified by the customer trading partner.
• Need By - Capable to Promise should update Need By dates in demand schedules with calculated CTP Need
By dates. The Need By date is the date by which the customer trading partner requires delivery of part quantities.
• Both - Capable to Promise should update Ship By and Need By dates in demand schedules with calculated
CTP Ship By and CTP Need By dates.
Note In all cases, the Epicor application performs demand schedule date updates only when the calculated
CTP dates are later than the actual demand schedule dates.
216 Epicor ERP | 10.2.700

Where Located
The Update Dates (Capable to Promise) check box and accompanying unlabeled drop down list are located on
the Customer Maintenance > Customer > Demand and Customer Maintenance > Ship To > Demand sheets.
Menu Path
Unit Price Difference
Specifies if the Epicor application should validate if there is a difference between the current unit price in your
Epicor application database and the unit price in an incoming EDI file received from this customer trading partner.
• Select the check box if the Epicor application should perform this validation when you run the Process Demands
selection (on the Actions menu in Demand Entry). If you select this check box, use the associated Action field
to specify how the Epicor application should process demand schedules when unit price validations fail.
• Clear the check box to skip this validation when importing part demand from this customer trading partner.
Where Located
The Unit Price Difference check box is located on the Customer Maintenance > Customer > Demand and
Menu Path
Epicor ERP | 10.2.700 217


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

Weekly Forward, Ship Day
If you selected the Weekly Forward Rules check box, select the day of the week on which shipments must
arrive to this customer.
Where Located
The Weekly Forward, Ship Day field is located on Customer Periodicity Maintenance. The Weekly Forward,
Ship Day field is located on Customer Periodicity Maintenance.
Menu Path
Epicor ERP | 10.2.700 219

EDI / Demand Management Flowcharts EDI Demand Management Technical Reference Guide
EDI / Demand Management Flowcharts
Order Management Pricing - EDI / Demand Management
220 Epicor ERP | 10.2.700

EDI Demand Management Technical Reference Guide EDI / Demand Management Flowcharts
Epicor ERP | 10.2.700 221

Part Lookup and UOM Determination - EDI / Demand Management
222 Epicor ERP | 10.2.700

EDI Demand Management Technical Reference Guide EDI / Demand Management Flowcharts
Part Validation Processing - EDI / Demand Management
Epicor ERP | 10.2.700 223

Site Code Assignment - EDI / Demand Management
224 Epicor ERP | 10.2.700

EDI Demand Management Technical Reference Guide EDI/Demand Management Troubleshooting
EDI/Demand Management Troubleshooting
If you experience issues with a program or process in this module, review the troubleshooting topics below for
a potential solution.
Error Message Log
If an issue causes an error message to display, you have several features for viewing the log details.
Error messages display in a dialog box. This dialog box has options for reviewing the logged details for the
message. To display, print, email and/or save the error message log:
1. Click the Detail button to display the error message log.

The dialog box expands, showing you the following information:
• Application Error - Displays the application error generated by the system.
• Error Detail - Contains the primary information about the error, including the Message that displays,
the Program which initiated the error, and the Method that generated it.
• Client Stack Trace - Displays the call trace that generated from your client installation.
• Inner Exception - Contains the server stack trace and the exception thrown by the system.
2. Click the Summary button to restore the original error message view.
3. Click the Print button to make a hard copy of the error message log.
The Print window displays.
4. Now print the error message log.
a. From the Name drop-down list, select printer to which you will send the application error log.
b. Click OK.
The error message log is printed on the selected printer.
5. Click the Email button to send the error details in an email.

The EMail Message window displays.
a. Type in the recipient's email address in the To field.
b. If you want to send a copy of this email to other recipients, add their email addresses into the Cc field.
c. In the Toolbar, click Send.
6. You can also copy and save the error message log to a file. To do this, in the error message dialog, click
Copy.
The error log is added to the clipboard.
Epicor ERP | 10.2.700 225

EDI/Demand Management Troubleshooting EDI Demand Management Technical Reference Guide
Note This action also adds some system information to the error log. This system information includes:
• AppServer Connection - specifies the application server address and the ERP instance - for
example, net.tcp://EpicorServer/ERP102700.
• Form Name - specifies the name of the ERP program the error occurred in - for example, Sales
Order Entry.
• Customization Name - specifies the name of the customization layer applied to the current
program, if any.
• Menu ID - specifies the menu ID of the ERP program - for example, OMMT3001.
• Software Version - specifies the ERP version - for example, 10.2.700.3.
7. Open a text editor like Notepad or a similar text editor.
8. Paste the error message log.

The error message and related system information now display in the text editor.
9. Save the error message log.
You now have an error message file you can send to your Epicor consultant or Epicor Technical Support.
Customer Maintenance > Demand - Lead Time Parameters
When defining lead times in the Customer Maintenance > Demand or Ship To > Demand sheets, there are six
settings the Epicor application uses when processing trading partner-requested changes on inbound EDI
transactions.
Schedule Level Changes

• Add - Should the Epicor application accept requests to add a new demand schedule, if the time to reach the
Ship/Need By dates for the new schedule are less than the lead time? The value entered controls the minimum
lead time that is acceptable for a new schedule.
• Change - Should the Epicor application accept change requests for an existing demand schedule, if the change
was received with a time winder that is shorter than the lead time for that item? The value entered controls
the minimum amount of lead time that is acceptable for any change to an existing schedule (not just dates,
quantities).
Note This is not the same as just changes to dates; instead, it's intended to be a check for any change
received within a too-short time-window.
• Cancel - Should the Epicor application accept cancellation requests for an existing demand schedule, if that
cancellation was received with a short time window before the expected Ship/NeedBy Date? The value entered
controls the minimum amount of lead time that is acceptable for a change to an existing schedule ahead of
a currently-planned date.
• Quantity Change - Should the Epicor application accept quantity change requests for an existing demand
schedule, if that change was received within a time window that's shorter than the lead time? The value
entered controls the minimum amount of lead time that is acceptable for a change in quantity ahead of a
currently-planned date.
• Date Change - Should the Epicor application accept Ship By or Need By date change requests for an existing
demand schedule if that change causes a time window that's shorter than the lead time? The value entered
226 Epicor ERP | 10.2.700

controls the minimum amount of lead time that is acceptable for a change in an existing currently-planned
date.
Detail Level Changes

New Line - Should the Epicor application accept a request to add a new order line to an existing demand order
if the Ship/NeedBy date is within a time window that's shorter than the lead time? The value entered controls
the minimum amount of lead time that is acceptable for the addition of a new detail line.
Example The New Line (lead time) value is five days. You add a line to a demand record that begins
shipping quantities four days from now. Because this date falls inside the defined date range, the Epicor
application causes either a Stop or a Warning to occur.
Demand Contract Matching Parameters
Use the Demand Contract Entry > 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
General Notes
In these notes, inbound EDI 856 transaction .app file rows are referred to as:
• H = Demand Header line
• D = Demand Detail line
• SCH = Demand Schedule line
• UD = User Defined line
Example Using this terminology, D.UD.ShortChar01 refers to the
DemandDetail.UserDefined.ShortChar01 field. If we are referring to the actual database table field,
we would use DemandDetail.ShortChar01.
Allow Non-Perfect Match

If you set this to true, the matching process looks for any of the options (ShipByDate, Qty, Open, Reference) to
be true in priority order, descending down the list until it finds one condition to be true. It views this as being
good enough for a match and ignores any of the proceeding options. The following matching options apply:
• ShipByDate - This is a match on the SCH.ShipByDate to OrderRel.ReqDate, either in the .app file or when
calculated by Demand Entry.
• Quantity - This is a match on DemandSchedule.Quantity to the OrderRel.SellingRequestedQty.
• Open - This considers if the OrderRel.RelStatus is equal to true for an open release, and ignores all closed
releases when trying to match.
• Reference - This considers the DemandSchedule.Demand_Reference to OrderRel.DemandReference.
Epicor ERP | 10.2.700 227

SCH.Demand_Reference Field
The following conditions apply for the SCH.Demand_Reference field:
• If you populate D.Demand_Reference but do not populate SCH.Demand_Reference, when the demand
schedules are created, they inherit the D.Demand_Reference value. This means that all schedules will have
the same SCH.Demand_Reference value.
• If the SCH.Demand_Reference is the same for all demand schedules and Reference is the only matching option
selected, matching occurs on a one-to-one basis. If you have eight demand schedules and eight order releases,
for the line, the Epicor application matches them one for one However, if you change the dates on the demand
schedules, the Epicor application still matches match one for one, and does not consider that older schedules
are gone and new ones need to be added on at the end of the order releases.
• SCH.Demand_Reference has max character limit of (X30).
• If you suddenly decide to start using SCH.Demand_Reference and begin populating this in the map, if you
already have demand entries from a prior EDI 830/850 transaction, none of the demand schedules match to
the order releases. You will need to do a manual match and process. The next time you process an EDI 830
transaction, matching is automatically attempted on the new SCH.Demand_Reference values.
Inbound EDI Transaction Errors Troubleshooting
This flowchart is a pictorial representation of the suggested processing actions you should take if the Import EDI
Demand Process encounters errors when attempting to process mapped inbound EDI transactions. For more
228 Epicor ERP | 10.2.700

details or training, contact the Epicor ERP Implementation team. For technical assistance, contact Epicor Technical
Support.
Epicor ERP | 10.2.700 229

One Time Ship (OTS) Addresses in Demand Management
Using the Import EDI Demand Process, you can pass trading partner ship to address information into the Epicor
application from inbound EDI 856 transactions (.app files) for either the order header, order release or both
(should they happen to be different). This normally relies on the existence of valid CustID and Ship_Code
(ShipToNum in the Epicor application) position values on inbound EDI 856 (.app file) transactions.
However, the case where a trading partner is adding new ship to locations (distribution centers or stores), it is
possible that the Ship_Code passed to the Epicor application has not yet been set up for the customer. In this
case, the Demand Workbench displays this as an Invalid ShipTo error. You can troubleshoot/resolve the issue by:
• Adding a new ship to number for the customer record in the Epicor application, then reprocessing the inbound
EDI 856 .app file, or
• Changing the value in the Ship_Code position itself.
Inbound EDI 856 Transaction (.app) File Definition

Another alternative is also available that allows passing of the shipping address and Ship_Code as an OTS address,
with the possibility of saving the OTS as a new ShipToNum (ship to number) for the trading partner. However,
there are several nuances and some restrictions that must be considered before deciding to use this functionality.
There are several fields that can be used to capture the OTS information on both the Demand Header (H) and
Demand Schedule (SCH) rows in inbound EDI 856 transactions (.app files). Both types of rows contain these same
fields, though they both work in the same manner, they are located in different relative positions in each row.
Note For detailed information on Demand Header and Demand Schedule rows, refer to the Inbound EDI
Transaction File Mappings section of this document.
Where the ship to number is known, the inbound EDI 856 transaction (.app) file must contain valid CustID and
Ship_Code values previously defined in the Epicor application. When an OTS is required, you must specify the
following position values appropriately in Demand Header (H) and Demand Schedule (SCH) rows in the inbound
EDI 856 .app file:
• Set CustID (Position 8 in Demand Header (H) rows) equal to a valid customer number established in Customer
Maintenance.
• Set Ship_Code equal to blank in Position 13 in all Demand Header (H) rows, and Position 12 in all Demand
Schedule (SCH) rows.
• Set UseOTS equal to true in Position 12 in all Demand Header (H) rows, and Position 13 in all Demand
230 Epicor ERP | 10.2.700

Setting UseOTS equal to true (Position 13 in Demand Header (H) rows, and Position 12 in Demand Schedule
(SCH) rows) activates the corresponding OTS fields; you must set each of these values appropriately (Positions
37-48 on all Demand Header (H) rows, and Positions 30-41 on all Demand Schedule (SCH) rows):
• OTSName
• OTSAddress1
• OTSAddress2 (optional)
• OTSAddress3 (optional)
• OTSCity
• OTSState
• OTSZip
• OTSCountry
• OTSContact (optional) - If an OTSContact value is added, and the OTS is saved, a new contact is automatically
generated in the Epicor application for the ship to number.
Note If the OTS should be saved as a new customer ship to number, the OTSSaveCustID position value
should contain a valid ship to number for the specified ShipTo. The OTSSaveAs position value must also
be correctly set to T (this is the only value applicable for demand if a new ship to number is required).
Notes and Considerations

When you use this solution, the following notes and considerations should be taken into account:
1. If the sales OTS address is required on the order header or order release, the UseOTS position value must
be equal to true in Demand Header (H) and Demand Schedule (SCH) rows, and identical information must
be filled in in the OTS Address rows.
• If this is not done (for example, only the Demand Header (H) row has all the OTS information, when the
sales order is created,the ShipTo on the associated order releases are set to the blank default ShipTo
generated when you first create the customer record in the Epicor application.
• The reverse is true if only set on the Demand Schedule (SCH) row.
2. It is not possible to set the OTS information on both the Demand Header (H) and Demand Schedule (SCH)
rows, and ask both to be saved as a ship to number in the Epicor application. In this case, the Demand
Workbench displays a "ShipTo already exists for this Customer" error message; the following occurs:
• The OTS information found in the Demand Header (H) row automatically generates a ship to number in
the Epicor application when the demand entries are processed to a sales order.
• The OTS information found in the Demand Schedule (SCH) row processes after the OTS information in
the Demand Header (H) row has been processed. If it tries to save the OTS address information as a new
ship to number, a conflict results if it already exists.
Epicor ERP | 10.2.700 231

• This also creates a sales order in the Epicor application, but the order release has a zero quantity, and
the ShipTo information is incorrect (the order release was only partially created)
3. Logic would then state that setting the Demand (H) row to create the ship to number from the OTS values,
and then populate this value on the Demand Schedule (SCH) row as the Ship_Code when it is processed
after the H line. This will not work either because Ship_Code in the SCH row is evaluated when the .app
file is processed as a demand order, but only the OTS address in the H creates the new ship to number when
a demand entry is processed to a sales order. This is a timing issue.
4. The same issues as 2 (Conflict) and 3 (Timing) are encountered if there are multiple demand schedules to
be processed.
5. When using OTS, the Mark For or One Time Mark For positions also need to be populated in the .app
file.
The outcome of this review is that while it is possible to save OTS addresses as new ship to number records for
a customer record in the Epicor application, it is only applicable under certain circumstances without significant
UserHook BPM and Data Directive BPM creation.
Scenario 1 - No OTS Saved

OTS values do not need to be saved as a new ship to number record in the Epicor application. Do the following
in the inbound EDI 856 .app file:
• Set UseOTS equal to true in Position 13 in all Demand Header (H) rows, and Position 12 in all Demand
• Fill in the required OTS address information in Positions 37-48 on all Demand Header (H) rows, and Positions
30-41 on all Demand Schedule (SCH) rows.
• Do not set values for OTSSaveCustID (Position 49 on Demand Header (H) rows, and Position 42 on Demand
Schedule (SCH) rows) and OTSSaveAs (Position 50 on Demand Header (H) rows, and Position 43 on Demand
Schedule (SCH) rows).
Scenario 2 - OTS Saved (Proposed)

This requires custom development of UserHook and Data Directive BPMs to overcome the conflict and timing
issues.
232 Epicor ERP | 10.2.700

Epicor ERP | 10.2.700 233

Index EDI Demand Management Technical Reference Guide
Index
A demand entries generated from inbound edi transactions 145
demand header row table schematic 99
accept type 168 demand header rows (demand header record for demandhead
action (add) 169 table) 98
action (cancel) 170 demand management part validation processing flowchart 223
action (capable to promise) 172 demand management pricing flowchart 221
action (change) 171 demand management site code assignment flowchart 224
action (check for part) 173 demand processing logs and error resolution 147
action (check for revision level) 175 demand schedule rows table schematic 122
action (check for run out part) 176 demand_schedule rows (demand schedule record for
action (check partial shipments) 174 demandschedule table) table schematic 123
action (cumulative check discrepancies) 177 direction 199
action (date change) 178
action (new line) 179
action (quantity change) 180
E
add 181 edi / demand management base components overview flowchart
allow non perfect match 181 11
allow shipments for orders on hold 182 EDI / Demand Management base concepts 11
alt trading partner 182 edi / demand management troubleshooting 225
auto print outbound edi 68, 69, 70, 73 edi 810/INVOIC transactions (outbound invoices) 161
automatically match all 183 edi 855/865/ORDRSP transactions (outbound order
acknowledgements) 155
C edi 856/DESADV transactions (outbound advance shipping
notices) 158
cancel 184 edi file requirements and formatting rules 96
cancel non matched 184 electronic data interchange (edi) 12
cancel schedules action 185 entering demand contracts 78
change 186 error message log 225
check date (capable to promise) 187 evision 14
check for part 188 example 181, 184, 186, 196, 205, 212, 218
check for revision level 190 exclude from / from (days) 199
check for run out part 190 exclude until / until (days) 200
check forecast schedules 186 extra charges rows (linked to demand header and demand detail
check partial shipments 189 rows) 112
check unfirm schedules 191 extra charges rows table schematic 113
close rejected schedules 192
company configuration maintenance 27
consider working days in the delivery dates calculation 193
F
creating demand entries for existing orders 93 forecast transactions generated from inbound edi demand 151
cumulative check discrepancies 193
customer maintenance > demand - lead time parameters 227
customer periodicity maintenance 30 H
header > matching sheet 85, 88, 91
D hold orders for review 200
how it is organized 10
daily, include saturdays and sunday shipments 195
daily, rules 194
date change 195 I
date type 196
defining outbound edi report formats 57 import folder 201
defining trading partners in customer maintenance 32 inbound edi transaction file mappings 95
delivery days 197 intended audience 9
demand contract matching parameter notes 228 introduction 9
demand detail rows (demand detail record for demanddetail
table) 115
demand detail rows table schematic 116
234 Epicor ERP | 10.2.700

EDI Demand Management Technical Reference Guide Index
L R
line > detail sheet 82 record hierarchy for inbound edi files 97
log, error message 225
logic/algorithms 192, 198, 201
S
M setup components 24
smart string row table schematic 131
map id 202 smart string rows (for demanddetail table) 130
modifiers 168 split demand 212
monthly forward, first day ship 204
monthly forward, rules 203
monthly forward, week number in the month 204
T
test record 213
N Tolerance 213
trading partner 214
new line 204 troubleshooting 225, 227, 228, 230, 233
nth day of the week, day of the week shipment 206 customer maintenance > demand - lead time parameters
nth day of the week, rules 205 227
demand contract matching parameter notes 228
troubleshooting inbound edi transaction errors flowchart
O 230
options available 206 using one time ship (ots) addresses in demand management
options selected 207 233
order management pricing flowchart 222 troubleshooting inbound edi transaction errors flowchart 230
order transactions generated from inbound edi demand 149 type 215
outbound document 208 typical edi / demand management processing flow 17
P U
package control row table schematic 133 unit price difference 217
package control rows (linked to demand contract/purchase order) update dates (capable to promise) 216
132 user defined row table schematic 110
part, part lookup and UOM determination flowchart 222 user defined rows (linked to demand header, demand detail and
periodicity 210 demand schedule rows) 109, 112
Pricing 210 using one time ship (ots) addresses in demand management 233
processing components 78
programs and their modifiers 151 W
purpose of this guide 9
weekly forward, rules 218
weekly forward, ship day 219
Q what is Demand Management? 15
quantity change 211 where located 169, 170, 171, 172, 173, 174, 175, 176, 177,
178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189,
190, 191, 192, 193, 194, 195, 196, 198, 199, 200, 201, 202,
203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214,
216, 217, 218, 219
Epicor ERP | 10.2.700 235

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.

Epicor10 techrefEDIDemandMgmt 102700

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Epicor10 techrefEDIDemandMgmt 102700

Uploaded by

Copyright:

Available Formats

Epicor ERP

EDI Demand Management

Epicor ERP | 10.2.700 3

Define the Auto Print Action....................................................................................................73

4 Epicor ERP | 10.2.700

EDI 810/INVOIC Transactions (Outbound Invoices)........................................................................................161

Epicor ERP | 10.2.700 5

6 Epicor ERP | 10.2.700

Exclude Until / Until (days)............................................................................................................................200

Epicor ERP | 10.2.700 7

8 Epicor ERP | 10.2.700

Purpose of this Guide

Epicor ERP | 10.2.700 9

10 Epicor ERP | 10.2.700

EDI / Demand Management Base Concepts

Epicor ERP | 10.2.700 11

What is Electronic Data Interchange (EDI)?

Supported Inbound EDI Documents

12 Epicor ERP | 10.2.700

Supported Outbound EDI Documents

Epicor ERP | 10.2.700 13

What is TIE KINETIX eVisionTM?

Inbound EDI Transactions Import

14 Epicor ERP | 10.2.700

What is Demand Management?

Epicor ERP | 10.2.700 15

16 Epicor ERP | 10.2.700

Typical EDI / Demand Management Processing Flow

Define Trading Partner in Customer Maintenance

Epicor ERP | 10.2.700 17

Enter a Demand Contract

18 Epicor ERP | 10.2.700

Process Inbound EDI Transactions

Epicor ERP | 10.2.700 19

Correct Errors Using the Demand Workbench

Automated and Manual Demand Entry Processing

20 Epicor ERP | 10.2.700

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

Epicor ERP | 10.2.700 21

Generate Outbound EDI Transactions

22 Epicor ERP | 10.2.700

Epicor ERP | 10.2.700 23

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

24 Epicor ERP | 10.2.700

Prerequisite Installation and Setup Tasks

1. Verifying prerequisite installations, including:

Epicor ERP | 10.2.700 25

26 Epicor ERP | 10.2.700

Company Configuration Maintenance

Programs and Their Modifiers

Epicor ERP | 10.2.700 27

28 Epicor ERP | 10.2.700

Epicor ERP | 10.2.700 29

Customer Periodicity Maintenance

30 Epicor ERP | 10.2.700

Programs and Their Modifiers

Epicor ERP | 10.2.700 31

32 Epicor ERP | 10.2.700

Customer > Demand

Epicor ERP | 10.2.700 33

Programs and Their Modifiers

34 Epicor ERP | 10.2.700

Epicor ERP | 10.2.700 35