send feedback

❮ Previous Next ❯

Delivery Confirmation by Shipment interface for JD Edwards

About the Delivery Confirmation by Shipment interface

The Delivery Confirmation by Shipment interface allows you to either confirm at the load level, in which you can confirm every item as fully delivered, or to confirm at the shipment level, in which you can adjust individual product quantities.

In advanced transportation, it is possible to track a shipment or load once it has been shipped, confirmed, and left the shipping dock. Usually, you would do this if it is your vehicle that is making the deliveries. If you were using a third party for the shipper, such as UPS, then UPS assumes the responsibility of delivering the goods to the customer. If there is breakage of a delivery, then a claim is filed with UPS. However, if a company does its own shipping and delivery, and there is breakage, the responsibility falls on that company to account for the damage. This is commonly referred to as in-transit accounting.

A company using EnterpriseOne typically performs a load or shipment confirmation when the items left the shipping dock. This performs the standard ship confirmation (P4205) and creates a CARDEX entry indicating that the inventory has been relieved. Using the Work with Loads application as a row exit allows visibility to in-transit items (all the items that have been shipped on this load).

When the delivery is made there is another application in E1 that can be used to record the quantity of what was delivered; this is where you can account for in-transit breakage. There are two variations of this: the load level allows you to confirm everything at 100% delivered, and the shipment level allows you to adjust individual quantities of product for what was actually delivered. For example, company ABC sells lamps and ships three lamps to Bob's House of Lights. When the truck unloads at Bob's House of Lights one of the lamps is broken and Bob refuses to accept the broken lamp. It is this version of delivery confirmation that allows the quantity to be adjusted that is covered in this usage guide.

Advanced Inventory supports both versions of delivery confirmation in the NER, ND3N4950. There are two functions in this NER. This usage guide covers the dcLINKDeliverConfirmShipment function. This NER calls the ‘C' business function, BD3N4904, to retrieve the processing options.

Name	Function Name	Description
DD3N4951		dcLINK Interface – Deliver Confirm Shipments
ND3N4950	dcLINKDeliverConfirmShipment	dcLINK Interface – Deliver Confirm
DD3N4904		PO Retrieval – Deliver Confirm
BD3N4904	PORetrieveDeliverConfirm	PO Retrieval – Deliver Confirm

This guide applies to the newest version of the ERP.

Corresponding EnterpriseOne Application

In EnterpriseOne, the application you would run to perform a delivery confirmation is P49650, which can be accessed from the row exit on the Works with Loads application. The Work with Loads application can be found on the menu G4911.

Processing options

There are several processing options associated with delivery confirmation. However, in this NER, we use only four.

The dream writer version will default to ZJDE0001, if not otherwise specified in the parameter list on the call.

Process tab

Shipment tracking status code. The shipment tracking status code is passed into the begin doc MBF. This value must be a valid value in the UDC table 49/BH.
Shipment tracking status reason code. The shipment tracking status reason code entered into this field will be passed into the begin doc MBF. This value must be a valid value in the UDC table 49/BJ.
Thru shipment status (required). This code is compared to the shipment status which is retrieved when the shipment number is verified. If the shipment status is greater than or equal to the value in this field the shipment cannot be changed and an error is generated.

Defaults tab

Disposition Code - Valid values are: blank, C which means cancel, and S which means leave shippable. This value is only used if one or both of the following items are true:
- The disposition code in the input data structure is left blank
- The disposition code in the load header file is blank.

Processing option data structure - DD3N4904

The interface retrieves these parameters by calling BD3N4904. They are passed back in the following data structure.

Type	Description	Parameter
String	szPOVersion_VERS	Input
Date	jdDefaultDeliverDate_DLRT	Output
Char	cDefaultDispositionCode_DSCD	Output
String	szSONextStsInvliced_NXTR	Output
String	szNxtShpnStsFreightNoUpdt_SSTS	Output
String	szLoadStsPartialDelivered_LDLS	Output
String	szShipmentTrackingStsCode_SSCD	Output
String	szNextShpnStsFreightUpdt_SSTS	Output
String	szLoadStatus_From_LDLS	Output
String	szLoadStatus_To_LDLS	Output
String	szShipmentStatus_From_SSTS	Output
String	szShipmentStatus_To_SSTS	Output
String	szStsCdLastDeliverConfirm_LTTR	Output
Char	cPackedItemDeliver_gt_Sch_EV01	Output
Char	cBulkItemDelivered_gt_Sch_EV01	Output
Char	cPackedItemNegIntransit_EV01	Output
Char	cBulkItemNegativeIntransit_EV01	Output
String	szSalesOrderStatus_From_NXTR	Output
String	szSalesOrderStatus_To_NXTR	Output
Char	cWriteShipmentStatusRec_EV01	Output
Char	cDisplayLdDispositionForm_EV01	Output
String	szVersionLoadDisposition_VERS	Output
String	szShipTrackStsReasonCode_SSRS	Output
String	szIntransitLedgerDocCode_DCT	Output
String	szLoadStatusDelivered_LDLS	Output
String	szLoadStatusCompleted_LDLS	Output
String	szOverridnxtStsForSOLines_NXTR	Output
String	szVersUnscheduledDeliver_VERS	Output
Char	cDelCfmAtAmbOrStd_EV01	Output
String	szStsCdNextLeaveShippable_NXTR	Output
String	szCreditOrderStatus_From_NXTR	Output
String	szCreditOrderStatus_To_NXTR	Output
String	szCrdtStsCdLastDelvrCnfrm_LTTR	Output
String	szPurchasOrderStatus_From_NXTR	Output
String	szPurchaseOrderStatus_To_NXTR	Output
String	szPOStsCdLastDelivrConfrm_LTTR	Output
String	szOperationCode_OPRC	Output
String	szVersionReceiptRouting_VERS	Output
Char	cPieceWiseConfirm_EV01	Output

Processing - EnterpriseOne

You can use EnterpriseOne to work with loads and confirm delivery.

First, you need to select a load that has a load status of In-Transit. The following figure indicates the procedure for entering this using EnterpriseOne.

Highlight the grid line and click the row exit button labeled “Confirm Delivery”. The first screen displayed allows you to perform a Delivery Confirmation at the load level. This functionality is supported in the other function that is in this NER. We are concerned with confirming at the shipment level. Highlight the grid record for the shipment and routing step to be confirmed and click on the row exit button Confirm Shipment. The following screen displays.

This grid shows all the sales order lines that were on the shipment for the routing step selected. In this example, there is one bike that was load confirmed with a quantity of 3. Suppose that when the delivery was made, the quantity onboard had been reduced to 2. In this case, the user would key 2 into the delivered quantity field.

Processing - dcLINK

To be able to change each individual sales order line's quantity, the user must send up multiple transactions - one for each line being processed - and then process all those lines together.

There are three dcLINK action codes that control the processing. A dcLINK action code with a value of ‘0' loads the work file. Each call to this interface represents a sales order line that needs a delivery confirmation. The delivery information that can be entered differently for each line is the quantity delivered, the secondary quantity delivered (if applicable), and the disposition code. The date delivered, time delivered, and received by are specified on each call but are really expected to be the same for each line processed. Upon the successful processing of a call where the dcLINK action code is equal to a ‘0', a single entry should have been written to the FD3N4950 work file. The key to that file is load number, planning depot, shipment number, routing step number, order number, order type, order company, and order line number.

Once all the records have been loaded to the work file, they are processed by sending another transaction up with a dcLINK action code of ‘1'. The select on the work file is done by load number, planning depot, shipment number, and routing step. In other words, all previous records that have been sent up that have the same values in these four fields will be processed.

Clearing the work file is done by sending in a dcLINK action code of ‘9'. The same four fields that are used to process the file are also used as the key to clear the file. In other words, all transactions in the work file that have the same load, planning depot, shipment number, and routing step will be deleted together. The only time you need to delete the work file is if you were loading records (dcLINK action code of ‘0') and that process is aborted before the records are processed. Upon successfully completing a type ‘1' transaction this interface will automatically delete the transactions it just processed.

Required fields for processing

The following fields in EnterpriseOne are necessary for processing the Delivery Confirmation by Shipment Processing interface.

Because this interface is driven by different action code values, the dcLINKActionCode is a required field. The load number (mnLoadNumber_LDNM), planning depot (szPlanningDepot_VMCU), shipment number (mnShipmentNumber_SHPN), and routing step (mnRoutingStepNumber_RSSN) are all required fields. These fields must be supplied regardless of the dcLINK action code being used. If the dcLINK action code is equal to a ‘0', which means the work file is being loaded then the sales order number (szOrderNumber_DOCO), sales order type (szOrderType_DCTO), sales order company (szOrderCompany_KCOO), and sales order line (szOrderLineNbr_LNID) are all required in order to find the correct sales order line. Since the whole point of this interface is to confirm, line by line, that you also want to send up the quantity of the line being delivered (mnDeliveredQty_SOQS).

Mapping guidelines

As a script builder, you must decide whether to allow the NER to default in values, or to map those values in the API call in the script. The correct configuration for your environment depends on the readability and accessibility of the scripts.

The more effortless configuration is to allow NER to default as much as it can, in order to keep the script “clean”. The potential issue with that approach is that it hides items that may need to be changed. For example, some interfaces may require a different action code depending on what is being done. By allowing the NER to default the action code, the user who has to edit the script may not observe that the action code needs to be changed.

Verify the process

Before processing the loaded lines (dcLINKActionCode = 1), use UTB to verify that lines are being written to the FD3N4950 work file.

After the lines have been processed, there are several places you can check to verify that the interface processed correctly. The following figure shows the work with loads screen. Note that the status for the load has changed from In-Transit to Delivered.

In the Transportation Inquiries menu (G4914), highlight the grid row of a load that is at the delivered status, and click the row exit button for Intransit. The following figure displays items that are still in transit.

To display the In-Transit Ledger, highlight a grid row and click the row exit button Intransit Ledger.The In-Transit Ledger, displayed in the following figure, displays all activity that occurred on the item.

Input data structure DD3N4951

The following table describes the input data structure for DD3N4951.

In the following table, r indicates Required, o indicates Optional, and x indicates that the item is Required but will default in if not passed.

Name	Default Values	R/O	Alias	Notes
cdcLINKActionCode_EV01	0	x	EV01	Always defaults to a 0. No different action takes place based on this code.
cActionCode_ACTION	0	x	ACTION
jdDateUpdated_UPMJ	Current Date	x	UPMJ	Retrieved from GetAuditInfo
mnTimeOfDay_TDAY	Current Time	x	TDAY	Retrieved from GetAuditInfo
szUserId_USER	Current User	x	USER	Retrieved from GetAuditInfo
szWorkStationId_JOBN	Current Workstation	x	JOBN	Retrieved from GetAuditInfo
mnJobNumber_JOBS		o	JOBS
szProgramId_PID	ND3N4950	x	PID	Defaulted in program if not passed in
szVersion_VERS	ZJDE0001	x	VERS	Defaulted in program if not passed in
cSuppressErrMsg_EV01		o	EV01
cErrorCode_ERRC	Blanks	x	ERRC	Defaulted in program
szErrorMessageKey_EKEY	Blanks	x	EKEY	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 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.
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 they capture the screen ID where the change was made. dcLINK captures the script ID.
szGuidTextMessage_TEXTMES		o	TEXTMES	This is a free form entry field.
szPlanningDepot_VMCU		r	VMCU	This is the planning depot that was assigned to the load when the load was created.
mnLoadNumber_LDNM		r	LDNM	The load number this shipment is on.
mnShipmentNumber_SHPN		r	SHPN	The shipment number the sales order was assigned to.
mnRoutingStepNumber_RSSN		r	RSSN	The routing number of the shipment that the sales order was assigned to.
szOrderCompany_KCOO		r	KCOO	The company number from the sales order.
mnOrderNumber_DOCO		r	DOCO	The sales order number.
szOrderType_DCTO		r	DCTO	The document type of the sales order.
mnOrderLineNbr_LNID		r	LNID	The line number from the sales order for the item being delivered.
jdDeliveryDate_DLDT	Today's Date	o	DLDT	The date the item was delivered to the customer.
cDispositionCode_DSCD		o	DSCD	If entered this must be a valid disposition code.
szReceivedBy_DL01		o	DL01	The name of the person at the customer that received the delivered shipment.
mnDeliveredQty_SOQS		r	SOQS	This is the quantity being delivered.
mnSecDeliveredQty_SQOR		o	SQOR	If the item is a dual unit of measure item this is the secondary quantity.
mnDeliveryTime_DLTM		o	DLTM	The time the item was delivered to the customer.

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	Enter a Detail Line	Process all Detail Lines	Clear the Work File
cdcLINKActionCode_EV01	0	1	9
cActionCode_ACTION
jdDateUpdated_UPMJ
mnTimeOfDay_TDAY
szUserId_USER	Elvis	Elvis	Elvis
szWorkStationId_JOBN
mnJobNumber_JOBS
szProgramId_PID
szVersion_VERS	ZDBK0001	ZDBK0001	ZDBK0001
cSuppressErrMsg_EV01
cErrorCode_ERRC
szErrorMessageKey_EKEY
iDebugLevel_INT01
szGuidUniqueID_GUID
szGuidApprover1_USR1
szGuidFullName1_FULLNAME1
szGuidApprover2_USR2
szGuidFullName2_FULLNAME2
mnGuidReasonCode1_REASON1
szGuidCommentField_COMMENTS
mnGuidReasonCode2_REASON2
szGuidCommentField2_2COMMENTS
szGuidScriptID_FMNMVERS
szGuidTextMessage_TEXTMES
szPlanningDepot_VMCU	30	30	30
mnLoadNumber_LDNM	11	11	11
mnShipmentNumber_SHPN	73534	73534	73534
mnRoutingStepNumber_RSSN	1.0	1.0	1.0
szOrderCompany_KCOO	00001	00001	00001
mnOrderNumber_DOCO	550615	550615	550615
szOrderType_DCTO	S4	S4	S4
mnOrderLineNbr_LNID	1.000	1.000	1.000
jdDeliveryDate_DLDT	05/10/2005	05/10/2005	05/10/2005
cDispositionCode_DSCD	S	S	S
szReceivedBy_DL01	Dudley	Dudley	Dudley
mnDeliveredQty_SOQS	2	2	2
mnSecDeliveredQty_SQOR
mnDeliveryTime_DLTM

Common error messages

The following error messages are commonly generated by this BF. This table includes descriptions for each error.

Error Message	Description
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 sales order number is zero or null. This message can also be generated if the fetch on the F4211 fails.
045X	Action Code Invalid - The dcLINKActionCode entered was not 0, 1, or 9.
062S	Load Number Invalid - Either the load number passed in was blank or the load number was not found in the Load Header file (F4960).
4247	Invalid Depot - The planning depot number passed into this NER is blank.
053P	Invalid Shipment Number - The shipment number passed into this NER is blank.
080U	Shipment Status Not Valid - The shipment status from the Shipment Header file (F4215) is greater than or equal to the “to” shipment status in the processing options. Making the status out of the valid range.
069N	Routing step not found - The routing step that was passed into this NER is blank.
181B	Invalid Load/Shipment Number - The shipment routing steps file (F4941) was read, and either the load or planning depot that is associated with the shipment does not match the load or planning depot passed into this NER.
080T	Shipment Not Found - The shipment/routing step combination was not found in the shipment routing steps file (F4941).
042E	Sales order number missing or invalid - The sales order number passed into this NER is blank.
3500	Line Number Invalid - The sales order line number passed into this NER is blank.
0024	Company Number Invalid - The sales order company number passed into this NER is blank.
4634	Order Type required - The sales order type passed into this NER is blank.
075V	Load Status Invalid - The load status returned from the Load Header file (F4960) is less than the confirmed load status from the transportation constants file (F49002).
40R1	Disposition Code Invalid - The disposition code used was not found in the UDC table 49/DH.
081C	Order Line is not on shipment - The shipment number for the sales order line in the sales order detail (F4211) file does not match the shipment number passed into this NER.
081A	Sales Order Line not found - The sales order detail file (F4211) was read using the sales order company, sales order, sales order type, and sales order line number passed into this NER. No record was found in the F4211.
602H	Table Insert Failed - The write to the work file FD3N4950 failed.
017F	Fetch Unsuccessful - The NER is in processing mode and the fetch against the FD3N4250 work file failed.

There was a problem loading this topic

Mobile Enterprise Platform