MSCM upload error

I will be out of the office Monday, September 12th. Please direct your requests for support from Financial Systems to the FINSYS mailbox at FINSYS@geisinger.edu.



>>> 09/12/11 13:26 >>>

Lawson S3 Supply Chain Forum Notification
----------------------------------------------------------------
Posted by:Roger
Date: 09/12/2011 11:14 AM
Subject: MSCM upload error
Message:
----------------------------------------------------------------
Getting the error: "Cannot change requisition has been processed" on some reqs and lines when uploading handheld data. Has anyone dealt with this error before. We are seeing on random par locations, but is occurring daily on at least 1 par per day.

Thank you
----------------------------------------------------------------
To view the complete thread and reply via your browser, please visit:
https://www.lawsonguru.co...n/mscm-upload-error/

Thank you,
LawsonGuru.com

You were sent this email because you opted to receive email notifications when someone posted and/or responded to a message on this forum. To unsubscribe to this thread please visit your user profile page and change your subscription options.


IMPORTANT WARNING: The information in this message (and the documents attached to it, if any) is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken, or omitted to be taken, in reliance on it is prohibited and may be unlawful. If you have received this message in error, please delete all electronic copies of this message (and the documents attached to it, if any), destroy any hard copies you may have created and notify me immediately by replying to this email. Thank you.

Is this a retry?  You uploaded and got an error and your trying to submit it again?  Or you get this error on the first upload?

No, it haappens on the first upload.

I know this is an older thread but does anyone have an explanation why this happens? We have random incidents where users receive the error message "cannot change requisition has been processed". Those lines do not load to a requisition but the other lines appear to be fine. This is on the first upload attempt.

Like with Roger I've not seen this before other than when you attempt to resend the data to S3. It sounds like the req is being released prematurely before all lines have been uploaded. Do you have any processes outside of MSCM that auto-release unreleased reqs?

Requisitions with Lawson numbers entered in requisition center do release automatically; only those with special order items require approval. I wonder if our IPA flow is in fact, releasing the MSCM reqs before completion. I've reached out to the end user to try and determine more details, but they insist they are not doing anything different. Thanks for the guidance. I'll reach out to our IT for more details about our IPA process flow.

If you have the MSCM error - you can go to RQ10, put in the requester and click Previous - this will pull up their last req. Right click and drill on the req number - it should tell you who created it and the user id that released it. If it's the same user id as IPA - then yes, IPA is finding it too fast.

Thanks Kat. Our IPA does release all our MSCM requisitions. We're heavy on JIT locations. We may have it running too often in order to capture everything before our vendor's cutoff time. I'll check with our IT support since I don't remember how often we finally decided was optimal.

I created an LBI report that runs at noon every day and is sent to everyone that has access to do par ordering. It shows all MSCM orders that are unreleased. I put the responsibility on the material handlers and their supervisors to release their orders and make sure their pars are set up correctly.

Thanks Jon-the requisitions that contain the error message do release successfully through IPA. The items that have the error are not added to the requisition, so no order is created. All other items seem to transmit and release successfully.

You can get the IPA to skip the req release from MSCM by telling it to get REQHEADER.RQ_SOURCE as a variable. If it's 3 (Req came from MSCM) then let the users release it - then do what Jon is saying - make them responsible for checking all their reqs release.

I agree with that logic, but current management wants as much "hands-off" and automation as possible. I'm trying to determine how hard to fight this battle. Convenience vs failure to obtain product?

OK - but under normal circumstances - MSCM will release that req when it's done. It's breaking the system to have the other IPA do it. If MSCM encounters an error, it will leave the req unreleased - so the users need to check - but 99% of the time, it should just be a quick glance and done. I've never heard of an IPA looking to release a req it didn't create so I'm not sure what business need they felt there was?

I think they just want to make sure any MSCM reqs that didn't release due to an error get released that day to ensure the order is placed timely. It's really just a timing issue. The IPA is kicking off in the midst of an upload releasing the req before the upload can complete. I'm guessing it doesn't happen often but when it does it's a mess. I would set it to kick off once per day in the afternoon just prior to your first vendor order cutoff time. And communicate to the MSCM users that they should complete their uploads before then or at least not at the time the IPA is set to kick off.

Thanks JonA and KatV for your responses. You've pointed me in the right direction of the issue. We'll see if management wants to re-evaluate the process

Hi
The most common cause of mscm reqs not auto releasing is pricing. For nonstock items this means a price agreement is missing. For stock items it means the item has never been received into the storeroom and hence there is not a cost in the itemloc table for this company/location/item

To avoid this i recommend you always test nonstock items before adding them to a par location. The best test is to create a req in rqc or rq10 and then add the item to the req. if vendor, uom and cost all default onto the req line, you are good to go. Delete the req and move forward

For stock items I recommend you hold off on adding the item to the par loc until you have received your first po into the storeroom.

If you are not patient, you can instead force a cost into the itemloc table by adding a qty of 1 into the storeroom using ic21.2 (as a credit) or using ic24. Then immediately reverse the transaction by entering another transaction to remove the quantity.

This action puts a cost in the itemloc table and hence allows req lines to process without failure.

Of course there are also paint screens to accomplish this if you are fortunate enough to have access to them.

Tip: par counters - or their supervisor/lead should be trained to Log into the MSCM desktop app a couple of times each shift and then navigate to the par count screen (that allows searching of the days Par counts). Then they should specifically search for orders with status=upload error. This will quickly identify reqs that were held up due to a cost issue (or other issue). In my opinion it is always best to fix the cost issue then resend the park count from the screen however you can also simply release the requisition in rq10 But the item with problems will be left behind

So in short your organizations decision to have an IPA automatically release all unreleased requisitions is treating the symptom rather than the root cause and the steps I have outlined above are more likely (in my experience) to achieve stronger results and less disappointment in the long run

Another tip: it is best practice for pricing management teams to create and utilize data integrity queries / dashboard that identify items that do not have pricing. These queries should be setup such that an empty report means no action is required

Hope this helps

Thanks Mike, but this issue is different from missing unit cost. The requisition does release, the items with errors do not order. The error message in MSCM for items requiring unit cost is at least easy to understand: "unit cost is required". I couldn't determine what "cannot change requisition has been processed" meant when the end user insisted they did nothing different.