JIR ne prolazi??!!

Jan 14, 2013 at 4:15 PM
Edited Jan 14, 2013 at 4:18 PM

Ekipa, da podjelim iskustvo te zatrazim pomoc.

U petak (11.01.2013) me probudi porezna, neispravni računi, jir i ostalo... da kad bi dosao u poreznu nisu proknjizili neki PBO dokument pa je sustav odbijao provjeru JIR-a za jedan lokal (da bi se jav)ili kroz 2-3 sata da je sve ok.

Danas novi problem racuni od 8.1.2013 od otprilike 11:00h (izdani prije sve ok) pa na dalje ne prolaze provjeru niti po ZKI niti po JIR-u GREŠKA (Račun nije evidentiran u Poreznoj upravi. Relevantna provjera je 48 sati od trenutka izdavanja računa. Ako ni tada nije evidentiran, molimo dostavite isti u ispostavu Porezne uprave.), odmah sam posumljao (u sebe) da nisam nesto zej....b sa novom verzijom aplikacije (jer sam premoren u zadnje vrijeme pa mozda je nesto promaklo) ali nisam, dobijam JIR od porezne, tako da kontam da je s te strane slanja i primanja ok.Bio u poreznoj ali oni samo prebacuju gresku na programera tj. mene.

Nisam imao mira nego trk u koš za smeće kopaj i trazi racune, da bi pronasao racun od Mlinara 11.01.2013 ne prolazi jir ista greska, racun od trgovine do mene 11.01. ista stvar, INA 12.01??!!! sve isto greška Račun nije evidentiran u Poreznoj upravi. bla, bla, bla...

Molim nekoga da provjeri racune iz datuma od 8.1 poslije 11h mozda i neki random dan izmedju 8.1. i 14.1.

Jel netko ima slican, isti problem ili nije problem do nas programera, hvala na pomoci.

Jan 14, 2013 at 5:21 PM

Jel netko provjerio "svoje" JIR-ove od 8.1.2013 do 14.01.2013?

Jan 14, 2013 at 5:44 PM

 

evo sada sam provjerio jedan račun INE od 11.01 i njega nema a provjerio sam i jedan od 07.01. taj je evidentiran

Jan 14, 2013 at 8:00 PM

Ne razumijem sto tocno muci poreznike koji su bili kod tvojeg klijenta, ali ako imas kompletan xml koji je CIS vratio za te sporne jir-ove onda nema problema jer kod tebe sve stima.

Jan 14, 2013 at 8:17 PM

Dao sam si malo truda pa sam provjerio na par korisnika taj po tebi sporni datum: svi su Racuni evidentirani u poreznoj upravi.

Daj ti provjeri kod  sebe, da li ti nije neka greska u programu pa u slucaju npr. Time Out-a ti to ne evidentiras nego priljepis prethodni JIR,. I sada normalno da taj racun kad kontroliras nije evidentiran jer se radi o drugim parametrima racuna, iznos, vrijeme itd su od prethodnog racuna.

Ovo "lupetam" onako na brzaka, posto za sada sa COM komponenton nisam imao stvarno nikakvih problema.

Jan 14, 2013 at 8:29 PM
Edited Jan 14, 2013 at 8:30 PM

Provjeri račun SMS-om jer onda trebaš upisati samo JIR ili zaštitni kod. Ako ti je račun pronađen onda ti u poruci dođu i vrijeme i iznos koji je evidenitran za taj JIR ili zaštitni kod. Ako ti ništa ne nađe za JIR ili zaštitni kod onda ti ništa nije evidenitrano u Poreznoj, a ako ti je pronađen barem ćeš znati koje je vrijeme i koji iznos evidenitran.

Kod provjere nekih računa koji nisu bili pronađeni putem Weba se ispostavilo da nije ispravno vrijeme (plus/minus jedna minuta) ili nešto drugo nije bilo u redu s podacima na računu.

Jan 14, 2013 at 8:35 PM
goranv13 wrote:

Dao sam si malo truda pa sam provjerio na par korisnika taj po tebi sporni datum: svi su Racuni evidentirani u poreznoj upravi.

Daj ti provjeri kod  sebe, da li ti nije neka greska u programu pa u slucaju npr. Time Out-a ti to ne evidentiras nego priljepis prethodni JIR,. I sada normalno da taj racun kad kontroliras nije evidentiran jer se radi o drugim parametrima racuna, iznos, vrijeme itd su od prethodnog racuna.

Ovo "lupetam" onako na brzaka, posto za sada sa COM komponenton nisam imao stvarno nikakvih problema.

Nisam ni ja imao problema s COM komponentom... kada mi ode u timeout, nema jir-a... jer zapisujem prvo u bazu pa onda saljem na potpis, nakon toga printam sta ima (ne moze ostati zadnji jir ni da hoce).

Jan 14, 2013 at 8:40 PM
mpapec wrote:

Ne razumijem sto tocno muci poreznike koji su bili kod tvojeg klijenta, ali ako imas kompletan xml koji je CIS vratio za te sporne jir-ove onda nema problema jer kod tebe sve stima.

nemam cijeli xml, imam jir-ove (ako sam dobio jir onda kontam da se zapisao racun u poreznoj)

Jan 14, 2013 at 8:41 PM
idesh1984 wrote:

Provjeri račun SMS-om jer onda trebaš upisati samo JIR ili zaštitni kod. Ako ti je račun pronađen onda ti u poruci dođu i vrijeme i iznos koji je evidenitran za taj JIR ili zaštitni kod. Ako ti ništa ne nađe za JIR ili zaštitni kod onda ti ništa nije evidenitrano u Poreznoj, a ako ti je pronađen barem ćeš znati koje je vrijeme i koji iznos evidenitran.

Kod provjere nekih računa koji nisu bili pronađeni putem Weba se ispostavilo da nije ispravno vrijeme (plus/minus jedna minuta) ili nešto drugo nije bilo u redu s podacima na računu.

 

Probat cu sms-om thx for tip :)

Coordinator
Jan 15, 2013 at 6:20 AM

Dobra praksa bi bila čuvati cijeli XML sa odgovorom, s obzirom da je on digitaltno potpisan od strane PU; ovo je teorija, da li će i u praksi eventualni nadzor to prihvaćati u slučaju nekih problema, tek ostaje za vidjeti :)

Jan 15, 2013 at 6:53 AM
mirkofodor wrote:
mpapec wrote:

Ne razumijem sto tocno muci poreznike koji su bili kod tvojeg klijenta, ali ako imas kompletan xml koji je CIS vratio za te sporne jir-ove onda nema problema jer kod tebe sve stima.

nemam cijeli xml, imam jir-ove (ako sam dobio jir onda kontam da se zapisao racun u poreznoj)

Kako ti je i Nino predlozio, snimaj poslane i prihvacene XML-ove.

Ako koristis COM, onsa sa :

myObject.SnimiXmlDokumentDatoteka

Jan 15, 2013 at 8:08 AM
Edited Jan 15, 2013 at 8:23 AM

Puno to podataka dođe da da se k svemu čuva još i cijeli ulazni i izlazni XML. A na koncu dođe li do kakvog suda ili sl. to će biti klimav dokaz obzirom da se XML može lako editirati. Već bi JIR sam po sebi trebao biti dovoljan obzirom da je rezultat višestrukih provjera i komunikacije s njima te se uglavnom ne može "izmisliti", tj izmisliti JIR je znatno teže nego dobiti "7" na lotu. Tužno je da i nakon dobivenog JIR-a čovjek mora misliti "što ako mi to ne priznaju"?

Koliko ja shvaćam stvari oni uopće nisu predvidjeli da "na njihovoj strani" nešto ne bi štimalo u softveru.

I to u situaciji kad znaju sve vaše lozinke obzirom da se njima "štiti" komunikacija.

Programeri i vlasnici blagajni na taj su način dovedeni i tehnički u izrazito neravnopravan položaj.

K tomu u prilog govori činjenica da je server "slabo uslužan" s stanovišta kontinuirane provjere dostupnosti ili naknadne provjere zaprimljenih JIR-ova kroz svaki lokalni sustav. Naime, da bi ljudi bili sigurniji mogli bi pustiti "provjeru" svojih zadnjih 1000/2000 JIR-ova u smislu da li su i kako zaprimljeni te na što se odnose.

Tako nešto uopće i nisu predvidjeli.

Valjda zato da sve skupa ne bude "pretransparentno".

Jan 15, 2013 at 8:31 AM

Nešto si grdo pomiješao. Potpisani XML je nepromjenjiv i ne kužim kako misliš da je on klimav dokaz? Digitalno potpisan dokument je punovažeći dokument, i ako ga imaš (xml) digitalno potpisanog tada nema nikakve sumnje u autentičnost. Možeš ga pročitati i validirati potpis po root ca i uvjeriti se da je došao upravo od PU, a digerstom kako je to upravo taj sadržaj. Imaš li dokument kod sebe ti imaš dokaz. O kakvim lozinkama govoriš? Privatni ključ nema nitko osim tebe i nikakve lozinke nikamo ne putuju. Čak i onaj referentni i autorizacijski kod postaju neupotrebljivi nakon generiranja certifikata. finan je nakon par dana rada servisa omogućila i opetovano preuzimanje, no kad je certifikat izgeneriran prvi put sa samo tebi znanom lozinkom čak i naknadno preuzimanje certifikata postaje besmisleno ukoliko nemaš lozinku kojom je zaštićen certifikat.

Iz tog razloga ja sve zahtjeve i sve odgovore (potpisane xml-ove) snimam. Za svaki dan se automatski pri prvom zahtjevu kreira dnevni zip i dalje u njega trpam potpisane xml-ove, odvojeno zahtjeve, odvojeno odgovore. Još je sve složeno da se može paralelno snimiti na neki eksterni medij. Trenutno baš radim jedan utility koji će proći po zahtjevima i dogovorima, i moći rekonstruirati tijek i povezanost dokumenata, pročitati dokumente, greške i sl.

 

Koristim vlastito riješenje za generiranje, potpis i soap komunikaciju no poanta je ista. Digitalno potpisan XML je punovaljan dokument.

Jan 15, 2013 at 8:31 AM

Ustvari xml se ne moze nastelati a da potpis ostane valjan (ako je nekome uspjelo nek javi?) i ako je porezna kojim slucajem izgubila JIR kojeg je izdala, takav JIR je dokazivo dobar s originalnom xml porukom. Isto tak ako se na sudu priznaje digitalni potpis poreznog obveznika, onda se valjda mora priznati isti takav od porezne? :)

 

Jan 15, 2013 at 8:45 AM

Možda i nije klimav s obzirom da čuvamo i cijeli xml sa potpisom, mi logiramo svu komuikaciju sa PU još od 10 mjeseca prošle godine. Ako kod njih nešto ne štima to bi bilo pogubno za cijeli projekt fiskalizacije, oni su imali dovoljno vremena sve testirati za razliku od nas. Server od PU sigurno ima funkcionalnosti koje nisu nama dostupne, pretpostavljam da funkcionalnost inserta na 80 Gb dnevno troši najmanje resursa pa ne bi trebali niti očekivati nove za nas.

Jan 15, 2013 at 9:07 AM

Ok, znaci preporucljivo je cuvati xml od porezne... uzet cu to u obzir (spremit u bazu za kasnije)... kako ste rijesili minute +- na racunima? tj. koje vrijeme stavite na racun prije potpisa ili nakon potpisa?

P.S.Oni racuni koje sam naveo u prijasnjem postu da ne prolaze, prosli su ako sam stavio +1min na vrijeme.

Jan 15, 2013 at 9:14 AM
mirkofodor wrote:

Ok, znaci preporucljivo je cuvati xml od porezne... uzet cu to u obzir (spremit u bazu za kasnije)... kako ste rijesili minute +- na racunima? tj. koje vrijeme stavite na racun prije potpisa ili nakon potpisa?

P.S.Oni racuni koje sam naveo u prijasnjem postu da ne prolaze, prosli su ako sam stavio +1min na vrijeme.

Pa na racun ide vrijeme koje je upisano u bazi ( ili ce se upisati u bazu ) !!!

Sa tim vremenom racunam ZK, potpisujem, saljem itd

Jan 15, 2013 at 9:14 AM

Kako misliš koje vrijeme? Postoji samo jedno jedino vrijeme, vrijeme izdavanja računa, koje je u milisekundu identično onome koje ispisuješ na papiru. Zaboravi ona vremena slanja ili primanja odgovora iz čvora zaglavlja i sl. To služi samo za internu uporabu tj. evidenciju i praćenje što je povezano s čime. Ono što pišeš na papir to šalješ u PU i to nema nikakve veze s time šalješ li to nakon 2 sekunde, 2 sata ili 47 sati i 59 minuta, vrijeme izdavanja je uvijek isto.  Kasnije jedino u re-generiranju ZKI-a. može anstati onaj problem sa sekundama, gdje smo se mislim uglavnom složili kako je mudro na bloku ispisati sekunde jer su one zahtjevana komponenta u generiranju ZKI, a rezanje sekundi na nulu bi zapravo bilo krivotvorenje podatka.

Jan 15, 2013 at 9:21 AM

Ako je tako onda su to bube ili kod nas ili u PU..

Jan 15, 2013 at 9:42 AM

@Veky, Osobno nemam nikakvih problema s fiskalizacijom te su sve provjere koje sam napravio s svojim korisnicima pozitivne a držim da mi je programsko rješenje zadovoljavajuće iako ne snimam XML (zato jer neću). Podaci snimljeni s računom moraju biti minimalno dovoljni za naknadno generiranje "istovjetnog" računa te da se u postupku regeneracije ni jedan od parametara na računu ne promijeni uključujući ZKI na koji utječe uz ostalo i vrijeme izdavanja, iznos i operater.

Umjesto optužaba kako netko nešto ne razumije a obzirom da ti imaš "svoja rješenja" uzmi u obzir sljedeće činjenice:

1) JIR je rezultat cijelog procesa generiranja dokumenta i komunikacije te mu kao takvom ne bi trebali "podrezultati" kojima se do njega došlo.

2) Nemaš nikakve mogućnosti regeneracije tog podatka unazad osim pojedinačne provjere da li je isti kod njih evidentiran u režimu "one-by-one".

3) Sigurnost osobnih lozinki u ovom slučaju ne postoji obzirom je izdavatelj certifikata i pružatelj usluge jedan te isti.

4) Svaki dokument nastao u takvim uvjetima može biti sporan u datom trenutku a u slučaju spora znamo tko je "slabija strana".

Sve to navodim zato jer se na forumu vidi da postoje ljudi koji imaju "tehničkih problema" s izvedbom fiskalizacije ili ne nalaze zaprimljene račune za koje imaju JIR. I ja vjerujem da je u pitanju njihov softver ali nitko ne garantira da bi moglo biti i nešto drugo. Tko ti jamči da će sud priznati tvoj XML dokument koji si sačuvao ako porezna to (iz nekog od mogućih razloga) nema zaprimljeno?

Ti sebe možeš hrabriti u pouzdanost svojih rješenja. Jednako će tako u slučaju spora porezna tvrditi da je nemoguće da se kod njih nešto "sfufljalo". U tom i takvom slučaju će o težini dokaza odlučivati netko treći (sud).

Jedina obrana od, po mom mišljenju, opravdane sumnje bila bi puštanje procesa naknadne provjere zaprimljenosti određenih JIR-ova iz baze korisnika (blagajne). A to kako vidimo uopće nisu predvidjeli.

 

 

Jan 15, 2013 at 11:14 AM

Mislim kako se i dalje ne razumijemo. Ako si dobio jir u nekom vremenskom okviru i identičnog ID-a. kao u zaglavlju zahtjeva tada je to poveznica tvog zahtjeva i njihovog odgovora. I zahtjev i dogovor su digitalno potpisani i sto ga su autentični i nepromijenjivi, a poveznica zahtjeva i odgovora je već spomenuti ID iz zaglavlja. Prema tome ti dobiješ JIR za svoj zahtjev i imaš pravno valjan dokaz o tome, a gdje ga i zašto oni nisu evidentirali to je njihov problem.  I dalje mi nije jasno što želiš reći, kako je sve jedna velika teorija zavjere i kako Fina ima  mala vrata na koja dila lozinke exportanih certifikata u PU jer su sami sebi Trusted root?

I nije bitna pouzdanost mog riješenja ni to što sam ga sam razvio (navedeno je samo kao podatak da se ljudi čudili ako ja npr.  snimam potpisani xml, a oni ne mogu misleći da pri tom i ja koristim Raverus riješenje).

Ukoliko nešto zašteka vjerojatno će te pozvati k sebi i pokušati vidjeti o čemu se radi korz svoj backend koji je koliko sam vidio znatno "obožuraniji" opcijama od naše korisničke strane CIS-a. A ako netko nešto osporava tada se u upravnom, kaznenom, prekršajnom ili kakvom već postupku činjenice potprijepljuju ili osporavaju. Bit je da osiguramo maksimalnu količinu dokaza, a po meni potpisani xml-ovi. upravo to jesu.  Pada li valjanost digitalnog potpisa i XML-a. tada pada i valjanost svih obrazaca iz e-porezne, eregosa, razne bankarske transakcije internet bankarstva i sl.

Coordinator
Jan 15, 2013 at 11:22 AM

@Veky, vidi ovaj tool: https://www.fdev.hr/Explorer/FDev-Explorer.aspx

Jan 15, 2013 at 11:31 AM

Ljudi koji se bave tehnikom uglavnom se ne obaziru na "teorije zavjere" pa tako ni ja.

Ali zato znaju što je s tehnikom sve moguće.

Krađu podataka iz "tvoje" baze zasad nisam spominjao a moguća je. Jednako kao i čitanje podataka iz certifikata i slanje na "(ne)željenu adresu".

Zreli "tehničar" mora sve opcije uzeti u obzir posebno kad nas većina radi na "jednom poznatom OS-u". Poznatom po sigurnosnim propustima.

Čime je porezna "oboružana" u ovom je smislu manje važno (za nas).

Ali bi bilo važno da možemo svoj rad (pa i njihov) kvalitetnije kontrolirati.

Jan 15, 2013 at 2:07 PM

@telegrafstanga

Lijepo u zadnjem postu navedeš kako treba sve opcije uzeti u obzir, kako treba kontrolirati svoj (pa i njihov rad), a prije navedeš da ne snimaš XML-ove jer nećeš?Kontradiktorno, posebno što ti je Veky argumentirano naveo koje datoteke i zašto snima. Nije bitno što ti misliš o svom programskom rješenju, nego korisnici a i drugi programeri. Dodaj opciju snimanja poslanih i primljenih XML-ova, pa nek korisnik izabere uključiti je ili ne.

Jan 15, 2013 at 2:19 PM

O tome (snimanju) se može razmisliti, svakako.

No, bit "svega" je u tome da bi JIR trebao biti dovoljan za svako dokazivanje autentičnosti.

No, da li jest ili nije, to još ne znamo dok se neki sporovi ne dogode a "utakmica" nije fer jer jedni igraju s dvije lopte a drugi samo s pola lopte.

Npr, zašto osoba koja je sufinancirala cjeli projekt, (dakle ugostitelj) nema uvid u svoj prijavljeni promet putem svojih ovlasti koje mu ovjerava certifikat?

Što ako mu softver ne valja pa se podaci razlikuju od njegovih lokalnih?

Jan 17, 2013 at 2:40 PM

problem je što web sučelje pod vrijeme računa provjerava vrijeme inserta računa, a ne vrijeme izadavanja računa. znači sve naknadno fisklaizirane račune nećete tako moći naći.

Jan 17, 2013 at 2:56 PM
lemmingsica wrote:

problem je što web sučelje pod vrijeme računa provjerava vrijeme inserta računa, a ne vrijeme izadavanja računa. znači sve naknadno fisklaizirane račune nećete tako moći naći.

Jesi li ti siguran ??
Ja sam nasao i svoje naknadne racune ( sva sreca nema ih bas puni .. :)) i to sve po datumu i vremenu koji je na racunu !! 

Jan 17, 2013 at 3:37 PM
Edited Jan 17, 2013 at 3:49 PM

svi računi iz moje blagajne, pa i oni po sekundama vrlo bliski kraju trenutne minute - provjeravaju se bez problema po JIRu.

ovako, logikom, rekao bih da vi na papirnati račun ispisujete vrijeme računa, a u CIS dostavljate datum i vrijeme trenutka "CISiranja" računa :)

(edit : lemmingsica) to provjeri 

Coordinator
Jan 17, 2013 at 3:40 PM

garant je ovo što mladen veli. Provjerite vremena. Ili zaokruživanje iznosa ;)

Jan 17, 2013 at 3:42 PM
lemmingsica wrote:

problem je što web sučelje pod vrijeme računa provjerava vrijeme inserta računa, a ne vrijeme izadavanja računa. znači sve naknadno fisklaizirane račune nećete tako moći naći.

  Vrijeme izdavanja računa je relevantno a ne vrijeme kad je CIS primio, provjereno.

Coordinator
Jan 17, 2013 at 3:44 PM
lemmingsica wrote:

problem je što web sučelje pod vrijeme računa provjerava vrijeme inserta računa, a ne vrijeme izadavanja računa. znači sve naknadno fisklaizirane račune nećete tako moći naći.

Ovo nije točno. Sada sam provjerio jedan račun sa oznakom nakdodst=true, a na kojemu je vrijeme izdavanja računa (nije im radila interner konekcija). Račun je uspješno prijavljen... 

Jan 17, 2013 at 3:55 PM

 

dkustec wrote:

garant je ovo što mladen veli. Provjerite vremena. Ili zaokruživanje iznosa ;)

Da, imao sam problem s iznosom, nisam prizbrojio PNP pa mi nisu prolazili racuni s iznosom koji je "Ukupno" nego s razlikom. Prijavio naknadno s ispravnim izracunom po istom ZKI i prolaze uredno.

Provjerite račun po zki sms porukom da dobijete tocno vrijeme i iznos s kojim je primila porezna (0,85 po poruci  :) )

Jan 18, 2013 at 1:31 AM

Ja osobno ne snimam xml (1500 računa dnevno * 365 dana * cca 2kb * 2[zahtjev/odgovor]) = > 2GB xml-a godišnje.
Mislim da je nepotrebno. Dodatni razlog jer se dobiveni JIR može provjeriti obrnutim algoritmom od strane Porezne uprave.

Coordinator
Jan 18, 2013 at 6:45 AM

Nisam baš siguran što misliš pod "obrnuti algoritam" - no - UUID (GUID, UNIQUEIDENTIFIER) ne funkcionira na taj način. PU bi, naravno, trebala imati pripadajući XML (odnosno redak u bazi ili kaj već) za svaki pripadajući JIR, no, tko kaže da se kod njih ne može nešto dogoditi sa podacima? A teško da će oni biti ikada krivi za nešto :)

Jan 18, 2013 at 6:47 AM

XML-ove, zipaš, a čak i ta 2GB prostora godišnje na današnjim diskovima je smiješan prostor. Ako nikako drugačije, svakih 6 mjeseci ih zapržiš na nekakav DVD, cijena DVD-a. ne bi trebala biti neka stavka, ili neki USB stick. Ničime naknadno ne možeš dobiti valjan dokument kojim možeš dokazati odgovor koji si dobio na zahtjev u onom trenutku u kojem je on predan osim potpisanim odgovorom PU na taj zahtjev. Tu je poanta. Ne radi se o tome da ti kasnije preko sms poruke ili sl. iskopaš jir, problem je kad ti jir imaš, a oni ga nemaju. Ti im ako zagusti imaš čime dokazati kako si ga dobio, a njihov je problem gdje im je nestao. Dakle, po meni je osobito uz kompresiju stavka prostora u cijeloj priči sporedna.

Coordinator
Jan 18, 2013 at 8:19 AM

2Gb godišnje? Pa najjedftiniji diskovi danas po toj matematici mogli bi poslužiti za storage nekih... 250 godina :)
XML potpisan njihovim certifikatom, a koji je vezan UUID-om sa originalnom, poslanom XML porukom, a sadrži JIR je jedini i glavni dokaz da je kod tebe prošlo sve u redu i da oni imaju problem. Ne ti.  

Feb 5, 2013 at 10:36 PM
Edited Feb 5, 2013 at 10:38 PM
Sorry, nezgodno sam se izrazio, nisam mislio da obrnutim algoritmom rekreiraš podatke iz JIR-a. Htio sam reći da PU iz tvojih podataka može generirati istovjetni JIR u slučaju da je potrebna provjera, bez da sačuva XML,
već samo bitne podatke iz XML-a. Znači u slučaju da PU nekim slučajem nema JIR, ti ga ne možeš falsificirati ili
podmetnuti jer ne poznaš algoritam. Također ne možeš provjeriti slanjem istih podataka jer ne možeš simulirati
vrijeme slanja. Porezna i Inspektorat imaju za to određenu posebnu aplikaciju od strane APIS-a. Iz tog razloga mislim da je bezpredmetno čuvati kompletan XML. Ovdje nije pitanje je li disk jeftin ili nije i kako će negdje netko spremati podatke.
Računaj da prosječne SQL baze koje koristite (MS SQL, MySQL, Firebird, H2, berkeley DB, Sybase SQL Anywhere, SQLite i slične besplatne ili cjenovno pristupačne) već na 5 GB veličine tipično padaju sa 60 - 70 upisa po milisekundi na ispod 5 (za indeksirani redak). Ovo se odnosi na standardnu kućnu PC arhitekturu a to je 60 - 70 % svih PC blagajni u RH (naravno i sve moje). dok ostatak od 30 - 35% čine zastarjeli kompjuteri koji još uvijek rade (recimo to tako).
Čak i da samo spremaš fajlove u neki direktorij, nakon 50-tak tisuća fajlova prosječan jeftin disk će ti se usporit
za 10 -15% na MS Windows sustavu (7 - 10% na Linux-u). Dobro, možeš komprimirat na kraju dana pa je onda ova priča zaključena. Ako su vaši kupci mali pa to neće nikad primjetiti ili su zadovoljni usporenjem aplikacije to me se ne tiče.
Nastojim svojim strankama omogućit što manje glavobolje i suvišne administracije i bavljenja računalima
kako bi se mogli posvetit svojoj osnovnoj djelatnosti, a ne računalu.
Coordinator
Feb 6, 2013 at 6:10 AM
@cartman2001, potpuno si sve krivo shvatio - ZKI se generira prema (poznatom) algoritmu, JIR je UUID i to što ti pričaš, sorry, jednostavno nema veze s vezom :)
Dobra je praksa čuvati XML dokumente koje Porezna šalje nazad, vrijeme će pokazati da li je na osnovu toga moguće nešto "dokazivati" ili ne. U svakom slučaju, ako već brineš o strankama toliko, onda ih svakako upoznaj zašto bi bilo oportuno čuvati XML dokumente, bez obzira na potencijalne tehničke probleme koje su uvijek nekako riješivi - nasuprot tome da NIJE riješivo ako nešto trebaš dokazati a nemaš podatka.
Coordinator
Feb 7, 2013 at 1:36 AM
Ako će se računalo usporiti radi 50.000 datoteka, odnosno - 25.000 računa (ako snimaš zahtjev i odgovor), onda imaš veći problem od samog skladištenja tih xml datoteka jer imaš staru i trošnu opremu, koja će se raspsati neovisno o tome snimao ti XML ili ne.
Komprimirani folder sa tih 50.000 datoteka ne prelazi niti 10 Mb, a ako imaš dovoljno dobru aplikaciju, pri samoj odjavi korisnika, zaključka dana ili neke slične radnje, putem jednostavne metode ćeš, po mogućnosti asinkrono, kroz kod, komprimirati tu mapu.. ili još bolje - spremiti je na neku sigurnu lokaciju..

XML je zbilja, kako Nino kaže - dobro sačuvati - jer su jedini dokaz komunikacije sa CIS-om..