All support articles using ASQL are written in German language. We recommend using a standard website translating tool to read our support articles in your native language.

For better understanding, here are some basic principles and the reference to our postman documentation.


please switch to the actual TPAPI web request adress:
https://api.lina.de/ ...


understanding LINA

LINA Teamcloud is the web component of LINA where all interface requests connect to LINA Third Party API (TPAPI)

LINA manages all data synchronisation between Cloud and LINA POS server on premise.

LINA tunnels all POS request for article ordering and payment. To use the full functionality of LINA POS please refer to the /command call which tunnels the whole set of ASQL instructions to the POS server in the restaurant.

prerequisites

necessary endpoints must be licensed and a client for data interchange must be configured. For the use of POS functionality like order and pay, the configuration of a "webkasse" is mandatory

using the interface

authentication

Accessing resources of LINA third party API (TPAPI) is permitted by the data owner (login) . Data transfer is either secured by successful authentication with one of the methods OAuth or API-key.

Operator-ID

For partners we recommend the use of an operator-ID to make integration easier and to have more control about data access rights,

Postman documentation

Please refer to our postman reference: Third-Party-API Postman Dokumentation

interface development environment

We strongly recommend using a separated system for development and integration tests. Please order a training for partners inside LINA TeamCloud. A fully configured environment is included.

ratelimit

A ratelimit of 100 data-requests per store within 15 minutes is set. Threshold is calculated as moving sum. All requests in the last 15 min are summed up and are limited to 100.
Exceeding requests will be responded with a block by our firewall. Error message exceeding the threshold is a HTTP-Code 429, status: error, message: "API-Calls exhausted: 100 Calls per 15 minutes". Authentication is not affected.

The ratelimit can be increased by booking LINA POS API Webkasse multiple times.

operator ID, client and tokens - OAuth

a short explanation of operatorID, client and tokens

  1. Inside LINA/Einstellungen/Third Party API/Clients you are able to manually create clients for your data flow.
    Setting Titel (name), Weiterleitungs-URI (URL of your system) and Rechte (checkboxes with rights on endpoints).  A clientID and Geheimer Schlüssel (secret) is displayed.
  2. now OAuth2 Hybrid Flow (auth0.com) and a similar graph of openID
    only for the first connect you need to use clientID and secret, a user login box pops up. Logging in returns the authcode which you use for creating first access token
  3. OAuth circle
    From there you start the circle with access and refresh tokens
  4. Oauth for Dev
    If you want to access the client for dev, the other tab enables you to manually generate a refresh token with time restricted validity
operator ID replaces step 1. and integrates step2. : instead of manually creating a client the operator ID sets the respective parameters. The response contains client ID and secret as well as authcode


several endpoints “Endpunkte”

Several endpoints “Endpunkte” in TPAPI to access LINA data:

  • “Webkasse-POS” Point of sales: ordering, table and takeaway management, menu and tender, payment, tax, bill
     this is done using our ASQL (Amadeus SQL) instructions
  • “Artikelstammdaten” is everything about menu articles including price, pricelevel, taxlevel, site, selling point, availability, ingredients, recipe, salescost and so on
    this is the area where inventory or merchandise management take control
  • “Umsatz”: revenue , the daily journal. All articles, all areas, all timeslots, all selling points
  • “Personal” efficiency by number of service personnel
  • “BWA” all the accounting  stuff
  • “Taxonomie” for uploading full sets of taxonomy data according to german KassenSichV (TSE stuff
  • “Gutschein” to sell, check and redeem vouchers

 

Security is managed on several levels

  • OAuth for this REST API internet access
  • Redirect URI in the configuration of endpoints in LINA and read/write permission to set for each
  • Data access with permissions of a named user in LINA

 


Extensive information about accessing data stored in LINA for inventory management & sales analytics
In LINA we report data in two different journals

POS-journal containing all articles booked on a table which you later can find as lines on the receipt/invoice

  • Article with PLU number, text, count, discount, balance, single price, vat, finance type (revenue, cancellation, discount, …). 
  • Optional site (profit center), terminal, pricelevels, discount (promotion, time based..)Optional site (profit center), terminal, pricelevels, discount (promotion, time based..)
  • inhouse/takeaway for accounting with different taxes
  • Payment balance, type (cash, cards, credit, voucher,…)
  • restaurant service with waiter/waitress
  • dates&counter contain orderdate, businessdate and z-counter and unique ID


table journal ("Tischjournal", equivalent bill journal) with head data for a bill with the corresponding unique tableheader_ID

  • table type and number, splitting reference
  • dates&billing: business day and date&time of bill,  bill number, sums of different vat and the waiter/waitress
  • persons: debitor and for additional use reservation and number of adults/kids


article master data ("Stammdaten") combines basic article data and data for accounting

  • product category ("Sparten") which LINA separates main/standard/detail ("Hauptsparte/Sparte/Feinsparte")
  • Optional:
    • main articles may have tenders or extras
    • course menus may have different calculation of taxes depending on requirements of accounting
    • description, pictures and data about allergens and ingredients
    • active/inactive, availabilities, numbers in stock
    • MEC data is just for grouping the articles in the POS
    • recipes, vendors, costs of production


service personal data to calculate and transfer service tip tax free

  • Name, Address, Tax-ID
  • shift plan


splitting multiple counts of one PLU

read   tabledata.compressed.infos 

  • article.count [int]  (number of same PLU on this table
  • tabledata.id [int] (“main-id”, only representing one singular id)
  • tabledata.compressed.infos {array[text]}   (containing the other tabledata.id ‘s)

split the “main-id” to another table, one of the remaining tabledata.id is moved  to “main” 

 

Example: 

you book PLU40 article  5  pieces  on table splittable_A

  • article.count = 5
  • tabledata.id = 1111
  • tabledata.compressed.infos  is empty

 additionally book PLU40 one time and another one and another two

  • article.count = 9
  • tabledata.id = 1111
  • tabledata.compressed.infos  = 4x1111;1x1112;1x1113;2x1114

tabledata  sum is now 5x1111;1x1112;1x1113;2x1114 

 

split PLU40  eg 6 times 

splittable_A remains

  • article.count = 3
  • tabledata.id = 1113
     the list shifted “6 positions” to 1113
  • tabledata.compressed.infos  = 2x1114

Splittable_A.1 receives

  • article.count = 6
  • tabledata.id = 1111
  • tabledata.compressed.infos  = 4x1111;1x1112

 

sum splittable_A + splittable_A.1 is as expected    5x1111;1x1112;1x1113;2x1114

 

To split a table you pick tabledate.id on your choice. The selected move, the others stay.