Meters Resource Elements
While the meters applicable to an EGM as a whole, a game and a jackpot are different in detail, and therefore are captured in separate schemas. Meters resources follow a common pattern of reflecting a set of financial/monetary values some of which are directly used in balancing the entity being metered, and others of which provide a more detailed breakdown (that may not always be up to date or even complete, depending on protocol). In addition meters may include non-monetary occurrence counters. To provide a consistent model across protocols the meters resources contain a protocol specific set of actual meters, with the meters arranged into groups, and each group comprising the following:
- Credit Meter Set
- Debit Meter Set
- Auxiliary Meter Set
- Non-monetary Meter Set
The Credit and Debit meter set comprise the balance meters for the group. The meters within the Credit Meter Set can (and should) always be totalled to obtain the total metered credit contribution for that group. Similarly for the Debit Meter Set. For many groups, one or the other of these sets will be empty. The most obvious example of a group comprising both is the game meters, where Wins is a credit meter and Turnover is a debit meter.
Auxiliary meters may allow finer grained breakdowns to be obtained (possibly recording these directly, possibly requiring that an auxiliary meter be subtracted from a Credit or Debit Meter). Such calculations, while allowing derived values to be obtained at a time where the EGM (or at least the entity involved) is inactive, such as for daily reads, are generally unsuitable for “live” data as not all meters are updated at the same time. This can result in apparent transfers of funds from one derived meter to another, as the underlying meters are updated. Such calculations should be avoided and only meters within the Credit or Debit meter set (or a combination of both) should be added/subtracted to derive “live” values.
For most purposes, it is sufficient to treat the sum of each group’s Credit Meters and the sum of each group’s Debit Meters, as the logical, derived meter pair representing the state of that group. These meters are consistent across protocols. It is only for very specific purposes that a finer, protocol dependent breakdown is needed.
EGM Meter Groups
While all EGM protocols meter similar items, there is some variation in how these items are aggregated. To ensure that information is complete and reconcilable against the EGMs themselves, the actual EGM protocol meters are provided via the API. The MAXsys meters model details the meters that are collected and used, along with the meter relationships and balance equations. Note that while it is possible to perform arbitrary transformations from one meter model to another by applying simple arithmetic, there is no guarantee that all meters for a protocol are updated so as to preserve every such relationship. For this reason the direct/native balance equations and meters for a protocol should always be used when performing financial calculations. Failure to do so can result in phantom movements of funds between meters/accounts as the meters are updated.
Meters are grouped according to their usage for a number of reasons:
- Simply to avoid one vast list to search through and to avoid coupling every use of any sort of meter to every other.
- Each group represents a particular aspect of operation that while it may not be completely independent of other aspects of operation does have its own, independent rules for internal consistency and/or consistency with associated groups.
- Different groups will be updated/reported at different times (and with different frequencies) and/or about distinct components or aggregations of components (e.g. for the whole EGM vs for one particular game on the EGM vs about jackpots on the EGM)
- Different protocols support slightly different ways of reporting data (e.g. varying in how funds into an EGM are broken down into cash, tickets, electronic and/or provided in total). A protocol specific sub-group of meters provides the breakdown – obviously only one protocol will be present in any one meter set, so this breakdown is presented as a union (rather than a sequence of optional values)
Terminology
The egm.meters.AnyEGMMeters Avro schema type is capable of containing any of the meters described here, but a given record can contain meters of only one protocol (X, QCOM or G2S). Given an instance of AnyEGMMeters called m, m.protocol contains one of the types:
- egm.meters.XEGMMeters
- egm.meters.GEGMMeters
- egm.meters.QEGMMeters
In the following descriptions a convention of replacing protocol with the protocol name is used. So a meter name such as X.FundsIn.NonElectronic means the meter, that if m contained X series meters, would be the field m.protocol.FundsIn.NonElectronic.
EGM Monetary Meters
Monetary meters measure funds and represent flows of money. Any such flow on an EGM must preserve the equation: money in + money won – money out – money gambled = current credit + hand-paid wins.
Meters that are (part of) a term in the above equation are monetary meters. However, money gambled and money won represent financial aspects of game play. As such, while there must be monetary meters to represent these terms, the EGM/protocol may also maintain more detailed/specific meters regarding game play (e.g. separate meters for different bet types) that are NOT expected to always be consistent/coherent with the machine monetary meters (because updates/delivery of updates to one may lead or lag the other). Typically these more detailed meters are used for game performance purposes, not for accounting purposes.
NOTE: In some jurisdictions it may be possible for an EGM to have “credit” that while it can be played/gambled is not able to be “cashed”. Not all protocols separately meter funds according to such distinctions. G2S does record cashable and noncash amounts separately. G2S also supports separating cashable funds that are “promotional” from other funds. Neither of these facilities are supported by MAX API. All MAX API operations/meters deal with cashable amounts only.
Because some protocols include redundant meters the following meter lists indicate meters that are part of the primary financial information (required to balance) in italics. Other meters provide a more detailed breakdown of funds but cannot be relied on to always be up-to-date/consistent with the primary meter set. Any transaction that the EGM performs that causes meters to change should cause a new set of all primary meters updated as part of the transaction to be delivered. There is no assurance that any other meters involved will update at the same time (they may update earlier or later).
Any calculations that produce a “derived meter” and include a term that is subtracted from other meter(s) have the potential to result in a negative movement of the derived meter should a meter update be lost or delayed. Such formulations of derived meters should be avoided wherever possible and a form involving addition is preferred (but only possible if there is sufficient redundancy in meters). In the below the preferred form of any derivation is shown first. Alternate derivations/identities are for reference only and should not be used as the primary method of derivation.
Funds In Meters Group
Funds in meters record the transfer of funds that belong to the patron to the EGM’s credit meter. They do not include any increase in the credit meter from game play outcomes (i.e. wins). Note that in some protocols and for some types of win (such as an externally triggered mystery jackpot) the win itself is metered separately but as an amount that is (at least notionally) paid to the patron, not to the EGM credits. If there is a transfer of that won amount to the EGM electronically, it is, at that point, viewed as the transfer of the (already, separately metered as a win) amount back from the patron to the EGM.
G2S Funds In
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| voucher.G2S_cashableInAmt | voucher.cashableInAmt | G2S.FundsIn.Debit.Voucher |
| coinAcceptor.G2S_currencyInAmt | coinAcceptor.currencyInAmt | G2S.FundsIn.Debit.Coin |
| wat.G2S_cashableInAmt | wat.cashableInAmt | G2S.FundsIn.Debit.Electronic |
| noteAcceptor.G2S_currencyInAmt | noteAcceptor.currencyInAmt | G2S.FundsIn.Debit.Note |
- Total Funds In = G2S.FundsIn.Debit(Voucher + Coin + Electronic + Note)
- Cash In = G2S.FundsIn.Debit(Coin + Note)
- Venue Liability In = G2S.FundsIn.Debit(Voucher +Electronic)
The above includes WAT funds transfers to the EGM (FundsIn.Debit.G2S.Electronic) as these represent transfers from the patron’s account to the credit meter. It does not include any meters that represent payment of winnings to the credit meter (e.g from a linked progressive or mystery) as these are considered part of winnings, not Funds In. The inclusion of G2S.FundsIn.Debit.Electronic in venue liability assumes the venue is holding/liable for the value of the patron accounts.
QCOM 1.6 Funds In
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| 05 | Total EGM Cents In | QCOM.FundsIn.Debit.NonVoucher |
| 09 | Total EGM Cash Ticket In | QCOM.FundsIn.Debit.Voucher |
| 11 | Total EGM Coins In | QCOM.FundsIn.Auxiliary.Coin |
| 14 | Total EGM Cashless Credit In | QCOM.FundsIn.Auxiliary.Electronic |
| 16 | Total EGM Note Acceptor Cents In | QCOM.FundsIn.Auxiliary.Note |
- Total Funds In = QCOM.FundsIn.Debit(NonVoucher + Voucher)
- Cash In = QCOM.FundsIn.Auxiliary(Coin + Note)
- Venue Liability In = QCOM.FundsIn.Debit. Voucher + QCOM.FundsIn.Auxiliary.Electronic
Validation/Balance Check to verify Auxiliary Meters are consistent with balance meters:
- QCOM.FundsIn.Debit.NonVoucher = QCOM.FundsIn.Auxiliary(Coin + Electronic + Note)
The inclusion of QCOM.FundsIn.Auxiliary.Electronic in venue liability assumes that all cashless credits are from an account that represents a venue liability (e.g. in house jackpot or a patron account).
X Series Funds In
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| SDB.CashIn | SDB Cash In (includes TITO) | X.FundsIn.Debit.NonElectronic |
| SDB.MoneyIn | SDB Money In (CCCE In) | X.FundsIn.Debit.Electronic |
| MDB.Total Bills Inserted Dollar Value | MDB Notes Meter | X.FundsIn.Auxiliary.Note |
| MDB.Total Ticket Accepted | MDB Ticket In Meter | X.FundsIn.Auxiliary.Voucher |
Note that MDB meters are optional and not always available from the EGM and/or the PIE (GMIC). This impacts on any breakdown of type of funds other than Electronic (CCCE) / Non-Electronic (everything else).
- Total Funds In = X.FundsIn.Debit(NonElectronic + Electronic)
- Cash In = X.FundsIn(Debit.NonElectronic – Auxiliary.Voucher)
NOTE: Use of the Cash In equation for live data is problematic. X.FundsIn.Debit.NonElectronic and X.FundsIn.Auxiliary.Voucher are not delivered in the same message/at the same time and so cannot be relied on to be coherent/consistent at all times. There are insufficient meters available to form a balance equation to determine when the meters are consistent. Negative derived (Cash In) meter movements are possible.
- Venue Liability In = X.FundsIn(Auxiliary.Voucher + Debit.Electronic)
Funds Out Meters Group
Funds out meters record the transfer of funds that belong to the patron from the EGM’s credit meter to the patron. They do not include any spend to place bets/wager/play (i.e. turnover).
G2S Funds Out
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| handpay.G2S_cashableOutAmt | handpay.cashableOutAmt | G2S.FundsOut.Credit.Handpay |
| voucher.G2S_cashableOutAmt | voucher.cashableOutAmt | G2S.FundsOut.Credit.Voucher |
| cabinet.G2S_egmDispensedCashableAmt | cabinet.egmDispensedCashableAmt | G2S.FundsOut.Credit.Cash |
| wat.G2S_cashableOutAmt | wat.cashableOutAmt | G2S.FundsOut.Credit.Electronic |
- Total Funds Out = G2S.FundsOut.Credit(Handpay + Voucher + Cash + Electronic)
- Cash Out = G2S.FundsOut.Credit.Cash
- Venue Liability Out = G2S.FundsOut.Credit(Handpay + Voucher + Electronic)
Venue Liability Out includes WAT funds transfers from the EGM as these represent transfers to the patron’s account from the credit meter. The inclusion of the amount in venue liability assumes the venue is holding/liable for the value of the patron accounts.
QCOM 1.6 Funds Out
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| 03 | Total EGM Cancel Credit | QCOM.FundsOut.Credit.Handpay |
| 04 | Total EGM Cash Ticket Out | QCOM.FundsOut.Credit.Voucher |
| 06 | Total EGM Cents Out | QCOM.FundsOut.Credit.CashAndElectronic |
| 12 | Total EGM Coins Out | QCOM.FundsOut.Auxiliary.Coin |
| 15 | Total EGM Cashless Credit Out | QCOM.FundsOut.Auxiliary.Electronic |
- Total Funds Out = QCOM.FundsOut.Credit(Handpay + Voucher + CashAndElectronic)
- Cash Out = QCOM.FundsOut.Auxiliary.Coin
- Venue Liability Out = QCOM.FundsOut.Credit(Handpay + Voucher) + QCOM.FundsOut.Auxiliary.Electronic
Validation/Balance Check to verify Auxiliary Meters are consistent with balance meters:
- QCOM.FundsOut.Credit.CashAndElectronic = QCOM.FundsOut.Auxiliary(Coin + Electronic)
X Series Funds Out
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| SDB.CancelCredit | SDB Cancel Credit (includes Ticket Out) | X.FundsOut.Credit.HandpayAndVoucher |
| SDB.CashOut | SDB Cash Out | X.FundsOut.Credit.Cash |
| SDB.MoneyOut | SDB Money Out (CCCE Out) | X.FundsOut.Credit.Electronic |
| MDB.Total Ticket Printed | MDB Total Ticket Out Meter | X.FundsOut.Auxiliary.Voucher |
- Total Funds Out = X.FundsOut.Credit(HandpayAndVoucher + Cash + Electronic)
- Cash Out = X.FundsOut.Credit.Cash
- Venue Liability = X.FundsOut.Credit(HandpayAndVoucher + Electronic)
Note that MDB meters are optional and not always available from the EGM and/or the PIE (GMIC).
Funds Accumulation Meter Group
Funds accumulation meters deal with the physical accumulation/flow of funds within the gaming machine, along with any metering of venue operations that add or remove accumulated funds from the gaming machine (hopper fills and cash clearances) without affecting the current credit on the EGM. They do not form part of any credit equations. These meters can be used to determine the value of funds accumulated in the EGM as part of operation/play, but accurate calculation of current levels will typically require additional information (not collected via the monitoring system/protocol) on actual clearances and fills performed.
G2S Funds Accumulation
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| coinAcceptor.G2S_currencyToDropAmt | coinAcceptor.currencyToDropAmt | G2S.FundsAccumulation.Auxiliary.ToDrop |
| coinAcceptor.G2S_currencyToDispAmt | coinAcceptor.currencyToDispAmt | G2S.FundsAccumulation.Auxiliary.ToHopper |
G2S does not meter hopper refills or otherwise attempt to provide a hopper level gauge. It does provide hopper high water (hopper full) and hopper low water events that can be used to manage hopper levels. G2S can use currencyToDrop and currencyToDisp meters to report notes to a note-stacker vs a note dispenser similarly to the way coins to drop vs dispenser (hopper) are metered. However, no note dispenser support is required in NSW, so these meters are not listed/supported at this time.
QCOM 1.6 Funds Accumulation
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| 10 | Total EGM Hopper Refills | QCOM.FundsAccumulation.Auxiliary.HopperRefill |
| 13 | Total EGM Coins to Cash box | QCOM.FundsAccumulation.Auxiliary.ToDrop |
| 1D | Total EGM Coins Cleared | QCOM.FundsAccumulation.Auxiliary.CoinCleared |
| 1E | Total EGM Notes Cleared | QCOM.FundsAccumulation.Auxiliary.NoteCleared |
Cash in EGM = Cash In – Cash Out + QCOM.FundsAccumulation.Auxiliary( HopperRefill - CoinCleared - Note Cleared).
This value includes drop box, hopper and note acceptor.
Hopper Level = QCOM.FundsIn.Auxiliary.Coin – QCOM.FundsOut.Auxiliary.Coin + QCOM.FundsAccumulation.Auxiliary(HopperRefill - CoinCleared). This may be wrong if operational process not followed (correct value of fill entered, clearance recorded.)
X Series Funds Accumulation
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| SDB.Cashbox Meter | Coins to Cashbox (includes notes in and tickets in) | X.FundsAccumulation.Auxiliary.NotToHopper |
While the SDB Cashbox meter is described as such, the inclusion of notes and TITO vouchers in the total essentially serves to record the cash in that does not go to the hopper. This is useful as part of managing hopper levels by using the following measure for coins that have gone to the hopper:
- FundsIn to Hopper = X.FundsIn.Debit.NonElectronic – X.FundsAccumulation.Auxiliary.NotToHopper
Game Play Meters Group
Game Play meters record the game-play on the EGM as funds gambled (turnover) and won. However, only wins to the credit meter are recorded here. Wins that are directly hand-paid are reported in the separate Hand-Paid Wins Group.
G2S Game Play
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| cabinet.G2S_wageredCashableAmt | cabinet.wageredCashableAmt | G2S.GamePlay.Credit.Turnover |
| cabinet.G2S_egmPaidGameWonAmt | cabinet.egmPaidGameWonAmt | G2S.GamePlay.Debit.GameWon |
| cabinet.G2S_egmPaidProgWonAmt | cabinet.egmPaidProgWonAmt | G2S.GamePlay.Debit.ProgressiveWon |
| bonus.G2S_cashableInAmt | bonus.cashableInAmt | G2S.GamePlay.Debit.MysteryWon |
- Total Turnover = G2S.GamePlay.Credit.Turnover
- Wins To Credit Meter = G2S.GamePlay.Debit(GameWon + ProgressiveWon + MysteryWon)
- Total Wins = G2S.GamePlay.Debit(GameWon + ProgressiveWon + MysteryWon) + G2S.HandPaidWin.Debit(GameWon + ProgressiveWon)
G2S does not meter SAP jackpots via the spc device (it does maintain some “meter-like” attributes, per SAP level). Each spc device is associated with (owns) a progressive device, which will consequentially result in the progressive win meters being updated for SAPs identically to LPs.
Any wins awarded via the bonus class (used for mystery jackpots) are always via the EGM, even though the credit meter may not change as a result of the transaction. This is because, if the bonus payment is directed to a destination other than the EGM credits, it will result in a transaction that also increments the relevant funds out meters (e.g. handpay).
QCOM 1.6 Game Play
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| 01 | Total EGM Turnover | QCOM.GamePlay.Credit.Turnover |
| 02 | Total EGM Wins (includes SAP wins) | QCOM.GamePlay.Debit.GameAndSAPWon |
| 0C | Total EGM Stand Alone Progressive Wins | QCOM.GamePlay.Auxiliary.SAPWon |
| 18 | Total Residual Credit Removal Turnover | QCOM.GamePlay.Auxiliary.ResidualCreditTurnover |
| 19 | Total Residual Credit Removal Wins | QCOM.GamePlay.Auxiliary.ResidualCreditWon |
- Total Turnover = QCOM.GamePlay.Credit.Turnover
- Wins To Credit Meter = QCOM.GamePlay.Debit.GameAndSAPWon
- Total Wins = QCOM.GamePlay.Debit.GameWon + QCOM.HandPaidWin.Debit(ProgressiveWon + MysteryWon)
X Series Game Play
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| SDB.Turnover | Total EGM Turnover | X.GamePlay.Credit.Turnover |
| SDB.Wins | Total EGM Wins (includes SAP wins) | X.GamePlay.Debit.GameAndSAPWon |
| PDB2.Wins | SAP Total of all jackpots won level n (n=1..4) | X.GamePlay.Debit.SAPLevel1 |
| X.GamePlay.Debit.SAPLevel2 | ||
| X.GamePlay.Debit.SAPLevel3 | ||
| X.GamePlay.Debit.SAPLevel4 |
Total Turnover = X.GamePlay.Credit.X.Turnover
Wins To Credit Meter = X.GamePlay.Debit.GameAndSAPWon
Total Wins including linked jackpot and mystery is not available per X EGM. A linked jackpot win meter is available on the X EGM via MDB but this may only include amounts actually paid via CCCE. In any case it is dependent on the support of extended CCCE. Typically total link wins paid is obtained by monitoring the linked jackpot controller (LPJS) PDB2.
Hand Paid Wins
Game Play meters record wins that are paid to the credit meter. Wins that are not directly paid to the credit meter are recorded here. These wins, while they form part of the return to player, do not form part of the EGM credit equation.
Wins in this category depend on the EGM protocol, EGM/game types and configuration. Examples of such wins include particularly large game or stand-alone progressive wins. At least some linked progressive wins (above a threshold that can be paid to the credit meter) will be recorded here. In addition some protocols do not automatically pay progressive wins to the credit meter (even if they are not large). In such cases these wins are recorded as hand-paid wins, with the subsequent, actual transfer to the credit meter recorded as electronic funds in. This list is not exhaustive - there may be other cases where a win cannot be paid to the credit meter and is recorded here.
G2S Hand Paid Win
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| cabinet.G2S_handPaidProgWonAmt | cabinet.handPaidProgWonAmt | G2S.HandPaidWin.Debit.ProgressiveWon |
| cabinet.G2S_handPaidGameWonAmt | cabinet.handPaidGameWonAmt | G2S.HandPaidWin.Debit.GameWon |
Note that any wins awarded via the bonus class (used for mystery jackpots) are always via the EGM, even though the credit meter may not change as a result of the transaction. This is because, if the bonus payment is directed to a destination other than the EGM credits, it will result in a transaction that also increments the relevant funds out meters (e.g. handpay).
QCOM 1.6 Hand Paid Win
Linked (mystery or EGM triggered linked progressive) jackpot wins are always treated as-if they are hand-paid in QCOM. Any transfer to the credit meter that may occur is via a separate cashless transfer of the notionally already hand-paid funds onto the EGM as funds in.
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| 08 | Total EGM Linked Progressive Wins | QCOM.HandPaidWin.Debit.ProgressiveWonHandpay |
| 0D | Total Mystery Jackpot Wins | QCOM.HandPaidWin.Debit.MysteryWonHandpay |
NOTE: Mystery/externally triggered jackpot wins are not actually metered by the QCOM EGM. However the MID maintains a pseudo-meter per EGM for recording mystery wins and reports this as if it were QCOM meter 0D.
X Series Hand Paid Win
There is no provision in X for recording hand-paid wins as distinct from wins to the credit meter. Large wins (or simply a large value of the credit meter) may cause a large win lockup, but does not prevent the credit meter and other meters incrementing. When the large win lockup is cleared/the large win is paid, the credit meter and the hand pays meter are updated accordingly.
Both linked progressive and mystery jackpot wins are not metered by the EGM. Instead, at least for overall venue metered win purposes, the total wins for the link are obtained from the LPJS Controller.
Balance Equations & Credit Meter
The Credit Equation (for all protocols) where Credit.* or Debit.* is the sum of all meters within that meter set is: Credit = FundsIn.Debit.* + GamePlay.Debit.* – GamePlay.Credit.* – FundsOut.Credit.*
G2S Balance and Credit
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| cabinet.G2S_playerCashableAmt | cabinet.playerCashableAmt | G2S.Credit.Credit.Cashable |
- Credit = Credit.Credit.G2S.Cashable
QCOM Balance and Credit
QCOM has no actual credit meter and the standard credit equation MUST be used to obtain the current credit value if required. Broken down into individual QCOM meters this is: Credit = QCOM.FundsIn.Debit(NonVoucher + Voucher) – QCOM.GamePlay.Credit.Turnover + QCOM.GamePlay.Debit.GameWon – QCOM.FundsOut.Credit(Handpay + Voucher + CashAndElectronic)
X Series Balance and Credit
| Protocol Meter ID | Protocol Meter Name | Common Meter Model ID |
|---|---|---|
| SDB.Credit | EGM Credit | X.Credit.Credit.Cashable |
- Credit = X.Credit.Credit.Cashable
Mapping to X
Wherever possible the native protocol meter model should be used. Using a model with meters mapped to X has the following issues:
- A temporarily unbalanced set of meters when/if not all meters needed to calculate the derived value are received in the same protocol message.
- Meters cannot be directly compared to the meters displayed on the EGM audit screen.
- No advantage can be taken of the more detailed breakdown of meters available in other protocols.
- No protocol specific handling of metering differences (progressive jackpots in particular). The following mapping can be applied to obtain an SDB-like set of meters where required. It is recommended that these mappings be applied only as a view where interfaces require this form.
| SDB Field | Common Meter Model X | Common Meter Model G2S | Common Meter Model QCOM |
|---|---|---|---|
| SDB.Stroke | X.GamePlay.NonMonetary.GamesPlayedCount | G2S.GamePlay.NonMonetary.GamesPlayedCount | QCOM.GamePlay.NonMonetary.GamesPlayedCount |
| SDB.CashIn | X.FundsIn.Debit.NonElectronic | G2S.FundsIn.Debit(Voucher + Coin + Note) | QCOM.FundsIn.Debit.Voucher + QCOM.FundsIn.Auxiliary(Coin + Note) |
| SDB.MoneyIn | X.FundsIn.Debit.Electronic | G2S.FundsIn.DebitElectronic | QCOM.FundsIn.Auxiliary.Electronic |
| SDB.CancelCredit | X.FundsOut.Credit.HandpayAndVoucher | G2S.FundsOut.Credit(Handpay + Voucher) | QCOM.FundsOut.Credit(Handpay + Voucher) |
| SDB.CashOut | X.FundsOut.Credit.Cash | G2S.FundsOut.Credit.Cash | QCOM.FundsOut.Auxiliary.Coin |
| SDB.MoneyOut | X.FundsOut.Credit.Electronic | G2S.FundsOut.Credit.Electronic | QCOM.FundsOut.Auxiliary.Electronic |
| SDB.Turnover | X.GamePlay.Credit.Turnover | G2S.GamePlay.Credit.Turnover | QCOM.GamePlay.Credit.Turnover |
| SDB.Wins | X.GamePlay.Debit.GameAndSAPWon | G2S.GamePlay.Debit(GameWon + ProgressiveWon + MysteryWon) | QCOM.GamePlay.Debit.GameAndSAPWon |
| SDB.Cashbox Meter | X.FundsAccumulation.Auxiliary.NotToHopper | G2S.FundsAccumulation.Auxiliary.ToDrop + G2S.FundsIn.Debit(Voucher + Note) | QCOM.FundsAccumulation.Auxiliary.ToDrop + QCOM.FundsIn.Debit (Voucher + Note) |
| SDB Credit Meter | X.Credit.Credit.Cashable | G2S.Credit.Credit.Cashable | QCOM.FundsIn.Debit(NonVoucher + Voucher) – QCOM.GamePlay.Credit.Turnover + QCOM.GamePlay.Debit.GameWon – QCOM.FundsOut.Credit(Handpay + Voucher + CashAndElectronic) |
egm.meters.XGamePlayNonMon