send feedback

❮ Previous Next ❯

Kanban Processing interface for JD Edwards

About the Kanban Processing interface

Kanban can be defined as a finished goods and components management system where the manufacturer keeps safety stock on hand at all times for each stage in the manufacturing process.

The safety stock may come from on-site storage locations, and be transferred to the consuming location, or it can be purchased from the outside and received and transferred to the consuming location. The way it keeps goods in stock is by using the Kanban as a signal to say when stock needs to be replenished. The word “Kanban” is Japanese and means “sign board”. E1 kept these manual terms like cards for their implementation of Kanban. Kanban uses Super Backflush behind the scenes to accomplish a lot of the transaction processing. The dcLINK interface is called ND3N3157 and calls the ‘C' business function BD3N3107 to retrieve processing options.

Name	Function name	Description
DD3N3157		dcLINK Interface Kanban Processing
ND3N3157	dcLINKKanbanProcessing	dcLINK Interface Kanban Processing
DD3N3107		PO Retrieval Kanban Processing
BD3N3107	PORetrieveKanbanProcessing	PO Retrieval Kanban Processing

The full name of this interface is ND3N3157 Kanban Processing

This interface guide applies to the following JDE versions.

EnterpriseOne Xe through 9.1

Corresponding EnterpriseOne application

In EnterpriseOne, the application you would run to check in/out Kanban cards is P3157 and can be found on menu G3115.

Processing options

Processing options for Kanban Processing.

The dream writer version will default to ZJDE0001 if not otherwise specified in the parameter list on the call. The version really should be passed and not defaulted. Typically, the Kanban check out uses one version, while the Kanban check in uses a completely different version.

Mode tab

Mode: If this set to a ‘1' it signals the Kanban supply mode. If it is blank, it signals the Consumption mode. Since this field can only be one or the other, there are separate versions for check ins and check outs

Defaults tab

Be aware that on this tab the item number, location, employee number, and vendor number can all be defined and “defaulted” into the transaction. While E1 gives you the ability to default this information, most of the time it is not defaulted but rather entered on the transaction.

Process tab

Each entry on this tab allows the execution of a function blindly by keying a ‘1' into the processing option. In all cases for dcLINK, each of these functions should have a ‘1' for blind execution.

Processing option data structure for DD3N3107

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

Type	Description	Parameter
String	szPOVersion_VERS	Input
Char	cPO_SetMode_EV01	Output
Char	cPO_PromptConfirmation_EV01	Output
Char	cPO_Kanbanstatus_KBST	Output
String	szPO_ItemNoUnknownFormat_UITM	Output
String	szPO_Location_LOCN	Output
Numeric	mnPO_HoursPerDay_MATH01	Output
String	szPO_ClosedStatusCode_SRST	Output
String	szPO_TypeBill_TBM	Output
String	szPO_AlternateAddressKey_ALKY	Output
Char	cPO_CallWOProcessing_EV01	Output
Char	cPO_HoursQuantitiesBlind_EV01	Output
Char	cPO_IssueBlind_EV01	Output
Char	cPO_CompletionsBlind_EV01	Output
Char	cPO_ShipConfirmBlind_EV01	Output
Char	cPO_InvTransfersBlind_EV01	Output
Char	cPO_PurchaseOrder_EV01	Output
Char	cPO_EDITTransaction_EV01	Output
String	szPO_RateHeaderMaintVers_VERS	Output
String	szPO_PartAvailabilityVers_VERS	Output
String	szPO_WOEntryVers_VERS	Output
String	szPO_WOProcessingVers_VERS	Output
String	szPO_OpenOrdersInqVers_VERS	Output
String	szPO_POEntryVers_Vers	Output
String	szPO_POPrintVers_VERS	Output
String	szPO_POReceiptsVers_VERS	Output
String	szPO_SuperBackflushVers_VERS	Output
String	szPO_HoursQuantitiesVers_VERS	Output
String	szPO_IssuesVers_VERS	Output
String	szPO_CompletionsVers_VERS	Output
String	szPO_InvTransfersVers_VERS	Output
String	szPO_SOEntryVersion_VERS	Output
String	szPO_ShipConfirmVersion_VERS	Output
String	szPO_ReceiptLocation_LOCN	Output
String	szPO_ItemCompVersion_VERS	Output
Date	jdPO_DateTransFrom_DTFR	Output
Date	jdPO_DateTransThru_DTTO	Output

Processing

Kanban transaction processing.

Kanban is a relatively easy transaction to execute. It does not require a lot of input but, because it does so much, it can be confusing as to what is really happening. The first place to start in understanding Kanbans is the type of Kanban, often called the source type. The four most common source types are:

Kanban is supplied by a work center or rate (in other words - manufacturing).
Kanban is supplied by available inventory (in other words - transfers).
Kanban is supplied by a purchase order from a defined supplier.
Kanban is supplied by a purchase order from a defined supplier who provides the labor for the item. A sales order is created to sell the material for making the item to that supplier.

Each type can be defined as a one-phase or two-phase Kanban. A one-phase Kanban can only have two statuses: check-in or check-out. A two-phase Kanban has three statuses: check-in, check-out, and complete.

The following table shows what happens to a Kanban for each source type, and whether it is one-phase or two-phase.

Source	Phase	Check-in Kanban status = 1	Check-out Kanban status = 2	Complete Kanban status = 3
1 Work Order or Rate	1	The Work Order or Rate that was created at checkout will be completed using Super Backflush. The completion will be to the supplying location. A transaction to transfer the inventory from the supplying location to the consuming location will be generated blindly. IC transactions for completion of work order. IM transaction for the issue of the components on the work order. IH transaction for the labor hours on the work order. IT transaction for the transfer of the material from the supply location to the consuming location.	A Work Order or Rate will be created if an existing one is not found at less than the processing option status. If the processing option is set to run R31410, the part list and routing will be attached.	N/A
1 Work Order or Rate	1	A transaction to transfer the inventory from the supplying location to the consuming location will be generated blindly. IT transaction for the transfer of the material from the supply location to the consuming location.	A Work Order or Rate will be created if an existing one is not found at less than the processing option status. If the processing option is set to run R31410, the part list and routing will be attached.	The Work Order or Rate that was created at checkout will be completed using Super Backflush. The completion will be to the supplying location. IC transactions for completion of work order. IM transaction for the issue of the components on the work order. IH transaction for the labor hours on the work order.
2 Inventory	1	A transaction to transfer the inventory from the supplying location to the consuming location will be generated blindly. IT transaction for the transfer of the material from the supply location to the consuming location.	No actions will be initiated.	N/A
2 Inventory	2	A transaction to transfer the inventory from the supplying location to the consuming location will be generated blindly. IT transaction for the transfer of the material from the supply location to the consuming location.	No actions will be initiated.	No actions will be initiated.
3 Supplier	1	The Purchase Order that was created at checkout will be received if the Kanban Receipts flag is on in the Kanban Master record. The item will be received at the supplying location. If the Kanban receipts flag is not on, no transaction will occur. A transaction to transfer the inventory from the supplying location to the consuming location will be generated blindly. OV transaction if the Receipts flag is on. IT transaction for the transfer of the material from the supply location to the consuming location.	A Purchase Order will be created if an existing one is not found, as long as the processing option is set to do so.	N/A
3 Supplier	2	A transaction to transfer the inventory from the supplying location to the consuming location will be generated blindly. IT transaction for the transfer of the material from the supply location to the consuming location.	A Purchase Order will be created if an existing one is not found, as long as the processing option is set to do so.	The Purchase Order that was created at checkout will be received if the Kanban Receipts flag is on in the Kanban Master record. The item will be received at the supplying location. If the Kanban receipts flag is not on no transaction will occur. OV transaction if the Receipts flag is on.
4 Outside Assembly	1	The Purchase Order that was created at checkout will be received if the Kanban Receipts flag is on in the Kanban Master record. The item will be received to the supplying location. If the Kanban receipts flag is not on no transaction will occur. Ship Confirmation will be performed for the corresponding Sales Order. A transaction to transfer the inventory from the supplying location to the consuming location will be generated blindly. OV transaction if the Receipts flag is on. SO transaction for the confirmation of the shipment of the components. IT transaction for the transfer of the material from the supply location to the consuming location.	A Purchase Order will be created if an existing one is not found, as long as the processing option is set to do so. At the same time a Sales Order will be created for the components of the item, with the supplier as the customer.	N/A
4 Outside Assembly	2	A transaction to transfer the inventory from the supplying location to the consuming location will be generated blindly. IT transaction for the transfer of the material from the supply location to the consuming location.	A Purchase Order will be created if an existing one is not found, as long as the processing option is set to do so. At the same time a Sales Order will be created for the components of the item, with the supplier as the customer.	The Purchase Order that was created at checkout will be received if the Kanban Receipts flag is on in the Kanban Master record. The item will be received to the supplying location. If the Kanban receipts flag is not on no transaction will occur. Ship Confirmation will be performed for the corresponding Sales Order. OV transaction if the Receipts flag is on. SO transaction for the confirmation of the shipment of the components.

dcLINK processing

We use three different action codes (cActionCode_ACTION) values to control processing. A value of ‘I' tells this interface to issue the entire license plate. A value of ‘T' tells the interface to transfer the entire license plate. A value of ‘D' tells the interface to delete the license plate.

Required fields

Very little is required to perform a Kanban transaction. The hard part is the setup of the Kanban.

If you are checking out a type 1, Manufacturing Kanban, you need to pass the branch/plant, Kanban ID, Kanban card number, and a ‘0' in the check in/out button field (cBTNCheckInOut_EV02). To check in a Kanban, pass the same info, except pass a ‘1' in the check in/out field and also include the shift code and employee number.

If you are checking out a type 2, Inventory Kanban, pass the branch/plant, Kanban ID, Kanban card number, and a ‘0' in the check in/out field. The same fields are passed for check in. Just change the value of the check in/out field to a ‘1'.

If you are checking out a type 3, Purchase Order Kanban, pass the branch/plant, Kanban ID, Kanban card number, and a ‘0' in the check in/out field. The same fields are passed for the check in. Just change the value of the check in/out field to a ‘1' and also pass the default supplier ID.

Best practice

Always include the processing option version with the transaction being executed. If nothing is passed, it will default to ZJDE0001, and while that may work for either the check in or check out, depending on how the version is setup, the other half of the check in/out is usually a different version.

While it is possible to default the shift, employee, and supplier in the processing options, it is much cleaner to pass that information in on the transaction and it heightens the awareness of what is required to perform the transaction.

Verify the processing

CARDEX is the main application to verify the processing.

To verify the processing, complete the following steps in JDE.

Open CARDEX to verify the following transactions display.
Step Information
IC to show the completion of a manufactured item.

IM to show the issue of parts needed to build a manufactured item.

IT to show an item being transferred from the supplying location to the consuming location.

OV to show an item was received on a purchase order.

SO to show an item was shipped to the supplier so they could assemble it.

Input data structure

Input data structure for DD3N3157.

Name	Default value	R/O	Alias	Notes
cdcLINKActionCode_EV01	0	X	EV01
cActionCode_ACTION		X	ACTION
jdDateUpdated_UPMJ	Current Date	X	UPMJ	Retrieved from GetAuditInfo.
mnTimeUpdated_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	ND3N3157	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.
cDefaultShiftCode_SHFT		O, R	SHFT	This field is required if doing a Check In. It can be defined in the processing option version that is being run.
szDefaultEmployeeNumber_ALKY		O, R	ALKY	This field is required if doing a Check In. It can be defined in the processing option version that is being run.
szDefaultSupplierNumber_ALKY		O	ALKY	This field is used if the Kanban is creating a purchase order.
szBranchPlant_MCU		X	MCU	If not passed in, this field will default from the Kanban Master file (F3016).
mnKanbanID_KID1		R	KID1	This is the key to the Kanban Master file. This, together with the card number, must point to a valid Kanban record.
mnKanbanCardNumber_CDN		R	CDN	This is the key to the Kanban Master file. This, together with the Kanban ID, must point to a valid Kanban record.
mnQuantityTransaction_TRQT		X	TRQT	If not passed in, this field will default from the Kanban Master file (F3016).
szLotSerialNumber_LOTN		O, R	LOTN	This field is required if the item number associated with the Kanban is a lot controlled item.
cBTNCheckInOut_EV02	0	O	EV02	Used to simulate a button was pressed on the application. 0 = Check Out 1 = Check In
cBTNComplete_EV03	0	O	EV03	A value of ‘1' has to be entered in order to perform the Complete process of a 2 phase putaway.
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 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.

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	Check out- Manufacturing	Check in- Manufacturing	Check out- Inventory	Check in- Inventory
cdcLINKActionCode_EV01
cActionCode_ACTION
jdDateUpdated_UPMJ
mnTimeUpdated_TDAY
szUserId_USER
szWorkStationId_JOBN
mnJobNumber_JOBS
szProgramId_PID
szVersion_VERS	ZDBK0001	ZDBK0002	ZJDE0001	ZJDE0002
cSuppressErrMsg_EV01
cErrorCode_ERRC
szErrorMessageKey_EKEY
iDebugLevel_INT01
cDefaultShiftCode_SHFT		1
szDefaultEmployeeNumber_ALKY		6001
szDefaultSupplierNumber_ALKY
szBranchPlant_MCU	M30	M30	M30	M30
mnKanbanID_KID1	685	685	689	689
mnKanbanCardNumber_CDN	1	1	1	1
mnQuantityTransaction_TRQT	1100	1100	500	500
szLotSerialNumber_LOTN
cBTNCheckInOut_EV02	0	1	0	1
cBTNComplete_EV03
szGuidUniqueID_GUID
szGuidApprover1_USR1
szGuidFullName1_FULLNAME1
szGuidApprover2_USR2
szGuidFullName2_FULLNAME2
mnGuidReasonCode1_REASON1
szGuidCommentField_COMMENTS
mnGuidReasonCode2_REASON2
szGuidCommentField2_2COMMENTS
szGuidScriptID_FMNMVERS
szGuidTextMessage_TEXTMES

Common error messages

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 error message can result from any of the following conditions. 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 Inf, or dcLINK Utility Write Signature Capture Record. The required field, kanban ID (mnKanbanID_KID1), was not passed into this NER. The required field, kanban card number (mnKanbanCardNumber_CDN), was not passed into this NER. The processing option set mode is equal to supply (“1”). The check in/out button (cBTNCheckInOut_EV02) is set to perform a check out (“0”), but the complete button (cBTNComplete_EV03) is not set to a ‘1'. The processing option set mode is equal to consumption (blank), and the complete button (cBTNComplete_EV03) is equal to ‘1'. The check/in out button (cBTNCheckInOut_EV02) is set to do a check in (“1”), and the complete button (cBTNComplete_EV03) is equal to a ‘1'. The fetch from the Kanban Master file (F3016) failed. The key is the Kanban ID (mnKanbanID_KID1).
0037	Address Number Invalid. This error is returned from the Kanban Cache Process business function. The address book number – either employee (szDefaultEmployeeNumber_ALKY) or vendor (szDefaultSupplierNumber_ALKY) – is invalid.
011S	Purchase Order Header record not found. When the order number field from the Kanban Master file (F3016) is zero, and the business function to retrieve open purchase orders fails, this error is displayed.
039L	Kanban Status Invalid to Check In. This error is displayed when the Kanban Check In Edit Line fails, and the Kanban status from the Kanban Master file is equal to ‘1'.
039M	Kanban Status Invalid to Check Out. This error is displayed when the Kanban Check Out Edit Line fails, and the Kanban status from the Kanban Master file is equal to ‘2'.
051E	Shift Code is Not Defined. This error is returned from the Kanban Cache Process business function. The shift number (cDefaultShiftCode_SHFT) is invalid.
1198	No Routing or Process Exists. When the Kanban processing is running a super backflush process, it calls a business function to check for routings. If this function fails, this error is returned.
148Z	Invalid PO Status for Receipt. This interface reads all the purchase order detail records for a specific order/item combination. It checks to find a line whose next status is one of the three valid statuses, as defined in the processing options for PO Receipts (P4312). If no records are found this error is displayed. The version used to retrieve the processing options comes from the Kanban processing options.
2745	Lot/Serial Number Must be Entered. This error is returned from the Kanban Cache Process business function. The lot/serial number (szLotSerialNumber_LOTN) is invalid.

There was a problem loading this topic

Mobile Enterprise Platform