Home > Technical > Data > DailySales

DailySales

The DAILYSALES table contains details about the actual transactions performed at POS. For a single transaction there will be a number of DAILYSALES records. The strSaleType field contains a value which determines the use of the specific record. The values for these fields are explained below.

strSaleType Field

The strSaleType field in DAILYSALES gives meaning to the record.

Value   

Comment

)

Records that a user logged in.

(

Records that a user logged out.

>

Indicates a Clock In transaction.

<

Indicates a Clock Out transaction.

}

Indicates POS has entered training mode.

{

Indicates POS has exited training mode.

@

Indicates stock adjustment (breakage, inc stock) which is the equivalent of a 'H' record for stock adjustments.

$

Indicates a Givex Gift Card has been sold or redeemed.

^

This is basically the same as $ but for POINTS. These are both gift card updates; the $ is for amounts.

A

A trailer record. The contents of the DAILYSALES is not particularly important. The 'A' record simply tells us that it is the end of the transaction. It is not required for Log In/ Out, Clock In/ Out, Training On/ Off transactions. For other transactions, there is always one record at the end of the transaction.

a   

An item on a pending or cancelled transaction. This is really just bookmarking the item. It is similar to the 'I' value but it does not count as an actual sale and it doesn't adjust stock. If the 'a' record is for a pending transaction such as a customer order, layby or COD, it does have an impact on the Allocated Qty of an item.

B

Tender fee.

b

This is similar to a 'T' but indicates a previous payment. It is typically used on Order or Layby transactions. In this case the original transaction would have a T record to record the payment. When the transaction is recalled and a further payment made, the original payment will be shown in the transaction as a 'b' and the new payment will be a 'T'.

C

Account payment. The customer has made a payment to adjust their account.

c

Cancellation of an order. The value will be the total value of the transaction.

D

Tender in an external payment type transaction.

E   

The amount given as change back to the user. There will be zero or one record for the entire transaction.

e

Cancelled Item. This is used for audit purposes to show an item has been cancelled.

F

Refund.

f

Indicates a change of quantity. It is simply an audit record. If you changed the quantity of an item you would get an 'I' record for the new quantity and an ' f' record for the old quantity.

G

Header record in a gaming transaction.

g

Item in a part return transaction (like I or m).

H  

Header of a transaction that contains items. There will be one record for the entire transaction.

h

Similar to 'H' but indicates a transaction paid for with points. This was a version 4 code which is no longer used.

I

An item on a transaction. It indicates the item has been accepted, recorded as an actual sale and stock has been adjusted. There will be one record for each item sold.

i

Similar to 'I' but indicates a transaction paid for with points. This was a version 4 code which is no longer used.

J

Skim/Float transaction. A negative value indicates a skim and a positive value indicates a float.

j

The tip amount which may have been added to a transaction.

K

Shows any rounding on the transaction. If you round a sale to the nearest $0.05, you might have to round the sale by $0.02. This value will be written in a ' K' record.

k

Rounding in a cancelled transaction.

l

Modifier in a cancelled transaction.

M

Similar to 'T', this indicates a payment on an exchange transaction.

m

An item used within a set meal item. If you had a set meal of a drink, burger and fries, there would be an 'I' record for the set meal item and an ' m' for the drink, burger and fries.

N

Indicates a No Sale transaction.

n

Set meal in a cancelled transaction.

O

The amount over tendered for the sale. The total value of the 'T' and 'O' records is the amount actually paid by the customer. There will be zero or one record for the entire transaction.

P

Paid In/Out transaction. A negative value indicates a paid out and a positive value indicates a paid in.

p

Reward.

Q

Used in SUV records. Previously taken voucher record – equivalent to a b tender record for tenders accepted previously for example in an order where the items have not yet been released or a transaction put on hold after tenders were taken.

q

Indicates additional operators assigned to a transaction.

R

Similar to 'T', this indicates a payment on a return transaction.

r

Request to reprint a transaction. Used as an audit to indicate a transaction was reprinted.

S

Start of day float.

s

Header in a POS transfer.

A payment on this transaction. This is the value of the amount used to pay for the exact transaction amount. If the payment was overtendered, the remaining amount is stored as an O. There will be one record for each payment made. Only the last payment can be considered over tendered.

t

Similar to T but indicates a transaction  paid for with points. This was a version 4 code which is no longer used.

U

US taxes – in sales / refund and so on.

u

US taxes – in a print bill, cancelled transaction and so on.

V

Committed SUV tender record. That is, a voucher which had been successfully marked as used with the voucher service.

v

Uncommitted SUV tender record. The voucher was validated but could not be marked as used - presumably because the voucher service went off-line before the transaction was completed.

W

Discount - attached to an I record. Added to support the Cloud Deals Engine to support separate discount records rather than including the discount information within the item record.

w

Discount - attached to an a record. Added to support the Cloud Deals Engine to support separate discount records rather than including the discount information within the item record.

X

Tender in a cancelled sale.

x

Similar to 'H' but is the header of a cancelled order/return/layby. There will only be one record per transaction.

Y

Start shift header.

y

Reprint of an EFT receipt when the interface used is EFT link.

Z

Indicates a Z read has been performed.

z

X-read header.

Example 1. Basic Sale

1 item sold for $50

1 item sold for $10

Customer paid $60

H

$60

I

$50

I

$10

T

$60

A

 

Example 2. Basic Sale Overtendered

1 item sold for $50

1 item sold for $10

Customer paid $100

H

$60

I

$50

I

$10

T

$60

O

$40

E

$-40

A

 

Example 3. Customer Order

1 item sold for $50

1 item sold for $10

Customer paid $20 deposit

H

$60

a

$50

a

$10

T

$20

A

 

Customer pays remaining $40

Note the 'a' records for the item have changed to 'I' records to indicate the items are finalised.

H

$60

I

$50

I

$10

b

$20

T

$40

A

 

Example 4. Basic Sale Cancelled

1 item sold for $50

1 item sold for $10

User cancels sale

x

$60

a

$50

a

$10

A

 

Example 5. Customer Order Cancelled

1 item sold for $50

1 item sold for $10

Customer paid $20 deposit

H

$60

a

$50

a

$10

T

$20

A

 

Customer cancels the order and is charged cancellation fee of $5.

x

$60

a

$50

a

$10

I

$5

b

$20

c

$60

T

$-15

A

 

Example 6. Basic Sale With Rounding

1 item sold for $49.99

1 item sold for $10

Customer paid $60

H

$59.99

I

$49.99

I

$10

K

$0.01

T

$60

A

 

Example 7. Paid Out Transaction

Paid out $40 for a cash invoice.

P

$-40

A

 

Example 8. Clock In

>

 

Example 9. SUV

If a transaction holds 4 items and was paid for with a voucher for 1.00 and then cash for the remainder,

H

the header record

4 x I

4 item records for the item details

T

the SUV tender record for an amount of 1.00

V

the voucher details

T

the cash tender details

Tax

The sales for an item are stored in curSales. This amount is an ex-tax amount though. The tax details are stored in curTaxAmt1, curTaxAmt2 and curTaxAmt3. curTaxAmt2 is the Service Fee, curTaxAmt2 is the GST/VAT and curTaxAmt3 is the service fee (used in Singapore). The tax amounts are stored to the number of decimal places for the currency used.

The tax amounts are stored as a line total value. Lets say you have an item worth $10 with 10% sales tax. For one item, curSales would be $9.09 and the curTaxAmt2 would be $0.91. If we sold two items, the curSales would be $18.18 and the curTaxAmt2 would be $1.82.

The total of the tax amounts on the 'I' records will equal the values stored in the 'H' record.

Discounts

The discounts for an item are stored in four fields - curDiscount, curSalesDiscount, curOfferDiscount and curTenderDiscount - depending on the type of discount. The value of the discount is a unit discount stored to four decimal places. The values are stored as a negative number.

To calculate the total discounts given, use the following formula:

( curDiscount+ curSalesDiscount+curOfferDiscount+curTenderDiscount) * dblQtySold

The sum of the calculated discounts (discounts x quantity) on the 'I' records should equal the discount values stored on the 'H' record.

If you wanted to know the original pre-discount price of the item, you would do the following calculation:

curSales + curTaxAmt1+curTaxAmt2+curTaxAmt3- (( curDiscount+ curSalesDiscount+curOfferDiscount+curTenderDiscount) * dblQtySold)

Identification Numbers

Before looking at the specific identification numbers available in DAILYSALES, it is important to understand transactions and their relationships.

Action

An action performed on the POS, for example a sale, making a customer order, retrieving a customer order and making a further payment, retrieving the customer order and finalising it. Each of these is a specific action.

Transaction

A collection of related actions. Each sale will be considered a transaction by itself. But a customer order which is originally made, retrieved with an extra payment and then retrieved again to be finalised,  will have three actions but is considered the same transaction.

With this distinction in mind, the following identification numbers are available in every DAILYSALES record:

intSaleID

The receipt number (that appears on a customer receipt) for an action. This number is generated per till ,so it can be duplicated in the database for different tills. Since the number is obtained from DYNAMIC.INI, if the file is cleared its possible the number will restart from one and so can actually be duplicated within a till as well. The number is always generated by POS as soon as the action is performed.

intTransNum

The number for the transaction. For normal sales, the number is assigned when the sale is processed at the MCS end. For pending transactions such as held transactions or customer orders, POS will obtain the number from MCS and assign it immediately. In the case of a customer order being made, retrieved for a payment, then retrieved for finalising, there will be three actions and one transaction. Each action will have a different intSaleID but the same intTransNum.

intOrderCode

Every single action in the system will have a unique order code. This is the best way to identify a specific instance of an action. It is assigned by MCS as the action is processed. So in the case of the customer orders example we have been using, there will be three actions each with a different (but possibly duplicate) intSaleID, the same intTransNum and a unique intOrderCode.

Converted from CHM to HTML with chm2web Pro 2.85 (unicode)