Claims:1. A computer implemented invoicing and payment system (100), said system (100) comprising:
a memory (10) configured to store a predetermined set of rules;
a processor (20) configured to cooperate with the memory to receive the predetermined set of rules and further configured to generate system processing commands;
a non-invoicing module (30) configured to cooperate with a plurality of external services to receive a plurality of ticket files having ticketing data and store said ticketing data corresponding to said ticket files in a database (40);
an invoicing module (50) configured to cooperate with said database (40) to receive said ticketing data and further configured to generate invoices with respect to said plurality of ticket files based on said ticketing data;
a payment module (60) configured to cooperate with said invoicing module (50) to receive said invoices and obtain payment information, said payment module (60) includes:
a client payment module (62) configured to accept payments from a plurality of clients based on said invoices, and
a supplier payment module (64) configured to provide payments to a plurality of suppliers based on said invoices;
a cancellation module (70) configured to cooperate with said database (40) to receive said ticketing data corresponding to said ticket files and further configured to cancel a ticket file from said plurality of ticket files based on a cancellation request received from at least one client; and
an updation module (80) configured to cooperate with said invoicing module (50), said payment module (60) and said cancellation module (70) to receive the generated invoices, the payment information and the cancellation request respectively, and further configured to update the ticketing data corresponding to the ticket files in said database (40).

2. The system as claimed in claim 1, wherein said non-invoicing module (30) includes a selection module configured to provide a plurality of options including search ticket files, view ticket file, select multiple ticket files and discard ticket files.

3. The system as claimed in claim 1, wherein said invoicing module (30) includes an organizer module (34) configured to provide a plurality of options including search invoice, view invoice, edit invoice, print single invoice, print multiple invoice, generate multi language invoice, create group invoice, and navigate to other invoices.

4. The system as claimed in claim 1, wherein said ticketing data is stored in said database (40) manually and/or automatically.

5. The system as claimed in claim 1, wherein said cancellation module (70) includes a refund module (72) configured to refund an accepted payment to a respective client based on said cancellation request.

6. The system as claimed in claim 1, wherein the payment information includes information related to said accepted payments and said provided payments.

7. A computer implemented invoicing and payment method, said method comprising the step of:
• storing a predetermined set of rules;
• receiving the predetermined set of rules and generating system processing commands;
• receiving a plurality of ticket files having ticketing data and storing said ticketing data corresponding to said ticket files in a database (40);
• receiving said ticketing data and generating invoices with respect to said plurality of ticket files based on said ticketing data;
• receiving said invoices and obtaining payment information;
• accepting payments from a plurality of clients based on said invoices;
• providing payments to a plurality of suppliers based on said invoices;
• receiving said ticketing data corresponding to said ticket files and cancelling a ticket file from said plurality of ticket files based on a cancellation request received from at least one client; and
• receiving said invoices, said payment information and said cancellation request and updating the ticketing data corresponding to the ticket files in said database (40).
, Description:FIELD
The present disclosure relates to the field of invoicing and payment system.

BACKGROUND
Conventional invoicing and payment system are generally distributed and not integrated into a single real time platform, which results in increased processing time for processing the invoices and payments. Further, the conventional invoicing and payment systems do not provide efficient tracking of customer and transaction tracking.
Hence, in order to overcome the aforementioned drawbacks associated with the conventional invoicing and payment systems, there is a need for an integrated platform which integrates all the invoicing and payment functionalities into a single system and further provides efficient customer and transaction tracking.
OBJECTS
Some of the objects of the present disclosure, which at least one embodiment herein satisfies, are as follows.
It is an object of the present disclosure to ameliorate one or more problems of the prior art or to at least provide a useful alternative.
An object of the present disclosure is to provide an invoicing and payment system which provides an integrated platform for various functionalities associated with a ticket reservation.
Another object of the present disclosure is to provide an invoicing and payment system which provides efficient customer and transaction tracking.
Other objects and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.
SUMMARY
The present disclosure envisages a computer implemented invoicing and payment system that comprises: a memory which is configured to store a predetermined set of rules, a processor which is configured to cooperate with the memory to receive the predetermined set of rules and further configured to generate system processing commands, a non-invoicing module which is configured to cooperate with a plurality of external services to receive a plurality of ticket files having ticketing data and store the ticketing data corresponding to the ticket files in a database, an invoicing module which is configured to cooperate with the database to receive the ticketing data and further configured to generate invoices with respect to the plurality of ticket files based on the ticketing data, a payment module which is configured to cooperate with the invoicing module to receive the invoices and obtain payment information. The payment module includes a client payment module which is configured to accept payments from a plurality of clients based on the invoices, and a supplier payment module which is configured to provide payments to a plurality of suppliers based on the invoices, a cancellation module which is configured to cooperate with the database to receive the ticketing data corresponding to the ticket files and further configured to cancel a ticket file from the plurality of ticket files based on a cancellation request received from at least one client, and an updation module which is configured to cooperate with the invoicing module, the payment module and the cancellation module to receive the generated invoices, the payment information and the cancellation request respectively. The updation module is further configured to update the ticketing data corresponding to the ticket files in the database.
In an embodiment the non-invoicing module includes a selection module configured to provide a plurality of options including search ticket files, view ticket files, select multiple ticket files and discard the ticket files.
In another embodiment, the invoicing module includes an organizer module which is configured to provide a plurality of options including search invoice, view invoice, edit invoice, print single invoice, print multiple invoice, generate multi language invoice, create group invoice, and navigate to other invoices.
In yet another embodiment, the ticketing data is stored in the database manually and/or automatically.
In one another embodiment, the cancellation module (70) includes a refund module (72) configured to refund an accepted payment to a respective client based on the cancellation request.
In an embodiment, the payment information includes information related to the accepted payments and the provided payments.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING
A computer implemented invoicing and payment system and method thereof will tracking now be described with the help of the non limiting accompanying drawing, in which:
Figure 1 illustrates a schematic block diagram of a system for computer implemented invoicing and payments, in accordance with an embodiment of the present disclosure;
Figure 2 illustrates a flow diagram of a method for a computer implemented invoicing and payment, in accordance with an embodiment of the present disclosure;
Figures 3 illustrate a flow diagram showing steps performed by a non-invoice module of the system of Figure 1, in accordance with an embodiment of the present disclosure;
Figure 4 illustrates a flow diagram showing steps performed by an invoice module of the system of Figure 1, in accordance with an embodiment of the present disclosure;
Figure 5 illustrates a flow diagram showing steps performed by a payment module of the system of Figure 1, in accordance with an embodiment of the present disclosure;
Figure 6 illustrates a flow diagram showing steps performed by a refund module of the system of Figure 1, in accordance with an embodiment of the present disclosure;
Figure 7 illustrates a flow diagram showing steps performed by an Internal Branch Reference (IBR) number / Limited Purchase Order (LPO) number generation module of the system of Figure 1, in accordance with an embodiment of the present disclosure; and
Figure 8 illustrates a flow diagram showing steps performed by a bank reconciliation module of the system of Figure 1, in accordance with an embodiment of the present disclosure.
LIST OF REFERENCE NUMERALS USED IN THE DRAWING AND DESCRIPTION
100: system 10: memory
20: processor 30: non-invoicing module
32: selection module 34: organizer module
40: database 50: invoicing module
60: payment module 62: client payment module
64: supplier payment module 70: cancellation module
72: refund module 80: updation module

DETAILED DESCRIPTION
A computer implemented invoicing and payment system will now be described with reference to the embodiments shown in the accompanying drawing.
Figure 1 illustrates a schematic block diagram of the computer implemented invoicing and payment system (100). The computer implemented invoicing and payment system (100) comprises a memory (10), a processor (20), a non-invoicing module (30), a database (40), an invoicing module (50), a payment module (60), a cancellation module (70) and an updation module (80). In an embodiment, the system (100) is implemented on the server.
The memory (10) is configured to store a predetermined set of rules. The memory (10) may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or a non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
The processor (20) is configured to cooperate with the memory (10) to receive the predetermined set of rules and is further configured to generate system processing commands. The processor (20) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor (20) is configured to fetch and execute the predetermined set of rules stored in the memory (10).
The non-invoicing module (30) is configured to cooperate with the processor (20) to receive the system processing commands. The non-invoicing module (30) cooperates with a plurality of external services to receive a plurality of ticket files having ticketing data and store the ticketing data corresponding to the ticket files in the database (40). The ticketing data incudes a passenger information, route, ticket no, PNR, Airline name, basic fare, taxes, and commission charges.
In an embodiment, the non-invoicing module (30) receives a ticket files from the GDS (Global Delivery System) are BSP (Billing & settlement plan) tickets. The GDS system is classified into a Amadeus Interface Record (AIR) and a Machine Interface Record (MIR). The GDS system includes a pro-printer which issues the ticket files in .AIR and/or .MIR format. In another embodiment, the non-invoicing module (30) receives the ticketing data from the Airline booking portal files (Non-BSP Tickets). The ticketing data with respect to the Non-BSP tickets are feeded to the non-invoicing module (30) manually or in excel format. In one another embodiment, the non-invoicing module (30) includes a selection module (32) which is configured to provide plurality of options to a user including search ticket files, view ticket files, select multiple ticket files and discard ticket files.
Figure 3 illustrates a flow diagram showing steps performed by the non-invoice module (30) of the system (100), in accordance with an embodiment of the present disclosure. The method steps are as follows:
• at block 300, the method step includes issuing a ticket on a reservation platform by the reservation executive;
• at block 302, the method step includes to check if the ticket is issued from a GDS platform;
• if yes, the method proceeds to block 304 which includes checking whether the pro-printer is configured; if no, then the method proceeds to block 322;
• if yes, the method proceeds to block 306 which includes dropping the AIR/MIR tickets into the pro-printer server;
• at block 308, the method step includes reading the ticketing data;
• at block 310, the method step includes storing the ticketing data in the database (40);
• at block 312, the method step includes searching the ticket files;
• at block 314, the method step includes viewing the tickets files;
• at block 316, the method step includes selecting one or more ticket files;
• at block 318, the method step includes discarding the ticket files;
• at block 322, the method step includes entering ticket data manually; and
• at block 324, the method step includes entering ticket data through excel template, subsequent to which the method proceeds to block 310.
The invoicing module (50) is configured to cooperate with the processor (20) to receive the system processing commands. The invoicing module (50) is configured to cooperate with the database (40) to receive the ticketing data and further configured to generate the invoices with respect to the plurality of ticket files based on the ticketing data. In an embodiment, the invoicing module (50) can generate a single consolidated invoice for multiple invoices/tickets. The invoicing module (50) will provide the unique invoice no. which will be updated against all the selected invoices. In another embodiment, the invoice contain the information related to client such as Client name, Markup (language), Service fees, Sub agent commission, supplier commission.
In an embodiment, the invoicing module (30) includes an organizer module (34) which is configured to provide a plurality of options such as search invoice, view invoice, edit invoice, print single invoice, print multiple invoice, generate multi language invoice, create group invoice, and an option of navigating to other invoices.
Figure 4 illustrates a flow diagram showing steps performed by the invoice module (50) of the system (100). The method steps are as follows:
• at block 400, the method step includes selecting one or more tickets from the non-invoice repository 110A;
• at block 402, the method step includes generating one or more invoices;
• at block 404, the method step includes entering invoice level details;
• at block 406, the method step includes checking if the generated invoice is a multicurrency invoice;
• if yes, the method proceeds to block 408 which includes entering the currency ratio and then to block 410;
• if no, the method directly proceeds to block 410 which includes entering passenger details which include Pax name/airline name / Internal Branch Reference (IBR) number / Limited Purchase Order (LPO) number;
• at block 412, the method step includes entering amount details which include base fare and other charges;
• at block 414, the method step includes entering supplier details which include name of the supplier and commission charges;
• at block 416, the method step includes entering the sub-agent account details and the sub-agent charges;
• at block 418, the method step includes entering tax details incurred by the customer and the supplier;
• at block 420, the method step includes checking if multiple services are availed in the invoice;
• if yes, the method step proceeds to block 442; if no, the method proceeds to block 422 which includes saving the invoice into the database;
• at block 426, the method step includes searching the invoice in the database;
• at block 428, the method step includes viewing the invoice;
• at block 430, the method step includes editing the invoice;
• at block 432, the method step includes printing of a single invoice;
• at block 434, the method step includes printing of multiple invoices;
• at block 436, the method step includes generating a multiple language invoice;
• at block 438, the method step includes generating a group invoice;
• at block 440, the method step includes navigating to other invoices;
• at block 442, the method step includes selecting the service when multiple services are availed in the invoice, subsequent to which the method is looped back to block 410.
The payment module (60) is configured to cooperate with the processor (20) to receive system processing commands. Further, the payment module (60) is configured to cooperate with the invoicing module (50) to receive the invoice that contains payment information. The payment information includes information related to the accepted payments (payments to be accepted from the clients) and provided payment (payments to be provided to a plurality of supplies). The payment module (60) includes a client payment module (62) and a supplier payment module (64). The client payment module (62) is configured to accept payments from a plurality of clients based on the invoices. The supplier payment module (64) is configured to provide payment to a plurality of suppliers based on the invoices.
Figure 5 illustrates a flow diagram showing steps performed by the payment module (60) of the system (100). The method steps are as follows:
• at block 500, the method step includes selecting a customer name;
• at block 502, the method step includes checking if the payment is multi-currency;
• if yes, the method proceeds to block 504 which includes entering the currency conversion ratio; if no, then the method proceeds to block 506;
• at block 506, the method step includes selecting the payment type;
• at block 508, the method step includes selecting cash as payment mode;
• at block 510, the method step includes selecting single/multiple invoices against which the payment is to be generated; the method proceeds to block 524;
• at block 512, the method step includes selecting bank as payment mode;
• at block 514, the method step includes entering the cheque number; the method proceeds to block 524;
• at block 516, the method step includes selecting other account as payment mode;
• at block 518, the method step includes selecting the other account; the method proceeds to block 524;
• at block 520, the method step includes selecting voucher as payment mode;
• at block 522, the method step includes selecting the voucher; the method proceeds to block 524;
• at block 524, the method step includes selecting single/multiple invoice(s) against which the payment is to be generated;
• at block 526, the method step includes entering the amount being paid against each invoice;
• at block 528, the method step includes entering remarks pertaining to the payment;
• at block 530, the method step includes entering adjustment amount, if any, subsequent to which the method proceeds to block 532;
• at block 532, the method step includes saving the payment in the database (40);
• at block 534, the method step includes modifying the receipt if cheque is bounced;
• at block 536, the method step includes the mentioning the bank account and bounce charge in modified receipt;
• at block 538, the method step includes searching the existing payment; and
• at block 540 the method step includes printing the existing payment.
The cancellation module (70) is configured to cooperate with the processor (10) to receive the system processing commands. Further, the cancellation module (70) is configured to cooperate with the database (40) to receive the ticketing data corresponding to the ticket files and further configured to cancel a ticket file from the plurality of ticket files based on cancellation request received from the client. The cancellation module (70) includes a refund module (72). The refund module (72) is configured to refund an accepted payment to a client based on the cancellation request.
Figure 6 illustrates a flow diagram showing steps performed by the refund module (72) of the system (100). The refund process can be carried out in two ways, viz. manually and by selecting an existing invoice. The method steps are as follows:
• at block 600, the method step includes checking if the refund is manual;
• if yes, then the method proceeds to block 602 which includes clicking on the manual refund tab; if no, then the method proceeds to block 630;
• at block 604, the method step includes selecting the customer name;
• at block 606, the method step includes entering the refund date;
• at block 608, the method step includes entering the agent code;
• at block 610, the method step includes selecting a service against which the refund is availed;
• at block 612, the method step includes entering the passenger details;
• at block 614, the method step includes entering passenger amount details;
• at block 616, the method step includes entering supplier amount details;
• at block 618, the method step includes entering sub agent details;
• at block 620, the method step includes entering the tax details incurred at the customer side and the supplier side;
• at block 622, the method step includes checking if the refund involves multiple currencies;
• if yes, the method proceeds to block 624 which includes entering the currency conversion ratio; if no, then the method proceeds to block 626;
• at block 626, the method step includes saving the refund in the memory 144;
• as mentioned previously, the refund is not manual, the method proceeds to block 630 which includes selecting the date range on the invoice spool screen;
• at block 632, the method step includes displaying the list of invoiced tickets on the invoice spool screen;
• at block 634, the method step includes selecting the tickets to be refunded and generating a refund;
• at block 636, the method step includes displaying the invoice number along with the ticket details;
• at block 638, the method step includes entering the refund date, subsequent to which the method proceeds to block 622 and operates as explained in the previous steps.
The updation module (80) is configured to cooperate with the invoicing module (50), the payment module (60) and the cancellation module (70) to receive the generated invoices, the payment information and the cancellation request respectively. The updation module (80) further updates the ticketing data corresponding to ticket files in database (40) based on the invoices, the payment information and the cancellation request received from the invoicing module (50), the payment module (60) and the cancellation module (70) respectively. In an embodiment, the updation module (80) updates the database (40) at periodic intervals. In another embodiment, the updation module (80) updates the database (40) in real time.
Figure 2 of the present disclosure envisages a computer implemented invoicing and payment method (200). The method (200) may be described in the general context of computer executable instructions. Generally, computer executable instructions may include routines, programs, objects, components and modules. The method (200) may be implemented in any suitable hardware, software, firmware, or any combination thereof.
At block 202, predetermined set of rules is stored in memory (10).
At block 204, the predetermined set of rules is received by the processor (20). The processor (20) further generates system processing commands.
At block 206, a plurality of ticket files having ticketing data is received from the external services and ticketing data corresponding to the ticket files is stored in a database (40).
At block 208, the ticketing data is received by the invoicing module (50) which further generate invoices with respect to the plurality of ticket files based on the ticketing data.
At block 210, the invoices are received by the payment module to obtain payment information.
At block 212, the payments are accepted by the client payment module (62) from a plurality of clients based on the invoices.
At block 214, payments to a plurality of suppliers are provided on the basis of the invoices using the supplier payment module (64).
At block 216, the ticketing data corresponding to the ticket files is received by the cancellation module (70). The cancellation module (70) further cancels a ticket file from the plurality of ticket files based on a cancellation request received from at least one client.
At block 218, the invoices, the payment information and the cancellation request is received by the updation module (80) from the invoicing module (50), the payment module (60) and the cancellation module (70) respectively. The updation module (80) further updates the ticketing data corresponding to the ticket files in the database (40) based on the invoices, the payment information and the cancellation request received from the updation module (80) from the invoicing module (50), the payment module (60) and the cancellation module (70).
In an embodiment, the system 100 further includes an IBR/LPO generation module. Figure 7 illustrates a flow diagram showing steps performed by the IBR/LPO generation module of the system (100). The IBR/LPO generation module facilitates generation of a reference number for those purchase orders which are received by an email from the clients or the internal branches. The Inter Branch Reference (IBR) and Limited Purchase Order (LPO) help each branch to generate IBR & LPO number. The method steps are as follows:
• at block 700, the method step includes selecting the type of reference number (IBR/LPO number);
• at block 702, the method step includes entering details of reference email;
• at block 704, the method step includes importing the email and generating the IBR/LPO number;
• at block 706, the method step includes saving the generated IBR/LPO number;
• at block 708, the method step includes storing all the IBR/LPO numbers in the database (40);
• at block 710, the method step includes searching the IPR/LPO number;
• at block 712, the method step includes printing the IPR/LPO number; and
• at block 714, the method step includes navigating to other LPO/IBR numbers.
In an embodiment, the system (100) further includes a bank reconciliation module. Figure 8 illustrates a flow diagram showing steps performed by the bank reconciliation module of the system (100). The bank reconciliation module assists a user to select a bank account with which the payment details of a particular transaction are associated. The method steps are as follows:
• at block 800, the method step includes selecting a desired bank account;
• at block 802, the method step includes selecting a date range for which the bank transactions are to be viewed;
• at block 804, the method step includes checking if the display of multi-currency transactions is desired;
• if no, then the method proceeds to block 806 which includes displaying all the transactions in the base currency; if yes, then the method proceeds to block 808;
• at block 808, the method step includes displaying all the multi-currency transactions;
• at block 810, the method step includes verifying the system transactions with bank account statement;
• at block 812, the method step includes clearing transactions after the verification;
• at block 814, the method step includes entering cleared date of the transaction and remarks associated therewith; and
• at block 816, the method step includes displaying cleared/un-cleared balance.

TECHNICAL ADVANCEMENT
The present disclosure described herein above has several technical advantages including, but not limited to, the realization of a computer implemented system for invoicing and payment:
• which provides an integrated platform for various functionalities associated with a ticket reservation; and
• which provides efficient tracking of customer and transaction.
The disclosure has been described with reference to the accompanying embodiments which do not limit the scope and ambit of the disclosure. The description provided is purely by way of example and illustration.
The embodiments herein above and the various features and advantageous details thereof are explained with reference to the non-limiting embodiments in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
The foregoing description of the specific embodiments so fully revealed the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.
Throughout this specification the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.
The use of the expression “at least” or “at least one” suggests the use of one or more elements or ingredients or quantities, as the use may be in the embodiment of the disclosure to achieve one or more of the desired objects or results.
Any discussion of documents, acts, materials, devices, articles or the like that has been included in this specification is solely for the purpose of providing a context for the disclosure. It is not to be taken as an admission that any or all of these matters form a part of the prior art base or were common general knowledge in the field relevant to the disclosure as it existed anywhere before the priority date of this application.
The numerical values mentioned for the various physical parameters, dimensions or quantities are only approximations and it is envisaged that the values higher/lower than the numerical values assigned to the parameters, dimensions or quantities fall within the scope of the disclosure, unless there is a statement in the specification, specific to the contrary.
While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.