I’ve been asked to look at limiting ship via selections based on some custom logic. Essentially, some customers say you can use any carrier you want, but x and y, we hate them. And other customers say, you can use one of these three carriers. Other places have different requirements based on shipto location.
Right now this is handled with notes, but the request is to enforce this at the software level. Seems like to me the simplest thing would be if the customer has specific requirements they should arrange the shipping, but of course that’s not a valid response.
My first idea was to put a BPM on the GetList BO method for ShipVia, but I don’t know how I would get the required data (customer, ship to ID) into the BPM across various screens (quote, order, pack…etc). Perhaps I could use BPMCallContext? I’ve heard BPMCallContext doesn’t work quite the same in Kinetic though?
My second idea was to replace the drop downs with my own, and populate the results with a BAQ that fills in the Customer ID and Ship To ID with BAQ Markup. I don’t like that very much as I would have to recreate it in application studio when we switch…
Are there better ways of achieving this business goal?
Something along the lines of a tilde/comma separated list of valid ship via’s on the customer / ship to record and then (if BPMCallContext.CharacterX is not null) filtering the ship via list in a post-processing method directive should do the trick.
BPMCallContext should work for both Classic and Kinetic forms. This is likely the least maintenance required solution.
Yeah, I am leaning in this direction, I was just hoping there was a BPM/Function only way of solving this. I will still have have to make a customization to populate the BPMCallContext, so that means a customization on at least three screens.
I’ve heard BPMCallContext doesn’t ‘stick around’ as long as it does in the client, and I think the amount of data you can fit into it is more limited in kinetic but it should probably still be fine.
In general I also am a bit nervous that other people will use the same BPMCallContext field I am later and break things. Can cause very hard to troubleshoot issues.