Kakav šlamperaj - stopa PDV-a je string a ne decimal

Coordinator
Dec 9, 2012 at 10:57 AM

Za ovakav šlamperaj stvarno nemam riječi - promijenili su XSD schemu, stavili su da je stopa PDV-a (tj. PorezType) string, a ne više decimal kako je bilo do sada. Da mi je samo znati koji razlog može biti za to - kakve to fundamentalne probleme u APIS-u imaju kada ne mogu primati brojeve kao brojeve!!??

I, da, ako se pitate - Tehnička dokumentacija NIJE izmijenjena, samo su promijenili XSD !!!

Kakva teška improvizacija, koji diletanti...

 

Dec 9, 2012 at 9:49 PM

Ne znam koji su njihovi problemi, ali npr. 0,00 tesko moze biti nesto drugo osim stringa, i posto hoce formatirane brojeve tako su trebali krenuti od pocetka.

Dec 9, 2012 at 10:50 PM

@mpapec -  Ne kužim - prvo nije 0,00 nego je 0.00 - drugo, po čemu je to string? (stope i iznosi su po prirodi stvari decimalni brojevi)

Ili sam možda nešto propustio? 

Coordinator
Dec 10, 2012 at 7:10 AM

Da, broj je broj, a format prikaza ovisi o tome što želiš, iz koje si zemlje i sl. - to i je moj point... uzmite u obzir da se ovo mijenja ovako kasno u fazi realizacije, bilo bi baš dobro saznati što su to majstori zajeb... pa da im treba string :)

Dec 10, 2012 at 11:19 AM

I što je najbolje kad mu upišeš krivi string (ili decimal u ovom slučaju) vrati Internal error 500, pa si ti misli.

 

Jedva čekam 1.1. da vidim taj kaos.

Dec 10, 2012 at 11:33 AM

Nije vezano za broj ali s obzirom da mjenjaju brojeve u string, dali će i mjenjati godinu na 2013 u sljedećem redu

<tns:RacunZahtjev xmlns:tns ="http://www.apis-it.hr/fin/2012/types/f73 "

Coordinator
Dec 10, 2012 at 12:10 PM

@dotvip, vjerojatno ne - to je dio definicije scheme i nema nikakvog razloga da se mijenja - schema i je iz 2012.

Dec 10, 2012 at 9:36 PM
Edited Dec 10, 2012 at 9:38 PM
nrasinec wrote:

Za ovakav šlamperaj stvarno nemam riječi - promijenili su XSD schemu, stavili su da je stopa PDV-a (tj. PorezType) string, a ne više decimal kako je bilo do sada. Da mi je samo znati koji razlog može biti za to - kakve to fundamentalne probleme u APIS-u imaju kada ne mogu primati brojeve kao brojeve!!??

I, da, ako se pitate - Tehnička dokumentacija NIJE izmijenjena, samo su promijenili XSD !!!

Kakva teška improvizacija, koji diletanti...

 

Jesam li ja jos davno reko da su nam svi oni neprijatelji, a? a ti mi, gazda, prvi nisi vjerovao!

Sto mozemo, tu je sto je. Ja sam upravo otprintao Teh. Dok 1.2 i krenuo u "file compare". Znaci li ova tvoja tvrdnja da ga ne moram usporedjivati s (uglavnom) procitanom varijantom 1.1? Radi li ova njihova izmjena kakve probleme u tvom EXE-u ili DLL-u (BTW, sto je s novom verzijom?)?

Coordinator
Dec 11, 2012 at 6:50 AM

Da li ova izmjena radi probleme u postojećoj (staroj, v1.2.) verziji FiskalizacijaDEV-a - ne znam; rekli su da je okruženje po novoj tehničkoj specifikaciji od jučer iza 17h. Kako smo mi u v2.0 već implementirali sve te promjene, mogu samo potvrditi da sa novom schemom v2.0 radi kako treba...

Dec 11, 2012 at 6:57 AM

Ako se ne varam, jučer su u 17 sati trebali u rad uvesti zadnji wsdl po specifikaciji 1.2?

Ako su to napravili, koliko za sad primjećujem meni se formatiranje nije nigdje negativno odrazilo tj. radi uz novu schemu. WSDL ne importiram u Delphi jer mi ni prva varijanta nije radila kako spada nego kao i Raverus koristim "direkt pristup" u kreiranju xml-ova.

Coordinator
Dec 11, 2012 at 6:58 AM

E, da, ipak potvrđujemo da radi i sve po starom - dakle - ako niste ažurirali svoj kod prema specifikaciji 1.2. i dalje sve radi kako trebao - iako - bitno je napomenuti da se trenutno aktualne tehničke specifikacije treba pridržavati.

Dec 11, 2012 at 8:13 AM
gmacarol wrote:

@mpapec -  Ne kužim - prvo nije 0,00 nego je 0.00 - drugo, po čemu je to string? (stope i iznosi su po prirodi stvari decimalni brojevi)

Ili sam možda nešto propustio? 

To je string zato jer iz pozicije prog. jezika/baze je string svaki broj koji se ide formatirati (koristeci sprintf, to_char, itd).

Dec 11, 2012 at 8:16 AM
Edited Dec 11, 2012 at 8:20 AM
nrasinec wrote:

Da, broj je broj, a format prikaza ovisi o tome što želiš, iz koje si zemlje i sl. - to i je moj point... uzmite u obzir da se ovo mijenja ovako kasno u fazi realizacije, bilo bi baš dobro saznati što su to majstori zajeb... pa da im treba string :)

Nesto slicno je bilo u prijasnjoj verziji, promjenili su constraint na IznosType i StopaType (umjesto tocke se teoretski mogao slati bilo koji broj :) )

Coordinator
Dec 11, 2012 at 8:59 AM

@mpapec, to jednostavno nije točno - broj je broj i točka :)

Dec 11, 2012 at 9:18 AM

moguće je da rade "denormalizaciju" performansi radi. 

Dec 11, 2012 at 9:25 AM
mladenbabic wrote:

moguće je da rade "denormalizaciju" performansi radi. 

Pa to bi moglo biti. Ovako definiraju VarChar pa je polje koliko posaljes. 

Ako je cisti Num ili Dec onda je npr 12.2 fixno.....

Dec 11, 2012 at 12:03 PM

Prije, kad je iznos bio tipa decimal, uredno je prolazio primjer s tabom prije iznosa:

<f73:Osnovica>	250000.00</f73:Osnovica>

Sada ne prolazi:

<tns:PorukaGreske>Poruka nije u skladu s XML shemom: cvc-simple-type 1: 
element {http://www.apis-it.hr/fin/2012/types/f73}Osnovica value ' 250000.00' is not a valid
instance of type {http://www.apis-it.hr/fin/2012/types/f73}IznosType</tns:PorukaGreske>

Dec 11, 2012 at 2:28 PM

Bez tog jednog "TABa", CIS svakih 12 sekundi primi jedan račun manje.
Ipak je to veći benefit od pretrpiti ovakve "uvrede" od "nas" programerčića :)

Dec 11, 2012 at 2:58 PM

Pretpostavljam da je netko od velikih igrača koji su se upleli u ovo (čitaj n.pr. T-com) imao sitan problem sa decimalnim formatom (1.56 ili 1,56), pa da se ljudima olakša, što ne bi bio string?

Drugog razloga ne vidim, lakše je APIS-u pretvarati oba navedena stringa u pravi decimal, nego nabrzinu skupljenim programerima za fiskalizaciju navedenog velikog igrača replaceati zarez sa točkom... :)

Dec 11, 2012 at 3:08 PM

a što je tek s kućnim brojem, genijalci su smislili da to može biri samo numerika, prolazi ako upišeš '0' ili ako uopće ne pošalješ ali 'bb' vraća grešku

a sad mi trebamo objašnjavati korisniku da on ne može ptijaviti ptostor na 'Ilica bb', ajd pogodi koga će korisnik psovati

Dec 11, 2012 at 3:50 PM
bubimir wrote:

a što je tek s kućnim brojem, genijalci su smislili da to može biri samo numerika, prolazi ako upišeš '0' ili ako uopće ne pošalješ ali 'bb' vraća grešku

a sad mi trebamo objašnjavati korisniku da on ne može ptijaviti ptostor na 'Ilica bb', ajd pogodi koga će korisnik psovati

Probaj sa KucniBrojDodatak string(4)

Dec 11, 2012 at 4:02 PM
Edited Dec 11, 2012 at 4:09 PM

a teško ti je ako je "bb" postaviti na String.Empty?

Dec 11, 2012 at 4:13 PM
nrasinec wrote:

je samo znati koji razlog može biti za to - kakve to fundamentalne probleme u APIS-u imaju kada ne mogu primati brojeve kao brojeve!!??


Inace za ovo mozda cak nije ni Apisova krivica. :)

http://www.croz.net/nasi-korisnici/

Dec 12, 2012 at 8:27 AM

Ima gdje za skinuti kod sa novim promjenama, jer meni radi na stari način (iznos i stopa su decimal), ali kada sam ih promijenio u string javlja mi grešku "internal server error"

Coordinator
Dec 12, 2012 at 8:31 AM

v2.0 samo što nije, radimo zadnja testiranja :)

Dec 12, 2012 at 10:24 AM
Edited Dec 12, 2012 at 10:24 AM

Dok ne bude v2.0 spremna jel se može barem postaviti za download izgenerirani kod za novu shemu, jer ja nikako ne mogu natjerati xsd2code da to napravi, a malo mi je sve skupa već hitno

Dec 12, 2012 at 2:04 PM
nrasinec wrote:

v2.0 samo što nije, radimo zadnja testiranja :)

Ako nije problem dal može neki info kad će ova nova najavljena verzija?

Coordinator
Dec 12, 2012 at 2:14 PM

Nije problem - ide danas do kraja dana :)

Dec 12, 2012 at 2:40 PM

Na kraju krajeva u soap paketu sve je string, nema drugog tipa podataka, jedina razlika je u koji tip podatka se atribut serijalizira odnosno deserijalizira ;)

Problem sa decimalom je što nema ogranićenja na dvije decimale - a oni su to ogranićenje htjeli uvesti.Najjednostavniji i najbrži naćin je dakle promjena tipa u string sa fiksnim formatom. Istina, stara šema je imala tip decimal sa formatom(možete provjeriti), problem je jedino što većina frameworka (uključujući i dot.Net 2.0) ignorira format na decimalu kod serijalizacije.

Server bi bio jako opterećen kada bi radio replace po ulaznim paketima, To se tako ne radi nego se paket jednostavno validira preko XSD sheme - ako šema ne štima vrati ti grešku (to je najbrži i najsigurniji naćin).

Dakle ja u tome ne vidim ništa sporno (ionako se ne može upisati ništa drugo nego ispravan iznos jer maska onemogućava takve unose), a ne vidim ni razlog zašto bi performanse zbog toga bile smanjene -osim ako ne krenemo brojiti bajtove - no oni zavise od stvarne dužine broja...pa se može pokazati da za manje iznose sa samo dvije decimale string funkcionira bolje ;)

Dec 12, 2012 at 2:46 PM
nrasinec wrote:

Nije problem - ide danas do kraja dana :)

A ako nije problem - oćel odmah i EXE?

Dec 13, 2012 at 6:45 AM
Edited Dec 13, 2012 at 7:31 AM

Jel ima uopće potrebe mijenjati što u aplikaciji, pošto je decimalni znak i dalje točka?

Ako sam dobro skužio string je uveden samo radi kontrole podataka, a ako je to riješeno na nekom drugom mjestu tada ne bi trebalo biti nekog razloga za mijenjanje...

Dec 13, 2012 at 10:40 AM

Nismo mjerodavni, probali smo za stope upisati: 125,0%, 25% , 5.00%  i 0,5%. Uvijek dobivamo ispravno formatiranu stopu u XML-u i sve prolazi u CIS.. koristimo NET 3.5

<tns:Stopa>125.00</tns:Stopa> 
<tns:Stopa>125.00</tns:Stopa> 
<tns:Stopa>5.00</tns:Stopa>
<tns:Stopa>0.50</tns:Stopa>
Ne vidim razlog zašto bi trebali dirati ako je ovo po pravilima XML ok.