Home > Accounts > Concepts > Accounts

Accounts

Introduction

Account Types

Payment Terms

Locations

Transactions

Accounts

POS

Reports

Balance To Date

Introduction

Accounts are used to keep track of how much we owe suppliers and how much customers owe us. Every time we receive an invoice, a transaction is entered in the supplier's account. Every time a customer pays for something with their account, a transaction is entered in the customer's account. From an accounting perspective, these are known as accounts payable and accounts receivable. Merchant Central does not have a general ledger module but it is able to export data to interface with a general ledger.

Merchant Central uses the open item accounting method. Every transaction is recorded individually. When you make a payment, it needs to be allocated to specific sale transactions. Options are available to allocate payments to the oldest transactions to make data entry faster.

Account Types

There are several types of account used within Merchant Central. Supplier, Customer and Gift Accounts.

There are two types of supplier accounts - Supplier Credit and Supplier Debit. The Supplier Credit account records transactions for each supplier invoice we receive. The Supplier Debit account records transactions for the rebates that a supplier owes us. These are the only two accounts available for suppliers and they are ignored by the POS.

There are three basic types of accounts for customers - Member Credit, Member Debit and Points. The Member Credit account is used for customers that pay for goods on account and pay us later on - a 'buy now, pay later' account. The Member Debit account is used for customers that pay us in advance and use the available credit to buy goods - a 'pay now, buy later' account. The Points account is used to record loyalty points on customer sales.

The Points account is automatically created when a new customer is created. The Member Credit and Member Debit accounts are created on demand, that is a customer has asked for a credit account, you have checked their credit references and decide they can have an account with you.

Note: The values shown in the Points account are actual points, not real dollars/pounds/whatever your currency is.

You can also define additional types of customer accounts. Imagine you were in a golf club. You could have a credit account to use in the golf shop, a food account to use in the club's dining facilities and a general debit account to use when buying drinks at the bar. When a customer account is used there will be a BE customer attached to the POS transaction so the options for things like printing the balance on the receipt will be applied when printing the customer details.

There is one more type of account and that is a gift account. This is a combination of a member debit account and a gift certificate. The customer can buy a gift account item for $50. This will automatically create a new gift account with a credit of $50. The customer can then use that account just like a member debit account. The key point is that the gift account is not connected to the customer in anyway. The account can be purchased by one customer and given to some one else as a gift.

You can create new customer account types, or rename the existing types, using the Account Types function.

Payment Terms

Payment terms are used to show when an account needs to be paid (either for you paying the supplier or the customer paying you). You can set up payment terms for weekly, monthly, quarterly payments. Each account that is created is then assigned a payment term. This allows you to identify the accounts that need to be paid together. The system does not actually take any special action on specific dates. It is up to you to say I am doing the monthly accounts today. The payment terms simply gives you a way to identify which accounts are the monthly ones.

Different payment terms can be set up for each type of account. The Account Payment Terms is used to set up these codes.

Locations

In a centralised system, you need to make important decisions about how accounts are shared across the locations. Can a customer use their account at all locations, or only the location where they joined? Is a single supplier account used for all locations, or does each location have their own account?

In the Accounts tab in the Locations function, you can set up the rules for account locations. Basically, for each location, for each account type, you tell the system what Account Location should be used. Any locations with the same Account Location will share accounts. So if a customer account can be shared across all locations, you would edit location SHOP1 and say its Account Location is ALL, then you would then edit location SHOP2 and say its Account Location is ALL and so on for all locations. If a customer account could only be used at the current location, you would edit SHOP1 and set its Account Location to be SHOP1, SHOP2 would have an Account Location of SHOP2, and so on. You don't have to use either the specific location or the top-level ALL location. You could have accounts by state. The rule is simply that if two or more locations have the same Account Location code, they will share accounts.

WARNING: These account locations need to be set up before any accounts are set up.

As new suppliers are created, the system will automatically create all the required Supplier Credit and Supplier Debit Accounts for the unique Account Locations. If you add a new location, the system will check its Account Location and create new Supplier Credit and Supplier Debit accounts, if required.

If you change the Account Locations in the Locations function, existing accounts will not be modified. You can delete, the record from the grid and re-insert it, in which case new accounts will be set up, but existing accounts will still not be changed.

Transactions

A transaction is an individual entry in the system. Transactions can be recorded for sales from POS, invoices from suppliers, payments (both in and out), credit notes, and so on. Many of these transactions (such as sales and invoices) are automatically created by the system. Other transactions (such as payments or credit notes) are manually entered using the Accounts. There is a generic transaction called an adjustment. When you do an adjustment, you have to select an adjustment reason. This reason will tell the system two things:

The adjustment reasons are set up using the Account Adjustment Codes function. Different reasons can be set up for each type of account.

Accounts

Supplier accounts can be accessed by finding the supplier in the Supplier function and going to the Accounts tab. The grid on this tab will show all of the accounts that belong to this supplier. These will be the Supplier Credit and Supplier Debit accounts for each Account Location. Highlight the required account and press the Accounts button. This will start the Accounts function and show you the full account details.

Customer accounts can be accessed in a similar way. You find the customer in the Customer function and go to the Accounts tab. The grid on this tab will show all the accounts that belong to the customer. Highlight the required account and press the Edit button. This will start the Accounts function and show you the full account details. You can add a new account for a customer by pressing the Add button. This will ask for the account type, payment terms and credit limit.

You can also access the Accounts function directly from the menu and find the account you require. If you use this method, there should be an Accounts menu option for each account type, for example Supplier Credit Accounts, Supplier Debit Accounts, Customer Credit Accounts, and so on. The system uses the same function for all account types.

POS

Customer accounts can be accessed from POS. If you create new customers at POS, you can also create new accounts. You can only create a single default account for a customer. (The type of account that will be created is defined in the Loyalty tab of System Settings.) If you want to create more than one account, you need to use the back office Customer function.

You can pay for a sale on account by selecting the account tender code. This tender will only be displayed if the sale has a customer and that customer has one or more accounts. If the customer has more than one account, you can choose which account to use for the sale. The system will automatically create an account transaction for this sale.

You can make an account payment on POS in a similar way. You select Activity| Account Payment to start the payment. You will be asked for a customer and the account for which the payment is being made. This will create a payment transaction in the customer's account.

Reports

There are a number of reports that can be used to help you run your accounts efficiently:

Statements

Statements showing the current amount owed and transactions for the last accounting period can be generated using Account Statements. This shows the details for one account type (customer credit accounts, supplier credit accounts, and so on).

Unallocated Payments Report 

As a payment is received, it is allocated against existing transactions. Payments should be fully allocated so that the system can accurately calculate the overdue amounts. This report shows payments that have not been fully allocated yet.

Aged Trial Balance 

This report shows the amount due for each account, aged over a number of periods.

Member Account Transactions Report

This report shows the transactions for customer accounts. It is only for customer accounts because it shows the details of the original POS transaction.

Balance To Date

All accounts keep a balance value. This is the sum of debits and credits of all the transactions on the account. However, there is also a To Date Value balance. This is primarily used for Member Points accounts and is used when upgrading/downgrading members (see Upgrade Members). It keeps track of the balance earned since a certain date. Lets say there is a rule that if a Silver member earns 10000 points they can be upgraded to Gold. We have a member who has earned 11000 points but has spent 9000. His normal balance will be 2000 points. Using this balance, the member would not be upgraded  However, their To Date Value balance would be 9000. With this balance the member would be upgraded. Sale transactions will adjust the balance. Payments will not. Adjustments may adjust it if the adjustment type is flagged to adjust the balance (see Account Adjustment Codes).

When the Upgrade Member process is run it will use the To Date Value balance. Once finished it will reset the value back to zero. The balance will then increase, ready for the next cycle of upgrading.

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