If I am understanding correctly, the only difference in these orders is the part num on the line of the sales order? And if this true, why are you trying to change the behavior of the Customer Shipment Entry? I would think that all the standard business logic would be sufficient for a shipment, but that’s what I don’t know for your scenario what the intent is.
Another technique to set field values is to use a BPM to set a field based on incoming criteria, such as checking if the new line being created on the pack has a part number starting with “3”. Using a BPM would be nice because you wouldn’t need to maintain a form customization and could perform 2 actions at once, like changing the “Our Ship Qty” field and the package code field.
Regarding the boolean return, the method will return true or false depending on if it was able to retrieve a recordset. It’s the same with a “GetByID” method. A common technique is to call the method while setting a return type and then providing an “if” statement to proceed to the next step of the code. In this way, we avoid runtime errors if we passed a set of variables into the method and it wasn’t able to find a record, like you experienced in the BL tester.
A boolean value will either be “true” or “false” and your “if” statement will read a true/false value.
bool recFound = someAdapter.GetByID("someValue");
if(recFound)
{
//do something if we did find a record
}
What this means in this example is that calling the method you are calling will either return a true or a false depending on if it found a record associated with the parameters you sent it.
Because you are trying to do something with the data you are returning, I would recommend a code architecture like above. Inside your if statement, you would then access the data of the adapter.
Given the length of this post, do you want to try to solve one of the problems with a BPM or are you going to keep playing with the form customization?
Just to quickly answer this before I read the rest, we can ship these out via Customer Shipment Entry with absolutely no issues. It’s just that we’re going to have one person that doesn’t use Epicor heavily to ship these orders towards the end of the day. My task was to make this shipping procedure as easy as it can be. So instead of having the Header tab and Lines tab and switching back and forth, I just have all the info on one screen. That way the user can just click New Pack, enter in ship via, click tab, enter in package code, etc.
edit: This will not effect how other orders are shipped
I hope to get the retrieval button working, for my sanity and just to gain the knowledge/experience that goes along with adding that. But I did want to use a BPM for the other stuff (1 qty, auto package code, etc.)
I would think that you will have plenty of other use cases for a button click retrieval, but in this case, I would go with a BPM. Are you familiar with BPMs?
Let’s start with the criteria should trigger new behavior and at what step in the process you are trying to set some fields. This will tell you which method you will want to build the BPM off of.
If you believe that BPMs would enable me to accomplish all the auto processes, then lets go that route. It’s definitely going to be more challenging since I’m not familiar with BPMs at all. I understand the basics with them, but I’ve never went in and messed with Method Directives Maintenance or anything like that.
Alright let me think about this…
So user clicks New Pack -> they enter in Ship Via -> New Line, input Order Number *here’s the trigger, and the criteria should be if the order has a part number on it that starts with “3.NFL” If the order does have a part starting with 3.NFL, then input “WT” in the package code box, pull in the line/rel information (if possible), then change the “Our Ship Qty” field to 1.
I feel like this is going to be very difficult… Especially at the part where it brings in line/rel information - since the part num data doesn’t seem to be “read” until the line/rel information is put in. So would the above process have to be re-arranged so that the user will have to manually put in line/rel info, but then the BPM kicks off all the other automated stuff? If that’s true, then I’ll be 100% fine with that.
Mine is a pre-processing BPM built on that method. Pre-processing means that it gets assessed before the method fires. Post processing means it gets assessed after the method fires. Certain values will be changed/available in the pre-processing vs the post-processing. You won’t want to create any base processing directives…
Click the design button to go into the workflow designer.
In the example below, I am demonstrating the use of the Set Field node to a specific expression
In your example, you will want to have a condition node off of the start node that checks the value of the ttShipDtl.PartNum field.
My wildcard may be incorrect, but this is just an example.
Thank you so much Aaron. All your posts have been super informational and helpful - I really appreciate it.
The post-processing BPM I added didn’t work - but I’ll mess around with it more tomorrow (or Thursday if the EUG takes all day).
I tried both wildcards for the part (* and %), neither worked, then I tried messing with the “the changed row” and tried a few of those and none of those worked… I’m not sure if I need to use a different method or not - looking at the trace log file it looks like PartNum data isn’t called up when GetOrderLineInfo is processed, but the next one, GetOrderRelInfo does have PartNum data. So maybe I just need to change which method I’m adding the BPM to.
Happy to help!
You should use the Field Help (any form, go to Help>Field Help and pin that sucker so the tab doesn’t float away) and find out what Pack Code is bound to. I would bet it’s the header.
AAH found the issue - I don’t think you can have wildcards in the condition process. Once I got rid of the * and/or % it worked!
Now I need to add some more set field nodes : )
Edit: When the method GetOrderLineInfo runs it updates PkgCode with wt, but then when you bring in the release num (GetOrderRelInfo runs) it gets rid of it. It’s never easy!
I tried but unfortunately it doesn’t work unless it’s on the base process of GetOrderRelInfo… I understand that you shouldn’t mess with the base processing for most methods, but in this context do you think it’s fine?
Definitely don’t do that. My understanding is that a base processing directive will replace the standard logic that the method performs. This can result in major data issues, so I can’t recommend doing this.
Let’s get back to what you’re trying to do. Are you’re just setting a qty right now, correct?
No I’m setting the PkgCode to “wt” for now. I do aim to add more set fields on this, but I need to actually get it working on post/pre processing first…
That is correct. I tried it on both pre and post processing.
I changed both condition and set field to “all rows” instead of changed row and that didn’t work. I also tried just the set field to “all rows” but that didn’t work either.
