Seitenvergleich

...

Sending salary documents includes the following main characteristics:

• User will be managed from the partner

• Documents must be sent to specific user only

• Documents will be imported as files

• preferred: User will be managed from the partner

The sent data is personal data. As hotelkit does not need the information itself, it has to be ensured, that the documents are encrypted before imported to hotelkit.

Functionality

push user

...

list user

The partner needs to know the available user users from hotelkit to send them their information.

...

This is the functionality to import the documents. For each recipient an individual message will be created to make sure documents are only available for the intended persons.

optional: push user

As the user data is managed within the partner system and it must be ensured that the user is available in hotelkit, the partner will be granted the functionality userPush to suggest new user in hotelkit.

Request Types

It is suggested to create an individual request type for every type of document, the partner wants to import. This way the customer is enabled to set custom settings within hotelkit for each document type.

...

PUT /setup/partner
{
    "userSync":{
        "regEx":"^(\d{3}_\d*)(,\d{3}_\d*)*$",
        "examples":[
            "123_00025","123_12345,045_58975"
        ],
        "errorMessage":{
            "de_DE":"Personalnummern müssen dem Format XXX_XXXXX entsprechen",
            "en_US":"personnel numbers must be given in the format XXX_XXXXX"
        }
    }
}

Daily Routine

The routine will be described with the preffered option that the partner manages the users.

Before updating & making suggestions for users in hotelkit, clearly a partner has to load the available users from hotelkit. If the customer is new, the partner should check whether there is another customer-key that is better suited for getting all information about the users.

...

Header x-hotelkit-customer-key: demo1
GET /users

> 200
[
   { //complete data set + vowels in name
      "ID": "16",
      "clientID": "123_01425"null,
      "givenName": "Hans Peter",
      "surName": "Müller",
      "loginName": "u12345",
      "birthDate": "24.12.2019",
      "email": "user@example.com",
      "customerList": ["demo1","demo2"]
   },
   {  //only required information + vowels in name
      "givenName":"Hans Peter",
      "surName":"M\00DCller",
      "customerList":["demo1"]
   }
]

...

As there is no clientID given for user 16, the partner should update this user. Either the user can be matched – the user then will be sent at resolvedvia PUT /users/{ID}, or the matching is unclear , and the user is listed as unresolved: The and no action is taken fromt he partner.

In hotelkit the clientID will be validated against the inserted regular expression before set to the user.

PUT /users/16 
{
    "ID": "16"
    "clientID":"123_258"
    .... //more fields
}

Request Import

When a user could be matched between both systems he can be adressed in the message import.

POST https://api.hotelkit.net/requests?type=salary
{
    "title":"June 2022",
    "recipientList":[
        "16" //user.ID
    ],
    "attachements":[
        {
            "fileName":"test.txt",
            "mimeType":"text/plain",
            "base64":"TW9pbiBNb2luIQ=="
        }
    ]
}