Name: JD Edwards Orchestration Functionality for Operational Success at Oil-Dri Corporation of America
Uploaded: 2025-04-22T19:32:18.066Z
Duration: 54 min 40 s
Description: JD Edwards Orchestration Functionality for Operational Success at Oil-Dri Corporation of America

Transcript for "JD Edwards Orchestration Functionality for Operational Success at Oil-Dri Corporation of America": Welcome, everyone, and thank you for attending today's webinar, JD Edwards' orchestration functionality for operational success at Oil-Dri Corporation of America. Before we begin, I wanted to cover a few housekeeping items. If you have technical or content related questions during the presentation, please use the q and a box and we will address them. Closed captioning is available by hovering over the stage area and clicking the CC button at the bottom of the screen. To access today's resource materials, simply select the docs tab on the right hand side of your screen. And of course, this presentation is being recorded and we will send all registrants a link to the recording post webinar. And now I would like to introduce our first speaker for today, Mark Wilson. Mark is the senior engagement manager for managed services at Argano. With a strong background as an IT director and senior project manager, he excels in program and project management, business process optimization, IT strategy, shared services implementation, and business intelligence. In his current role, Mark drives organizational efficiency and supports strategic decision making. Mark, welcome. You may now begin. Thank you, Carrie, and welcome everyone to the, to the webinar today. We look forward to discussing our topic with you, and, I'll quickly step through our agenda. So, the first thing we'll we'll go through, we'll do some introductions of our speakers today. We'll talk about Argano, just a little bit. Don't wanna bore you too much with that. Then, we'll get into, Oil-Dri, what we did with their upgrade project, and their project overview. And then we'll talk specifically about one particular orchestration that we developed during their upgrade, which uses a product called Active Factory to monitor their equipment and and, you know, report back to JD Edwards and create, any kind of work orders that are needed to go out and monitor that equipment. So, first thing, we'll talk about introductions. I'll go back to the to this slide. First, our first speaker will be Anthony Cacciatore. Anthony is the director of, he's a manager of application delivery at Aldra. He's got over twenty five years experience in JD Edwards, primarily in the manufacturing and distribution side of the business. He oversees their upgrades and continuous improvement projects, ensuring that the company's systems are optimized and up to date, and he keeps up with and actively adopts new features. So, Anthony plays a key role in driving new functionality at Oil-Dri. Leslie, Stephenshaw. Leslie has been with Oil-Dri for twenty four years, in a variety of roles and operations and planning before moving over into IT. She joined IT during the initial implementation of JD Edwards in 2018. She is currently a manager of application delivery with a focus on department intake and prioritization, automation tools, use cases, and JD Edwards' order processes. And then we also have Diana Maas, who is our senior director of technical services for client for client services at Argano. She's got thirty six years of IT experience, twenty four years as an Oracle developer and tech lead. She specializes in designing and developing deliverables, troubleshooting conversions and interfaces, and creating strategies for discovery, reporting, upgrades, resource management, and quality control. Diana's been integral to many JD Edwards EnterpriseOne implementations and upgrades. She was the, the, tech lead for the upgrade that we did at Oil-Dri, And she excels at translating abstract ideas into defined deliverables and transferring knowledge to clients for ongoing success. So these these are the, presenters for today. We will talk briefly about Argano. So, Oh, alright. So Argano is a dynamic digital consultancy that combines design and delivery to create sustainable, high performing business outcomes. We have business units, dedicated to all of the major, software suites, but our largest business unit is our Oracle, business unit. That business unit is focused on Oracle Cloud as well as, all of the Oracle JD Edwards, products. So we have, successfully completed thousands and thousands of projects. We have a net promoter score of 86, reflecting our commitment to customer set. This is compared to the industry average net promoter score of 35. And Oracle was a, 24 partner awards winner of the, North American application innovation category and showing our commitment to innovation on behalf of our clients. So, first up will be, Leslie. Leslie will tell us a little bit about Oil-Dri and, the upgrade, project and and kinda how our how, Oil-Dri got to where they were at when Argano stepped into the system. So, Leslie? Good afternoon. I'm gonna give you a little history on Oil-Dri. We are a mining and manufacturing company headquartered in Chicago, Illinois. Oil-Dri mission statement is creating value from sorbent minerals. As such, we look for innovative ways to use our raw materials in a variety of industries. We're founded by Nick Jaffe in 1941. The company is now run by his grandson, Dan, who's the third generation to lead Oil-Dri. We are a publicly traded, closely held company, and we are proud of the family aspects of our leadership that translates to multiple generations of teammates working at both our corporate implant locations. Recently, we had a new lawyer joined who whose mother worked for Oil-Dri and whose grandmother worked for Oil-Dri. Central to how we operate are our we care values and our lessons learned. These are a series of commandments that drive how we work. We have a keeper of the culture who travels to all of our facilities to train teammates on these values, and that training includes conversations among teammates about how they've seen these 24 lessons learned in practice. Examples of our key values and lessons learned are winning at Oil-Dri as a team game. And if you're not making mistakes, you're not doing anything, but don't get kicked by the mule twice. We have five mining facilities in The US where we mine, process, and package our raw materials. And in Illinois, we have our innovation center where our research scientists are focused on expanding the use of our raw materials. We do have our business split up into consumer products and then a b to b side. And, we are able to, use our raw material over various industries. So our main consumer products in industry is pet care, where our product is cat litter. We have an industrial division, and that was where our original product actually called Oil-Dri comes from. That's to soak up spills, like, on a garage floor. We have a sports division, and we make a product used to build the infield for baseball diamonds, and most of Major League Baseball actually uses our products. On the b to b side, we have a fluids purification division, which, their product is used for removing color and contaminants in edible oil refining. We have an animal health division, and that we our product is an additive into the animal feed for gut health, and it's used in chickens and swine and other farmed animals. And then we have an agricultural horticultural, division, and those granules are used they're spread on the fields, and they're used to help with crop health. In the bottom here, you can see there's a variety of brands that we sell our products under. So that's a history of Oil-Dri. And then for our history with Oracle JD Edwards, so we implemented Oracle JD Edwards in 2018. We were coming from a green screen AS 400, very customized system. That was mainly in inventory and accounting system. When we implemented JD Edwards, we implemented all major processes. So order to cash, procure to pay, plan to produce, and we, moved our maintenance into JD Edwards. We went live with an unstable system, and it took us about two years to stabilize that system. Over time, we realized that we had customized JD Edwards much more than we had intended. So in 2022, we took on a project to remove our customization. So it's about an eighteen month project where we stopped all development. We had an escalation process that we put through any customizations that the business wanted to keep, and the business had to present their case to the CFO and the CEO to keep their customizations. The goal coming out of that project was to keep up to date with releases, and to implement a consistent release schedule. We did implement a tools upgrade just this past fall in 2024, and we are now working on making sure that our internal customers understand the benefits of these upgrades and so that we can keep implementing them in the future. And Anthony is going to give you some more information about how we've using been using orchestrations. Thank you, Leslie. So, as Leslie had said, we originally had gone live with, JD Edwards back in 2018. The project that I had taken over was a Code Current project, and, one of the goals of that project really was, as Code Current usually is, is to get to the latest set of application and tools. As part of that, we did stop all of our development, and we implemented a strategy to remove as many customizations as possible. And we did that because we wanna stay code current, and we wanna be able to take ESUs and things of that nature in the future. So getting rid of customizations was our number one goal and utilizing, on the glass solutions which are less intrusive. And it is really the way JD Edwards is going nowadays to, utilize things like form personalizations, form extensions, orchestrations to help us become more efficient. Overall, we were successful. We removed about 50% of our intrusive customizations, and, we continue to build new orchestrations. Our internal business teams really love, the solutions that have been coming out of it. And, at the time when we were starting this code current upgrade, the orchestration that we're going to talk about here, which is active factory and part of our maintenance solution, was a very complicated process. So internally, we really did not have the skill set, and that's when we reached out to Argano who helped us, with the overall project. But we really found that their level of expertise related to helping teach us and design these more complicated processes was quite helpful. So just some stats on our project overall. As I told you, our project had number one goal of removing customizations. And, as you can see, the the dark blue bar here was what we started off with, which is about 330 customizations. We had them in different classifications. But, in overall, we reduced that down, to a 67 customizations left over, but the middle section, which are modifications to standard, we reduced those tremendously, and that was really what our goal and target was. So, that's the overall strategy related to our project, but the part that I think you probably are most interested in is talking about the, targeted orchestration, that we identified at the beginning of this project that would really have a big impact to our business. So the term act, the factory, it's a it's a product. It's a software system. It has actually changed some names over the time, but basically, it's a product that our maintenance department uses. And in a nutshell, what it does is it monitors all of our PLCs, that are set up on our different equipment throughout the manufacturing area. It does things like monitoring hours that it might be running. It might be monitoring the temperature of individual machines to make sure it doesn't go out of tolerance. But, basically, it will trigger alerts, and these are things that we actually had to have people sit around and watch, originally because they would have to take those alerts and manually go in and enter work orders, maintenance work orders in the maintenance system in order to, take action on those alerts. There was a period of time in which we created an internal solution, in which we, built the bridge or the interface between the two systems, but noting that we were going to be upgrading and getting on these new great orchestration features. It really was only an interim solution until we could figure out how to, leverage JD Edwards Orchestrator to achieve even a better output. So, talking a little bit about our legacy implementation, so this was that interim that we had. Originally, it was an integration between the two systems. It was built around reports now, really, which would go out and interrogate the various servers that we had active factory running on, and it would drop a file. And that file would be picked up by our EDI system and sent over to JD Edwards to process. Again, we had many different resources that had to be involved with that. As far as our orchestration approach, it is basically a few custom tables that we needed to set up in JD Edwards, and that's things like master data that we just didn't have any other place for in JD Edwards. So we could say these are our machines, these are the, intervals that you have to monitor it by, these are the ranges in which an alert is triggered, and then there's connectors and other transformations that happen. I won't go into detail. I think Diana will talk a little bit more about, the details of how the orchestration works, when she comes up on stage. So just represent representative of how our legacy solution looked. As I said, we had about five or six different servers that were running active factory at the individual plants. Our, we had a reports now expert who knew very well how to write reports and will go out and interrogate that, drop it into a file in which EDI would then transfer that to JD Edwards. After we implemented the orchestrator solution, what we found was that we could actually leverage, the Insight BI tool which came with the active factory product. So we were able to centralize all of the data into one specific database and then use JD Edwards connectors to go out and interrogate just the, single point and gather all of the alerts and bring them into JD Edwards. So I think at this point in time, I'm gonna introduce Diana Maas, from Argano. She's gonna go into a little greater detail, as we walk through, the details of how it's set up. So there you go. Hand off to Diana. Thank you so much, Anthony. I appreciate that very, very much. Hey. Good afternoon, guys. Thanks so much for joining. As Anthony indicated, I am gonna go ahead and step through the various pieces and parts of of the orchestration that we built to support sorry. My screen went blank for a second. To support the various asks from from from Oil-Dri. And and just restating what Anthony said about what the what the asked task was. They wanted us to replace processes that occur occur outside enterprise one. These processes might be homegrown solutions or they might be other third parties that you've leveraged third party products that you've leveraged to make that connection between JD Edwards and some other product. Could be Bill Pro. Could be Historian, also known as Active Factory. Could be a variety of things, right? And there was a little bit of a complicated process as Anthony indicated. They had the reports now that dropped a file out there, created a CSV, they moved the CSV into a shared location, Then they went through the machinations of reading that up and getting that staged in an appropriate way for EnterpriseOne to be able to manage. So what did we do to help them solve that solution? What did that replacement look like? It's it's a variety of components. As Anthony Cacciatore mentioned, we did still leverage traditional what I think of as traditional JD Edwards development objects like a file a file table here or there that we required to hold data that isn't innate to the JD Edwards product. We also leveraged some UVEs that they already had in place. Why reinvent the wheel when they already have it in place and we can leverage that within the JDA which toolset doesn't exist outside of that toolset. And then there are some business functions that we wrote. Those of us who have worked with Orchestrator, those of you who've worked with Orchestrator understand it's more of a design process than a logic process. You may be able to add pieces and parts in of other UDOs that actually do logic, like a logic extension, but really you're taking the building blocks that are already present in your EnterpriseOne system and you're layering those, building a process out of those to complete an automated solution for you. So as Anthony Cacciatore indicated, one of the pieces of information that we didn't have available in the EnterpriseOne system in an easily definable, identifiable, updatable place manner, was their service tags. We have service tags, and each of the machines that we need to reach out and check on has information about it that we needed to store in a retrievable place. And, also, we needed to have some additional criteria, as Anthony Cacciatore mentioned, about time frames. What's our window frame? What are we looking for from that particular piece of information? So we're taking what we have in enterprise one, wrapping that with an orchestration and reaching out to that endpoint. So this this is the initial let me back up on that a second. The slide that you're looking at right now is the initial orchestration that that reaches out. That first orange box, so diagram one, is actually a data request. That data request is going to go out to that new file that we created that holds the service tag information for the various pieces and parts that we want to go and do inquiry on. Has a active and active flag. You may have a machine down for a certain amount of time. You wanna turn that off. You don't want somebody to get messages every fifteen minutes telling them a system is down when they know it's down. It, loses the priority of that message. That next, that next diamond, the purple shaped diamond, the diagram two, that that actually is applying a very simple rule. Did I find a machine to do a service tag to go do introspection on? If I didn't, it merges at the end of that top little kind of grayish kind of a row, so it does not do the other steps below to go determine what other happenstances need to occur. So if you look at if you look at the diagram and you see diagram three, f of x means formula. Right? It's calling an NER. What does that NER do? That NER goes out and gets a batch number. Now we did have to create a specific batch number because we are leveraging an alphanumeric variable to load into the z file processor that we're gonna use down the road. Leveraging what is in enterprise one so as not to recreate any of those tried and trued and very, very quick to process with all the rules and regulations Edwards applies to things. So it goes on and gets a batch number. And then the and then the diagram four, that is, a form request iteration. And what that iteration is going to do is it is going to call the next, Sorry, guys. It's going to call this next orchestration. And the next orchestration just simply starts off on based on some of the information in my in my file that I queried, the data that I got back on my individual service type that I'm looking at right now. What time frame? What window am I looking at? What what is my rule that I need to apply to the data that I'm going to get? And then we have a couple different ways that we can go. If we go the top half, you'll see that the diagram number two there has the little cloud and the little plug, which means it's a connector. It's connecting out to a specific endpoint, an API type of a URL where it's going to retrieve specific information. And that specific information is then gonna allow us in the in the next diagram, which is diagram three. Diagram three is all about what information am I going to accrue. What notification do I wanna send? What are my alerts? What information does the does does the EnterpriseOne system need? Why does it need that information? As Anthony intimated, it's not just sending a notification. It's not just logging something in a file. We are entering that data into an interactive application. That interactive app application is gonna accrue that information for each and every service tag in each and every possible alert from that service tag, and it's going to present it available through an interactive application. But then we're gonna read through that, which I'll get to in a minute. But we'll read through that, and we'll build work orders. Right? So that first that top that top, flow is if I accrue one set of data. And then if we go down to that second flow, you'll notice it's a little bit different because the diagram for there is an f of x, which means that the NER. And so what is that NER doing? That NER is actually determining, it's determining time information. So on my top alert, did I have a time frame that I needed to be concerned about so I needed to do some time calculations? No. It could just flow along in a more simple process. But we break that off based on the rule in diagram one. Do I need to get some time variation to make a decision about whether to log an alert and therefore send a notification and build a work order? So presuming it flows along, it's got another connector because it's, of course, going to a different API because it has additional information it's carrying with it and potentially different information it's bringing back from that form request. So both of the diagrams, three and oh, gotta count. Three and six, those both are form requests that write data into into an interactive application, and it's an iteration. So if my service tag information that I get back has one or five values in it, it's gonna load all. This moment in time, the product only sends us one tag. But the way that API was written, it sends us an array, so we had to write it into an interactive application grid as an array. We couldn't trust that it was one single record. So what happens when we what happens when we get to the end of that and we're at diagram seven? Diagram seven is gonna bring us back into that first orchestration that I showed you. So now we've iterated over all of the possible service tags that we pull back in diagram one in that data request. We've put we've done all the form requests, all that we can, and now we're back to the call to the second orchestration, the sub orchestration that we looked at. And to the right, you'll see diagrams five, six, and seven. Those are all UBE calls. So what do those UBE calls? That first UBE call give me just a second. Sorry. 67 actually take I read that wrong. Diagram five was a brand new custom UBE that we wrote to support this process, and it actually steps through the various alerts that we have out on that, interactive application in that file that I mentioned on the previous slide. So we would read through all that, and we make some determination on that. Were we over or under specific temperatures? Are are pressures being maintained? And we take that information, and we parse it out and we build it into the various fields that are required for us to call the next steps out of the process. So we are taking the information that was in the initial file that we read. We're taking the information that we read back on the API that tells us about the various service tag bits and pieces of concern, and we're merging those into single think of them as single data streams for that specific service tag. Then we take that information and we call a custom UVE that Wildra had previous to this process, and we leveraged that to build that work order in the JD Edwards interoperability system. So it's a custom customization over a previously delivered JD Edwards product, UBE, that we needed additional information based on the service tag information to write that record out there in the z file. And then that last UBE, that diagram seven, is a call to the JD Edwards based UBE that takes that work order processing information and then generates those work orders into the enterprise one system. And when we get back to that top row, which is diagram eight, it's. It's over and done. The system goes back and waits for the next time that it's going to run on scheduler. So that's that's the end of that's the end of my conversation about this piece. So what maybe we can do is kick this back over and talk to Anthony or and or Leslie about some of the pieces and processes and the deliverables that they've created that Anthony alluded to earlier in this session. They were gangbusters about this product, and they moved ahead delivering for their team. So take it away, Anthony. Thank you, Diana. You're welcome. Diana actually made the complex sound relatively simple there. As you can see this, although we did already have a solution prior to switching it over to orchestration, there is no way that we internally would have been able to tackle this on our own with our own knowledge set. So Argano did a fantastic job. One of the things, the benefits that we see related to this is that in our old solution, it was very cumbersome for us, to bring on new machines, and and we really were only doing our legacy system with a couple of machines. What this solution has actually, allowed us to do is to set up many more machines that operate, and we can do them much faster, to bring them up online. So this this has been a huge win for us at Oil-Dri. And, as Leslie said earlier, winning is a team game, and and we're happy to be teammates with Argano. So that was really kinda like the beginning of our journey, related to us learning orchestrations. And, we have since then implemented a few more orchestrations, actually. We've continued to use the tool. We've learned a lot more internally. We still reach out to Argano to help us with complicated matters, but that was, like I said, just the beginning of our journey. Since then, we utilized the transportation management module, And, so I'm just gonna list off some other ways that since then we have been using, orchestrations at Oil-Dri. So, we actually ship in full truckloads, frequently, and we use Wren McNally as an external tool to provide distance for each of our loads, and that helps us shop different routes and and mileage and all that kind of stuff. We had a older solution that utilized BSSD connection, and that was always very unreliable. We have since then, transformed that into an orchestration that runs at the time that the loads are created, and it has become exponentially more reliable for us. Some of the other areas that we have, engaged orchestrations is in different areas of mass data updates. I think that that's a natural first step, for doing things. So a couple of the ones that we've done is our new vendors. So we add new vendors through orchestrations and we also deactivate vendors through an orchestration. We utilize, drop ship processing with another business partner of ours, and that involves a process of us sending them orders, communicating with them what needs to ship by who. And then, they do the shipping and then they send us back information that says we ship using a different carrier, and this is how much the freight was. And that was a very manual process that involved six or seven people to manage. We have since then automated that process, and it has dropped the headcount by at least one or two. Also, we utilize orchestrations for the purchasing area. So we do create blanket orders, and we do that across our various plants. We try to create one one single blanket order, and that was all being done in Excel, in order to aggregate all of the data to be able to write a purchase order. Since then we have now been able to utilize orchestration to aggregate the data all in one single press of a button. It comes out and tells us what blankets need to be written and actually write the blankets for us. Tremendous time savings. We've also fully leveraged it. They love that. So they said, hey. We want a solution to, help us release blankets or release POs from blankets, and we were able to create that as an add on to it. In the accounting area, I think there's a lot of areas, ripe. And again, we do have many more than just these. These are the ones we highlight, but we also in AP, we have a speed voucher entry, and in AR, we also have a speed invoice entry. And then one other one I'd highlight is, we have things called planners, which are, actually in our sales, sales area in which we plan for promotions and other things like that. These are areas where our data would get a little bit funky over the course of time because, nobody was really maintaining them and updating them to show the current status, just because it was very time consuming and we were able to leverage orchestrations to help that group of people, be able to do mass updates in order to close all of their planners out. So just a couple examples, like I said, we're our we work off a project list and, we do have our business is very excited about the solutions that get delivered to them, so our list of what they would like for us to do is ever growing. So, just a little sales pitch. I think it's a it's a it's a great thing if you have not adopted it yet. So any no project or or tool would be good if we didn't actually look retrospectively and and gather some lessons learned. Right? Because learning is always a a journey here. And, we definitely learned some lessons as we were going through this process. One of the first ones, again, we were very optimistic about, what the orchestrations could do and we participated in a lot of Oracle demonstrations, and I think we probably, overestimated everything that orchestrations can do. So one lesson learned that I would, point out to you is that not all customizations can be, replaced by on the glass solutions. There are just some things that, either the way Oracle has it set up or it's the tool just isn't developed far enough. It keeps getting better and better, but not everything that we wanted to do could be done on the glass. One other thing that we learned, like I said, our business teams are very positive about orchestrations and what orchestrations can do for them. Part of that, I would suggest that as you're going to do this, I would educate and really promote your business teams, as to, what's coming their way. We got our teams very excited. We showed them a lot of things, demonstrations that Oracle had done, and they were very open and optimistic about us delivering to them things that they had seen. Another lesson learned is really around project planning. I would always say that when you go to either do orchestrations or any kind of big project, we've learned that the the plan itself, was the key to our success. Argano has been a fantastic business partner for us. They have all of the experience when we set out for, our code current project. They probably saved us months at least just in having a plan ready and available, able to, execute. So we really feel that that was the key to our success. Just looking at a couple other ones, the good orchestrations because, of course, we've abandoned orchestrations in the past, that's how we learned this. Some of our bad orchestrations, we were trying to bite off way too much, all at once. So what I would tell you is that in order to come up with good orchestrations, I would tell you that it is an iterative process. I would always tell you to crawl, walk, then run, because you learn things just by doing it. And when you start out with anything that's way too complicated, you kinda get lost in the weeds. So start out small, do things that you can accomplish and then learn and build upon, that skill set. Another one just it's not limited to orchestrations and I'm sure all of you already know this, I'm probably preaching to the choir, but testing, testing, and testing. So, make sure that you, plan appropriately, give it enough time and make sure that you develop good tests, have good test scripts. We went through many different iterative processes, and, you know, you always still find something even if you have tested really well. We internally have created, archives of all this and we are constantly improving that. We actually also are attempting to get to automated testing at some point in time, so that is a goal for us in the future, hopefully leveraging, the orchestration toolset. Again, orchestrations, they in order to to do good orchestrations, they have to be based on a well defined process, not creative coding. So if you can if you can't put it down on a flowchart, you probably shouldn't start the orchestration. So make sure it's defined very well before you start on it. Otherwise, it it never will come out the way you intended to do. Again, another one of these lessons learned and this goes back to our testing, testing, testing piece. We had an issue which dealt with time zones in the data. So as I told you before, a lot of our Historian products are they are located throughout The United States in our different plants, and they all had different time zone markers on them. I think when we started testing, we didn't really understand that or know that, And, we kinda got bit by the time zone data after we had gone live because, our maintenance people started noticing that they were getting alerts, but the alerts were saying 6AM when it really was 10AM. So, we had to go back in and make some changes that didn't really hurt us in any way, but it is something that, we didn't pick up in the testing and and we did end up having to do a fix. And then the last thing that I would say from a lesson learned is, stick with it. Keep building new orchestrations, keep learning. Oracle is constantly coming out with new things. I think some of the things you don't even see them here, but we've started using them more, is the what do they call them now? Well, they have workflows in there and everything else. So they're they're constantly enhancing the tools. We have even things that we built before that did not let us drop files in and go from a spreadsheet to upload. Our latest upgrade to the latest tool set now allows us to do that. So our we our business teams, really find that they're seeing the value of our upgrades by the tools that we're able to provide to them. So, you know, that that is a big part because our people say, well, what are we getting for the effort we're putting in? And and this is the one area that I would say that they, they are seeing the payback. We are giving them solutions that definitely affect the work that they do in a positive way. So that's pretty much all the, the lessons learned that we have. Hopefully, you've enjoyed my presentation and Leslie's and everybody else. I think we're gonna I think we're at the end now. Right, Mark? Yeah. Thanks, Leslie and Anthony and Diana for, everything that, that you've shared with us this afternoon. I know we've, we've covered a lot of information, and, you know, there's a there's a lot more out there. So, what we'd like to do is, if you guys have any questions, there's a q and a box that, that you can enter your questions in. And, we'll we're more than happy to, to answer any questions that we can. And if, if you if you, if you stump the panel, so, if if you put in a question in there that we can't answer, we, we will get back to you on that. So feel free to to enter your questions, whatever questions you have, and, and and we'll we'll, answer those for you. Mark, I thought you were gonna offer, like, a dollar amount price for a stump. Yeah. For a stump the panel. Yeah. No. I'm answering that one. Yeah. Hey. So, you know, as as we wait for any questions that might come in, I thought I'd touch back on what Anthony was saying about the time zones. And he really is correct. It didn't really burn us, but it did make us do, oops, what happened there. So so what we discovered was that historian was being asked in returning times in Zulu time time zone. Right? U UTC. So what the developer did was write a little business function that looks up the user's configured time zone. So what he really did was he stopped using just the regular, business function for the various audit fields, and we modified, wrote a new one that would actually go see what that user was configured in. And then based on the times on the server, it would convert that and make that more of a real time valuable time zone, time information for for the user. And that and the other piece that we found out is that during that process is that the it part of the, part of the discovery was exactly how that API that we were calling was returning the format. So it's actually turning it in, in ISO format for that date and time, which is a little bit different than JD Edwards UTC. So the way that they store that UTC, so we had to do some little hop, skip, and jump in the business function, but didn't take very long and, and turned that right back around and had Anthony and team back up and running. So no questions. The one thing I'll share with you yeah. One thing that came in, prior to this, this this, webinar was a question in regards to when if I'm if I'm on whatever tools release or whatever apps release I'm on on JD Edwards, can I take advantage of orchestrations? Right? Can I take advantage of some of the things that Anthony referred to when we talk about omnichlass? Things like form extensions, personal forms, logic extensions, which is one of the newer ones. Depending on what apps release you're on and what tools release you're on, yes, you can. If you're on nine two, a lot of apps nine two, then a lot of the UDOs are present. Orchestration became an integrated product in 09/02/1946 and has marched onwards since then, delivering a lot of, newer features as Anthony mentioned. What if what if you're not on nine two? It could be a challenge unless you're on nine one. If you're on nine one, you can take the option to go to a nine two two a nine two tools release. It is limited, and you can only get as far as nine two four six. But that does give you, if you're on nine one, some of the facilities that you do get with an orchestrator. It's doesn't have doesn't have some of the full blown things that we talked about on this orchestration. Can't cannot cannot pull in arrays. I'm trying to think. There's no there's no I'm trying to think what else is not there. Definitely not arrays. No logic extensions. Connecting an orchestration to a form extension, that's not there yet. But you can do orchestration. So you could start to replace some of what you think of as maybe, antiquated manual processes or or old school processes that that could benefit with an uplift towards more of a real time approach. Right. And, you know, just staying code current, you know, the ability to to get up to a point, as Anthony and Leslie mentioned early on in the presentation. You know, their one of their goals was to Mhmm. Eliminate the modifications to make the upgrade process a lot easier. You know, if you've got a lot of modifications, whenever you try to do an apps upgrade, you know, you've got, retrofits you've gotta do. You've got a lot of testing, gotta do things like that. But, if you can get to a point to where you can plan that and and stay code current, then you can take advantage of of a lot of these tools because, the the tools update is where Oracle is putting a lot of this functionality Mhmm. When you're when you're talking about, orchestrations and and UDOs and and those types of things. So, you know, it's it's to to your advantage to to stay to get yourself in a position to stay more code current. And that is correct, Mark. So just sharing our experience. As Leslie pointed out, our code current project was eighteen months, from beginning to end. And since then, we have actually done a tools update, And that tools update took us I think it was less than three months or it was about three months in time, but that was also over the holiday season. Mhmm. So beginning to end, and the hardest part of it really or the most time actually was spent in testing, which was a little bit longer than a week process. And, of course, it takes us a little while to set everyone up. So it was, much easier left staying current than it was getting current. So, we as an organization, plan to remain current, and it's much easier at this point. So I encourage everyone, bite the bullet and then get there. It's worth it. And, Anthony, one of the and, Anthony, not that it really plays into the whole orchestration conversation or the UDOs, but but like you mentioned earlier in the conversation, when you guys were upgrading, you made it part of the practice of this project to deliver and as much as we could through UDOs and to remove as many of the modifications as we could. And I know one of the things that your team asked for that's not always thought of, and that is, Diana, when you and your team are going through all of these modifications that we've done, seeing if we can replace those with the UDO, will you do us up a document on that so that we know what we have going forward so that if a new UDO does come out that we can look back on that and say, will this UDO replace that now? Because as it grows, we there's more things that we could replace with the UDO. That's true. Very true. Definitely. Alright. Well, if there's no other questions, we'll turn it back over to Carrie real quick and and, let her close things out. Thank you, Mark. That this now concludes our q and a session. If we if you were not able to submit a question, please feel free to submit one later. We also invite you to learn more about Argano's JD Services by checking our docs tab on the platform. You can also reach out to our Argano speakers that spoke today if you have any questions about today's webinar content. A special thanks to Anthony and Leslie for presenting with us today. Also, I want to thank everyone for your time and we hope you join us for future events. Thank you.