XML za razmenu fakt...
 
Notifications
Clear all

XML za razmenu faktura

33 Posts
4 Users
0 Likes
2,619 Views
(@nbatocanin)
Posts: 113
Member
Topic starter
 

Ponovo šaljem XML format za razmenu faktura koje je predložio kolega Dejan iz New Dimension. Molim vas da pogledate predlog i javite svoje mišljenje. Sada je jedinstvena prilika ako treba nešto izmeniti, posle će sve biti mnogo teže.

 
Posted : 26/03/2014 3:47 pm
(@nbatocanin)
Posts: 113
Member
Topic starter
 

Da krenemo sa UPSS Netom. Izdvojio sam iz Dejanovog predloga samo obavezne stavke. Dakle, faktura se može poslati minimalno ovako:

<?xml version="1.0" encoding="utf-8"?>
<Dokument>					
   <Tip>Faktura</Tip>
   <Grad>Pancevo</Grad>
   <Datum>28.04.2009</Datum>		
   <Oznaka>101-09</Oznaka>		
   <Posiljalac>					
      <PIB>101048964</PIB>      		             
   </Posiljalac>
   <Primalac>							
      <PIB>121212122</PIB>				
   </Primalac>
   <Stavke>				
      <Stavka>				
         <Vrsta>Roba</Vrsta>					
         <ID>100100A1</ID>			
         <Naziv>KONCETRAT ZA PRASAD</Naziv>			
         <JM>Kg</JM>
         <Kolicina>100.00</Kolicina>				
         <Cena>50.10</Cena>					
         <PorezProc>8.00</PorezProc>
      </Stavka>
      <Stavka>					
         <Vrsta>Usluga</Vrsta>					
         <ID>100100A1</ID>					
         <Naziv>ISPORUKA NA ADRESU</Naziv>	
         <JM>Km</JM>						
         <Kolicina>70</Kolicina>			
         <Cena>25.00</Cena>					
         <PorezProc>20.00</PorezProc>		
      </Stavka>
   </Stavke>
   <Ukupno>	
      <VrednostProd>8217.72</VrednostProd>	
      <PDVUkupno>918.72</PDVUkupno>
      <ZaUplatu>8217.72</ZaUplatu>			
   </Ukupno>
</Dokument>

Deluje mi prilično pregledno i jasno. Ne vidim nigde datum valute? Ja bih umesto "Oznaka" stavio "BrojDokumenta" ili samo "ID" i to odmah ispod "tip", ali može i ovako.

Što se ostatka tiče, tu imam nekoliko manjih primedbi:

- Umesto "Grad" treba staviti "Mesto" - ima firmi koje su u selima.

- Mislim da avansi treba da se promene. Ne vidim potrebu da se prikazuje ukupan iznos i iznos koji se zatvara, za fakturu je bitan samo iznos koji se zatvara. Sa druge strane, veoma je važna struktura PDV-a, nije isto da li se zatvara PDV 20 ili 10. Predlažem ovako nešto:

<Avansi>
   <Stavka>
      <Opis>Av.Fak.123</Opis>
      <Iznos>1200.00</Iznos>
      <Pdv>20</Pdv>
      <PdvIznos>200.00</PdvIznos>
   </Stavka>
</Avansi>

- ne sviđaju mi se brojači u okviru tagova poput <TekuciRacuni cnt=2>. Mislim da samo stvaraju gužvu, a nema neke koristi od njih.

 
Posted : 07/04/2014 6:38 am
(@dpnd)
Posts: 11
Member
 

Ok, u principu se slažemo onda, kačim RC3 verziju, (godinu dana nakon RC2... al' vreme leti...)

- DatumDPO sam, po predlogu, postavio među obavezne tagove.

- U sekciji Avansa sam dodao stavke koje sadrže ono što si predložio.

- Brojači su opcioni i ne moraju da se koriste, u predlogu su napisani plavom bojom, pa ko neće, ne mora obračati pažnju na njih, te ih ne bi izbaciovao? Ako insistiraš, skloniću ih, nije da su neophodni.

- Zamolio bih da nekako preskočimo promenu naziva tagova "Grad" u "Mesto" i "Oznaka" u "ID" jer će to generisati dosta promena u dosta softvera koji već koriste ovaj format a bez neke preterane potrebe, smisao je isti. Mi smo, kao i do sada, gurali ovaj xml u RC2 verziji k'o da je usvojen, tj. naš, što je, siguran sam, nekim kolegama sa foruma i poznato 🙂

Elem, Release Candidate 3 je u prilogu

DP/ND

 
Posted : 17/09/2014 12:03 pm
(@nbatocanin)
Posts: 113
Member
Topic starter
 

- Brojači su opcioni i ne moraju da se koriste, u predlogu su napisani plavom bojom, pa ko neće, ne mora obračati pažnju na njih, te ih ne bi izbaciovao? Ako insistiraš, skloniću ih, nije da su neophodni.

- Zamolio bih da nekako preskočimo promenu naziva tagova "Grad" u "Mesto" i "Oznaka" u "ID" jer će to generisati dosta promena u dosta softvera koji već koriste ovaj format a bez neke preterane potrebe, smisao je isti. Mi smo, kao i do sada, gurali ovaj xml u RC2 verziji k'o da je usvojen, tj. naš, što je, siguran sam, nekim kolegama sa foruma i poznato 🙂

Ne smeta mi nešto posebno, ali ipak mislim da bi bilo bolje da je "mesto" i "broj". Kod generisanja i parsiranja je naravno svejedno, može da se zove bilo kako, ali imaj u vidu da će ovaj format biti kritički analiziran uzduž i popreko i da ćemo morati na njemu da branimo svaku sitnicu. Postoji nekoliko "konkurentnih" formata čijim autorima treba objasniti zašto se koristi ovaj, a ne njihov, pa je bolje unapred imati što čIstije i ispravnije rešenje. Već sam bio u takvoj situaciji.

SVakako bi valjalo da još neko kaže svoje mišljenje, jer kad kasnije krene u upotrebu biće daleko teže da se bilo šta izmeni. Kolege, molim vas da pogledate ovaj predlog i da date svoje mišljenje!

 
Posted : 17/09/2014 4:54 pm
(@dpnd)
Posts: 11
Member
 

Tekst sličan ovom i sa istim attachmentom je i u temi vezanoj za razmenu artikala.

XML za razmenu faktura, kako stoji u naslovu, ne mora biti samo za razmenu faktura.

Prikačio sam UPSS XML 2.0 RC4 koji sadrži i predloženu definciiju za prenos artikala (i eventualno stanja i prodaje) i još jednu definciju taga stavke za prenos komitenata (isto sa eventualnim prenosom stanja). Ova nova potreba za prenosom artikala i komitanata je u xmlu realizovana tako da u tim slučajevima tip prenosa / dokumenta ne bude "faktura" ili "otpremnica" već "šifarnik", te da se zadrži struktura koja onda mora imati tag "stavke" i pojedinačne stavke koje su onda artikli i/ili komitenti, a ne stavke dokumenta fakture za šta je UPSS XML format uglavnom služio.

Obzirom da su neki veliki lanci krenuli sa nekim, blago rečeno, čudnim idejama o tome kako treba da se prenose dokumenti u elektronskom obliku, mislim da je kranje vreme da mi ovaj Release Candidate ozvaničimo i kažemo da je ovo UPSS XML 2.0 format i da ga guramo svi zajedno! Inače ćemo svi završiti u pravljenju po 20 formata za prenos za svaku veću firmu kojoj to padne na "pamet", što je čisto gubljenje vremena jer to često proizilazi iz ideje o zaradi na prenosu podataka, a ne iz ideje o efikasnosti pri radu, kao što bi trebalo.

Šta ćemo sa UPSS NETom? Krećemo li?

DP/ND

 
Posted : 05/12/2014 3:49 pm
(@nbatocanin)
Posts: 113
Member
Topic starter
 

Probaću na ovom mestu da sumiram sve moje predloge. Nešto od toga sam i ranije pisao, ali zbog kompletnosti pišem opet. Prvo, mislim da je ideja da preko UpssNeta razmenjujemo razna dokumenta odlična i da to odmah treba da predvidimo. Generalno, mi ćemo razmenjivati "dokumenta", a dokumenta mogu biti fakture, šifarnici, cenovnici.... Za početak pravimo fakture, a odmah posle toga možemo da dodajemo ostale tipove. U svetlu toga, mislim da bi trebalo nekako grupisati stavke da podaci o dokumentu čine jednu celinu. Naime, mi sada imamo nešto ovako:

<Dokument>
   <Tip>
   <Oznaka>
   <Datum>
   <Pošiljalac>
   <Stavke>
</Dokument>

Tj, skoro sve ide u prvi nivo. Deluje mi logičnije da prvi nivo bude zajednički za SVA dokumenta:

<Dokument>
   <Identifikacija>
   <OpstiPodaci>
   <Stavke>
</Dokument>

Sada bi sva dokumenta imala ovakvu osnovnu strukturu. U okviru Identifikacije (ne pada mi na pamet bolji naziv) bi išli podaci o verziji formata, tipu dokumenta i sl. Zatim u Opstim podacima za fakture pošiljalac, primalac... Za cenovnike bi tu išao naziv cenovnika i tako nešto. Ne insistiram na ovome, samo mi deluje kao logično.

Druga bitna stvar: treba ozbiljno razmisliti o tome da svi tagovi budu na engleskom jeziku. Nama naravno više odgovaraju srpski tagovi, ali ako ovaj standard zaživi, sigurno ćemo ga preporučivati i strancima, a verovatnoća da ga oni prihvate i korektno odrade drastično raste ako su im tagovi jasni. Da ilustrujem, imao sam prilike da pravim eksport na grčkom 😉 Znam da to izgleda kao drastična izmena, ali mislim da u ovoj fazi možemo to prilično bezbolno da uradimo. Znam da time pravim problem kolegama koji već koriste ovaj format, ali mislim da bi značajno olakšali širenje ovog formata ako sve prevedemo na engleski.

Ostalo su uglavno sitnije primedbe:

- Obavezno promeniti Grad u Mesto - ima firmi i po selima 🙂
- U okviru kupca/dobavljača mislim da treba dodati stavku "Kontakt" u okviru koje bi moglo da se doda više telefona, mailova i osoba za kontakt:

<Kontakti>
   <Kontakt>
      <ImePrezime>
      <Telefon>
      <Mail>
   </Kontakt>
   <Kontakt>
      <ImePrezime>
      <Telefon>
      <Mail>
   </Kontakt>
   ...
</Kontakti>

- Nemamo datum valute

 
Posted : 06/12/2014 2:57 am
(@dpnd)
Posts: 11
Member
 

Ovo da treba da prenosimo razna dokumenta sam zagovarao od pocetka jer mi to tako i koristimo vec 7 godina, ali to nije naislo na prihvatanje u proslim iteracijama u vezi sa zajednickim formatom, secas se? Tako mi, sada, a bogami i jos neki, a mislim i ti Nenade, imas svoj format koji ima prenos svega i svacega, a ovde se godinama natezemo oko toga kako se prenosi faktura i da li ce mozda i samo mozda da se prenese jos nesto... Mi smo na osnovu osnovnog upss xml-a odavno napravili prenos svega sto nam treba i to koristimo, a ovde se, zvanicno, nismo dogovrili jeli grad ili je mesto ili selo ili zaseok i na kom je jeziku i da li je grad/mesto/city/willage/place u okviru grupe identifikacija ili je u rutu... ostavicemo prenos svega za neku sledecu reviziju.

Elem, hajde da pocnemo da koristimo ono sto imamo nekako, a da raspravu oko stila izvedbe i raznih drugih stvari ostavimo za verziju 3.0. Englesku podvarijantu svakako mozemo napraviti, ali to nije neophodno raditi pre UpssNeta i pre usvajanja UPSS XML 2.5 tako nesto. Ja bih da krenemo sa ovim sto imamo, iako moze i bolje i na grckom i na slovenackom i tome slicno...

Napravio sam ver2.5 rc1 koji ima tag "mesto" umesto "grad", koje ima "kontakt" i u posiljaocu i u primaocu, i kontakte u okviru stavke tipa "komitent". Umesto atributa za redni broj stavke dodao sam novi neobavezni tag "RBStavke" u okciru "stavka" taga. Datum valute postoji kao "datumdpo" u korenom tagu i obavezan je od ranije.

Kolege, jel usvajamo ovaj standard kao zvanicni UPSS XML 2.5?

Ko ima nesto krucijalno da doda, neka doda do 10.12.2014, kada 2.5 postaje zvanican UPSS XML standard koji ce se redovno nadogradjivati kasnije, na primer jednom godisnje ili tako nesto.

...Pa da krenemo sa UpssNet realizacijom koja ce da krene sa UPSS XML 2.5...

DP/ND

 
Posted : 06/12/2014 11:38 am
(@nbatocanin)
Posts: 113
Member
Topic starter
 

Nema razloga za nervozu, svima nam je cilj da napravimo što bolji standard.

Shvatam da nije jednostavno menjati nešto što već koristiš, ali još je gore da po drugi put propadne isti projekat (koliko znam, osim tebe ga niko nije ni koristio). Zato sam izneo predloge za koje smatram da mogu poboljšati standard, jer mi je u interesu da bude najbolji mogući. Bez obzira na to da li će ti predlozi biti usvojeni, podržaću standard koji izađe iz ove iteracije.

Nikada nisam bio protiv razmene više dokumenata, samo sam za to da se koncentrišemo na osnovni cilj (razmena faktura), jer su tako veće šanse da sve proguramo. Takođe mislim da se interna razmena dokumenata mora razdvojiti od javne razmene, pa svakako planiram da zadržim naš interni sistem za razmenu unutar poslovnica firme.

Što se tiče ovih detalja, smatram da je veoma važno da se urade najbolje moguće, jer sam siguran da će to biti tačka na kojoj će nas napadati protivnici. Banalna stvar poput neusklađenosti sa zvaničnom terminologijom tu može biti presudna.

Još jednom molim ostale da se uključe, mislim da su ova pitanja izuzetno važna!

Pozdrav, NB

 
Posted : 06/12/2014 3:45 pm
(@dpnd)
Posts: 11
Member
 

Ok, ako nam je cilj da se nesto pokrene u skorije vreme ili odmah, onda smo na istom tragu.

Nervoze nema, nego je proslo vise od godinu dana od poslednjeg pomaka, a sada opet pricamo o sitnicama umesto da pokrenemo stvar takvom kakva je, pa da onda menjamo verzije standarda i dodajemo te sitnice kada bude trebalo. Naravno da je najbolje da odmah bude savrseno, ali to nikad nikome nije uspelo.

Nama nije nikakav problem menjanje onoga sto se koristi jer smo, nauceni u prethodnim desavanjima, prosle godine napravili da sva mesta sa kojih se izvozi i da sva mesta na kojima se nesto uvozi imaju podesivo verziju upss xml standarda (kojih za sada imamo 3-4), koje su konkurentno u upotrebi. Ovo smo pravili da ne bi zbog dugih dogovora u okviru ove grupe stajali sa razvojem i/ili eksternim firmama menjali nesto sto nije do njih i sto ih se ne tice, kao sto je "grad" u "mesto". Dakle, njima ce ostati isto, mi cemo dodati novu verziju standarda koja ce za nove raditi po novom, a starima raditi po starom ako tako odaberu i to je to. Ovo nije bas tako jednostavno za izvesti, kako zvuci, sto svi ovde znamo, ali izvedeno je.

Objasnjavam sve ovo gore da ne budem pogresno shvacen da meni smeta nesto drugo do samog cekanja. Tehnicki, nama ovo nije problem, a nije problem ni firmama koje su na nase insisitiranje poslednjih dosta godina uvele upss xml kao nacin za komunikaciju sa nasim softverom. Ima ih bar 10. Njima moze biti problem ako budu zelele da predju na noviju verziju standarda, ali pitanje je da li ce zeleti ako ona ne donese nesto kvalitativno novo.

Ako ucesce u diskusiji ne uzme veci broj kolega to ne znaci da opet treba godinu dana da cekamo. Neke firme zajednicki format jednostavno ne zanima i/ili im nije u interesu, ali ako se ne konkretno ne suprotstave donosenju standarda, tj. ako samo ne ucestvuju u raspravi, to ne znaci da mi treba da stojimo sa donosenjem neke odluke o zvanicnom standardu udruzenja.

DP/ND

 
Posted : 06/12/2014 4:30 pm
(@nbatocanin)
Posts: 113
Member
Topic starter
 

Ako ti ne pravi problem da se nešto izmeni, onda zaista nema razloga da se odmah ne ispravi SVE oko čega se ovde složimo. Ne očekujem da će sve biti savršeno, ali sam siguran da će ovo što sam napisao pre ili kasnije ispasti problem. Zašto onda ne bismo to odmah sredili? Sve ovo što sam nabrojao je posao od možda par sati - ako treba, mogu ja to da odradim. Ako neko predloži nešto krupnije, možemo da napravimo neki spisak za sledeću verziju.

Što se tiče aktiviranja standarda, to naravno zavisi samo od dobre volje učesnika. Ja sam već rekao da ću podržati taj standard ma kakav on ispao posle ove iteracije. Iskreno se nadam da će se broj korisnika proširiti na više od dve firme. Nadam se da će se i ostali uključiti u diskusiju.

Pozdrav, NB

 
Posted : 07/12/2014 5:01 am
(@toni-babic)
Posts: 35
Member
 

Ovaj post sam počeo da pišem pre odgovora DP/ND, pa neke napomene za nbatocanin-a sam obrisao, ali ne sve.

@nbatocanin
>...U okviru kupca/dobavljača mislim da treba dodati stavku "Kontakt" u okviru koje bi moglo da se doda više telefona, mailova i osoba za kontakt:

Tag <Adresa>, <Telefon>, <Mail> su opcioni i trebalo bi da mogu se pojave jednom ili više puta.

>...treba ozbiljno razmisliti o tome da svi tagovi budu na engleskom jeziku...

U inicijalnom predlogu Faktura0.xml postojao je tag:
<PodaciProgramskogPaketa>
  <ppp_Jezik>srpski</ppp_Jezik>

Ovaj podtaka može biti i "ENGLESKI", pa bi parseri radili sa engleskim terminima.
Tu sam ostavio prostor da se odrede tačni termini, koji su u poslovnoj komunikaciji na engleskom.

Možda bi koreni, root tag: <Dokument> trebalo staviti u engleskoj verziji: <Document>,
pa na osnovu taga: <Jezik>srpski</Jezik>,
nastaviti dalje sa razvojem XML specifikacije, a u međuvremenu ispravno prevesti sve usaglašene termine, pa svako da koristi ono što mu odgovara: srpsku, englesku, francusku, grčku,...verziju. Ovako bi stvar bila prihvatljiva strancima.

>...Nemamo datum valute

U inicijalnom predlogu stoji:
<Racun>
...
  <rac_Datum>19.12.05</rac_Datum>
  <rac_DatumDPO>19.12.05</rac_DatumDPO>
  <rac_Valuta>23.12.05</rac_Valuta>
...
Treba ga dodati.

@DP/ND
>...nije nikakav problem...menjali nesto...kao sto je "grad" u "mesto".

Tačno, imena tagova su nevidljiva za korisnika! Vidljiva su samo za program koji parsira/tumači XML dokument.
Ako programer koji pravi program za parsiranje tog dokumenta stavi u tag <Jezik>:

<Jezik>KrijemZnacenjeTagova</Jezik>

Tu umesto "Mesto" može da stoji "xyz123"!
Program razmene će raditi, ali samo njemu. Kad odluči da i drugi mogu da koriste tu njegovu "nauku", podeli će svoj standard kao novi jezik (<Jezik>), ostali koji žele prilagodiće svoje parsere za taj novi jezik i stvar radi.
Kod određivanja TAGOVA, nebitno je kako se zovu, bitno je da li imaju smisla u okviru/kontekstu u koji su uključeni.

>...da ne budem pogresno shvacen da meni smeta nesto drugo do samog cekanja...

Polako. Inicijalno rešenje dato je u januaru 2006! Prvi mejl sa bilo kakvom reakcijom (pozitivnom) dobio sam pred kraj 2009. Tri (3) godine kasnije!
Za sporo usvajanje, odgovornost delimično snosi i sam DP/ND. Da je u postupku usvajanja rešenja, objavio da radi po UPSS inicijalnom standardu uz neophodne korekcije, zahtevane pri konkretnom rešavanju problema u realnoj upotrebi, ovaj razgovor bi se vodio znatno ranije. Ali šta je tu je. Pretpostavljam da je glavni razlog za ovaj DP/ND postupak bio da dogovaranje oko standarda ne uspori primenu rešenja. Sve je neka vrsta trgovine.

@nbatocanin
>...proširiti na više od dve firme...

Firme koje koriste ovaj standard će proširiti standard, ne mi, firme koji ga definišemo ili radimo programe da bi bio primenjiv. Kada firme korisnici budu prinuđene da plaćaju razmenu podataka, a biće, ili nemaju nikakav standard, počeće da koriste ovaj standard, jer će u kontaktu sa onima koji već koriste UPSS.XML.standard, doći do zaključka da je dobro preći na njega. Otvoren je i besplatan, što je po meni trenutno i jedan od razloga što se ne primenjuje. Mislim da je nematrijalna dobit od olakšanje pri procesu komunikacije, veća od novca koji se može zaraditi. Ipak smo mi malo tržište.
Ovakve tehnologije se koriste u svetu kao deo web servisa. Razmena podataka pomoću ovog standarda može tehnološki unaprediti svakoga ko ga koristi.

Razmena podataka sa Poreskom upravom u XML formatu, čini da će se situacija ipak menjati na bolje.

Pozdrav, Toni Babić

P.S. U prilogu sam prikačio originalni predlog koji je DP/ND prihvatio i unapredio u dokumentu: "UPSS_XML_2.5.docx".

Trebamo se držati njihovog sadašnjeg rešenja, jer oni imaju najviše iskustva u primeni ovog rešenja.
Inicijalnu verziju sam prikačio samo da bi imali uvid odakle se krenulo i da bi bilo jasnije gde dalje treba ići.

Danas se ne bi izjašnjavao o kvalitetu priložene XSL datoteke, ali je tada bilo potrebno razumljivo, a ne optimizovano rešenje. Ispravno je parsirala dokument Faktura0.XML u Internet Exploreru(5+).

I danas ispravno radi u Internet Exploreru!

Prefiksi u tagovima npr.: rac_Datum, su nepotrebni, tada mi se činilo da dodatno pojašnjavaju lokaciju podatak u okviru dokumenta, a u stvari dokument čine manje čitljivim. Svaki tag mora biti jedinstveno imenovan i to je dovoljno.

Pozivam vas da iz priloženog zip fajla ponovo pročitate dokument: "upss2006a09-predlogXMLrazmene.txt"!
Ono što je u njemu rečeno i danas, posle 9 (devet) godina važi!

Kako nas je Poreska uprava naterala da podatke šaljemo u XML formatu, to nalazim da je danas lakše prihvatiti ovakvo rešenje, tj. njegovu detaljnu razradu ponođenu od DP/ND, a navedenu u dokumentu: "UPSS_XML_2.5.docx".

Da još jdnom naglasim, da bi ISPRAVNO VIDELI DOKUMENT: "Faktura0.XML", pogledajte ga u Internet Exploreru 5 ili novijem!

 
Posted : 07/12/2014 11:03 am
(@nbatocanin)
Posts: 113
Member
Topic starter
 

Tag <Adresa>, <Telefon>, <Mail> su opcioni i trebalo bi da mogu se pojave jednom ili više puta.

Ne vidim razloga da se Adresa pojavi više puta? Što se tiče telefona i maila, aKo ih ne grupišemo neće se znati na koga se šta odnosi. Svakako nam treba neko polje za ime kontakt osobe.

U inicijalnom predlogu Faktura0.xml postojao je tag:
<PodaciProgramskogPaketa>
  <ppp_Jezik>srpski</ppp_Jezik>

Ovaj podtaka može biti i "ENGLESKI", pa bi parseri radili sa engleskim terminima.
Tu sam ostavio prostor da se odrede tačni termini, koji su u poslovnoj komunikaciji na engleskom.

Možda bi koreni, root tag: <Dokument> trebalo staviti u engleskoj verziji: <Document>,
pa na osnovu taga: <Jezik>srpski</Jezik>,
nastaviti dalje sa razvojem XML specifikacije, a u međuvremenu ispravno prevesti sve usaglašene termine, pa svako da koristi ono što mu odgovara: srpsku, englesku, francusku, grčku,...verziju. Ovako bi stvar bila prihvatljiva strancima.

Mislim da bi to bilo preterano komplikovano, faktički bi trebalo radiiti posebno parsiranje za svaki jezik. Ja bih uveo sam jedan jezik i već sam napisao zašto mislim da to treba da bude engleski.

>...Nemamo datum valute

U inicijalnom predlogu stoji:
<Racun>
...
  <rac_Datum>19.12.05</rac_Datum>
  <rac_DatumDPO>19.12.05</rac_DatumDPO>
  <rac_Valuta>23.12.05</rac_Valuta>
...
Treba ga dodati.

Ako je ovo DPO "datum nastanka dužničko-poverilačkog odnosa", onda je to valjda to. Ako je datum prometa, onda treba dodati.

 
Posted : 07/12/2014 5:31 pm
(@toni-babic)
Posts: 35
Member
 

nbatocanin je napisao:
   ...aKo ih ne grupišemo neće se znati na koga se šta odnosi.

U konačnom predlogu: "UPSS_XML_2.5.docx", na strani 5, stoji:

<Kontakti> 
  <Kontakt> 
    <Ime>*</Ime> 
    <Tel>*</Tel> 
    <Mail>*</Mail> 
  </Kontakt> 
</Kontakti> 

Moj predlog je da se <Tel> i <Mail> mogu pojaviti 1 ili više puta za isto ime:

<Kontakti>			
  <Kontakt>			
    <Ime>*</Ime>
    <Tel>*</Tel>
    <Tel>*</Tel>
    <Tel>*</Tel>
    <Mail>*</Mail>
  </Kontakt>
  <Kontakt>			
    <Ime>*</Ime>
    <Tel>*</Tel>
    <Mail>*</Mail>
    <Mail>*</Mail>
    <Mail>*</Mail>
  </Kontakt>
</Kontakti>

Ja bih uveo sam jedan jezik i već sam napisao zašto mislim da to treba da bude engleski.

Pre devet godina si napisao ovo:

>Wings.NB:
>Treba još jednom razmisliti o jeziku na kome će se praviti ključne reči.
>...
>...mislim da imamo mnogo bolje šanse ako koristimo srpsku terminologiju.

Ako si tad bio u pravu, da li si sad u krivu? Ne, ali dobrim delom zbog stava, to je previše, nepotrebno, komplikovano,... sad nemamo gotov engleski rečnik.

Mislim da bi to bilo preterano komplikovano, faktički bi trebalo raditi posebno parsiranje za svaki jezik.

Ne! Program koji parsira XML fajl, čita IMENA tagova iz neke tabele.

Ako je jezik "srpski" iz tabele će se uzeti imena tagova na srpskom.
Ako je jezik "engleski"iz tabele će se uzeti imena tagova na engleskom.
...itd...
Ako je jezik "MojaImena" iz tabele će se uzeti imena tagova koje je autor sam odredio da nešto znače.

Ovo sve radi SAMO ako se uvede tag: <Jezik>

Isti program bi samo na osnovu jedne promenljive dobijene iz taga: <Jezik>, punio XML fajl drugim nazivima.
Nemoguće da je ovo komplikovano i da može prostije.

Tag <Jezik> možemo imenovati i <Lang> ili kako već.

Navedena tabela/rečnik može da stoji na disku u fajlu ili da u okviru neke indeksne promenljive, bude uključena u parser.exe

Suština XML razmene ovako postavljene, a koju nikako ne umem da objasnim, ne zahteva nikakav dodatni trud, jer oni podaci koji ti ne trebaju ti ih iz XML dokumenta ni ne uzimaš, oni pored tvog programa prolaze nezapaženo, ne opterećuju tvoj sistem, program ili šta već.

   Ako je ovo DPO "datum nastanka dužničko-poverilačkog odnosa", onda je to valjda to. Ako je datum prometa, onda treba dodati.

  <Datum>    - datum dokumenta 
  <DatumDPO> - datum nastanka dužničko-poverilačkog odnosa 
  <Valuta>   - datum plaćanja 

Jeli ovo odgovarajuće?

Pozdrav, Toni Babić

 
Posted : 07/12/2014 7:54 pm
(@nbatocanin)
Posts: 113
Member
Topic starter
 

Moj predlog je da se <Tel> i <Mail> mogu pojaviti 1 ili više puta za isto ime:

<Kontakti>			
  <Kontakt>			
    <Ime>*</Ime>
    <Tel>*</Tel>
    <Tel>*</Tel>
    <Tel>*</Tel>
    <Mail>*</Mail>
  </Kontakt>
  <Kontakt>			
    <Ime>*</Ime>
    <Tel>*</Tel>
    <Mail>*</Mail>
    <Mail>*</Mail>
    <Mail>*</Mail>
  </Kontakt>
</Kontakti>

Ok, ovo je prihvatljivo, mada mislim da nije nešto preterano bitno.

Pre devet godina si napisao ovo:

>Wings.NB:
>Treba još jednom razmisliti o jeziku na kome će se praviti ključne reči.
>...
>...mislim da imamo mnogo bolje šanse ako koristimo srpsku terminologiju.

Ako si tad bio u pravu, da li si sad u krivu? Ne, ali dobrim delom zbog stava, to je previše, nepotrebno, komplikovano,... sad nemamo gotov engleski rečnik.

Svaka čast na memoriji, ja se jedva sećam jučerašnjih događaja 😉 Šta da kažem, tada sam mislio tako, a evo sad sam valjda pametniji, pa mislim ovako. Za prevod se ne bih brinuo, verujem da je to lak i brz posao za profesionalnog prevodioca - evo mogu ja da ga nađem.

Ne! Program koji parsira XML fajl, čita IMENA tagova iz neke tabele.
Ako je jezik "srpski" iz tabele će se uzeti imena tagova na srpskom.
Ako je jezik "engleski"iz tabele će se uzeti imena tagova na engleskom.
...itd...
Ako je jezik "MojaImena" iz tabele će se uzeti imena tagova koje je autor sam odredio da nešto znače.

Ok, ali i to mi deluje kao nepotrebna komplikacija, a ne vidim neku prednost takve osobine.

  <Datum>    - datum dokumenta 
  <DatumDPO> - datum nastanka dužničko-poverilačkog odnosa 
  <Valuta>   - datum plaćanja 

Jeli ovo odgovarajuće?

Meni je ok, ali nisam siguran da su ove dve stavke iste? Imamo li datum prometa?

 
Posted : 07/12/2014 10:11 pm
(@toni-babic)
Posts: 35
Member
 

Svaka čast na memoriji, ja se jedva sećam jučerašnjih događaja 😉

Moja je memorija u istom stanju ako ne i gorem ;))
Molim te pročitaj tekst: "upss2006a09-predlogXMLrazmene.txt", red: 20-23, u prethodno priloženom "UPSS_RazmenaPodataka_2006a10.zip" arhivu. To je citat iz tog dokumenta, od pre 9 godina.
Kad sam ponovo prilagao inicijalnu verziju pročitao sam sve još jednom. Otud mi sećanje!

Ok, ali i to mi deluje kao nepotrebna komplikacija, a ne vidim neku prednost takve osobine

Kako je moguće da ti, koji si kroz glavu i prste preturio gomilu koda, ne vidiš čemu ovo služi.
Na ovaj način se postiže veća fleksibilnost. Nisi zakucan za jedan jezik, jedno rešenje, a razlika u kodu je jedan red!

Naprosto te molim da imaš poverenja da je predloženo deo šire slike, za koju ili nemaš vremena da je vidiš ili ja nisam dovoljno rečiti da je objasnimo, ali stvar nije za cepidlačenje, a počinjem da verujem da se upravo to dešava.

Sistem postavljen pre devet godina i usput sve vreme razrađivan i popravljan i prezentovan u "UPSS_XML_2.5.docx" naprosto RADI.
Klijenti DP/ND razmenjuju podatke koristeći ove procedure GODINAMA.

Ja shvatam da postoje oprečni interesi. Shvatam da je liberalni kapitalizam napredovao i postao predatorski, i da je na sceni fraza: "ili si sa nama ili te nema".
Sve je to meni jasno, ali je ovo inicijalno bio deo zajedničkog angažovanja da se IT u Srbiji poboljša. Otvoreni standardi ne znače da ih ne možeš naplatiti. Ti naplaćuješ svoju uslugu koju si ostvario korišćenjem otvorenog, besplatnog rešenja. Ovo naše nastojanje je trebalo omogućiti svima da koriste definisane procedure, i ne gube vreme oko osmišljavanja svog standarda razmene podataka.

Imamo li datum prometa

Datum nastanka prometa je datum kada je nastao dužničko-poverilački odnos. Da li je to OK?

Pozdrav, Toni Babić

 
Posted : 07/12/2014 11:25 pm
Page 1 / 3
Share: