send feedback

❮ Previous Next ❯

Warehouse Confirmation Common interface for JD Edwards

About the Warehouse Confirmation interface

Warehouse confirmations are used to confirm movement within a warehouse.

These movements are in the form of picks, putaways, and replenishments. The warehouse system creates suggestions on how product should be moved in the warehouse. These suggestions are sometimes referred to as task/trips. It is these task/trips that this interface confirms. This interface was written in NER, and calls ‘C' business function, BD3N4601 to retrieve the processing options.

Name	Function name	Description
DD3N4617		dcLINK Interface – Warehouse Confirmation
ND3N4617	dcLINKWarehouseConfirmation	dcLINK Interface – Warehouse Confirmation
DD3N4601		PO Retrieval Data Structure – Warehouse Confirmations
BD3N4601	PORetrievalWarehouseConfirmation	PO Retrieval – Warehouse Confirmations

Corresponding EnterpriseOne application

EnterpriseOne Warehouse Confirmation.

In EnterpriseOne, the application you would run to perform a warehouse confirmation is P4617, and can be accessed from the menu G4611, G4612, or G4613 depending on whether you are processing a putaway, a pick, or a replenishment.

Processing options

Processing the warehouse confirmation options.

The dream writer version will default to ZJDE0001 if not otherwise specified in the parameter list on the call. The dream writer parameters that are used by this NER are the following.

Parameters	Writing parameters
Display tab	Program Mode: This parameter must be complete, otherwise the NER will throw an error. This defines what kind of warehouse transaction is being performed. 1 = Putaway 2 = Pick 3 = Replenishment. Phase Control Code: The NER uses this parameter to verify that the task being processed is at the correct phase. If this is set to a ‘2', the NER will check to make sure the 1^st phase confirmation has competed. Shipping Location: The NER will use this parameter to verify that the shipping location can, in fact, be overridden. The NER will ignore any attempt to change the shipping location if this flag is not set.
Move tags tab	Move Tag: This field is used to control printing a move tag. This value is passed into the End Doc MBF and the print move tag UBE (R46473). Bar Code: This field is used to control the printing of the bar code on a move tag. This value is passed into the End Doc MBF, and the print move tag UBE (R46473). Unit of Measure: This field is used to control the printing of the unit of measure on a move tag. This value is passed into the End Doc MBF, and the print move tag UBE (R46473). Item/Location Quantity to Be Printed on the Tag: This field is used to control the printing of the item/location quantity on a move tag. This value is passed into the End Doc MBF, and the print move tag UBE (R46473). Enter the number of Duplicate Copies to be printed for each tag:This field is only used by the End Doc MBF. It is used to indicate how many copies of a move tag will be printed. DREAM Writer version of the move tags to be used for the printer overrides: This field is also only used by the End Doc MBF. It is the version that will be used by R46473.
Bulk picking	Bulk Detail Report: This field is passed into the End Doc MBF. It is used to control if the bulk pick detail report is run or not. Bulk Pick Detail Report (R46210) Version: This field is passed into the End Doc MBF. It is the version number that will be used when R46210 is called.
Carton Detail	Carton Detail Information: This is used by the End Doc MBF to determine if carton detail information should be generated. Version of Carton Reorganization (P4620) to use for Generating Carton Detail Information: This field is also passed into the End Doc MBF. It is the version number of P4620 that will be used.

Processing option data structure DD3N4601

Processing warehouse confirmation options.

Our interface retrieves these parameters by calling BD3N4601, and is passed back in the following data structure.

Type	Description	Parameter
Char	cWMSConfirmationType_TYFL	Output
Char	cPhaseControl_PTPH	Output
String	szDefaultStatus_PSTB	Output
Char	cVerificationCodeRequired_EV01	Output
Char	cAutoInquiry_EV01	Output
Char	cPrintMoveTag_EV01	Output
Char	cPrintBarCode_EV01	Output
Char	cPrintUOMStructure_EV01	Output
Char	cPrintF41021Quantity_EV01	Output
String	szMoveTagVersion_VERS	Output
Numeric	mnNumberOfDuplicateTags_MATH01	Output
String	szSOConfirmedNextStatus_NXTR	Output
String	szSOCancelledNextStatus_NXTR	Output
String	szP4617Version_VERS	Input
Char	cSuppressErrorMessage_SUPPS	Output
Char	cErrorCode_ERRC	Output
String	szErrorMessageID_DTAI	Output
Char	cCallR46210BulkPick_EV01	Output
String	szR46210Version_VER1	Output
Char	cPPSGenerateCartonDetail_EV01	Output
String	szP4620CartnDetailVersion_VERS	Output
Char	cOverrideLocations_MSRL	Output
Char	cShipAscendErrorFlag_EV01	Output
String	szVersionPackCfrm_VER	Output

Processing

Confirm that an inventory movement has occurred in a warehouse environment.

The purpose of this interface is confirm in EnterpriseOne that an inventory movement has occurred in a warehouse environment. How that movement is handled is driven by the dcLINK action code values.

Action code	Description
0	When the dcLINKActionCode is equal to 0 this NER will perform both an Edit Line and an End Doc call. This is ideal if the goal is to process a single task/trip. Use this dcLINKActionCode if the transaction needs to be overridden in some fashion.
1	When the dcLINKActionCode is equal to 1, this NER will only perform an Edit Line. The idea behind this was that it allows mulitiple Edit Line calls to be entered and then processed with a single End Doc call. This allows for processing several unrelated task/trips together. While the NER still supports this, changes made to TranServer to reset cache have effectively removed any value to processing transations this way.
2	When the dcLINKActionCode is equal to 2 or 3, this NER will only perform an End Doc. This action code works in conjunction with dcLINKActionCode of 1 to group transactions together, and then commit them with one End Doc call. As stated under the dcLINK Action Code – 1 write up, this method is no longer encouraged.
3	When the dcLINKActionCode is equal to 2 or 3, this NER will only perform an End Doc. This action code works in conjunction with dcLINKActionCode of 1 to group transactions together, and then commit them with one End Doc call. As stated under the dcLINK Action Code – 1 write up, this method is no longer encouraged.
4	When the dcLINKActionCode is equal to 4, this NER will call R46473 to reprint the move document.
5	When the dcLINKActionCode is equal to a 5, this NER will loop through the F4611 file and confirm all trips for a given task (or sequences for a given suggestion – depending on what is passed in) that are at the status to be confirmed. For example, a task is created that has ten trips, each one moving an item to a different location. As long as all transactions can be confirmed, with no overrides, then this dcLINKActionCode can do it in one call, versus the 10 calls it would take to accomplish the same thing using dcLINKActionCode – 1.

Best practice

Even if some trips need to be overridden, it still makes sense to use an action code of 5 in conjunction with action code 1.

The script will need to detect which tasks were overridden, and then process them with a dcLINKActionCode of 1. Since this will change their statuses, then a single call using dcLINKActionCode of 5 will process the remaining unchanged transactions. Using the example of 1 trip with 10 tasks, if 2 tasks needed to be overridden, then all 10 tasks could be confirmed with 3 calls (2 calls using dcLINKActionCode 1 to override the task, and 1 call using dcLINKActionCode 5 to confirm the remaining 8 tasks). In order for this strategy to be effective, the warehouse environment has to be setup so there are multiple tasks assigned to each trip.

In addtion to the dcLINKActionCode, the ActionCode also has values that can be set.

Action code	Description
1	This is the default. If nothing is passed in the action code field, this is the value that will be assgined. The action code is passed into the Edit Line MBF; A value of 1 says the line is being confirmed.
6	The action code is passed into the Edit Line MBF; a value of 6 says the line is being reprinted.
9	The action code is passed into the Edit Line MBF; a value of 9 says the line is being cancelled.

Required fields

Required fields for a warehouse confirmation.

Enough of the data needed to confirm a transaction can be defaulted from the F4611 detail record that, really, the only required fields are those needed to read the F4611 file. The warehouse detail file can be read in one of two ways. Either by the task/trip, or by the suggestion batch/sequence. To confirm a single task/trip with no overrides, the only thing that is really required is the task/trip. If you want to confirm an entire task with no overrides, then all you need is the task and a dcLINKActionCode of 5.

License plates

License plating for a warehouse confirmation.

Support for license plating has been added to warehouse confirmation. If a task is being overridden, the grid will allow the license plate number to be changed. The processing follows the conventional logic. For example, on putaways the “from” information is overridden but the “to” information is not. On picks the “to” information is rarely changed but the “from” information is.

CARDEX

CARDEX for Warehouse Confirmation.

For every warehouse confirmation, there should be two entries to record the “from” and the “to” of each transaction. Note the document number is the task number.

Summary availability

Summary availability for a warehouse confirmation.

Since an item is being moved from one location to another, there should be a decrease in the quantity in the “from” location, and an increase in the quantity of the “to” location. In order to use this check effectively, you really need to look at the summary availability, both before and after the warehouse transaction was run, to be able to track the change in quantities.

Confirming Warehouse Confirmation

Confirming a warehouse confirmation.

The E1 application can be used to show changes as well. After a transaction has been confirmed, its status code should change to reflect that. Usually the status will change to 399, but customers can tailor that to fit their needs. So don't assume, if it changes to a value other than 399, that it didn't work.

Location detail selection P4605

Location details for a warehouse confirmation.

In the warehouse system there is a file called the Location Detail Information file (F4602). This file has detail entries on how both sides of a warehouse confirmation affect the locations involved in the confirmation. Much like summary availability, this file really needs to be studied both before and after a warehouse transaction to know what value was changed.

One of the biggest challenges is finding which detail record was affected. Either side of the transaction (from/to) could have multiple detail records, so you really need to record all of the records in order to tell which one changed. Another challenge is, if the detail record on the “from” side only has the quantity of the transaction, then after the confirmation that detail record should go to zero.

This detail file is somewhat self-cleaning, meaning if a record has no quantity, then instead of showing a record with zero quantity, the record itself is simply deleted.

Input data structure

The input data structure for DD3N4617.

Name	Default value	Notes
Name	Default value	R/O	Alias
mnJobNo_JOBS		O	JOBS
mnSuggestionBatchNo_SGBT		O	SGBT	Lines maybe confirmed either by Task./Trip, or suggestion batch/sequence. If the dcLINK Action Code is equal to a ‘5', then all the sequence numbers for this batch will be confirmed.
mnSuggetionSeqNo_SGSQ		O	SGSQ	This is required if: 1) the batch number is passed in and, 2) the dcLINK Action Code is not equal to a ‘5'.
cActionCode_EV01	1	X	ACTION	1 = Confirming 6 = Reprinting 9 = Canceling
mnTransQty_TQTY		O	TQTY	If not passed in, it will default to the transaction quantity from the F4611 file.
szTransUoM_UOM1		O	UOM1	If not passed in, it will default to the transaction unit of measure from the F4611 file.
szFromLoc_FLOC		O	FLOC	If not passed in, it will default to the “from” location stored in the F4611 file. Depending on the type of confirmation being performed, this field may result in an error if it is overridden.
szToLoc_TLOC		O	TLOC	If not passed in, it will default to the “to” location stored in the F4611 file. Depending on the type of confirmation being performed, this field may result in an error if it is overridden.
mnTotQtyLevel1_TQL1		O	TQL1	If not passed in, it will default to the quantity level stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szUoMLevel1_UML1		O	UML1	If not passed in, it will default to the unit of measure stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
mnTotQtyLevel2_TQL2		O	TQL2	If not passed in, it will default to the quantity level stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szUoMLevel2_UML2		O	UML2	If not passed in, it will default to the unit of measure stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
mnTotQtyLevel3_TQL3		O	TQL3	If not passed in, it will default to the quantity level stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szUoMLevel3_UML3		O	UML3	If not passed in, it will default to the unit of measure stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
mnTotQtyLevel4_TQL4		O	TQL4	If not passed in, it will default to the quantity level stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szUoMLevel4_UML4		O	UML4	If not passed in, it will default to the unit of measure stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
mnTotQtyLevel5_TQL5		O	TQL5	If not passed in, it will default to the quantity level stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szUoMLevel5_UML5		O	UML5	If not passed in, it will default to the unit of measure stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szContainerCodeLevel1_EQL1		O	EQL1	If not passed in, it will default to the container code stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szContainerCodeLevel2_EQL2		O	EQL2	If not passed in, it will default to the container code stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szContainerCodeLevel3_EQL3		O	EQL3	If not passed in, it will default to the container code stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szContainerCodeLevel4_EQL4		O	EQL4	If not passed in, it will default to the container code stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szContainerCodeLevel5_EQL5		O	EQL5	If not passed in, it will default to the container code stored in the F4611 file. Note – even the “typical” warehouse transaction that is doing overrides seldom requires this field to be changed.
szLotNo_LOTN		O	LOTN	If not passed in, it will default to the lot number from the F4611 file.
szReasonCode_CODR		O	CODR	If not passed in, it will default to the reason code from the F4611 file.
szLocVerificationCode_LVER		O	LVER	If not passed in, it will default to the lot verification code from the F4611 file.
mnStorageUnitNoFrom_STNF		O	STNF	Always defaults to a 0.
mnStorageUnitNoTo_STNT		O	STNT	Always defaults to a 0.
mnLocDetailSeqNoFrom_LDFT		O	LDFT	Always defaults to a 0.
mnLocDetailSeqNoTo_LDTS		O	LDTS	Always defaults to a 0.
szProgramId_PID	ND3N4617	X	PID	Defaulted in program if not passed in
szVersion_VERS	ZJDE0001	X	VERS	Defaulted in program if not passed in
cSuppressErrMessage_EV01		O	EV01
szErrorMessageID_EKEY	Blanks	X	EKEY	Defaulted in program
cdcLINKActionCode_EV01	0	X	EV01	0 = Edit Line & End Doc (1 task/trip only) 1 = Edit Line only (1 task/trip only) 2 = End Doc 3 = End Doc 4 = Reprint Move Tag 5 = Multiple Edit Lines and one End Doc (looping to get all trips within a task or sequence within suggestion batch).
szUserId_USER	Current User	X	USER	Retrieved from GetAuditInfo
mnWarehouseTaskNumber_PTSK		O	PTSK	Lines maybe confirmed either by Task/Trip or by suggestion batch/sequence. If the dcLINK Action code is equal to a ‘5', then all the lines for this task will be confirmed.
mnWarehouseTrip_TRIP		O	TRIP	This is required if: 1) the task is passed in, and 2) the dcLINK Action Code is not equal to ‘5'.
szWorkStationId_JOBN	Current Workstation	X	JOBN	Retrieved from GetAuditInfo
jdDateUpdated_UPMJ	Current Date	X	UPMJ	Retrieved from GetAuditInfo
mnTimeUpdated_TDAY	Current Time	X	TDAY	Retrieved from GetAuditInfo
cErrorCode_ERRC	Blanks	X	ERRC	Defaulted in program
iDebugLevel_INT01		O	INT01	Displays M&D Debug statements if the value is greater than 0
szGuidUniqueID_GUID	Automatically generated by dcLINK	O	CFRGUID	If generate GUIDs is turned on in the dcLINK configuration utility, this field will contain a GUID (guaranteed unique identifier). The GUID is used to tie database changes in PeopleSoft to the transactions that triggered those changes to occur.
szGuidApprover1_USR1		O, R	USR1	An entry in this field or the Approver 2 field will cause a signature capture record to be written. Signature capture records are part of the GUID processing and should not be used unless a GUID is being created by dcLINK. The value of this field is a User ID, not an address book entry. There must be a value passed in to either this field, or the approver 2 field otherwise it is an error.
szGuidFullName1_FULLNAME1		O	FULLNAME1	This field is the full name of the GUID Approver 1.
szGuidApprover2_USR2		O, R	USR2	GUID processing supports up to two approvers. If two approvers are required, this is the user ID of the second approver. There must be a value passed in to either this field, or the approver 1 field, otherwise it is an error.
szGuidFullName2_FULLNAME2		O	FULLNAME2	This field is the full name of the GUID Approver 2.
mnGuidReasonCode1_REASON1		O, R	REASON1	If either of the approver fields contain a value, but no value is entered into one of the reason code fields, then an error will be returned. Reason codes must match the valid reason codes setup for GUID processing, otherwise it is an error.
szGuidCommentField_COMMENTS		O	COMMENTS	This is a free form entry field that is used to further explain the reason code entered into the previous field.
mnGuidReasonCode2_REASON2		O, R	REASON2	If either of the approver fields contains a value, but no value is entered into one of the reason code fields, then an error will be returned. Reason codes must match the valid reason codes setup for GUID processing otherwise it is an error.
szGuidCommentField2_2COMMENTS		O	2COMMENTS	This is a free form entry field that is used to further explain the reason code entered in the previous field.
szGuidScriptID_FMNMVERS		O	FMNMVERS	In PeopleSoft the screen ID where the change was made is captured. dcLINK captures the script ID.
szGuidTextMessage_TEXTMES		O	TEXTMES	This is a free form entry field.
mnSecondaryQty_SQOR		O	SQOR	If the item is a DUAL unit of measure item, then this is the secondary quantity.
szSecondaryUoM_UOM2		O	UOM2	If this item is a DUAL unit of measure item, then this is the secondary unit of measure.
mnSecondaryOverPickQty_SQOR		O	SQOR	Passed into the Edit Line MBF
szParentLicensePlateNumb_PLPNU		O	PLPNU	Passed into the Edit Line MBF
szFromLicensePlateNumber_LPNUF		O	LPNUF	Passed into the Edit Line MBF
szToLicensePlateNumber_LPNUT		O	LPNUT	Passed into the Edit Line MBF

R = Required

X = Required but will default in if not passed

O = Optional

Transaction test scenarios

The following test scenarios demonstrate a variety of ways in which this interface could be used, and the fields that would be passed for each scenario.

The data structure fields are in the left column, and the corresponding values for each scenario are listed by column.

Field name	Putaway using trip/ task	Putaway using suggestion batch/SEQ	Pick using trip/ task	An override pick using task/trip	Override putaway using task/trip
mnJobNo_JOBS
mnSuggestionBatchNo_SGBT		239
mnSuggetionSeqNo_SGSQ		5
cActionCode_ACTION				1	1
mnTransQty_TQTY				1	5
szTransUoM_UOM1				EA	EA
szFromLoc_FLOC				4.A.2
szToLoc_TLOC					4.A.2
mnTotQtyLevel1_TQL1
szUoMLevel1_UML1
mnTotQtyLevel2_TQL2
szUoMLevel2_UML2
mnTotQtyLevel3_TQL3
szUoMLevel3_UML3
mnTotQtyLevel4_TQL4
szUoMLevel4_UML4
mnTotQtyLevel5_TQL5
szUoMLevel5_UML5
szContainerCodeLevel1_EQL1
szContainerCodeLevel2_EQL2
szContainerCodeLevel3_EQL3
szContainerCodeLevel4_EQL4
szContainerCodeLevel5_EQL5
szLotNo_LOTN
szReasonCode_CODR				OVR	OVR
szLocVerificationCode_LVER
mnStorageUnitNoFrom_STNF
mnStorageUnitNoTo_STNT
mnLocDetailSeqNoFrom_LDFT
mnLocDetailSeqNoTo_LDTS
szProgramId_PID
szVersion_VERS	ZJDE0001	ZJDE0001	ZJDE0002	ZJDE0002	ZJDE0001
cSuppressErrMessage_EV01
szErrorMessageID_EKEY
cdcLINKActionCode_EV01	0	0	0	0	0
szUserId_USER	Pete	Larry	Pete	Joe	Joe
mnWarehouseTaskNumber_PTSK	228		24637	24638	228
mnWarehouseTrip_TRIP	6		1	1	5
szWorkStationId_JOBN
jdDateUpdated_UPMJ
mnTimeUpdated_TDAY
cErrorCode_ERRC
iDebugLevel_INT01
szGuidUniqueID_GUID
szGuidApprover1_USR1
szGuidFullName1_FULLNAME1
szGuidApprover2_USR2
szGuidFullName2_FULLNAME2
mnGuidReasonCode1_REASON1
szGuidCommentField_COMMENTS
mnGuidReasonCode2_REASON2
szGuidCommentField2_2COMMENTS
szGuidScriptID_FMNMVERS
szGuidTextMessage_TEXTMES
mnSecondaryQty_SQOR
szSecondaryUoM_UOM2
mnSecondaryOverPickQty_SQOR
szParentLicensePlateNumb_PLPNU
szFromLicensePlateNumber_LPNUF
szToLicensePlateNumber_LPNUT

Common error messages

Commeon error messages for the warehouse confirmation.

The following are common error messages that can be generated by this BF, and what those error messages mean.

Error message	Meaning
0002	Record Invalid: In the context of this BF, this error is returned when an error has been detected from one of these three business functions: dcLINK Set User ID, dcLINK Utility Set Audit Info, or dcLINK Utility Write Signature Capture Record. This message is also generated if the processing option that defines the type of warehouse transaction (pick, putaway or replenishment) is blank.
069D	Invalid Location: This message is received if the “from” location on a putaway transaction is being overridden.
126B	Cannot Override To Location: The override to location cannot process the suggestion that has been selected for confirmation.
3542	Phase 2 suggestion cannot be confirmed: If the processing option is set for a 2 phase confirmation, the warehouse detail file will be read to verify the first phase transaction is at a status of ‘399'. If it is not, then the 1^st phase isn't confirmed, which means the 2^nd phase cannot be run. This error is then generated.
3631	No records selected: Sometimes when transactions go through the batch process to create a task, errors are identified even though a task/trip was created. This error message is receive if the task/trip that is being confirmed has an error already associated with it.
774T	Item has errors: An error occurred in the Edit Line MBF.

There was a problem loading this topic

Mobile Enterprise Platform