Prepopulate Key1 in new record of UD Table - in App Studio

I am modifying the entry screen for UD12, which I will use for PPAP (part inspections, basically).

For simplicity, I think I would like to go with Key1 being set as the current date-time when the record is created.

Is there a way to do this in Application Studio? I am fairly new to this.

I guess it would be some kind of Event? If so, could you provide guidance on that? I’ve been poring over the guides but still can’t wrap my head around this.

I’m sure this could be done in a BPM on save, but I thought this would be a simpler way…

BPM is the simpler way and better practice.

2 Likes

You could also do it on GetNew Post processing…

I also agree you should try the BPM route.

Also, using datetime stamp as a key field is a not-great practice.

What is the advantage or philosophy there?

I am going to hazard a guess and say because it then makes it visible to the user while she creates the record - but before save?

Why, what ever do you mean?

As if it was going to completely reformat the text in the header:

image

Both of those are Key1

I will definitely not argue, and it makes sense as it’s universally effective rather than something that would be bypassed in a REST call or updatable dashboard, etc.

I just feel like having the code in a separate place makes it harder to follow. But I get it, this is a backend rule I am making, so don’t code it into the frontend.

It’s just to have a complete record when you save it. It also will be visible to the user as you said. It’s just a matter of preference really. If you want it when they actually hit save then Pre-processor is what you will want.

For starters, there’s a low (but not zero) chance of two people creating two records at the same time, causing a key collision.

Second, having a deterministic key (e.g. an integer that counts up by 1 each record) can make it a lot easier to troubleshoot things if something goes wrong.

Third, nothing in stock Epicor works that way, and IMO, it’s always better (if possible) to follow the conventions of the parent system when extending it.

None of these things are show stoppers on a typical Epicor system with dozens to hundreds of users. They are minor annoyances at worst. Still, best practice is best practice and everything else isn’t.

2 Likes

For educational purposes, you would create an event on a trigger (found via Dev Tools in the browser) that would call the row-update widget.

SetKey1

2 Likes

If you want some simple code for the BPM, you can put this in a post-processing on update.

  int lastRecord_ID = 0;
  Ice.Tables.UD12 lastRecord = null;
  
  try
  {
      lastRecord = (from UD12Rows in Db.UD12
                      orderby UD12Rows.Key1 descending
                      select UD12Rows).First();
  }
  catch {};
  
  if(lastRecord != null) lastRecord_ID = Convert.ToInt32(lastRecord.Key1);
  
  foreach(var record in ds.UD12.Where(rec => rec.RowMod == "A"))
  {
      lastRecord_ID++;
      record.Key1 = lastRecord_ID.ToString();
  }

If you would like to actually use the current date time, store your value as Ticks and you will have a hard time generating duplicate rows, and can convert back easily for display. You could do that in the client, but if you are going this route, I’d do it on GetNew.

You could also prepopulate an unused field with the same value for easy display:

    DateTime now = DateTime.Now;

    ds.UD12.FirstOrDefault().Key1        = now.Ticks.ToString();
    ds.UD12.FirstOrDefault().ShortChar01 = now.ToUniversalTime().ToString();

You don’t even need code for this.
Post-processing on GetANewUD12 and add a set field widget.

Perfect for him!

I’m assuming you meant for the second part, because if you can do the first without code I’m all ears.

Yep, this part isn’t hard. I can do widgets all day, and I’ve already done something similar to this in a Function:

But now App Studio is, what, JavaScript? That’s what I infer from other things I have read. Yay, another language. But many places in App Studio don’t have a widget or a drop-down. So here comes another learning curve.

Now, I definitely did not know about the “Ticks” thing, and I will probably incorporate that. Thanks, @klincecum !

1 Like

So… Not only could you all do this better than I could, but I might even have a better way to do this these days.

But, I certainly do have a very rudimentary “autonumber” BPM in place - for 3 years now. (The 2 rightmost widgets are new since January, though.)

To explain this, we have 2 main sites (plus a third; long story). I call them MFG and PDC. MFG was first and its POs are in the 300,000 range per company config (or maintenance or whatever).

When PDC came into the fold, I made them a site but wanted them to have their own PO numbers, and in fact they already did have their own, in the 100,000 range (around 143000 at the time). So to honor that, I made this BPM for users logged into the PDC site.

1 Like

We currently don’t have access to any javascript functionality.
I’m not sure if we are getting any, and if we do, at what level.

Now the app itself is run off of javascript, but it basically reads
widgets and config files out of huge json files.

That’s not true.
Any expression field can execute JavaScript by including #_<your code>_#

Wow, I really don’t mess with it enough. I need to dig more then.

Have you been able to do anything useful with it ?

I use it all the time for small stuff like the above.

@josecgomez got it to load a blob and preview a PDF of a report in a new tab. Pretty swanky. :star_struck: