Warehouse Management 9.1.0.0 Integration Transactions Overview
Warehouse Management 9.1.0.0 Integration Transactions Overview
Release 9.1.0.0
Legal notice
Rights to the content of this document
Copyright © 2005-2015 JDA Software Group, Inc. All rights reserved.
Printed in the United States of America.
Reproduction of this document or any portion of it, in any form, without the express written consent of JDA Software Group,
Inc. ("JDA") is prohibited.
These materials are protected by the Copyright Act of 1976, as amended, as an unpublished work and the foregoing notice and
legend shall not be deemed to constitute publication or an intent to publish thereunder. These materials are proprietary and
confidential information of JDA and may be disclosed and used only as authorized in a signed, written agreement controlling
such disclosure or use.
The fact that a particular name or logo does not appear on this notice does not constitute a waiver of any intellectual property
rights that JDA has established in any of its products, feature or service names, or logos.
Technical documentation
NOTICE: This design or technical documentation is supplied as a courtesy only and does not form part of the "Documentation"
as defined in your JDA license agreement. This design or technical documentation is supplied in the English language only and is
supplied "as is" and without warranties. JDA, at its discretion, may choose to offer this document in additional languages, but is
under no obligation to do so. JDA undertakes no obligation to update this design or technical documentation.
Patents
This product may be protected by one or more United States and foreign patents. Please see the JDA Patents website
(http://jda.com/JDAPatents).
Provide feedback on this document
JDA values your opinion and strives to ensure that the documentation you receive is clear, concise,
and provides the appropriate information required for you to use each JDA application efficiently.
If you would like to provide feedback on this document, you can submit your questions or suggestions
to the JDA Documentation Management team (mailto:[email protected]) and they will
be forwarded to the appropriate development teams for review and consideration in a future release.
Table of Contents
Chapter 1. Communications overview.............................................................................. 1
Standard connections and responsibilities ....................................................................... 1
Hardware connection ........................................................................................... 1
Software connection ............................................................................................ 1
External system responsibilities ............................................................................ 1
Customer responsibilities ..................................................................................... 1
Application responsibilities ................................................................................... 1
JDA responsibilities ............................................................................................. 2
Software implementation advisement .................................................................... 2
General communications concepts ................................................................................. 2
Host computer.................................................................................................... 2
Event ................................................................................................................ 2
Event Output (EO) .............................................................................................. 2
Inbound communication ...................................................................................... 2
Interface File Definition (IFD) ............................................................................... 2
Inbound IFD ....................................................................................................... 3
IFD segment ...................................................................................................... 3
Outbound communication .................................................................................... 3
Outbound IFD..................................................................................................... 3
EO segment ....................................................................................................... 3
Communication process flows........................................................................................ 3
Description of standard inbound communication ..................................................... 3
Description of standard outbound communication ................................................... 4
Inbound transaction format standards ............................................................................ 4
Common file formats ........................................................................................... 4
Valid characters .................................................................................................. 4
Inbound XML-based transactions .......................................................................... 4
Transaction elements .......................................................................................... 5
Inbound transaction types ............................................................................................ 5
Outbound transaction format standards .......................................................................... 6
Communication methods ..................................................................................... 6
Valid characters .................................................................................................. 6
Outbound XML-based transactions ........................................................................ 7
• Provide timely and accurate information transfer between the applications in an automated fashion
This chapter provides an overview of communication standards and concepts, and it illustrates the
standard process flows for both inbound and outbound communications.
Note: If you have any special communications requirements, please notify your JDA Project Team as
soon as possible. Hardware configurations other than a straight Ethernet connection are customization
options and are not described in this document.
Software connection
The application uses a store and forward file transfer method of communications for reliability,
flexibility, and simplified error recovery. The application provides configuration functions to tune and
monitor the interface. The standard installation uses transmission control protocol/internet protocol
(TCP/IP) for communications. TCP/IP is a well-established communications protocol available on many
computers and can be provided by a number of software companies. The normal TCP/IP package
(4.3BSD) includes file transfer protocol (FTP) file transfer utilities. The application uses FTP to move
information.
Customer responsibilities
Typically, customers are responsible for cabling, telephone lines, gateways, and other network
equipment to establish the communication link between the external system and the computers.
Application responsibilities
The application is responsible for preparing uploads. It is also responsible for accepting downloads in a
timely manner and in the format described in the generated integration transaction detail tables.
JDA responsibilities
Generally, JDA is responsible for any hardware or software, such as network interface cards and the
TCP/IP software package, which is part of the server.
Host computer
The primary or controlling computer in a multiple computer network. A host computer provides data,
information, and computing facilities to a distributed population of terminals.
Event
A defined occurrence in a system that triggers a transaction to be sent. Events are format neutral and
cause Integrator to gather data from the system database or from an inbound interface file definition
(IFD) for later communication.
Note: Events are not generated by the flat file communication method. Integrator does not distinguish
between inbound and outbound events. Defined events occur within JDA applications causing data to
be sent.
Note: EOs are not generated by the flat file communication method.
Inbound communication
Communication from an external system to a JDA application.
Inbound IFD
Data that is coming into Integrator from any system.
Note: Inbound IFDs are not generated by the flat file communication method.
IFD segment
Represents a portion of the entire data for the IFD. Segment data is one kind. An IFD defines the set
of fields for a record, including the position, length, and data type of each field.
Outbound communication
Communication that originates from a JDA application and is sent to an external system.
Outbound IFD
Data derived from an EO and sent from Integrator to any system. The outbound IFD is also called the
result IFD.
Note: Events are not generated by the flat file communication method.
EO segment
Represents a set of data that composes an event output. For example, for shipment completion event
output, the shipment information and the order information may be defined as different EO segments.
Note: The following process flow does not apply to the flat file communication method.
2. An adapter program identifies the IFD, the IFD segments, and each instance of the IFD. Then
Integrator determines what to do with the information, such as add, modify, or update, and then
triggers that event.
Note: Inbound data is typically sent to the application database; however, an event may also
generate an IFD to an external system.
1. A defined action, such as picking inventory, in the JDA application triggers an event.
• Sends the data to the receiving system using the assigned communication method.
• FIXED BYTE: Files in which field values contain a standard number of characters.
• XML: Files in which field values are encased in XML format code.
Valid characters
The following valid characters are accepted when receiving transactions from external systems:
• Non-XML communication: Printable ASCII characters are allowed, including alphanumeric values
such as A–Z, a–z, and 0–9.
Note: Depending on data layout, certain characters may need to be escaped. For example, a
double quote (“) must be escaped by another double quote (“ “) when using CSV data layout.
• XML communication: Characters for XML communication must follow XML standards. For
example, certain characters, like ‘<’, ‘>’, ‘&’ and so on, are escaped when used as part of data.
IMPORTANT: Be careful when using special characters such as ampersands (&), at symbols (@),
single quote characters (‘) and colons ( : ). They may be reserved characters for other programs
and processes that Warehouse Management uses.
The XML file or message specifies which inbound IFD the transaction is to use. Integrator then uses the
“meta data” definition to identify and process the transaction into Warehouse Management. Each
inbound IFD, segment and field has a unique XML tag.
The data can be a “partial” envelope of data, meaning there is no need to specify all attributes with
values within the XML envelope. The minimal requirement is to fully specify all primary key elements
for the transaction. The remaining segment attributes are optional and are handled by Integrator
differently depending upon whether the transaction is adding a new object or is changing an existing
object:
• For new object creation, Integrator either defaults or suppresses all optional attributes (which have
been omitted from the XML transaction) as specified by the resultant IFD.
• For object change, the optional attributes (which have been omitted from the XML envelope) are
simply suppressed by Integrator; that is, attributes are not passed to the Warehouse Management
components.
Transaction elements
The following transaction elements are common to all inbound transactions:
• Transaction name: Identifies the transaction being sent. Integrator refers to the inbound
transaction name, along with its corresponding version number, and then maps the inbound data
to the matching Integrator transaction.
• Transaction version: Used in conjunction with the transaction name to identify the transaction.
The transaction version does not necessarily correspond to the Warehouse Management version
number.
• Warehouse ID: Matches the native name of the system to which information is being sent. This is
optional information that can be used in multiple site systems to ensure that information is being
sent to the appropriate site.
• Segment name: Identifies a specific segment (for example, header or detail) in a transaction.
Transaction
Description Behavior
type
Additions, changes, and deletions of specific segments of
information occur on the host. Warehouse Management is
notified of these changes.
A transaction fails when the following modifications are made:
Add, Change,
A, C, D
Delete • A segment is added on the host, but the data already exists in
Warehouse Management.
• A segment is changed on the host, but the data does not exist
in Warehouse Management.
Transaction
Description Behavior
type
Similar to A, C, D, however, the transaction type R determines
whether the segment data is considered an add or a change
based on information obtained from the Warehouse
Management database.
If the transaction determines that a segment added to the host
Add, Change,
already exists in Warehouse Management, then a change
Delete, Refresh
occurs; if it determines that a segment added to the host does
Note: Refresh not exist in Warehouse Management, then an add occurs.
A, C, D, R is only
With a refresh, a complete data set for a transaction is
available on
received, and then the transaction determines whether an add,
selected
change, or delete occurs.
transactions.
Note: With a refresh, existing transaction details that are not
downloaded with a subsequent transaction can be deleted. For
example, if an order transaction is downloaded with four order
lines, and then the same transaction is downloaded again with
only three order lines, the fourth order line will be deleted.
Communication methods
A communication method defines how Warehouse Management communicates with another system.
The following examples show the communication methods that a standard Integrator to Warehouse
Management configuration can use:
• SL_IFD_TO_FILE: Creates a file in the specified directory using the designated naming
convention.
Valid characters
The following characters are valid to use when sending transactions from Warehouse Management:
• Non-XML communication: Printable ASCII characters are allowed, including alphanumeric values
such as A–Z, a–z and 0–9.
Note: Depending on data layout, certain characters may need to be escaped. For example, a
double quote (“) must be escaped by another double quote (“ “) when using CSV data layout.
• XML communication: Characters for XML communication must follow XML standards. For
example, certain characters, like ‘<’, ‘>’, ‘&’ and so on, are escaped when used as part of data.
IMPORTANT: Be careful when using special characters such as ampersands (&), at symbols (@),
single quote characters (‘) and colons ( : ). They may be reserved characters for other programs
and processes that Warehouse Management uses.
Sending systems
Warehouse Management accepts information from the following systems:
• Host computer: Business system at a Warehouse Management installation with which Warehouse
Management communicates to synchronize information to efficiently manage the activities in the
facility.
• Duty management: A duty management application that enables companies to meet the
requirements of customs authority approvals and to manage the declaration of customs duty,
excise duty and value-added tax (VAT). By moving the duty payment to the last possible point in
the supply chain, duty management integration helps you lower costs and administration effort.
• ERP Interface: JDA application that facilitates a single point of connectivity between Warehouse
Management and enterprise resource applications (ERPs) such as SAP, Oracle and PeopleSoft. All
ERP transactions are routed to/from ERP Interface, eliminating the need for Warehouse
Management, and other JDA products, to map directly to an ERP application.
• Vocollect: Voice recognition interface application that provides voice prompts to workers, such as
to pick a pallet, and accepts voice responses from workers using a voice recognition interface
device (such as a headset).
• Warehouse control system: Third-party warehouse control application that provides an interface
to automated material handling equipment, such as an automated storage and retrieval system
(ASRS), an automated guided vehicle (AGV), and other field devices such as a manufacturing
execution system (MES) or conveyor.
• Work Order and Work Order Line (Detail) Information (WO_INB_IFD): Warehouse
Management accepts both work order and work order line (detail) information from the host
computer.
• Buffer Full (BUFFER_FULL): Warehouse Management accepts buffer location information from a
WCS when the WCS manages both buffer and infeed locations. This notifies Warehouse
Management that all the locked pallets in the buffer location can be recalculated for putaway and
released to the Work Queue. When buffer locations are managed by Warehouse Management, this
transaction is not used.
• Line Setup (LINE_SETUP): Warehouse Management accepts production line information from a
WCS or MES. This notifies Warehouse Management when a work order is assigned, started, or
stopped at a production line.
• Pick Error (PICK_ERROR): Warehouse Management accepts pick error information from a WCS.
This notifies Warehouse Management that either the WCS cannot satisfy the requirements of a pick
request or is confirming the requirements of a prior pick cancel.
• Request (REQUEST): Warehouse Management accepts pallet request information from a WCS
(typically required when an anonymous pallet is identified by the WCS). This notifies Warehouse
Management that the WCS wants either pallet contents, movement information about an
anonymous pallet or both. If pallet contents are requested, Warehouse Management sends a LPN
Detail transaction. If movement information is requested, Warehouse Management sends a
Movement Request transaction. If both are requested, Warehouse Management sends the
configured inbound event transaction, typically the default Induction transaction. If the pallet in
the request transaction is not found, Warehouse Management sends a LPN Error transaction.
Accepting systems
Warehouse Management can send information to the following systems:
• Host computer: Business system at a Warehouse Management installation with which Warehouse
Management communicates to synchronize information to efficiently manage the activities in a
facility.
• Duty management: A duty management application that enables companies to meet the
requirements of customs authority approvals and to manage the declaration of customs duty,
excise duty and value-added tax (VAT). By moving the duty payment to the last possible point in
the supply chain, duty management system integration you lower costs and administration effort.
• ERP Interface: JDA application that facilitates a single point of connectivity between all JDA
products and enterprise resource systems (ERPs) like SAP, Oracle and PeopleSoft. All ERP
transactions are routed to/from ERP Interface, eliminating the need for Warehouse Management,
and other JDA products, to map directly to an ERP system.
• Track & Trace: JDA application that maintains a long-term historical repository of detailed
product shipment information. It serves as a centralized source of shipment information in
electronic format for use in product recall situations.
• Warehouse Labor Management: JDA application that is an extensive labor scheduling and
reporting solution designed to help management personnel maximize employee performance and
facility operation through improved planning, workload balancing, real-time feedback, and
productivity reporting.
• Vocollect: Third-party voice recognition interface application that provides voice prompts to
workers, such as to pick a pallet, and accepts voice responses from workers using a voice
recognition interface device (such as a headset).
• Warehouse control system: Third-party warehouse control application that provides an interface
to automated material handling equipment, such as an automated storage and retrieval system
(ASRS), an automated guided vehicle (AGV), and other field devices such as a manufacturing
execution system (MES) or conveyor.
• Inventory Scrap Work Order (INVENTORY_SCR_WO): Warehouse Management can send this
transaction to the host computer whenever a work order is closed and component inventory is
specified as scrapped or moved to a work in process supply location. This transaction is
immediately followed by the inventory move transaction to adjust the scrapped or work in process
supply inventory out of available inventory.
• Item Information (PART_OUB_IFD): Warehouse Management can send this transaction to the
host computer whenever item information is created in Warehouse Management outside of
Integrator.
• Work Order Closing (CLOSE_WKO): Warehouse Management can send this transaction to the
host computer whenever a work order is closed. This transaction balances the ordered quantity
against what was actually delivered.
• Inventory Scrap Work Order (INVENTORY_SCR_WO): Warehouse Management can send this
transaction to ERP Interface whenever a work order is closed and component inventory is specified
as scrapped or moved to a work in process supply location. This transaction is immediately
followed by the inventory move transaction to adjust the scrapped or work-in-process supply
inventory out of available inventory.
Note: All of these transactions, except for the Integrator parameter changes and warehouse subscribe
transactions, are sent only after a site subscribes to and is monitored by Inventory Visibility. The
exception transactions are sent before the site subscribes to Inventory Visibility and are used to
subscribe to Inventory Visibility.
• Work Order Close (CLOSE_WKO-LENS): Warehouse Management can send this transaction to
Inventory Visibility whenever a work order is closed.
• Inventory Holds (TL_LPN_HOLD): Warehouse Management can send this transaction to Track
& Trace whenever a hold is added to or removed from inventory.
• Work Order Deposits (TL_LINE_DEPOSIT): Warehouse Management can send this transaction
to Track & Trace whenever inventory quantity changes occur as a result of components being
delivered to a work order production location for consumption by a work order.
• Work Order Receipts (TL_LINE_RECEIPT): Warehouse Management can send this transaction
to Track & Trace whenever inventory is identified from a production line for a work order.
• Work Order Returns (TL_LINE_RETURN): Warehouse Management can send this transaction
to Track & Trace whenever component inventory is returned to stock from a production line.
• Get Put Away Records (SAL_VOI_GET_PUT_AWAY): Warehouse Management can send this
transaction to Vocollect with information on the putaway of each individual LPN.
• Get Put Away Region (SAL_VOI_GET_PA_REGION): Warehouse Management can send this
transaction to Vocollect with information on the valid regions in which the operator can perform
putaway functions.
• Get Put To Store Puts (SAL_VOI_GET_PTS_PUTS): Warehouse Management can send this
transaction to Vocollect with information on the individual put records. This transaction is sent
when the device receives a successful Get Put To Store Assignment response.
• Get Work Areas (SAL_VOI_GET_WRKARE): Warehouse Management can send this transaction
to Vocollect with information on all possible work areas for which the operator is authorized.
• Process Put To Store Puts (SAL_VOI_PRC_PTS_PUT): Warehouse Management can send this
transaction to Vocollect with confirmation that an item quantity was deposited in a put-to-store
location. If weights are captured, a separate entry is accepted for each weight captured.
• LPN Detail (LOAD_DETAIL): Warehouse Management can send this transaction to a WCS to
communicate the inventory attribute details for the pallet provided in the Request transaction.
• LPN Error (LOAD_ERROR): Warehouse Management can send this transaction to a WCS to
inform the WCS that the pallet provided in the Request transaction was not found in Warehouse
Management.
• Pick Cancel (PICK_CANCEL): Warehouse Management can send this transaction to a WCS to
request the cancellation of an outstanding pick request of inventory (can be a single pick or a
group of picks).
• Pick Request (PICK_REQUEST): Warehouse Management can send this transaction to a WCS to
request the WCS to pick inventory for an outbound order, a work order, or replenishment
(emergency, manual, top-off, demand, or trigger).
• Removal (REMOVAL): Warehouse Management can send this transaction to a WCS to request
the removal of a pallet.
• Measured Tasks (DIRECT 104): Warehouse Management can send this transaction to
Warehouse Labor Management whenever an operator performs a direct activity (measured task)
within Warehouse Management. This transaction provides detailed information about the measured
task that was performed.