NP Retail Support

Search




Table of Contents

68.1 POS Entry List - Setup
68.1.1 Underlined Configuration for POS Entry List to work
68.1.2 NP Retail Setup
68.1.3 Sample Chart of Account
68.1.4 Bank Account
68.1.5 Setup for POS
68.1.6 POS Payment Bins
68.1.7 Different POS Unit and Bin configurations
68.1.7.1 Setup of Single POS Units
68.1.7.2 Setup of multiple POS Units and Bins as a cluster on its own
68.1.2 POS Payment Methods
68.1.3 POS Payment BINS
68.1.4 POS Entry Posting
68.1.4.1 Posting Sequence of POS Entry lines
68.1.4.2 How to do different configurations for the POS Posting Setup?
68.1.4.3 POS Posting Priority Rule
68.1.4.4 Different logic of configuration for POS posting setup
68.1.4.5 Posting Compression
68.1.4.6 Accounting Setup for POS Payment Methods not included in counting process
68.1.4.7 Accounting Setup for Different Currencies when counting
68.1.4.8 Accounting Setup for Transfer to BANK & SAFE
68.1.4.9 Conclusion on POS Posting Setup
68.1.5 POS Menus Setup
68.1.5.1 POS Action BIN_TRANSFER
68.1.5.2 POS Action BALANCE_V3
68.1.5.3 POS Action PRINT_RECEIPT
68.1.5.4 POS Action RUNPAGE for POS Entry List


POS Entry List - Setup

The POS Entry List has replaced the classic audit roll that we used to have. You will need to go to the following to activate it: Menu: Departments/Retail/Setup



And it requires the "Advance Posting Activated" in NP Retail Setup. Once this setup is done and the posting to Item ledger Entry & G/L is activated in "Advanced POS Entries Activated", you are set to use the POS Entry List.
You will see a message that will appear on the Audit Roll indicating that the Advanced Posting is activated.



Unlike the Audit Roll which constitutes one table and the information are kept in that one table, the POS Entry List has different components or sub-pages that points to different tables.


  • POS Entry (6150621) – This table is the header for the lines, you will have a summary of the transactions in this table.
  • POS Sales Line (6150622) – This table gives us the POS Sales Lines details that have been posted via the POS.
  • POS Payment Line (6150623) – This table gives us the Payment details of each transaction done via the POS.
  • POS Tax Amount Line (6150629) – This table keeps the tax information for the transaction.



68.1.1 Underlined Configuration for POS Entry List to work

To understand what needs to be configured, let's try to identify and compare to the setups used by Audit Roll.
In the table below, we have identified sections in the old setup that has not yet been migrated to the POS Entry list.

Audit Roll

POS Entry List

Configuration Areas of the Audit Roll that is still required for POS entry to work

Retail Setup

NP Retail Setup

New concept


POS Store

New concept

Cash Register

POS Unit

The Cash Register & POS Unit must have the same ID.
We need the following sections from Cash Register:

  • Register
  • Touch Screen
  • Sale




Payment Type

POS Payment Method List

The Payment Type & POS Payment Method List must have the same ID.
We need the following sections from Payment Type:

  • General
  • Option
  • Prefix Table
  • Coin Type





POS Payment Bins

New concept


POS Posting Setup

New concept



NP Retail Setup

Menu: Departments > Retail > Setup > NP Retail Setup



The two fields Automatic Item Posting (Posting to Item Ledger Table) and Automatic POS Posting (Posting to G/L Entry Table) controls when the posting of the POS Entry Lines are done.


Note on Activating the POS Entries:


All POS Posting Setups & Chart of Account should be done before activating the Advanced Posting Activated.


In case of a conversion of a client who is on Balance V1 into Balance V3, the last balancing of the register must be done before Advance Posting Activation. On activation, the system will take the closing of Balance V1 & create the Opening Float of Balance V3 from it.

Sample Chart of Account


Bank Account

Setup for POS

The POS configurations for Posting are found in the NP Retail setup. The shortcut for the menus are under Navigate > Advance > POS Group, there is setup. The path for NP Retail Setup is found under the Menu: Departments > Retail >Setup

POS Payment Bins


This setup defines the POS Payment BINS that are available on doing Cash Count. For example, is a BIN is referred to a physical cash drawer on register or a safe or a bank.

Note:

The AUTO-BIN always carries a Bin Type "Virtual". This type is not seen on the Cash Balancing and Transfer Screen so that we prevent salespeople from transferring manually into that BIN by mistake.

68.1.7 Different POS Unit and Bin configurations


The default bin is specified on the POS Unit. For end of day purposes, it needs to be executed for evert POS Unit.


A POS Unit may have many additional bins, these are specified on the Unit To Bin Relation.
Currently there is no easy way of selecting alternative bins, but end-of-day process will handle contents from multiple alternative bins correctly.


Multiple POS Units can also share the same bin. Even though they share the same bin id, bin contents is not mixed between the POS Units, therefor End of Day process still needs to execute on both POS units.


Setup of Single POS Units

Setting default POS Payment Bin in the POS Unit.

Select the POS Unit and then configure a default POS Payment Bin associated with it.

POS Unit to Bin Relation

In the POS Unit Card, go to the NAVIGATE Ribbon to set the relationship of POS Unit to POS Payment Bin. Instead of a one to one relationship, we can have multiple relationship.

But we need as a base to have at least one to one relationship whereby a POS Payment Bin is attached to a POS Unit. The normal scenario is that we have a POS Payment Bin per POS Unit.



The following scenario is possible, but there is no practical need for them:

a) In a scenario that we have a supervisor who does the Cash Count on all POS Payment Bins, even those attached to other POS Units, we can select to have a POS Unit that sees all the Bins & the counting can be done from that POS Unit itself.


Hence the POS Unit 1 will see all the bins even if they are under POS Unit 2 or POS Unit 3. The counting can be done from POS Unit 1 itself and no need to move to individual bins.



b) We can even take that logic into a scenario where we have a POS Payment Bin shared by two POS Units.


In this case, the POS Unit 1, will see both POS Payment Bin 1 & 2 for counting. And the POS Unit 2 will see both POS Payment Bin 2 & 3 for counting.


Setup of multiple POS Units and Bins as a cluster on its own



This setup can also be done when the bins are shared. Since the bin contents is tracked, it will not make any difference to the process.

This model will be more difficult to analyse due to the amount of transaction moving bin contents from slave unit to master unit on the same bin id.


Setup of POS End of Day Profile for Multiple POS Unit

There is a new field on the POS Unit card, "POS End of Day Profile". Those POS units sharing the setup should have the same profile code. When every POS are individuals, the can all share the same profile. A blank profile code provides reasonable defaults.

All POS units that should be managed by one the same singe end-of-day process, must share the same "POS End of Day Profile" code. Having multiple groups requires different profile codes for each group.




All the POS Units in the cluster will have the same "POS End of Day Profile". This is the link to the group configuration. In practice, you will have a configuration for each cluster.

Explanation of fields:

  • End of Day Type:
    • Individual – all POS's are required to execute End of Day individually.
    • Master & Slave – one POS within the group of POS's sharing the profile code, is designated master when it comes to end of day processing. The other units are considered to be slaves.
  • Master POS Unit No.: The designated master POS within the group of POS's sharing the profile code.


  • Z-Report UI: Controls the UI when a Z-Report is requested. The Z-Report will always print. Option are:
    • Summary + Balancing: With this option, user is first shown the summary screen and from the page menu you can navigate to the balancing page. This is the default behavior.
    • Balancing Only: With this options, you are not bothered with sales statistics are taken directly to the balancing page.


  • X-Report UI: Controls the UI when a Z-Report is requested. Option are:
    • Summary + printing: shows the sales summary page, you can optionally navigate to the bin counting page. The X-Report is printed on completion. This is the default behavior.
    • Printing Only: There is no page displayed, and there is only printing.


  • Close Workshift UI: When the slave POS Units, ends the work shift, you have the following options:
    • Print: will close the POS Unit, and print the X-Report.
    • No Print: will close the POS Unit without printing the X-Report.


  • Force Blind Counting: With this options, you will not get any help regarding the calculated contents of the bin.


Forced Blind Counting TRUE:


Forced Blind Counting FALSE:


Requirements for Single End of Day process for Multiple POS Units.

  • A POS Unit does not need to be balanced prior to being added to a master & slave setup. Whatever un-balance amounts on the unit, will be added to the group.
  • A POS unit does not need to be balanced when leaving a master & slave setup. The un-balanced amount will remain on the unit until its balanced as an individual or in a different group.

At the end of the day

  • All slave POS units must be in the state closed before the master POS unit can perform the end-of-day. This is to prevent an ongoing sale on one of the slaves during end-of-day process on the master POS.
  • To close the slave POS, there is a new verb "Close Workshift" on the BALANCE_V3 action.


  • If master POS attempts to do the Z-Report prior to all slaves being closed, there will be an error message.


  • X-Report from a either master or slave is possible regardless of state of the POS. An X-Report on the master will include all the sales data / bin contents from the slaves.


  • The "Close Worshift" is only intended for POS Units configured to be slave, the purpose is to prevent the slave POS unit to login while master POS unit is performing end-of-day.


Beginning of the day

  • The master POS Unit must be the first Unit to open after End-of-Was performed. This is guarantee the bin contents confirm message on POS open.


  • Attempting to open a slave POS unit prior to the master POS Unit is opened, results in an error message:


  • When opening a slave POS unit, you are greeted by a different message than from the ordinary message:


  • A slave POS Unit may close and reopen any number of work-shifts through-out the day, as long as the master POS remains open.


POS Payment Methods

The POS Payment Methods replace the Payment Types in the Advance Posting Process that use the POS Entry List. Hence the accounts setting should be done on Payment Methods and not Payment Types.



If we want to include the payment method in the register balancing, we need to activate it in the Payment Method card as above. It is only these POS Payment Method set to Count that will be available in the counting process in the register balancing.



If we want the system to accept the amount without counting, then we set the field Include In Counting to "Virtual".


Import Note: As we are using two different systems for type being, we will have both Payment Type & POS Payment Method defined & run in parallel.

POS Payment BINS

The concept of BINS illustrates the buckets where we keep or "receive into" our currencies or even none-currencies like lottery / Voucher if we want to track them when we move them around. We can have Cash Drawer for a Register, as well as a Safe in the Manager's Office or ultimately our Bank. They are buckets where we receive into the currencies from our sales.

And on each POS Unit (Cash Register), we attached a Default POS Payment Bin.


Now that we understand that we have an account code attached to each POS Payment Bin Code, we can do some accounting transactions. If we extrapolate the POS Posting Setups to the POS Payment Bins in a simplistic logic, we have the following:


POS Entry Posting

Posting Sequence of POS Entry lines

When posting occurs is managed by the setting on NP Retail Setup:

Option

Logic

No

The system will not post automatically the POS Entry Lines. The user will need to go to the POS Entry List to post the entries one by one or by batch.
Or we can set a task queue to run CodeUnit 6150631.

After Sale

As soon as the Sale is completed, the system will post the line. In this situation, the posting to G/L is done one by one, we do not have a consolidation of lines when posting. Hence the posting will not be compressed.

After End of Day

As soon as we complete an End of Day on a POS Unit, the system will post the lines in details or consolidated form, depending on the setup for compressing the data for posting.

After Last End of Day in Store

A store can have multiple POS Units. When we refer to last end of day, we are referring to the end of day of the last POS Unit for that Store. It is at this point, that the POS Entry Lines will then be posted.
The system will post the lines in details or consolidated form, depending on the setup for compressing the data for posting.

After Last End of Day Company-wide

The structure of the Company can be that it has multiple stores and under each store, we have multiple POS Units. When we say Companywide, it means that all the stores should be balanced before the posting starts.
Bottomline, we need balance all the POS Units before the posting starts.
The system will post the lines in details or consolidated form, depending on the setup for compressing the data for posting.




How to do different configurations for the POS Posting Setup?

The question that has been asked by everyone is what is the best way of doing the POS Posting Setup? Let's have a look at how the system priories the way we configure the POS Posting Setup.

POS Posting Priority Rule



The purpose of the posting setup is to be able to post a payment from the POS on a specific G/L a/c or Bank a/c. There is a flexibility in the way we can set it up. We have to consider the 3 elements:

  • POS Store Code
  • POS Payment Method Code
  • POS Payment Bin Code


The posting setup selection is based on a posting priority rule. There are 3 possible combinations as follows:

1) Full Match – POS Store Code, POS Payment Method Code, POS Payment Bin Code



When we compare the 3 possible examples, this one will have a higher priority as it is more precise than the two others. When we read the setup, we can see that

  • a payment by POS Payment Method = K
  • from the POS Store Code = 1
  • in the POS Unit Payment Bin Code = 1
  • will debit the G/L Account = 2019.


2) 2 constraints – POS Store Code, POS Payment Method Code



This setup is less precise that the one we have in example 1 above. When we read the setup, we can see that

  • a payment by POS Payment Method = K
  • from the POS Store Code = 1
  • in ANY POS Unit Payment Bin Code
  • will debit the G/L Account = 2019.


3) 1 constraint – POS Payment Method Code



This setup is less precise that the one we have in example 1 above. When we read the setup, we can see that

  • a payment by POS Payment Method = K
  • from ANY POS Store Code
  • in ANY POS Unit Payment Bin Code
  • will debit the G/L Account = 2019.


Note that the following possibilities are not supported by the system:

1) 2 constraints – POS Payment Method Code, POS Payment Bin Code



2) 2 constraints – POS Store Code, POS Payment Bin Code



Now that you understand the priority rule, you will need to apply it, based on the requirement of your client.


The following covers the action of receiving Cash as a payment for a sale:

For example, if the client has 1 POS Store, 3 POS Units & only 1 G/L account for POS Payment Method Cash for all POS Units, you can use a simple combination like:

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)


CASH


G/L Account

230450

G/L Account

720700

720700


For example, if the client has 3 POS Store, 3 POS Units & 1 G/L account for POS Payment Method Cash per POS Store, then, it is better to go for a Full Match:

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)

STORE1

CASH

REG1

G/L Account

230450

G/L Account

720700

720700

STORE2

CASH

REG2

G/L Account

230451

G/L Account

720700

720700

STORE3

CASH

REG3

G/L Account

230452

G/L Account

720700

720700


For example, if the client has 1 POS Store, 3 POS Units & 1 G/L account for POS Payment Method Cash per POS Unit, then, it is better to go for a Full Match:

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)

STORE1

CASH

REG1

G/L Account

230430

G/L Account

720700

720700

STORE1

CASH

REG2

G/L Account

230440

G/L Account

720700

720700

STORE1

CASH

REG3

G/L Account

230450

G/L Account

720700

720700


For example, if the client has 1 POS Store, 3 POS Units & 1 G/L account for POS Payment Method Cash per POS Store, then, you can either go for a full match or 1 constraint for the POS Payment Method Code Cash:

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)

STORE1

CASH

REG1

G/L Account

230490

G/L Account

720700

720700

STORE1

CASH

REG2

G/L Account

230490

G/L Account

720700

720700

STORE1

CASH

REG3

G/L Account

230490

G/L Account

720700

720700


POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)


CASH


G/L Account

230490

G/L Account

720700

720700


The Posting Setup is flexible, and it is up to you to define a best fit for your client's requirement.



Different logic of configuration for POS posting setup

We need to consider the following arguments:

1) If we want to send all transaction in ONE G/L account and then on counting, be it real or virtual, we transfer them out into the right G/L Account leaving only Cash in this one G/L account.

This logic being used in our Demo Companies, but it is not practical for a real business. It can be simple for a demo company, but in real life, the client will not like to see all kind of transactions in its CASH a/c. Then move it out of the CASH a/c. There will be too much movements INs & OUTs in the CASH a/c. The client will be completely loss.



Its advantage is simplistic but, it does not make sense in practice to go this way. As the main disadvantage is that we have lots of transactions in the Cash a/c 2915 which does not belong there.


2) Whether the client has only on G/L account for Cash or not, irrespective of whether it is in foreign currency or local currency, then we can send every cash transaction in that one G/L account.

Accounting-wise, it can be done as the G/L account is kept in local currency. But then we lose the ability to revalue the currencies at some stage. The other consideration is whether the client hold Bank Accounts in foreign currencies or not. If the client does not have a foreign currency Bank and keep everything in local currency, then we can put them in one CASH a/c. Otherwise, it is advisable to keep different G/L account for each foreign currency payment methods and it is easier to maintain when we do transfer the currencies in their foreign Bank accounts.
Note:
The payment on POS Unit done in Foreign Currency uses the selling rate defined in the Payment Type for that foreign currency.
Whereas when we transfer the foreign currency from the POS Unit into the foreign bank, the transfer is being done using the Exchange Rate of the day as per Navision multicurrency setup.
At this point, we are already making a margin on the foreign currency transfer to the Bank. And, in Navision, as the reporting currency is in local currency, we can revalue foreign currency amounts for bank account transactions at a certain point to calculate gain or loss on foreign exchange. This practice is more prominent in large organisations. But we have the framework for it.


3) Do we want to update an intermediary G/L account with all transactions other than the counting POS Payment Methods such as Cash and then on the point of doing the Balancing, we transfer the lines using an Auto-Bin and do a virtual counting into a consolidated state into the right account?

This logic can be used if we consider that certain type of transactions are done in details, but when transfer to Bank, they are done in a consolidated line per day. An example can be that Credit Card transactions are done in details on the POS, but at the end of the day, the Bank will be debited with a single amount from the Credit Card company. If we send this as a single amount, it will be easier to perform the Bank Reconciliation. Worse case scenario, we are sending one amount per POS Unit, instead of multiple lines per transactions. This will help in the Bank Reconciliation.


4) The last option is to send the transaction on the right account for the POS Payment Bins on doing the transaction itself. Hence, on doing a payment by Credit Card VISA, the account associated with VISA will be debited when we receive a payment. Same with other POS Payment Bin. No need to have intermediary accounts in between. It is a direct approach.


5) The other factor is we need to consider what kind of compression do we want to achieve for posting?


Posting Compression

There are many settings controlling how the posting compression is selected. The following sections are intended to straighten the line. POS Posting Compression is select at posting time from the entry marked as open in the "POS Period Register List".



The above list is managed by the end-of-day process which closes the period and first login, creates a new entry with status open. Hence if we decide to set the way in which state to post the transactions, it will be after we have closed a period and hence on the next opening the change will applied.

Posting Compression Setup in POS Store for Sales

The POS posting compression is then selected from the POS Store, the POS Unit belongs to:



The options for compression are:

  • Uncompressed
  • Per POS Entry
  • Per POS Period

The "POS Period Register No. Series" is optional for options Uncompressed and "Per POS Entry" posting.
If specified, posting will use this document number when posting to G/L. The actual document number used through-out the period is specified on the "POS Period Register List" which comes from the Cash Register setup if a Sales Fiscal No Series not set.

Method to post

Particulars

Uncompressed

the posting is done in detail, one by one

Per POS Entry

There is more than one line, the posting will be compressed, into lesser lines, which is determined by G/L account, G/L Posting group, Dimension etc.

Per POS Period

The entries within a period (the span of time that a register is opened and then closed) will be compressed based on G/L account, G/L Posting group, Dimension etc.


This means that if we set Automatic POS Posting in NP Retail to After Sale, then the system will automatically post the G/L in an Uncompressed manner, irrespective of what is setup in the POS Store.


Example of uncompressed posting:

Example of compression per POS entry:

Example of compression per POS period:

Posting Compression Setup in POS Payment Method

Payments have not been compressed. There is a setting on the "POS Payment Method" to managed payment compression.


Example of compression per POS period and condensed payment posting:

With a blank posting description:



With a custom posting description

System values can be added to the description according to the following substitutions:

"My Posting Description %1 %2 %3 %4 %5"

  • %1 -> POS Unit No.
  • %2 -> POS Store Code
  • %3 -> Posting Date
  • %4 -> POS Period Register No.
  • %5 -> POS Payment Bin Code
  • %6 -> POS Payment Method Code

Specifying a custom posting description requires the "Post Condensed" to be true.

Posting Compression using an Intermediary A/C and AUTO-BIN

Now, let's have a look at the POS Payment Methods that we want to do an automatic counting at the end of the day when doing the Balancing.

The Virtual-Count will transfer the detailed transactions lines from an initial account into the target account in a compressed format, using an AUTO-BIN. Hence the system is doing a virtual count for us; we do not need to count the POS Payment Method manually as we do for Cash.

We can send the detailed lines in an Intermediary account & then send the compressed line in the right account. Or we can send the detailed lines in the right account and then send the compressed line into BANK to facilitate the bank reconciliation.

Detailed lines in Intermediary account & Compressed in the right account.

Let's take the example that we the detailed lines in an Intermediary account & then send them in the right account. Let's use Gift Vouchers & Credit Vouchers as examples.

Code

Processing Type

Currency Code

Vouched By

Include In Counting

Bin for Virtual-Count

Post Condensed

Rounding Precision

Rounding Type

Rounding Gains Account

Rounding Losses Account

FG

Voucher


Internal

Virtual

AUTO-BIN

No

1,00

Nearest

9150

9150

FT

Voucher


Internal

Virtual

AUTO-BIN

No

1,00

Nearest

9150

9150

G

Voucher


Internal

Virtual

AUTO-BIN

No

1,00

Nearest

9150

9150



POS Posting Setup

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)


FG


G/L Account

2999

G/L Account

8610

8615


FT


G/L Account

2999

G/L Account

8610

8615


G


G/L Account

2999

G/L Account

8610

8615

1

FG

AUTO-BIN

G/L Account

5330

G/L Account

8610

8615

1

FT

AUTO-BIN

G/L Account

5326

G/L Account

8610

8615

1

G

AUTO-BIN

G/L Account

5320

G/L Account

8610

8615

2

FG

AUTO-BIN

G/L Account

5330

G/L Account

8610

8615

2

FT

AUTO-BIN

G/L Account

5326

G/L Account

8610

8615

2

G

AUTO-BIN

G/L Account

5320

G/L Account

8610

8615


In the above settings, we are sending the individual voucher transactions in the Intermediary account 2999 and then re-allocate them in a consolidated format in the right G/L a/c for Vouchers. In this logic, the details will be found in G/L a/c 2999 and the consolidated line in the right account. At the end of the balancing, the Debit Total will equal to the Credit Total in the G/L a/c and hence the intermediary a/c will auto-balance at each balancing process.

I have taken vouchers as an example, but in practice, most of our clients prefer individual lines in the voucher accounts itself so that it is easier for them to reconcile. (This setup will be discussed in the next section).

We might have clients who wants to count the value of the vouchers and balance it with the theoretical expected value. Then we will need to consider the same setup as Cash balancing where we count the cash physically and not a virtual count.

Detailed lines in Right account & Compressed in Bank account.

As we have seen above, the logic of Virtual-Count will transfer the detailed transactions lines from an original account into the target account in a compressed format, using an AUTO-BIN.

Let consider that all payment by credit card goes into a credit card account & then we transfer them a compressed line into the BANK itself or an Intermediary account.
If we choose to send it to our BANK account, the figure will be available for reconciliation.

Code

Processing Type

Vouched By

Include In Counting

Bin for Virtual-Count

Post Condensed

Rounding Precision

Rounding Type

Rounding Gains Account

Rounding Losses Account

MAESTRO DK

EFT

Internal

Virtual

AUTO-BIN

No

1,00

Nearest

9150

9150

MAESTRO UD

EFT

Internal

Virtual

AUTO-BIN

No

1,00

Nearest

9150

9150

T

EFT

Internal

Virtual

AUTO-BIN

No

1,00

Nearest

9150

9150


POS Posting Setup

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)


MAESTRO DK


G/L Account

2345

G/L Account

8610

8615


MAESTRO UD


G/L Account

2346

G/L Account

8610

8615


T


G/L Account

2348

G/L Account

8610

8615

1

MAESTRO DK

AUTO-BIN

Bank Account

MAESTRO DK

G/L Account

8610

8615

1

MAESTRO UD

AUTO-BIN

Bank Account

MAESTRO UD

G/L Account

8610

8615

1

T

AUTO-BIN

Bank Account

DANSKE

G/L Account

8610

8615

2

MAESTRO DK

AUTO-BIN

Bank Account

MAESTRO DK

G/L Account

8610

8615

2

MAESTRO UD

AUTO-BIN

Bank Account

MAESTRO UD

G/L Account

8610

8615

2

T

AUTO-BIN

Bank Account

DANSKE

G/L Account

8610

8615


We can have bank accounts setup for each payment provider (AMEX, VISA etc). It will make the reconciliation way easier or use the BANK account in which the payment provider does the transfer company.

Detailed lines in Right account & Compressed an Intermediary account.

Whereas if we transfer it to an intermediary account, it is at the time of doing the Bank Reconciliation that we transfer it to our BANK.

POS Posting Setup

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)


MAESTRO DK


G/L Account

2345

G/L Account

8610

8615


MAESTRO UD


G/L Account

2346

G/L Account

8610

8615


MAN DAN


G/L Account

2347

G/L Account

8610

8615


T


G/L Account

2348

G/L Account

8610

8615

1

MAESTRO DK

AUTO-BIN

G/L Account

2999

G/L Account

8610

8615

1

MAESTRO UD

AUTO-BIN

G/L Account

2999

G/L Account

8610

8615

1

MAN DAN

AUTO-BIN

G/L Account

2999

G/L Account

8610

8615

1

T

AUTO-BIN

G/L Account

2999

G/L Account

8610

8615

2

MAESTRO DK

AUTO-BIN

G/L Account

2999

G/L Account

8610

8615

2

MAESTRO UD

AUTO-BIN

G/L Account

2999

G/L Account

8610

8615

2

MAN DAN

AUTO-BIN

G/L Account

2999

G/L Account

8610

8615

2

T

AUTO-BIN

G/L Account

2999

G/L Account

8610

8615


Accounting Setup for POS Payment Methods not included in counting process

Let's relook at the example of Gift Vouchers & Credit Vouchers. If we are not required to count the vouchers, let we can just send them into the right accounts in details.

Code

Processing Type

Currency Code

Vouched By

Include In Counting

Bin for Virtual-Count

Post Condensed

Rounding Precision

Rounding Type

Rounding Gains Account

Rounding Losses Account

FG

Voucher


Internal

No


No

1,00

Nearest

9150

9150

FT

Voucher


Internal

No


No

1,00

Nearest

9150

9150

G

Voucher


Internal

No


No

1,00

Nearest

9150

9150


POS Posting Setup

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)


FG


G/L Account

5330

G/L Account

8610

8615


FT


G/L Account

5326

G/L Account

8610

8615


G


G/L Account

5330

G/L Account

8610

8615


Accounting Setup for Different Currencies when counting

POS Payment Method:

Code

Currency Code

Vouched By

Include In Counting

Bin for Virtual-Count

Post Condensed

Rounding Precision

Rounding Type

Rounding Gains Account

Rounding Losses Account

EURO

EUR

Internal

Yes


No

1,00

Nearest

9150

9150

GBP

GBP

Internal

Yes


No

1,00

Nearest

9150

9150

K


Internal

Yes


No

1,00

Nearest

9150

9150

NOR

NOR

Internal

Yes


No

1,00

Nearest

9150

9150

SEK

SEK

Internal

Yes


No

1,00

Nearest

9150

9150

USD

USD

Internal

Yes


No

1,00

Nearest

9150

9150


As these currencies are being counted in their own currency, the POS Bins will keep them in their respective currencies, whereas on G/L the will be in LCY. We could use only one G/L account, but we will have a mix currencies equivalent in it.

We would advise the client to have separate G/L accounts for them, where it can be monitored separately.

The logic will be that when we do sales, we cash the currencies in a POS Bin and when transfer to BANK or SAFE, we remove the currencies from the POS Bin. As such, what is left is the actual float of the day.

And, as we define individual G/L a/c for each currency, we target to have the balance in each G/L a/c representing the total float of the organisation for that currency.

If we want to have more precision, then we can define a G/L a/c for each currency of each POS Unit. But this will be an extreme way of configuring the POS Posting Setup. Nevertheless, as the Posting Setup is flexible, it can be achieved if a client wishes for it.

A good approach will be to have one G/L a/c per currency and not per POS Unit & Currency.

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)


EURO


G/L Account

2910

G/L Account

8610

8615


GBP


G/L Account

2911

G/L Account

8610

8615


K


G/L Account

2912

G/L Account

8610

8615


NOR


G/L Account

2913

G/L Account

8610

8615


SEK


G/L Account

2914

G/L Account

8610

8615


USD


G/L Account

2915

G/L Account

8610

8615

1

EURO

BANK

Bank Account

EURO

G/L Account

8610

8615

1

EURO

SAFE

G/L Account

2980

G/L Account

8610

8615

1

GBP

BANK

Bank Account

GBP

G/L Account

8610

8615

1

GBP

SAFE

G/L Account

2980

G/L Account

8610

8615

1

K

BANK

Bank Account

DANSKE

G/L Account

8610

8615

1

K

SAFE

G/L Account

2910

G/L Account

8610

8615

1

NOR

BANK

Bank Account

NOR

G/L Account

8610

8615

1

NOR

SAFE

G/L Account

2980

G/L Account

8610

8615

1

SEK

BANK

Bank Account

SEK

G/L Account

8610

8615

1

SEK

SAFE

G/L Account

2980

G/L Account

8610

8615

1

USD

BANK

Bank Account

USD

G/L Account

8610

8615

1

USD

SAFE

G/L Account

2980

G/L Account

8610

8615

2

EURO

BANK

Bank Account

EURO

G/L Account

8610

8615

2

EURO

SAFE

G/L Account

2980

G/L Account

8610

8615

2

GBP

BANK

Bank Account

GBP

G/L Account

8610

8615

2

GBP

SAFE

G/L Account

2980

G/L Account

8610

8615

2

K

BANK

Bank Account

DANSKE

G/L Account

8610

8615

2

K

SAFE

G/L Account

2910

G/L Account

8610

8615

2

NOR

BANK

Bank Account

NOR

G/L Account

8610

8615

2

NOR

SAFE

G/L Account

2980

G/L Account

8610

8615

2

SEK

BANK

Bank Account

SEK

G/L Account

8610

8615

2

SEK

SAFE

G/L Account

2980

G/L Account

8610

8615

2

USD

BANK

Bank Account

USD

G/L Account

8610

8615

2

USD

SAFE

G/L Account

2980

G/L Account

8610

8615


You can have more precision for one POS Unit per POS Store:

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)

1

EURO

REG1

G/L Account

2910

G/L Account

8610

8615

1

GBP

REG1

G/L Account

2911

G/L Account

8610

8615

1

K

REG1

G/L Account

2912

G/L Account

8610

8615

1

NOR

REG1

G/L Account

2913

G/L Account

8610

8615

1

SEK

REG1

G/L Account

2914

G/L Account

8610

8615

1

USD

REG1

G/L Account

2915

G/L Account

8610

8615

2

EURO

REG2

G/L Account

2910

G/L Account

8610

8615

2

GBP

REG2

G/L Account

2911

G/L Account

8610

8615

2

K

REG2

G/L Account

2912

G/L Account

8610

8615

2

NOR

REG2

G/L Account

2913

G/L Account

8610

8615

2

SEK

REG2

G/L Account

2914

G/L Account

8610

8615

2

USD

REG2

G/L Account

2915

G/L Account

8610

8615

2

EURO

BANK

Bank Account

EURO

G/L Account

8610

8615

1

EURO

SAFE

G/L Account

2980

G/L Account

8610

8615

1

GBP

BANK

Bank Account

GBP

G/L Account

8610

8615

1

GBP

SAFE

G/L Account

2980

G/L Account

8610

8615

1

K

BANK

Bank Account

DANSKE

G/L Account

8610

8615

1

K

SAFE

G/L Account

2910

G/L Account

8610

8615

1

NOR

BANK

Bank Account

NOR

G/L Account

8610

8615

1

NOR

SAFE

G/L Account

2980

G/L Account

8610

8615

1

SEK

BANK

Bank Account

SEK

G/L Account

8610

8615

1

SEK

SAFE

G/L Account

2980

G/L Account

8610

8615

1

USD

BANK

Bank Account

USD

G/L Account

8610

8615

1

USD

SAFE

G/L Account

2980

G/L Account

8610

8615

2

EURO

BANK

Bank Account

EURO

G/L Account

8610

8615

2

EURO

SAFE

G/L Account

2980

G/L Account

8610

8615

2

GBP

BANK

Bank Account

GBP

G/L Account

8610

8615

2

GBP

SAFE

G/L Account

2980

G/L Account

8610

8615

2

K

BANK

Bank Account

DANSKE

G/L Account

8610

8615

2

K

SAFE

G/L Account

2910

G/L Account

8610

8615

2

NOR

BANK

Bank Account

NOR

G/L Account

8610

8615

2

NOR

SAFE

G/L Account

2980

G/L Account

8610

8615

2

SEK

BANK

Bank Account

SEK

G/L Account

8610

8615

2

SEK

SAFE

G/L Account

2980

G/L Account

8610

8615

2

USD

BANK

Bank Account

USD

G/L Account

8610

8615

2

USD

SAFE

G/L Account

2980

G/L Account

8610

8615


You can have one POS Store & multiple POS Units:

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)

1

EURO

REG1

G/L Account

2910

G/L Account

8610

8615

1

GBP

REG1

G/L Account

2911

G/L Account

8610

8615

1

K

REG1

G/L Account

2912

G/L Account

8610

8615

1

NOR

REG1

G/L Account

2913

G/L Account

8610

8615

1

SEK

REG1

G/L Account

2914

G/L Account

8610

8615

1

USD

REG1

G/L Account

2915

G/L Account

8610

8615

1

EURO

REG2

G/L Account

2910

G/L Account

8610

8615

1

GBP

REG2

G/L Account

2911

G/L Account

8610

8615

1

K

REG2

G/L Account

2912

G/L Account

8610

8615

1

NOR

REG2

G/L Account

2913

G/L Account

8610

8615

1

SEK

REG2

G/L Account

2914

G/L Account

8610

8615

1

USD

REG2

G/L Account

2915

G/L Account

8610

8615

1

EURO

BANK

Bank Account

EURO

G/L Account

8610

8615

1

EURO

SAFE

G/L Account

2980

G/L Account

8610

8615

1

GBP

BANK

Bank Account

GBP

G/L Account

8610

8615

1

GBP

SAFE

G/L Account

2980

G/L Account

8610

8615

1

K

BANK

Bank Account

DANSKE

G/L Account

8610

8615

1

K

SAFE

G/L Account

2910

G/L Account

8610

8615

1

NOR

BANK

Bank Account

NOR

G/L Account

8610

8615

1

NOR

SAFE

G/L Account

2980

G/L Account

8610

8615

1

SEK

BANK

Bank Account

SEK

G/L Account

8610

8615

1

SEK

SAFE

G/L Account

2980

G/L Account

8610

8615

1

USD

BANK

Bank Account

USD

G/L Account

8610

8615

1

USD

SAFE

G/L Account

2980

G/L Account

8610

8615


POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)


EURO


G/L Account

2910

G/L Account

8610

8615


GBP


G/L Account

2911

G/L Account

8610

8615


K


G/L Account

2912

G/L Account

8610

8615


NOR


G/L Account

2913

G/L Account

8610

8615


SEK


G/L Account

2914

G/L Account

8610

8615


USD


G/L Account

2915

G/L Account

8610

8615

1

EURO

BANK

Bank Account

EURO

G/L Account

8610

8615

1

EURO

SAFE

G/L Account

2980

G/L Account

8610

8615

1

GBP

BANK

Bank Account

GBP

G/L Account

8610

8615

1

GBP

SAFE

G/L Account

2980

G/L Account

8610

8615

1

K

BANK

Bank Account

DANSKE

G/L Account

8610

8615

1

K

SAFE

G/L Account

2910

G/L Account

8610

8615

1

NOR

BANK

Bank Account

NOR

G/L Account

8610

8615

1

NOR

SAFE

G/L Account

2980

G/L Account

8610

8615

1

SEK

BANK

Bank Account

SEK

G/L Account

8610

8615

1

SEK

SAFE

G/L Account

2980

G/L Account

8610

8615

1

USD

BANK

Bank Account

USD

G/L Account

8610

8615

1

USD

SAFE

G/L Account

2980

G/L Account

8610

8615


If we think about it, it does not mean that a configuration in one organisation, will fit another one. We need to understand each organisation's requirement & then configure the POS Posting Setup.


The logic will be how do we want to post the transactions of various POS Payment Methods.

Additional Setup to cater for transfers between POS Payment BINS in the Cash Register Setup

There are two configuration that we need to pay attention to:

  • The field Registerstatement must be set to "Manual".
  • The G/L in the field Rounding must have a value.

The rest of the fields are not used by POS Entry Routine. This setup is temporary. We will move them away from Cash Register in the future.

Note: In the future, we will move these setups away from Cash Register to POS Payment Methods & POS Bins.

Accounting Setup for Transfer to BANK & SAFE

The POS Payment Bin for BANK will have a specific account. Hence if the define a EURO Bank, where we transfer EURO into it, then we will have a BANK POS Payment Bin called EURO.

This BIN will be linked to our EURO BANK. (The Bank Account Posting Group will define which G/L account is attached to it). This Bank A/C will be debited when receiving the currency.

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)

2

EURO

BANK

Bank Account

EURO



8610

8610


The POS Payment Bin for SAFE can be a G/L account and not necessarily a BANK account as we do not have Bank Reconciliation to do in this case. It is a physical Safe and we track the transfers into our accounting on that G/L account. Hence, if the EURO is transfer into the SAFE, the A/C 2980 will be debited.

Transferring into SAFE

POS Store Code

POS Payment Method Code

POS Payment Bin Code

Account Type

Account No.

Difference Account Type

Difference Acc. No.

Difference Acc. No. (Neg)

2

EURO

SAFE

G/L Account

2980



8610

8610


The POS Payment Bin for AUTO-BIN can be a G/L account for that POS Payment Method. And hence we track the transfers into our accounting on that G/L account. Hence, if the MAESTRO DK is transfer by AUTO-BIN, the A/C 2345 will be debited. If we use a BANK account for the credit card MAESTRO DK, the we can configure it as a BANK instead

Conclusion on POS Posting Setup

You need to consider the priority logic as well as what kind of posting routine you want each individual POS Payment Method to do in order to optimise your POS Posting Setup.

For example, for Cash & most of the POS Payment Bins, we might consider a direct approach and set the posting setup directly on the right account.

For Gift Voucher & Credit Voucher, we might need an intermediary account to get all details in it & then a compressed posting onto the right G/L account.

For Credit Card, we might have a different Customer Accounts instead of G/L account. Or we can have an intermediary account and then post it compressed into a Bank Account.

This type of discussion needs to be taken in advance with our client before implementation. As the system is flexible, there is no right or wrong way of doing the posting.

POS Menus Setup

POS Action BIN_TRANSFER

The next configuration that we should understand is what triggers which account is Debited & which account is credited when doing a transfer. This is in parameters of the POS Action BIN_TRANSFER.


We set the following actions for the Transfers:

Transfer out of Register - we set the parameters on the POS Action BIN_TRANSFER as follows:
Name            Data Type                Value
SourceBin      Text
SourceBin      SelectionOption      PosUnitDefaultBin

The PosUnitDefaultBin means that it will use the POS Payment Bin Code associated with the POS Unit. Hence, it will Credit the A/C Code of the Register and Debit the A/C of the BIN to which we are transferring the amount.

Transfer out of Safe - we set the parameters on the POS Action BIN_TRANSFER as follows:

Name          Data Type               Value
SourceBin   Text                         SAFE
SourceBin   SelectionOption     FixedParameter

The FixedParameter means that we are defining which POS Payment Bin is being used as the source for the transfer. In this case, it will use the A/C Code associated with the POS Payment Bin Code = SAFE. Hence, it will Credit the SAFE A/C and Debit the A/C of the BIN to which we are transferring the amount.

Transfer out of Bank - we set the parameters on the POS Action BIN_TRANSFER as follows:

Name           Data Type               Value
SourceBin    Text                         BANK
SourceBin     SelectionOption     FixedParameter


The FixedParameter means that we are defining which POS Payment Bin is being used as the source for the transfer. In this case, it will use the A/C Code associated with the POS Payment Bin Code = BANK. Hence, it will Credit the BANK and Debit the A/C of the BIN to which we are transferring the amount.

POS Action BALANCE_V3

Balance V3 - (X-Report) - we set the parameters on the POS Action BALANCE_V3 as follows:

Name       Data Type    Value
Security    Text              None
Type         Option          X-Report (prel)

The Security parameter is not used anymore. As we have developed security based on the POS Menus itself and not the POS Button as it was previously.

Balance V3 - (Z-Report) - we set the parameters on the POS Action BALANCE_V3 as follows:

Name            Data Type         Value
Security         Text                   None
Type              Option              Z-Report


The Security parameter is not used anymore. As we have developed security based on the POS Menus itself and not the POS Button as it was previously.

Balance V3 - (Z-Report) - we set the parameters on the POS Action BALANCE_V3 as follows:

Name                Data Type            Value
Security             Text                      None
Type                  Option Close       Workshift

The Security parameter is not used anymore. As we have developed security based on the POS Menus itself and not the POS Button as it was previously.

Note: The POS Action Balance V3 is explained in the End Of Day Process section below.

POS Action PRINT_RECEIPT

A new POS Action has been created and will be release in NPR 5.51. This button will display the sales ticket as well as the balancing ticket from the POS (Case 353191)

POS Action RUNPAGE for POS Entry List

We can also use the generic POS Action RUNPAGE to show pages from POS. The page number for "POS Entry List" is 6150652.