JP2001256423A - System for preparing and presenting electronic bill - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an incorporated bill preparing and presenting system which prepares and presents an electronic bill proper to a user, and its method. SOLUTION: An electronic bill generator is provided with an open schema database generator constructed so as to receive a bill having a format to be decided and to also prepare a user definition database table having a plurality of fields, a database server constructed so as to receive the database table and is also constructed and to also store the database table, and an bill data processor having a data pump that transmits bill data to a database table field and prepares an electronic bill.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to electronic issuance of bills or presentation of electronic bills.

[0002]

BACKGROUND OF THE INVENTION Electronic billing or "electronic bill presentation" is rapidly evolving, largely due to increased use and reliability on the Internet. Many companies want to embark on the field of electronic billing. However, it is often discouraged by the complexity involved in creating and operating an electronic bill presentation system.

[0003] Billing is not a simple task. This is because the data that is ultimately displayed in electronic format must be queried from the database server, processed, and dynamically formatted. In addition, various pre-presentation processing tasks prior to presentation, including, inter alia, extracting data from the hard copy of the invoice and storing the associated data in a format that can be subsequently queried for presentation. Must be performed.

[0004] Another reason that invoicing is complex is that invoices are customer-specific.
ific). For example, a bill may span from 1 to 10,000 or more records, and each record may span from 1 to 100 items. This requires a sufficiently flexible database structure to accommodate the full range of records and primitive items. As an example, consider a telephone bill. The customer may receive, for example, an incoming call, a conference call, telephone messaging (ph
One may be a subscriber to various telephone services, such as one messaging, Internet related services. For each service, there may be records for usage time, telephone number of the call destination, fee, and other different items.

[0005] However, a limiting feature of the prior art electronic bill presentation system is that the database schema is fixed to predetermined database fields. This "fixed schema" approach limits the bill presentation system to business-specific bill schema templates. In other words, a separate bill presentation system must be individually and uniquely designed, for example, for each telephone company, utility, insurance business, or other billing entity or business entity.

Another problem may be encountered when bills are to be submitted over the Internet. The electronic bill is displayed in a browser, but the bill data is dynamic because it is embedded with logic, not just a pure HTML page. In other words, the interface of the invoice changes dynamically with the data. Consider the above example of a telephone bill. Since each customer makes a different number of calls during a particular billing period, displaying a particular customer's invoice is difficult to see, for example, if the number of calls is greater than the display format allows. Or even become impossible to read.

[0007]

Therefore, HTML pages require display flexibility. Conventional solutions include, for example, script language programmers (script
ting language programmer)
Specialists are needed. This is undesirable from a user's point of view, especially for users who lack programming know-how.

[0008]

SUMMARY OF THE INVENTION An electronic bill generator according to the present invention is configured to receive a bill having a format to be determined and create a user-defined database table having a plurality of fields. An invoice data processor having an open schema database generator, a database server configured to receive and store the database tables, and a data pump for sending invoice data to database table fields to generate electronic invoices With
Thereby, the above object is achieved.

[0009] The bill data processor may further include a data mapper configured to determine the format of the bill and the location of the bill data within the bill.

[0010] The database server may be configured to store a super template containing all possible forms in which the bill can be formatted.

The data mapper determines the position of the bill data and creates a data extraction program to use the super template to extract the bill data from the bill. It may be configured.

[0012] The data pump may be configured to receive the data extraction program, extract the bill data using the received data extraction program, and send the bill data to the database table.

The invoice data processor extracts the invoice data from an XML-formatted invoice.
It may further include an ML mapper.

The electronic bill generator is configured to retrieve bill data from the database table and render the bill data for display via a predetermined bill template including a user-defined subset of the super template. It may further include a generated bill template processor.

[0015] The bill template processor extracts bill data from the database table.
SQL configured to create QL statements
A generator may be included.

The bill template processor enables a user to change the interface of a bill template by entering logic or conditions to affect bill generation and display. May be further included.

The bill may be accessed remotely by a browser and may be displayed electronically.

[0018] The electronic bill generator may be configured to accept bills in any print format and further include a data conversion processor operable to convert the bill format to text.

A method for creating an electronic invoice according to the present invention includes providing an invoice having a plurality of invoice fields containing invoice data, and selecting the plurality of invoices by selecting a tag from a list of tags. Identifying a field of a first portion of the bill field; identifying a field of a second portion of the plurality of invoice fields by defining a new tag; Constructing a database structure in a database using the generated tags, extracting the bill data from the bill field, and sending the bill data to the database structure, Thereby, the above object is achieved.

[0020] The database structure may be constructed as one or more tables.

The method further comprises the steps of using a super template to determine the location of each invoice field in the invoice, and defining a mapping rule for sending the invoice data to the one or more tables. May be included.

[0022] The method may further comprise the step of generating an SQL statement for a bill template retrieved from a database server storing the database structure.

The bill may be accessed remotely by a browser and displayed electronically.

[0024] Prior to providing the bill, the method may include converting non-text bill data in the bill field to a text format.

An electronic billing and presentation system according to the present invention includes a tag generator configured to establish a database structure by associating a set of tags with a set of bill fields, and a bill generator from the bill. Create an HTML formatted bill template and a data mapper configured to extract billing data and define a mapping rule for sending the billing data to the bill field represented by the tag. A bill template generator configured as described above, and an electronic bill presentation engine configured to display the extracted bill data as represented through the bill template. The above object is achieved.

[0026] The system may further include a database server configured to store the database structure and the bill data.

[0027] The invoice template generator may be configured to affect the display by accepting user defined logic or conditions.

[0028] The electronic bill presenting engine is configured to execute the HT
It may include a merger engine configured to merge the ML formatted invoice template with logic or conditions.

In an exemplary embodiment of the invention, an electronic bill generator is provided. The system receives an open schema database generator, a database table configured to receive an invoice in a determined format and configured to create a user-defined database table having a plurality of fields;
And a database server configured to store, and a bill data processor having a data pump that pumps bill data to database table fields to generate electronic bills.

In another exemplary embodiment of the present invention,
The electronic invoice providing an invoice having a plurality of invoice fields including invoice data; selecting a tag from a list of tags to identify a field of a first portion of the plurality of invoice fields; Defining new tags to identify fields in a second portion of the plurality of invoice fields; building a database structure in a database using the selected and defined tags; And sending the billing data to a database structure.

[0031] In yet another embodiment of the present invention, an electronic billing and presentation system includes a tag generator configured to establish a database structure by associating a set of tags with a set of bill fields. A data mapper configured to extract the invoice data from the invoice and send the invoice data to the invoice field represented by the tag, to create an HTML formatted invoice template. And an electronic bill presentation engine configured to display the extracted bill data as represented through the bill template.

A further understanding of the nature and advantages of the invention described herein may be realized by reference to the portions described hereinafter and the accompanying drawings.

[0033]

DETAILED DESCRIPTION OF THE INVENTION In general, the present invention provides an integrated billing and presentation system and method for creating and presenting user-specific electronic bills. Invoices in any print format can be accepted, and non-text invoice files, eg, Advanced Feature Presentation (Advanced)
d Function Presentation:
A data conversion server for converting a bill in the (AFP) format into a text file is provided. The creation and presentation systems and methods of the present invention provide a new "open schema" approach that allows users to create electronic bills that characterize any particular schema. This open schema aspect allows for the creation and presentation of invoices in any format from any business, thus limiting prior art "fixed schemas" to an invoice presentation system to industry-specific invoice schema templates. It is more versatile than the approach.

In the present invention, billing is performed by NetOb
This is done using any suitable HTML editor, such as a jets or Fusion editor, allowing the user to graphically design the bill. Tags, eg, XML (Extensible Markup Language) tags, are inserted into the bill at specific locations to represent bill information, eg, bill numbers, bill dates, account numbers, and the like. The invoice is extracted from the database server via the tag,
Represented via an invoice template. Invoice data is stored in a database server and displayed by logic embedded within the web page along with the tag when the web page is invoked. By utilizing the XML standard, the system and method of the present invention provides
And relational data such as Oracle
Provide users with a high-performance framework for page assembly based on components from multiple data sources. Finally, the present invention provides for template check-in and check-out, tracking versions,
Provides for remote check-out and check-in of invoice templates from the web.

Referring now to FIG. 1, an exemplary embodiment of a system 10 for creating and presenting electronic bills according to the present invention is shown in more detail. Referring to FIG. 1, there are three main processing modules. Database and XML tag creation processing module 100, bill data processing module 1
04, and the invoice template processing module 112
It is. All three of these processing modules may reside on a single database server 103, accessed by a user, typically a biller, via a computer workstation 101.

The database and XML tag creation processing module 100 includes a tag generator 102, preferably using a graphical user interface (GUI), which allows the user to determine which XML tags are required to compose the content of the electronic bill. Can be easily selected. The tag generator 102 simplifies billing schema creation because the user does not need to type SQL statements to create tables. Rather, by using a graphical interface, the user need only define the table and its fields to generate the data structure.

The bill data processing module 104 includes a data mapper 106, an XML mapper 108, and a data pump 110. The data mapper 106 preferably provides a GUI that allows a user to easily define mapping rules that convert any invoice format of any invoice to a format that matches the data structure in the database server 103. It is realized together with. XML mapper 108 is similar to data mapper 106, but differs because it is specifically designed to extract invoice data from XML-formatted invoices. The ability to define mapping rules allows any invoice type to be standardized into a format that can be processed by the system 10. The data pump 110 sends out the bill data to the database server 103 using the rule file created by the data mapper 106.

Invoice template processing module 112
Comprises an SQL generator 114 and a bill generator 116. The SQL generator 114 allows the user, preferably a GU
Useful for generating SQL statements via I. Invoice generator 116 provides the user with tools to change the interface for the invoice template.

The three main processing components 100, 104,
A more detailed description of the elements within each of 112 is provided below. However, a description of the invoice data types and tables, including the data structure of the database, is first provided.

All data in a given invoice is 2
May be classified as one of two types of data, "header" or "details". The header data is data having a one-to-one correspondence with the descriptor. For example, customer name: John Smith Account number: 777121 Reference number: 158796315

In contrast, the detailed data is characterized by several bases. For example, detailed data typically includes a number of rows and columns and is presented in a table format, as shown in Table 1. In Table 1, "Date",
"Item" and "Amount" are detailed data.

[0042]

[Table 1] Next, referring to FIG. 2, the tag generator 102
A flowchart is shown illustrating a database structure and a method of creating tags. To create tables and tags, at step 200, a user first logs in and accesses the system.

After the login is authenticated in step 202,
The user selects the type of table, namely the header table or the detail table. The selected table stores the header or detailed data.

At step 204, the user enters a description of the selected table, and at steps 206 and 208, the user proceeds to select fields for the table. To select a field for a particular table, a range of available field names is provided, for example, via a GUI (step 206). However, the user is provided the option to add a new field name if desired (step 208).

At step 210, the user defines a primary reference key for the table, and then, at step 212, the table is saved. The above process is repeated until all tables have been defined.

After defining all the tables, the user defines the master table in step 214. The master table is one of the header tables. All primary reference keys are concatenated to form an internal reference value. To complete the table creation process in the database, in step 216, a list table of invoices is defined, and step 2 is executed.
At 18 a foreign key or link key is defined. This list table includes fields that list the list of invoices and serves as a link between the customer, account number, and invoice. Each table has an additional field (column) for storing the internal reference value obtained from the master header table, and this field is used to link the header and the detailed table together as a whole. In step 220, a table creation process is performed, and the created table is stored in the server 103. In some embodiments, the user can recall previous settings, modify or delete existing fields, or add new fields. As mentioned above, the user interface to the tag generator 102 is preferably a GUI. FIG. 3 shows an exemplary GUI for the tag generator 102.

Referring now to FIG. 4, the tag generator 10
2 shows a database structure diagram of the database generated by the second embodiment. This database structure can have different schemas 302A, 302B, 302C, etc. Therefore, each schema 302A, 302B, 3
02C and the like indicate the type of bill.

Each schema 302A, 302B, 302C
Are three types of tables (that is, header tables 30 each called an H table).
4, a detail table 306 called a D table, and an invoice list table 310). Tables H and D are generated to be synchronized with the data characteristics of the bill. The names in the tables H and D are preferably HXXX and DXXX, respectively (XXX is a table counter). Therefore, one bill includes a header table in the range of 011 to 999 and 011
It is possible to have a detailed table in the range of ~ 999. Naming tables through the use of table counters simplifies management of the database structure and avoids duplicate tables. The beginning of each field in a particular table is indicated by the name of that table (eg, H001_ACCOUNT or D002_DAT).
E etc.).

When all tables have been generated, the user proceeds to extract bill data using the data mapper 106 (see FIG. 1), determines the data position in the bill using the super template, and Get and then
Generate an executable data extraction program that extracts data from invoices. The super template is a text template provided by the user, and includes all the description formats of data that may be described in one bill. FIG. 5 shows an exemplary super template.
The user can introduce the super template into the system 10 using various transfer modes (eg, leased line, dial-up, FTP, copy, etc.). All invoices that have the same format as the super template are a subset of the super template.

In the exemplary embodiment, the extracted data is stored as a delimited format text file. The same extraction program can be used for invoices that have the same format as a super template or that are a subset of a super template. One of the advantages of the data mapper 106 is that the data in the invoice can be manipulated by the same extraction program, even if any future invoices happen to be in the same format as the super template.

In the mapping process, the user
Set indicators like "page start" and "trigger" to tell the system what you want to do when the indicators appear on the text file. Table 2 lists some exemplary indicators and function names used by the data mapper 106.

[0052]

[Table 2] Referring now to FIG. 6, a flowchart of the operations performed by the data mapper 106 is shown, starting with the mapping process and ending with the generation of an executable data extraction program. In step 500, the super template is loaded. Then, in step 502, the user sets a "page start" indicator to define the starting point of the data to be extracted into the text file. In step 504, the user initiates the mapping of the header data or sets a "trigger" indicator to indicate in the text file a reference point for mapping the header and detail data. The user can map the header data using “page start” or “trigger” as a reference point. However, to start mapping the detailed data, the user needs to set a “start repeat” condition in step 506. Finally, in step 510, the user sets an "end of repeat" condition,
End the detailed data mapping process.

In step 512, a rule file is generated based on the positions of the header data, detailed data, "page start", "trigger", "repeat start", and "repeat end" indicators. Step 514
The source file for a data extraction program (which may be, for example, an AC ++ program source file) or source code written in another suitable programming language is generated using the rules file. Finally, in step 516, the source file is
Compiled to create an executable data extraction program. As described above, the data mapper 106
Is preferably a GUI. FIG. 7 illustrates an exemplary G for the data mapper 106.
Shows the UI.

As mentioned above, the XML mapper 108 and the data mapper 106 are similar, with the main difference being that the XML mapper 108 is designed to extract bill data from XML formatted bills. There is a point. Accordingly, since some companies store invoices in the XML format, an XML mapper 108 is provided so that data can be extracted from the XML format file.

Referring to FIG. 8, the XML mapper 108
Is shown, which begins with a mapping process and ends with the generation of an executable data extraction program operable on a file in XML format. First, in step 600, the user enters a document type definition (D
TD) Select a file. DTD file is XML
5 is a text file showing valid tags and attributes in a document and the context in which the tags and attributes are valid.
In this way, a relationship between the selected DTD file and the database is formed. In step 602,
After listing all elements and attributes, the user selects a database structure file. Then the user:
Choose whether to define one or more field tags (step 606), or
"Repeat field" tag and "End repeat"
A tag is set (steps 608, 610, 612).

As in the case where the data mapper 106 is used, the user sets the indicator when using the XML mapper 108 to inform the extraction program of the task to be performed when the indicator appears in the text file.
The indicators used in the XML mapper 108 are:
It is almost the same as the data mapper 106. For example, “bill” corresponds to “page start” in the data mapper 106. Other indicators include "field", "repeat start", "repeat field", and "repeat end". Table 3 lists the indicators and function names used by the XML mapper 108.

[0057]

[Table 3] At step 614, a rule file is generated based on the XML mapper 108 indicator locations corresponding to the tables and fields in the database and the elements and attributes in the DTD. At step 616, these rules are used to generate a source program, and at step 618, the source program is compiled to generate an executable data extraction program. Since the extraction process depends on the XML tags and the database structure included in the invoice, each different invoice has its own data extraction program.

Referring now to FIG. FIG. 9 is a flowchart of a process for sending data to a database by the data pump 110. The data extraction program is used by the data pump 110 to extract data and send it to a database. Upon execution of the extraction program, the delivery process begins at step 700.

At step 702, a range-limited file in which data is stored according to the table name is generated. The data extraction program also generates a file containing a list of headers and detail tables.

In step 704, the data pump 110 reads the table list file, and then prepares an SQL script in step 706. Finally, at step 708,
The data pump 110 executes the SQL script and imports the range limitation file into each header and detail table.

For the XML mapper 108, the generated data extraction program is similar to the parser. XM
The L mapper 108 reads through the XML file and extracts all data according to the tags encountered. As an example, consider an XML file that includes the following tags and indicators.

<TagA>-> Invoice <TagB>->Field-> Header Field B <TagC>->Repeat-> Detail Table C <TagD>-> Repeat Field-> Detailed Field D <TagE>-> When the extraction program finds <TagA>, it returns <Ta
gA> is determined to be a “bill” type tag. <
TagA> indicates that the invoice is new or a new record. When the extraction program finds <TagB>, it determines that <TagB> is a “field” tag and that the data corresponding to that tag is stored under “header field B” in the database. When the extraction program finds <TagC>, it extracts <TagC
> Is a “repeat start” tag, and all data for <TagC> and <TagD> between the “repeat start” tag <TagC> and the “repeat end” tag <TagE> are detailed table C and detail, respectively. It is determined that it is stored in the field D. This process continues until all documents have been processed.

All of the extracted data is stored in a file having a limited-range format, after which data pump 110 operates in a similar manner to steps 704-708 (FIG. 9) as described above for data mapper 106. And sends the data to the database.

After terminating the bill data processing module 104, the bill template processing module 112 is activated. The first task of the invoice template processing module 112 generates an SQL statement for the invoice template. This allows the data to be successfully retrieved from the database and presented properly via the bill template. Invoice data processing module 104 provides a simple way for a user to change the interface of an invoice template by plugging in logic or conditions, and then generate the invoice template into an invoice. The logic or conditions are in the form of user-defined scripts, executable programs or procedures. Since the interface changes with the data, the plugged-in logic mainly consists of SQL statements for retrieving data from the database. Accordingly, the bill data processing module 104 also includes the SQL generator 114. The first task of the invoice template processing module 112 generates an SQL statement for the invoice template, so that the data is successfully retrieved from the database and presented properly. Please refer to FIG. FIG. 10 shows a SQL generator 1 according to one embodiment of the present invention.
14 is a flowchart showing generation of an SQL statement by the C.14. The SQL generator 114 allows the user to set the SQL
It provides a GUI that requires only a few button clicks to generate statements, thereby facilitating the task of the bill designer. FIG. 11 shows the SQL generator 11
4 shows an example of a GUI for the X.4.

At step 800, the user logs in and
Access the L generator 114. In step 802,
If the system determines that the user has not been authenticated by the login process, the SQL generator 114 program ends. Once authenticated, at step 804, the H table and D
The table is loaded and displayed. Preferably, it is loaded into a drop down combo box on the interface. At step 806, the user selects a table for the SQL statement from the drop down combo box. Once a table is selected, at step 808, the fields in the selected table are displayed in a list box below the combo box. Tables and fields are created through the tagging and mapping process described above.

To avoid ambiguity, a description of the field is preferably displayed below the interface window. Before the next step, the user needs to know the general nature of the required SQL statement. For example,
This is the nature of the "select all" statement. There is no need for the user to create the actual SQL statement. At step 810, the user selects the desired field, and at step 812, the user moves the selected field to the right list box. If all fields have been selected, a "*" or other symbol is preferably displayed to indicate that all fields have been selected. The user can define multiple conditions for the SQL statement by adding “where classes”. This is done at step 814 by clicking on the "Terms" button displayed on the interface. At step 816, the values for any terms the user adds are moved to the text box. If the user makes an error in the middle, the user is given the opportunity to delete the SQL statement and clause.

If you need customized SQL,
At step 818, the user may manually key in the statement by clicking on the "Switch to Customized SQL" button displayed on the interface. Next, at step 820, the selected table is loaded into the left list box. Step 8
At 22, the customized SQL statement is
Moved to text box.

Before instructing the SQL generator 114 to generate an SQL statement, the user must determine which type of table the SQL statement refers to, ie,
Specify whether the table is an H table or a D table. At step 824, the user clicks the "Generate" button on the interface, and at step 826, the system 10 specifies whether to save the SQL statement in the H-table, D-table, or both. Detect whether or not. If the user did not properly specify the table, at step 828, the program requests the user to specify the table type of the SQL statement to reference. Once the user has properly specified the table, an SQL statement is generated at step 830 and stored in the selected table.

Referring now to FIG. FIG. 12 is a flowchart illustrating the bill generation process by the bill generator 116 from a new bill template, an existing bill template from the database server 103, and an unverified bill template from a local directory. At step 900, a user provides login information such as a database name, schema, ID, and password. At step 902, the login information is verified. If the login information is incorrect, an error is detected in step 904 and the program ends. If the login information is correct, the main window of the bill generator 116 is displayed. Preferably, the interface to bill generator 116 is a GUI. FIG. 13 shows an example of a GUI for the bill generator 116.

Next, in step 906, the user opens the bill template file. The user can create a completely new HTML invoice template with XML tags (step 9).
08), an existing template in the database server 103 (step 910) or an unchecked template in a temporary local directory (step 912).

When the user selects a new invoice template, step 908 displays the selected invoice template. If the user selects an existing invoice template from the database server 103, step 910
Displays an existing bill template from the database server 103. In addition to retrieving an existing invoice template at step 910, definition files, rule-undo files, and rule-function files, commonly known as logical files, are also checked out from database server 103. These files generally store information about previous changes. The definition file is a file for storing information from the database, the rule-undo file is a file for storing information required for the undo operation, and the rule-function file is a function created during the previous change. Is a file that stores the information of Finally, if the user selects from the temporary local directory, at step 912, the existing invoice templates in the local directory are displayed,
Then, in step 914, the definition file, rule-undo file, and rule-function file are stored as hidden files in the same local directory.

Thereafter, in step 916, the bill generator 116 creates a system function that retrieves data from the database and enters another application by entering logic or conditions such as "create an SQL function". Assign a value to a variable, perform an operation, and / or add the conditions "if / if not" and "while doing". For variables, the user must declare that the variable is used in the function by adding the relevant variable to the variable list. The addition and removal of variables occurs prior to the creation of the function in step 916.

When entering logic, the logic file is modified. Thus, upon completion of the bill generation process, a new fileset is created at step 918. The new fileset consists of the modified invoice template and logical files. In step 920, the logical file and the invoice template are merged, and step 922
In the script, XML tags can be user-defined,
Converted to an executable program or procedure.

In step 924, if the bill generation is successful, a duplicate bill file name is checked.
This is done to avoid redundant bill file names. Step 9 if there is no duplicate invoice file name
At 26, the bill template and the logical file are entered into the database server 103. If the check-in process fails, at step 914, the invoice, invoice template, and logical file are stored in a local directory.

FIG. 14 is a flowchart showing a method used by a user to preview an invoice generated using a browser. First, in step 1000,
The user accesses the user site by logging in. At step 1010, the user's ID and password are confirmed. If either the ID or password is invalid, at step 1012, an error message is displayed and the process ends. If the ID and password are valid, the user may request at step 1014 to preview the invoice from a selection list of available invoices. After the user selects the invoice to preview, at step 1016, a user-definable script, executable program or procedure at the web server is called and executed. Step 1018
At, a user-definable script, executable program or procedure processes and then formats the processed output of the invoice. Thereafter, the process returns to the web browser for display. If the user is dissatisfied with the bill, the user may check the bill again and the entire bill generation process is repeated.

FIGS. 15-18 are shown to further illustrate what is seen during the bill generation and presentation process. FIG. 15 shows a sample bill in text format. FIG. 16 shows a sample of the bill table structure (bill schema) after the table creation process in the database and XML creation processing module 100. FIG. 17 shows a sample invoice template with XML tags. FIG. 18 shows a sample bill displayed by a browser.

As described above, according to the present invention, an electronic bill creation and presentation system based on an open schema structure is provided. The system includes a database and tag creation module, a bill data processing module, and a bill template processing module. The bill data processing module includes a data mapper, an XML mapper, and a data pump. The bill template processing module includes an SQL generator having a graphical interface and a bill generator.

[0078]

As described above, the present invention provides an integrated billing and presentation system and method for creating and presenting user-specific electronic bills. According to the present invention, there is provided a data conversion server that can accept invoices in any print format and converts invoices in non-text invoice files to text files, and provides an electronic invoice that characterizes any particular schema. Allow users to create.

[Brief description of the drawings]

FIG. 1 is a block diagram of a billing and presentation system according to an exemplary embodiment of the present invention.

FIG. 2 is a diagram of FIG. 1 according to an exemplary embodiment of the present invention.
3 is a flowchart showing a method for creating a database and XML tags by the tag generator of FIG.

FIG. 3 is an example of a GUI of the tag generator shown in FIG. 1;

FIG. 4 is a diagram illustrating a database structure of a database created by the tag generator illustrated in FIG. 1;

FIG. 5 is an example of a super template.

FIG. 6 is a flowchart illustrating a mapping process performed by the data mapper shown in FIG. 1 beginning with the mapping process and ending with generation of a data extraction program.

FIG. 7 is an example of a GUI of the data mapper shown in FIG. 1;

FIG. 8 is a flowchart showing bill data processing by the XML mapper shown in FIG. 1;

FIG. 9 is a flowchart showing a process of sending data to a database server using the data pump shown in FIG. 1;

FIG. 10 is a flowchart illustrating a process for generating an SQL statement.

FIG. 11 is a diagram showing a GUI of the SQL generator shown in FIG. 1;
It is an illustration of.

FIG. 12 is a flowchart showing a bill generation process by the bill generator shown in FIG. 1;

FIG. 13 is a GUI of the bill generator shown in FIG. 1;
It is an illustration of.

FIG. 14 is a flowchart illustrating a method used by a user to preview a bill generated using a browser.

FIG. 15 is an illustration of a sample bill in text format.

FIG. 16 is an example of a table structure (invoice schema) for the invoice sample shown in FIG. 15;

FIG. 17: XML for the invoice sample shown in FIG.
It is a sample of an invoice template with a tag.

FIG. 18 can be displayed in a browser, FIG.
6 is an example of a bill sample shown in FIG.

 ──────────────────────────────────────────────────続 き Continuation of front page (71) Applicant 501046981 NO. 37 Lolong 23 Geylang # 07-02 / 03, Yu Li Industrial Building, 388 371 Singapore (72) Inventor Yo Wen Ting Malaysia Penang, Jalan Go Guan Ho 28 (72) Inventor Lo Cho Cho Min Roll, Malaysia Star 05100, Jalan Tunku Abdul Harim, No. 1015-H Jubilee, Rencock Nipard Pair 27-8-6 (72) Inventor Chong Mei Liang, Malaysia Seragor, Rawang, Kundan 48020, Kampung Kandan No. 34 (72) Inventor Loka Huy Malaysia, Malaysia Down 1160, Jeruto down, Jalan Batu ipecac Nan bar 57 (72) inventor ring tune Chai, Malaysia Johor, Moore 84010, Jalan Temengon Erma de, Paris Baker, Pikeiei 27

Claims (21)

[Claims] 1. An open schema database generator configured to receive a bill having a format to be determined and create a user-defined database table having a plurality of fields; and receive the database table; An electronic invoice generator, comprising: a database server configured to store, an invoice data processor having a data pump that sends invoice data to database table fields to create an electronic invoice. 2. The invoice data processor, further comprising: a data mapper configured to determine the format of the invoice and the location of the invoice data within the invoice. Electronic invoice generator. 3. The electronic bill generator of claim 2, wherein the database server is configured to store a super template that includes all possible forms in which the bill can be formatted. 4. The data mapper uses the super template to determine the location of the bill data and create a data extraction program to extract the bill data from the bill. The electronic bill generator of claim 3, wherein the electronic bill generator is configured to: 5. The data pump is configured to receive the data extraction program and extract the bill data using the received data extraction program and send the bill data to the database table. Electronic bill generator according to claim 1. 6. The electronic invoice generator of claim 1, wherein the invoice data processor further comprises: an XML mapper that extracts invoice data from an XML formatted invoice. 7. An invoice template processor configured to derive invoice data from the database table and display the invoice data via a predetermined invoice template including a user-defined subset of the super template. The electronic bill generator of claim 5, further comprising: 8. The invoice template processor,
An SQL configured to create an SQL statement for extracting bill data from the database table
The electronic bill generator of claim 7, comprising an L generator. 9. The invoice template processor, wherein:
9. The bill generator of claim 8, further comprising a bill generator that allows a user to change the interface of the bill template by entering logic or conditions to affect bill generation and display. Electronic invoice generator. 10. The electronic bill generator according to claim 1, wherein the bill can be accessed remotely and displayed electronically by a browser. 11. The electronic invoice of claim 1, further comprising a data conversion processor configured to accept the invoice in any print format and operable to convert the invoice format to text. Generator. 12. Providing an invoice having a plurality of invoice fields including invoice data; and selecting a tag from a list of tags to reduce a field of a first portion of the plurality of invoice fields. Identifying and identifying a field of a second portion of the plurality of invoice fields by defining a new tag; and using the selected tag and the defined tag in a database. A method of creating an electronic bill, comprising: building a database structure; extracting the bill data from the bill field; and sending the bill data to the database structure. 13. The method of claim 12, wherein the database structure is constructed as one or more tables. 14. The method further comprising: determining a position of each invoice field within the invoice using a super template; and defining a mapping rule for sending the invoice data to the one or more tables. The method of claim 12, wherein 15. The method of claim 12, further comprising generating an SQL statement for an invoice template retrieved from a database server that stores the database structure. 16. The method of claim 12, wherein the bill can be accessed remotely and displayed electronically by a browser. 17. The method of claim 1, further comprising the step of converting non-text invoice data in the invoice field to a text format prior to providing the invoice.
3. The method according to 2. 18. A tag generator configured to establish a database structure by associating a set of tags with a set of bill fields, extracting a bill data from the bill, and A data mapper configured to define mapping rules for sending invoice data to the invoice field represented by the tag; and an invoice template generator configured to create an HTML formatted invoice template And an electronic bill presenting engine configured to display the extracted bill data as represented through the bill template. 19. The system of claim 18, further comprising a database server configured to store the database structure and the bill data. 20. The system of claim 18, wherein the bill template generator is configured to affect the display by accepting user-defined logic or conditions. 21. The system of claim 18, wherein the electronic bill presentation engine includes a merger engine configured to merge the HTML formatted bill template with logic or conditions.