I have been working on getting a Customer Shipment record created using the ideas in this post Creating Customer Shipments through the API
However, I get an exception at the point of calling GetOrderRelInfo right after a call to GetOrderLineInfo
This has been talked about in other posts but none of them have steered me in the right direction as the most promising talks about removing the “extra” ShipDtl record, but I am not sure that is my issue. I have run a trace on doing this in the UI multiple time and am fairly certain I have all the same steps. The specific exception is System.NullReferenceException: Object reference not set to an instance of an object.
at Erp.Services.BO.CustShipSvc.GetOrderRelInfo(CustShipTableset& ds, Int32 packLine, Int32 orderRelNum, Boolean allowNewShipTo) in C:_releases\ERP\ERP11.2.100.10\Source\Server\Services\BO\CustShip\CustShip.cs:line 11495
I plan to add a code widget right before that today to see if I can capture additional info. I am testing this using Postman and I can successfully call a function I split off to just create the header as one way to narrow down what may be causing this. Also, if it matters, this is on the very latest release 2022.1.10
The trick with widgets is to pass them exactly what they are needing to be passed. In this case, it’s probably not being passed the CustShip dataset or some other required parameter prior to the method being invoked.
Definitely sounds familiar but I am not sure what I did exactly to get around that. Have a look in my initial post here, I think you need to set the order lines and release no’s manually before you call those 2.
Hi Aaron, The issue seems to be further down the pipeline. See my response to Dragos. The same path of method calls in a code widget works, but replicating it with widgets does not. My eyes are aging, but after 3 looks, I am pretty sure I have the same set of calls
Hi Dragos,
Once again you come to my rescue and save some of my hair. I cannot explain it, but modifying the code in your other post to match my needs works fine in a code widget, but in a full widget setup it does not, although I did not add the “deferred” stuff that comes at the end of your code to the “full” widget setup, but the exception seems to be happening before that.
Another unexplained experience with Epicor customizations
Not sure about the widgets, I prefer the code, it’s easier for me. I remember I tried to do it with widgets initially but soon gave up as there were way too many of them.
I wouldn’t worry about the deferred stuff - that is for updating the on-hand qty’s after the SO is shipped. In my case, when the function is called through REST from outside (3rd party system), if I don’t do that deferred stuff there, Epicor sometimes takes 20-30 mins to update the on-hand qty’s of the shipped parts. The code I have there just speeds that up.
In my experience, it’s probably not a widget problem. It’s very likely some tiny thing being missed.
Without any screenshots or explanation of what’s going on other than an error message, it’s going to be tough to help.
I have replicated very complex transactions that I used to do in code and now I do with widgets. It’s a small learning curve to transition from primarily code to primary widgets, but it’s far more upgrade friendly and more robust to maintain.
Pay careful attention to your trace and the RowMod field.
I have found that when using widgets there can be some places you have to set the RowMod specifically in a BPM for the calls to work correctly, where in the UI it was getting set by the form/dataview/etc.
I can see in a shipment customization I have that I had to set the RowMod = “U” on the ShipHead record before calling the GetOrderInfo / GetOrderLineInfo / GetOrderRelInfo calls on a shipment line.
Yeah, there was some, but you go through the BPM validation, and you get a list of bad BPM’s and you open them up, check syntax, and you can find them pretty easily.
I know this goes against what they say as far as using widgets to upgrade more cleanly, but I’ve had more problems with bugs in widgets (not upgrade related) than we’ve had with upgrading custom code. Widgets are like using 100% base Epicor. One record at a time, you’re probable fine. But as soon as you have to look at/so something with a multiple records, your off to customizing so you can be more efficient with a dashboard, or custom code to be able to use a simple foreach loop.
Automation studio handles loops well, which is great (would be better if this product was included, but it’s an add-on). The BPM widget engine, unfortunately doesn’t. It really should be able to handle looping easily out of the box. It’s one of the biggest limitations of the BPM designer. If they could make that work, it would truly negate the need for custom code for a big chunk of situations that require it.
