Super Backflush interface for JD Edwards
About the Super Backflush interface
Super backflush is a manufacturing transaction that allows issues, completions, and hours and quantities to be posted against a work order with a single transaction.
The catch to this process is that everything is recorded at standard. MEP only supports a “blind” super backflush transaction. Blind means that based on the quantity reported for the super backflush transaction, the program will determine how many issues, completions, and hours to record. The dcLINK version is called ND3N1123. This interface was written in NER and calls ‘C' business function, BD3N3102, to retrieve the processing options.
| Name | Function name | Description |
|---|---|---|
|
DD3N1123
|
dcLINK Interface Super Backflush
|
|
|
ND3N1123
|
dcLINKSuperBackFlush
|
dcLINK Interface Super Backflush
|
|
DD3N3102
|
PO Retrieval Super Backflush
|
|
|
BD3N3102
|
PORetrievalSuperBackflush
|
PO Retrieval Super Backflush
|
The full name of this interface is ND3N1123 Super Backflush
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 perform a super backflush entry is P31123 and can be accessed from the menu G3112.
Processing options
Processing options for Super Backflush.
The dream writer version will default to ZJDE0001 if not otherwise specified in the parameter list on the call. Many times MEP is able to use the same processing option version that the EnterpriseOne application uses. Rarely with super backflush is that true. MEP has to have blind processes. Be sure to double check that this is how the version is setup
Caution: Work order completions can be configured in the processing options to also perform blind work order issues. When setting up processing options for super backflush, you must be very careful and deliberate in configuring the processing options to avoid double issues.
Process tab
-
Work Order Completions: This field must have a ‘1' for a blind work order completion. szPO_DocumentType_DCT
-
Work Order Issues: This field must have a ‘1' for a blind work order issues. szPO_StatusCode_SRST
-
Hours and Quantities: This field must have a ‘1' for a blind hours and quantities.
Edits tab
-
Validate Quantity at Operation: This field acts as a control to make sure the work order is processed in the correct sequence. Let's say a work order has four operations; 10, 20, 30, and 40. If this field is blank, the order in which the sequence numbers are processed is not enforced. Operation 10 could be done, then operation 40, 20, and 30. If this field is not blank, then the program checks to make sure there is enough quantity at the step being processed to allow the operation to continue. For example, 10 items were reported complete at step 10 – there are now 10 items available at step 20. If a transaction is done to report 10 items at step 40, then an error will be generated, because there are no items available at that step. If the work order is at this status or higher the super backflush transaction will not be allowed to run.
Versions tab
-
Hours and Quantities (P311221): Enter the version number to be used. If nothing is entered, the version used is ZJDE0001. Even though we are processing blind, the super backflush MBF will use this version to determine rules of processing for hours and quantities.
-
Work Order Issues (P31113): Enter the version number to be used. If nothing is entered, the version used is ZJDE0001. Even though we are processing blind, the super backflush MBF will use this version to determine rules of processing for work order issues.
-
Work Order Completions (P31114): Enter the version number to be used. If nothing is entered, the version used is ZJDE0001. Even though we are processing blind, the super backflush MBF will use this version to determine rules of processing for work order completions.
Processing option data structure
Our interface retrieves these parameters by calling BD3N3102 and is passed back in the following data structure.
| Type | Description | Parameter |
|---|---|---|
|
String
|
szVersion_VERS
|
Input
|
|
String
|
szPartialCompletion_OPST
|
Output
|
|
String
|
szFullCompletion_FOSE1
|
Output
|
|
String
|
szStatusCodeWo_SRST
|
Output
|
|
String
|
szHoursQtysVersion_V001
|
Output
|
|
String
|
szIssuesVersion_V002
|
Output
|
|
String
|
szCompletionsVersion_V003
|
Output
|
|
String
|
szTestResultsVersion_V004
|
Output
|
|
String
|
szBackflushStatus_SRST
|
Output
|
|
Char
|
cCompletionsBlindExecution
|
Output
|
|
Char
|
cIssuesBlindExecution_EV02
|
Output
|
|
Char
|
cHoursQuantitiesBlindEx_EV03
|
Output
|
|
Char
|
cQuantityAtOperationFlag_EV04
|
Output
|
|
String
|
szSchedulingWorkBenchVers_V005
|
Output
|
|
String
|
szWOEntryVersion_V006
|
Output
|
|
Char
|
cApplyYield_APYD
|
Output
|
|
Numeric
|
mnEmployeeNumber_AN8
|
Output
|
|
String
|
szWOTypeTransaction_TYTN
|
Output
|
|
Char
|
cWOBeforImageProcessing_BIPROC
|
Output
|
|
Char
|
cShiftCode_SHFT
|
Output
|
Processing
Processing information for Super Backflush.
Because Advanced Inventory only supports blind super backflush transactions, this really is an easy interface in terms of what needs to be passed in. The interface does a lot, and there are lots of places to check to make sure the interface completed and updated everything, but the input is pretty simple.
The principle behind super backflush is that the material on a parts list has been flagged to be backflushed, and some operations on a routing have been setup as pay points. Backflush occurs at the pay points, and affects all the operations and material between this pay point and the previous pay point. At each pay point the quantity completed (or scrapped) is being reported. It is completely up to the client which operations are set up as pay points in the routing.
For example, let's say a work order has six operations: 10.00, 20.00, 30.00, 40.00, 50.00, and 60.00. Of those six operations, only three are pay points: 20.00, 40.00, and 60.00. To fully super backflush this work order will require three transactions. The first transaction reports the quantity complete at operation 20.00. The next transaction does the same for operation 40.00, and the final transaction reports the completion for operation 60.00.
To perform this transaction in EnterpriseOne requires three transactions. It takes three transactions in dcLINK as well. However, if nothing is changing, the same worker completes the same quantity at each step, then dcLINK can offer a “short cut”. A dcLINKActionCode of ‘1' tells the interface to process one pay point at a time. A dcLINKActionCode of ‘0' tells the interface to process all the pay points for the order. The catch is, with a dcLINKActionCode of ‘0', each pay point will be reported identically: the same quantity complete, the same quantity scrapped, the same worker, the same shift, etc.
Required fields
The MEP action code, work order number, employee number, sequence number, quantity completed (and/or scrapped), and shift code are the required fields. The employee and shift code could be defaulted in from the processing options, but we find this approach so limiting that it's hard to imagine anyone would process that way. Version number is not a required field, but as we have said many other times, to default the version, especially for super backflush, is not a safe practice due to the requirement of blind processing.
Verify the processing
To verify the super backflush, check three sections, issues, hours and quantities, and completions.
Because super backflush does so much work, this is really the hard part, checking to see that everything was updated the way it should be. There are three basic parts to super backflush: issues, hours & quantities, and completions.
Depending on what is being completed there may be some additional checking that can be done. For example, is the item being manufactured under lot control? If it is, then a lot master record should have been created.
To verify the processing, complete the following steps in JDE.
-
Check each of the following sections to determine if the super backflush transaction worked.Step Information
-
Issues: Super backflush will issue all the eligible material between the previous pay point, and the pay point being processed. The key is eligible material. Each component on a parts list has an issue code. This code has to be set with either a ‘B' or a ‘U', to be issued when super backflush is run. When an issue occurs, the results can be viewed in a couple of places. One place is CARDEX. Inquiring on the component item number, there should be an entry. The quantity that is reported complete is the quantity that super backflush has determined is required to be issued, in order to have completed the quantity entered.Attention:For example, if it takes two of this part for each item completed, and 15 items were reported as complete, then you would expect to see 30 for the component quantity. The other place to look is the parts list itself. There is a column call issue quantity, and it is updated each time an issue is made.
-
Completions: Super backflush is smart enough to only perform a completion at the last operation. Like an issue, there are a couple of places where you can look to make sure a completion occurred. Again, look at CARDEX. This time, inquire using the item number of the part being manufactured. The quantity in CARDEX should match exactly to the quantity reported on the super backflush transaction. The other place to look is the on the order itself. If you inquire on the order on the Dates & Qtys tab, it shows how many items have been completed and scrapped.
-
Hours & Quantities: An hours and quantities entry will be generated based on standard hours keyed in routing of the work order. Super backflush, when run blind, assumes everything is completed at standard. The employee number and shift used to create this transaction is part of the information passed in on the super backflush call. The quantity part of this entry will match exactly the quantity completed and scrapped that was entered in the super backflush transaction. To view the hours and quantities transactions that get created, go to G3112 and double click on P311221. Inquire by order number.
-
Input data structure
Input Data Structure for DD3N1123.
| Name | Default value | R/O | Alias | Notes |
|---|---|---|---|---|
|
cdcLINKActionCode_EV01
|
0
|
X
|
EV01
|
MEP Action Codes: Values 0, 2, 7 are valid and have their standard meanings.
|
|
cActionCode_ACTION
|
1
|
ACTION
|
The Action Code “2” will update the User ID in the Cardex record.
|
|
|
jdDateUpdated_UPMJ
|
(today)
|
X
|
UPMJ
|
Returned from GetAuditInfo if not passed in.
|
|
mnTimeUpdated_TDAY
|
(now)
|
X
|
TDAY
|
|
|
szUserId_USER
|
(current user id)
|
X
|
USER
|
|
|
szWorkStationId_JOBN
|
(current workstation id)
|
X
|
JOBN
|
|
|
mnJobNumber_JOBS
|
X
|
JOBS
|
||
|
szProgramId_PID
|
ND3N1122
|
X
|
PID
|
Generally leave this blank and let it default in.
|
|
szVersion_VERS
|
ZJDE0001
|
X
|
VERS
|
This is used by function to look up the appropriate set of processing options.
|
|
cSuppressErrMsg_EV01
|
O
|
EV01
|
Enter a 1 here to suppress error messages – not recommended. You should usually leave this field blank.
|
|
|
cErrorCode_ERRC
|
ERRC
|
Indicates an error condition. Set by program.
|
||
|
szErrorMessageKey_EKEY
|
EKEY
|
Holds JDE error message number.
|
||
|
iDebugLevel_INT01
|
O
|
INT01
|
Leave blank except for debugging and testing purposes only. Higher numbers will show more debug dialog boxes. Leave this blank, or set to suppresses all debug dialog boxes. Do not leave a value greater than 0 in this field after initial setup and testing as it will cause synchronous dialogs on the computer to pop up when the function is called.
|
|
|
mnOrderNumber_DOCO
|
R
|
DOCO
|
Work order number
|
|
|
mnEmployeeNumber_AN8
|
R
|
AN8
|
Address book number of employee
|
|
|
mnSequenceNumber_SEQU
|
R
|
SEQU
|
Operation sequence number.
|
|
|
mnInputQtyCompleted_QT01
|
R
|
QT01
|
The quantity being reported as “good” or “completed”.
|
|
|
mnInputQtyCanceled_TRQT
|
R
|
TRQT
|
The quantity being reported as “bad” or “scrapped”.
|
|
|
szInputOpStatusCode_OPST
|
R
|
OPST
|
The status that the operation will be updated to. Validated against the UDC table 31/OS.
|
|
|
cInputPayPointStatus_PPRF
|
O
|
PPRF
|
The pay point status. Validated against the UDC table 31/PP.
|
|
|
szInputUnitOfMeasure_UOM
|
O
|
UOM
|
Unit of measure that matches the quantity being reported (cases, eaches, etc.). Validated against the UDC table 00/UM.
|
|
|
cProcessedCode_YST
|
R
|
YST
|
||
|
cShiftCode_SHFT
|
R
|
SHFT
|
Shift Code. Validated against the UDC table 06/SH.
|
|
|
jdDateTransactionJulian_TRDJ
|
X
|
TRDJ
|
The date of this transaction. If not entered it will default to the current date.
|
|
|
szGuidUniqueID_GUID
|
Automatically generated by dcLINK
|
O
|
CFRGUID
|
If generate GUIDs is turned on in the MEP 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 MEP. 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 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.
|
|
|
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. MEP captures the script ID.
|
|
|
szGuidTextMessage_TEXTMES
|
O
|
TEXTMES
|
This is a free form entry field.
|
|
|
szEquipmentNumber_ASII
|
O
|
ASII
|
||
|
cCrossDockFlag_EV01
|
O
|
EV01
|
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 | Single paypoints | Multiple paypoints |
|---|---|---|
| cdcLINKActionCode_EV01 |
1 |
0 |
| cActionCode_ACTION |
||
| jdDateUpdated_UPMJ |
||
| mnTimeUpdated_TDAY |
||
| szUserId_USER |
||
| szWorkStationId_JOBN |
||
| mnJobNumber_JOBS |
||
| szProgramId_PID |
||
| szVersion_VERS |
ZDBK001 |
ZDBK001 |
| cSuppressErrMsg_EV01 |
||
| cErrorCode_ERRC |
||
| szErrorMessageKey_EKEY |
||
| iDebugLevel_INT01 |
||
| mnOrderNumber_DOCO |
453405 |
453405 |
| mnEmployeeNumber_AN8 |
6001 |
6002 |
| mnSequenceNumber_SEQU |
20.00 |
80.00 |
| mnInputQtyCompleted_QT01 |
10 |
10 |
| mnInputQtyCanceled_TRQT |
||
| szInputOpStatusCode_OPST |
||
| cInputPayPointStatus_PPRF |
||
| szInputUnitOfMeasure_UOM |
||
| cProcessedCode_YST |
||
| cShiftCode_SHFT |
1 |
1 |
| jdDateTransactionJulian_TRDJ |
||
| szGuidUniqueID_GUID |
||
| szGuidApprover1_USR1 |
||
| szGuidFullName1_FULLNAME1 |
||
| szGuidApprover2_USR2 |
||
| szGuidFullName2_FULLNAME2 |
||
| mnGuidReasonCode1_REASON1 |
||
| szGuidCommentField_COMMENTS |
||
| mnGuidReasonCode2_REASON2 |
||
| szGuidCommentField2_2COMMENTS |
||
| szGuidScriptID_FMNMVERS |
||
| szGuidTextMessage_TEXTMES |
||
| szEquipmentNumber_ASII |
||
| cCrossDockFlag_EV01 |
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.
In the context of this BF, this error is returned when an error has been detected from one of these three business functions: MEP Set User ID, MEP Utility Set Audit Info, or MEP Utility Write Signature Capture Record.
|
|
113C
|
Reserved By.
This message is returned if the work order being processed is currently open in another application by a different user.
|
Loading...
There was a problem loading this topic