In this episode, Chandra and Paul discuss the realities of software customization within JD Edwards environments. They emphasize that while extensibility tools have reduced the need for customizations, some remain necessary for business-specific requirements. The hosts lay out best practices and key dos and don’ts for customizing software, such as following naming conventions, avoiding modifications to base objects and indices, and using customer-reserved system codes. They warn against common pitfalls that can harm performance or data integrity and suggest always adhering to published development standards.

03:52 What’s more important at INFOCUS than Paul’s hair?

09:21 Customizations are a reality

11:58 Object customization best practices

14:03 Adhere to JDE naming standards

15:33 Maintaining data integrity

18:25 Do I need a custom table for a custom application?

21:44 Design for performance when customizing

23:57 Let’s talk about the Don’t Do’s

32:26 Midwesternism of the Day

Resources:

JD Edwards EnterpriseOne System Extensibility Guidelines: https://www.oracle.com/webfolder/technetwork/tutorials/jdedwards/Tools/system_extensibility_guidelines/system-extensibility-guide.pdf

Development Guidelines for Application Design Guide: https://docs.oracle.com/en/applications/jd-edwards/development-tools/9.2.x/eotds/index.html

Form Design Aid Guide: https://docs.oracle.com/en/applications/jd-edwards/development-tools/9.2.x/eotfd/index.html

Event Rules Guide: https://docs.oracle.com/en/applications/jd-edwards/development-tools/9.2.x/eotev/index.html

Development Standards for Business Function Programming Guide: https://docs.oracle.com/en/applications/jd-edwards/development-tools/9.2.x/eotds/index.html

Quest Oracle Community proudly presents The

JDE Connection, a Quest on-air podcast

production. This podcast explores and showcases how JDE

customers are harnessing specific functionality and capabilities to

drive business success. This

episode is brought to you by RST Solutions,

accelerating digital transformation with AI-driven

business efficiency. Hello, JDE Connection

listeners. Welcome back. I'm Chandra Wobschall, one of

your podcast hosts, and I'm the Business Solutions Lead

at Colossus IS Support. Back with me this week,

and maybe this week I'll move you to most weeks, is

my friend— Hi. And podcast partner, Paul Houtkooper,

Vice President of JD Edwards Product Development at Oracle.

Hey, Paul. Hey, Chandra. Hello, everybody. How's it

going? Boy, you sound excited today. What?

Geez. Hey, Chandra, pick it up a notch.

Let's go. Pick it up a notch? Okay. Hey, did you know we need new

poker chips? These were, uh, 10,000 downloads. We're at

25. Oh, 25,000 downloads? That's

awesome. No, just, just 25.

Today, you mean? Today.

25,000. Yes, we did hit 25,000. So now

when we give these out, we'll have to give people 2 and a half. Should

I bring like the little hacksaw? Little hacksaw.

That's right. Yeah. I'm not flying, so technically I could, I could just drive

in with my hacksaw. All right. Well, with the way inflation is going on, you

probably need to give them like 5 of them or whatever. I don't know. Yeah,

it's 50 in there, about 50 cents. Yeah, about 50 cents on the dollar. So

there you go. All right. There you go. Oh, I love it. That's

awesome. We're a week out from Enfocus. All right. I suppose we

better figure out what the heck it is we're going to say, what it is

we're going to do, not only from our podcast, but from the team perspective.

So pressure is now really on. So yay. Yeah,

I know I've got a couple, obviously I should probably figure out what I'm gonna

talk about for the financial SIG meeting and obviously

what we're going to talk about. So. I'll get there. We

always do. I know. And of course, we got the fun factor this

year. I think Wes brought in Blockbuster. Remember Blockbuster where you'd

go Friday nights, get your video, get some popcorn,

get your soda? My VHF tape, which some people may not know what

those are. VHF, VHS, whatever it was.

VHS. VHS, not VHS. You're right. You were going down the

VFW, so you just can buy them. You went to the VFW to watch

your VHS. See how that works?

Now you got me going. I got you going too. Sweet. Awesome.

What the youngins out there say is, well, the fact that you guys are talking

about it means you belong in the— anyway. Yeah, right.

Yeah, that should be fun. I'm excited. I'll have to think of a character and

show up in some sort of costume. I guess I should get on that. I

guess I could make it my twofer. It could be my Halloween costume too, since

that's in like a month and a half. Yeah. I'll get on that.

So we may as well get into this week's topic, I suppose. Do you mind?

Or did you have an update that you wanted to provide for everybody? I

do. Oh, you do? We have something really

fun that's going to happen at InFocus besides the party.

I knew I should have moved straight to the topic. You should have. You didn't

move fast enough. You gave me an opportunity. And guess what?

I'm going to take it. Um, all right, so I'll

unmute now while you do what you need to do. Catch you guys in

a little bit. So I think I alluded to it earlier at the

end of one of our podcasts where we were going to talk about what was

really important to add in Focus. It has been a topic I

think that as long as I've known you,

I've heard talked about in the community, and that is your

hair. Yeah, I know, I know. I

don't personally— I don't get it. I think it fits you. I think it's

you, but it is a contentious topic. It's, you know,

yeah, it's a heated debate, whatever. It's a heated debate. I've

noticed there are some strong opinions that you need to cut that.

Yeah, that ponytail. I am. Yeah, I'm sure you're more aware than

that. It's not just in the community, it's in my family.

Family too. Yeah. So yeah. Well, we had

originally talked about doing this as like an auction and

fundraiser for a charity, but there's a lot of

regulations involved with that, I've learned. So

instead, what we're gonna do is we are going to have a

mechanism for people to vote on whether you should

cut it or keep it. So kind of like Love It or List It for

those that might watch HGTV type stuff. Either

cut it or keep it. And so this will be available to

attendees at InFocus only. So if you're not going, well,

you better get signed up so you can cast a vote. I don't

think anybody's coming to InFocus just for this. Thanks. You

never know. But anyway, so we will have that option. We

will still encourage a donation. The charity that we're going

to point people towards is called Wigs for Kids. And that is

where my hair actually will go, not

just Monetary contribution, but my, my physical hair. I will

be donating it after In Focus, and we will

record said haircut as well. And for

yours, we may or may not be able to do said

cut at our live podcast episode.

However, we will announce if it is a cut

it or keep it. And then from there, we'll either, if

we are able to do it there, we will allow

Hopefully one of the people that voted is in attendance and

is selected and could cut your hair, or

we will go to an appropriate hair establishment

and record and publish it after the fact. So

there will be video evidence so people can see it.

When you say select somebody, are we going to like hand out a raffle ticket

or something like that to be able to do some sort of sweepstakes and somebody

gets to be the lucky person or what? Still working

out that level of detail, but I do know in order to vote, you will

be required to provide an email address. So we might be able to

do it through that as well. So we'll figure out a way. We're working on

that last minute detail. So that is the plan. So for

those that want to see Paul without the ponytail,

you can vote that way. I think it's— or they want to see Paul lose

the ponytail. Great. Yeah. If you're fine with the ponytail and

whatnot, you can vote to keep it. And regardless, we're going to have

some chopping going on because you are going to chop your hair and donate

that. So that's going to go to a good cause. And maybe through doing this,

we're able to actually raise some money for a good charity as

well in the process. Exactly. So I'll just have to

make sure that some certain family members have access to

The voting tool so they get to cast their vote as well. And

I'm guessing you can only vote once, otherwise I'll be out there with

my vote blocking everybody. You just go in a bunch of times. I

think you'll be limited since you have to provide your email address. You'll be limited

to one vote. We won't have somebody going in there every second of the day

to vote yes, yes, yes, or no, no, no, whatever it might be.

Right. And this voting site will have some Pretty cool photos.

Some pretty epic photos, actually, if I do say so.

I'm so glad I was consulted in this,

obviously, as people can tell. Okay, fun. I can't wait

to see it. It's gonna be wonderful. I know. They always say

laugh at yourself before anybody else does. So. Exactly.

All right. I'd say we move on from that topic

and talk about something super fun.

Crickets. Super fun. Super fun. Um, actually.

Yeah. I mean, you and I were talking earlier this week about this topic and

it is an important topic. It's extensibility. And the reason

that this is coming up is I had a situation in

the last week or so where a customer

did customize. They had to customize. And it

reminded me that the reality is, is that No matter how much we

provide these extensibility tools, there's always going to be a use case out there

somewhere that requires some level of customization, or

maybe it's just easier. I don't know. There's a lot of different reasons, but customizing

the software is just a reality. And as we were

working through this situation with this customer, I was just reminded

that we used to have some guidelines out there that we tried to share with

folks to try to keep things in bounds, to try to—

protect your customizations as much as possible,

recognizing that most customizations, they create a level of

overhead and serve as almost blockers to your upgrade and

applying ESUs and stuff like that. But there are ways to do

customization. So customizations are a reality still.

So we should probably talk about what are some of the best

practices around doing those customizations that

help you reduce that TCO, that total cost of ownership,

lower risk. Right? Some people may not realize that there are

certain ways in which you could customize the software that actually puts you at

risk of object contention and other things. And then

if you are going to customize, one would argue that

you should apply the same standards that we do when it comes to

development. And those are a lot of different standards, whether it be

design standards or performance or naming, whatever we should.

be at least trying to adhere to similar

standards for consistency's sake. So anyway, so I thought

we would talk a little bit about the best practices around that,

because it is still a reality, but we don't talk about it as much

because of course we have all these other really cool ways in which to extend

the software, right? So we've spent all our time talking about those, and we've

kind of gotten away from the fact that, hey, guess what? People still

customize software. They don't just extend it. They don't just throw out a NUDO

here or there and accomplish what they need to accomplish. Sometimes they actually need to

make some changes that just aren't covered by a logic extension

or form extension or you name it.

Yes, I think it's true. And I know we've really kind of beat on the

drum and, I don't know, called it the dreaded C word, right? And

we've really beat on the modernization. And as part of that

path, decustomization comes into play, right?

But the reality is Most of us have a

business need or a requirement to have

some customization. There isn't a product that

will allow me to transact business the way my

business wants to transact business without this

customization. Maybe we can reduce some of what we have put

in over the years now with the quote unquote newer

tools that are available. But the reality is there's

probably still some level of customization. So

agree. I think this is a good thing to talk about. I mean, I think

we strive to eliminate the need. I mean, I think we should continue to strive

to eliminate the need and improve our ability

to extend without customization. That remains a goal and we

keep on getting closer and closer. But in the

meantime, while customization remains a reality, let's talk

about maybe some of the best practices. All right.

So I should modify all the base objects, right? That

is the number one thing that you can do. I don't know why

anybody doesn't do that. Like the easiest thing to do is to go into

P4210 or P42101 and just change

it to fit whatever it is that you want and you're good to go.

And then, well, I don't want to throw anybody under the bus, but I have

seen this of all things. And then what you do is, well, you

do that, you modify the base object in whatever release you're on. Let's say you're

on 8.11 or 8.11.1. SB1, you modify the base

object. And then what you do when you upgrade to 9.2, you know what you

do? Or 9.1, you know what you do? You transfer that

object. Oh. Yeah. And then you wonder why it doesn't work.

You call development and say you should make it work, but we won't go into

that. All right. I've got some scars. There's still some scar tissue.

Maybe some counseling has been involved. Who knows? But

anyway, but the cool thing is, is I've gotten to travel around the world

for Situations like that. All right, moving on. No, please

don't modify the core object, the base

object. I want to say, if you can avoid it, I want to say, geez,

I sure as heck hope these days you can avoid that. Modifying the

base object is a bad idea. Your stuff's just going to get

overwritten the next time you take an ESU. You put yourself directly into that

difficult spot. So in that sense, if you need to

change an existing object, then one of the main ways to do that then ends

up being cloning. At least clone it. Then you own it. You clone

it, you own it. I like it. You clone it, you own it, and you

can tweak it from there. And depending on the degree of changes that you take

or that you have, when you then take subsequent ESUs

and whatnot, you're either retrofitting what we did or you're

retrofitting what you did one way or the other, right? But you're not

putting your changes directly to the base object that are just going to get overwritten

by us the next time we take an ESU. Naming standards.

It might seem like a simple thing, or maybe an unimportant thing,

or an innocent thing, but naming standards matter.

Yeah. You want to make sure that you're adhering to

the naming standards that we prescribe so that you don't

have conflicts. And it's not just conflicts

within production, or it's not conflicts with us,

it's also conflicts across Your environments.

So yes, when you name a table, it should be F

followed by your system code. And as a

customer, I believe your system codes are whatever,

55 through 59. If you're not a customer, don't

use those system codes. I don't know who I'm supposed to tell that to. Maybe

it's a business partner. So, okay, business partners don't do that, but you're

probably doing it on the part of a customer. So chances are you are going

to use those system codes. So the only people I'm talking to, I guess, is

my own staff. Don't use 56. Anyway, I'm just kidding. We wouldn't.

But the point is 55 through 59 reserved for customers. So if you're

naming a table, it's F followed by your system code, followed by some

sort of sequential number of your file and whatnot.

So there are different naming standards for business views, table

conversions, processing options, templates for your

applications. If you're going to go create your own applications,

interactive apps, everything. And we do publish those. I believe in our

development standards documents. So please make a

point of adhering to those to avoid conflicts and avoid

contention. We've got all these wonderful ways to

do things, whether it be form extensions, logic extensions.

But if you are going to make a modification,

another way to extend is to use some of

the other design patterns that we have for like

localizations. Localizations allows you to do a bit

of plug and play. And there's advantages to that.

So look at those design standards and how we've done

things for localizations and see if that makes sense for how you

want your customization to behave. Other things,

create hooks into new functionality. Again, I look at this and I

was like, if you do have to add a call to a function or a

named var, put it at the end of an event. But I also look at

that and say, geez. A form extension should allow you to do these sorts of

things. And again, not everything's going to be handled through logic

extensions. So maybe you want to create a business function, maybe you want to create

an AMDR, maybe that's what you have to do for whatever reason.

But if you're going to hook it in, hook it in at the end and

make it easy. A few other things, insert, updates, deletes

to Oracle tables. If you're going to do that,

don't write your own. Don't do updates

directly from ER. In a

standard application that you cloned. In almost all of our

major system codes and A applications, we

have standard interfaces that are used to

update the tables, and that's to ensure data

integrity. And what you don't want to do

is start writing your own inserts,

updates, deletes. Whether it be from ER or

from other functions, you get potential contention. You

get potential problems with transaction

boundaries. We created what we called file servers

for a lot of our functions. X3111 is an example. There's

many others that you should be using those to do

your adds, your updates, your deletes to ensure that things are

consistent and adhered to. There's things like— Interoperability

and other things that we have to also make sure

that we retain integrity for and do consistently.

And so we want to funnel all updates to major tables

through those interfaces for consistency and data integrity

purposes. So it may not be obvious when you write your

little update as to how could this possibly be causing

problems, but we have transaction processing and we

have The ability to roll back things. And depending on

how we've written it and depending on how we've cached certain

information, you could be creating some

risk, risk of a data integrity problem. So question then,

if I create a custom application and that custom

application has fields on it that aren't in the

standard, let's say I'm customizing PO entry.

And I've got a bunch of stuff in my custom application

that I want in my purchasing table. Should I be

creating a 55, if that's, say, the system code I'm going to

use, a 55 table then and not use the

standard table? So it depends. As

always, there's never just a yes/no answer.

And again, it can get more complicated than this, but to try to keep it

simple and not eat up the entire 30 minutes on

one Question. One question. There are things like user reserve

fields as well as future use fields.

Yes. Okay. Very familiar with those. We use some of those.

Well, and you say you use some of them and I'd say, okay,

you can use the user reserve fields. You are the user, you are the

customer. You can use those. You should not use the future

reserve fields. Those are for me. Those are for my team. So

if there are available user reserve fields, that you

can use to represent the data attributes that

you wanna store. I mean, that's what they're there for. If

not, then yes, what you're creating after that, what we would call

a tag table, that is probably a

System55 table with the same

key structure as the base table, and it serves

as an extension, and you will be the one to write the logic

to update that table. Mm-hmm. But that's outside the confines

of probably the standard interface that writes to the base table.

Now, if you look at some of our tables, we've created our own

tag tables because we've had to do that for many

reasons. And those standard interfaces also control

the tag table, which is again— Tag table. Another good example of, well, if

you didn't go through the standard interface, all of a sudden you're adding records to

the base table without adding the corresponding records to the tag table

because you didn't know about the tag table, didn't think about the tag table.

In addition, all the records that you were adding to the base table were supposed

to also be getting put into the, say, the Z1

interoperability table, and you didn't write that. So now all of a sudden,

what are you doing, right? You're creating this data integrity nightmare where the tag

table is out of alignment with the base table and your

interoperability is missing records potentially. I mean, again, just an example,

not the best example perhaps, but an example. Yep. Thank

you. Yeah. What are some of the other tips? Man, I hate to say this

because I know we've got great partners out there and we've got development

teams at customers that are very sophisticated

and they do some amazing things. So I am not bringing these

things up to browbeat anybody or anything or—

Yeah. Throw anyone under the bus or anything. But of the

times that I got put on a plane to put on my Superman pajamas to

go fix somebody. I can tell you I boarded the plane more

times because somebody did

customize the software and didn't follow some

basic tips and tricks and best practices around performance.

Yep. And because they modified the base object, it

wasn't clear and obvious to the customer

themselves, whether it was their team or a

business partner that did it, doesn't matter. It was not obvious. So they're calling thinking

they have a problem with the base object, that it's not performing.

Which they do, but it's not really the based object at that point because it's

been customized and somebody's added a while loop

that is reading records and accumulating

values one by one, row by row

at the ER level because that's what they knew. So they got in there and

they said, oh, I need to go add up these values. And so they loop

through 1,000 sales order lines and they try to accumulate that value and they

do it through ER. And meanwhile, the application falls

asleep or whatnot. And I wish I was joking. I really do.

But I've found these loops. I've found infinite loops

written. Oh gosh. In ER to accumulate

values. I see people writing loops even in C, whether it be

ER or C, and not using our aggregation functions

that allow you in a single call to aggregate and group by

and do these things so that you can do a count, you can do a

sum, you can do those sorts of things. Much more efficiently, 'cause you're

actually using the database rather than this chatty

interface between your application or your business function and the table.

So all of that is related to what? It's related to performance. I ask

that if you do have to customize, please keep performance in mind.

Please. You should design for performance. And

there's a lot of documentation out there about dos and don'ts and whatnot.

And I just ask that people try their best to write

efficient logic. And we will do the same. Trust me. I'm not saying we're

flawless and that we don't make our own mistakes and that there's not our own

opportunities, especially in today's day and age with the tools that

you have available. Writing performant code gets a lot easier

now than perhaps it was before. Some restrictions. Let's just

rattle off some don'ts. So those were maybe some best practices.

Let's rattle off a few Please don't do this. I think we already

talked about system codes, right? 55 to 59, reserve that for

customers. Don't modify the

indexes of a table or the tables.

Which, this one was a little bit of news to me. Like,

I, I hear a lot about, and maybe I've not asked the questions

enough to say, did we just create our own

index or did we modify The base one,

because a lot of times maybe you're putting another field

in, you're using one of the user reference fields, and you're

populating that field with data that your business

inquires on a lot. So you want it to be indexed, right? Yep.

And I've never asked the question. I was

like, oh, I never thought about that. Oh, is that our own

index or did we modify the existing one?

Again, this is stuff that we have to adhere to internally as well, right? So

indexes get used all over the place. We have to be cognizant of where they

get used. And the problem with modifying the existing

index is you may be modifying it for your utilization within

one use case, but it's currently used in 100

different other places. And by doing what you just did, whether it's

changing the sort order or because of the way those

other usage instances access it, you

suddenly created a full table scan and you're creating performance

problems in those other places. Not that you intended to do that. You did something

that you thought was innocent, but it can cause problems. And we don't want to

get into, again, the way databases choose what index to use, this, that, and everything

else. There's some sophistication there as well, right? Mm-hmm.

But we open a table in code to use specific indexes,

and you have to be mindful of that. So if you decide you want a

new index for performance reasons, go create one. But if you

modify an existing one, again, you just run the risk. Same thing, you already asked

about tables. Don't modify the tables. That doesn't mean you can't use user reserve

fields, but don't go adding columns to a table. That's a big no-no.

Don't go modifying business views. Same sort of thing, right?

Right. They're used in multiple places, and unless you

know all those places and you understand the implications of that, even then,

unless you're going to own the ramifications to it, because as soon as you

change that business view, if I use that in 5 different applications, technically you just

customized 5 different applications. Oh gosh.

So yeah, again, it's just some dos and don'ts. Data dictionary items,

yeah, don't modify them with the exception of the glossary. Please

don't. Um, do you know how many times in

my career I have been asked to add more characters to a

field? Oh God. Yeah, I'm sure. I'm sure.

No, we can't do that. We are not modifying. No, no,

still no. Nope. It's

true. I get it. And I got to live by those same restrictions, right?

There's plenty of times when somebody says, geez, we want that field to be,

I don't know, 32 characters long. And we go, sorry, can't do that.

Right. Yeah. It's a very, is the word

invasive, intrusive, or both? All of the above.

Yes. Don't delete data items from data structures. What are

data structures? Well, there's processing options.

Don't delete a processing option value. No,

right? As you probably noticed, we have processing options out there that

have the word obsolete on them. Why? Because we don't delete them

either. Okay. It causes problems. Form data structures, report data

structures, business function data structures, which includes named ER data

structures. Don't delete. Bad idea.

Okay. Don't delete items from structures. Don't

write code around a new value in an existing processing

option. So maybe we're checking for 0, 1, 2, 3.

You decide, hey, let's do 4. You're running risk. Why?

Because what if I decide to do 4? Now what are you going to do?

Right. It's just, just, just, and I reserve the right.

To make those changes. And I lose. Absolutely. It's your software.

Unfortunately. Yeah. And we win, so to speak. So, we already said this one,

use user reserve fields if you're a customer, but not future

use fields because future use fields we put there.

Try not, I shouldn't say try not, I guess I'm just more

empathetic to the cost, but I say do

not use existing fields for another purpose. Right.

I don't know that I'm talking to customers right now, business partners right now. I

could be talking to my own development team right now. This is one of those

pet peeves that I have is somebody decided to

reuse an existing field for a purpose it was never intended.

And then we wonder why things break, because

nobody knew that all of a sudden we're going to put the 19th

character of the 32-character string when

it is X is now going to mean Whatever. No,

just no. Don't do it. Just don't do it. All right. Don't

override data dictionary items settings in an

application. Bad idea. If an app doesn't have the toolbar

up top, don't go into FDA and add it. There's a

reason it doesn't have it. Yes, exactly.

Maybe to kind of wrap, the base object, obviously we own.

If you copy a base object, which I would call cloning, right?

You own that. Yeah. Well, as soon as you clone it, like we said before,

you own it. So we'll own the base. And this is where many times

when you call into support with an issue with your

customized version, we ask if you could reproduce it in

the pristine version, which gets back to kind of managing your

customizations. One good thing to make sure that you have is a pristine copy

of everything that you can go back to, to try to reproduce.

Easier said than done. I 100% appreciate that. I

really do. I'm just putting it out there because it is best

practice, but that doesn't mean it's easy. It doesn't mean it gets adhered to all

the time. But in many of these instances, we find

ourselves going, all right, at least to establish a

baseline, can you go back to the preceding object and are you able

to replicate it? We ask that as if that's a simple thing,

and I recognize that it's not because it's likely a different

environment, it's likely different data, it's likely different volume,

it's likely different— I don't need to go on. I get it. It's

very, very difficult in those cases. But

regardless, if you clone it, you own it. I mean, that's

enough for this time around. I think so. You know, I mean, there's more, don't

get us wrong. Yeah, there's probably some more we could talk about and Maybe

we will. And maybe not. In the future. Well, you know, maybe I trip

some triggers and we're going to get some negative feedback and I'll

have to deal with that, but that's fine. Again, many of these are

best practices. Many of these are things that will get you in

difficult situations. I've seen almost, I

hate to admit it and maybe I shouldn't, but most of these I've seen violated.

Oh, 100%. You've been around. You've been with JDE a

long time, so I'm not shocked at that. Yep.

And many of the times when I've seen them violate it, I'm on site and

I'm pointing it out, and then I'm being educated

on why I'm wrong. And then I just remind them

that, then why am I here? Right. You brought

me here to solve your problem. Anyway,

enough on that. I don't know if that's helpful to folks. Or not, but

there are dos and don'ts and guidelines for customizing the

software still, because we can't get

100% away from it yet. Nope. Not quite there yet,

but I think this was a good overview. Hopefully, like you

said, it was helpful for our listeners. We know we have newer

folks that listen. I didn't even know there was actually published

guidelines, but I'm also not a developer. But

now that I know, it might be interesting to go find those and

maybe we can link to them in our show notes so that if people are

interested and want to make sure that their business is

following best practice, or as they're looking at maybe some of

their decustomizations, if there's an opportunity to

even bring this in, if maybe they haven't followed some best

practices. Agreed. Yeah. All right.

Well. Can't wrap up without one last item.

Oh yes. What is this week's

Midwesternism? This week's Midwesternism is

actually brought to you by a friend of yours that sent you a Facebook

video that was rather entertaining. But there were some things in said

video that I was like, oh my gosh, wow, I haven't said that in

a while. But yeah, funny as heck. And one of those was

Clicker. Ah, the old clicker. The old

clicker. Can you hand me the clicker? I want to change the

channel on the TV and I use a clicker to do that,

AKA a remote control. We have names for

everything. I know. I mean, it's like we can't call it by

whatever it is. Nope. Yeah. Like who thought the clicker and how

did that catch on? Quite frankly. It makes me laugh.

And I know I've said it. I think I retrained myself. I

probably got made fun of at some point in my life. And I retrained myself

to say, oh, can you hand me the remote? And so, hey, can you hand

me the clicker? Yep, absolutely. I mean, that's, that's probably the one

that everybody's used to is, hey, give me the remote. Yeah. I mean, I use

that for everything. But it's like, no, I want that clicker. And I'm not talking

about the PowerPoint thingamajig. Yeah, right.

So I can point to that specific bullet on my slide. I'm referring to

the remote control so I can change the channel. Which almost doesn't make any

sense anymore because most of them now have that little thumb thing that they

ripped off of Apple and there's not as much clicking involved. Clicking. Yeah,

there's definitely not. At least on certain

brands, I would say. Brands, for sure. Oh yeah, that's fair. Maybe certain

brands of televisions or whatever. So at least the ones

I'm most familiar with anyway. So, oh, the ones where you actually have

to walk up to and like turn the dial. Oh, 100%.

Yeah. Dang, man. And then you gotta get the rabbit ears just right. You might

even have to get some foil to put on the rabbit ears. And

then you gotta get it just right. You're dating yourself. And then you can't take

your hands off it. So then the problem is, is then you gotta get outta

the way of the TV, but you have to stand there and hold it so

that everybody can watch. Okay. Never mind. Yeah, dating yourself, just so you

know. Uh, yeah, yeah. Yes, but the first TV we had in my house

definitely did not have a clicker. I remember getting up to change the channel.

Yep. For my parents. For my parents. I think it—

right? Yes. Oh, those were the days. As they were sitting

on the— what is it, the Davenport? Well, that might be coming

in a future episode. Oh, my bad, my bad. Did I— You're jumping

ahead. I might have read ahead. My bad. Yeah, sorry.

Oh, oh, geez, you really messed

that one up now, didn't you? Geez Louise. Geez Louise.

All right, until next time, let's keep learning, sharing,

and most importantly, laughing together. Toodles! See

ya! Thank you for tuning in for today's episode of

The JDE Connection, a Quest On Podcast production.

Show notes and links can be found at

questoraclecommunity.org/jdeconnection.

To learn more about what's happening in the Quest JD Edwards community,

visit our website at questoraclecommunity.org/jdedwards.