DSI Ship Confirm does not update Cardex on network/system failure

Abir Mannan

Active Member
Hi, Not sure yet if its a DSI issue or JDE also not sure if its technical issue or setup issue.
So DSI scan the items to ship confirm, in middle of ship confirm if some network outage happen, the Ship confirm process fine, it updates the status, sales ledger Etc. But it does not release the inventory and dont write in the F4111.
Just checking if anyone faced similar problem. Still going through if it is a DSI problem or JDE. Looks like JDE issue because when DSI calls the JDE MBF, it does process the ship confirm but fails at 1 point.
Unable to recreate the issue.
Any information will be great.
Thanks..
 
"Looks like JDE issue ..."

"if some network outage happen"

Sounds like a network issue to me ...

Your experience matches what I have seen also.
In general you will find that most complex transactions in JDE do not have complete rollback.
 
Hi, It sounds that is not a DSI, and not a JDE issue. The Ship Confirmation Business Functions calls other business functions. It is pretty involved BSFN, and it calls many more supporting functions. If your network connectivity is lost, then you will end-up with an incomplete ship confirmation transaction.
 
Hi Larry,
I hate that fact about not having rollback.
Were you able to fix the problem that you saw? or any other workaround?
 
Thanks Rob, but that sounds like JDE bug and i would say that will be a bad bug because in that case we will face the same problem even with the Ship Confirm Application.
 
just a thought ...

Assuming DSI is calling it's ship confirm NER, I wouldn't say a network issue caused this. DSI sends the single function call via XML and waits for the return (again assuming not asynch). A disconnect from the scanner would have no effect on the function running on the E1 server. It will just do it's thing and not have a client to send the resulting XML to. So the issue could be a bug in the DSI NER wrapper or indeed with the JDE MBF. If the network was the issue that caused the half-baked transaction, it would be with the enterprise server communicating with the database server. In that case you should see systemic issues affecting all activity at that time.

DSI does log all it's function call activity. Perhaps reviewing that and the call object kernel logs on the E1 server could shed some light.

Craig
 
In P4205, there is a processing option (under the Process tab) that controls whether or not inventory is relieved at time of Ship Confirmation. Also, you need to add document types to the 40/IU UDC table for all order types you wish to update inventory for.

Maybe this might provide some insight on what you're seeing.
 
This also may be different based on the version you're running. Xe has a tendency not to roll-back ship-confirm transactions, but later versions are more resilient. What version are you running, Abir ?
 
Ditto to what Don said - that's what caught me out with DSI ship confirm... but when I used P4205 with the same version, the inventory did relieve - go figure.
 
Also would depend on how you are calling Ship Confirm(interface or E1 internal) and where the error occurs. If its on End doc then chances are more that part will be updated and part not if its called from interface and transaction processing is not set correctly.

Chan
 
Have you checked in F41021WF or the program P42210 to see if the failed transaction is in there? Supposedly R42210 will correctly replay some of the failed transactions, but I've never gotten it to work reliably.
 
Hi. I have another issue. When doing PO Receipts with DSI, one purchase order may have 20 lines. When doing the receipt of the PO, DSI creates a different OV # for each line on the PO, even though it is received at the same time. This is not an issue when receiving directly into JDE. It creates one OV# for all the lines. Has anyone experienced this with DSI? I think it may be a mapping/configuration issue with DSI.

Your comments will be appreciated.

Thanks.
Mark
 
Hi. I have another issue. When doing PO Receipts with DSI, one purchase order may have 20 lines. When doing the receipt of the PO, DSI creates a different OV # for each line on the PO, even though it is received at the same time. This is not an issue when receiving directly into JDE. It creates one OV# for all the lines. Has anyone experienced this with DSI? I think it may be a mapping/configuration issue with DSI.

Your comments will be appreciated.

Thanks.
Mark

It better to open new thread then activating an old thread which has to relation except DSI.
 
Back
Top