Electronic form processing enables organisations to easily collect information through online forms and process the requests in accordance with defined business procedures. The main objective is to ease and speed the collection of data and automate the processing of the information.
Electronic forms are equivalent of paper forms. Basically forms are required to transact the business. The information collection through paper forms is quite cumbersome, very expensive and a slow process. Often information obtained contains several errors. Many a times users are not able to fill the form properly due to lack of knowledge or filling instructions given on the forms are just not sufficient. Further the data entry operator makes the mistake while keying in data and deciphering the hand writing requires skills, which further accumulates the errors. Converting manual process to automated processes using e-Forms has proven to be an effective way to reduce costs and improve productivity of an organisation. Electronic form processing enables organisations to easily collect information through online forms and process the requests in accordance with defined business procedures. The main objective is to ease and speed up the collection of data and automate the processing of the information.
Collecting data through forms has been a surprising expense for organisations. The solution requires the suitable IT infrastructure and front-end and back-end software applications. Further it needs the extensive support of IT department to implement the entire life cycle of data processing. The cost associated with programming, forms designing and modifications come out to very high and many a times the process of data collection is to be abandoned.
Using Hypertext Markup Language (HTML) to design and deliver forms had become the obvious solution for many organisations, but programming needed to collect the data creates the bottleneck. The next roadblock to widespread use of e-Forms has been in data processing. Even if organisations are able to design, deliver and collect form data, cleaning and verifying the data is often the most tedious process. Forms are often submitted with outdated or inaccurate information. If the e-Form system does not use business rules to verify the data, then bad data will get into databases and line-of-business systems. This creates expensive data-driven errors.
The solution is found in standards-based applications, where organisations design a form, publish as HTML or portable document format (PDF), set-up data collection, and configure business rules, using point and click tools. Since almost every desktop today has a Web browser, HTML is an ideal delivery mechanism and it works the same way in almost every browser. PDF requires Acrobat Reader which has become almost as pervasive as Web browsers. By delivering forms using HTML and PDF standards, the forms are accessible to anyone-anywhere around the world. New e-Form products are now available that use open standards to automate the delivery and processing of forms, and have proven to be an effective way to reduce costs and improve productivity for any size organisation. These products open up a new opportunity for organisations to increase the number of processes they automate because they substantially reduce or eliminate cost related with design, distribution, and collection and processing.
InfoPath is an application part of Microsoft Office for forms design and XML data entry that uses a familiar Office like interface and allows offline data entry, which is not possible with Web-based forms. InfoPath forms can contain custom code to validate data and submit completed forms to back-end applications, such as customer relationship management (CRM) systems or enterprise resource planning (ERP) systems. However, InfoPath forms designers do not have to write code for many tasks, including validating data formats, automatically expanding forms to include new line items, and submitting completed forms to Web services.
InfoPath has been used for forms-based applications inside organisations, particularly for mobile workers who are not online full time and who are familiar with Office. However, adoption has been hampered by the product’s “thick-client” architecture. Every user must have InfoPath installed, even users who only enter data and never design forms. This has made InfoPath more expensive for IT organisations, which must license and deploy the product for every user. It also excludes InfoPath from markets where there is little or no control over the client platform, such as e-Government initiatives that deliver services to citizens using digital forms sent over the Web.
With InfoPath 12, developers will be able to design, code, test, and debug forms within the visual studio development environment. In addition, InfoPath 12 will have a managed object model, a more extensive set of managed application programming interfaces (APIs) for custom code that validates forms input and processes forms. The visual studio designer and improved APIs will make InfoPath more attractive to professional developers accustomed to working in visual studio with the VB.NET and C++ languages. Both inside and outside visual studio, the InfoPath 12 forms designer will include new design options to support the new thin-client architecture. It will enable a designer to create a single form that works both for browser users and for users of the full InfoPath product. These “design-once” forms are ASP.NET Web pages, which the designer deploys to an InfoPath 12 forms server. Once deployed, the Web page automatically detects the type of client and delivers the appropriate type of form (HTML or InfoPath XML) to that client. With InfoPath 12, organisations will also be able to create libraries of forms controls and forms sections that include code to exchange data with specific back-end applications.
InfoPath e-mail forms can help streamline the processes that you use to collaborate and share data. That is because you can open, fill out, and submit InfoPath forms from within Office Outlook 2007, without having to open InfoPath. If you receive an InfoPath e-mail form, you can reply to it, forward it, and store it just as you would with any other items in Office Outlook 2007. The full integration of Office Outlook 2007 with Office InfoPath 2007 makes it possible to embed an InfoPath form within an e-mail message, and to send it to people along with a request that they fill in the needed information. Recipient are just needed to reply the message and complet the embedded form. After you have collected the respondent’s answers, you can export the data to MS Office Excel 2007 for analysis, or merge the answers from the form that you distributed into one master form.
Browser enabled forms can eliminate the need of form designing software on the client system. The email forms can streamline your day to day work and can certainly increase the office productivity. InfoPath forms have been integrated with Microsoft outlook 2007 email environment. That means forms can now be viewed, edited, saved, and forwarded similar to email messages, meetings, or tasks. This tighter integration makes it really easy to work with forms and to leverage all the structured information they provide without having to leave your familiar Outlook environment. Let us assume that I need to collect the travel details about employees of my organisation. The form template can be designed with InfoPath very easily or alternatively built in “travel request” template can be used for the purpose. Once the template is completed, it is needed to be deployed using the publishing wizard and selecting the option “to a list of e-mail recipients”. It then needs to specify the recipients, add an optional comment, and send out the form.
The employees of the organisation receive the forms and can fill out the form by clicking ‘reply’ button. The form opens in Infopath and after filling the completed form, can be sent back to the originator. The employees will have the choice to send an editable extensible markup language (XML) form or just a read only view. A comment related to the form can be added in the ‘introduction’ field which travels as metadata along with the form.
Now it is turn of data collection. The large number of forms received from various employees requires the processing. For collecting the data a new InfoPath form folder can be created. Now create a rule that automatically routes incoming ‘travel request’ forms to this folder. Then pick-up the specific forms type out of the list of all the templates that have been cached on my local machine. For each incoming message, the rule will check if it is an e-mail form of type ‘travel request’ and will route all the matching e-mails to the ‘travel’ folder.
When each form is saved into the ‘travel’ folder, the data stored in form folders can be aggregated and exported to excel for further processing and analysis. It is a collection of structured forms that can be very easily processed and extracted the data to report on. By selecting all the forms in the folder and then selecting the ‘export to excel’ option from the toolbar. This option automatically generates a spreadsheet with all the data mapped from the forms into excel.
Now we know that e-mail forms can be used to gather ‘travel request” information from various employees of the organisation. e-mail forms could also be used for many similar scenarios within the organisation and outside the organisation. Similarly various government department can make all the forms available to their customers either as email based forms or distribute through server as browser enabled forms which can really simplify the life of customers, enhance the efficiency and productivity of the department and reduce the cost of data collection. The only requirement is that the data needs to be structured.
The developers will be able to create forms that users can fill out either in a browser or with the full InfoPath client. The code for distributing InfoPath forms and processing will reside on a new InfoPath forms server, based on Microsoft’s windows sharepoint services portal and document management platform. Browser data entry will minimise the amount of software installed on each PC and will serve scenarios such as e-Government, where not all users have the full InfoPath client installed. However, the browser version of an InfoPath form will not have all the data entry features of a form displayed in the full InfoPath client. Forms designers will be able to use the InfoPath client application and its scripting development environment as they do today. However, they will also be able to design and debug forms in the visual studio environment by running a plug-in designer based on the InfoPath client. visual studio will probably become the environment of choice for professional developers creating forms that require complex processing on the server.