Abstract: Systems, methods, and computer program products for processing exchange requests. An itinerary change request is received to modify at least one attribute of an existing ticket that includes one or more existing ancillary services. A replacement ticket and one or more replacement ancillary services may be identified by identifying a recommendation for a replacement ticket, determining whether the one or more existing ancillary services are available with the replacement ticket, constructing a search filter including category descriptions and a similarity score for the one or more replacement ancillary services, and transmitting the recommendation for the replacement ticket and one or more replacement ancillary services to a user interface.

Abstract: Systems, methods, and computer program products for processing exchange requests. An itinerary change request is received to modify at least one attribute of an existing ticket that includes one or more existing ancillary services. A replacement ticket and one or more replacement ancillary services may be identified by identifying a recommendation for a replacement ticket, determining whether the one or more existing ancillary services are available with the replacement ticket, constructing a search filter including category descriptions and a similarity score for the one or more replacement ancillary services, and transmitting the recommendation for the replacement ticket and one or more replacement ancillary services to a user interface.

Abstract: Systems, methods, and computer program products for creating and managing database records. A database management system receives requests to exchange tickets. In response to determining that a request requires enhanced processing, the system queries a penalty collection database for instructions on providing the enhanced processing. The instructions may be identified based on an identity of a provider of a travel product and/or the market in which the product is sold. The penalty collection database may include a table that provides instructions on collecting the penalty which are indexed to a specific provider, market, or combination of provider and market. If a penalty is owed for the exchange, the instructions may cause the system to implement a specific method of collecting the penalty. The instructions may cause the penalty to be encoded and stored in a manner specific to the provider and/or market to avoid an incompatibility with another system.

Abstract: Methods, systems, and computer program products for auditing transactions involving sales of tickets by one business entity for a travel product provided by another business entity. An application receives data including a fare basis and a fare charged for a ticket. A plurality of priceable units each consistent with an itinerary of the ticket and each including a fare corresponding to the fare basis is determined. Combinations of these priceable units that conform to the itinerary are defined, and a fare for each combination determined. The fare of each combination is compared to the fare charged for the ticket, and a matching fare selected. The rules used to price the selected combination are compared to the ticket and pricing context of the ticket, and errors in pricing the ticket determined based thereon. An agency debit memo may be defined based on errors in pricing the ticket and audit discrepancies.

Abstract: Methods, systems, and computer program products for auditing a transaction involving a sale by one business entity of a ticket for a travel product provided by another business entity. An audit module receives a pricing context of the transaction and determines an audit amount therefrom. The audit amount is compared to a price charged for the transaction to determine if an agency debit memo should be generated. If the pricing context for the transaction is not available and a ticketing office that issued the ticket is flagged for enhanced auditing, the audit module may determine one or more pricing context parameters by determining prices for a plurality of combinations of pricing context parameters. These prices may be compared to the price charged for the transaction, and the combination of pricing context parameters having a matching price may be selected. The pricing context parameters may then be used to generate audit related documents.

Abstract: A system for identifying a parameter in a version of a data entity created at a specific time, wherein at a first time the version is an active version and at a second time the version is a previous version, the system comprising: a database for storing the plurality of versions of the data entity as they are created; a cache for storing the first active version of the data entity; wherein when a new version of the data entity is created by updating at least one parameter of the data entity, a new active version replaces the first active version stored in a cache and the first active version becomes a previous version stored in the cache; and wherein the new active version includes a list of the or each previous version of the data entity with an associated time at which the version was an active version, such that by identifying the version of the data entity which was active at the specific time the parameter is determined.

Abstract: A system for identifying a parameter in a version of a data entity created at a specific time, wherein at a first time the version is an active version and at a second time the version is a previous version, the system comprising: a database for storing the plurality of versions of the data entity as they are created; a cache for storing the first active version of the data entity; wherein when a new version of the data entity is created by updating at least one parameter of the data entity, a new active version replaces the first active version stored in a cache and the first active version becomes a previous version stored in the cache; and wherein the new active version includes a list of the or each previous version of the data entity with an associated time at which the version was an active version, such that by identifying the version of the data entity which was active at the specific time the parameter is determined.