List of source systems

All these articles reside within the knowledge base.

Monitor Incoming data – Import status

About

Import Status is used to get an overview of your properties´ daily imports from your source systems (PMS, POS, Timekeeping etc). The main features of this module include:

  • Detecting data that has not been updated in PMI e.g data missing for the property and various options for handling it depending on what sort of data it is.
  • Viewing imported data to PMI. As a user, you can no use our drill-down feature to view what was imported to PMI, and see what accounts are connected to the figure. This way you can check what we received and what the output in PMI was.
  • An overview of active interfaces PMI uses to import data to your property.

Intended Users

All users with Administrator, or Controller rights have access to this module.

Instructions

  1. Breadcrumb menu – Chain is by default the chain you have access to and can not be changed.
  2. Property will display the properties you have access to, that have the status you have selected in the menu, in this case “not updated in PMI”. Properties with missing data will show if you have access to more than one.
  3. Refresh Table – You can click this to refresh the table and get the latest update. If you know an interface has been updated refresh the table and the line should disappear, It will now be under the option “Updated in PMI”.
  4. Actions – Depending on how we collect the data for the interface showing you will have different options. See the actions listed below.

4.1 Rotating arrow – Important: The interface will change its status to “In progress” found in the menu selector. Most data will be collected in between 3-15min, but note that some interfaces can take up to one hour in some cases. OTB is usually the longest import.

Re-trigger the API to collect data. This option is only available if your interface is connected to an API. Clicking this will start the process of collecting the latest data from the API. Note this usually takes up to fifteen minutes before data is collected to PMI, sometimes longer, depending on the provider. If data is still not updated in PMI, contact the provider and explain that data is missing.

4.2 Question mark – Click this to get info on who to contact if data is missing, and steps to upload the data. Question mark will have a blue color if it contains text. If the question mark is empty, please contact support@d2o.com and let them know.

4.3 Snooze button – Clicking this will set the interface to Ignored. Ignored means that you do not need to update PMI with this information today and you do not wish to have it populate the table. Use only if you are sure you are not expecting this data today.

Different statuses

  • All – Will list all interfaces and show the status they have in the table
  • In Progress – Will show data that has been retriggered by the user and data that is expected to arrive later due to ETA settings.
  • Ignored – An ignored interface that the user has deemed as data they do not expect to receive today.
  • Not updated – Data that is missing in PMI.

This view lists your interfaces and displays the status. If the file is imported you will find them in the status “updated in PMI” If the file is not imported, it will be listed in the “Not updated in PMI” table.

If you are aware of how to export source files then you should perform a new export of the missing files. If not, read the info in the question mark and follow the steps.

The missing files are also listed on the PMI Desktop.

Viewing imported files

  • Choose Updated in PMI under status

Magnifier glass feature (import drill-down)

Magnifier glass activates the interface drill-down.

Imported source data = what we received. Transformed values = What you see in PMI.

Click the magnifier glass on any interface that has been imported and you will get an overview of what PMI has received and what was imported to PMI. This is a great way to validate the figures in PMI (transformed values) against what you expect to see. The drill-down will also highlight any account that is unmapped or has been ignored. Reasons for data not showing in PMI can be:

  • New accounts that are not mapped to a specific department in PMI.
  • Ignored accounts are accounts that are ignored in the mapping module, meaning the figures will be blocked.
  • Another reason could be that the expected figures are not included in the import and a new import is needed.

Tools

Under the Tools Menu, you may enable or disable the different interfaces connected with your property. You must have a property selected in the menu for this setting to appear as this is property specific

  1. Name of the data receiving interface.
  2. Is this interface active? e.g should you receive data from this interface to PMI. Deactivating will stop data import through this interface. Only deactive this if you are sure it should not be in use.
  3. Warning refers to the red message seen on you landing page (home page) Do you wish to see this when data is missing?
  4. Track status enable the data to be shown in the updated or not updated interface table.
  5. Delay days – How often do we expect the import to contain data?
  6. ETA – At what time should this data be updated. If the data is not updated before the ETA it will show as not updated in PMI until data is received.

 

Watch the video tutorial here:

r

Troubleshooting tips

This section provides additional troubleshooting advice for readers experiencing specific issues. While it’s packed with useful insights, you may skip it if you’re not facing any related problems.

Resolving Data Discrepancies Between PMI and Your Source System

The data in PMI are extracted not only from an export file we receive but also through various active APIs that provide real-time data from the source system interface.

show more

​If you find any discrepancies, you can cross-check the figures using the Import status module in PMI. The module lets you track down imported data at a granular level, which can considerably simplify the process of validating the figures. If discrepancies or missing data between PMI and the source system persist, the first step should be to inspect the PMI settings and mappings. This knowledge base article provides step-by-step guidance for troubleshooting the common issues: You can also  open a support ticket at your chain's service desk or the source system provider. When doing so, include all relevant information and specify that the issue is related to data discrepancies between the source system interface and PMI.

show less

How to setup an Opera reports export

PMI requires data from Opera on a daily basis. There is a possibility to set up automatic export from Opera.

The different reports we require needs to be set up in Opera Scheduler. See the instructions below on each report that needs to be set up.

 

We have created a separate guide on how to set up each report, click on the links to how to.

 

When reports are set up and ready for export, we need to set up the transfer of the report. This is done either via SFTP set up or email. These credentials are supplied by d2o. See the instructions below.

 

PMI API

For complete documentation and a list of all methods in the PMI API see:

Best practice documents:

PMI API Best Practice Get Forecasted hours

Most request to the PMI API requires a property id (guid) or a chain id which will be part of the url.

These will be provided by d2o. In the following examples we will use “4f725e8a-d8e0-48bb-bb6e-84183edb581d” as chain id (in the end of all urls) and property id (h_id) 41

1. To get a complete list of properties you use

 

Result:

  • ExternalCode = Code name for the property
  • Id = Internal PMI property id known as “h_id” (hierarchy_id)
  • MaxRooms = number of rooms.
  • Name = Property Name

 

2. To get “your” departments related to these PMI departments/cockpits you use the xml/Mapping/TKS/Departments for each property/hotel, like:

Parameters:

  • H_id = Property ID from the Hierarchy/AllProperties method

Response:

  • Hid = Internal deparment/cockpit ID in PMI
  • SourceDepartment = Imported department name (from your system)
  • SourceDepartmentIdentifier = Imported department id (from your system)
  • Status = 1 = Department is in use, 2 Department is not in use.

 

3. Once you have the relation between your department id and the department id in PMI (Hid), above, you can retrieve forecasted hours.

 

Parameters:

  • h_id = 62 (refers to “Breakfast” from the Mapping/TKS/Departments method).
  • from= date from
  • to = date to

Response:

Use the “SmartForecast” for forecasted hours.

PMI File Agent setup and documentation

Prior to installation:

  • Send d2o the full path name to where source files are located, i.e. PMI File Outbox folder
  • Filenames (according to agreed naming conventions)

The above information needs to be sent to d2o in order for the PMI File Agent configuration at the receiving end to be completed appropriately.

Technical requirements for PMI Agent to be installed and work successfully:

  • Operating system: Windows Server 2008 R2, Windows 7 and later.
  • Windows Installer 5
  • Microsoft.NET Framework 4.6 or later (you can also check this using File Explorer: enter C:\WINDOWS\Microsoft.NET\Framework)
  • Allow outbound HTTPS (port 443) connections as part of firewall setup at customer’s end
  • Customer’s system time (clock) must be set correctly according to local time zone (cannot differ more than 10 minutes)
  • PMI Agent Outbox folder at client’s server must allow read and write permission for user “System”
  • Download: [PMI File Agent Setup version 1.4.6.1]
  • Unzip the setup package and double click on the setup.exe file
  • This installation will take you 10 – 20 minutes to complete

Installation steps:

The installation will download Microsoft.Net Framework 4.6 if it is not installed. If it does not exist, you should perform this step to install Microsoft.Net Framework 4.6 first.

You will get the screen below.

  • Select where you want to install the Agent. The default path is C:\d2o_Agent but you can change it to another location if need be.
  • Always choose option “Everyone”.
  • The next step is to enter a unique Agent Key (which you should have received from d2o by now). Click “Next” to proceed.

 

  • The installer will now complete the set-up of the Agent service.
Technical specification for data integration

Summary

This document explains the secure one-way data feed from various source applications to PMI. More specifically, it outlines:

  • which transaction applications (sources) are relevant to consider as data feed systems to PMI (target);
  • what data (data elements and values) are required for daily data feed to PMI;
  • PMI preferred output formats from source applications;
  • PMI preferred communication and transfer (data exchange) methods from source applications to PMI; and
  • what data (data elements and values) are required as historic data (one-off exercise).

As part of our services, we will proactively assist our customers – often in liaison with our customers’ third parties (software providers) – to define the data export requirements and procedures (see step 1 in the figure below). Once the output file with the agreed format is developed, the experienced integration team of d2o will ensure the subsequent steps of the process (steps 2 – 4) are completed to securely communicate/transmit the (source) data, import these, and make management information appropriately accessible to users through a web browser via our cloud-based solution.

We will ultimately, together with our customers, execute an end test or “dry run” – from the beginning to the end – to validate that all interfaces and the whole data journey work as intended, before certifying the solution ready for productive go-live.

Intended Audience

This document is meant for those who have a need and interest to understand the one-way data feed from source applications to PMI. More specifically, this document will include

Contents

 

  • 1Summary
  • 2Intended Audience
  • 3Overview
  • 4Process overview: daily data journey from source applications to PMI
  • 5Step 1: the data elements required from source applications, and the output formats to be used
  • 6Step 2: communication and data transfer methods
  • 7Step 3: loading and mapping of source data to PMI
  • 8Step 4: user access to management information in PMI
  • 9Historical data requirements
  • 10Data element library
    • 10.1Points of Sale (POS)
    • 10.2F&B Reservation Systems (FRS)
    • 10.3Time Keeping/Management System (TKS/TMS)
    • 10.4Property Management System (PMS)
    • 10.5Revenue Management System (RMS)
    • 10.6Sales & Catering Management System (S&C)
    • 10.7Accounting Management System (AMS)

Overview

This document explains the PMI data requirements for historical data and day-to-day data feed. The focus of this document is to explain what data elements and associated transactions are required to be exported from the various source applications, i.e. step 1 of the data journey. This is the part of the data journey that the d2o team will need to work on together with customers (or their third party) to ensure the right data are included in the export. It also details the applicable security measures and protocols built into the data exchange solution.

The rest of the journey, i.e. steps 2 – 4 (see figure below) will be accommodated by the PMI standard data integration solution.

Process overview: daily data journey from source applications to PMI

PMI relies on data feeds from various transaction applications (referred to as “sources”) like Points of Sale, Time Management, Reservations, etc. in order to process and deliver the intended management information. The scope of the data feed that needs to be established will vary from process to process and with the PMI scope that is to be implemented.

For instance, if the process is (only) related to restaurants, the various (source) applications relevant to consider as data “feeders” would typically be:

  • Points of Sale (POS)
  • Time Keeping/Management System (TKS/TMS)
  • F&B Reservation System (FRS) and equivalent

If this is to be applied to hotels or cruises, the various (source) applications relevant to consider as data “feeders” would typically be:

  • Points of Sale (POS)
  • Time Management System (TKS)
  • Property Management System (PMS)
  • Revenue Management System (RMS)
  • Sales and Catering System (S&C)

If the Planning module is a part of the PMI implementation scope (in addition to the base module Revenue & Productivity), a data feed from an accounting management system would also typically be recommended.

In general, we recommend that automation of the daily data export task from the source applications is automated, since this ensures accurate daily feed and eliminates any human interventions.

The daily data feed (data journey) can, at a high level, be described in four main steps, as illustrated in figure 1.

  1. Step: Execute dataset export to a pre-agreed output format, preferably Web service XML or a structured flat file format.
  2. Step: Communicate or transfer the output to the PMI server (cloud-based delivery model).
  3. Step: Import the source dataset into PMI and map it to corresponding data field structure.
  4. Step: The data will be computerised and the information presented through the PMI user-interface.

Step 1: the data elements required from source applications, and the output formats to be used

For each relevant application type, we have listed the data elements that would need to be included in the daily feed. The feed is run and imported into PMI every day, including weekends and holidays.

Daily data export routine: There are, in principle, three options to export the data from a source application (listed in order of preference).

  1. The export function in the source application is scheduled to run automatically every night, and eliminates the need for human intervention (most common and reliable option).
  2. The export function is invoked by a macro recording procedure (defined by using a software like AutoHotKey) to emulate the sequence of keystrokes and mouse clicks required to download the desired dataset and save this as an output file. This macro procedure (an EXE-file) is scheduled to run automatically every night, thus eliminating the need for any manual interventions.
  3. The export task to download the dataset and save this as an output file in a specific area is carried out manually by a person every night – thus allowing for human error.

Data export date selection: The daily data feed contains transactions not only for the day prior to the export day, but also pertaining to seven (7) days back in time. This is done to make sure that any changes and/or adjustments made pertaining to transactions falling within this time span are captured and, hence, fed to PMI.

An example: The daily data export on Jan 2, 2013 will not only include transactions pertaining to Jan 1, but also those from Dec 25, 2012 up to and including Dec 31, 2012.

Some customers may use a data warehouse or an enterprise data warehouse as a central repository holding data imported from one or more disparate source applications for reporting and for data analysis. Often, such a data warehouse is used as the main data source for PMI, since it normally has flexible export capabilities available.

Output formats: The exported data (output) from a source application can be in either Web service XML or plain flat file format. PMI data integration solution supports different output formats as long as the data content follows a consistent structure. However, given a choice, we recommend the following formats, listed order of preference:

  1. XML, or
  2. Json, or
  3. Flat file based RFC 4180, a widely accepted CSV format. More details on http://supercsv.sourceforge.net/csv_specification, or
  4. Other structured file format to be agreed on, or
  5. Open database connectivity (ODBC), in some cases between PMI and for the time management system.

In case of flat file, the files must always be stored in a pre-determined naming convention and catalogue so that the PMI file agent can initiate the file transmission procedure using NET.TCP or HTTPS, protocols that are commonly used professional websites to ensure secure data communication/transmission over the internet.

Step 2: communication and data transfer methods

The default choice is to use HyperText Transfer Protocol over SSL/TLS (HTTPS) for both Web service and flat file transfer.

In case of file communication (or transfer), the data files are automatically initiated by a PMI file agent as soon as the files are saved in a predetermined folder. The transmission to PMI cloud-based solution is based on either NET.TCP or HTTPS. These secure protocols (using authentication, encryption, etc.) are commonly used to transfer sensitive data (e.g. payment transactions) over the internet by professionals.

However, we do support customers who, for different reasons, prefer other data communication and transfer protocols like FTPS, SFTP, etc.

Once the output files from source applications have been downloaded and stored in line with the agreed naming convention in the PMI Agent Outbox folder (step 1), PMI File Agent, a small Windows service (.Net C#), initiates a secure file communication/transmission (step 2). More specifically, the agent is designed to perform the following main functions:

  • At predefined time intervals, monitor PMI File Outbox for predefined file names.
  • If a new file arrives, considering the naming convention and the create/modify time, transmission will be initiated.
  • When required, restart (agent).
  • Delete files upon successful transmission (to avoid unnecessary filling up of storage space)

The functioning of PMI File Agent has proven to be very robust and stable. Experience from hundreds of properties so far suggests minimal need for manual interventions from customers’ IT personnel. However, should the agent fail, the d2o support team may have to liaise with the customer’s personnel at property to check the existence of the agent on the local server.

For more information about technical requirements for PMI File Agent, how to install it, and to download the Microsoft service, please see below:

Step 3: loading and mapping of source data to PMI

Once the source output data from the source application has been received, it is immediately validated, imported and transmitted to PMI, a robust multi-tenants application architecture.

Data errors due to missing account mappings or files will be highlighted on PMI Desktop for review and corrective actions by users.

Step 4: user access to management information in PMI

d2o use SSL (Secure Sockets Layer), which is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral. SSL is an industry standard and is used by millions of websites for protection of their online transactions with their customers.

The users can securely access the PMI cloud-based application by using the web browser via HTTPS connection (with logon authentication), i.e. the same level of security as, for instance, any secure professional website capturing sensitive information like payments transaction and personal information.

There is no need to install any additional software locally in this respect.

PMI response time: Based on experience accumulated over more than ten years and from of thousands of end users located in Europe, Africa, the US and Asia, the response time has not been an issue or inconvenience factor. A normal session in PMI application will typically require less than 10KB per second. The ultimate response time experienced by end users will, of course, be influenced by available bandwidth at the respective properties.

Historical data requirements

For comparison purposes and calculation of variables, trends, predictive analytics, etc. PMI will require historical data to be loaded as part of a one-off exercise. The source data elements and associated values are the same for the historical as for the daily feed. The main difference is in the date range to be selected. Unless the property has been recently opened, it is typically recommended that the historical data load consist of the 12 months prior to the month of go-live.

An example: If PMI is to go live (i.e. be ready for business use) on Jun 1, 2012, the historical data load needs to consist of transaction values pertaining to data from Jun 1, 2011 up to and including May 31, 2012.

To understand which data elements are required to be exported from which source applications, please refer to “Step 1: the data elements required from source applications, and the output formats to be used”.

Data element library

Below, we have included examples of mapping tables. A mapping table serves to define how data elements in one application (source) relate to data elements in another (target).

Where available and permissible, examples of XML, flat file or other output formats can be provided by the d2o team upon request.

How to transfer data to PMI

There are 5 main options to transfer files/data to PMI. They are listed below in the preferred order:

  1. Webservices/API – If your system offers such service, please provide access information/credentials.
  2. SFTP Client – you upload the daily extract to d2o server, credentials will be provided by d2o.
    1. Server host key
    2. Algorithm: ssh-rsa 1024
    3. Fingerprints: SHA256:OaK8ia0WT5HWLzpC3i10bG7PUp2XCU7IFf67Lzl/70A
  3. FTP/SFPT server – if your system offer such service, please provide access information/credentials.
  4. E-mail – send the files to d2o via mail, mail adress will be provided by d2o.
  5. d2o agent upload service – an agent is installed at the server in the property and the files are dropped into a folder where d2o will pick them up.

If the options above cannot be accommodated, we can discuss other methods.

Automate SFTP upload via WinSPC on windows

  • Get, and install, the latest version of WinSPC.
  • Open a text editor and paste the following

open sftp://USER_NAME:PASSWORD@ftp.d2o.biz/ -hostkey=”ssh-rsa 1024 OaK8ia0WT5HWLzpC3i10bG7PUp2XCU7IFf67Lzl/70A=”
put d:\temp\Test.txt /
exit

Replace

USER_NAME = The user name provided by d2o
PASSWORD = The password provided by d2o
D:\temp\Test.txt = The File you want to upload

Save the file as, for example sftp_upload_instructions.txt

Open a new text editor and past the following

@echo off
C:\Program Files (x86)\WinSCP>WinSCP.com /ini=nul /script=d:\temp\winspc\ sftp_upload_instructions.txt

Replace

C:\Program Files (x86)\WinSCP>WinSCP.com = The correct path to the installed WinSCP.com
d:\temp\winspc\sftp_instructions.txt = The correct path to the instructions file you just created.

Save the file as, for example “sfp_upload.bat”

You can now test your script by opening a command prompt, browse to your bat file and execute it and then use the windows scheduler if you want to schedule the transfer.

Data elements required from AMS

The table below shows the PMI data elements required for PMI Planning module. Corresponding data elements must be identified and included in the export routine that is to be set up in the accounting management system (or ledger/ERP). The extract only needs to include P&L accounts – balance sheet accounts are not used in PMI Planning. Please note: The names of data elements are provided in source system (native) codes. These native codes will be translated into PMI names in PMI.

Transfer Methods

See here what different transfer methods are available – Transfer Methods

VISMA IMPORT ACTUAL FIGURES

For import of Actual figures from Visma into PMI Planning P&L

It is advised to use the format .csv if possible and otherwise Excel will suffice.

Steps of pulling a Visma report

  1. Regnskap/Accounting
  2. Bilagssøk/Verifications
  3. Hovedbokstransaksjoner/Ledger Transactions
  4. Pick you fields – see picture
  5. Write it all out in Excle format first and…
  6. Delete all balance accounts or simply pick from what accounts you wish to the far right.
  7. Once done save as .csv file and either e-mail to support; support@d2o.com or save in specified catalogue on the hotel server.
  8. This should be done once a month once closing of the previous month is completed.

The fields that are to be included are

  • Visa save as .csvYear
  • Period (1-12)
  • Account
  • Department
  • Name of Account
  • Value = sum of verifications within the period/month

Not needed:

  • Opening balance
  • Closing balance
  • Balance Accounts (1000-2999)
Manual Export AMS – Visma

For import of Actual figures from Visma into PMI Planning P&L

It is advised to use the format .csv if possible and otherwise Excel will suffice.

Steps of pulling a Visma report

  1. Regnskap/Accounting
  2. Bilagssøk/Verifications
  3. Hovedbokstransaksjoner/Ledger Transactions
  4. Pick you fields – see picture
  5. Write it all out in Excle format first and…
  6. Delete all balance accounts or simply pick from what accounts you wish to the far right.
  7. Once done save as .csv file and either e-mail to support; support@d2o.com or save in specified catalogue on the hotel server.
  8. This should be done once a month once closing of the previous month is completed.

 

The fields that are to be included are

  • Year
  • Period (1-12)
  • Account
  • Department
  • Name of Account
  • Value = sum of verifications within the period/month

Save as .csv file

 

    Not needed:

    • Opening balance
    • Closing balance
    • Balance Accounts (1000-2999)
    Data elements required from TRS
    This form explains the table reservation data we need in PMI for its daily cover forecasting algorithms. Its purpose is to help experts find the precise data points (fields) to extract from a table reservation system. Preferably, the daily extraction should utilize an API, although flat file transfer is also supported.
    Data elemets required for food cost import

    This form explains what elements are required for food cost imports.

    Data elements required from POS

    This is a section describing what is required for the implementation of new POS interfaces. For existing interfaces please visit the detailed description of these interfaces. The implementation of using actual covers is optional for POS systems.

    Please note: The names of data elements are provided in source system (native) codes. These native codes are translated into PMI names in PMI.

    Data Spec POS import for F&B Analytics

    This spec is for the new F&B Analytics module only. Some elements may not be valid for all properties, like segment, then ignore that.

    FRS – 2Book (SAAS only)

    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

    You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in PMI staging table where such have been applicable.

    An example of the source file data, format and structure is also attached below the table.

    This table will be updated whenever the source file or the interface in question are changed throughout the interface life-cycle. The two adapters that are now used are utilizing XML data retrieved from a web service. The web service creates a separate file for each restaurant based on the <Restaurant> tag.

    POS – RMS

    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

    You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

    An example of the source file data, format and structure is also attached below the table.

    This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

    Download an example of the source file format: File:Rms.txt

    POS – RTP

    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

    You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in PMI staging table where such has been applicable.

    An example of the source file data, format and structure is also attached below the table.

    This table will be updated whenever the source file or the interface in question are changed throughout the interface life-cycle.

    Download an example of the source file format: File:CJx.txt 

    POS – HSI

    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

    You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

    An example of the source file data, format and structure is also attached below the table.

    This table will be updated whenever the source file or the interface in question are changed throughout the interface life-cycle.
    Te file name pattern is like CJ*.txt

    POS – KDR Gold

    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

    You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

    An example of the source file data, format and structure is also attached below the table.

    This table will be updated whenever the source file or the interface in question are changed throughout the interface life-cycle.

    Before KDR Gold, the system provided by this data source provider was called RMS and this name can still be found in many places in the system.
    The filename follows the pattern “SLSACC*.txt”

    All the interfaces handling this system are called Rms_Fb and there are many versions. The generically used versions are handled in this part. First we give an overview of the differences and then we will describe version 1, which is the base interface for all generic interfaces.

    Download an example of the source file format: File:Rms Fb V001.txt

    POS – Micros
    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source). You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable. An example of the source file data, format and structure is also attached below the table. This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

    Output examples for download:

    Flat file in CSV format for Micros_revenue interface:

    Flat file in CSV format for Micros_Covers interface:

    POS – Opera

    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source). You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable. An example of the source file data, format and structure is also attached below the table. This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

    Output examples for download:

    Flat file CSV for Opera_restat interface:

    • File:Opera hb V100.txtFile:Opera hb V101.txt

    Flat file CSV for Opera_restat interface:

    • File:Opera trialbalance V001.txt

    Flat file fixed length for Opera_Fb interface:

    • File:Opera Fb V001.txt
    POS – Protel

    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source). You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

    An example of the source file data, format and structure is also attached below the table. This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

    Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

    Output examples for download:

    XML file for Protel_RevHistory interface:

    • File:Protel RevHistory V001.txt

    Flat file for Protel_Rev interface:

    • File:Protel Rev V101.txt
    POS – Squirrel

    This is a section describing what is required for the implementation of new POS interfaces.

    1
    2
    3
    4
    5
    6
    7
    8
    PMI data element (target)
    Example
    Example
    Example
    Example
    Example
    Example
    Example
    Example
    Description
    Example
    Example
    Example
    Example
    Example
    Example
    Example
    Example
    Mandatory / Optional
    Example
    Example
    Example
    Example
    Example
    Example
    Example
    Example
    Comment
    Example
    Example
    Example
    Example
    Example
    Example
    Example
    Example
    POS – Vest Systempartner

    The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

    You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

    An example of the source file data, format and structure is also attached below the table.

    This table will be updated whenever the source file or the interface in question are changed throughout the interface life-cycle.

    Te file name pattern is like CJ*.txt

    Download an example of the source file format: File:CJx.txt

    Arrivals/Departures

    The table below shows the PMI data elements required for PMI Revenue and Productivity (R&P) module regarding Arrivals & Departures.

    It shows the elements that we require from the source system PMS (Property Management System).
    Within PMS we import both actuals and reservations (on the book).

    Data elements required from PMS

    The table below shows the PMI data elements required for PMI Revenue and Productivity (R&P) module. It shows the elements that we require from the source system PMS (Property Management System). Within PMS we import both actuals and reservations (on the book).

    Revenue Actuals (yesterdays data + preferably 7 days back)

    Rooms on the books (OTB) data (“today” + 500 days)

    Please note: The names of data elements are provided in source system (native) codes. These native codes will be translated into PMI names in PMI.

    The data we like to receive on a daily basis as early in the morning as possible.

    For more details, please see this article on Transfer methods

     

    Examples

      Manual Export PMS – Fidelio

      Night audit from Fidelio 6.1 to PMI

      These reports (exports) have to be executed AFTER the Fidelio night audit is successfully completed.

       

      Report 1: PMI Market Segment (MONTHFOR.DBF)

      1. Open Fidelio List & Reports, chooseA. Reports andB. Special

      2. Choose the report “2 – PMI Market Segment”

      3. Choose “Calculate New Forecast”.NOTE! Calculate from including today and including 31st of December next year. E.g. if today is 26th of February you need to choose until date 31st of December 2009. If you do not have minimum time span, PMI will not accept the file.

      4. Fill out the screen according to the screenshot (please note that everything should be Y, except for Include Parlors and Tentative, i.e. (N in Include Parlors and Tentative). The report should take a couple of minutes to generate.
      5. After the report is displayed on the screen, remember to close the report (hit the Esc. Key). Otherwise you will lock the report for retrieval.
      How to do a manual PMS export from Opera

      Night audit from Opera to PMI

      These reports (exports) have to be executed AFTER the Opera night audit is successfully completed.

       

      Report 1: Reservation Statistics 1 (res_statistics1)

      1. Go to Miscellaneous and choose Reports

      2. Enter reservation in the Report field and click on Search.

      3. Choose the report Reservations Statistics 1 (REP name should be res_statistics1)

      4. Click on Print to file

      5. The file format should be DELIMITED DATA (not just delimited, but check that it says delimited data)

      6. Click on OK

      7. From Date should be yesterdays date

      8. Under “Options”, choose Market Code

      9. Click on File

      10. Click on Save

      11. Choose disc, say: Q:\ (NB: disc and folder may be different – check property specific instructions)

      12. Enter the file name restat.txt

      13. Click on Save

      Historical reservation data

      Since there is a need for a 12-month worth of historical reservation data, this report is also often used for this purpose. An example: if PMI is to go live (i.e. be ready for business use) on Jun. 1st 2012, the historical revenue data load needs to consist of values pertaining to Jun. 1st 2011 (“From” – ref. step 7 above) up until and including May 31st 2012 (“To” – ref. step 7 above).

      Report 2: Reservation Forecast, (res_forecast)

      1. Back in the report overview, choose Reservations Forecast (REP name should be res_forecast1)

      2. Click on OK

      3. From date should be today’s date. To date should be 12 months ahead E.g., if today is the 12th of September 2012, then “From Date” should be “12.09.2012” (or 09.12.12 in US mm.dd.yy date format) and “To Date” should be 11.09.2013″ (or 09.11.13 US mm.dd.yy format). You can also type in the date directly instead of using the calendar

      4. Under Reservation types, check Block.

      5. Under Options, check Market Code6. Click on File.

      7. Click on Save

      8. Choose disc: I:\ and the folder PMI Agent Outbox (NB: disc and folder may be different – check property specific instructions)

      9. Enter the filename resfct.txt10. Click on Save

      The Reservation Forecast report cannot be run in the past. It is a snapshot of future booking pace from today’s date and forward.

      Report 3A: Trial Balance (trial_balance)

      1. Back in the report overview, write trial in the Report field and click on Search
      2. Choose Trial Balance (REP name should be trial_balance)
      3. Click on OK

      4. The date should be yesterdays date, click on File
      5. Click on Save
      6. Choose disc: J:\nightrun (NB: disc and folder may be different – check property specific instructions)
      7. Enter the filename trial_balance.txt
      8. Click on Save

      Export of historic revenue data

      Since there is a need for a 12-month worth of historic revenue data, this report is also often used this purpose.

      Unless the daily export files are available and ready for re-use for PMI historic data purpose, the limitation is that a date “From” and “To” range cannot be defined on this particular report in Opera. Therefore, the report would need to be run 365 times – one per day to get a revenue file for each day – 12 months back in time.

      An example: if PMI is to go live (i.e. be ready for business use) on Jun. 1st 2012, the historical revenue data load needs to consist of values pertaining to Jun. 1st 2011 up until and including May 31st 2012.

      Report 3B: Alternative to 3A Trial Balance following Daily Revenue (HB) can also be used

      1. On the main menu Opera, choose Back Office Interfaces2. Click on Revenue Transfer3. Enter relevant accounting date to be exported4. Click Start

      (The data will be automatically exported to a file normally named as hb_statYYYMMDD.txt)

      Report: Reservation History & Forecast (history_forecast)

      This report can be used to export arrivals and departures.1. Go to Miscellaneous and choose Report

      2. Write %fore% in the Report field and click on Search
      3. Choose the report History and Forecast (the REP name should be history_forecast)
      4. Click on Print to file5. The File Format should be DELIMITED DATA (not just delimited, but check that it says delimited data)6. Click on OK
      7. From date should be two weeks in the past and one month into the future from today’s date (i.e. if today is June 17th 2013, you should choose June 3rd 2013 as From Date and July 17th 2013 as To Date)

      8. Let all other setting be as they are9. Click on File

      10. Choose disc: Y (or the driver agreed specifically at the property)

      11. Enter the folder for the correct property (or the folder agreed specifically at the property)12. Keep the system default file name13. Click on Save

       

      Report Scheduler: Schedule daily automatic run of the reports

      For certain release and license of Opera, a scheduling feature is possible to enable automatic execution at specified time(s). Below are the navigation steps.1. In Opera, select “PMS”

      2. In Opera PMS, select “Miscellaneous” and “Reports Scheduler”
      3. In Scheduler, you can create a new scheduled report by clicking the “New”-button to the right
      4. Find the correct report and configure it according to the previous sent manual
      5. Enter date and time, date is the first date you want the report to run, time is when you want the report to run. In this case we suggest after night audit at maybe 05.00 or 06.00. Repeat should be Every 1 Days.
      6. Highlight the report you just created and then click on Parameters and Set Date.
      7. Chose report date and -1 days.
      8.There are two options to export this to PMI, either you have an Agent setup on your server and then choose distribution list if you have a folder setup by d2o for PMI export data. Put PMI in the Folder name and the report will end up in that folder. (NB: disc and folder may be different – check property specific instructions). The best solution is to use SFTP. Choose that and d2o will provide you with credential where to connect.
      Manual Export PMS – Picasso

      Night audit from Opera to PMI

      These reports (exports) have to be executed AFTER the Opera night audit is successfully completed.

      Report 1: Management Accounts (yesterday’s turnover)

      1. Enter the Picasso Selector and select Management (F5)

      2. Select the report Accounts (located top right).

      3. Select the previous day from the calendar (located on the far left in the picture)

      4. Click the departments in the Sort Order field.

      5. Click on Total’s just right for Sort Order field.

      6. Now you should see the report itself in the middle of the picture. After that appears click on the Excel icon located on the right side.
      7. After the report is opened in Excel format, select store (either click on the save icon, or hold down the CTRL key and press S).:

      8. If you get an error message that the file cannot be saved in the current format, click OK.:

      9. Click Export (far left of the dialog screen).:

      10. Click Save. After this you can close the report.

      Report 2: Report Statistics

      1. Enter the Picasso Selector and select Reports (F7)

      2. Click Statistics (very top of the picture).

      3. Click on Products (right in picture).

      4. Select yesterday’s date from the calendar (left in picture).

      5. Check that Day Products is unchecked.

      6. Click on the Excel icon (bottom right).

      7. Click the Excel file that has now been generated.

      8. After the report is opened in Excel format, select store (either click on the save icon, or hold down the CTRL key and press S).

      9. If you get an error message that the file can not be saved in the current format, click OK.

      10. Click Export (far left of the dialog screen).

      11. Click Save. After this you can close the report.

      Report 3: On The Book

      1. Enter the Picasso Selector and select Reports (F7)

      2. Select In-House from the Tools menu

      3. Date from to stand as it does, to date shall be the last date of the same month as the current next year. Thats If today is the 21/1/08 shall be as of 8/21/08 through 31/01/09.

      4. In the Reservation Status, click All to status objects are highlighted.

      5. In the Group by, select Date6. Click the Excel finally, now stock TECHOTEL a report that we should save to Export folder

      7. Click on the Excel spreadsheet that has now been created.

      8. Select the save / save (either click on save / save icon, or hold down the CTRL key and press S).

      9. If you get an error message that the file can not be saved in the current format, click OK.

      10. Click Export (far left of the dialog screen).

      11. Click Save. After this you can close the report.

      Manual Export PMS – Protel

      Night audit from Protel to PMI

      Report 1: Revenue

      1. Log in to Protel, selectA. OfficeB. ReportC. 423 – Accounting Report (history)

      2. Select yesterday’s date in the fields “From time” and “To time”. If tonight is the night of 16.09.2006, the selected date should be 15.09.2006 in both “From date” and “To date” fields (night driving from yesterday).:: Click on OK

      3. Click on the envelope with a red arrow on it to export the file.A. In the export image that pops up, click on the format field and select Tab-Separated textB. Click OK
      4. Click save the imageA. Select Q disk (shared directory on mother \ Users), then drill down into the data folder, on down to dormidocmi and eventually into the Data folder.B. In the image filename type REV and the abbreviation for yesterday’s date (DDMMYYYY). If we created the file 18.09.2006 shall stand REV18092006 here.C. Click Save. PS! If prompted to overwrite the file that is there already, then yes.

       

      Report 2: Occupancy

      1. Select a Report2. Click on Hotel Status.

      3. In Hotel Status image that is presented, select:A. In a field of date shall be one month ago. If it’s the 16.09.2006 at day shall there be 16.08.06 in this field.B. In the field to date shall be 31.12 for next year. For all of 2006 should be 31.12.07 in this field (in 2007, it should be 31/12/08, etc.).C. Check that the “special treatment” is NOT ticked, while the “Calculate detailed …” should be checked.D. Click the View
      4. In the Report Selection field that appears click OK (field 141 – Hotel status will be shown in blue).
      5. Click on the envelope with a red arrow in order to export the file.A. In the export image that pops up, click on the format field and select Tab-Separated textB. Click OK
      6. Click save the image, select Q disk (shared directory on mother \ Users), then drill down into the data folder, on down to dormidocmi and eventually into the Data folder.A. The file name should be HSTAT2B. Click OK.

      PS! If prompted to overwrite the file that is there already, select yes
      Manual Export PMS – Spirit Web

      Procedure to print OTB figures from Spirit

      1. Select the Report 247

      2. Mark the date line, and click the F3 key on your keyboard.

      3. In the new image, select printing for 500 days.

      4. Mark To file line and click the F3 key on your keyboard.
      5. Click enter the filename HGP247 / htm

      6. Select Common.

      7. Select OK

      8. Answer Yes when asked whether you want to replace the file that already exists.
      PMS – Cenium

      The table below shows the PMI data elements required for PMI R&P module. Corresponding data elements must be identified and included in the export routine that is to be set up in PMS. There are two distinct sets of data needed from the source PMS: PMS actuals and PMS reservations.

      PMS actuals

      Download an example of the source file format:

      PMS – Citybreak

      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source). You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable. An example of the source file data, format and structure is also attached below the table. This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.
      Used for registration of tickets.

      The file structure is the same for actual and on the book. The only difference is that the date is before today (actual) or from today onward (otb).

      Output examples for download:

      PMS – Fidelio

      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source). You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable. An example of the source file data, format and structure is also attached below the table. This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      The file name pattern is: Res*f*c*t*

      Output examples for download:

      PMS – Opera

      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source). You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table. This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      Output examples for download:

      Flat file CSV for Opera_restat interface:

      Flat file CSV for Opera_resfxt interface:

      PMS – Protel

      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source). You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table. This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      Output examples for download:

      Flat file CSV for Protel_Hstat interface:

      XML file for Protel_ResForc interfaces:

      How to do a manual PMS export from HotSoft

      To manually send data to PMI for a specific date, go to the “Monitors” tab in the main menu and click on “GEX Console”.

      Select the interface you want to export data to, in this case PMI1, and the export date, and click Ok.

       

      HotSoft compiles the data and uploads it to PMI. You will get a confirmation when it is complete.

      Data elements required for hotel market report
      In GM daily digest PMI can display the competitor benchmarking KPIs such as ranking of the property in the comp set, RGI, MPI and ARI.

      To be able to do this PMI needs a daily import from the hotel’s provider of this data.

      Below is a description of what data is needed to calculate the KPI’s in PMI as well as a description of different transfer methods at the bottom of the article.

      The competitor data is reported as collective data.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      PMI data element
      Property ID
      Property name
      Comparison group
      Currency
      Date TY
      Date LY
      Property max. no. rooms TY
      Property no. sold rooms TY
      Property room rev. TY
      Property max. no. rooms LY
      Property no. sold rooms LY
      Property room rev. LY
      Compset max. no. rooms TY
      Compset sold rooms TY
      Compset room rev. TY
      Compset max. no. rooms LY
      Copset sold rooms Compset LY
      Compset room rev. LY
      Ranking TY
      Ranking LY
      Completeness TY
      Completeness LY
      Description
      ID of the property (hotel, restaurant)
      Name of the property (hotel, restaurant)
      Name of the comparison group
      Currency
      Date this year
      Date last year
      Maximum no. rooms for the property this year
      No. rooms sold for the property this year
      Room revenue for the property this year
      Maximum no. rooms for the property last year
      No. rooms sold for the property last year
      Room revenue for the property last year
      Maximum no. rooms for the compset this year
      No. rooms sold for the compset this year
      Room revenue for the compset this year
      Maximum no. rooms for the compset last year
      No. rooms sold for the compset last year
      Room revenue for the compset last year
      Ranking this year
      Ranking last year
      Completeness this yea
      Completeness last year
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Optional
      Comment
      Property id (abbreviation)
      Name of property
      Name of the comparison group
      Currency being used for the monetary values
      The date on which information is applicable this year
      The date on which information is appliable last year
      Maximum number of rooms available for sales for the property on the date this year
      The number of rooms sold for the property on the date this year
      Room revenue excl. mva. for the property on the date this year
      Maximum number of rooms available for sales for the property on the date last year
      The number of rooms sold for the property on the date last year
      Room revenue excl. mva. for the property on the date last year
      Maximum number of rooms available for sales for the competitive set on the date this year
      The number of rooms sold for the competitive set on the date this year
      Room revenue excl. mva. for the competitive set on the date this year
      Maximum number of rooms available for sales for the competitive set on the date last year
      The number of rooms sold for the competitive set on the date last year
      Room revenue excl. mva. for the competitive set on the date last year
      The property’s position in the ranking within the competitive set for the date concerned this year
      The property’s position in the ranking within the competitive set for the date concerned this year
      The number of respondents in the competitive set complied who provided data input: 100% signifies that all in the set provided input for the date concerned this year.
      The number of respondents in the competitive set complied who provided data input: 100% signifies that all in the set provided input for the date concerned last year.

      For more information, please see the article Transfer methods.

      Data elements required from RMS
      The table below shows the PMI data elements that need to be populated with values associated with corresponding data elements in the RMS application. There are two distinct sets of data needed from source RMS: RMS actuals and RMS reservations.

      Date range should be from “today” + 365 days or how far out there is data in the RMS

      1
      2
      3
      4
      5
      6
      7
      8
      PMI data element (target)
      Property ID
      Property Name
      Extract Date
      Date
      Market Code
      Forecasted Room Nights
      Forecasted Guest Nights
      Forecasted NetRevenue Rooms
      Description
      ID of the property
      Name of the property
      Date of the data extract
      Date of stay
      Name of the market code
      Number of room nights
      Number of guest nights
      Room revenue without F&B, VAT and other authority charge rates
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Mandatory
      Comment
      For instance, if the guest stays for three days, we expect three records; one for each day.
      Not selling rate.
      RMS – Easy RMS
      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      Download an example of the source file format: File:EzRms.zip

      S&C – Delphi

      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      Download an example of the source file format:

      Data elements required from S&C

      Why? The data set allows calculation of daily revenue forecast and optimal productivity as well as staffing level in PMI. 

      What? The data set comprises of a daily snapshot of all sales and catering reservations recorded on the book for the next 365 days.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      PMI data element (target)
      Property ID
      Property Name
      Department ID
      Department Name
      EventType ID
      EventType Name
      MealPeriod ID
      MealPeriod Name
      Extract Date
      Event Date
      Covers
      NetRevenue
      Event Status
      Description
      ID of the property (hotel, restaurant)
      Name of the property (hotel, restaurant)
      ID of the department within the property
      Name of the department within the property
      ID of the event type
      Name of the event type
      ID of the meal period
      Name of the meal period (e.g. Breakfast, Lunch, Dinner)
      Date of the data extract
      Event Date
      Number of covers/guests
      Revenue without VAT and other authority charge rates
      Booking status of the reservation
      Mandatory / Optional
      Optional
      Mandatory
      Optional
      Mandatory
      Optional
      Mandatory
      Optional
      Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Comment
      An event type can be any kind of catering activity; it can be as simple as a one-hour reception, or something more complex such as a three-day business meeting with meals, breaks, and specific meeting room, setup, and resource requirements. Other common examples are: dinner, meeting, coffee break, etc. These attributes are used to map associated revenue to correct departments and segments.

      Please note: The table above shows the PMI data elements required. Equivalent data elements must be identified in source S&C application as part of the extract specification exercise.

      The export should be scheduled daily as early as possible in the morning.

      Please see the article Transfer methods for more details. 

      Manual Export – Opera Scheduler

      Report Scheduler: Schedule daily automatic run of the reports

      For certain release and license of Opera, a scheduling feature is possible to enable automatic execution at specified time(s). Below are the navigation steps.1. In Opera, select “PMS”

      2. In Opera PMS, select “Miscellaneous” and “Reports Scheduler”
      3. In Scheduler, you can create a new scheduled report by clicking the “New”-button to the right
      4. Find the correct report and configure it according to the previous sent manual

      5. Enter date and time, date is the first date you want the report to run,time is when you want the report to run. In this case we suggest after night audit at maybe 05.00 or 06.00. Repeat should be Every 1 Days.

      6. Highlight the report you just created and then click on Parameters and Set Date.

      7. Chose report date and -1 days.

      8. There are two options to export this to PMI, either you have an Agent setup on your server and then chose distribution list if you have a folder setup by d2o for PMI export data. Put PMI in the Folder name and the report will end up in that folder. (NB: disc and folder may be different – check property specific instructions)The best solution is to use SFTP. Chose that and d2o will provide you with credential where to connect.

      For more information, please see this Oracle Scheduler document. 

      Manual Export S&C – Delphi

      Here are two SQL queries that can be used for Delphi S&C export. Both files are in Zipped format.

      Manual Export S&C – Opera

      Night Audit from Opera to PMI

      This report are used to import S&C OTB.. It has to be executed AFTER Opera Night Audit is successfully completed.

      Report: Daily Catering Forecast (rep_ev_forecast)

      1. Go to Miscellaneous and choose Reports

      2. Enter rep_ev in the Report field and click on Search

      3. Choose the report Daily Catering Forecast (REP name should be rep_ev_forecast)

      4. Click on Print to file

      5. The file format should be DELIMITED DATA (not just delimited, but check that it says delimited data)

      6. Click on OK

      7. From date should be today´s date, To Date should be 12 month ahead.

      8. Other choices should be as below.

      9. Click on File and save the report where the Opera files normally are saved.
      Data elements required from TKS

      PMI is a Productivity Management Tool. The tool is looking at productivity per department in the hotel. PMI calculates productivity by looking at the Cost Driver for the department, normally revenue, room nights or covers. PMI is then taking the cost driver and dividing it with the amount of hours used for a specific day or planned for a specific day in the future.

      Out of this PMI can suggest a planning for future days as well as analyse history days.

      The hours used or planned for a specific department is the information PMI is looking for from a Time Keeping System.

      Integration with an external TKS is all about importing used hours per department as well as planned hours per department for future days.

      What data do we need from your Time Keeping System (TKS)?

      The purpose of recording hours in PMI is to keep track of paid hours incurred and paid hours planned/scheduled to be incurred per department/operational unit (e.g. Housekeeping, Front Office, Breakfast etc.).

      The data need to be extracted daily. Each extract need to encompass yesterday including 30 days back in time and schedule hours today including minimum 45 days ahead (preferably more if that exists).

      Extra information for PMI Planning

      If you also wish to integrate the salary from the TKS, or a salary system, into the Planning module in PMI we also need this additional data in a separate export on a monthly basis:

      Key clarification on the use of TKS

      The following questions will be addressed during the discussion on how the integration should be set up.

      1. If a staff belonging in one department and performing a task for another department, will the hours be recorded accordingly in TKS, i.e against two separate departments codes?
      2. What time categories will be extracted? Examples? (See point 6 above)
      3. What job categories will be extracted? Examples? (See point 8 above)
      4. In PMI we need all hours recorded imported everyday. Does your extract support this, or is it restricted to only “approved” hours?
      5. In PMI we need to also separate future/planned/schedule hours between productive and non productive (e.g vacation, training) “tasks”. Does your system support such separation?
      6. If the data cannot be provided trough Webservice or API, the extract should be divided into two files; one with Actual (yesterday minus 30 days) and the other with Scheduled/Planned (today plus 45 days).

      For more details on data transfer methods, please see the article How to transfer data to PMI

      How to use a timekeeping system (TKS) import in the Cockpit

      Summary

      This article explains how the cockpit works if you have a connection to an external time keeping system (TKS).

      Intended Users

      Cockpit owners

      To activate the different settings you must have administrator user rights.

      Requirements

      How PMI handles imported hours are affected by what export the external system have. Should the property not have an external system this function will not be activated.

      How PMI handles Live forecast hours in the schedule beyond the imported hours also affects the properties without external system.

      Instructions

      Mapping

      Since the external TKS (timekeeping system) is connected to PMI it all starts with mapping. The incoming information from the TKS needs to be connected to the correct section in PMI.

      Categories and Departments are the two main areas to be connected.

      •  Categories are the different types of time categories PMI will receive from the external TKS. This can vary depending on the TKS.
      •  Departments are where the hours will be connected in PMI – which cockpit and which schedule.
        • Departments are also divided into Tasks, which the TKS provides to PMI. If Tasks are activated in the mapping settings, there is a possibility to map a task to a schedule other than the main (top) one.
      • Period – You can set a From and/or To date in an import. If you are changing your TKS, you may need to set a To date in the old system and a From date in the new system.

      In the example below, the areas needing to be mapped are highlighted in red. All unmapped segments should be mapped in the same way as the ones already mapped above them.

      Categories are mapped after discussion with the hotel to find out exactly what all categories are used for. It is important to find out if it is productive hours or non-productive hours. Some may also be ignored, like vacation, off days and other leave that is not paid by the hotel.

      It is also possible to add colours to each category. This will be reflected in the cockpit. It is important to have the productive worked hours at the bottom of the list with not ignored categories. Use the arrows to move it down.

      Make sure that the cost is set correctly to reflect the actual cost in the cockpit. If the hotel pays 80% of the sick leave, the category for sick leave should be at 0.8 in Cost column.

      If the source system text is not easy to understand you might want to translate the categories. This will be visible in the cockpit as well.

      In the cockpit the view will be as follows. In the graph the different colours are displayed depending on the settings in the mapping.
      There are 3 different views in the cockpit table of hours.
      1. Yesterday – open the day on the plus sign.
        TKS excluded hours – depending on Tool choice (see below) there will be hours here from the PMI schedule or not. Departments with outsourced hours that are not part of any imported hours should be recorded here. Note that for collaborating hotels with shared resources (cluster positions), it can also be used to register negative hours, in case you have a scheduled employee spending time in another hotel.
        TKS Hours – this is the imported hours from any external system. Click on the row and a popup will show more detailed information.
        TKS Adjustment – should you want to adjust the TKS hours you untick the TKS Hours box and tick this box instead. Enter the new total number of hours.
      2. Within Schedule Horizon.
        TKS excluded hours – from schedule, sum of the day, both if you have persons in schedule + unspecified row.
        TKS Hours – if you have future hours from external system (see below settings) it will be displayed here in Bold Red, indicating it is the future. You may click the row and a popup will show more detailed information.
        TKS Adjustment – not possible to do anything with this for future hours.
      3. Beyond Schedule Horizon.
        All is ignored and the SMART forecast is populating the day.

      Tools

      Only accessible by Administrator User Rights. Contact the Administrator for your property if needed.

      When setting up this TKS import it is very important to be very clear of what the TKS will export to PMI. The settings in the cockpit are depending on what is exported to PMI.

      • Enable TKS – if the property is using external system for recording historical hours this needs to be enabled
      • Use TKS Future hours – if the property is using external system for scheduling hours this needs to be enabled
      • Ignore scheduled historical hours – if the schedule in PMI is used for scheduling hours but an external system is used for historical hours this needs to be ticked. If not you will get the scheduled hours from the schedule in PMI in the cockpit for yesterday as well as the imported hours from TKS.
      • Ignore scheduled historical Unspecified hours – should the hotel use PMI schedule but not on person level and put all hours in Unspecified this needs to be ticked in order to not get these hours into the cockpit for yesterday. Should the property use Unspecified to enter Outsourced hours that you want to be transfered to cockpit for yesterday you need to untick this box.
      • FTE – this enable to see FTE in the schedule instead of hours
      • Schedule Horizon – when ticked PMI lets you set the amount of days you want to schedule for in the future. Either how far out you have an import of external hours or how far out in the future you want to manually schedule in PMI schedule. See pictures below how Schedule Horizon is displayed in Cockpit and Schedule, between the red line (today) and the green line, is the Schedule Horizon. Beyond the green line there is an option to use schedule hours but if you do not have schedule that far out you may let PMI enter the Smart Forecast. The Horizon is set in the settings in cockpit and you decide per cockpit how many days the Horizon is.
      • Use SMART forecast beyond schedule Horizon – PMI will enter the SMART forecasted hours per day BEYOND the imported hours or manually entered hours in the PMI Schedule.

      In the Cockpit graph overview you can choose to see how you have scheduled BEYOND the horizon by clicking the Schedule graph at the bottom.

      Refresh TKS

      This function is dependant on your TKS integration. If you have made changes to your actual hours and schedule and want the changes to be reflected in PMI as well, you can refresh the TKS. 

      Refresh TKS is found under Tools. Define the date range you want to refresh and click OK. The range between the dates is pre-programmed but can be manually changed each time a refresh is needed.

      This option is available in both the Cockpit and Schedule modules. Any updates only apply to the specific department you are in.

      In Time Keeping Mapping Tools you may use the Mapping TKS to change the name of the TKS system.

      Here you may also Print the Departments or Categories to excel or PDF.

      r

      Troubleshooting tips

      This section provides additional troubleshooting advice for readers experiencing specific issues. While it’s packed with useful insights, you may skip it if you’re not facing any related problems.

      Scheduled Horizon Misunderstanding

      The Scheduled Horizon in the labor cockpit is a common source of confusion. It's important to understand that adjusting the Scheduled Horizon does not affect the import of hours from your TimeKeeping System (TKS).

      show more

      ​The Scheduled Horizon setting is mainly used to determine how many days into the future you can see in your cockpit. It does not control or extend the number of days for which data is imported from your TKS . If you're not seeing the expected data in your cockpit, it's likely an issue with the TKS data or the mapping settings, not the Scheduled Horizon.

      show less

      Incorrect codes in TKS

      Make sure the correct codes have been used in your TKS. If the hours are still not correct after the next import, there may be an error in the mapping – please contact your controller who will make the necessary changes.

      TMS – Kronos
      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.
      Because the Time interfaces are still maintained in the old import structure, their name starts with: ‘I_T7_DD_’.

      Interface name incl. version
      I_T7_DD_KRONOS_TIME_V002
      Comment
      File name pattern: Kronos_pmitime*
      Columns
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      Name
      LABORLEVELNAME1
      LABORLEVELDSC1
      LABORLEVELNAME2
      LABORLEVELDSC2
      APPLYDATE
      PAYCODEID
      PAYCODENAME
      LABORLEVELNAME3
      LABORLEVELDSC3
      PERSONNUM
      TIMEINSECONDS
      1
      2
      3
      4
      5
      6
      7
      8
      PMI data element (target)
      Property Name
      Department Name
      Date
      TimeCategory
      JobCategory
      Staff ID
      Hours
      Approved
      Description
      Name of the property (hotel, restaurant)
      Name of the department within the property
      Working date (timesheet)
      Name of the time category
      Name of the job/task category
      ID of the staff (employee)
      Number of hours (on the timesheet)
      If the hours are approved or not
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Data transformation/load rules
      Directly mapped from source file
      Directly mapped from source file
      Directly mapped from source file
      Directly mapped from source file
      Directly mapped from source file
      Directly mapped from source file
      Directly mapped from source file
      Approved and to-be-approved hours exist. Loading rule: only import approved hours
      Data element (source)
      LABORLEVELDSC1
      LABORLEVELDSC2
      APPLYDATE
      PAYCODENAME
      LABORLEVELDSC3
      PERSONNUM
      TIMEINSECONDS
      Not in source file
      Comment
      Property name is used to validate if the row needs to be imported (hard coded).
      Original header: sum( cast( [TIMEINSECONDS] as decimal ) / 3600 )
      All hours included in the file are approved
      Download an example of the source file format: File:I T7 DD KRONOS TIME V002.zip
      TMS – Mirus
      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      PMI data element (target)
      Property ID
      Property Name
      Department ID
      Department Name
      Date
      TimeCategory ID
      TimeCategory Name
      JobCategory ID
      JobCategory Name
      Staff ID
      Hours
      Approved
      Description
      ID of the property (hotel, restaurant)
      Name of the property (hotel, restaurant)
      ID of the department within the property
      Name of the department within the property
      Working date (timesheet)
      ID of the time category
      Name of the time category (e.g. Fixed Salary, Absence)
      ID of the job category
      Name of the job category (e.g. Servers, Managers)
      ID of the staff (employee)
      Number of hours (on the timesheet)
      If the hours are approved or not
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Optional
      Mandatory
      Mandatory
      Mandatory
      Data transformation/load rules
      Does not exist in file. ID provided by local PMI agent
      Does not exist in file. ID provided by local PMI agent
      3rd column (from left in the file)
      Does not exist in file
      1st column (from left in the file)
      4th column (from left in the file)
      Does not exist in the file
      Does not exist in the file
      Does not exist in the file
      2nd column (from left in the file)
      5th column (from left in the file)
      Does not exist
      Mirus data element (source)
      N/A
      N/A
      3rd column
      N/A
      1st column
      4th column
      N/A
      N/A
      N/A
      2nd
      5th column
      N/A
      Comment
      All hours in the file are approved hours. Non-approved hours are excluded in the export setting in Mirus.
      TMS – Planday
      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      PMI data element (target)
      Property ID
      Property Name
      Department ID
      Department Name
      Date
      TimeCategory ID
      TimeCategory Name
      JobCategory ID
      JobCategory Name
      Staff ID
      Hours
      Approved
      Description
      ID of the property (hotel, restaurant)
      Name of the property (hotel, restaurant)
      ID of the department within the property
      Name of the department within the property
      Working date (timesheet)
      ID of the time category
      Name of the time category (e.g. Fixed Salary, Absence)
      ID of the job category
      Name of the job category (e.g. Servers, Managers)
      ID of the staff (employee)
      Number of hours (on the timesheet)
      If the hours are approved or not
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Optional
      Mandatory
      Mandatory
      Mandatory
      Data transformation/load rules
      Exists but not used. See Property Name below
      Directly mapped to source equivalent
      Exists but not used. See Department Name below
      Directly mapped to source equivalent
      Derived from date and time string
      Exists but not used. See TimeCategory Name below
      Mapped to PMI equivalent
      Exists but not used. See JobCategory Name below
      Directly mapped to source equivalent
      Exists but not used
      Exists in minutes. Transformation rule: minutes divided by 60 to get number of hours in PMI
      Approved and to-be-approved hours exist. Loading rule: only import approved hours
      Planday data element (source)
      PortalId
      PortalName
      DepartmentId
      DepartmentName
      Start
      TimesheetTypeID
      TimesheetTypeName
      EmployeeGroupID
      EmployeeGroupName
      EmployeeID
      Minutes
      TimeSheetApproved
      Comment
      This is needed to separate productive and non-productive hours.
      Not presented at staff level, but at job category and date level.
      All hours included in the file are approved in Planday.
      TMS – PPE
      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      PMI data element (target)
      Property ID
      Property Name
      Department ID
      Department Name
      Date
      TimeCategory ID
      TimeCategory Name
      JobCategory ID
      JobCategory Name
      Staff ID
      Hours
      Approved
      Description
      ID of the property (hotel, restaurant)
      Name of the property (hotel, restaurant)
      ID of the department within the property
      Name of the department within the property
      Working date (timesheet)
      ID of the time category
      Name of the time category (e.g. Fixed Salary, Absence)
      ID of the job category
      Name of the job category (e.g. Servers, Managers)
      ID of the staff (employee)
      Number of hours (on the timesheet)
      If the hours are approved or not
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Optional
      Mandatory
      Mandatory
      Mandatory
      Data transformation/load rules
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Exists in minutes. Transformation rule: minutes divided by 60 to get number of hours in PMI
      Approved and to-be-approved hours exist. Loading rule: only import approved hours
      PPE data element (source)
      Not in use
      Property Name
      Not in use
      Department Name
      Date
      Not in use
      Type
      Not in use
      Cost Center Name
      Staff ID
      Hours
      Approved
      Comment
      / AZ, eventuelle über Weekly
      Type This is needed to separate productive and non-productive hours
      Not presented at staff level, but at job category and date level
      All hours included in the file are approved in PPE
      TMS – Protime
      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      NB. This export lacks property name and therefore needs to have each property defined in [TimeSystem_Properties_External] with the “Property ID” (from the source file).

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      PMI data element (target)
      Property ID
      Property Name
      Department ID
      Department Name
      Date
      TimeCategory ID
      TimeCategory Name
      JobCategory ID
      JobCategory Name
      Staff ID
      Hours
      Approved
      Description
      ID of the property (hotel, restaurant)
      Name of the property (hotel, restaurant)
      ID of the department within the property
      Name of the department within the property
      Working date (timesheet)
      ID of the time category
      Name of the time category (e.g. Fixed Salary, Absence)
      ID of the job category
      Name of the job category (e.g. Servers, Managers)
      ID of the staff (employee)
      Number of hours (on the timesheet)
      If the hours are approved or not
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Optional
      Mandatory
      Mandatory
      Mandatory
      Data transformation/load rules
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      Exists in minutes. Transformation rule: minutes divided by 60 to get number of hours in PMI
      Approved and to-be-approved hours exist. Loading rule: only import approved hours
      Protime data element (source)
      PropertyID
      Property Name
      Not in use
      DepartmentName
      Date
      Not in use
      Type
      Not in use
      PayCodeName
      StaffID
      Hours
      Approbation
      Comment
      Not always reliable.
      Empty = true
      TMS – Tidsbanken

      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      PMI data element (target)
      Property ID
      Property Name
      Department ID
      Department Name
      Date
      TimeCategory ID
      TimeCategory Name
      JobCategory ID
      JobCategory Name
      Staff ID
      Hours
      Approved
      Description
      ID of the property (hotel, restaurant)
      Name of the property (hotel, restaurant)
      ID of the department within the property
      Name of the department within the property
      Working date (timesheet)
      ID of the time category
      Name of the time category (e.g. Fixed Salary, Absence)
      ID of the job category
      Name of the job category (e.g. Servers, Managers)
      ID of the staff (employee)
      Number of hours (on the timesheet)
      If the hours are approved or not
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Optional
      Mandatory
      Mandatory
      Mandatory
      Data transformation/load rules
      Exists but not used. See Property Name below
      Directly mapped to source equivalent
      Exists but not used. See Department Name below
      Directly mapped to source equivalent
      Derived from date and time string
      Exists but not used. See TimeCategory Name below
      Mapped to PMI equivalent
      Exists but not used. See JobCategory Name below
      Directly mapped to source equivalent
      Exists but not used
      Exists in minutes. Transformation rule: minutes divided by 60 to get number of hours in PMI
      Approved and to-be-approved hours exist. Loading rule: only import approved hours
      Planday data element (source)
      PortalId
      PortalName
      DepartmentId
      DepartmentName
      Start
      TimesheetTypeID
      TimesheetTypeName
      EmployeeGroupID
      EmployeeGroupName
      EmployeeID
      Minutes
      TimeSheetApproved
      Comment
      This is needed to separate productive and non-productive hours
      Not presented at staff level, but at job category and date level
      All hours included in the file are approved in Planday
      TMS – Timeplan
      The table below shows the data relationship between PMI data elements/fields (target) and corresponding source data elements/fields (source).

      You will find the transformation/load rules meant to explain any programmatic manipulation and calculation applied in the adapter to get the desired data format and/or result in the PMI staging table where such have been applicable.

      An example of the source file data, format and structure is also attached below the table.

      This table will be updated whenever the source file or the adapter in question are changed throughout the interface life-cycle.

      NB.This import uses the HIDXXX folder structure and the hard coded “siteId” to determine the property. This means that the property needs to be defined in the TimeSystem_Properties_External table.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      PMI data element (target)
      Property ID
      Property Name
      Department ID
      Department Name
      Date
      TimeCategory ID
      TimeCategory Name
      JobCategory ID
      JobCategory Name
      Staff ID
      Hours
      Approved
      Description
      ID of the property (hotel, restaurant)
      Name of the property (hotel, restaurant)
      ID of the department within the property
      Name of the department within the property
      Working date (timesheet)
      n/a
      Name of the time category (e.g. Fixed Salary, Absence)
      ID of the job category
      Name of the job category (e.g. Servers, Managers)
      ID of the staff (employee)
      Number of hours (on the timesheet)
      If the hours are approved or not
      Mandatory / Optional
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Mandatory
      Optional
      Optional
      Mandatory
      Mandatory
      Mandatory
      Data transformation/load rules
      n/a
      n/a
      n/a
      Directly mapped to source equivalent
      Directly mapped to source equivalent
      n/a
      n/a
      Directly mapped to source equivalent but is numeric
      n/a
      Exists in minutes. Transformation rule: minutes divided by 60 to get number of hours in PMI
      n/a
      Timeplan data element (source)
      Costcenter
      Date
      Account
      Balance
      Everything is treated as approved.
      How to trigger a new Planday TKS export file

      To trigger a new export in Planday, go to Settings > Portal settings section > Scheduled jobs

      The transfer runs on a schedule, specific for each portal. To trigger a “manual” transfer, the time
      must be changed to a time in the near future. For example, if you are missing an import at 07:00, you can change the export time to 07:30 and Planday will generate the report.