Stock Items Converting to Non-Stock PO's

Legacy Contributor

Hi,

We are currently experiencing issues with our stock items issueing to PO's. It happens for single line requisitions as well as multi-line reqs. We haven't been able to find a solution to the problem.

When we check IC12, everything is setup correctly. Inventory tracking flag is set to yes, and the bin tracking flag is set to yes and a preferred bin assigned. We have also checked the par location that we most recently experienced this issue with and the items have the right replenishment information stored.

Any additional ideas or thoughts on what might be causing this issue would be greatly appreciated.

Thanks
John

Find more posts tagged with

Comments

Is this happening for both par locations and standard requesting locations?

Legacy Contributor

Hey!

Yes, I believe so.

This particular instance, the end user entering in the req put the req in under the primary requesting location. Then, he was asked to update to the par location to allow for more accurate tracking. So, he changed the location from the cost center to the par location name, that's when the items were all converted from stock to non-stock.

Hope that makes sense. Let me know if you need more info.
Thanks again
John

Legacy Contributor

We experienced this issue when the requisition was created from the IC142, and the buyer added items to the requisition before releasing. The buyer added inventory items to the requisition, and the items defaulted to non-stock, and pulled into the PO as non-stock items on a PO of all inventory items. I opened an incident and was told Lawson was working as expected, which I found very surprising. We are currently using v9.0.1.10 in production, and testing for upgrade to v10.0.6 (go live 7/20). I tested in v10.0.6 with the same results.

Are the items that are going to a PO on stockless agreements? Look at PO25 Header Type Specific tab and look at the RQ01 record for the par location and see if the Stockless Flag is set to Y for both. If so this will override the item pulling from your storeroom and put the order on a PO.

Legacy Contributor

Pattianne,

As far as I know the process using IC142 wasn't followed in this instance. That is good to know however cause we are currently testing for V10 upgrade as well.

Jon A,

I checked the PO25 header of 3 items, each with a different contract header, as well as the RQ01 setup and the Stockless Flag was set to NO for all contract headers and their respective locations. Any additional thoughts on this?

Thanks to both of you for the help, it's greatly appreciated.
John

Do you have more than 1 warehouse? Is the default from location set to the appropriate warehouse?

Legacy Contributor

Hey!

No we just have one warehouse, STRM. This is the location that we add all products, stock or non-stock to when we do the initial location build in IC12

And the RQ01 are set for the default from location?

Legacy Contributor

Yes, the from location is set to our warehouse location, STRM.

Is it only the one PAR location? Only one User? Just trying to narrow down the possibilities.

Legacy Contributor

Not a problem!

It's multiple par locations and users. We haven't had this issue until the last week and a half to two weeks. Started noticing the issue early last week and it's starting to happen more and more often.

Any CTPs applied in that time frame?

Legacy Contributor

Sorry, can you expand on what a CTP is?

Legacy Contributor

I was going to ask if you had made any changes in that time frame. As Jon A said a CTP - patches to your system, might be a potential culprit.

0811181026417683.xls

Legacy Contributor

Ah, thanks.

I just checked with one of our Lawson Admins and he stated we haven't installed any patches for some time. I asked in particular for anything in the last 2 weeks and he said we hadn't installed anything new.

Sorry John, I am stumped at this point. Perhaps run an IC192 to see if there were any recent IC12 changes that may cause this.

Legacy Contributor

Not a problem. The information everyone has provided was more than what I had to start with so it's better than where I began.

We have a call setup with an Infor Rep to discuss the issue. If anyone is interested, I'd be happy to post the solution (if we are able to define one on this call) for any to reference in the future if ever needed.

Thanks again
John

IGUG Application 2020.docx

Legacy Contributor

Sounds good, John. If I think of anything I will post. Make them do a webex with you so they can see your setups rather than having to keep supplying dumps and screen shots. Good luck.

Make sure to post resolution so that I'm not up at night wondering!

Good luck!

0911060553270289.pdf

Legacy Contributor

Hi,

So we had originally thought we find a solution contained in a patch from Infor. Upon further review, we were unable to re-create the problem in our test environment, so won't be able to install the patch.

One of our Lawson admins suggested their could be a difference in the code or forms that RQC populates when reqs are entered. Is anyone familiar with the forms on the "backend" that RQC uses, or has anyone run into an issue where the code was different from one environment to the other?

Thanks in advance!
John

I don't believe we have ever run into that. You're absolutely sure that these items that are going to a PO instead of the storeroom are set up on the par (IC81.2) to replenish from STRM and not a vendor? Not just the header in IC81.1 but specifically in IC81.2.

Legacy Contributor

Hey!

Yes, we had run into the problem a while back when we first started creating new par locations. That's when we figured out that in order to have the items pull from the right location, they either needed to be assigned to the right company and from location, or if they were a non-stock item, we had to include the vendor and purchase from.

We have checked a lot of the guilty products specifically and have not found any build discrepancies. At this point, I wish we had found a mistake.

Legacy Contributor

John,
We use RQC quite a bit here, and have not encountered this issue. Have you compared the RQ10 against the RQC, which are one and the same, but once in a blue moon, I have found that they have not worked the same. I assume you are working with GSC? How about doing a document with screen shots and posting here, maybe more sets of eyes can help see the issue.

Legacy Contributor

Hey Victoria, attached is a word doc with some screenshots of RQ10. There are two different reqs, the first one used a RQ01 requesting location and the second one used a par location as the requesting location within RQC.

Everyone, please let me know if you need me to expand on any paritcular details. Thanks for the feedback
John

Hey John,

Just for giggles and grins could we see the Purchasing and Miscellaneous tabs for the lines?

Legacy Contributor

John:
Now let's see the RQ01 setup for CODE, and the IC81.2 setup for this item 5112733. And like Jon said, the Purchasing and Miscellaneous tabs. V

Legacy Contributor

In addition, please send the Main tab, and the Source tab on IC12 for this item.

Wichtige_Lösungen_in_der_Wissensdatenbank_September_2012.pdf

Legacy Contributor

Hi, sorry for the delay. Our other analyst is out so I'm covering both desks. Will try and get screenshots for the above requests on monday. Thanks!

0712131256598360.doc

Legacy Contributor

Hi, me again.

Sorry for the lack of screenshots but we have identified the issue.

While in RQC, whenever our end users are trying to order from a par location, the products are marked as a non-stock item within the application. Even though we were able to confirm the flags were correct in IC12, RQC was not recognizing them. In order to fix it, we are working with Infor's AMS group to install a patch in our test environment so we can verify the fix.

Thanks for all the feedback.

Legacy Contributor

We have experienced the same issue. We have narrowed ours down to only RQ10 users (not RQC or pars or even IC141).
The issue is totally random - different items, different users, etc. I can have multiple requisitions entered on the same day for the same item and 1 of them will default to Nonstock and go onto a PO. That same user can enter another req for that same item and it will be fine. I also cannot recreate the issue on demand. I am hoping you will have better luck finding a solution or cause.

Important Links

Popular Tags