P4312 not in F43121

[lavh]

When we do a Po reception with P4312, the system write the transaction in the F4111 and the F41021, but not in F43121 and not in F4311. So my inventory was affect but we could do the reception twice and no payable was generate.

Denver does not find anything to help us. We are not able to reproduce the case, but a lot of user have the problem. In debug, the case does not appear !!!

Thanks

ERP8.0 SP22 Win2K Citrix metaframe XP

 

[Krofire.com]

I can offer sympathy. I feel there should be a white paper out there titled "So your experiencing Data Integrity Problems". I also sympathise with PeopleSoft as this is next to impossible to reproduce. You admit you can't reproduce it yourself. Yes, it happens when large volumes of transactions go through the system. You best bet is to switch some kind of logging on in the Database and see what is happening at that level. I really know little about it but I learnt that we ended up having to live with it and generate Reports to show the problems and Programs to fix it.

Have you taken everything back to basics on a fat client in Pristine software? Does it only happen in Citrix? Do you have any technical architecture using Load Balancing, Data-Mirroring or such-like?

 

[Aarto]

Hi There!

I have seen this a lot and there is only one way (as far as i know) to stop this from happening. (And i've been complaining about this since 1999)
Turn off the asynchronous processing in the goods receipts. It requires a small modification in the application P4312 itself, the instances where the Master business fucntion for receipts is called must be changed from Asynchronous to synchronous. (I think it's called F4312EndDoc)
This will force P4312 to process all the receipts before the screen is released and the user can go on to other tasks. If you have very large purchase orders, this may be a problem but it will surely stop the integrity problems.

As for fixing the failed transactions, we have used following method
1. Reverse the receipts for all the lines on the OV document that were written to F43121 (normally, some lines for the failed receipt are actually written to F43121)
2. Delete (By SQL) all the Item ledger entries for the failed OV document (If As-of process has been run, you will have to regenerate the As-of data)
3. Void the G/L entries for the failed OV document
4. Update Quantity on hand for the failed lines to the same level as before the receipt.

hope this helps...

 

[Krofire.com]

Aarto - Interesting. This Post now follows the same solution as another, concurrent Post on the 'List, dealing with duplicate Cardex records. Is this changing of the Master Business Function from Asynchronous to Synchronous a panacea for this kind of problem?

I have seen the same kind if problems with both Work Order Completions (P31114) and Work Order Issues (P31113). Do you know if this fix has been tried in Manufacturing?

 

[Aarto]

Yes, i have found that this cures some 99% of all errors in goods receipts (at least for release ERP8 and earlier)


Apparently it's all down to how OneWorld manages the cache in the receipt processing. The cache seems to get correupted when user inquires on open purchase orders or does anything remotely related after a receipt has been started and is running in the background. Obviously, i have not been duplicate the errors but the asynch processing is definately the culprit. Once the process is run in synchronous mode, the user can not perform any actions that could corrupt the cache

The only drawback is that the screen will be "frozen" until the receipt has been completely processed but i think that is still better than to run SQL updates to fix failed receipts...

 

[Aarto]

Sorry, didn't reply on the last sentence..

I do not have a lot of experience in manufacturing but i do know that turning the asynch process of does correct the problems in Shipment confirmations (P4205) as well, so it seems to be a universal cure. I can only gues that this would also help with manufacturing as i believe the technology/method used in the asynch processing is not very safe.

Obviously, it is only the master business fucntions that have the asynch option but i'd belive that the manufacturing ones also have this option.

Turning off the asynch process does increase the bandwith usage if you're running on Citrix or if the business functions are mapped on the server ("W-environments") but the increase is not too high. It is something that should be planned for in environments with very large number of transactions per day.

 

[levm4]

When we do a Po reception with P4312, the system write the transaction in the F4111 and the F41021, but not in F43121 and not in F4311. So my inventory was affect but we could do the reception twice and no payable was generate.

Denver does not find anything to help us. We are not able to reproduce the case, but a lot of user have the problem. In debug, the case does not appear !!!

Thanks

ERP8.0 SP22 Win2K Citrix metaframe XP

 

[Aarto]

The wonderful thing about debug is that it overrides the process so the Master business functions are called synchronously (i.e NO background process) because otherwise it would not be possible to catch the break points. This is why it can not be duplicated in debug...

The process runs synchronously - No errors

 

[Nancy_x]

Turn off the asynchronous processing in the goods receipts. It requires a small modification in the application P4312 itself, the instances where the Master business fucntion for receipts is called must be changed from Asynchronous to synchronous.

Hi, Aarto,

I also met this kind of thing when doing shipment confirmation. I wonder if there is a easier way to turn on
synchronous processing. Do you know P90701? What is this program used for?

Best Regards