Hyvityslaskun luominen
Laskusta tulee hyvityslasku, mikäli sen summa on negatiivinen. Laskulla ei siis ole erillistä "hyvityslasku"-merkintää. Laskua ei myöskään voi linkittää hyvitettävään laskuun. Jos tieto esimerkiksi alkuperäisen laskun numerosta halutaan laskulle näkyviin, on se tuotava esimerkiksi Lisätietoja -kentässä.
Jotta käyttäjä löytää Procountorissa tuotavalla hyvityslaskulle helpommin hyvitettävän laskun sen alkuperäisen / muun järjestelmän numeron perusteella, voi myyntilaskun tuontikutsussa tuoda hyvitettäväksi tarkoitetun alkuperäisen laskunnumeron Myyjän muistiinpanot -kentässä (apissa kenttä 'notes'). Kenttä on tarkoitettu sisäisen tiedon välittämiseen, eikä siihen syötetty tieto tulostu laskun kuvalle.
Automaattisesti laskettujen viivästyskorkojen ja maksumuistutusmaksujen lisääminen automaattisesti APIn kautta tuoduille myyntilaskuille
API-rajapinnassamme ei ole toistaiseksi tukea huomautus- ja / tai viivästyskulujen lisäämiseksi automaattisesti APIn kautta tuotaville myyntilaskuille. Mahdollisia kerääntyneitä kuluja ei ole myöskään mahdollista hakea API-rajapinnan kautta.
Tällä hetkellä kertyneiden kulujen seuranta ja niiden laskutus tulisi tehdä Procountorin käyttöliittymän puolella. Kuluja vasten tulisi Procountorissa muodostaa käsin asiakkaalle uusi myyntilasku, joka sitten kerää kertyneet kulut ja korot.
Käyttöliittymässä on raportti, jonka kautta voi seurata asiakkaille kertyneitä perintä- ja viivästyskuluja. Perintä- ja viivästyskuluraportti -näkymälle pääsee kohdasta Raportointi > Perintä- ja viivästyskuluraportti. Lisätietoja ja tarkempi kuvaus löytyvät ohjekirjastamme: Perintä- ja viivästyskuluraportti
Viivästys- ja muistutuskulujen lisäyksestä rajapinnan kautta tuotaville laskuille on viety kehitystoive tuotekehitykseen, mutta toistaiseksi kyseistä ominaisuutta ei ole aikataulutettu. Tiedotamme API-rajapintamme uusista ominaisuuksista ja tulevista suunnitelmista kehittäjäsivustomme Release Notes -osiossa.
Factoring -laskut
Mikäli laskut luodaan Procountoriin API-rajapinnan kautta, laskulle on mahdollista laskun luonnin yhteydessä määrittää käytettävä rahoitussopimus. Tällöin laskulle tulisi lisätä halutun rahoitussopimuksen ID "factoringContractId". Ympäristöön tallennetut rahoitussopimukset ovat noudettavissa rajapinnan kautta GET /factoringcontracts -endpointin avulla (tämä palauttaa mm. tuon tarvittavan ID:n joka on siis eri kuin sopimusnumero).
Mikäli laskulle lisää rahoitussopimuksen, niin tilinumeron "accountNumber" tulee olla rahoitussopimukselle tallennettu rahoitusyhtiön tilinumero. Jos laskulla ei tuoda siirtolauseketta "factoringText", täydentää Procountor rahoitussopimukselle tallennetun siirtolausekkeen laskulle. Jos laskun mukana tuodaan siirtolauseke, käytetään laskulla aineistolla tuotua siirtolauseketta.
Jos Procountorista on valmis (sisäänrakennettu) yhteys valittuun rahoitusyhtiöön, jossa Hyväksy-painikkeen painalluksesta myyntilasku lähtee rahoitusyhtiölle, niin myös APIn kautta tehty hyväksyntä siirtää laskun rahoitusyhtiölle.
Varastotuotteiden saldojen päivittyminen (varastotapahtumien muodostuminen) API-integraation kautta tuoduissa laskuissa
Varastotuotteiden saldot EIVÄT päivity API-rajapinnan kautta tapahtuvassa laskun hyväksynnässä (PUT /invoices/id/approve).
Lasku tulee siirtää ja jättää Kesken-tilaan, ja suorittaa laskun hyväksyntä käyttöliittymässä käyttäjän toimesta siirron jälkeen.
Myyntilaskujen luominen kuluttajaverkkolasku- ja suoramaksuasiakkaille
Kun uusi lasku luodaan kuluttajaverkkolaskuasiakkaalle APIn kautta, on lasku kohdistettava (partnerId:llä, henkilötunnuksella tai asiakasnumerolla) Procountorin asiakasrekisterin asiakkaaseen. Laskun on kohdistuttava asiakkaaseen, jonka kuluttajaverkkolaskujen vastaanottoilmoitus on vastaanotettu ja käsitelty. Laskulle on rajapinnan kautta tuotava laskukanavana ("invoiceChannel") verkkolasku (ELECTRONIC_INVOICE) sekä vastaanottoilmoituksella saapunut verkkolaskuosoite.
Lisätietoa kuluttajaverkkolaskuista löydät ohjeesta: Kuluttajaverkkolasku
Suoramaksu ("paymentMethod": "DIRECT_PAYMENT") maksutavan tuominen laskulle APIn kautta edellyttää, että asiakkaalle on Procountorissa kohdistettu suoramaksujen vastaanottoilmoitus ja että lasku kohdistetaan suoramaksuasiakkaaseen "partnerId":n avulla. Maksutavan ollessa suoramaksu, laskukanavan ("invoiceChannel") on oltava Posti (MAIL) tai Sähköposti (EMAIL). Tämä on se kanava, jota kautta suoramaksusta kertova lasku lähetetään asiakkaalle.
Tämän lisäksi kutsulle on lisättävä "counterParty":n sisälle verkkolaskuosoite "einvoiceAddress". Tämän arvona tulisi olla se verkkolaskuosoite ja -operaattori, joka asiakkaalla on asiakasrekisterissä. Verkkolaskuosoite on se osoite, jonne pankille lähetettävät laskutiedot suoramaksusta lähetetään ja joka täydentyy automaattisesti asiakkaan tietoihin vastaanottoilmoituksen käsittelyssä.
Lisätietoa suoramaksuista löydät ohjeesta: Suoramaksu
Viitenumero
Viitenumero on mahdollista muodostaa APIn kautta seuraavasti:
-
Procountor muodostaa oman viitenumeron automaattisesti, jos kutsussa viitenumeron arvo on tyhjä "bankReferenceCode": ""
-
Jos viitenumeroksi halutaan lisätä oma viitenumero, täydennetään se bankReferenceCode:n arvoksi. Viitenumeroformaatin oikeellisuus tarkistetaan.
-
Mikäli bankReferenceCode jätetään kutsusta kokonaan pois, ei laskulle lisätä viitenumeroa.
Viitenumero on pakollinen, mikäli laskukanavana on verkkolasku.
Laskunumero
Procountor generoi aina oman juoksevan laskunumeronsa varsinaiseksi laskunumeroksi. Toisen järjestelmän laskunumeroa ei ole mahdollista käyttää varsinaisena laskunumerona.
Toisen järjestelmän laskunumeroa varten laskuaineistolla on elementti originalInvoiceNumber, jota varten Procountorin käyttöliittymässä on tositteiden haussa ja laskunäkymällä oma kenttänsä, johon tieto siirtyy. Original_invoice_number - Ulkopuolisen järjestelmän laskunumero -kenttä myyntilaskulla -erikoisoikeus voidaan aktivoida asiakaspalvelun kautta. Toisen järjestelmän laskunumero toimii sisäisenä tietona, eikä se näy asiakkaalle menevällä laskulla.
Myyntilaskun kohdistaminen asiakasrekisteriin API-rajapinnassa
Myyntilaskun voi kohdistaa asiakasrekisteriin API-rajapinnassa.
Jos käyttöasetuksissa on ruksittu kohta "Perusta asiakkaat laskun luonnin yhteydessä", Procountor luo tällöin asiakkaat myös APIn kautta tulleilta myyntilaskuita. Asetuksen ollessa päällä perustetaan uusi asiakas rekisteriin automaattisesti ensimmäisen laskun tallennuksen yhteydessä. Ennen uuden asiakkaan perustamista tarkistetaan onko asiakas jo rekisterissä ja jos on, kohdistetaan lasku siihen. Kohdistaminen voidaan tehdä kannan ID:n eli partnerId:n, y-tunnuksen (identifier), asiakasnumeron (customerNumber) tai nimi- / osoitetietojen (nimen ja osoitteen oltava täsmälleen samassa kirjoitusmuodossa) perusteella.
Kannattaa huomioida, että mikäli lasku kohdistetaan asiakkaaseen, asiakasrekisteristä ei kuitenkaan käydä poimimassa mahdollisesti puuttuvia tietoja. Ainoastaan mahdollinen oletusdimensio ja -kirjanpitotili saadaan asiakkaan takaa rekisteristä, mikäli lasku kohdistuu rekisterissä olevaan asiakkaaseen. Kohdistamisella on siis mahdollista tehdä linkitys laskun ja asiakkaan välille, mutta tämä ei kuitenkaan hae asiakkaan tietoja rekisteristä laskulle, vaan kaikki tarvittavat tiedot tulisi tuoda laskun luonnin yhteydessä.
Jos laskussa ei käytetä partnerID:tä, vaan tuodaan y-tunnus ja asiakasnumero ja jos samalla asiakasnumerolla Procossa onkin eri asiakas (eli eri y-tunnus) rekisterissä, niin kohdennus tapahtuu tällöin y-tunnuksen perusteella. Y-tunnus on siis vahvin tunniste partnerID:n jälkeen.
Ostolaskun kohdistaminen asiakasrekisteriin API-rajapinnassa
Jos käyttöasetuksissa on ruksittu kohta "Perusta asiakkaat ja toimittajat ensimmäisen laskun luonnin yhteydessä", niin Procountor luo tällöin toimittajat myös APIn kautta tulleilta ostolaskuita. Asetuksen ollessa päällä, perustetaan uusi toimittaja rekisteriin automaattisesti ensimmäisen laskun tallennuksen yhteydessä. Ennen uuden toimittajan perustamista tarkistetaan, onko toimittaja jo rekisterissä ja jos on, kohdistetaan lasku siihen. Kohdistaminen voidaan tehdä kannan ID:n eli partnerId:n, y-tunnuksen (identifier), toimittajanumeron (customerNumber) tai nimi-/osoitetietojen (nimen ja osoitteen oltava täsmälleen samassa kirjoitusmuodossa) perusteella.
Kannattaa huomioida, että mikäli lasku kohdistetaan toimittajaan, toimittajarekisteristä ei kuitenkaan käydä poimimassa mahdollisesti puuttuvia tietoja. Ainoastaan mahdollinen oletusdimensio ja -kirjanpitotili saadaan toimittajan takaa rekisteristä, mikäli lasku kohdistuu rekisterissä olevaan toimittajaan kannan sisäisen partnerId:n avulla. Kohdistamisella on siis mahdollista tehdä linkitys laskun ja toimittajan välille, mutta tämä ei kuitenkaan hae toimittajan tietoja rekisteristä laskulle, vaan kaikki tarvittavat tiedot tulisi tuoda laskun luonnin yhteydessä.
Laskujen maksutapahtumat ja niiden tilat (Payment events)
PaymentMethodTypes
| PUT /invoices/{invoiceId}/ paymentevents/markpaid |
UI (FI) | UI (EN) | |
| EXTERNAL_BANK_TRANSFER | tilisiirto muualla | external bank transfer | |
| CASH | käteinen | cash | |
| CREDIT_NOTE | hyvityslasku | credit note | |
| CREDIT_LOSS | luottotappio | credit loss | |
| SET_OFF | kuittaus | set-off | |
| BANK_STATEMENT | tiliote | bank statement | |
| CHARGE_CARD | maksukortti | charge card | |
| CORRECTION | korjaus | correction | |
| ADJUSTMENT | oikaisu | correction |
| GET /invoices/{invoiceId}/ paymentevents |
UI | PaymentsType in DB |
| BANKTRANSFERELSEWHERE | tilisiirto muualla | 1 |
| CASH | käteinen | 2 |
| COMPENSATIONINVOICE | hyvityslasku | 3 |
| CREDITLOSS | luottotappio | 4 |
| CORRECTION | korjaus | 5 |
| SETOFF | kuittaus | 6 |
| BANKSTATEMENT | tiliote | 7 |
| CHARGECARD | maksukortti | 8 |
| ADJUSTMENT | oikaisu | 9 |
| REFERENCEPAYMENT | viitemaksu | 12 |
| OTHERPAYMENTMETHOD | muu maksutapa | 10 |
Myynneissä maksutapahtumalla voi olla tilana Maksettu, Maksettu muualla tai Osittain maksettu. Myyntien puolella maksutapahtuma saa oman tilansa, kun maksutapahtuma tallentuu; jos maksutapahtuma kohdistuu automaattisesti, niin tilaksi päivittyy Maksettu ja jos maksutapahtuma lisätään manuaalisesti, tilaksi päivittyy Maksettu muualla tai Osittain maksettu. Itse laskun tila määräytyy sen mukaan, mitä maksutapahtumia laskulle lisätään ja myös sen mukaan, mikä on maksutapahtumien arvo verrattuna laskun summaan. Jos maksutapahtumien summa on sama kuin laskun summa, saa lasku saman tilan kuin maksutapahtuma. Jos taas maksutapahtuman arvo on pienempi tai suurempi kuin laskun summa, tulee laskun tilaksi Osittain maksettu.
Laskujen mahdolliset tilat:
Myynti: Maksettu, Maksettu muualla, Osittain maksettu
Osto: Odottaa siirtoa pankkiin, Siirretty pankkiin, Maksettu, Maksettu muualla, Osittain maksettu
Maksutapahtuman tilaan vaikuttaa käyttäjän toimenpiteet kuten maksaminen, asettaminen maksetuksi muualla, kohdistaminen maksetuksi, maksujen peruutus / poisto.
Samoin vaikuttavat eri ajastetut toiminnot kuten paymenthandlerit, jotka siirtävät maksuja pankkiin sekä tiliotteiden ja viitemaksujen sisäänluku, joka kohdistaa laskuja / maksuja maksetuksi.
APIssa käytetyt laskujen tila-koodit
| Status | Tila käyttöliittymässä (FIN) | Tilan koodi Procountorin tietokannassa | Myyntilasku | Ostolasku | Matkalasku | Kululasku |
| EMPTY | ||||||
| UNFINISHED | Kesken | 1 | x | x | x | x |
| NOT_SENT | Lähettämätön | 2 | x | |||
| SENT | Lähetetty | 3 | x | |||
| RECEIVED | Vastaanotettu | 4 | x | x | x | |
| PAID | Maksettu | 5 | x | x | x | x |
| PAYMENT_DENIED | Maksukiellosssa | 6 | x | x | x | |
| VERIFIED | (Asia)tarkastettu | 7 | x | x | x | |
| APPROVED | Hyväksytty | 8 | x | x | x | x |
| INVALIDATED | Mitätöity | 9 | x | x | x | x |
| PAYMENT_QUEUED | Odottaa siirtoa pankkiin | 10 | x | x | x | |
| PARTLY_PAID | Osittain maksettu | 11 | x | x | x | x |
| PAYMENT_SENT_TO_BANK | Siirretty pankkiin | 12 | x | x | x | |
| MARKED_PAID | Maksettu muualla | 13 | x | x | x | x |
| STARTED | ||||||
| INVOICED | Laskutettu | 15 | ||||
| OVERRIDDEN | ||||||
| DELETED | ||||||
| UNSAVED | Tallentamaton | |||||
| PAYMENT_TRANSACTION_REMOVED |
Ostolaskun tiedot eroavat alkuperäisen laskun tiedoista
API palauttaa ne tiedot, jotka Procountorissa laskulla on.
Kun lasku saapuu ohjelmaan verkkolaskuna, pyritään laskun tiedot ensisijaisesti muodostamaan sen mukaan, miten ne on esitetty verkkolaskuaineistolla. Procountor kuitenkin itsenäisesti tekee aineistolle tarkistuksia laskua muodostaessaan.
Verkkolaskuaineistolla esitetään erikseen laskun loppusumma ja erikseen tuoterivien tiedot. Procountorin automaattinen rivikäsittely katsoo, täsmääkö tuoterivien yhteissumma loppusummaan sentilleen. Jos nämä täsmäävät, muodostetaan rivitiedot sellaisenaan Procountoriin laskulle (eli alkuperäiset kappalemäärät ja muut rivin tiedot). Jos rivien yhteissumma ei täsmää loppusummaan, pyrkii rivikäsittely muokkaamaan rivien tietoja niin, että ne täsmäävät loppusummaan, sillä loppusumman on oltava aina sama kuin sähköisesti saadulla aineistolla esitetty loppusumma.
Procountorin automaattinen rivikäsittely toimii niin, että ensimmäisellä kierroksella aineisto yritetään lukea sisään täydellisillä tiedoilla (kappalehinta, määrä, rivinkokonaishinta yms.), mutta jos tässä vaiheessa rivitedot ja loppusumma eivät täsmää, niin sisäänlukua yritetään uudelleen vajaammilla tiedoilla. Yksi keino mitä Procountor käyttää koittaessaan täsmätä aineistoa on se, että kappalemääräksi laitetaan riville yksi, eli rivi koitetaan saada täsmäämään kokonaishinnan avulla.
Alennusprosentit valitettavasti usein aiheuttavat pieniä eroja laskennassa (kpl-määrä, yksikköhinta, alennus%, alv). Rivien yhteissumma täsmää loppusummaan sentilleen usein paremmin silloin, kun alennuksia ei ole käytetty. Mutta tämä ei tarkoita etteikö välillä voikin olla niin, että yhteissummat täsmäävät myöskin silloin kun alennuksia on käytetty.
Ensisijaisesti rivien tietoja pyritään saamaan ohjelmaan sellaisina kuin ne on esitetty aineistolla, mutta jos nämä tiedot eivät täsmää, koitetaan tietoja saada sitten vain tuoterivien yhteissummalla tarkemman kappalemäärän sijaan.
Verkkolaskuaineistojen välityksessä on muutenkin paljon liikkuvia osia, jotka voivat vaikuttaa siihen, millaisena aineisto toimitetaan Procountoriin. Lähettävä järjestelmä luo verkkolaskuaineiston, joka kulkeutuu lähettäjän verkkolaskuoperaattorille, joka sitten konvertoi sen vastaanottajan operaattorille, joka sitten toimittaa aineiston Procountoriin. Jo tässä matkalla saattaa konversio hieman vaikuttaa siihen, miten tiedot esitetään verkkolaskuaineistolla. Lopulta sitten vielä Procountorin päässä tehdään aineistolle tarkistus ja katsotaan täsmäävätkö tuoterivien yhteissumma laskun loppusummaan.
Ostolaskun hyväksymiskierron asetukset ja niiden käyttö APIn kautta tuoduilla ostolaskuilla
Jos "invoiceApprovalInformation" -elementtiä ei tuoda ollenkaan API-kutsussa (POST /invoices), käytetään ympäristökohtaisia asetuksia.
Jos lasku kohdistetaan toimittajaan partnerId:llä, käytetään toimittajan taakse asetettuja oletushyväksyjiä/asiatarkastajia.
Jos API-kutsussa tuodaan tyhjänä elementti "invoiceApprovalInformation": { }, ei hyväksyjiä ja asiatakastajia aseteta laskulle ollenkaan riippumatta ympäristön asetuksista tai oletuksista.