Skip to content

POS Tenders Table and Records

Andy Theuninck edited this page Mar 23, 2015 · 1 revision

Intro

Tenders in CORE refer to methods of payment such as cash or credit card. Information about tenders is stored in the "tenders" table of the operational database (default name: opdata). The table includes these columns:

Table Structure

  • TenderID is simply a unique integer identifier.
  • TenderCode is a two letter code associated with the tender. This code must be unique. Using the values provided in the sample data for common tenders is recommended but not required. This value is what the cashier types to use a particular tender. The value also appears in the trans_subtype column of transaction records for tenders. Transaction records for tenders have trans_type T.
  • TenderName is the name of the tender that appears on screen, on receipts, and in the description field of transaction records.
  • TenderType is a two letter code associated with the corresponding change record. This value should generally match an existing TenderCode. The value appears in the trans_subtype column of change transaction records. See Change Records
  • ChangeMessage is the name that appears on corresponding change records on screen, on receipts, and in the description field of transaction records. See Change Records.
  • MinAmount is the minimum amount allowed for a given tender. Entering a lower amount will result in a warning for the cashier.
  • MaxAmount is the maximum amount allowed for a given tender. Entering a higher amount will result in a warning for the cashier.
  • MaxRefund may or may not do anything right now. Now is 23Mar2015.
  • TenderModule is a character value naming a PHP TenderModule class. Assigning modules to tenders allows more complex error conditions, warnings, and behaviors at run time. The default value is the string "TenderModule". See Tender Modules.

Change Records

Every completed transaction will contain at least one tender record and one change record. This is important to understand when counting tender usages and when choosing TenderType column values. When a tender is entered that matches or exceeds the current transaction total, the next to records will be a tender record and a change record.

  • The tender record has trans_type "T", trans_subtype matching the tender's TenderCode value, and total is the amount tendered. Tender totals are generally reflected as negative was as item totals are reflected as positive.
  • The change record has trans_type "T", trans_subtype matching the tender's TenderType value, and total is any excess amount (including zero).
    • If the current total is $10 and the cashier enters a $15 tender, the tender record will have total $-15 and the change record will have total $5.
    • If the current total is $10 and the cashier enters a $10 tender, the tender record will have total $-10 and the change record will have total $0. The default behavior uses "CA" (i.e., Cash) as the code for all change records. This tends to be accurate in terms of cash entering and leaving the till and makes counting the number of non-cash transactions easy. The dollar value of items purchased with non-cash tenders may be inaccurate from a certain point of view. For example, if a customer makes a $20 debit payment and receives $10 cashback with the change record as "CA", the debit total for the day would say $20 when only $10 worth of goods were purchased with debit. On the other hand, the card processor's reporting and batch/settlement information would most likely list it as a $20 line item. Reconciling total authorized amounts works better if cashback does not reduce the debit tender type.

Tender Modules

Tender modules provide additional run-time customization and flexibility. This section discusses the default tender module and some (but not all) of the alternatives.

  • TenderModule (default) enforces the limits described in the table structure above. It does not limit the amount beyond the MinAmount and MaxAmount warnings. In particular, there is no restriction on overtendering resulting in non-zero change. The default module also does not require an amount. Merely entering the two letter TenderCode will prompt the cashier to tender the current transaction total as the given tender. This behavior is provided to reduce miskeys but is generally not appropriate for all tenders.
  • NoDefaultAmountTender requires the cashier to key in an amount for the tender. There is no prompt provided to tender the entire current total. Coupons, for example, might use this module.
  • NoChangeTender limits the tender amount to the current total - i.e., if the total is $10 attempting to tender $10.01 is an error.
  • FoodstampTender enforces the specific limits of foodstamp eligibility. This is only appropriate for tenders where eligibility is an issue. "EBT Cash" or equivalent does not require this enforcement.
  • CheckTender behaves mostly like NoChangeTender but also includes check endorsing via the printer. Members may be allowed to write checks that exceed the transaction total. This is a separate, member-specific setting on the Extra tab.
  • StoreChargeTender checks member balances and limits for in-house charge accounts. This extends customers a small line of credit or lets them run a tab.
  • SignedStoreChargeTender is the same as StoreChargeTender but uses digital signature capture. Compatible hardware is required.
  • ManagerApprovedTender requires a manager password before the tender is applied.
  • DisabledTender prevents a tender from being used. Deleting the tender from the tenders table will have a similar effect, but keeping the record may be useful in reporting against historical data that includes retired or discontinued tender types.

Refunds and Tenders

Refunds are often a point of confusion due to how CORE writes Change Records. In the (problematic) refund situation, the transaction total will be negative. When faced with a negative total, there are two rather different methods of finishing the transaction:

  • Enter a negative tender for the refund amount and desired tender type. For the sake of accuracy and/or if the POS keyboard lacks a minus key, simply entering the two letter tender code without an amount may be preferable. The tender record will have the tender type the cashier entered and the total column will be positive rather than the typical negative. The subsequent change record will have a total of zero.
  • Enter zero for an amount plus the desired tender type. The tender record will have a total of zero and the change record's total will match the refund amount. In either case, the rules above for Change Records will determine the tender type for that record. If there's no per-existing preference or learned behavior, the first approach is probably easier. The non-zero total record is controlled directly by the cashier's input. Marking the "zero change" record with an appropriate tender type is ideal, but if there's a mistake or misconfiguration the practical consequences of screwing up the zero record are minimal.
Clone this wiki locally
You can’t perform that action at this time.