But… we aren’t on latest and greatest and I am trying to revert the company back to using masterpack.
Right now we put everything on 1 shiphead and then use the invoice comment field on each pack line to put a “skid number” so we can count how many skids are in our shipment and identify what skid each product is on. this was done back when they switched to 10.0 from vantage and something was super messed up with masterpack after go-live so they did what they had to do.
This all comes with a multitude of workarounds to change base reports to adopt this logic as well as takes away a lot of functionality when it comes to the shipping module and the picking modules…
Anyways… we use BOL entry now and when we hopefully switch to using mast packs we would need to link master packs to the BOL. What I am finding is that the BOL service method “UpdateLinks” is properly linking the masterpack to the BOL, BUT, BUT, it is also going out and updating any customer shipments with the same packnumber as the masterpack with the BOL number and that’s just wrong .
This is problematic because now old packs are being updated with BOLs from 2024 simply because the masterpack number and the shiphead.pack number are the same… I’m fairly positive this is a bug, but maybe I could just start the masterpack number way higher than the customer shipment number, but that seems really hacky.
Anyways, bottom line, I want to use materpacks and my shipping department needs to use BOL entry and if I can’t get this to work, well, I guess I can’t get us back to using master packs.
I have identified that after “update links” is called the problem occurs. My thought is, maybe I write a data directive on ship head??? cause I don’t see any way to handle this in the BPM… nothing in BOL the method trace shows the shiphead.BOLNum being updated or returned except for afterwards in the return parameter dataset in the update links method… and that’s too late.
I’m looking for any ideas or guidance from anyone who has tried to work around a bug like this…
As investigation hack you can throw exception inside data directive, catch it and dump it with stack trace to the log. You will see where it is called from
It is possible, just make the new start very large. I separated customer and misc. shipments when we started in 2012 by 80,000, but we have now some overlap which can cause some oddness.
Resolution
This is not something that can be done through the core application at this time.
Thank you Greg, I will see if I can just do that and be done with this, but we make so many more packs than we do master packs so I eventually will run into the same thing.
I gotta dig up @hkeric.wci or @josecgomez 's posts on callcontextBPM to understand how that all works again for the life of the transaction scope.
In this case I am doing and update on BOL, but that is spanning a bunch of different table updates apart from those in the dataviews on the screen… so I believe I can loop through the ds tables in the BOLsvc.UpdateLinks method call and sort out which packs that I’m linking are masterpacks and which are regular packs cause there is a flag called “MAsterpack” which is true or false. And since I know that I can store all of the regular pack IDs in an array or something in a call context field as well as an indicator that this is being called from the BOL.UpdateLinks so that on a data directive in ship head I can investigate calls that are updating shiphead from BOL.updatelinks and that are updating shipheads originating from a linked packs call…
I gotta sleep on it. Thank you @Olga for your input and anything you can tell me about callcontextBPM data and how I am intending to use it here. I’ll look into it myself as well.
I am trying to make sense of these two posts from these two very talented people.
Can I use call contextBPMdata.Character01 on BOL.UpdateLinks method directive and rely firmly on it being passed to the callcontextBPMData.Charcter01 value for the data directive on shiphead… I tried it out and I see that the value is passing, it’s actually working, which is super cool and maybe an answer to this whole thing… but I’d love to understand WHY it works or a little more about callContextBpmData… I know I have over the years but I never put it all together and tinkered with it to solidify a complete understanding.
CallContext is a header, that is attached to the REST call. So if you are inside REST call that sets this header, then it should work. If it is something asynchronous like scheduled task, then you won’t have that header.
.