+1
Hi there
I am having an issue with inserting a loop into a WADACO transaction for material issue.
My transaction starts with asking for the Shop Order number which is correct. What I want is that WADACO will stay in that order as I have multiple issues to make to make to it. Is there a way to do this? Production operators are losing time having to constantly enter the order number.
Below is how we have attempted to set up this transaction.
Thank you
Best answer by Dario Zani
View original
+6
Hi
if it’s a valid option in your scenario, try placing PART_NO right after ORDER_NO to see if it works.
As the configuration is using Fixed values for RELEASE_NO and SEQUENCE_NO, and the loop is activated only after them, IFS may be trying to loop parts based on those fixed values.
Not related to Shop Orders, but I had this similar issue with a loop where I had LINE_NO before my loop started. Therefore I chose the line to process and started the loop, but as the loop was fixed to line 1(for example) the loop could not jump to line 2 etc.
Br,
Mikko
Hi
I have feeling
I have to admit shop order and manual issue shop order is not really my area of expertise and how the database model for this object look like and what is head and what is detail.
But the general idea if you want to run what we call an internal loop (its when you use loop start/end in the configuration) is that everything outside the loop should only have 1 value for all "datasets" you work with and inside the loop all the unique values that could be different for each "dataset" should appear. In this case couldn't release_no or sequence_no also be different for each part/detail you handle, in that case they should also be inside the loop.
But there is also other issues with internal loop, like for you too not see already handle objects in the same session there need to be some code that will hide them, this might not have been implemented in this process, I'm not sure, we only added in some places where there was some benefit to use internal loop.
Also there is also possible performance issues if you have many datasets/loop laps in one sessions that could be cause a timeout to the mobile device you are using. Plus if you enter something wrong in of one the loop laps that is causing an error during the execution of all the datasets you will have to re-enter all data that came after the value that caused the error, so its not so user friendly if they enter wrong values/data.
In this its unclear if you had any issue with this configuration, what happens since you ask about it?
Generally we recommend what we call subsequent looping instead, where you let your configuration loops to itself since then the performance issues and showing old data will not happen since there will be a database commit between each session. Also the error issue will be much easier handle since you only work with one dataset at the time. To avoid entering order_no for each session you set it up to be subsequent value so it will be sent between the different sessions, the only thing could be what happens when no more details exist for that order_no, either you will get some error or you will be stuck on the order_no perhaps with an empty LOV, in that case just return to the menu and restart the process that way to handle next order.
Not related to Shop Orders, but I had this similar issue with a loop where I had LINE_NO before my loop started. Therefore I chose the line to process and started the loop, but as the loop was fixed to line 1(for example) the loop could not jump to line 2 etc.
Yeah that’s a classic mistake when it comes to internal loops, items that come before the loop start will only be fetched/gather 1 time connected to the first dataset, while items that come after the loop end will be fetched/gather 1 time connected to the last dataset. So its super important that its only things that will never change between the datasets/loop-laps that are outside the loop.
We had a customer recently that had put the aggregated_line_id item for a Pick HU process outside and after the loop which would mean they would re-pick the last dataset handling unit over and over, since that item is the real key that also points to the reserved handling unit but its value is very cryptic for the user.
Unfortunately its is more or less impossible for us to code any checks on the configuration to see if the configuration is setup correctly when it comes to internal loops since it is a very generic solution, it is more of a thing you learn by experience when configuring your processes.
+1
Hi
I have feeling
I have to admit shop order and manual issue shop order is not really my area of expertise and how the database model for this object look like and what is head and what is detail.
But the general idea if you want to run what we call an internal loop (its when you use loop start/end in the configuration) is that everything outside the loop should only have 1 value for all "datasets" you work with and inside the loop all the unique values that could be different for each "dataset" should appear. In this case couldn't release_no or sequence_no also be different for each part/detail you handle, in that case they should also be inside the loop.
But there is also other issues with internal loop, like for you too not see already handle objects in the same session there need to be some code that will hide them, this might not have been implemented in this process, I'm not sure, we only added in some places where there was some benefit to use internal loop.
Also there is also possible performance issues if you have many datasets/loop laps in one sessions that could be cause a timeout to the mobile device you are using. Plus if you enter something wrong in of one the loop laps that is causing an error during the execution of all the datasets you will have to re-enter all data that came after the value that caused the error, so its not so user friendly if they enter wrong values/data.
In this its unclear if you had any issue with this configuration, what happens since you ask about it?
Generally we recommend what we call subsequent looping instead, where you let your configuration loops to itself since then the performance issues and showing old data will not happen since there will be a database commit between each session. Also the error issue will be much easier handle since you only work with one dataset at the time. To avoid entering order_no for each session you set it up to be subsequent value so it will be sent between the different sessions, the only thing could be what happens when no more details exist for that order_no, either you will get some error or you will be stuck on the order_no perhaps with an empty LOV, in that case just return to the menu and restart the process that way to handle next order.
Dario, thank you very much. Your suggestion on “Subsequent Value” has worked a treat!
+1
In my “Manual Issue Shop Order Part” transaction, for some reason when I scan the Lot/Batch for the component I want to issue, the below screen comes up.
Surely IFS should know which part I am issuing based on the lot/batch scanned?
If not, is there any way of getting the Part Number added to the “Search for Line Item No” screen? Staff are finding it confusing without being able to see the part number.
Thanks in advance.
David
In my “Manual Issue Shop Order Part” transaction, for some reason when I scan the Lot/Batch for the component I want to issue, the below screen comes up.
Surely IFS should know which part I am issuing based on the lot/batch scanned?
If not, is there any way of getting the Part Number added to the “Search for Line Item No” screen? Staff are finding it confusing without being able to see the part number.
Thanks in advance.
David
If you mean is the possibility to add part number to the description part of this Forced Line Item No LOV, then yes. But only with a customization since it needs to be added in the code for this LOV. I’m guessing that is the Part Description that is visible now? I guess when this was coded we expected most to use Description when looking for a certain part in this LOV. It’s the same with location, we usually show location name rather than location number.
In future releases there will be some new possibility to configure what you want to see in the description part of the LOV. But it requires some extra coding from our part so we will initially only do it for some of the LOVs, but it always good if we get some information of what customers would like to see in each of these LOV to better select or search for the objects they want to find.
+1
Ok
Thanks for your time.
David
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
