Pcid bpm

Hi

Looking for some C# coding help please. On the handheld PCID screen, I’m trying to make the process fully electronic, without needing to write down or print out a label with the generated PCID. I already have a customisation that is setting a checkbox on the Mtl Queue, showing whether this item you’re about to pick is a “New Pallet” or not. If it is, then you need to press Gen PCID and create a new one. If not, it should be picked into the SAME PCID as the last item on the users “My Mtl Queue”.

The bit I need help with is a Method Directive BPM to store the PCID on a session variable, and then another BPM to pull it back from that variable and load into into the PCID field of a new record. A friendly contact in CSG had said that I should be able to do the following:

Set [“PCIDString”] = PCID.Value

Get PCIDValue = (string)[“PCIDString”]

So setting a custom variable against the session object, but it’s not liking it. What’s wrong with my syntax?

Many Thanks
Mark

use CallContextBPMData.Character01 to store and retrieve the data…

1 Like

Problem is that field as I understand it lives and dies with that BOM directive call, or certainly the transaction. I need a variable that persists between transactions, I’ve seen it done where you store variable against the session and it will persist for that user until they close Epicor

oh! you want to persist it throughout the session…
This should work

//Insert 
this.Session.Add("MyVarThing", "MyValue");
//Retrieve
this.Session["MyVarThing"]
1 Like

@deleoye this is what I was talking about on the phone :slight_smile:

Many Thanks @josecgomez
is there a command to create my own BPM call variable, i.e. instead of using CallContextBPM variables, the reason for that is, to avoid variable using overlap, up to now 177 BPM’s and 73 Customization which these variables might be used within, i had to create an Excel Master file to map out the use of these variables, it will be a great feature to have in Epicor to identify that on the relevent UI forms or even state them on an ice table

You should be clearing whatever you put in the call context at the end of your BPM every time. That failing you can just store the information in the session or a UD table.
Also 177 BPMs… seems excessive! That’s a lot of overhead…yikes!

we do clear them, but there is cases when i needed to use them as triggers for other BPM’s -depends on the need- and user can run two UI using the same variables, thereby one of them will fail, also 177 BPM’s include Method, Data, and U-BAQ, we do have load of controls on our UI, that is why i would like to start creating my own BPM/Customization variables, so could you please elaborate a bit about storing information in session ?
do you mean this :