Method, system and apparatus for intermediating database updates

A method in an intermediate server of initiating updates to a secondary database based on activity in a primary database includes: retrieving primary data from a primary server hosting the primary database; retrieving secondary data from a secondary server hosting the secondary database; storing a combined data set including the primary data and the secondary data; responsive to receiving a request from a client device, presenting a portion of the combined data set to the client device; receiving, from the client device, input data associated with the portion of the combined data set and updating the combined data set in the memory; determining whether to synchronize the updated combined data set with at least one of the primary server and the secondary server; and when the determination is affirmative, selecting a subset of the combined data set for transmission to at least one of the primary and secondary servers.

FIELD

The specification relates generally to database synchronization, and specifically to a method, system and apparatus for intermediating database updates.

BACKGROUND

In various environments (e.g. manufacturing, provision of professional services, etc.), multiple streams of data are maintained by distinct systems. Although discrete, such systems may nevertheless be related in that updates to one system are triggers for updates to another system. Typically, such updates are made manually by one or more human operators, an approach that is time-consuming and error-prone. Alternatively, the systems may be reconfigured to enable communication therebetween, which may undesirably increase the operational load placed on one or both of the systems under consideration.

SUMMARY

An aspect of the specification provides a method in an intermediate server of initiating updates to a secondary database based on activity in a primary database includes: retrieving primary data from a primary server hosting the primary database; retrieving secondary data from a secondary server hosting the secondary database; storing a combined data set including the primary data and the secondary data; responsive to receiving a request from a client device, presenting a portion of the combined data set to the client device; receiving, from the client device, input data associated with the portion of the combined data set and updating the combined data set in the memory; determining whether to synchronize the updated combined data set with at least one of the primary server and the secondary server; and when the determination is affirmative, selecting a subset of the combined data set for transmission to at least one of the primary server and the secondary server.

DETAILED DESCRIPTION

FIG. 1depicts a system10including a primary server100hosting a primary database102stored in a non-transitory computer-readable medium such as a memory104thereof (e.g. any suitable combination of volatile and non-volatile memory, implemented as one or more integrated circuits, magnetic disks, or the like). The primary server100includes a central processing unit (also referred to herein as a processor106and implemented as one or more integrated circuits) connected with the memory104. The processor106is configured to execute the computer-readable instructions of an application108stored in the memory104in order to perform various functions discussed herein, including hosting of the primary database102and interacting with other computing devices via a communications interface110connected to a network115(e.g. any suitable combination of wired and/wireless local and wide-area networks, including the Internet). The communications interface110thus includes any suitable hardware components (e.g. network interface controllers, transceivers and the like) to connect the primary server100to the network115.

The system10also includes a secondary server120hosting a secondary database122stored in a non-transitory computer-readable medium such as a memory124thereof (e.g. any suitable combination of volatile and non-volatile memory, implemented as one or more integrated circuits, magnetic disks, or the like). The secondary server120includes a processor126connected with the memory124and configured to execute the computer-readable instructions of an application128stored in the memory124in order to perform various functions discussed herein, including hosting of the secondary database122and interacting with other computing devices (including the primary server100) via a communications interface130connected to the network115.

In the illustrated example, the primary and secondary servers100and120are implemented as distinct servers, the components of which will be discussed in greater detail below. In other examples, however, the servers100and120can be co-located (that is, the primary and secondary databases102and122can be hosted on a single server in other examples).

The primary and secondary databases102and122can contain any of a wide variety of types of data. In general, the primary database102contains data that, under certain conditions (e.g. when certain updates are made to the contents of the primary database102), is required to initiate updates to data in the secondary database122. For example, as will be discussed in greater detail below, the primary database102can contain data defining a plurality of events, such as tasks related to the provision of goods and/or services (e.g. professional services, manufactured goods, or the like). The primary database102may therefore contain records defining the above-mentioned events, including deadlines, personnel assignments, volumes, prices, and the like.

The secondary database122, meanwhile, can contain data defining accounting information associated with the above-mentioned events. In the examples to be discussed below, the secondary database122is an accounting database containing records defining amounts invoiced for the above goods and/or services, amounts paid or prepaid for such goods and/or services, expenses associated with the provision of the goods and/or services, and the like. Other examples of primary and secondary databases, in which updates to the primary database require updates to the secondary database, will also occur to those skilled in the art.

The primary database102, in other words, contains records that may be updated periodically to reflect new tasks and to track the progress of previously created tasks. Some of the above-mentioned updates, such as those indicating the completion of a given task (e.g. the delivery of goods and/or services to a customer), require updates to the secondary database122. For example, the delivery of goods and/or services to a customer, as reflected in the primary database102, typically requires the storage of data in the secondary database122defining revenue and/or a payable balance associated with the delivered goods and/or services. In some examples, partial completion of a task as reflected in the primary database102may also require updating of the secondary database122to define one or more work-in-progress (WIP) amounts associated with the task. The primary and secondary servers100and120, however, are not configured for direct communication in the present example.

Further, the updates to the secondary database122noted above are typically not only initiated by certain updates to the primary database102, but also contain data from the primary database102. For example, upon completion of the delivery of goods and/or services, as indicated in the primary database102, it may be required to store a payable amount in the secondary database122, with a value equal to a price defined in the primary database102. Still further, updates to the secondary database122may also depend on input data received at one or more client devices, an example client device140of which is illustrated inFIG. 1. The client device104can be implemented as any suitable one of a mobile device (e.g. a smartphone, tablet computer, laptop computer or the like), a desktop computer, and the like.

The client device140includes a communications interface142(e.g. one or more transceivers, NICs, or the like) connecting the client device140with the primary and secondary servers100and120via the network115. The client device140also includes a processor144interconnected with a non-transitory computer-readable medium such as a memory146, which stores computer-readable instructions in the form of an application148executable by the processor144. Execution of the application148configures the processor144to communicate with one or more of the primary and secondary servers100and120. In the present example, the application148is a web browser application, the execution of which permits the client device140to interact with the servers100and120to retrieve data from, and make updates to, the databases102and122. That is, the servers100and120are configured (e.g. via the execution of the applications108and128, respectively), to implement web-based interfaces for interaction between the client device140and the databases102and122. In other examples, the client device140can execute distinct applications stored in the memory142for interacting with each of the databases102and122. For example, a distinct client application can be employed to view and update data from the primary database102via interaction with the primary server100.

The client device140is configured to initiate updates to the primary database102, for example via the receipt of input data at an input device150(e.g. a keyboard, touch screen, mouse, or the like) and the transmission of updates to the primary server100via the network115. Such updates can indicate, for example, changes in the progress of a task (e.g. indicating the completion of a task), the creation of new tasks, and the like. The client device140is also configured to retrieve and present, for example via a display152or other suitable output device, data from the primary database102.

The client device140can also be configured to update the secondary database122via direct interaction (over the network115) with the secondary server120. As noted above, however, certain updates to the secondary database122depend on information from both the primary database102and the client device140(i.e. information entered at the input device150, which is not otherwise available at either of the databases102and122), and may also depend on information from the secondary database122itself.

The system10therefore also includes an intermediate server160connected to the network115for communication with the servers100and120, as well as the client device140. The intermediate server160, as will be discussed in greater detail below, is configured to retrieve data from the primary and secondary databases102and122for storage in an intermediate database162. The intermediate server160is further configured to obtain input data associated with updating the secondary database122from the client device140. Based on the data retrieved from the databases102and122, and on the input data received from the client device140, the intermediate server160is configured to effect updates to the secondary database122(and optionally to the primary database102), while mitigating the impact of the above-mentioned activity on the performance of the primary and secondary servers100and120.

The intermediate server includes a non-transitory computer-readable medium such as a memory164(e.g. any suitable combination of volatile and non-volatile memory, implemented as one or more integrated circuits, magnetic disks, or the like). The intermediate server160also includes a processor166connected with the memory164and configured to execute the computer-readable instructions of an application168stored in the memory164in order to perform various functions discussed herein, including hosting of the intermediate database162and interacting with the servers100,120and the client device140via a communications interface170.

Turning now toFIG. 2, the operation of the system10will be described in greater detail. Specifically,FIG. 2illustrates a method200of initiating updates to the secondary database122. The method200will be described in conjunction with its performance within the system10, and particularly by the intermediate server160, via the execution of the application168.

At block205, the intermediate server160is configured to retrieve primary data from the primary server100. The primary data retrieved at block205includes at least a set of primary records including data to be employed in the initiation of updates to the secondary database122. In other words, the intermediate server160is typically configured to retrieve only a portion of the data in the primary database102. The portion retrieved at block205can be defined, for example, by a set of criteria specified in the application168. For example, the application168can include identifiers of fields from the database102to be retrieved, and can also specify criteria for when such fields are to be retrieved. For example, the intermediate server160can be configured to periodically query the primary server100to retrieve records containing the above-mentioned fields that have been updated at the primary server100since the previous performance of block205.

At block210, the intermediate server160is configured to retrieve secondary data from the secondary server120. The secondary data retrieved at block210includes at least a set of secondary records including data to be employed in the initiation of updates to the secondary database122. In other words, the intermediate server160is typically configured to retrieve only a portion of the data in the secondary database122. As noted above in connection with block205, the portion of the database122retrieved at block210can be defined by criteria specified in the application168, such as identifiers of fields from the database122to be retrieved when such fields have been updated at the secondary database122more recently than the previous performance of block210.

At block215, the intermediate server160is configured to store the data retrieved from the primary and secondary servers100and120in a combined dataset in the intermediate database162. The combined dataset includes not only the primary data retrieved at block205and the secondary data retrieved at block210, but also additional data associated with the initiation of updates to the secondary database122but not contained in either database102or122.

Turning toFIG. 3, an example performance of blocks205-215is shown. As will now be apparent, blocks205,210and215need not be performed in exactly the order shown inFIG. 2. For example, blocks205,210and215may be performed in parallel at a configurable interval (e.g. every five minutes, although both longer and shorter intervals are also contemplated), as indicated by the dashed line extending from block215to block205.

FIG. 3illustrates the performance of blocks205-215schematically. In particular, at block205the server160is configured to retrieve a portion200of the primary database102containing data corresponding to criteria204stored at the server160(e.g. specifying which records and/or fields to retrieve, a maximum age of the records, and the like). At block210the server160is configured to retrieve a portion208of the secondary database122containing data corresponding to criteria212stored at the server160(e.g. specifying which records and/or fields to retrieve, a maximum age of the records, and the like). In other words, the portions200and208of the databases102and122omit portions of the databases102and122not directly related to updating the secondary database122based on data in the primary database102, and also omit data that may be directly related, but does not satisfy other criteria (e.g. data that is sufficiently aged that it is presumed to already be present in the database162).

At block215, the server160is configured to store the portions200and208in the intermediate database162, which also includes intermediate data216, which may also be referred to as auxiliary data (i.e. extending beyond the content of the primary data200and the secondary data208). Specific examples of the primary data200, the secondary data208, and the combined data (including the intermediate data216) are shown below for the purpose of illustration.

Table 1 illustrates an example set of primary data200retrieved at block205. In particular, the set of primary data200includes a plurality of records also referred to as charge lines. Each charge line contains data for initiating an update to the secondary database122. In the present example, in which the primary database102tracks the provision of goods and/or services, and the database102contains accounting information corresponding to such provision of goods and/or services, each charge line contains data defining at least a portion of the value of a good and/or service (i.e. the cost of the good and/or service to the customer or client).

In the example above, each charge line includes a project identifier (also referred to as a case identifier, matter identifier or the like), which corresponds to a given good or service, or to a related set of goods or services (e.g. the filing and prosecution of one patent application for a particular customer). Each charge line also includes a client identifier and an event identifier, which may also be referred to as a task identifier or work code (i.e. corresponding to a particular predefined good or service, or portion thereof, such as the payment of a maintenance fee in connection with a patent application). Each charge line also includes an amount, representing the value of the event as stored in the primary database102. Each charge line can include various other data, not shown above for simplicity of illustration. Such other data can include a unique charge line identifier (e.g. a database key) distinguishing the particular charge line from other charge lines. The other data contained in charge lines can also include a description (e.g. a text string) of the task, an identifier of personnel that performed the task, an indication of whether the task is taxable and/or an amount of tax payable in connection with the task. Further examples of the data contained in a charge line include a number of units and a price per unit (either in addition to, or instead of, the total amount for the task shown in Table 1), a date of creation of the charge line, and the like. Still further examples include an indicator of a charge line type, such as an indicator of whether the charge line corresponds to a service fee or a disbursement (i.e. an expense paid to a third party during the provision of the goods and/or services).

Table 2 illustrates an example set of secondary data208retrieved at block210. In the present example, the secondary data208contains a plurality of records defining prepayment amounts previously received from customers for the subsequent provision of goods and/or services. In particular, as shown below, each record in the secondary data208contains a customer (i.e. client) identifier, as well as a prepayment value. Each record can also contain a project identifier, although in some embodiments the project identifier can be omitted (i.e. prepayment values need not be associated with a specific project).

Each record of the secondary data208can also include other values not shown above, including for example a date of receipt of the corresponding prepayment, a record identifier (i.e. a database key uniquely distinguishing the record from other prepayment records) and the like.

Table 3 illustrates an example combined dataset generated at block215, including the primary and secondary data200and208, and intermediate data216.

As seen above, records from the primary and secondary data200and208are combined based on case identifier (i.e. project identifier). Thus, the prepayment amount for the case identifier “P1234CA00” is associated in the database162with the three charge line records shown in Table 1. The table structure shown above is for illustrative purposes only, and it will be apparent to those skilled in the art that a wide variety of storage structures can be employed to store the combined data. For example, the primary and secondary data200and208, as well as the intermediate data216, may remain in separate records that are associated with one another via one or more suitable key values, rather than being stored in combined records as shown above. The generation of combined data at block215, in other words, refers generally to the process of storing associations between the primary, secondary and intermediate data200,208and216.

The intermediate data generated by the server160, as shown in Table 3, includes a discount field associated with each charge line, and a status field associated with each charge line. In the present example, the discount and status fields are stored in the same record of the database162as the charge line data itself, but in other examples the intermediate data may be stored in a separate but associated record. Other examples of intermediate data generated at the intermediate server160rather than received from the primary or secondary servers100and120include a group identifier field (which will be discussed in greater detail below).

Returning toFIG. 2, at block220the intermediate server160is configured to present the combined dataset (or at least a portion thereof) to the client device140, and responsive to presenting the combined dataset, to receive input data from the client device140. The performance of block220need not immediately follow the performance of block215. Indeed, numerous instances of blocks205-215may be performed before block215is invoked. In the present example, block215is initiated by the receipt, at the intermediate server160, of a request for the combined data from a client device140. For example, the client device140can transmit a request for a predefined uniform resource locator (URL) to the intermediate server160via the application148. Prior to transmitting the request, the client device140may be required to authenticate with the server160according to any suitable authentication mechanism (e.g. the provision of a username and password and/or other authentication data).

The client device140can also be configured to include parameters in the above-mentioned request that define the scope of the combined data returned at block220. For example, the request can include parameters limiting the requested data to data corresponding to one or more specific case identifiers, data corresponding to a selected date range (e.g. charge lines created in the primary database102between start and end dates specified by the client device140), data associated with particular personnel, and the like. The request can also specify a status parameter, indicating that the combined data returned must have a selected value in the “status” field shown in Table 3, which will be discussed in greater detail below.

The intermediate server160, responsive to the above request, is configured to retrieve data from the database162matching the parameters of the request, and to transmit the retrieved data to the client device140for presentation, for example on the display152. Turning toFIG. 4, an example graphical interface400generated on the display152is shown. The data returned to the client device140by the intermediate server160can be transmitted as a web page formatted as shown inFIG. 4, for example. Various other mechanisms for transmitting the requested data to the client device140and presenting the data at the client device140may also occur to those skilled in the art.

As shown inFIG. 4, the graphical interface400includes charge line elements404-1,404-2,404-3each corresponding to the charge lines represented in the database162(and based on the primary data retrieved at block205). Thus, each charge line element404indicates an event identifier and an amount. Each charge line element404also includes intermediate data, in the form of a status field. Other data obtained through the performance of blocks205-215can also be included in the graphical interface400, including case and client identifiers408and prepayment information412. As will now be apparent, the prepayment information can include data directly corresponding to the secondary data208(as stored in the database162), as well as data derived from the secondary data208. For example, in addition to the prepayment amount of $2200.00 for the case identifier P1234CA00 retrieved from the secondary database122, the prepayment information element412of the graphical interface400also includes a total of all prepayment amounts corresponding to the client identifier “Acme Co.” in the database162, which therefore includes the amount shown in Table 2 in association with the case identifier P1251CA00.

The graphical interface400also includes a discount element416, to be discussed in greater detail below. The graphical interface400further includes a plurality of selectable elements for editing the combined data generated at block215and presented at the client device140via the performance of block220. Examples of such selectable elements include a delete element420corresponding to each charge line element404, selection of which deletes the corresponding data from the database162. The selectable editing elements also include an “add charge” element424, selection of which updates the interface400with an additional charge line element404(e.g. below the element404-3) for completion. Certain portions of the additional charge line element, such as the “Event ID” field, can be populated by selection from a drop-down menu dynamically populated by the intermediate server160. The drop-down menu can be dynamically populated by querying the primary server100to retrieve a list of active events associated with the relevant case identifier.

The selectable editing elements also include an “apply discount” element428, selection of which generates a prompt for receiving input data defining a discount to apply to one or more charge lines. The selectable editing elements further include an “apply prepayment” element432, selection of which generates a prompt for receiving input data defining at least a portion of the prepayment amounts shown in the element412to one or more charge lines. Prepayments applied to any charge lines can be reflected in a prepayment element434(and deducted from the available prepayment amounts shown in the element412). The selectable editing elements also include a group creation element436, and a group approval element440, each of which applies a predefined value to the “status” field of one or more selected charge elements404(charge elements can be selected via the check boxes444, or via any other suitable selection mechanism). The status updates, as will be discussed below in greater detail, determine when updates to the secondary database122, and optionally to the primary database102, are initiated. The graphical interface400can also include other functionality, dependent on the data stored in the database162. For example, the database162can store a historical record of each charge line, and the graphical interface400can include, in association with each charge line element404, a history element (not shown) that is selectable to display previous versions of a selected charge line.

As will now be apparent, the receipt of input data at block220includes the selection of one or more of the elements of the graphical interface400at the client device140, and the receipt of input data editing the contents of a selected element. The client device140is configured to transmit any edited content in the graphical interface400to the server160for storage in the database162and subsequent processing.

Turning toFIG. 5, for example, the graphical interface400is illustrated following a change to the charge line element404-1(now appearing as an updated charge line element404-1′) received from the client device140. In particular, the amount associated with the charge line element404-1′ has been edited from $150.00 to $180.00. At block225, the server160is configured to determine what type of update is represented by the input data received at block220. In the present example, the updating of the amount associated with the charge line element404-1corresponds to a charge data update (that is, an update to a charge line rather than to the status of the charge line within the database162) rather than a status update. Therefore, at block230the server160is configured to update the combined data in the database162in accordance with the input data. For example, Table 4 illustrates the contents of the database162following the above performance of blocks220-230.

At block235, the server160is configured to determine whether to synchronize the updated data with one or both of the primary and secondary databases102and122. When the determination is negative, the server160returns to block220(and may perform additional instances of blocks205-2015in parallel). The determination at block235is made according to a preconfigured set of criteria defining which updates are synchronized and which updates are maintained solely at the database162rather than being synchronized with the primary and/or secondary databases102and122. In some examples, the criteria specify simply that all updates to data originally retrieved from the primary are synchronized only to the secondary database122, but not to the primary database102. In other examples, updates to certain types of charge lines (e.g. disbursements, but not services fees, or vice versa) can be synchronized. In further examples, block235can be omitted, such that no updates to charge line data are synchronized to the databases102and122following block230.

Responsive to a negative determination at block235, the performance of the method200returns to block220. When the determination at block235is affirmative, the server160performs block240, at which selected data from the combined database162is synchronized to one or both of the primary and secondary databases102and122prior to returning to block220. The performance of block240will be discussed in greater detail below.

Turning toFIG. 6, a further update to the graphical interface400is shown, following receipt of input data at the client device140selecting the charge line elements404-1′ and404-2(now indicated as404-1″ and404-2′) and subsequently selecting the “create group” element436. Selection of the “create group” element436updates the status of any selected charge line element(s)404from “WIP” (i.e. work-in-progress) to “pending” or any other suitable indicator. The status field shown inFIG. 6also includes a group identifier “GR1”. As will now be apparent, the charge line element404for a given case identifier can be combined into more than one group (though no single charge element404can be a member of multiple groups), and the group identifiers thus serve to distinguish the groups. The pending status indicator shown inFIG. 6indicates that the charge lines with the pending status indicator and a common group identifier have been selected for use in initiating an update to the secondary database122, but are not yet in condition for updating the secondary database122. In the present example, updates to the database122are made to reflect invoiced charge lines (i.e. charge lines whose amounts and the like have been finalized for communication to a customer, representing the completed delivery of goods and/or services). Charge lines with the pending status indicator may require, for example, approval before the update to the secondary database122is initiated.

As seen inFIG. 2, the status update shown inFIG. 6leads from block225to block245, at which the above-mentioned group identifier is generated and assigned to the relevant charge line elements404, and stored in the database162. In the present example, following block245, the server160returns to block220, without synchronizing any data with the primary and/or secondary databases102and122. That is, the status data in the database162is updated, but the update is not communicated to the databases102and122. Indeed, the databases102and122need not contain fields to accommodate the “pending” status indicator or the group identifiers shown inFIG. 6.

FIG. 7illustrates the graphical interface400following a further performance of blocks220and225, in which both a discount and a prepayment have been applied to the subset of charge elements404with the group identifier “GR1”. The updates shown inFIG. 7lead to block230, at which the database162is updated. In the present example, the determination at block235is again assumed to be negative, and the performance of the method200thus returns to block220. Following the performance of block230, Table 5 illustrates the updated content of the database162.

As shown above, the discount and prepayment amounts applied to the subset of charge lines with the group identifier “GR1” are reflected in the database162. The “prepayment applied” field indicates a prepayment amount applied to the subset, and may not exceed the total prepayment amount for the corresponding client identifier (i.e. $2350, in the above example). In the present example, the prepayment available (the right-most column) is not updated following the performance of block230. Instead, as discussed below, the prepayment amount available is only updated responsive to a subsequent performance of block210, following an update to the secondary database122.

Turning toFIG. 8, a further performance of blocks220-225is illustrated. InFIG. 8, however, the retrieval criteria applied at block220include a criterion to retrieve only records from the database162with the status of “pending”. Thus, the charge element404-3does not appear in the graphical interface400. The update made at block225in the present example is the selection of the “approve group” element440, which updates the status of the charge elements404having the “pending” status and a common group identifier to “approved”. As will now be apparent, prior to selection of the element440, additional edits can be made to the charge line elements404. Provision of the element440in the graphical interface400can be restricted to certain client devices140or accounts (i.e. sets of authentication data) in some examples, such that the interface shown inFIGS. 6 and 7, for instance, may lack the approval element440.

Following selection of the approval element440, the data corresponding to the charge line elements404-1″ and404-2′ is locked, preventing further edits thereto. The status of the charge line elements404-1″ and404-2′ is then updated to “approved”, indicating that an update containing at least a portion of the data associated with the charge line elements404-1″ and404-2′ can now be initiated to one or both of the primary and secondary databases102and122.

At block250, the server160is configured to further update the status of the approved charge lines to “final”. For example, approved charge lines can be added to a queue that is processed daily (e.g. at a time selected to reduce peak load on the databases102and/or122) to finalize and perform synchronization. The contents of the database162following the performance of block250is shown below in Table 6.

The server160is then configured to perform block240, at which a preconfigured portion of the data associated with finalized charge lines is selected and sent to one or both of the primary server100and the secondary server120. The server160can store, for example with the application168, a set of field identifiers from the database162indicating which data to select, and a corresponding set of field identifiers in the secondary database122indicating the destination of the data selected from the database162. In the present example the fields to be synchronized include the case identifier, client identifier, event identifier, amount, discount amount, and prepayment amount applied, as shown in Table 6 above. The prepayment amount available need not be synchronized. Instead, subsequent activity in the secondary database122itself will update the prepayment amount, and a further performance of block210will therefore update the prepayment amount available to reflect the application of at least a portion of the amount shown above.

The data transmitted to the secondary database122can be formatted in any suitable manner. For example, charge line records, as well as an invoice record can be generated and transmitted to the secondary server120at block240. The charge line records may include the case, client and event identifiers as well as the amounts shown above, while the invoice record can include the discount and prepayment amounts shown above. The invoice record can also include an invoice identifier generated by the intermediate server162. Similar data may also be sent to the primary server102, in some examples. In other examples, at block240the intermediate server162may simply transmit a status update to the primary server100, to update the charge lines (e.g. those shown in Table 1) to indicate that the charge lines have been finalized and invoiced (i.e. synchronized to the secondary database122).

The system10thus provides a mechanism for initiating updates to a secondary database based on data in a primary database but also requiring data from the secondary database itself and from one or more client devices, while minimizing the need for reconfiguration of either the primary or secondary databases for direct communication or for tracking of synchronization status.

Variations to the above systems and methods are contemplated. For example, in some examples additional synchronization stages can be implemented by the intermediate server162. For example, the intermediate server162can be configured, following retrieval of data from the primary database102at block205, to synchronize at least a portion of the data to the secondary database122(e.g. during performance of block210). At the cost of increased load on the database122, such additional synchronization provides the secondary database122with up-to-date data regarding the provision of goods and/or services, while awaiting the changes in status described above. Further updates to the secondary database122, in such examples, can await the performance of block235or240.

Various other updates to the data in the combined database162are also contemplated. For example, charge lines can be reassigned to other case identifiers (e.g. via a drop-down menu dynamically populated via a request from the intermediate server162to the primary server100for a list of active case identifiers). As a further example, discounts can be applied to individual charge lines, in addition to or instead of to groups of charge lines.

In further examples, the intermediate server162can also be configured, at block240, to generate and send (via email or the like, according to contact data retrieved from the primary database102) an invoice document containing the data selected for synchronization to the secondary server120.

Those skilled in the art will appreciate that in some embodiments, the functionality of any one or more of the applications108,128,148and168may be implemented using pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components.