EverEST FAQ

EverEST FAQ

This page contains some frequently asked questions concerning EverEST functionality.

CREDIT CARDS HANDLING
Q	Does register have integrated Credit Card handling?
A	At the moment the system handles the credit cards with and without the real connection with a bank. EverEST supports different EFT systems in the following countries: Sweden, Norway and Italy. MPS is committed to build any EFT solution based on the customer request.

Q	Can Credit Card transactions be referred to a central authorization server in the store?
A	We have already developed a similar system where the POS requires an authorization to a server in the local network. Implementing this functionality in EverEST is in plan

Q	How is this achieved?
A	The POS will issue a request to the server and an answer is required to this request by the POS. In Windows POS will issue a TCP/IP request to the server

Q	What would be involved in accepting cards with Track 2 data not conforming to ISO standards?
A	We support reading the track 2. It depends whether the MSR device you have does support reading this trace. It will be useful if you can provide us one of these cards for testing purposes.

Q	Can the register process credit cards in OFF LINE mode i.e. when operating while not on any network?
A	It is necessary to verify the checks the POS have to perform. If the check consists in verifying the presence of this CC in the black list, it is not a problem

Q	In this situation what provision is there for a local hot list on the register?
A	If the POS are equipped with a local disk then all the sales functions will be available locally. The only check we can do in this case is to verify whether the current credit card is in the black list.

Q	Is there a limit to the number of cards in this hot list?
A	Supporting up to 150,000 cards should not be a problem

SCANNING
Q	How many PLU items can the system store?
A	The limit is given by the RDB. Let’s say that holding up to 500.000 items should not be a problem. We have done some performaces tests with this huge number of items with very good results.

Q	How many registers can a PLU server support?
A	The PLU is done locally on the POS unless there is a PLU download from the server. The bottle neck in limiting the PLU access is the network. A good network virtually supports unlimited PLU access (the PLU information is not huge)

Q	How many different sell prices are possible for each PLU?
A	Today we support multiple prices. We can have multiple promotions (not just one) associated to specific customers. In addition it is possible to define different item prices based on the POS number and on the customer type (I.E. senior customers)

Q	Is there a search function by product description on the register?
A	For the DOS version this is not foreseen. For the NT version is not currently implemented but it is not a problem to do it

Q	Is the register capable of storing some or the entire PLU file locally?
A	The POS holds locally (if it is equipped with a local disk) the complete set of data necessary for the sales operations. This means that the POS can work offline with very few limitations (suspend/resume, end of day close etc.)

Q	Can the PLU file be modified / updated while registers are in use?
A	This feature is included in the base product. The PLU change will be automatically dispatched to all the POS and the change can be applied while a POS is within a transaction (price consistency in the current transaction) or just after the transaction is completed

Q	Does the system report numbers of barcodes scanned that were not found in the PLU file?
A	There is a report displaying all the sales exceptions. Some of them are: Item not found Manual price override Manual transaction discount

MISCELLANEOUS
Q	Does the register require a mouse?
A	The DOS version does not require any other device than the standard used by the POS (scanner, msr, etc). For the Windows version it is not mandatory because all the POS functions can be accessed only with the keyboard

Q	What network typology and protocols are normally used?
A	We support the 2 main networks today used in a PC LAN; Ethernet and Token Ring. In our lab we have both these networks connected to the server with no problem

Q	Do you recommend that the EPOS system is the only system on the network or network segments that it is using?
A	This is not mandatory (our lab is wired and uses IP addresses as the rest of the office LAN). Of course, having a different IP address for the EPOS system is recommended in order to insulate the traffic between LANs.

Q	In the event of sudden power loss to the register will the register application restart without attention from support staff?
A	The POS will restart with no intervention by the user. If the server is not in the network, then the POS will automatically switches in the offline mode (it will return online as soon the server is back)

Q	In the event of a register becoming disconnected from the network does the register have to be restarted to resume network functions when the network is restored?
A	If the network used is the Ethernet, no manual intervention is required (unless the cable is physically disconnected).

Q	What languages / development tools have been used to create the register application?
A	The POS DOS version has been developed by using Microsoft C (JAVA VM) and Microsoft J++ compiled with SUN Java for the application. For Windows NT, Visual C++ and Microsoft J++ compiled with SUN Java for the application.

Q	What is the minimum spec recommended to run the register application?
A	For DOS, the minimum HW required is a 486 66Mhz with 4MB ram. For Windows NT, it is the minimum recommended by Microsoft (Pentium 75, with 16 MB RAM). We anyway suggest to have a Pentium 133 with 64MB RAM

Q	What support/configuring functions on the registers can be done remotely?
A	All the configuration function can be done from the server. I.E. changing a PLU, changing the POS options, changing the POS functionality etc.

To return to the main page, click here.

Best viewed with IE 5.x, Mozilla 1.7 or higher