|
|
|
Posting Transactions
The Transaction Posting screen is used to manually apply charges to guest folios and group master accounts. Transaction posting may be accessed from several areas within OPERA: Among them, you can select the Post button from the guest's Billing screen (Cashiering>Billing); you can select Cashiering>Fast Post; you can select the Billing option from the Reservation Options screen (select the Options button from the guest's Reservation screen); you can select the Post Rate Code option from the Billing Options screen. You can also access the Transaction Posting screen from within AR (AR>Account Maintenance) when creating a new invoice or when posting an additional charge to an existing invoice that has not yet been closed. You may also post to a Passerby Credit Bill.
The Pre Stay Charging feature controls whether the property allows charges to be posted to the reservation before check-in. The Post Stay Charging feature controls whether the property allows charges to be posted to folios after checkout. These features are made available by setting the Cashiering>Pre Stay Charges and/or Cashiering>Post Stay Charges application functions to Y. (See Pre- and Post-Stay Charging for details.)
Postings can be made to a guest's invoice even if the reservation status is No Show or Cancelled, provided the Cashiering>Noshow and Cancellation Postings application function is set to Y.
A transaction is any item that will affect the final balance of an account. Transaction codes are used to uniquely identify the kinds of transactions posted to the guest's bill. Not only do transaction codes identify charges on the guest folio, but they are important to hotel accounting and reporting systems. Some transaction codes refer to Revenue for the property — for example Food and Beverage charges, and Room and Tax charges. These are considered debits to the guest's account. Other transaction codes refer to Payments made by the guest — such as credit card payments and cash payments. These are considered credits to the guest's account. In addition, there are also Wrapper transactions, which refer to packages that include several transactions processed as a single unit.
When posting transactions using the Transaction Posting screen, not all types of transaction codes will be available to you. For example, transaction codes related to payments will only be available when you are posting payments to the bill (using the Payment button on the Billing screen).
In addition, certain transaction codes can be designated as "non-manual" when they are configured by the property. Non-manual transaction codes are not available to you for posting using the Transaction Posting screen. For example, certain room and tax transaction codes may be reserved for use exclusively by the Night Audit procedure.
At the property's discretion, certain "adjustment" transaction codes may be set up. (These may be identified by the letters ADJ in the description, or by using some other naming system.) Adjustment transaction codes may be intended for use when applying adjustments to transactions that are designated as being non-manual. For example, 1000 - Room and Tax might be a non-manual transaction code posted by Night Audit, and 1050 - ADJ Room and Tax might be the associated adjustment transaction code. If the guest was overcharged and you must make an adjustment to the 1000 transaction, you cannot simply post a negative amount using the 1000 transaction code because this code is unavailable for manual posting. You would instead select transaction code 1050 and post the adjustment amount to it.
Adjustment transaction codes may also be set up simply to keep track of adjustments made to specific kinds of transactions. For example, there might be a transaction code 2000 - Lobby Bar Food that is used when posting charges to the guest bill, and an associated 2050 - ADJ Lobby Bar Food that is used when it is necessary to adjust a 2000-type posting. Both of these codes might allow manual posting.
Transaction codes are set up individually for the needs of each property. It is up to you to select the correct transaction code when making a posting.
Note: When using the Fast Posting feature (Cashiering>Fast Posting), the Transaction Posting screen differs slightly from the screen described here. See Fast Posting for details.
Total. View-only. A running total of all transactions posted during this session.
Code. The transaction code for the item being posted. You may select the down arrow and choose the code from the LOV, or, if you know the code, you may enter it manually. You may also enter the first 1, 2, or 3 digits of the code and press [Tab] or [Enter] or [F9]; OPERA will display a list of all transaction codes starting with the number or numbers you entered. If you enter an invalid code number, the LOV appears allowing you to select the valid transaction code.
Enter a letter or letters and press [Tab] or [Enter] or [F9] to display a list of transaction codes whose descriptions begin with the letter(s) you enter. If only one transaction code description begins with the letter or letters you enter, that transaction code will automatically populate the Code field. If no transaction code descriptions begin with the letter or letters you enter, the Transaction Code LOV appears allowing you to choose.
Once you have selected the Post button to post the transaction, the line below the last posting displays the same transaction code. Defaulting to the last-used transaction code speeds posting multiple charges to the same transaction code. You can, of course, change the default transaction code when posting the next charge.
Transaction codes that have generate charges attached will automatically post the appropriate taxes when you return to the Billing screen.
Note: When you post a transaction code that is designated as a Paidout (that is, when the Paidout check box is selected on the Transaction Code screen; see Transaction Code Setup), the Cashiering>Print Receipt application setting determines whether you will be prompted to print a receipt, whether a receipt is automatically printed, or whether no receipt is printed.
Effective Date. Available when the OPV_<version number> OPERA Vacation Ownership license is active and the Ownership>Effective Date application parameter is set to Y, the Effective Date column allows for transactions to be posted to an invoice for a period that has ended by using an effective date. For example, if transactions in May have been “rolled up” into one invoice on the last day of the month, the user is then able to post into that invoice during the next period (i.e. June) and post a transaction and have it recorded in the May invoice.
When posting with an Effective Date, the user will only be able to post for any date that is less than the business date. If the business date, or any future date is selected, the user will be prompted with a message that states, "Date must be less than business date".
Note: Using the Effective Date to post transactions may have an effect when viewing/printing the Owner Statements and Owner Checks.
Description. Description of the transaction code. This is filled in automatically once the transaction code has been defined. You may not change this description, but you may add supplementary information in the Supplement or Reference column within this form if an explanation is needed. OPERA may print this supplementary and reference text on the folio (based on the folio style selected and how your property has customized their folios).
Amount. Amount of the item posted. The system defaults to 0.00, unless a default price has been specified for this transaction code (see Transaction Code Setup). The Total field will display a calculated total price (Price x Quantity) if you post the transaction with a Quantity greater than 1.
Negative amounts may be posted to reverse a charge. When posting a negative amount, enter a minus sign before the amount or before the quantity. Negative amounts require an entry in the Supplemental field. When a negative amount is entered, the posting will have the opposite effect of how the transaction code was defined.
Note: Rates and other amounts expressed in the currencies of certain countries can involve strings of up to 16 digits. Due to space limitations, these strings can't be easily accommodated by OPERA screens and reports. When the Currency Divisor feature is activated, the property can set a divisor of either one thousand (1000) or one million (1,000,000) through General>Currency Divisor Value application setting. When the currency divisor is active, an (M) for million or (K) for thousand, depending on the parameter setting chosen, follows the currency code. For example, assume the rate amount is 155000000. If the currency divisor is set to one million, the Rate Query screen would show 15.5. The (M) indicator would appear following the currency code.
Currency. If the FOREIGN PAIDOUTS application parameter is set to Y, your property allows paid-outs to be made in foreign currencies. If this is the case, the Currency column is displayed following the Price column. The Currency LOV is active only when the Paid-Out transaction code is selected.
Qty. Quantity of the item posted. (You may enter a negative quantity to post a negative charge.) The system defaults to 1. You might change the Quantity, for example, if Greens Fees for one person cost $25, and the guest is playing with friends. If you enter a Quantity of 3, OPERA will calculate a total price of $75 on the guest's bill and the printed folio.
Nts. Number of nights associated with the posting. Available when the OPP_GCA OPERA Comp Accounting add-on license is active and when posting a Lodging type transaction code that has the Track Nights check box selected. (Nights information is used in developing data for comp analysis reporting.) Your cursor will skip this field if your permissions do not allow you to enter a number of nights.
Win. The Billing screen window in which the transaction is to be displayed. The default is window 1 or the currently active window. You may select another window from the LOV. If the window you select has not yet been opened on the guest's Billing screen, it will automatically be created. If the window number you choose to open is not next in sequence (e.g., if you pick window 4 and there is not yet a window 3 open), OPERA creates the intervening window(s) as well as the window to which you are posting the transaction. If routing instructions have been defined, the transaction is automatically placed in the pre-defined window. (See Managing the Billing Screen for details.)
Arr. Code. Select an Arrangement Code for the transaction. An Arrangement Code is a folio grouping code that controls the display of this transaction on the folio. For example, the total cost for all transactions with the "Expenses" Arrangement Code might be shown on a single line on the folio with the description "Expenses". (The folio style you choose controls whether and how the Arrangement Code is used. See Folio Styles for details.) If the transaction code you select is already assigned to a folio grouping, the appropriate Arrangement Code will automatically appear here. You may edit this entry if you like or select another code from the LOV.
Check No. If the POS is down, and transactions are not being posted automatically by the interface, the check number may be entered manually. You may also enter a check number manually if your property uses numbered checks but does not have a POS interface.
Note: If the Check No. Mandatory check box is selected on the Transaction Code screen, a check number must be entered when posting charges to that transaction code. The check number entered in this field will display on the Billing screen in the Reference column.
Note: If the Cashiering>Rollup Transactions application parameter is set to Y, entries related to the same check number (e.g., Restaurant Food and Tax) on the Billing screen will be rolled up into a single line item. The entry will have a plus sign ( + ) in the Code field, with the check number following the Description. Double-click on the plus to display the individual postings included under that check number. If the Cashiering>Rollup Transactions application parameter is set to N, then the Check Number radio button on the Transfer Type form will be disabled.
Supplement. Additional information regarding the transaction. This field is generally reserved for the guest credit card number. If a negative amount was posted, you are required to enter text in the Supplement field to explain the reason for the negative posting.
Reference. Transaction reference information. This field is generally reserved for the guest credit card expiration date or for notation of any automatically generated taxes for the previously listed transaction. This field is also used to note any transferred postings and/or interface information, such as phone details.
Post. Post the transaction to the guest account. (You may also post the transaction by pressing the [Enter] key at any time while working with the Transaction Posting screen.)
Note: Should the amount not meet the Minimum or Maximum amount that may have been set for the transaction code, then a message is displayed notifying the user what the minimum or maximum amount for the transaction code is. The user can then select to continue to post with the current amount or stop the posting completely.
When you post a transaction and the transaction code has routing instructions for that guest, a prompt asks you to confirm the routing before it is executed. If you select No, the transaction is not automatically routed. (See Routing Transactions for details.)
Note: Transactions that are posted by an interface (e.g., telephone or POS) will not prompt for confirmation.
Note: If the No Post flag has been set on the guest's reservation Privileges screen (a No Post lamp displays in the lower part of the Transaction Posting screen), the warning prompt: "<Room number> has no post flag on. Do you want to post anyway?" appears prior to the first posting attempt. Thereafter, all other postings made during that posting session are made without warning. (See Indicator Lamps for No Post lamp details.)
When the Post button is selected, the value set for the Cashiering>Print Receipt application setting determines the options available to you for printing receipts.
Note: When the General>Profile Language application function is set to Y, if the specific receipt type does not exist for the Language that is attached to guest profile, then the following error message is displayed and the printing is stopped: 'Payment Receipt has not been configured for language Xxxx.'
If the language associated with a Profile is changed after the receipt was generated using a specific language, then the same message is displayed if there is no receipt configured using the new/changed language.
When the General>Profile Language application function is set to N, then the report will continue processing the printing using the Language configured for the property.
The number of copies defaults to the number that is setup for the receipt in Configuration>Setup>Report Setup>Reports (See Report Setup for details). The settings are:
Note: If the Cashiering>Print Receipt application setting is set to Always, a payment receipt will not be generated for payments made to the direct bill Payment Code (that is, payments associated with the transaction code specified by the Cashiering>AR Settlement Trn Code application setting).
Note: Payment receipts can be printed in the guest's language as specified on the guest's profile if the General>Profile Language application function is set to Y. You must also have set up payment receipt reports in the appropriate languages and associated each with a language (see Configuration>Setup>Report Setup).
Close. Exit the screen and return to the Billing screen without making any changes.
(This feature is available when the Cashiering>Articles application function is set to Y.)
One transaction code can sometimes serve as an umbrella for multiple individual items, or articles, that can be posted using that code. At times it may be desirable to be able to break out these separate articles for billing and revenue-tracking purposes. For example, a single "minibar food" transaction code might cover potato chips, crackers, peanuts, pretzels, and so forth. Using articles setup, you can specify an individual article number that identifies each of these food items, even though they are all grouped under the same transaction code. Moreover, you can specify a default price for each article, just as you can for transaction codes. Then, instead of posting a lump sum to the minibar food transaction code, you have the option of posting each individual article and its quantity and price. Using our example, rather than posting 7.75 to minibar food, you can post 5.00 for two bags of peanuts and 2.75 for potato chips. Two separate charges to the minibar food transaction code will appear on the guest's bill (one for 5.00 and one for 2.75). The breakdown of charges by article will also be available for revenue tracking.
If articles are configured for your property, you will see one of the following behaviors when you choose to post to a transaction code that has articles assigned to it. Which behavior you see depends on the Cashiering>Article Prompt application setting.
Regardless of the Cashiering>Article Prompt setting you select, the following shortcuts can be used to post articles:
Upon selecting an article for posting, the article description appears in the Transaction Posting screen Description column. When you select the Post button, the article description is replaced by the description of the transaction code to which the article belongs. The default price appears in the Price column, if a default price was assigned to the article; this default value may be edited.
Note: If you select the Tab key after selecting the article transaction code or entering the article shortcut in the Code field, the cursor moves to the Qty field where you may enter a quantity for that article posting. If you select Enter rather than the Tab key, OPERA assumes a default quantity of 1.
Show Me
See Also
