RCScash is a software that acts between the cash drawer and the point of sale software, so that we consult the data at the origin of the sales, analyze them, show their sale to make their payment and store their result.

It must be emphasized that RCScash is not only an integration solution between the different cash control machines and the establishment’s sales control, RCScash intends, through various mechanisms, to stop fraud in establishments.

RCScash can be integrated by different methods. Each one of them is completely valid for a pure integration, but it must be kept in mind that, depending on the method used, we will lose robustness, reading the database being the best of all.

Our software collects the sales made every 3 seconds (configurable), comparing the differences and collecting only the sales that have not been previously collected.

We have several methods to carry out the integrations:

  • Database reading
  • Writing in our database
  • files
  • TCP/IP socket

Database reading

The client must create a user of the POS database that only has read permission and that shows us which are the sales tables, vendors, counters, and companies. With that user, we will perform the integration. We also give the option for the client to create views of the POS database with the tables mentioned above. The POS developer must specify what type of database engine is being used (MySQL, SQLServer, Access…), as well as the connection protocol (TCP/IP, ODBC…) and any necessary parameters, outside of the standard for your connection.

The data we need to read from the database is:

  • Ticket number
  • Date and Time
  • Total
  • User
  • Counter
  • Cash or card
  • Company or activity (not necessarily strict)

It is the method that we recommend the most, by giving us the reading of the database, we can guarantee the complete operation of RCScash, making a fast, simple and secure integration.

Writing in our database

In our database engine, the POS can write or make a copy of all POS sales transactions. This option is valid if the developer does not want to provide data from his connection or the database engine he uses is not standard and he prefers to write this data in our DBMS engine.

In this case you can configure our database for full access and create a database in our MySQL similar to this, although you can also use SQLServer or Access.

In our database engine, the POS can write or make a copy of all POS sales transactions. This option is valid if the developer does not want to provide data from his connection or the database engine he uses is not standard and he prefers to write this data in our DBMS engine.

In this case you can configure our database for full access and create a database in our MySQL similar to this, although you can also use SQLServer or Access.

SALES TABLE

  • id varchar (30) PK[code]
  • Date timestamp – accurate to seconds[datetime_totalized]
  • Enterprise integer (11)[fk_pos]
  • Seller integer (11)[fk_cashier]
  • Full counter (11)[fk_company]
  • Amount integer (11) –[amount]what is collected in cash (preferably in cents)
  • Type integer (1) –[sale_type]0 if it is a card, 1 if it is cash

SELLERS TABLE

  • Id integer (11) PK[id_cashier]
  • Name varchar (250)[cashier]

TABLE OF COUNTERS

  • Id integer (11) PK[id_pos]
  • Name varchar (250)[pos]

TABLE OF COMPANIES

  • Id integer (11) PK[id_company]
  • Name varchar (250)[company]

files

The client is the one who writes to us and sends us files of any format (txt, xml, json…) optionally using AES 256 encryption.

For this method, you need a shared folder on the network, which has full permissions for both RCScash and the POS, in terms of creation, modification and deletion.

If the files are txt, in which there will be a single line indicating the operation in question with the following format (separated by «;»).

(Amount); (Nº POS/BOX); (Invoice/Ticket Number); (User Number/Name); (Date and Time); ((0 if the payment was made by card)/(1 if the payment was made with cash)).

Depending on the type of transaction it is, the name of the file will change.

Example:

Sale made by Carlos for €1, at the MOST2 counter at 12:12:25 on January 1, 2017. The ticket number is 12345 and has been paid with cash:

– V12345.txt>>1, 00; MOST2; V12345; CARLOS; 2017-01-01 12:12:25; 1

Refund (or credit) made by Javier of -1€, at the MOST1 counter at 15:15:25 on January 1, 2017. The ticket number is 12346 and has been paid by card:

– V12346.txt>>1, 00; MOST1; V12346; JAVIER; 2017-01-01 15:15:25; 0

When RCScash starts, it will read the pending files and load them. When the sales have been paid, it will delete the files and create another one with the response of the transaction (whether it was successful or not).

Example:

Successful transaction:

– V12345.txt>>OK

Unsuccessful transaction:

– V12345.txt>>KO

TCP/IP socket

RCScash will work as a server and will receive payments from the different POS in the establishment. In the event that RCScash is turned off, the transaction made will not appear anywhere, and therefore, it will be lost.

In any case, to carry out this type of integration, the client will send us a Socket with a single line, the same as that of the txt files.

It is the method that we least recommend.

To send a transaction to RCScash this string will be sent:

NEW TRANSACTION

– DATA;{ID_TRANSACTION};{SALESMAN};{POS};{AMOUNT};{TYPE}

  • ID_TRANSACTION
    • It is the identifier of the transaction.
  • SALESMAN
    • It is the name of the seller.
  • POS
    • It is the name of the Point of Sale (Terminal).
  • AMOUNT
    • Is the transaction amount (integers).
  • TYPE
    • It is the type of transaction.
      • 0 = Card
      • 1 = Cash
  • Examples
    • DATA;V000001;CARLOS;P1;120;1
      • Transaction V000001 created by Carlos in POS P1, amount €1.20 in cash
    • DATA;V000002;JAVIER;P2;565;0
      • Transaction V000002 created by Javier in POS P2, amount €5.65 in card

CANCEL: (POS-side)

– DATA;{ID_TRANSACTION};{CANCEL}

RESPONSE: (RCScash-side)

– DATA;{ID_TRANSACTION};{CODE}

  • ID_TRANSACTION
    • It is the identifier of the transaction.
  • code
    • The response code (see code table):
    • If the code is [000] the transaction is ok, otherwise there is an error.
FIELD CODEDESCRIPTION
SUCCESS000The operation was carried out successfully.
PAID001The operation is paid.
ERROR_UKNOWN999The operation failed for a reason not

specified above.

The error message field can be

checked for more information.
ERROR_TICKET_ID101The number of entries is empty or has
special characters.
ERROR_TICKET_TYPE104The ticket type is different from 0 or 1.
ERROR_TICKET_CASHIER105Cashier name is empty or has
special characters.
ERROR_TICKET_POS106The device cashier name is empty
or has special characters.
ERROR_TICKET_AMOUNT107Total amount is empty or not a number.
ERROR_TICKET_DUPLICATED108This operation is already in the CI database
running or finished.
ERROR_TICKET_NOT_EXISTS109The Requested Ticket does not exist.
Scroll al inicio