How to Get Started Replacing AFP Forms

On-Demand Webinar

How to Get Started Replacing AFP Forms

IBM i, Windows
June 14, 2018



IBM is discontinuing support for AFP utilities, starting with IBM i 7.3.

What does this mean? You probably need to find a replacement. AFP utilities have long been used to create electronic forms on IBM i. However, creating a form involves too many manual steps and takes up far too much of your time. So now is the time to find a more efficient electronic forms solution.

How do you do it? Start here. Watch this on-demand webinar to learn:

  • Which features of AFP utilities you need to replace
  • What to look for in an electronic forms solution
  • When you need to have your replacement
  • How to implement new forms incrementally

Plus, you'll see a demonstration of how an electronic forms solution from HelpSystems can fully replace AFP and make your organization more efficient.

Richard Schoen:                All right, well, hello everyone, and welcome to today's webinar. I'm Richard Schoen coming to you from our world headquarters in Eden Prairie, Minnesota. I'll be the moderator today for our webinar titled: "How to Get Started Replacing AFP Forms". If you're using an older form technology such as IBM Advanced Function Printing or AFP, or another older, outdated PC or other PostScript based, spooled file only form technology to generate business output, you're probably asking yourself if now is the time to start modernizing your form generation processes. With all the forms you currently have in production, you can't just throw away your existing technology.

                                                However, you need to start moving down a path to modern-day document production without ripping and replacing your old form software all at once. This webinar will provide an introduction to some common reasons why companies may want to eliminate AFP, and other old form processes and why now might be the time to update your form software and consolidate your products under a single vendor, such as HelpSystems.

                                                As mentioned, I'm Richard Schoen, Director of Document Management here at HelpSystems. I'm part of the technical solutions group, bringing topics like this to our customers and prospective customers. I now have over 30 years of background, just like the IBMI, on IBMI and Windows, and Linux. Managing and delivering forms and documents, as well as integrating IBMI and PC systems, report and application data. I'm also part of our automation team helping customers automate their daily work process as well.

                                                Before we get things rolling, a little introduction to HelpSystems and what we do: HelpSystems has been around for over 35 years, providing solutions for everyday automation needs. Our solutions help customers automate their daily operations, including system management, network and infrastructure monitoring, business and desktop process automation, and report and document management. We also help customers secure their networks and business systems from cyber attacks, and help companies maintain compliance. And we keep users and management informed all day long through the use of our business reporting, data warehousing, and executive dashboarding software products as well. And our products can be deployed across multiple platforms, including IBMI, Windows, Linux, and AIX.

                                                On the document management front, our Web Docs solution covers three core areas of a business trying to go paperless: Document management, process management, and forms management. On the document management front, we focus around capturing and managing scanned documents, scanned paper documents, electronic reports from IBMI and other systems, manufacturing drawings, emails and balance faxes, and other electronic documents such as photos, videos, and more. We can manage pretty much just about any type of document that can be created in a PC format today.

                                                On the process management front, Web Docs contains a built-in document routing system to provide the ability to electronically route documents to the right people for review and approval, as well as electronic signature capture. Signatures can be captured via desktop software, or web-based forms that can be sent out internally or via the internet.

                                                And then forms management, which is essentially our topic today; which covers for us two different, but very important areas. There's input forms, which is the idea of taking a paper-based form and turning it into an online form where data can be captured directly into a business system, so it's a great way to capture form-based data right away without re-keying, and then output forms generating high-quality business output documents such as invoices, purchase order statements, build up [inaudible 00:03:22], and more to reduce paper usage.

                                                All right, so our journey today starts with a short discussion on the state of advanced function printing in IBMI, and some of the potential associated issues. We'll also talk about some reasons you might want to consider modernizing your form output generation processes, and then next, we'll provide some ideas on how to get started replacing your AFP forms in a planned and organized fashion, and we'll introduce you to our I-Forms business form output generation software as well. Then we'll provide a short technology demo of the I-Forms form design process, and we'll end with a few minutes of Q&A and a couple of polling questions. So feel free to enter your questions in the chat window as we go, and I'll address them toward the end of the webinar.

                                                We'll also plan to complete our session in about 30 minutes, so you'll have plenty of time to make your next important meeting, and today's event is being recorded, so you'll receive a link after the webinar to share with anyone in the organization who couldn't attend today's session. All right, so before we continue, I'm going to put up our poll with a couple of forms-related questions. If you don't mind answering those questions, we'll review the results with the group towards the end of the webinar, so you can see what your peers plans are in terms of using electronic forms.

                                                All right, so the nice thing about advanced function printing is that at some point in the past, your company has probably embraced moving from pre-printed forms to nicer looking output. I still see a lot of customers coming to us where they're using pre-printed forms and no form software, so that's a good start, but the recent moves by IBM in regard to printing and AFP print management over the past several years and the need to improve form processes and iterate changes faster; make it time to consider updating your form generation technology. Creating AFP forms is painful. I should know, since I worked with AFP quite a bit over my 30-year career working with IBMI.

                                                Using AFP to design forms also takes special programming knowledge for creating formal relays, page segments, and other elements needed to generate a new form, not to mention that each form usually requires its own custom RPG program to generate an AFP output document for print or electronic distribution. AFP and IPDS also typically requires special printers or converter boxes to render the forms correctly onto these modern printers and multi-function print servers.

                                                Let's take a closer look at the problematic AFP form design process. If you've used AFP or another green-screen based design tool, you know the form design process can be very painful. AFP page overlays must typically be created using an MS-Word document, a Microsoft Paint, or some other document authoring tool. The document is printed and exported to an AFP printer drive that can be output as a binary file containing the overlay object. After that, the AFP object is manually converted to an overlay on IBMI by uploading the file and running through several manual steps, including the "Create Overlay" command. Then finally, the overlay is printed using a custom RPG program on IBMI. Then the printer prints it out, and it's looked at and reviewed, and then this several step process continues over and over until the form is completed.

                                                There's at least five to six steps involved when creating or updating an AFP overlay document. There's also several problems with this process as well. Form design changes can't be quickly iterated and reviewed because of all the steps involved. Custom RPG is required; we talked about that. You have to output to spooled files, although in today's world, AFP output can be converted directly to PDF and TIFF and other formats. Forms with AFP or PCL-based overlays don't always render correctly to both printers and PDF documents, so sometimes, you have to make changes there. Then often, customers are using special AFP or IPDF printers, as we already also mentioned.

                                                So if you know this pain, it might be time to replace your outdated electronic form technologies. As you'll see in our I-Forms demo today, the form design and runtime process can be greatly simplified. This is a problem as well: AFP knowledge depletion is another issue. As many of the older generation of RPG developers move onto other roles or towards retirement, the newer generation doesn't want to work with AFP. They want graphical tools that are modern. Having to teach a form designer who comes from the visual development generation, the golden rule of manual AFP programming is not an exercise that will bear long-term fruit or gains in productivity. After their first or second AFP form, they'll typically be ready to move onto something else that builds their resume skills, and I'm guessing that AFP and custom RPG form programming isn't at the top of the list, even though modern-day RPG is much nicer to work with, even using the new free form.

                                                Modern developers also expect to be able to track their changes easily in a source code management system such as Git. When working with AFP forms, design resources are often split between IBMI and PC-based documents, and source code that are used to create the form overlays. Then there's the future lack of support for AFP. The good thing is that core AFP support still exists in the operating system, and hopefully won't be eliminated any time soon that I can see. This means that things like overlays and page segments and the like will still work if you need to use the older AFP print processes. However, the hand writings on the wall is saying that it's probably time to think about modernizing.

                                                In 2007, IBM sold the majority stake of the printing division to RICOH, and then the InfoPrint Designer AFP form design isn't supported on modern desktop OS, and is not being enhanced. In fact, RICOH is recommending that InfoPrint users move to another form design tool moving forward, such as I-Forms. Then finally, IBM appears to have dropped support for the AFP utilities in V7R3 and beyond, which tells you that if IBM isn't putting resources into AFP forms going forward, you should probably be rethinking your future form processes as well.

                                                Fortunately, we have a solution that can help work with your existing AFP processes as you start your modernization efforts and will also help you move forward. I-Forms is our option for form process modernization and document creation. Let's talk a little bit about our I-Forms software and some of the things to look for in an IBM, AFP modernization strategy. Today's form designers want the ability to be able to design and test on the fly before moving forms into production. With I-Forms you can design, test, review, and deploy a new form from one interface. This allows designers to eliminate all the manual steps it previously took with AFP to develop and implement forms. With I-Forms, designers also render always to PDF first, which means that you never have issues with output format shifting, because we render to a final format PDF all the time, and then we distribute that or archive it, or if we need to render it, we print the original PDF, which means it maintains its print fidelity and alignment or colors, or black and white, depending on the type of printer that you're using.

                                                If you still need to generate spooled files or want to use existing spooled files as document input for new forms, by all means, we won't stop you. A lot of our customers start that way, but if you want to build data-driven documents that include information from any database, including DB2, SQL Server, Oracle, MySQL and more, that's also a good option. In this scenario, you can eliminate the need to create any RPG programming at all by using SQL queries, or XML, or even CSV data file inputs to drive form generation and mail merge documents and labels, or you might want to create a form that includes input from both a spooled file and additional information from a database that isn't in the spooled file. I call that a "hybrid-form". I-Forms is also multi-platform, so you can not only service your IBM users, but you can generate forms and other reports and documents from any application on Windows, Linux, and AIX as well. Regardless of whether you're on IBM or any other platform, we can support you.

                                                Determining how to manage form versions and changes is one of the common questions we get asked. Saving a new form version is as simple as saving a PC file from the designer to a network or an IFS folder, and then those form templates are stored as XML files, and any native graphic files are also stored in their native format. You can use bitmap, JPEG, GIF, and PNG files for logos or image resources in your forms and documents. I've talked to customers where they want to pull signature documents, and they're capturing stuff for mobile applications. They want to be able to just use those GIF or PNG files inside of their forms, and they can do that on the fly. Managing forms when using a source control system such as Git, Subversion, TFS, or any of the IBMI change management systems that support PC objects is as simple as saving your I-Forms template, and any graphic files into the change management software as a new version. You have lots of IBMI and PC change management options, and we support all of them as long as they support PC objects. Git also now runs natively on IBMI, which makes it easier than ever to get started version controlling your templates, even if you're not ready to do a full-blown Git rollout. You can run it natively on I.

                                                All right, when we talk about implementing our I-Forms in an existing AFP shop, this often elicits concern about trying to do a rip and replace of all the existing forms, especially if you have hundreds of forms. Fortunately, I-Forms can be incrementally implemented beside your existing AFP documents, so you don't need to do a big bang rollout and replacement of existing forms. Many businesses have hundreds or thousands of those templates living in also individual RPG programs written for those AFP processes; so being able to migrate slowly and side-by-side is key to implementing a modern form technology like I-Forms in an existing AFP shop that has lots of templates.

                                                Let's talk about a few of the form types you can generate with I-Forms. All businesses have the need to generate standard daily forms and documents for output. With softwares such as I-Forms, form designs can be quickly created and contain graphical elements such as static text, dynamic database fields, barcodes, images, and graphs. If printing is required, documents can also be generated in black and white or full color formats to take advantage of today's available color printers. You can also go paperless with your form generation, archive, and distribution processes as well.

                                                If you start with a spooled file document, chances are the data format is already in a fixed, 80, 132, or 198 column layout with 66 or so lines per page. For this fixed data scenario, you might just generate a new single page template or repurpose an existing AFP or other form overlay graphic to simply create a page overlay, and then appropriate or add the appropriate data fields from the spooled data file over the top. It's pretty easy to be able to create a new document when using an existing spooled file, or using a graphical form overlay to get started, and then you can get more sophisticated in your output as you go along.

                                                When using an existing spooled file, you can also reach out to a database and pull in those additional data fields. We talked about that hybrid format, so those fields may not be in the original spooled file, but the nice way to add those additional fields to a form without changing any data IBMI spooled file data stream. So, you don't have to update an existing RPG or Cobalt program if you want to draw in additional data. Every business case is different, so there's no right way to get started, but you definitely have lots of options.

                                                When you start moving away from using spooled file documents as form data sources using databases, you can build a very dynamic, structured documents such as orders and invoices, and shipping documents. I always like building a document this way, dynamically, much like building a layers of a sandwich. First, you add the page header, then any detail lines, and then as each detail line is output, maybe the form prints a related comment line that needs to be placed under each detail line as the document progresses and gets built. Then once the core document data is output, footers and totals can be automatically created, and then the process continues for each document that needs to be generated dynamically.  Did I mention no RPG programming is needed for a data driven form?

                                                Many businesses have the need to generate large quantities of letters, price books, policy changes, product modification notices, recall letters, and other documents for vendors, employees, and customers? Letters often need to be retained for audit and compliance purposes so that they might get manually filed or scanned. Often, these letters are also generated via manual or semi-automated email mail merge processes, taking lots of time away from more meaningful work. Using a software solution such as I-Forms allows the generation of forms and letters to be integrated into existing application processes, or even green screens or other application screens as well, because you can call out a form merge through an API call. When integrated into an existing application or screen, those letters can be generated, printed, filed, and distributed all in one action, such as a function key press, making the process real-time. Or, a process can be submitted as a background job that runs on a scheduled basis. Again, you have options.

                                                Warehouse mailing and shipping labels are also a hallmark of all businesses who ship product or send correspondence, so being able to generate labels on the fly from existing IBMI or database input or CSV files is a great way to satisfy your organization's need to create labels without needing to be a label process expert. Labels can include dynamic text, images, barcodes, to meet all of your production requirements in various sizes, and the labels can be printed to any laser printer, Zebra label printers, and other formats as needed.

                                                All right, so let's talk for a moment on how to get started replacing your AFP or existing form process, and then we'll do our demo. When you're ready to start considering AFP and other form production processes with I-Forms, the process is easy. You can reach out to your sales rep here at HelpSystems, or me, or my colleague, Greg Schmidt, and schedule a consultation to discuss your requirements and your current form pain points. Then we identify, typically, one or more of your forms that you might want to start with as a proof of concept, and see a live demo of one of your own forms transformed and work with us to determine where to start going forward. Do you want to own the process building forms, or do you need the help from our services team? So there's lots of options.

                                                All right, let's take a quick look at our form design process. One moment, let me bring up my screen here. All right. This is what we call our Text Layer Designer, and typically, you would bring this into play if you were doing a spooled file-driven document. The idea is you can go pick an output queue and then get a list of all the reports from that output queue, and then just pick one that you want to start with. In this case, we're going to pick one of our invoice samples. And you'll notice that it opens it over here in the Text Layer Designer.

                                                Over here, I've got some designs that were already done. This one happens to be ... In some cases, I've seen where customers just want to add a logo and make a really simple form to start with, so what they'll do is they'll draw a box around all the spooled file data and then basically, I'll put that in a fixed pitch format on a form document, and then they just add a logo or maybe some header and footer information to make it look nice. It's really easy to do those type of documents just by drawing a box around the whole thing, but more common is customers want to actually do something like this, where they'll add the field, and then each field, you draw boxes around.

                                                This is a five-line ship-to address. If I click on that one, that's my go-to address. I've got an invoice number, an order number, or even a column like in this case. These are my items, these are my quantities, these are my totals. What's nice is if you think about it, we treat every spooled file page as a database record. As we're going through processing, we just pull that information real-time, and then we process it through our form design tool, which ultimately uses the temporary database information that gets created. But you don't have to worry about any of that, because it happens in the background. In this case, this usually takes to set up for a new form, even less if you have a standard one that covers the whole page. You can use that one over and over in all of our form designs.

                                                All right, so once you get the spooled file map set up, you'll notice these same field names come over here into the designer when we pull them in. Now I can just drag and drop them onto the form like I did here. You'll see "Bill to" and "Ship to" and all my columns. I can re-arrange those columns if I wanted to change the look and feel. You can also do things such as ... In this case, do scripting where ... Like this example, we're taking an invoice number and putting a carriage return line, and then putting invoice data out all in one swipe. You can also do that with large chunks of formatted text, or if you want to call any sort of Java scripting logic, which is the scripting engine we use for conditional text, things like that. If you can turn fields on and turn fields off; there's all kinds of fun things that you can do.

                                                This is an example of a logo. This particular one is hard-coded, but again, I can build a personal expression. We see a lot of customers, where, as they're generating a big spooled file, they might have changes in ... Let's say location or maybe a division or something like that. We can draw in automatically a different logo as we're processing a single spooled file or for each document, however you want to do it, or just have a hard code in one like I do, where it's going out and bringing that file in all the time, because we don't need multiple ones. Then a barcode, this one shows an example of barcode data. This one actually is ... that's coming off our invoice number, and it's doing a Code 39. Essentially, you have all kinds of different formats that are supported. Most of the common things, the 2-D barcodes, QR codes, that sort of stuff. So, lots of different options for that.

                                                Now, once I'm all set, let's say I've built my design and I want to test it. We talked about the old AFP process. In this case, all I have to do is hit the button, and I can render it directly to PDF. As I'm designing, I can build this thing out into a final form PDF document as well at the same time, and look at it and make changes if I need to, and in this case, this one looks good.

                                                A couple of other form types; this would cover mostly your invoice, your ship docs, those sorts of things. Here's an example: A lot of customers want to do Accounts Payable checks and things like that. So just an example of ... This is a check template we provide, and then this is using a MICR toner, so I'll just show you that example so you can see what it would look like. If you want to do Accounts Payable checks or payroll checks, or something like that, I-Forms can fully support you on that as well, because we have the MICR toner involved there. I always tell people, "If you do a new check form, just make sure you take a test run to the bank." I've had a couple of customers where they didn't do that, and then they moved the MICR way too high, so the check readers wouldn't read them. Always take a sampling to the bank when you create a new form, whether it's with I-Forms or however you're doing it.

                                                Letters, mail merge letters, think of the old style Office Vision stuff you used to do, so we can pull in lots of text and data. In this case, this one is actually driven off an SQL query, so this is a data-driven document coming directly off a database. It can be an XML or a CSV file. You can pass parameters into those, so maybe I want to do just one letter, maybe I want to do a whole range, maybe I want to do the whole file like in my example. It's very easy to parametrize all the information coming into your forms and then drive them when you're running our API command, or something like that. But in this case, this is a sample letter one. We'll show you, we'll run this guy. You can see it pulled our data in from our database in real-time, and generated this mail merge for us. Maybe these get archived, or maybe they do get printed and sent out, or you can do them individually if you want to email them. There's lots of ways to organize setting these up.

                                                Then finally, kind of a ... If you don't really think of a forms product as being able to generate reports, but we have a report component in here as well, much like you do a dynamic form, you can actually build business reports in here as well. In this case, you'll see I can actually generate just a customer list document, but it's very nice to be able to generate detailed style reports coming out of a table, or maybe join some information in there, and then build what I call "action reports", which in this case is cool, because I was actually able to build hyperlinks in here, even on orders. We have customers who use our document management system, and they want to view a report and then click a button to go see the associated invoice or order. It's a great way to build actionable links like all these action reports. In this case, we'll click this one and it'll launch our website, but it's very nice you can build reports that are actually actionable, so I don't have to be tabbing back and forth or clicking back and forth. If I need to go find related documentation, I can link it directly to my ERP system. So, some cool things you can do. You can do this in either documents or within form documents as well that you might create.

                                                A quick example of ... If you're over on the green screen, so in this case ... Excuse me. This one is going to use our CL command. This would basically replace, in many cases, the RPG that you're generating, perhaps. If you decide to move away from spooled files or even if you use spooled files, you can call this out behind the scenes through a function key or submit it to a batch. All the parameters in here can be used to pick a particular template, like we do here, we pick our invoice, what format do we want to go into? We support all kinds of different output formats for you, PDF, TIFF, XL. We can output the data files, those sorts of things, and then output location. Am I emailing it? Am I going to store it on the IFF? Do I want to print it out directly via my network printers? Do I want to spool it back to an out-queue like I do with my AFP documents? So, lots of options. Built-in email component, we can send directly through email. All of that functionality is built directly into the system, and then, essentially, there's an email address that we're going out to.

                                                Then if we look at the bottom parameters as well, we talked about being able to pass runtime parameters, right? Any number of runtime parameters can be passed when you're generating the documents. You may or may not use them, but they're there as part of our API to be able to generate documents.

                                                All right, I think that's the gist of our tour here. Let's take a quick look at the Q&A. Let's see if anybody's got any questions today. I'll give you guys a second. I've got a couple that are coming here. This one says: "Can I filter or omit pages from a spooled file or records from a database during generation?" We kind of talked about that with the parameters. Like we talked about, you can use soft-coded parameters to drive filtering within a database query, or when selecting pages from a spooled file, we can actually filter it as well. So that's kind of neat. You can also use our report splitter product to burst documents before processing with I-Forms if you've created a big spool file. An example of that might be an invoice run that you can run an entire data range or a single invoice reprint, or something like that.

                                                This one says, "Can I call the document generation process from a .net, PHP, or RUBY application? You can utilize the I-Forms rest API to call form generation from a platform other than IBMI. We showed the CL command, but the rest API is supported from any platform that can make a URL call. This would include business process automation tools such as our automate software. Maybe you've got a customer or a vendor portal where you want to generate documents on the fly; you can tie into those as well, so that's kind of a nice thing.

                                                If all my data is given in my IBMI spooled file or PCS [Asking 00:25:43] Text report, can I grab information from the database? We kind of talked about that already. That's our hybrid form, so take the spooled file and draw in the additional data through SQL statements, including email addressed or other destination information, and maybe even a company number, right? If we want to swap logos or something like that, and we don't want to make changes to our existing documents.

                                                How would I generate documents from databases other than DB2? In the designer, you can specify any database that's available, as long as it has a database driver available. I-Forms can use it. Simply specify the driver of choice, create an SQL statement to grab the data needed for your form. We support databases, including DB2-400, DB2, SQL Server, MySQL, PostScript, CSV; anything that has a Java-based driver, we can support, so that's nice.

                                                Can I print any PDF document with I-Forms? Oh, we didn't talk about that. Yeah. We have the ability ... We have a document assembly component where you can print generated forms and static PDF documents directly from the IBMI via an output queue or using a Windows Print driver. We have a hybrid scenario where we can render as PCL, PostScript, or even AFP with the appropriate Windows drivers, and then either print directly to the Windows printer, or the data can be re-spooled into an out-queue, like we talked about if we're intermixing with an existing AFP process. It's kind of nice.

                                                Can I print barcodes? Yes, we already answered that. Is I-Forms part of a package, or can we purchase stand-alones? I-Forms is our forms output generation solution, so we have additional modules for automated distribution and archiving and signing of documents. Our sales team, as well as the archive piece ... Our sales team can articulate the various modules for you if you want to talk about something like that a little more.

                                                Will this software also image the PDF file after it's printed? We talked about archiving. We can store PDFs in any file system. It could be SharePoint, you could be using a document management system like Web Docs, where documents get immediately archived, or any other third-party ECM software that you might use for content management, so that's nice. Let's see if there's other ... Oh, this is good, terms and condition. Forms can be created to draw in terms and conditions, and some of that other static info can go on the back of each page, or maybe on the first page, you only want to print terms and conditions, and then they're going to be sent out electronically, or maybe they'll be duplexed. That's another way you can do that.

                                                Can we alternate signatures on checks? You can set up logic, like we talked about with the scripting logic where maybe the check is under a thousand, and it only needs a single signature, or it goes above a thousand, and it needs two signatures. You can set up those scenarios as well, so a lot of different, fun scenarios that you can set up very easily when you're building out your document, so that's pretty cool.

                                                Let's see. Oh, this is ... Here's another one. This is kind of a ... I think of this more for manufacturing and shipping documents and stuff, but this says, "We have the need to assemble document packets and automatically print them to get our teams out of the manual document assembly business. Does I-Form have features for this?" We didn't talk about the assembly component, but we have a built-in document assembly API that can be used to take any IBMI or multi-platform system generated document and turn it into a form, and then include additional documents like we talked about, like static product certifications or specs, or work instructions, or marketing information if you want to include some marketing information; or other static PDF documents that you want to include in the package. If your printing equipment supports collating and stapling, you can also do that job automatically as well, or simply email and archive and assemble the packet. If you're doing paperless shop floor, send it out so your team can work on these online on their workstation. So, lots of different fun things that you can do.

                                                All right. We're in the home stretch here. A quick look at ... Let me pull up our poll here for a second. All right, let's see what everybody's thinking about AFP. Which one of these is true about your organization? We have 31% of you using AFP already. Currently using non-AFP, 4%. Nobody is using Matrix out of this group. I think last time, we had a few people using Matrix. 8% of you have a project starting soon. All right, reasons to replace your old forms? 4%, staff attrition. Let's see, need to modernize our process, 15% it looks like, and then "Other", 19%. We've got a couple of different reasons for doing that.

                                                This is always interesting: How many different form programs does your team use today? One to 20 is about 15% of you. 21 to 50 is 8%, 51 to 100 is 8%, and then the rest are somewhere probably above 100, which is interesting. Do you already use other HelpSystems products? A pretty low number that said yes, so hopefully, we get a chance to earn the forms business from the rest of you that attended today's session. Hopefully, we educated you a little bit and get a chance to talk to you after today's session.

                                                We hope you learned some helpful information to allow your company to start thinking about moving towards modernizing your electronic form generation output and assembly strategy, and reduce your reliance on AFP and other outdated form generation technology. As mentioned earlier, if you have any additional questions on any of our forms document management products, or automation software, feel free to reach out to our sales team, Greg Schmidt or myself, and we'll be happy to schedule a free consultation to address any of your technical questions, or provide a more in-depth demo or use case discussion.

                                                You'll also receive a link to the webinar, so you can share the webinar with those who could not attend today's session. Thanks again for attending today's session. Have a great day, and enjoy the rest of your week.

Ready to Replace AFP Forms?

See how easy it can be. Get your free demo of iForms today.