Laskentakohteiden uudistukset - Voimassaoloaika ja muutokset integraatioihin

Netvisorin laskentakohteiden käsittely uudistuu. Julkaisemme muutokset lähiviikkoina. Tiedotamme viikkojulkaisutiedotteella, kun muutokset ovat käytettävissänne. Tuomme Netvisoriin tuen erillisille laskentakohteiden tunnisteille ja voimassaoloajoille.

Uusi voimassaoloseuranta varmistaa, että yrityksenne käytössä ovat vain ajantasaiset laskentakohteet. 

Lisäämme laskentakohteille yksiselitteisen tunnisteen, joka takaa virheettömän tiedonsiirron integraatioissa ja helpottaa täsmäytystä eri järjestelmien välillä. Tämä poistaa nimikkeiden samankaltaisuudesta johtuvat epäselvyydet.

Mikä muuttuu laskentakohteiden käsittelyssä?

Taloushallinnon arjessa laskentakohteet (kuten projektit tai kustannuspaikat) ovat kriittisiä raportoinnin kannalta. Uudistus vastaa asiakkaidemme tarpeisiin seuraavasti:

Voimassaoloajat laskentakohteille: 

Sekä laskentakohdeotsikot että yksittäiset kohteet tukevat jatkossa alkamis- ja päättymispäivämääriä. Toiminnon avulla voidaan laskentakohde asettaa käyttöön määräajaksi esimerkiksi projektin voimassaolon mukaisesti. Voimassaolon päättymisen jälkeen laskentakohde säilyy raportoitavana, mutta uudet kirjaukset sille estetään.

Vähemmän virheitä integraatiossa: 

Integraatioissa voidaan jatkossa estää kirjaukset kohteille, joiden voimassaolo on päättynyt.

Tunniste ja nimi erilleen: 

Voit jatkossa määritellä laskentakohteelle erikseen lyhyen tunnisteen (esim. P105) ja kuvaavan nimen (esim. Verkkosivuston uudistus).

Huomioitavaa uusien kenttien käyttöönotosta integraatioissa:

Mikäli käytössäsi on integraatioita Netvisorissa, varmistathan yhdessä integraation toteuttajan kanssa, että integraatio tukee uusia laskentakohdekenttiä ennen uusien tunniste- ja voimassaolokenttien lisäystä Netvisoriin laskentakohteille. Uusien kenttien käyttö rajapinnassa vaatii integraation toteuttajalta muutoksia integraatioon.

Huomioitavaa integraatiokumppaneille

Uudistus on merkittävä julkisen Netvisor-rajapinnan osalta. Kehittäjien on hyvä huomioida seuraavat tekniset muutokset. Päivitämme tukisivuston resurssien dokumentaatiot kun muutokset on tuotu tuotantoon. Suosittelemme siirtymistä uusiin code- ja label-kenttiin, sillä ne ohittavat vanhan yhdistelmäkentän, kun molemmat on annettu.

1. Uudet kentät ja hierarkia (POST)

Kaikkiin keskeisiin POST-rajapintoihin (kuten accounting.nv, salesinvoice.nv, workday.nv) on lisätty tarkemmat elementit:

• code / dimensionItemCode: Laskentakohteen tekninen tunniste.

• label / dimensionItemName: Laskentakohteen selkokielinen nimi.

• Hierarkian hallinta: Uudet kentät fatherCode ja fatherLabel mahdollistavat ylätason laskentakohteiden määrittelyn aiempaa tarkemmin.

2. Älykkäät kyselyparametrit tuontiin

Voit ohjata tuontikäyttäytymistä kahdella uudella vapaaehtoisella parametrilla:

• checkdimensionvalidityperiod: Rajapinta hylkää tuonnin, jos kohde ei ole voimassa tositteen päivämääränä

• useonlyexistingdimensions: Estää uusien laskentakohteiden automaattisen luonnin. Jos koodia ei löydy, rajapinta palauttaa virheen.

3. Taaksepäin yhteensopivuus ja GET-vastaukset

Olemme huolehtineet siitä, etteivät nykyiset integraatiot rikkoudu:

• Yhdistelmänimi: Vanha DimensionItem-kenttä palauttaa jatkossa yhdistelmänimen (tunniste + nimi, esim. "P001 Verkkosivuston uudistus"). Integraatiot, jotka ovat lukeneet tästä vain nimeä, näkevät jatkossa tunnisteen nimen edessä.

• Poikkeukset: Tietyissä rajapinnoissa (kuten getpurchaseinvoice.nv) olemassa oleva nimikenttä säilyy muuttumattomana, ja tunniste on lisätty sen rinnalle omana kenttänään.

• Ehdollisuus: Uudet kentät sisältyvät vastaukseen vain, jos vastaava arvo on asetettu.

  
  
  

Dimension Updates — Validity Periods and Integration Changes

Netvisor's handling of dimensions is being updated. We are releasing the changes this week and will notify you via the weekly release bulletin once they are available.

We are introducing support for separate dimension identifiers and validity periods in Netvisor.

The new validity tracking ensures that only current, active dimensions are in use at your company. We are also adding a unique identifier for each dimension, which guarantees accurate data transfer in integrations and makes reconciliation across systems easier — eliminating ambiguity caused by similar-looking names.

What is changing in dimension handling?

Dimensions, such as projects or cost objects, are critical for financial reporting. This update addresses our customers' needs in the following ways:

Validity periods for dimensions Both dimension headers and individual items will support start and end dates. This allows a dimension to be set as active for a defined period, for example aligned with a project timeline. Once the validity period ends, the dimension remains available for reporting, but new entries against it are blocked.

Fewer errors in integrations Integrations can now be configured to reject postings to dimensions whose validity period has expired.

Separate identifier and name You can now define a short identifier (e.g. P105) and a descriptive name (e.g. Website Renewal) independently for each dimension.

Note on adopting the new fields in integrations

If you have integrations in Netvisor, please confirm with your integration provider that the integration supports the new dimension fields before adding the new identifier and validity fields to your dimensions in Netvisor. Using the new fields via the API requires changes on the integration provider's side.

Note for integration partners

This is a significant update to the public Netvisor API. Developers should take note of the following technical changes. We will update the resource documentation on the support site once the changes are live in production. We recommend migrating to the new code and label fields, as they take precedence over the legacy combined field when both are provided.

1. New fields and hierarchy (POST) More granular elements have been added to all key POST APIs (such as accounting.nv, salesinvoice.nv, workday.nv):

• code / dimensionItemCode — The technical identifier for the dimension item.

• label / dimensionItemName — The human-readable name for the dimension item.

• Hierarchy management — New fatherCode and fatherLabel fields allow parent-level dimensions to be specified with greater precision than before.

2. Smart query parameters for import Two new optional parameters allow you to control import behavior:

• checkdimensionvalidityperiod — The API will reject the import if the dimension is not valid on the voucher date.

• useonlyexistingdimensions — Prevents automatic creation of new dimensions. If the code is not found, the API returns an error.

3. Backward compatibility and GET responses 

We have ensured that existing integrations are not broken:

• Combined name — The legacy DimensionItem field will now return a combined name (identifier + name, e.g. "P001 Website Renewal"). Integrations that previously read only the name from this field will now see the identifier prepended.

• Exceptions — In certain APIs (such as getpurchaseinvoice.nv), the existing name field remains unchanged, and the identifier has been added alongside it as a separate field.

• Conditionality — New fields are only included in the response if a corresponding value has been set.