OzBiz Export

Field Name

Description

Data Type

Required

transaction_id

Unique identifier for the transaction.

Text

Optional (blank accepted)

terminal

The name of the terminal the transaction occurred.

Text

Mandatory

terminal_Location

The Location of the terminal, within the Business/Venue.

Text

Mandatory

line

Line number of the item.

Integer

Optional (blank accepted)

transaction_timestamp

The timestamp of the transaction.

Date Time (yyyy-mm-dd hh:mm:ss)

Mandatory

stock_code

The stock code of the purchased item.

Text

Mandatory

product_description

The name of the Product.

Text

Mandatory

product_department

The department that the Product belongs to.

Text

Mandatory

product_unit_price

The unit price of the Product purchased, before any discounts are applied.

Currency

Mandatory

product_cost

The cost of the item.

Currency

Mandatory

price_level

The price level the Product was sold at, e.g. Member or Visitor

Text

Optional (blank accepted)

quantity

The number of Products purchased on that line item.

Integer

Mandatory

tax_amount

The amount of tax paid on the Product item.

Currency

Mandatory

sale_price

The amount paid for the item.

Currency

Mandatory

member_id

The unique identifier of the member making the transaction. This should be 0 for visitors.

Integer

Mandatory

Field Name

Mandatory

What is it?

Sourced From

Balance ID

Yes

If the information was being supplied from a manual cash register, this would be the non-resettable grand total number. These are produced every time an end-of-day Z read is performed. It allows an owner to check that a register has not been used for a period and then read and zeroed. This provides us with a sequential numbering system so that can track any missed end-of-days.

Generated by the end-of-day finalisation

Date

Yes

This is the date of the End of Day reconciliation, not the date the report was printed. Again, using the example of the manual cash register, this would be the date on which the Z read was carried out.

From the End of Day Report, Date

Gross Sales Amount (Gross because it contains GST)

Yes

This is the Total Sales being reported, including GST.

Normally obtained from the End of Day report ? Total Sales including GST

Debtor Charges Amount

Yes

Sales that have been charged to Debtor accounts

From the End of Day report, Debtor Sales

Debtor Payments Amount

Yes

The total of debtor payments made to debtor accounts.

From the End of Day report, Debtor Payments

Takings

Yes

The sum of all payments made against Sales. This includes payments tendered and recorded as a Payment Method. Includes all payments methods tendered, including non-monetary considerations such as Vouchers.

We anticipate that the actual values will be supplied by the user ? either within the POS or within OzBiz.

If have an end-of-day declaration of actual cash ability, it will be the sum of the ACTUAL amounts for each Payment method. Otherwise will be the expected amount and the register discrepancy determined from a re-declaration in OzBiz.

This total must balance with the reported breakdown by payment method in the C, and E lines.

Total Payouts

Yes

The sum of all payments made from the Cash Register for goods and petty cash. It does not include EFTPOS cash outs or Safe Drops.

From the End of Day report, Register Payouts taken for payment of expenses

Internal Adjustments

No

This was developed for the Hotel industry, where the owner has goods rung up as sold, but then provides the goods free. The barman uses a Payment Method called ?Internal Adjustment? to indicate that the goods were not paid for. Can also be used for markdowns or damaged stock where the sale is recorded, but then expensed - though these are often better handled within the POS inventory management.

Within the POS software these are not to be included as payments within the ?Takings.

From the End of Day report, Internal Sales Adjustments

Site ID

No

Where multiple sites are being entered into one accounting data file, users are able to have the Sites differentiated in reports by using either ?Category? or ?Job? in MYOB. While we are picking up from the file name, can also be included in the header of the file itself.

If used, would simply be a field within the POS. Each Site would be given an identity. In many cases this would be a name that identifies the Location.

Field Name

Mandatory

What is it?

Sourced From

Cost Centre ID

No

If used, would provide separate Sales line for each register.

This may be an option ? most users will only require data for the site as a single S line.

Should only provide Cost Centre ID if have multiple S lines

A single Location may be split into ?Profit Centres? with this field. This is typically a Hotel where the Bar is split from the Bottle shop and the Bistro etc. The Cost Centre is attached to each Register within the Point of Sale report.

This would come from a field that identifies the Location of each Cash Register.

Department ID

Yes

An identifier supplied from the POS identifying the department.

This field is used to link the Sales Department to a GL Code within the accounting programme through our configuration. Department ?Sales? may either be included in income, or be considered as not a part of Income (as in the case of Lotto or Poker Machine revenue). Within the accounting programme, multiple Sales Departments would normally be mapped to a broader Department GL Code.

These Departments will include:

            Normal Income Sales Departments ? Eg. Cards, Papers, Confectionery

            Non-Income Sales Departments - Eg. Lotto, Bus Ticket Sales, Advance Deposits, Layby Receipts

            If have an end-of-day money declaration, include Register Discrepancies.

From within the POS there will be a unique ID for each Department in the Departments Table.

Department Sales Amount

Yes

The total sales for each department, including GST

The Register Department Sales from the End of Day report.

Register Variance from Cash Reconciliation Report Variance ? prepared from your SwiftPOS Back Office end-of-day reconciliation.

GST Amount

Yes

The GST value included in the reported Department Sales Amount

The GST amount for each Register Department Sales from the End of Day report

The GST on the Variance will need to be calculated. This may require that it be based on the % of taxable sales to non-taxable sales for the day.

Field Name

Mandatory

What is it?

Sourced From

Cash Amount

Yes

The Cash value received for banking.

From the SwiftPOS Back Office end-of-day reconciliation

Cheques Amount

Yes

The Cheques value received for banking.

From the SwiftPOS Back Office end-of-day reconciliation

Field Name

Mandatory

What is it?

Sourced From

Payment ID

Yes

The identifier for the payment type

From the Payments Type table in the POS. The field is preferably the NAME of the payment type.

Payment Amount

Yes

The amount for the particular payment type

From the SwiftPOS Back Office end-of-day reconciliation

Memo

No

As each EFTPOS terminal may need to be banked separately, there is a need to be able to identify within the bank deposits the terminal the deposit relates to. Where payment is a Direct Credit, the Customer Name assists in reconciling in MYOB

From the SwiftPOS Back Office end-of-day reconciliation, and using the EFTPOS terminal reports, an attached ID for each EFTPOS terminal. For Direct Credits, the Customer Name either entered manually or picked up from the payment of their account.

Field Name

Mandatory

What is it?

Sourced From

Bank_ID

Yes

When the SwiftPOS Back Office function is done, the cash & Cheques are deposited into bank accounts.

From within the POS, there will need to be a screen into which a name is entered identifying the Bank account into which the deposit is made. The Bank ID is the unique ID from this table for each Bank Account.

Banked Amount

Yes

The amount of cash & Cheques deposited to a Bank Account.

From the SwiftPOS Back Office end-of-day reconciliation, and using the actual banking figures, the amount of Cash & Cheques being deposited into the Bank account.

Field Name

Mandatory

What is it?

Sourced From

Payment ID

Yes

The identifier for the payout type from within the POS

The Payment ID is the unique ID from the Payouts table for each Payout type.

Payout Amount

Yes

The amount taken from the register to pay for an expense

From the end-of-day reports

Payout Memo

No

A free-text description of the payout

Entered into the Cash Register at the time the Cash is taken.

IntAdj_ID

No

The identifier for the Internal Adjustment type in the POS.

Expense Payouts from the register can either be posted to a generic ?Payouts? account, or to specific designated accounts. However, as many payouts will have an Input Tax Credit that can be reclaimed, either this information will have to be entered into the POS, or entered into the accounting programme at a later time. As it is unlikely that the GST input tax credit amount will always be available at the time of the Payout, it is easier to leave the GST off and allow them to make the changes in their accounting.

From within the POS, there will need to be able to identify the type of Internal Adjustment being made.

Internal Adjustment Amount

No

The identifier for the Internal Adjustment type in the POS

The amount entered  into the register as the adjustments

Internal Adjustment Memo

No

A free-text description of the Adjustment

Entered into the Cash Register at the time the Adjustment is made.

Field Name

Mandatory

What is it?

Sourced From

Vendor Ref

Yes

The Supplier Name as it appears in the POS.

From Supplier Name in the POS Supplier table

Date

Yes

The date on the Invoice being entered

Entered by user into the POS, from info on Invoice

Due Date

No

The Date the Bill is due to be paid.

Entered by user into the POS, based on the trading terms for that Vendor

Ref Number

Yes

The Invoice Number (or any other identifying information)

Entered by User from the Invoice

Memo (Optional)

No

A free text description that users may enter onto the Bill as a note for internal use

Entered by the user

Total Amount

Yes

The total amount of the Invoice to be paid

Either entered by user of from the sum of the Items of the Invoice as they are entered into the POS

Published 28 Mar 2024