Projects and cost centers

Scenario outline

Many companies organize much of their work in projects. Some of them want to allocate some (or all) of their expenses to a project. The purpose could be to invoice clients for certain costs, or for internal cost control.

For an integration, the first question is whether you have a pre-defined list of available projects, or if employees should enter a project number manually? If you have a pre-defined list of projects and this list is longer than fifty or so items, or if it changes frequently, we recommend synchronizing them via our API.

Begin by creating a custom field in the Skovik UI, perhaps named "Project". You would then use the API to add or remove Custom Field Options regularly (usually via a daily or hourly cron-job).

Under this scenario we recommend the following approach.

📘

Cost Centers, Work Orders, Client IDs and More

While we use projects as an example here, all of this would be similar for other types of high-cardinality sets, for example cost centers, geographies, ship identifiers or any other category that you would like to display in Skovik as a drop-down list when employees register expenses in Skovik.

1. Find the data

Figure out which systems contain this information today. Sometimes everything will be stored in one place, but if not, you could either:
(a) pull from multiple sources
(b) adjust internal data flows so that everything is available in one place

In 99% of all cases, what you need is a label (for example a project name) and a value (computer-read value, often digits or letters). Sometimes the value and the label are the same.

2. Write the code

The integration code itself will be event based (when a project is created or removed) or scheduled (say every 12 hours). Both will work equally well from our perspective, but event-based integrations are less common. We usually recommend the scheduled-based approach.

Scheduled integration

The scheduled script will run every few hours and do something along these lines:

1. Extract a list of projects from your system (or systems).

2. Extract a list of projects in Skovik (via a series of GET requests, using pagination).

3. Iterate through the list from your system, compare each project with the data in the list pulled from Skovik, and put each item into one of three groups: (a) missing in Skovik, (b) should be removed from Skovik and (c) no action required.

4. For each group, make the relevant POST or DELETE request to add or remove these projects in Skovik.

• The steps 1-4 should all occur during one "run" of the scheduled script.
• When steps 1 and 2 are completed you'll have two in-memory lists, for example two arrays of dicts.
• During step 3 you'll create three new lists, corresponding to the desired changes in Skovik.
• In the 4th step you'll make the relevant requests to Skovik, effectively synchronizing your system with ours.

Event-based integration

When an event is triggered (a project is added/updated/removed), make the appropriate HTTP request to Skovik.

More than 5,000 projects

For large numbers of projects, note that the paginated requests are limited to 100 items per request. So for 20,000 projects there would be 200 requests to know the "current state". This works, but it takes 1-2 minutes. For a large number of cases, storing the synchronization state on your end (knowing what's already synced to Skovik) will make this quicker.

The event-based integration would also work better when the number of items is large.

3. Same list for everyone or scoped per employee

Most companies will want to use the same list for everyone. But there is also the option of showing unique subsets from the list to individual users. This is handled via the "Assign Custom Field Option" API endpoint.