IFS Cloud 21R1 - Warehouse Data Collection

  • 24 November 2021
  • 4 replies

Userlevel 3
Badge +4

Hello All,

I have some problems with a WADACO Configuration, maybe it´s a BUG in the IFS Cloud 21R1 because I have not the same problem on IFS APP10.

So if I put the RECEIVE_CASE as a automatic Value = Default (this value is always present and must be maintained at the supplier for purchased part) it doesn´t appear, the field remains empty and the LOV must be made

I have the same setting for the PART_NO and here it works:


Does anybody have an idea?

Thank you in advance.


Best answer by Dario Zani 25 November 2021, 11:24

View original

4 replies

Userlevel 5
Badge +11

I guess this will a similar answer like for your previously part description issue, try and make sure all source_ref1-4 plus source_ref_type items before receive_case I think it should work then.

In general all those items including the source_ref_type are important to have early if you want some of the functionality that use the source line to work properly.

Userlevel 3
Badge +4

@Dario Zani Thank you for your reply. It works for both. 

But now, the subsequent Data item ID is not taken into account, namely if an order has several positions, the scanner should take over the Source_Ref1, RECEIPT_REFERENCE and ARRIVAL_DATE for the second position. If the scanner has no further positions to capture, it should display the complete selection of all SOURCE_REF1 again. But now it shows nothing and I have to go back to the menu to enter more orders. Can you help me here too?


Thank you for your help.

BR Marina

Userlevel 5
Badge +11

Hmm not sure, normally that should work, this process have even code to make sure to handle a case like that so you can see all possible source_ref1 in the LOV if the value from the subsequent data item give a validation error. I just tried this in the Apps10 track and there it works like you were expecting I think, but when I tested in latest Cloud Track I got same thing like you did, it feels like a  new minor bug perhaps, it acts like it used the old value as filter for the LOV that’s why the LOV is empty. It might be because some odd new handling in the Aurena clients that we didn’t have in previous Apps9/10 tracks.

The workaround I could see is to set the Use Subsequent Value to Default instead of Fixed, then you have the option to remove the old value before you open the LOV (any value in the field will always be used to filter a LOV when you open it). The downside is that you always have to press save for source-ref1 that you get from the previous subsequent session, you will see when the there is no more data to scan by getting an error for the source_ref1 then you remove the value and open the LOV to choose another source.

Userlevel 5
Badge +11

@IneMarinM I found the issue now, it is a small change in the process code in Cloud track (due to how we implemented that source_ref3 can be Nullable) that causes this issue you are experiencing with empty LOV. You could report that as bug and mention my name in the bug explanation, to make sure that it would be considered a bug from R&D side. But I’m not sure it will be considered as a high priority bug so it might only be fixed for the next core Release and not for 21R1.