Perceptive Content/ImageNow for Accounts Payable

Alex Lindsey:
Hello, everyone and welcome to Webinar Wednesday. Not really Webinar Wednesday sorry, force of habit. Getting on in front of the cam here. Let’s see, there we are. That’s my body. Okay, so today we are going to be talking about the Perceptive Content, AP invoice eForm. How you guys use it, we’re going to do a general run through. And again, thank you guys for attending. I know we’re all in kind of a weird state with the quarantine and things like that. But you honestly gave me an excuse to not wear sweatpants today, so we’re going to roll with that. Just a reminder, so this is an Office Hours, we will basically leave this open to questions for you guys as you go through. On the GoToWebinar you have a hand raising icon that you could do to raise a hand and I can unmute you, to ask questions or you can just type in your questions in the questions tab as well. And then, we’ll address those one by one as we go through.

So, for Office Hours today, talking about the AP invoice eForm, we have some future webinars that are coming up that we encourage you guys to attend, we got on base form solutions. So, kind of the counterpart to perceptive on basic form solutions. We’ve got a really important one coming up April 8th, keeping business moving with remote workforce. This is really important, as a technology provider, how are we going to be able to help you guys, how are you guys going to be able to remotely work, how are you going to find synergies and integrations and things like that to kind of make this weird work from home state, kind of more flexible and easier for you as an admin or DBA. And then we have on base for human resources, April 15th, as well. My name is Alex Lindsey, I’m a Senior Solutions Architect here at RPI Consultants. I have over seven years’ experience working with all kinds of software, Perceptive Content, OnBase, Kofax, ReadSoft Online, Model TER, Workflow Technologies and a lot of integrations with a lot of different systems.

I specialize in accounts payable and some other non-standard solutions that are out there. And I also just build this gig on the side. On the agenda today we’re going to be talking about the AP invoice eForm, obviously, but I’m basically just going to go through and do a general walkthrough of the eForm itself. Here it is, here’s where you can find this. And then really kind of dig into some of those files that are the configuration files that you may use on a recurring basis, that you may essentially want to modify and just kind of show you how these items are related. So that you can kind of work through and make adjustments on your own, if you want. And then I’ll do a couple of example configurations, we’re going to add two new fields to the eForm that we have set up in our environment. And then we’ll basically open up for questions and answers. If you guys have any along the way, feel free to post those in the channel or raise your hand and we can stop at any point.

All right, moving on. So first and foremost, just walk through the eForm itself. Typically, within Perceptive Content, eForm processing is done through a workflow specifically, and open this up. I have no pages associated with this document. But here’s a good shot of the eForm itself. So, with the eForm, we basically got our standard things that are pretty much standard across all ERPs and what they require, which company or business unit are you going to be charged into.

And from here, this is typically a drop down as well, your vendor information, if you have a PO invoice, or you can essentially switch the tab over to this. You can get your PO number driving your vendor information or your invoice number, invoice date, amounts are all going to be items that you can either enter manually, or what we highly recommend if you’re spending the money to do an AP invoice eForm solution, it’s definitely worth it to introduce some kind of OCR technology that can actually read the document image and get that data validated and push it over to the eForm automatically and just rely on those validations and workflow processing.

And if you see down here, the eForm also has line details. So, if you were using OCR technology, you’d see the invoice lines that were extracted off of the invoice document versus the purchase order lines that are listed in your actual database with the data associated with that purchase order information. I’m going to go back up here, toggle back over to non-PO or we’ve got our header information. The nice thing about this eForm a lot of these integrations…or not integrations but the lookups themselves, the hooks essentially to say, when I click this or when I type this, I want it to be like this. Are kind of built into the form itself. We’re not starting from scratch with this, we have built in configurations that are automatically…we know we need invoice number; we know we need vendor information that’s a standard across all of this. So that’s something that if you purchased this, you wouldn’t have to actually build out.

But if you’re on the call today, you’re probably wondering a little bit more about how can I configure this? How can I troubleshoot this? How can I make enhancements to it, things like that. And that’s what we’re kind of going to jump into, towards the end of my presentation part of it anyway. So, there’s the eForm itself, again, there’s a lot of fields you can add and modify, you can format as well, when I jump out. So again, the way this works within image now, you’ve essentially got form files that are associated with that specific form. So, if I go to the table, apartments, navigate to forms. And you can see here if you have the AP invoice eForm and you have access to the management console, you should be able to see this, where you can manage form components. You see here we’ve got a number of different forms, we’ve got the AP invoice eForm selected here. Before you do that, the way that these forms are loaded and again, with the AP invoice eForm, it’s got its own installed package process that has…but you can also kind of manually load it as well.

Ultimately, there’s is a data definition which is your XML. So that is basically the skeleton of your eForm that sits on the back end of the document itself. From a database perspective, if you’re interested in navigating through that, if a document has a sub-object, that’s technically how it’s defined, I think it’s I and doc subbed or something like that in the database itself. But that information is stored. The information associated with the document and the form is stored in that database, you have shared files. So if you have more than one form, you can actually have files that are associated across calendar is a pretty specific one where you have calendar details or calendar files that you want to have on the eForm to put in a date, for instance, that’s something that can be shared. Typically, we don’t like to do that a whole lot. I’ve seen in the past where it interferes sometimes with others. But overall, if it’s not user growth like 10 different forms, it should be okay.

But generally, we like to keep it in its own presentations. So, the presentations themselves this is what it is a bunch of back end files. And I’ll navigate to the specific folder and the in-server directory that has this, so you can kind of make sense of how this was built and pushed into Perceptive Content itself. So, you have your data there, and you have your presentation files here. Within the presentation, you can essentially add all these different files that are associated with the form itself. There’s a few that we sometimes modify on our end for customizations. For instances, is AP, custom validation, if you need to add something specific, it’s basically a holder file that allows you to kind of insert yourself into the normal process of the normal validations and operations of the form and kind of do something specific.

The AP scan XML, that’s one that we actually do modify. In general as a good rule of thumb, do not touch these files, specifically, they have their built in functions, they have things that…especially the worksheet file, the worksheet script, things like that, we definitely don’t want users touching those, admins. I’m scared to touch them to be completely honest. So, we want to make sure that we keep these clean. But these are all the files that go in the background within that presentation that allow it to render within ImageNow, and also back in scripts, tied to the fields specifically, that kick off certain actions like vendor lookups, and PO loads and things like that.

So that as it stands, from a basically components standpoint, in terms of the form itself, and what you can configure, I mean with this, you can obviously create a new form. You have components here where you define the data depth file here, and then you choose a specific presentation. You can have more than one presentation, a lot of times what we do, we have a diagnostic type presentation file format. So, you can kind of see back end data without having to do a quick shortcut, which I’ll show you as well down the line. But ultimately, you can have it there in the windowpane where the form was and see the back end of the data. Those are super helpful and fairly easy to deploy as well. So, going to the map let us now, and then some basic security as well. What you can do within this, you can either create data using this form, delete data associated with the form, modify, or just view. Depending on the permissions and the groups that you guys have using these forms, you can kind of define how you want to specify how they’re going to use it and what they can do with the form.

As an overall general rule with invoice processing, and the way that AP automation solutions work. And then, that’s just not perceptive. But when you OCR the invoice it comes into a form of some sort. In this instance is AP invoice form, it’s modifiable in certain spaces. And I can show you where that’s configured as well, to kind of define it. And then after that, you technically don’t want people changing data on the form itself because it is aligned with a record that you’ve pushed into your ERP like Lawson. So, you want to be able to find that and reference that at a later date. So, permissions can be important. Depending on the industry you’re in especially, where you want to lock that down. From here, this is pretty basic, I wouldn’t worry too much about that, because a lot of the permissions with the AP invoice eForm happen kind of at the workflow queue level. So now I’m going to navigate to a few different places to kind of show you where these are, and kind of talk through some of the relationships there.

First and foremost, we’ve got our in-server directory on the app server itself. Navigate to form, and here you can see we’ve got a lot of different presentations, these presentations. When you install these create its own unique ID that’s stored in the database for that specific presentation. And along with that, you’ve got your data definition here where we’ve got our AP invoice here. And I’ll just show this real quick to kind of give you guys an idea of the back end. So, you can see here, here’s all the XML tags. So, see what this again, like I mentioned, it’s kind of a skeleton of the eForm. So, you can see all the different fields, you can see more importantly, if you’re looking to add fields, remove fields, things like that, this gives you an idea of what you can use or not use. That’s currently being configured on your eForm right now, a lot of times you can see here, we’ve got a lot of these additional amount fields that you can do. So, if you’re trying to get something specific like that, or something…another kind of amount field off of the invoice document, then you can store this information here on the form.

Same with header values. A little later on, we’ll configure this to allow for a new header value on the eForm that users can enter in. But ultimately, and this is something that a lot of users may not know, this is kind of a good time to show this if I can find it specifically. If you’re ever curious a lot of times there’s a lot of hidden data on the back end of a form, right? So, for instance, company we’ve got Team Willis. Well, there’s obviously a code associated with that. For the end user, we want them to see something that makes sense to them, like the specific company name itself that they can choose, but on the back end there is a code and that code will drive lookups and do filtering, potentially for data that you want to pull specifically for our vendor PO, you would only want to pull information from what we have here is Team Willis. So that’s code 01, that would become part of the lookup to vendors, so please return vendors where companies 01 is this.

On the back end here. If you want to see back end data and you don’t have a diagnostics presentation, like what we got here. That one’s obviously broken, pardon our demo environment. Well, there’s some value there that you can create. But if you want to see information here that’s on the background. So, let’s go ahead and put in a test information here. Literally typing in test, let’s call this Alex Test. Always date, I’m going to go ahead and save this. Oops. I hope you’re backup, and here’s something that you can do to see…and this isn’t just for the AP invoice eForm. This is just something that we at RPI do a lot with our testing when it comes to identifying data on the back end of the form. If you have your document open like this with the form itself, you can navigate to the main toolbar up here, hold down Shift, and right click on the blue tab up here. I know it’s very specific and go to explore application data folder.

In here, you’ve got basically a list of folders and a few additional files. What we’re really interested in is this worksheets folder here. And with this, you basically got a list of essentially presentation files of documents that have been recently opened. A good rule of thumb for this is typically if you have a document open right now, typically the…not the last but the second to last file. So, number two in this instance, that has the information you need. So, continue navigating until you find the XML open. So, this file here, so it’s going to say AP invoice, which is the XML, that’s the skeleton again, essentially with the form. And then there’s AP invoice, underscore open. And this is the one that you actually have open right now. So, you can see the data on the back end associated with it. Like I mentioned before, we have our company name, this is what the end user sees. But on the back end you’ve got company num-header, so it’s company number 1400 associated with vendor group 1400.

So, when you’re thinking downstream of lookups and things like that, I mean like, “Hey, return vendor Acme Corp, where company num-headers 1400.” So, these hidden values in the back end of the form help to drive filtering and lookups and validations. It may take some scrolling too, depend on how it renders, you can see these Vendor ID itself on the back end, the payment terms as well, that’s associated with that. And that can either be a lookup, which we’ll add to this form. A drop-down list actually or it can just be return from the vendor information itself. And that’s a nice little tip flash trick to understanding where the back-end data on your form is coming from, let me take a look at this. Make sure we don’t have any questions in here, good for now. Good. Now, moving back over to the directory itself, data depth, obviously I am not sure which one of these is actually the AP invoice eForm this one’s closed.

But ultimately, you can see here on all these forms and presentations, we’ve got all these different presentation files, and this is where these are stored, we have a lot. If you have the invoice form you may have a few others. But that is generally where you find it, I would look for the key values like AP underscore invoice, if you’re really having trouble finding it. So, when you install the AP eForm, you essentially get a lot of subscripts. So, you’re familiar with the STL package, which has…it’s from a script directory here, if you’ve got iScripts you probably understand it a little bit. Ultimately, the STL package has a lot of basic scripts that you can use to integrate with ImageNow, same thing for the AP invoice eForm. We have a lot of subscripts that are integrated within ImageNow that we really don’t want users to touch that much. We really don’t like touching them either. Admittedly, I’ve done it once. And it works but it’s not recommended as part of the part of the product itself.

So essentially, we’ve got AP duplicate check. So, this is a script that just fires off the duplicate check. When you do an action on the form, it’s actually firing these scripts that are then referencing the configurations or the connectors that look up to kind of return those results. So, these subscripts just exist here on the directory to kind of provide support and fire those functions. So, don’t touch those you can’t, we’ve got scripts. The custom validate server scripts that are meant to do those type of things if you need to make some kind of customization. So really don’t touch these. Along with that, depending on your current setup. I know in the past, this is a big thing for RPI when we were doing upgrades quite a bit for ImageNow and we continue to do invoice upgrades, AP invoice eForm upgrades. Also, we like to push our users to use some kind of custom connector or database connector to pull information from.

Previously, with the AP invoice eForm. You can use virtual tables and inside tables. It really used the folder structure, that project structure within ImageNow to kind of house and store data and do it through custom properties. This using a database connector or lookup scripts, tied to this eForm is a much better way to kind of pull that information. Plus, it’s more live data you don’t have to rely on an upload process, you’re pulling directly from the database itself. You get that information, to get that vendor PO information. If you are using a connector, it will be stored under the script directory, APEF connectors and then here you have some out of the box, there’s a demo connector. When you install the AP eForm it is automatically set to the demo connector where the lookups are basically happening. And I’ll show you kind of guys where that is. And that’s where the bulk of the configuration happens for AP invoice eForm is in these config files. And ultimately, you define specifically which connector lookup script you want to use from the AP config XML.

So, this one is basically, the custom connector that we’ve got set up. And this is essentially configured to point to our internal Lawson environment to pull data down to do lookups and things like that. So, I’ll get into that a little bit more when we actually start configuring a few things. Now for basic admin, things like that. When it comes to the AP invoice eForm, most of the things that you’re going to have direct control over are located in the in server FCAP directory and this is where the config files are essentially stored. The first and foremost is the AP config. We pull this up and hopefully this is zoomed in enough, I’m going to start at the top. I’m not going to go through everything, I’m just going to touch on it for a little bit and show some of the key points. You can install the eForm for different ERPs that they have essentially pre-programmed for. This one’s Lawson, but you can also have just a general ERP connector, if you have something that’s not defined. JDF for instance, is a good example where we can integrate a lot with AP invoice eForms.

But it’s just another ERP. Set your date format here, duplicate check. You can also enable this on the form, which I obviously don’t hear but we have just a lot of demo data training through. So, with this, we can basically define how you’d like to do this. So, if you are getting requests or you would like to add a third dimension to essentially your duplicate checks, so typically it’s going to be your invoice number and Vendor ID, you can now identify that. If you want to throw in a mount as well, that’s another common one or date or invoice date, for instance. This is where you would do that in the AP config XML to define that, it’s like an overarching basically validation that’s built within this file itself. Now as you’re testing, for instance, one good thing you can see here, we’re defined and these basically sub-nodes of scripts. These are those scripts I was talking about when it comes to the get companies. Your tax codes, getting vendors is a big one, to kind of identify those scripts that are running on the background.

This is helpful when you’re testing new functionality or let’s say you’re looking for a vendor. And depending on how your eForm is set up now, maybe you’re just not getting any results and you just want to know, what the heck am I seeing? Why is it not working? You can turn your debug level up to five. And that will essentially generate a log within the in server log directory showing you specifically if the SQL statement that was run to go get it, what the database returned, if it’s just a flat out error, things like that, you can do that. And this is going to kind of pivot me into the others as well. If you make any changes to these config files here, you’re not going to see the results until you run the AP maintenance script. So, let me pull that up really quick. Now, if you’re not familiar, the AP maintenance, scroll down here and see if I can find it. I’m not going to do that. Right here, so it’s a back file.

So, what this does is it basically goes through, sees the current configs that are there, versus the ones…basically the ones that are there, again the ones that are stored in the background. Versus the files that exist as well. And they notice any changes, if there are any changes, they basically override it and put those changes forward. So if you wanted to, for instance, turn up logging to get those log generation files, you set this to five here, save the file and you run the AP maintenance scripts, and that will allow you to essentially retest and then render those results when you open the document back up, you should see the items and I’ll kind of walk you through how that works as well. So, kind of scrolling through all this down to the bottom. If you’re doing a flat file export of a specific, so this one lots of specifically we’ve AP 520 and MA 540. If you’re doing a flat file, push into Lawson for instance or another ERP this kind of defines that and where those are.

Ultimately We’d love for all of our customers when it comes to pushing invoice data into their ERPs that do a database insert or something like that Or an API call or push, or pull to basically push that record into the ERP automatically without having the potential breakpoint of a flat file, a shared server folder that has to be pushed into the ERP or manually done even, I’ve still seen. I’m scrolling all the way to the bottom here, when I mentioned the connector itself, and how well it’s conveyed here in the AP config, it’s right here at the very bottom. When you install it gain, it’s a demo connector right out of the box. If you wanted to use the custom connector, you can do this or if you have any others, you would essentially configure that here, run the AP maintenance script. And then, it’s going to try to do the form function to essentially use that connector itself. Moving on the other really, really, really big one here has to do with the AP scan. AP scan really controls what you see or don’t see on the form itself.

If we kind of look through these, it probably looks like a lot of gobbledygook. But you can recognize keywords like business info, invoice info, lines themselves. And as you scroll down just a little bit, you can see this field specifically. So, if you wanted to hide fields, for instance, there’s a visible more down here, where we get into other areas. There’s a visible configuration, where you can mark this as true or false to hide or show a specific field on the invoice eForm. If you need to make it required, that’s automatically going to push over to the validation where if it’s blank and you can try to click Validate at the bottom of the eForm, it’s going to throw a flag and say, “Hey, this field is required.” So, if you are having requests right now of like, “We need to make this field required.” How am I going to do that? AP scan is where you start, essentially.

I did breeze over this too quickly here, under the first config section in the AP scan is actually the roles. Here you can kind of control. So, imagine you’ve got your eForm, and you’ve got your AP invoice workflow itself. This is where you can essentially define if it’s in this queue, can they modify the header? So, the invoice information, the vendor information or can they just do the line here? Can they do both? Can they fill out the GL data points that they need to post this? For POs even, if you need to modify lines and things like that there, can we modify the details? So, header would be your header information. So, let me pull up the form here to give a visual, header information here. So, if you wanted from a specific queue to allow a user to modify the header information, you can essentially copy this here Ctrl D, if you want to add a specific queue you wanted. Make sure that it is enabled for invoice entry at the header level, if you want the detail allowed you as well would basically change that to enable.

Then you would run the AP maintenance and then you should be able to modify that eForm from that specific queue. Let me put one to this one. Questions? I think we’re good here. Looking back at the configuration section here. And we’ll kind of get into this. You can see other fields as well; you can set max lengths or shorten. So, if you have for instance, this invoice number…if you have a standardized format. This is particularly helpful when you’re using OCR technologies. If the OCR technology isn’t looking for invoice number of at least eight characters or exactly eight characters kind of thing. You can kind of modify that or can kind of control that. That’s really helpful when it comes to the purchase order number when you’re controlling the max lengths, and how you’re validating that. A good example would be that let’s say you’re using some OCR technology, it extracts a purchase order number and there’s no rule in place in that technology to say it’s eight or 20 characters, if comes over to the eForm, it’s going to fail validation because it doesn’t fit your ERP’s specific purchase order number format.

If it’s eight characters starting with these things like that, the max lengths are where you kind of control that piece of it. If you wanted to go further with validation, let’s say you wanted to say, “All of our POs start with PO and then dash and a number da, da, da, da.” That would be a custom validation that you’d have to put into one of those custom scripts that are listed. And I can show those again, so I have to basically check for P 0 dash this and then a length, and that’s fairly easy to do as well. So, scrolling through here, again, this should give you an idea of how many fields are actually on the form, when we looked at the data definition here, not this one, B so I’m getting all close and personal. The data definition here. The AP scan is kind of the representative of all those fields. And what you can do or not do with it. You can see here, you can adjust some of the width as well. So, the basic configurations. Again, the label, the field itself. These items here again, just looks like gobbledygook.

But these have references to other sub scripts in the background, I’ll show you how you can kind of use this though, to modify names of fields and make basic to the caption key itself. And honestly, when it comes to some of these fields, when I’m working on this and someone’s like, “I want this to fit.” I got a 20-character thing here, or field or number or ID that I want to show, but the field is only set to like this 13 characters for instance, and you want to extend it. You can extend it, or you can adjust the pixel width as well. And sometimes that’s just kind of hit or miss or troubleshooting, you do a little bit here that’s too much, a little bit back until you find it just right and it’s just basically going back and forth. Being sure to run the AP maintenance scripts after you make these changes as well, so you can actually see those results. In here, yes. That is the high level of the AP scan.

The other piece here is the AP validate server. So, this kind of controls the back end of the…so with an AP invoice eForm, like I said, you get a lot of scripts, but you also get scripts that you can use in workflow itself. They validate server script. So as documents come in, they come in from OCR technology or for users manually entered it at some point, a workflow script is going to stop it for a second, typically as an inbound action run validations. So essentially, we have to have this validate server script, because we have validation on the form, right? But there’s nothing to stop the user from routing that invoice forward. Even if it has failed validation in the form, even if they click validate. And then it shows a ton of red, they can still route it forward in the process, but you don’t want those records going forward and causing issues downstream and approvals or the rework or posting to your ERP. And then you have to go into that, investigate that, see how you’re going to adjust that record, do you do an image now or not.

It kind of erases those questions of basically like, “Hey, we have this, it’s not going to move any further or integrate into the approvals or the integration with the ERP itself until we know that this date on the form is valid and should pass when we push it in.” So here you can kind of define a general error queue when it comes to any validations. What we typically like to do, that’s when it fails-fails, the validate server is going to do a bunch of things like duplicate check. It’s going to check the required fields, it’s going to check if the total amount of the invoice on the form aligns or if the total of all the line details on the form itself. And that can happen downstream after coding as well. But it’s going to do all these checks. And if it fails, what it’s going to do is essentially write to a custom property called AP custom valid. And you can adjust this, but it’s just more of a standard practice when it comes to this AP custom valid.

So, what happens, and this is kind of a standard part of the solution. It writes an error message, failed, error duplicate check, error distribution, things like that. It’s going to write to the custom property and typically downstream, within that queue itself actually, you set up routing rules that checks this custom property, check for specific values, and then route those documents. So, if AP custom valid has error duplicate checks, route it through a duplicate check queue. And so that user has a defined role that are assigned to that queue that can investigate that, “Oh, that actually is a duplicate or no it’s not, I just added an extra five at the end of the vendor number instead and that’s why it got caught.” So here you can actually define when we talk about the eForm right? If you’re using OCR technology, it maps the form it can kind of map to the other values. But if something changes along the way or if you’re just manually entering data into the form right now, you can essentially define where those values on the form get indexed on the document itself.

Looks like we have a question coming in, just one second. With the eForms or any of the configurations available on the Hyland website? Yes, there is an advanced setup guide. It’s at doc.hyland.com, when you go to doc.hyland.com there is actually an AP if you’re looking through the…if you browse through the products and things like that, there’s one that’s actually the AP invoice eForm. I’ll just go ahead and navigate to that real quick. So docs.hyland.com, got your product list here, and you’ve got your AP invoice eForm. And then depending on the version of eForm that you have, if you don’t know what version of the form you have, you can go to any of these files in the SEAP directory. At the very top, you should see AP invoice eForms. And then the version itself. Subsequently, if you don’t have access to the server if you’re a user that doesn’t have access to the server, it should also be at the very, very bottom of the form. So if you’re looking at a document at the form, it’s down here. Kind of defined as the version. So, with this version, we got 12.7.

We click on this. There’s online help, there’s installation guides, the technical guides are where I typically go, I still use this all the time to kind of figure out how to navigate and kind of configure certain things. There’s an advanced design and setup guide, that walks you through all of this. As you can tell it’s a pretty big document that has a lot of things that you can do when it comes to configuring. Sometimes you have to get creative, we have to get creative sometimes on some of our client requests. But it should give you an idea of how these are configured in way more in depth than the time I’m spending with you guys here today. So, I highly advise going and checking this out, or at least having it handy if you need to reference it for anything. Thanks for the question. All right, moving on. Okay, we’re talking about indexing.

So as part of the workflow process for AP eForms, you can essentially define where company value is going to go, is that going to go into a custom property which this one does or does it go into field one or field two on the document itself? Which are defined down here. So we want company to go to the folder level, which is a good one. Vendor ID needs to go to tab. Some of these things are still kind of defined with the old vernacular but you should be able to kind of figure that out. And that will essentially for the AP invoice eForm if anything does change, if the user modifies the eForm, and you send it back through the validate server script, which we always advise. If it’s ever stopped, for any reason as part of an exception process, always send it back to validate server queue to basically either re-index or to definitely double check the work essentially, that you did.

So, from here, you can essentially define the PL details required. So, this is where it’s getting a little bit more in depth about the purchase order processing. What we’re essentially checking for here that we have all the required fields and seeing what GL code validation or account validation. Difference being you’ve probably heard that in the past, so I guess it’s worth mentioning GL code validation versus GL account validation. GL code is where you can basically enter in the different GL elements, account, sub-account, projects, department, things like that, call centers. As individual kind of lookups that define like, “Okay, code here, here, here and here.” Whereas account validation is more driven as a string. So, there’s more validation around, “Well, if it’s this account unit, it can’t have this account category.” Kind of thing and that kind of defines and shapes the validations around the GL elements that you have, it’s pretty common with Lawson for us to basically have those dependencies.

Going through here we’ve got our distribution validation, all the way to the bottom where there’s this run IP mapping. IP is the Hyland product, essentially intelligent capture or Brainware as it’s now called. It’s gone through a number of different name changes which is fine. But IP is intelligent capture, where you can essentially define where we’re mapping values that are coming in from an OCR technology to the form itself. There is AP exports, so if you were actually doing a flat file exports this is where you would define the fields themselves. So, when it hits the export scripts and the workflow queue is going to basically take all these lines, however you have this defined generate a CSV from that. That you could then modify or push into your system.

Ultimately, we’re not seeing this as much anymore. We like to push directly into a database or through an API with the validations and things like that as opposed to this, but it’s worth mentioning.

The last one we’ll show potentially custom cultures, and this will kind of steer us into the modifications we’re going to make to this eForm today. Custom cultures, really what this is used for is to define the labels on the fields themselves. So, if we look at the invoice eForm here and we’ve got our GL distribution. And we’ve got our names defined at the account unit account description, account description. We’ve officially taken that caption key from the AP scan file, put it in here and then for the caption we’re defining the name that we actually want displayed to the end users, you don’t want to just put whatever and just say, “Hey, that’s just what the product is.” It allows you to kind of shape it to fit your users’ needs, so if they’re familiar with calling it AU or something like that instead of account unit, we could put in AU and kind of label that differently.

Right. Any other general questions before I get started on configuring this form? All right, let’s jump into it. Today, we’re going to be adding two fields to this form. One is basically a static field and the other one is a lookup using the custom connector. So jumping in right now, if I’m an admin for instance I got users that are saying, “Hey, I figured out this OCR technology can extract the site code off the invoices, this would be great for manufacturing companies and things like that, in a site code for these projects. I want to extract that and I want to push it or I just want the user to manually enter it.” This is a header value. So, let’s say we want this somewhere on this form that we can either manually enter it or have some other script or something push it over. So this is all we have now vendor information, invoice information and tax and other miscellaneous charges and then pay immediately and payment comments, sorry.

So, I’m going to go into the AP scan file. So again, this is where all the fields are kind of defined as whether you have them or not have them. I know that this is a header field. So, I’m going to browse down and the one that we typically use are these header one, header two, header three. And they’re basically on the form itself just kind of configured along with specific row, see these fields if you wanted to add additional ones. So, the first thing I’m going to do, is this visible configuration, I’m going to mark this to true. I’m going to save this file and close the document.
You don’t necessarily have to, but you’d have to reopen it. And I’m going to run that AP maintenance script. And right click, when you run it always run as administrator, just a good rule of thumb in general. You’ll see that one file, two files, three files moves. And what’s happening there is essentially… When I mentioned, we’ve got our stash, we’ve got our stored information configurations. It’s basically saying, “Okay, here’s the same file.” They’re difference so we’re going to overwrite those.

When I open this back up, you’ll see here we now have header one. There’s another field on the form that you can then enter data in. Header one means nothing to me or the end user. So, what we’re going to do is go into that AP custom cultures XML file, we’re going to make a copy of one of these lines, one of these message lines here. Ctrl D, if you’re using notepad++ is easy to use. And we need to find the label for header one. So, if I go back into the AP config file, not sorry, AP scan files. I’ve got this caption key value here, this is always kind of the last detail on the line itself, I’m going to copy this, I’m going to paste it into the key value here making sure that you’ve got the quotation marks around it. And then for the caption, I’m going to put in whatever I want for this header value, we can call this site code. I’m going to save this; I’m going to run the AP maintenance.

Now we’re going to navigate back to the form. And here you can see it now it’s a site code, site and choose before. Along with that now that you have this field, like all right you’ve got your fields it’s like well, we need it to be required. You can make it required now, by going back into the scan and basically saying, “Okay. It’s visible.” You can add the required piece here to the actual function to make it a required field, kind of going forward that it can’t be blank, it won’t pass validation unless it has something in it. If you need further validation around that, you may have to use some of the custom validation pieces there. Moving on the next thing I want to have so in this example here, automatically we’ve got payment terms associated with the vendor itself, but what you’ve kind of got some one-offs where you need to choose the payment terms themselves. We’ve already got this kind of configured for the lookup itself.

So, what I’m going to do is enable this field in the form and kind of walk you through how the actual custom connector works. So, you can understand on the back end and the steps that we did to kind of make this work for this form itself. So, I’m going to look for payment terms or just the word payment. Vendor payment terms, it’s the visible setting that’s set to false, so I’m going to change this to true. I’m going to run the AP maintenance script so that we can see this and there should be data in it. That’s very close and open the document back up. Side note, if you were ever testing this and you make a configuration change or you make a change to the custom connector, for instance. And you run AP maintenance and it looks like something happened but you’re still not seeing the results, it generates a log description, it writes the log in the log directory that can kind of show you, here it is, AP maintenance.

Show you that it processed correctly. If it wasn’t able to copy something over, it’s generally because of some kind of detector, missing a semicolon or something like that in the configuration or comma even or parentheses. That would be what is causing it to not render on the form for you to see in the log itself what failed as part of that. To run it, I’m going to open this document back up. And we’ve now got, let me expand the tab, we’ve now got payment terms here where you can see net 30 or just net 30 is set by the form itself or by the vendor itself. Now on the back end, we’ve got our custom connector. And this is where we kind of get into the bulk of what this looks like and what the actual database looks like. And this is where it can get a little complicated, but I just want to explain in general how these work. So, in the custom connector itself and again, this is something that if you make any changes to this file and then during an initial implementation, we make a ton.

You do have to run IP maintenance script to render those changes. So first and foremost, you’ll define essentially the DSN that you’re connected to. So, we’ve basically got our DSN there, that kind of connects to our database. And then we’ve got our configs specific to the lookups themselves. So, these are the lookups. As you can see here, we’re referencing the table, which table or view within the database itself. And again, this would kind of be your ERP database that we’re looking, the object property. Now this is the form field itself. The form knows that it’s tied to the object that’s on the form itself, and then the associated database column from that basically database view or table. And here you’ve got your where clause. So, it’s essentially the framework for building a SQL query in a database or Oracle query even to basically push that information over. We’re finishing up, so if you go down the payment terms, to your payment terms config you can see here we basically pull this where the records themselves are active.

Now this is where it gets a little bit more complicated and just explain this, and then we’ll open it up for Q&A. We’ve got a variable called payment term config. If we look for this further down in the script itself, you can see that we’ve already got these custom connector hooks to get payment terms or to get vendors or to get certain values itself. Here we essentially configure this to run these parameters through to return basically this function that runs SQL, speed SQL query virtual table to call this payment term config. So, whenever this is triggered, this hook here is automatically tied to that drop down on the form itself. Same thing with vendors isn’t automatically tied to essentially that lookup. So, when you configure this here, to run a specific config, it’s going to run that specific query on the back end of the form to essentially pull that information you want. You can see here this is just a list right? Like our where clause is active, static text is why.

If we go into something like vendor, you can see where vendor names like or equals and things like that. When that’s kind of configured and kind of built in house within the form itself. So that is a longer than expected run through of the AP invoice eForm. I hope I didn’t bore too many people, I’d like to open up for questions now if you guys have any questions or scenarios that you’d want to talk through, let me know and if you have a question you’d like to ask directly just use the raise your hand button on the webinar and I can unmute you and let you go, let you out. All right. Well, if you don’t have any questions, I will let you guys go. Thank you so much for joining our Office Hours today. Thank you, I hope you guys learned something about the AP invoice eForm. If you have any questions at all, feel free to reach out to us or you can email me directly, and I can help you with anything you guys need. I hope you enjoyed it, thank you. Bye.