Generic Inventory Transaction Upload

Purpose: Use the generic inventory transaction upload to import inventory transactions into Order Management System. Because each transaction arrives in a separate XML file, you can use this upload for either real-time updates to Order Management System, or for updates that you schedule on a periodic basis.

What types of transactions can you upload? The upload supports any type of transaction that you can process through Working with Inventory Transactions (WITI), such as transfers or adjustments. You cannot upload system transactions, such as a purchase order receipt or an issue (shipment); however, there is no restriction on user-defined inventory transaction codes, even if the code’s Allowable flag is unselected.

How do you upload the transactions? Each transaction arrives as a separate XML file, which is processed by the INVTRAN_IN process in Working with Integration Layer Processes (IJCT). You can use the INVTRAN_IN process to process transactions from any source as long as the XML files are correctly formatted and contain the required information.

Streamlined update: When you submit updates through the CWMessageIn Web Service, it processes up to 5 transactions concurrently if the target specified in the message is INVTRAN_IMMED and the transaction_code is OV. The program performs a streamlined update of the On hand quantity for the Item Warehouse and the Item Location; however, this update takes place only if the item/SKU, Item Warehouse, and Item Location already exist, and the transaction_quantity specified in the message is not less than the Reserved quantity for the Item Warehouse. Otherwise, the transaction goes through standard processing for an O (overlay) inventory transaction, including any error processing.

Processing a transaction_code of OV is available only if:

• The actual item/SKU is used, rather than the short SKU.

• There is only one existing location in the warehouse.

• There is no condition locking the Item Location for update, such as a freeze.

In this chapter:

Inventory Transaction Upload Process Overview

- Resolving the Item and SKU

- Processing Partial Quantities

- Summary of Transaction Rules

- Upload Setup Requirements

Inventory Transaction Upload XML Message (inCreateInvXaction)

- Inventory Transaction Upload Message: Sample XML

Inventory Transaction Upload Errors

Inventory Transaction Upload Process Overview

Types of transactions: Use the inventory transaction upload to process the following types of transactions:

• adjustments to on-hand quantity (A)

• item-to-item transfers (G)

• make up kits (M)

• overlay on-hand quantity (O)

• transfers (T)

• returns to vendor (V)

• user-defined transaction codes, including the Inventory Transaction Code for ’Sync’ Processing (I85)

See the Summary of Transaction Rules for more information.

You cannot use the upload to process system transactions, which include:

• issues (I)

• purchase order receipts (R)

• customer returns (C)

• express bill (E)

Additionally, if you use FIFO costing, you cannot process O (overlay) or G (item-to-item transfer) transactions. See FIFO Costing Overview.

Inventory transaction job: The INVTRAN_IN process in Working with Integration Layer Processes (IJCT) reads each XML message received into a queue specified for the INVTRAN_IN process:

• If the transaction is in error, the job creates a record in the Item Transaction Error table. You can correct the error and reprocess it, or just delete the error record. See Inventory Transaction Upload Errors. However, if the transaction is in error because no valid company is specified, then the job does not create an Item Transaction Error record and is not available through the Work with Inventory Transaction Errors Screen.

• If there are no errors, the job processes the transaction and makes the same updates as when you process a transaction through Working with Inventory Transactions (WITI). For example, it updates:

- inventory levels in the Item Warehouse and Item Location

- Item Transaction History

What if part of the quantity is reserved? If part of the quantity required to process the transaction is currently reserved, the transaction will “unreserve” it. In this situation, the system removes any pick slip preparation that may have been applied to the order and reevaluates the order for pick slip preparation; see Preparing Orders for Pick Slip Generation.

Example: The current on-hand quantity of item AB100 in the warehouse and location specified is 20, of which 11 is currently reserved for open orders. You receive an inventory transaction that has the effect of reducing the on-hand quantity to 10. One unit on an open order is unreserved, or put into backorder status, in order to reset the on-hand quantity to 10.

Note: The system does not unreserve items in order to process an M (make up kit) transaction).

What if part of the quantity is printed on a pick slip? A transaction never changes the status of a printed order line, so it might not be possible to process the entire quantity of a transaction if any units in the Item Location are printed. The allow_partial flag controls whether to process a partial quantity of a transaction for most transaction types; see Processing Partial Quantities.

Resolving the Item and SKU

The inventory transaction upload message can indicate the correct item and SKU through any one of the following:

1. item_number and sku_code: The sku_code is required if the item has SKUs, but should not be included for a non-SKU’d item. Validated against the Item and SKU tables.

2. short_sku: Validated against the Short SKU field in the SKU table.

3. retail_reference_nbr: Validated against the Reference # in the SKU table.

4. upc_type and upc_code: Both values must be specified. Validated against the Item UPC table. Note: Include any leading zeros. For example, if the UPC code is 06012011, pass 06012011 and not 6012011.

In searching for an item and SKU, the system checks the values in the message in the order indicated above. If any value (or set of values, such as item_number and sku_code) is blank, it checks the next value, such as short_sku.

Once the system finds one of the values listed above in the message, it checks the related tables to find a match. For example, if the message does not specify an item_number, but does specify the short_sku, the system checks the Short SKU field in the SKU table. If there is a match, the system continues processing the transaction. If there is no match, the system creates an item transaction error and stops attempting to resolve the item and SKU. Alternatively, if the message includes an incorrect item code and a correct short SKU, the system creates an error based on the item code; it never checks the short SKU.

For more information:

• item and SKU codes: Create Item Screen and Create SKU 1 of 2 (With Overrides) Screen

• short SKU number: Short SKU

• retail reference number: Reference #

• upc type and code: Work with UPC Codes Screen

Processing Partial Quantities

Since a transaction never changes the status of a printed order line, you use the allow_partial flag to control whether to process a partial quantity of the transaction if part of the indicated quantity is in a printed status.

Example: There are currently 20 units of item AB100 in location A010101, of which 11 are printed on pick slips. You receive an inventory transaction for an adjustment with a quantity of -10. The system cannot subtract the entire 10 units from the on-hand quantity of 20, because that would reduce the on-hand quantity below the printed quantity. If the allow_partial flag is set to Y, the system adjusts the on-hand quantity to 11 and creates an item transaction error for the unadjusted quantity of -1; if the flag is set to N, the system creates an item transaction error for the entire adjustment quantity of -10.

Basic rules: When the system cannot process the entire transaction quantity because of conflict with the printed quantity:

• If the allow_partial flag is set to Y or 1, the system processes as many units of the transaction as it can.

• If the allow_partial flag is set to N, 0 or blank, the system creates an item transaction error for the entire transaction quantity.

• Regardless of the setting of the allow_partial flag, the system never processes a partial quantity for an O (reset on-hand) or M (make up kit) transaction; instead, the system always creates an item transaction error for the entire transaction quantity.

Sample transactions:

Example 1:

Current on-hand quantity for location = 20

Current printed quantity for location = 11

Current reserved quantity for warehouse and location = 15

Inventory transaction: A (adjustment) for a quantity of -10

If allow_partial = N, 0 or blank: The system cannot process the full adjustment of -10, because that would reduce the on-hand quantity to 10, less than the printed quantity. The system creates an item transaction error of O/H LT Reserved/Printed for the full quantity of -10, and does not process any inventory updates.

If allow_partial = Y or 1: The system adjusts the on-hand quantity down by 9 and creates an item transaction error of Unable To Adjust for the remaining quantity of -1. In order to reduce the on-hand quantity, the system also unreserves 4 of the reserved units; the unreserved units are now backordered.

Example 2:

Current on-hand quantity for location = 20

Current printed quantity for location = 5

Current reserved quantity for warehouse and location= 15

Inventory transaction: A (adjustment) for a quantity of -10

In this situation, the system is able to process the full transaction regardless of the setting of the allow_partial flag. The on-hand quantity is reset to 10, and 5 units are unreserved. No item transaction error occurs.

Summary of Transaction Rules

The inventory transactions that you can upload are summarized in the following table.

Transaction

Code

transaction_quantity

Partial Quantities?

Guidelines

Adjustment

A

either positive or negative

allowed

Complete just the Transaction element.

Positive quantity: increases on-hand.

Negative quantity: decreases on-hand.

Item-to item transfer

G

positive

allowed

Complete both the Transaction and the TransactionTo elements. Decreases the on-hand quantity for the “from” item, and increases the on-hand quantity of the “to” item.

Not allowed if you use FIFO costing; see FIFO Costing Overview.

Make kit

M

positive

not allowed

Complete just the Transaction elements, specifying the kit item.

Decreases the on-hand quantity for each of the component items, and increases the on-hand quantity of the kit item.

Note: If the required quantity of any of the component items is partially reserved, the transaction will not process; the system does not unreserve a component item to make up a finished good.

Overlay (reset on-hand quantity)

O

positive

not allowed

Complete just the Transaction element.

Decreases or increases on-hand quantity, depending on whether the transaction quantity is higher or lower than the current on-hand quantity.

Not allowed if you use FIFO costing; see FIFO Costing Overview.

Transfer

T

positive

allowed

Complete both the Transaction and the TransactionTo elements. Decreases the on-hand quantity for the “from” item, and increases the on-hand quantity of the “to” item.

Return to vendor

V

positive

allowed

Complete just the Transaction element.

Decreases on-hand quantity.

User-defined: matches Inventory Transaction Code for ’Sync’ Processing (I85)

user-defined

positive

allowed

Complete just the Transaction element.

Resets the on-hand quantity to the transaction_quantity, adjusting upward or downward as necessary.

Allowed through the inventory transaction upload, even if the inventory transaction code’s Allowable flag is unselected.

User-defined: does not match Inventory Transaction Code for ’Sync’ Processing (I85)

user-defined

either positive or negative

allowed

Complete just the Transaction element.

Positive quantity: increases on-hand.

Negative quantity: decreases on-hand.

Allowed through the inventory transaction upload, even if the inventory transaction code’s Allowable flag is unselected.

Upload Setup Requirements

To process the inventory transaction upload, you need to configure the INVTRAN_IN process in Working with Integration Layer Processes (IJCT), and send an XML message to a queue specified for the job. Also, the XML message you send must conform to the layout specified under Inventory Transaction Upload XML Message (inCreateInvXaction). Any additional requirements related to batch or interactive inventory transactions must also be met.

If you will be processing sync transactions, specify the user-defined inventory transaction code in the Inventory Transaction Code for ’Sync’ Processing (I85) system control value.

If you want to store the entered_by_user in the Item Transaction History record, you should create each possible user as a user ID in Order Management System. Otherwise, the Item Transaction History record notes the user ID of the person who started the INVTRAN_IN job.

Note: Send only alphanumeric inventory transaction codes through the inventory transaction codes. Non-alphanumeric characters might not process correctly, an might cause an error.

CWMessageIn Web Service

You can use the CWMessageIn Web Service to route Inventory Transaction Upload messages. In this situation, the target for each inbound message must match the Inbound program name for the integration layer process queue, as specified at the Integration Layer Process Queue Screen.

Web service authentication? Use the Working with Web Service Authentication (WWSA) menu option to define a valid user for basic web service authentication. If you use Oracle Identity Cloud Service for password authentication, in addition to creating the web service authentication user in Work with Web Service Authentication (WWSA), you must also create a corresponding user profile in Oracle Identity Cloud Service and assign the user to the corresponding web service role defined for the Order Management application.

If you are using the CWMessageIn RESTful web service: You POST inbound CWMessageIn messages to the web service’s URI, or endpoint, of the RESTful service. The individual URL for the CWMessageIn RESTful service uses the following format: http://server:port/SerenadeSeam/sxrs/application/CWMessageIn, where server:port identifies the application server where the RESTful service is located and CWMessageIn is the name of the web service to call.

If you are using the CWMessageIn SOAP-based web service: The endpoint specified in the CWMessageIn.wsdl file is where you need to post messages in order for the CWMessageIn web service to process them. The endpoint is typically set to http://server:port/CWDirectCPService/services/CWMessageIn, where server:port identifies the application server where the wsdl is located and CWMessageIn is the name of the web service to call. The CWMessageIn SOAP-based web service requires that inbound messages be embedded in SOAP envelope tags.

Inventory Transaction Upload XML Message (inCreateInvXaction)

The INVTRAN_IN process requires an XML file laid out as follows.

 

Important: Please note the following rules for numeric fields:

- Do not pass an alphanumeric value in a numeric field; doing so will cause the INVTRAN_IN process to go into a message wait status.

- Do not exceed the specified length of any numeric field; doing so will cause the value to be interpreted incorrectly.

General rules for alphanumeric fields:

- case-sensitive; an a is not equivalent to an A.

- will be truncated if they exceed the maximum length specified below; a transaction_code of Adjustment will be truncated to A and processed correctly.

See Inventory Transaction Upload XML Message (inCreateInvXaction) for a sample message and see Generic Inventory Transaction Upload for an overview.

Attribute Name

Type

Length

Comments

Message

source

alpha

25

Identifies the source of the XML message.

target

alpha

25

Identifies the target of the XML message. RDC indicates the XML message is sent to Order Management System.

type

alpha

25

Identifies the type of information in the XML message. inCreateInvXaction is the recommended value to indicate the message contains an inventory transaction.

InventoryTransaction

batch_number

numeric

7

Will be stored in the Item Transaction History table. Must be a positive number.

identification_nbr

numeric

10

Will be stored in the Item Transaction History table. If the identification number exceeds 10 positions, it will be truncated. Not valid with G (item-to-item transfer) transactions.

transaction_code

alpha

1

Indicates the type of transaction. Valid transactions are:

A = adjustment

G = item-to-item transfer

M = make up kit

O = overlay current on-hand quantity

V = return to vendor

• any user-defined transaction codes, as specified through Work with Inventory Transaction Codes (WITC).

See Inventory Transaction Upload Process Overview and Inventory Transaction Code for ’Sync’ Processing (I85) for more information.

Note:

• If the information in the transaction code exceeds the maximum length of 1 position, it will be truncated. For example, if this attribute is set to Adjustment, it will be truncated to A.

• This attribute is case-sensitive. A value of a is not the same as a value of A.

G (item-to-item transfer) and O (overlay current on-hand quantity) transactions are not allowed if you use FIFO costing; see FIFO Costing Overview.

• Send only alphanumeric inventory transaction codes through the inventory transaction codes. Non-alphanumeric characters might not process correctly, an might cause an error.

transaction_reason

numeric

2

Must match a valid transaction reason code, as specified through Work with Inventory Transaction Reason Codes (WIT1); required if the inventory transaction code’s Reason required flag is set to Selected.

transaction_quantity

numeric

5

A negative quantity is indicated by a minus sign (-) preceding the number.

Note: If the minus sign is not positioned before the number, the transaction quantity will not process correctly. Depending on how the quantity is formatted, the transaction might go into error status or be processed with an incorrect quantity.

 

 

 

The actual effect on inventory varies with the transaction; for example:

• a transfer (T) always decreases the “from” location and increases the “to” location; the transaction quantity should always be positive. Item-to-item transfers (G) are the same.

• a return to vendor (V) always decreases inventory; the transaction quantity should always be positive.

• an adjustment (A) can be either positive or negative; the quantity is added to or subtracted from the current on-hand quantity.

Note: An overlay (O) or sync (Inventory Transaction Code for ’Sync’ Processing (I85)) resets current on-hand quantity, so the net result can be either a decrease or an increase; however, the transaction quantity should always be positive.

See Summary of Transaction Rules for more information.

allow_partial

alpha

1

Indicates whether to process the transaction even if the full transaction quantity cannot be processed because some of that quantity is currently printed. Valid values are:

Y or 1 = process a partial quantity if the full quantity cannot be processed

N, 0 or blank = do not process a partial quantity; put the transaction in error if the full quantity cannot be processed

See Processing Partial Quantities for a discussion.

create_item_

warehouse

alpha

1

Indicates whether to create an Item Warehouse record if it does not already exist in order to process the transaction. Valid values are:

Y or 1 = create an Item Warehouse record if it does not already exist

N, 0 or blank = do not create a new Item Warehouse record; put the transaction in error if the Item Warehouse does not exist

Note: In the case of a transfer (T) or item-to-item transfer (G) transaction, this value refers to the warehouse specified in the TransactionTo element; otherwise, it refers to the warehouse specified in the Transaction element.

create_item_location

alpha

1

Indicates whether to create an Item Location record if it does not already exist in order to process the transaction. Valid values are:

Y or 1 = create an Item Location record if it does not already exist

N, 0 or blank = do not create a new Item Location record; put the transaction in error if the Item Location does not exist

Note:

• In order to create both a new Item Warehouse and a new Item Location, both this flag and the create_item_warehouse flag must be set to Y or 1.

• In the case of a transfer (T) or item-to-item transfer (G) transaction, this value refers to the location specified in the TransactionTo element; otherwise, it refers to the location specified in the Transaction element.

entered_by_user

alpha

10

If this is a valid user ID, it is stored in the Item Transaction History table. Otherwise, if the message does not specify a valid user, the Item Transaction History record notes the user ID of the person who started the INVTRAN_IN job.

Transaction

company

numeric

3

If this value does not represent a valid company code on your system, the transaction will not process, and the error will not be visible through Working with Inventory Transaction Errors (WITE).

item_number

alpha

12

Defined in and validated against the Item table; see Performing Initial Item Entry (MITM). See Resolving the Item and SKU for information on how the system identifies the correct item and SKU.

Note:

• If the information in the item code exceeds the maximum length of 12 positions, it will be truncated.

• This attribute is case-sensitive. A value of a is not the same as a value of A.

sku_code

alpha

14

Required if the item_number is specified and the item has SKUs. See Resolving the Item and SKU for more information.

Note:

• There should be a blank space between each of the SKU elements.

• If the information in the SKU code exceeds the maximum length of 14 positions, it will be truncated.

• This attribute is case-sensitive. A value of a is not the same as a value of A.

short_sku

numeric

7

Can be used to identify the correct item and SKU; see Resolving the Item and SKU for information.

The system assigns the short SKU number, which you can review at the second Display SKU screen; see Performing Initial Item Entry (MITM).

retail_reference_nbr

numeric

15

Can be used to identify the correct item and SKU; see Resolving the Item and SKU for information.

You can assign a Reference # at the Create Item (Base Information) Screen or the Create SKU 2 of 2 (With Overrides) Screen.

upc_type

alpha

3

Can be used, along with the upc_code, to identify the correct item and SKU; see Resolving the Item and SKU for more information.

You use the Work with UPC Codes Screen to work with UPC types and codes.

upc_code

alpha

14

Can be used, along with the upc_type, to identify the correct item and SKU; see Resolving the Item and SKU for more information.

Note: Include any leading zeros. For example, if the UPC code is 06012011, pass 06012011 and not 6012011.

You use the Work with UPC Codes Screen to work with UPC types and codes.

warehouse

numeric

3

Required. Validated against the Warehouse table; see Creating and Maintaining Warehouses (WWHS) for more information. The create_item_warehouse flag indicates whether to create the Item Warehouse record if it does not already exist.

location

alpha

7

Required. Validated against the Location table; must represent a valid location in the warehouse indicated. See Creating and Maintaining Locations (WLOC) for more information. The create_item_location flag indicates whether to create the Item Location record if it does not already exist.

Note:

• If the location exceeds the maximum length of 7 positions, it will be truncated.

• This attribute is case-sensitive. A value of a is not the same as a value of A.

so_control

alpha

2

Updates the SKU table if the item will be sold out as a result of an item-to-item (G) transfer. Validated against the Soldout Control table; see Working with Soldout Controls (WSLD). If a soldout control code is indicated, it must represent a valid code even if it is not required for the transaction.

Note:

• If the code exceeds the maximum length of 2 positions, it will be truncated.

• This attribute is case-sensitive. A value of a is not the same as a value of A.

TransactionTo

Note: This element is used only for T (transfer) and G (item-to-item transfer) transactions. See Summary of Transaction Rules.

company

numeric

3

Specifies the company for the target of the transfer; required if the company for the source of the transfer is different from the one for the target.

item_number

alpha

12

Used only for G (item-to-item transfer) transactions. See Resolving the Item and SKU for information on how the system identifies the correct item and SKU.

Note:

• If the information in the item code exceeds the maximum length of 12 positions, it will be truncated.

This attribute is case-sensitive. A value of a is not the same as a value of A.

sku_code

alpha

14

Used only for G (item-to-item transfer) transactions. Required if the item_number is specified and the item has SKUs. See Resolving the Item and SKU for more information.

Note:

• If the information in the SKU code exceeds the maximum length of 14 positions, it will be truncated.

This attribute is case-sensitive. A value of a is not the same as a value of A.

short_sku

numeric

7

Used only for G (item-to-item transfer) transactions. Can be used to identify the correct item and SKU; see Resolving the Item and SKU for information.

The system assigns the short SKU number, which you can review at the second Display SKU screen; see Performing Initial Item Entry (MITM).

retail_reference_nbr

numeric

15

Used only for G (item-to-item transfer) transactions. Can be used to identify the correct item and SKU; see Resolving the Item and SKU for information.

You can assign a Reference # at the Create Item (Base Information) Screen or the Create SKU 2 of 2 (With Overrides) Screen.

upc_type

alpha

3

Used only for G (item-to-item transfer) transactions. Can be used, along with the upc_code, to identify the correct item and SKU; see Resolving the Item and SKU for information.

You use the Work with UPC Codes Screen work with UPC types and codes.

upc_code

alpha

14

Used only for G (item-to-item transfer) transactions. Can be used, along with the upc_type, to identify the correct item and SKU; see Resolving the Item and SKU for information.

Note: Include any leading zeros. For example, if the UPC code is 06012011, pass 06012011 and not 6012011.

You use the Work with UPC Codes Screen work with UPC types and codes.

warehouse

numeric

3

Required for T (transfer) and G (item-to-item transfer) transactions. Validated against the Warehouse table; see Creating and Maintaining Warehouses (WWHS) for more information. The create_item_warehouse flag indicates whether to create the Item Warehouse record if it does not already exist.

location

alpha

7

Required for T (transfer) and G (item-to-item transfer) transactions. Validated against the Location table; must represent a valid location in the warehouse indicated. See Creating and Maintaining Locations (WLOC) for more information. The create_item_location flag indicates whether to create the Item Location record if it does not already exist.

Note:

• If the location exceeds the maximum length of 7 positions, it will be truncated.

This attribute is case-sensitive. A value of a is not the same as a value of A.

Inventory Transaction Upload Message: Sample XML

Samples of the Inventory Transaction Upload XML Message (inCreateInvXaction) are presented below.

 

<Message source="idcqa79" target="idcqa79" type="inCreateInvXaction">

<InventoryTransaction transaction_code="O" transaction_quantity="50" allow_partial="Y" create_item_warehouse="Y" create_item_location="Y" entered_by_user="STORE">

<Transaction company="5" item_number="UITEM2" warehouse="10" location="STORE" />

</InventoryTransaction>

</Message>

<Message source="Integrate" target="SC_INVTR_I" type="inCreateInvXaction" resp_qmgr="QMGR" resp_q="INBOUND">

<InventoryTransaction batch_number="1" transaction_code="A" transaction_reason="1" transaction_quantity="1" allow_partial="N" create_item_warehouse="N" create_item_location="N" entered_by_user="EROOSEVELT">

<Transaction company="006" item_number="AB100" short_sku="514" warehouse="1" location="A010101" />

<TransactionTo company="006" item_number="AB100" warehouse="1" location="A010102" />

</InventoryTransaction>

</Message>

Inventory Transaction Upload Errors

Overview: Use Working with Inventory Transaction Errors (WITE) to review and work with errors that occur through the inventory transaction upload in the Inventory Transaction Upload XML Message (inCreateInvXaction). These errors are distinguished from system-generated errors (that is, errors that did not occur through the upload) by the fact that the I flag for upload errors is set to Y. Unlike with system-generated errors, you can change the information in an upload error by selecting Change for the error at the Work with Inventory Transaction Errors Screen.

Important:

- Do not pass an alphanumeric value in a numeric field; doing so will cause the INVTRAN_IN process to go into a message wait status.

- Do not exceed the specified length of any numeric field; doing so will cause the value to be interpreted incorrectly.

Error Description

Code

Possible Reason(s)

List Price Mismatch

1

For a G (item-to-item transfer) transaction, the item specified in the Transaction element and the TransactionTo do not have the same List price. See Create Item (Base Information) Screen and Create SKU 2 of 2 (With Overrides) Screen for more information on specifying the List price.

Unable To Adjust

2

The transaction quantity exceeded the unprinted quantity, but the system was able to process a partial quantity of the transaction. See Processing Partial Quantities.

Note: The error for an M (make up kit) transaction is Negative on hand.

Invalid From Item/Whs

3

There is no record of the item/SKU in the warehouse specified in the Transaction element, and the create_item_ flag is not set to Y or 1.

Trans Reason Required

4

There is no transaction_reason is specified, but the inventory transaction requires one, as specified through Work with Inventory Transaction Codes (WITC).

Comp Location Missing

5

The location is invalid.

Invalid To Item/SKU

6

The item and SKU in the TransactionTo element could not be resolved (G (item-to-item transfer) or T (transfer) transactions only); see Resolving the Item and SKU.

ID Must Be Blank

7

The identification_nbr was specified for a G (item-to-item transfer) transaction.

Invalid To item/warehouse

A

A G (item-to-item transfer) or T (transfer) transaction has the create_item_ flag set to N, 0 or blank, and an Item Warehouse record does not already exist for the item_number and warehouse specified in the TransactionTo element.

Invalid To item/location

B

The create_item_location flag for a G (item-to-item transfer) or T (transfer) transaction is set to N, 0 or blank, and an Item Location record does not already exist for the item_number and location specified in the TransactionTo element.

Trans Code Not Allowed

C

• The transaction_code is a system code, which is not permitted through the inventory transaction upload. System codes are:

- R = purchase order receipt

- I = issue

- C = customer return

- express bill (E)

• The transaction_code is O (overlay) or G (item-to-item transfer), and your Costing Method (A25) system control value is set to FIFO. These types of transactions are not allowed with FIFO costing; see FIFO Costing Overview.

Invalid Transaction Code

D

• The transaction_code does not exist in the Item Transaction Code table.

• There is no transaction_code indicated.

Note: This attribute is case-sensitive; a value of a is not the same as a value of A.

Invalid Reason Code

E

• The transaction_reason does not exist in the Item Transaction Reason table.

• There is no transaction_reason indicated.

• The transaction_reason exceeds the maximum number of positions.

Invalid From warehouse

F

• The warehouse specified in the Transaction element does not exist, or it exceeds the maximum number of positions.

• There is no warehouse specified.

FIFO - Negative OH

G

The inventory transaction will cause the on hand quantity for the FIFO cost layer to be negative.

Invalid Company

H

The company is invalid.

Invalid Item/SKU

I

The item and SKU could not be resolved; see Resolving the Item and SKU. For example:

• The item_number does not exist in the Item table.

• There is no item_number indicated.

• The sku_code does not exist in the SKU table for the indicated item.

• There is no sku_code indicated for a SKU’d item.

Note: These attributes are case-sensitive; a value of a is not the same as a value of A.

Item Must Be Finish Good

K

For an M transaction, the item is not a finished-good item, identified by an F in the Kit type field.

Invalid To location

L

A G (item-to-item transfer) or T (transfer) transaction did not specify a valid location in the TransactionTo element.

Invalid From item/loc

M

The item location specified in the Transaction element does not exist, and the create_item_location flag in the Transaction element is not set to Y or 1.

Negative on hand

N

• The transaction_quantity exceeds the on-hand quantity of the item/SKU.

• The transaction quantity exceeded the unprinted quantity for an M (make up kit) transaction. See Processing Partial Quantities.

Invalid From location

O

• The location specified in the Transaction element does not exist in the warehouse indicated.

• There is no location specified.

Note: This attribute is case-sensitive; a value of a is not the same as a value of A.

FIFO - Negative OH for PO

P

The PO Receipt transaction will cause the on hand quantity for the FIFO cost layer to be negative.

Missing Quantity

Q

No transaction_quantity is specified.

O/H LT Reserved/Printed

R

The transaction quantity exceeded the unprinted quantity, and the system did not process the transaction at all (see Processing Partial Quantities); or, the transaction would have reset the on-hand quantity to a negative number, even if there is not a reserved or printed quantity.

Invalid Sold Out Control

S

• The so_control specified in the Transaction element does not exist in the Soldout Control table.

Note:

• This attribute is case-sensitive; a value of a is not the same as a value of A.

• The system validates the soldout control code, even if it will not be used to process the transaction. A soldout control code is used only when a G transaction sells out the “to” item.

Invalid To warehouse

T

A G (item-to-item transfer) or T (transfer) transaction did not specify a valid warehouse in the TransactionTo element.

FIFO Unbalanced

U

There is a discrepancy between the on-hand quantities for the FIFO layers and the related item/warehouse and/or item/location.

Unable To Unreserve

V

The transaction could not be processed because the system was not able to unreserve the quantity required.

Comp Qtys Do Not Balance

W

 

Invalid From Company

X

The company is invalid.

Overlay Qty LT Reserved

Y

The overlay transaction could not be processed because the overlay quantity was less than the reserved quantity.

Invalid To Company

Z

The company is invalid.

ST01_02 OMSCS 19.0 December 2019 OHC