Oznaka NAKNADNE DOSTAVE RČUNA

Nov 5, 2012 at 12:02 PM

Citat iz tehničke specifikacije glasi :

"Oznaka naknadne dostave računa .
Pod naknadnom dostavom računa Poreznoj upravi smatra se situacija kad je isti
prethodno izdan kupcu bez JIR-a (npr. prekid Internet veze ili potpuni prestanak
rada naplatnog uređaja). True ako je riječo naknadnoj dostavi računa, u suprotnom false.
Boolean (1-true/0-false)"

Ovo mi se ne čini jednostavno koliko izgleda.

Naime iz te definicije proizlazi ,barem za mene nekoliko dilema.

1. U našim primjerima mi koristimo Boolean true ili false (predpostavljam da je ovo veliko slovo na T na True pogreška jer sa njim ne prolazi).

Međutim isto tako uredno prolaze i brojevi 1 ili 0 ,pa je iz gornjeg citata upitno koji su oznake ispravne.

2.U kontekstu sljednosti računa , dali je riječ o naknadnoj dostavi računa , ako se šalje račun koji je ranije proknjižen u Knjigu izlaznih računa a nije poslan u CIS - te nije predan kupcu.

I sve to ukoliko su računi sa večim brojem poslani u CIS.

Znači dali je samo uvijet "fizičke predaje računa kupcu bez JIR_a" , uvjet za stavljanje oznake naknadne dostave, ili se račun šalje "NAKNADNO" i ako je ranije poslan koji račun sa večim brojem.

Coordinator
Nov 5, 2012 at 1:02 PM

Oznaka naknadne dostave računa je Boolean tip, znači - "T" ne prolazi i tako i treba biti :) Treba proći samo 1 ili 0 i to je ispravno. Ako si u dilemi kod ovakvih stvari, probaj instalirati Xml Spy ili neki sličan tool kojim možeš na svojoj strani, bez slanja u CIS, provjeriti da li je tvoj XML u skladu sa XSD schemom.

Nov 5, 2012 at 1:17 PM

Ma problem je u tome da usprkos raznim specifikacijama - svašta prolazi i uredno dobiva JIR..

Pod velikim T"" sam mislio da "True" iz njihove "tehničke specifikacije"  nije točan jer prolazi samo kao "true" .

A osim toga nejasno (čitaj nepotrebno) je uopče spominjanje broja 1 ili 0 u tehničkoj specifikacili - ali i ti brojevi prolaze.

Nov 5, 2012 at 1:46 PM
Edited Nov 5, 2012 at 1:47 PM

citiram : "2.U kontekstu sljednosti računa , dali je riječ o naknadnoj dostavi računa , ako se šalje račun koji je ranije proknjižen u Knjigu izlaznih računa a nije poslan u CIS - te nije predan kupcu."

Kupcu fizički račun daješ odmah, bez obzira na to što na njemu nema JIRa. Cijela je ideja da se nevini kupac ne zadržava zbog tamo nekakvih tehničkih problema.

Kasnije (ali u roku od dva dana), omogući da tvoja aplikacija ponovno zahvati taj isti račun i dostavi ga CISu, te za njega napokon i dobije JIR. Pri tom ponovnom slanju se diže flag za naknadnu dostavu računa.  Jir se upiše u bazu i to je to. 

Nema NIKAKVE veze s knjigom I-RA i sličnim knjigovodstvenim dokumentima! Odnosno ako ti taj račun ODMAH knjižiš u I-RA, slobodno ga proknjiži jer to nema veze s postojanjem JIRa !

Nema nikakve veze što je nakon manjeg broja računa, poslan veći broj računa ili obrnuto.

"Slijednost računa" znači da jedan naplatni uređaj mora generirati račune od 1 do X u jednoj knjigovodstvenoj godini.

Kasnije, u knjizi I-RA na primjer, u polju "oznaka računa", može postojati nekoliko računa s rednim brojem 1 ali svaki od njih ima drugačiju oznaku naplatnog uređaja. (ako si na to mislio).

Nov 10, 2012 at 10:47 AM

Vezano uz rok naknadne dostave računa , dali mislite da CIS uopče neće prihvačati račune  sa danom izdavanja dužim od dva dana , i kakav je onda postupak dostave tih "zastarjelih računa" računa.

I šta je to uopče dva dana , dali je to od 23,59 u srijedu navečer do 00,01 u četvrtak ponoći (to je 24 sata i 2 sekunde).

Neko bi trebao iz apisa objasniti specifkaciju da eventualno možemo u soft neke zaštitne mehanizme protiv zastare ugraditi.

Nov 10, 2012 at 11:20 AM

Ja mislim da će CIS sve to prihvatiti ali će porezna putem CISa imati interni report o takvim situacijama, pa će takva tvrtka imati uvećan "rizik" za porezni nadzor.
Možda će se, što sam isto negdje pročitao, morati osigurati i kakva potvrda od HAKOMa, providera i sl.

Očito je da će biti problema, pogotovo izvan većih gradova ... ali će se sve te situacije već nekako vremenom riješiti, propisati, odrediti ....