RSS

Category Archives: Implementacija

Web program za obračun zarada

Web program za plate – slušati zahteve korisnika ili ne?

Prošle nedelje sam nekolicini registrovanih omogućio pristup radnoj verziji najjednostavnijeg programa za obračun plata i od nekoliko ljudi sam dobio istu primedbu i sugestiju, koju sam odradio u zadnja 2 dana, ali i večeras ipak odlučio da odstranim taj već odrađeni kod.

Razlog  zašto sam to odlučio je po meni veoma zanimljiv i izlazi van suvoparnog konteksta programa za plate pa rekoh da podelim sa vama svoje rezonovanje na tu temu koristeći program za plate čisto kao pokazni primer.

Opis problema i sugestije

Opis problema je za mene bio prilično šokantan: “Kako da odštampam obračun zarade? Kako da ga snimim kao pdf fajl koji onda mogu da pošaljem svom klijentu? Kako da odštampam m4 obrazac?”

Evo stranice koja pokazuje spisak obračunatih zarada u stanju kakav je bio prošle nedelje na kome sam ja osmislio da se štampanje ostvari.

Složićete se verujem da kada vam više korisnika postave ovako bitno pitanje uvidite jako brzo da imate kritični problem u svom pristupu dizajna ekrana.

Analiza problema

Osnovni problem je očigledno to što na samom ekranu nije jasno uočljivo gde korisnik treba da klikne da bi odštampao obračun. To što u koloni izveštaji stoji link dokumentacija koji je po meni očigledno namenjen za to sudeći po povratnim informacijama ne znači apsolutno ništa.

Pošto je štampač opšte prihvaćen grafički simbol koji asocira na štampu, odmah menjam njime ovaj glupi link

Kao što vidite na ovom ekranu, ikona štampača je uočljiva u zadnjoj koloni – problem otkrivanja je rešen, a ista metafora se koristi i za sekciju zbirnih izveštaja.

Hm, testirajući rešenje sa par mojih testera dolazim do novog feedbacka – “zašto klik na štampač ne štampa nego mi pokaže moje dokumente na ekranu?”

Ok, validan feedback – tehnički precizno govoreći zaista se ne štampa ništa nego se pokazuje PDF dokument u Adobe Reader-u – menjam…

Feedback? “A šta je ovo crveno? Kako da odštampam obračun? Kako da ga snimim” – menjam….

Nekoliko revizija i iteracija sa mojim testerima i dolazim do rešenja koje obuhvata sve sugestije

Feedback na vizuelnu skicu – jednoglasan :

“Odlično. Sad imam dugme za štampu, za snimanje, za brisanje i za pregled. Kako to da ovo nisi odmah ovako odradio kad je ovako prosto i očigledno?”

Ništa, kad je tako – kodiram rešenje i testiram ga prošlu noć – problem rešen.

Međutim…

Iz nekog razloga meni nepoznatog, meni se rešenje nije dopadalo te sam danas vozeći se metroom na posao razmišljao o tome šta je ispravno ovde učiniti. Na ovom blogu sam više puta već pisao o tome kako mi je interes korisnika uvek na prvom planu pa čak i kad ide meni na štetu i ovo mi je izgledalo kao savršen primer gde moram da prihvatim da odradim nešto u šta ne verujem jer korisnici to traže.

Truckam se ja tako u metrou pospano sve do momenta dok se nisam setio one čuvene izjave Henrija Forda “Da sam pitao korisnike šta žele, tražili bi mi brže konje.” i to me nagnalo da krenem da razmišljam o tome zašto mi to oni traže.

Odgovor do koga sam ja došao razmišljajući na ovu temu se svodi na to da oni verovatno u svom obračunavanju plata koriste programe za obračun plata (dos, Windows – nebitno) i da im je u glavi mentalni model oko toga kako rade obračun zarada satkan oko toga kako aplikacije funkcionišu, a ne oko toga kako Web prirodno funkcioniše.

Ono što mi oni traže su dugmad koja iniciraju određene operacije što ima smisla u desktop svetu, ali nema u Web svetu koji je satkan od sadržaja prikazanog na ekranu povezanog sa drugim sadržajima hiper vezama itd.

Taj zaključak do koga sam došao me je naterao da preispitam danas šta je najbolje za moje korisnike i odgovor do koga sam ovo puta došao je potpuno drugačiji, a to je da je ispravna stvar da implementiram svoj sajt na najjednostavniji mogući način koji je najviše moguće usklađen sa “duhom Web-a” i da trebam da se fokusiram na propagiranje i edukaciju takvog pristupa jer je prihvatanje toga zaista u najboljem interesu mog korisnika iako znam da će naići na bitan inicijalni otpor.

Rešenje

Kao što vidite, ovo je jednostavno rešenje koje je funkcionalno povratak na početak gde je jedino odstupanje od Web duha grafički prikazani hiper link – tekstualni link na žalost niko ne vidi.

Poenta ovog ekrana je da pokaže spisak obračuna i omogući korisniku da pronađe onaj koji mu treba – ništa više od toga.

Kada korisnik želi da snimi/odštampa/pošalje on klikne na lupu (koja je najobičniji a href element) i onda mu se u novom tabu/prozoru otvara pdf dokument.

S obzirom da sam odlučio da nemam zasebno dugme za štampu, a imajući u vidu da je verovatno u 90% slučajeva željena štampa dokumenta automatski podrazumevano pokazujem momentalno dijalog za štampu korisniku istog momenta kada se učita izveštaj

U 90% slučajeva korisnik samo klikne Print (ili lupi Enter) i dokument se štampa – koristi se standardna funkcionalnost PDF readera.

Ok, štampa je pokrivena time na efikasan i elegantan način – šta je sa ostalim zahtevima? Kako da se snimi dokument i pošalje klijentu?

Po meni je najbolji odgovor na to – nemojte ni da snimate jer onda mu šaljete dokument emajlom, on nema vremena danas da pogleda, otvara to sutra, a vi u međuvremenu ispravili neku grešku u obračunu itd… Ja razumem da je sve to standardna procedura u tome kako većina ljudi radi danas, ali nam Web daje mnogo jednostavnije rešenje – Web adresu dokumenta.

Evo recimo na primeru gore, ako ja kopiram adresu iz mog browsera i pošaljem vam emajl-om vi ćete moći da je otvorite čak i da nemate nikakav nalog na papirima. Evo, probajte sami…

http://arhiva.papiri.rs/1034075907901927/2013/Plate/TEST_9792_Plata_2013_3.pdf

Osnovna prednost ovog pristupa je da se izbegava pojava više verzija dokumenata gde više ni vi ni klijent ne znate koja je poslednja – kad god klijent ili vi kliknete na gornji link videćete ažurnu verziju obračuna plate za jun 2012-e.

Ipak, recimo da se ne slažete sa mnom ili da iz nekog razloga da vi ipak želite da snimite dokument – šta onda?

Rešenje je prosto – koristite Web kako je standardno osmišljen na jedan od sledeća dva načina

Način 1 – povlačenje miša do dna stranice da se pojavi alatna traka sa operacijama reader-a

Način 2 – korišćenje menija samog browsera.

Zaključak

Ovo je po meni dobra ilustracija principa u koji ja verujem a sastoji se u tome da treba odabrati uvek pravi put koji je u najboljem interesu korisnika pa čak ako se to i kosi sa njegovim trenutnim zahtevima.

U ovom primeru ja sam umesto dodavanja dugmadi i pravljenja aplikacije od sajta, odabrao rešenje koje je jednostavno i elegantno i koje sa zasniva na standardnim principima kako Web funkcioniše.

To što moji korisnici možda nisu naviknuti na Web nije razlog da promenim svoju implementaciju već je to dobar pokazatelj da trebam da radim više na edukaciji i evanđelizmu po meni suštinski ispravnih rešenja.

A sad, nazad na programiranje – kraj meseca se bliži – treba sve utegnuti i završiti do tada Smeško

 

Obračun zarada baziran na realnosti

Metode obračuna zarada u Papirima

Juče sam na putu kući prolazio jednim parkom i video sam nešto što me podstaklo na razmišljanje o mom programu za obračun zarada. Naime, park je prostran, sa propisno obeleženim asfaltiranim stazama za kretanje, koje se seku pod pravim uglom precizno odslikavajući namere arhitekte enterijeriste. Ipak, ono što je meni privuklo pažnju  i podstaklo da napišem ovaj post nije bio taj prelepi park, već to što je park išaran dijagonalnim uzanim putanjama nastalim time kako ljudi u stvarnosti prolaze tim parkom svakodnevno. Njima je očigledno potpuno nebitno  kako je arhitekta zamislio da se oni kreću, oni biraju putanju koja je najpraktičnija jer žure negde, a park im je prepreka na to putu.

(Naravno da ne smatram ovo prihvatljivim, naravno da park ne treba tako da se uništava itd.. – nema potrebe da to prolazimo)

U Srbiji je zakonom propisan bruto obračun zarada gde se zarada zaposlenih izražava u bruto iznosu koji u sebi uključuje zaradu koju “zaposleni nosi kući” (tj. neto zaradu), poreze i doprinose na teret radnika. Svaki radnik ima određenu bruto cenu radnog sata i na bazi količine i strukture ostvarenih radnih sati njegova osnovna zarada se računa, a na  bazi nje se određuju i ostali delovi zarade zaposlenog.

Sve je to lepo, sem jedne stvari: ne koristi se toliko u praksi.

Suština ove pojave se sastoji u sledećim stvarima:

  • Zaposleni su tradicionalno zainteresovani samo za svoju neto zaradu
  • U Srbiji je dugo godina u upotrebi bio metod neto obračuna zarada
  • Matematički govoreći kao što se sa bruta može odrediti neto, tako se i za zadati neto bruto može odrediti.
  • Državu prvenstveno interesuje da je preduzeće *ne zakine na reketu* tj na porezu i doprinosima, tako da ne ulazi u to kako se dolazi do zarade radnika već samo da su porezi i doprinosi srazmerni izraženoj bruto zaradi.

Jednom rečju, sve dok su cifre tačno iskazane na propisanim obrascima, državu ne zanima kako ste ih tačno obračunali

Ja sam pre jedno godinu dana pisao o tome da je moj pristup modeliranju poslovne stvarnosti fokusiran na realne radne procese koje moji korisnici svakodnevno obavljaju, pa iz toga izvodim najprostiji mogući programsko okruženje koje zadovoljava te procese, a ne obrnuto da softver nastaje prvi kao što je slučaj verujem kod dosta postojećih programa na tržištu.

Na primeru programa za obračun plata i u kontekstu metoda obračuna zarada to bi značilo da se ne držim rigidno zakonom propisanog “bruto satnica…” iz prostog razloga što “normalni ljudi” nemaju pojma kako da odrede kolika je bruto satnica radnika u magacinu. Normalan poslodavac kada zapošljava radnika razmišlja o cifri “koliko će mene ukupno ovaj radnik da košta”, a radnik “koliko meni ide na ruke” – nijednom od njih dvoje bruto iznos zarade ne znači ništa.

Da se poslužim primerom parka sa početka ode i da kažem da ja na svoj program za plate gledam kao da sam napravio park bez staza, posadio kentaki plavu travu svud, i na dan otvaranja pustio ljude da hodaju po njoj. Gde na kraju dana se ukažu utabane staze – to betoniram.

Pa da vidimo šta su to korisnici ugazili u mom parku tokom rada na Papiri obračunu zarada.

Vrste obračuna zarada

U mom parku postoje četiri osnovne staze – četiri osnovne metode obračuna zarada – poređane tako da one koje se najčešće koriste u stvarnosti idu prve.

 

Minimalac

Žalosna je istina (barem u kraju odakle sam ja) da je privredno stanje u našoj zemlji teško, da je velika nezaposlenost i da su nameti i dažbine na zaradu zaposlenih jako velike. Te tri stvari primoravaju veliki broj poslodavaca da radnicima isplaćuje zakonski propisanu minimalnu zaradu – “minimalac”.

Do marta 2013. minimalna cena radnog sata je tako propisana (potpuno nelogično u neto iznosu) na 115 dinara. Da bi stvari uprostio sa stanovišta obračuna ja taj iznos prevodim na bruto cenu na sledeći jednostavan način:

  • Najveći broj radnih sati u mesecu je 184 pa uzimam tu vrednost
  • Minimalna neto zarada za taj mesec je 184 sati  * 115 din neto =  21160 din neto mesečno
  • 7822 * 12% = 938.64 din poreske olakšice za mesec rada
  • Minimalna bruto zarada je po ovoj logici jednaka
    (21160 – 938,64) / 0,701 = 28846,45 din

 

Minimalna bruto cena rada u papirima se računa na bazi svega navedenog ovako

28846,45 / 184 = 156,77  din ~= 157 din bruto/h.

Ovakva bruto cena rada naravno da nije savršeno precizna jer se zasniva na pretpostavci o mesecu sa 184 radna sata, ali tu uskače u igru zaokruživanje na gore na 157 dinara što u praksi znači da će poslodavac u proseku da plati možda samo par stotina dinara više iznad teoretskog minimuma, a ja imam trivijalno prost obračun minimalne zarade.

Nadalje za sve radnike se koristi cena od 157 din koja se množi sa brojem sati i onda je to osnovica za računanje dodataka.

Moje dalje rezonovanje u pravcu uprošćavanja obračuna minimalne zarade ide ka tome da ko isplaćuje minimalac, njega topli obrok i regres i ne zanimaju tako da ja implicitno koristim u ovom obračunu razumne minimume tih dodataka: mesečni iznos od 100 din regresa i 10 din na dan dodatka za topli obrok.

Kako gazda kaže

Ovo je drugi čest primer o tome kako se plate definišu u praksi. Plate definisane na ovaj način se definišu između poslodavca i zaposlenog u ukupnom fiksnom mesečnom iznosu koji radnik prima bez obzira na broj radnih sati efektivno time rezultujući promenljivom cenom rada koja se prilagođava zadatom ukupnom iznosu.

Tip definisanog iznosa je različito u zavisnosti od toga iz kog se ugla formira zarada zaposlenog

Ugao radnika Pere:

  • Plata mi je 30000 din mesečno.
  • Plata mi je 300 evra mesečno.

 

Ugao poslodavca:

  • Želim da me Pera mesečno ukupno košta 30000 din.
  • Želim da me Pera mesečno ukupno košta 300 evra.

Kao što se vidi iz ova dva primera iako su cifre identične nominalno, tip iznosa definisan u ova dva slučaja je različit: u prva dva slučaja se radi o neto iznosu, dok se u zadnja dva radi o super bruto iznosu (bruto zarada + doprinosi na teret poslodavca).

Drugim rečima, bruto fiksni iznos plate u stvarnosti ne znači ništa ni zaposlenom (koga zanima neto) ni poslodavcu (koga zanima stvarna ukupna cifra) te utabane staze mog parka obračuna zarada izgleda ovako

Kao što vidite u opcijama sam definisao slučaj kada se kaže da će se mesečne zarade zaposlenih unositi u neto dinarskim iznosima. S obzirom da se ovde ne radi više o minimalcu, smatram da korisniku ima smisla ponuditi da promeni “razumno minimalne” iznose regresa  i toplog obroka, kao i da definiše da li dodeljuje stimulacije radnicima povrh dogovorene fiksne neto zarade.

Ovo je naravno samo primer kako neto dinarska mesečna zarada se definiše, program omogućava i ostale načine unosa  i definisanja zarada zaposlenih.

Evo podržanih tipova iznosa

A evo i podržanih valuta

Odabirom željene kombinacije ta dva izbora moguće je objasniti programu da će se zarade zaposlenih unositi npr kao: neto iznos u evrima, super bruto iznos u dinarima, super bruto iznos u evrima, bruto iznos u dinarima itd.

Bukvalno je na korisniku da saopšti Papirima na koji način u stvarnom svetu on razmišlja i definiše plate zaposlenih, a Papirima ostavlja da nekako šta god on odabrao u obračunu magično svedu na zakonski propisanu bruto cenu rada,satnice itd.

Nastaviće se…

 

Posted by on 04.12.2012 in Implementacija, oblak, Plate

8 Comments

Tags:

Knjigovodstveni programi u oblaku

Prednosti i izazovi programa za knjigovodstvo u oblaku

S obzirom da je tematika poslovnih aplikacija i “cloud computing-a”” u poslednje vreme jako aktuelna, odlučio sam da i ja iznesem svoja razmišljanja na temu uloge oblaka i knjigovodstvenih programa.

dCloud

Šta je to “oblak” i što se toliko priča o njemu u poslednje vreme?

Velika većina programa za knjigovodstvo danas su tradicionalne desktop aplikacije čiji se domen integracije u većini slučajeva ostvaruje u okviru lokalne mreže kompanije uz povremene izlete širenjem te lokalne mreže između podružnica putem VPN povezivanja. Osnovni problem (u kontekstu ovog posta) sa ovim tipom programa je u tome što ne postoji jednostavan način povezivanja korisnika koji su van lokalne mreže i u tome da je set podataka centralizovan na jednom mestu, a znate i sami onaj štos u vezi važnosti backup-a podataka

Korisnici se dele na dva tipa: oni koji su izgubili podatke 
i oni koji će tek izgubiti podatke.

CloudComputingPrvenstveno kao reakcija proizvođača programa na teškoće u instaliranju i ažuriranju desktop programa klijenata, ali delimično i u želji da se ova dva navedena problema otklone nastali su web programi za knjigovodstvo kod kojih je su program za knjigovodstvo i baza podataka na udaljenom serveru proizvođača knjigovodstvenog programa kojima se pristupa putem internet pretraživača kao što je na primer Firefox ili putem internet prebacivanja na kompjuter proizvođača knjigovodstvenih programa na kome se onda izvršava program. Kao jedna od osnovnih prednosti ovog rešenja po korisnike često se navodi to da o aplikaciji i podacima brinu profesionalci koji vrše redovno održavanje rezervnih kopija podataka, staraju se o problemima itd.

Programi u oblaku su dalji korak u “profesionalizaciji” web knjigovodstvenih programa. Logika ovde je da proizvođači knjigovodstvenih programa su eksperti u svom domenu knjigovodstvenih programa, ali nisu eksperti u domenu održavanja optimalnog stanja web resursa, mrežnoj infrastrukturi, nemaju dovoljno resursa da održe optimalno i efikasno funkcionisanje sistema kada veći broj korisnika u isto vreme kreće da koristi program itd. Iz tog razloga proizvođači knjigovodstvenih programa odustaju od  imanja sopstvenih internet servera, sopstvenih baza podataka itd u korist iznajmljivanja internet mrežnih resursa firmi specijalizovanih za to.

Ti internet mrežni resursi koji se rentiraju po potrebi se popularno nazivaju oblakom.

Prednost knjigovodstvenih programa koji se koriste oblakom je dakle da se:

  • o mrežnoj internet infrastrukturi  brinu firme specijalizovane za to (Microsoft, Amazon, Google itd)
  • o knjigovodstvenom programu na toj infrastrukturi se brinu firme koje ih prave
  • korisnika zanima samo kako da koristi program bez ikakvih instalacija itd.

Oblak i knjigovodstveni programi

Na žalost, po mom ličnom mišljenju, ova idilična slika nije sasvim primenjiva u oblasti poslovnih programa, prvenstveno usled problema koje  web knjigovodstveni programi imaju, a koji se ukratko svode na to da web knjigovodstveni programi ne iskorišćavaju maksimalno potencijale korisničkog kompjutera i limitiraju time korisničku produktivnost kao i na to da je meni postojanja internet veze kao preduslova za funkcionisanje poslovne aplikacije neprihvatljiv uslov za knjigovodstvene programe.

Kao rešenje tih nedostataka ja sam odabrao arhitekturu “S+S” knjigovodstvenih programa u kome se klasičan knjigovodstveni program povezuje se bazom podataka i setom internet servisa. Suština distribuiranog knjigovodstvenog programa je u tome da se u radu korisnik uvek koristi lokalno prisutnom bazom dok program preuzima na sebe slanje i preuzimanje novih podataka sa servera u oblaku. Pored baze u oblaku, koriste se i procesorski resursi u oblaku za stvari poput integracije sa B2B portalima dobavljača itd.

Ovakav koncept je na tržištu knjigovodstvenih proizvoda relativno jedinstven tako da svaki put kad ga prezentujem nekom dobijem more pitanja od kojih se neki ponavljaju, a s obzirom da njihovi odgovori određuju moje poglede na temu ovog članka knjigovodstveni programi u oblaku rekoh da ih pribeležim

Piši Milijana ‘vako…

Najčešće postavljena pitanja u vezi programa z knjigovodstvo u oblaku

  • Šta kad nema interneta?
    Program funkcioniše normalno u meri koja garantuje nesmetan rad do uspostavljanja internet veze. Onog momenta kada internet veza se uspostavi program sam pokupi sve promene kreirane lokalno i pošalje ih serveru u oblaku bez ikakve potrebe za korisničkom intervencijom – potpuno automatizovano.
  • Šta ako instaliram program na novom računaru (kući, druga prodavnica itd)?
    Program automatski-bez intervencije korisnika nakon instalacije pošalje na taj novi kompjuter ažurnu kopiju podataka tako da ste u roku od par minuta od instalacije programa potpuno spremni za rad.
  • Da li to znači da sa podacima moje firme mogu da pristupim od kuće, sa laptopa  i da vidim u realnom vremenu promene kako se dešavaju u preduzeću?
    Apsolutno.
  • Šta ako unosim podatke na više različitih mesta (kući, prodavnica1, prodavnica2)?
    Program automatski-bez intervencije korisnika sve podatke šalje na server gde se oni slažu u bazi u oblaku. Kompletiran set podataka se zatim šalje svim stanicama tako da svi imaju sve podatke.
  • Da li to znači da sa podacima mojih nekoliko maloprodajnih objekata mogu da radim od kuće? Npr. ako unesem kući kalkulaciju, odradim nivelaciju i slično za prodavnicu 1, to će se automatski pojaviti u kompjuteru prodavnice 1?
    Upravo tako.
  • Da li moj knjigovođa može da radi sa mojim podacima iz svoje kancelarije?
    Da li moj knjigovođa može da radi sa mojim podacima bez pristupa mojoj lokalnoj mreži (VPN itd)?
    Naravno da može. Knjigovođa se poveže sa centralnom bazom na internetu, odradi svoj posao i onda taj set novih podataka se sa internet servera pošalje na bazu koja se nalazi na računaru korisnika (isto kao br. 3)
  • Da li moj knjigovođa može da radi sa mojim podacima istovremeno dok ja radim svoj posao?
    Da li moj knjigovođa može da radi sa mojim podacima dok je meni ugašen računar?
    Naravno da može. Knjigovođa radi sa njegovom lokalnom bazom, korisnik sa njegovom lokalnom bazom potpuno nezavisno, a sinhronizacioni kod njihove promene šalje i prima sa internet servera.
  • Šta ako se baza na mom lokalnom kompjuteru obriše (disk se pokvari, obrišem je greškom itd)?
    Apsolutno ništa. Program će prepoznati da nema podataka i sa internet servera će skinuti ažurni set podataka tako da za par minuta baza je ponovo tu – potpuno automatski bez intervencije korisnika.
  • Šta je sa backupom podataka baze na internetu?
    Program koristi SQL Azure internet bazu podataka koja se sama po sebi kopira u dva geografski odvojena centra: jedan je u Irskoj drugi je u Holandiji. Sem toga, oblak svakog dana radi odvojenu backup baze u Table storage skladište na oblaku koji se takođe replicira lokalno na server moje firme..
  • Šta ako se baza u oblaku ipak obriše/uništi/pokvari, a nema ni rezervnih kopija? 
    To je potpuno nemoguće, ali čisto priče radi – neka bude. Ako bi se to desilo, nema problema opet jer svako od korisnika ima jednu ili više lokalnih baza sa kojima radi. Prazna baza na oblaku bi pozvala stanice da pošalju podatke sa lokalnih stanica i na taj način bi sama sebe regenerisala za manje od sat vremena.

    Questions

  • Da li neko može da prisluškuje i krade moje podatke dok ih šaljem na server u oblaku?
    Prisluškivač je onemogućen time što se sva komunikacija sa serverom u oblaku obavlja preko sigurnosnog šifrovanog SSL kanala (istu zaštitu koriste naprimer eBanking portali itd)
  • Da li neko može da skine sa internet servera moje podatke?
    Da li neko može na server da pošalje pod mojim imenom lažne/pogrešne podatke?
    Ukratko – ne. Svaki rad na sistemu zahteva da se korisnik prijavi i time dobija sigurnosni kod – token koji zatim šalje sa svakim paketom kao sredstvo identifikacije pošiljaoca. Dodatne provere poput IP adrese pošiljaoca itd su takođe uključene. Ovo su samo provere o kojima mogu javno da pišem – ima ih još par dodatnih koji garantuju poverljivost podataka.
  • A šta ako ipak neko nekako uspe da skine podatke sa internet oblaka?
    To je potpuno nemoguće, ali čisto priče radi – neka bude.
    Svi podaci tipa partnera, artikala, brojeva računa itd u bazi se nalaze šifrovani tako da i kad bi neko teorijski došao do podataka ništa u njima ne bi bilo čitljivo sem gomile brojki bez ikakvih ličnih podataka u njima.
    Slična vrsta zaštite je implementirana i u lokalnoj bazi.
  • Da li neki drugi korisnik može da dešifruje moje podatke?
    Ne. Svaki korisnik programa ima posebnu šifru koja se koristi za šifrovanje njegovih podataka.
  • Šta ako korisnik izgubi/zaboravi šifru?
    Tokom instalacije programa korisnik se pita da li želi da se kopija njegove šifre sačuva bezbedno na oblaku (dodatno šifrirana i zaštićena). U slučaju da se korisnik složi sa tim, kopija šifre postoji i njemu se šalje nakon striktne provere identiteta. U slučaju da se korisnik ne složi sa tim da moja firma u oblaku čuva kopiju šifrantskog ključa, on je jedini koji ga ima te u slučaju da ga izgubi nema mu pomoći – čak ni ja ne mogu da mu dekodiram podatke. Sam program će kao preporučen način će biti da se kopija ključa čuva u oblaku.
  • Šta je sa mojim podacima ako odlučim da ne budem više korisnik programa?
    Prvo, korisnik u svakom momentu ima potpuni set podataka na svom lokalnom kompjuteru tako da mu podaci u oblaku uopšte nisu potrebni. I pored toga, korisniku se svi podaci čuvaju besplatno na serveru neograničeno vreme tako da uvek može da ih skine u stanju u kome su zamrznuti kad god poželi bez zahteva da bude aktivan korisnik. Naravno, ako korisnik eksplicitno zahteva da se njegovi podaci obrišu iz oblaka, to je takođe moguće.
  • Da li je moguće ne koristiti sinhronizaciju sa oblakom?
    U cilju pojednostavljenja korisničkog iskustva i poslovanja moje firme – ne. Ono što je bitno naglasiti ovde da iako je sinhronizacija sa oblakom neophodan uslov, ona se obavlja potpuno nevidljivo za korisnika, može se obavljati povremeno (jednom dnevno, nedeljno itd) na bilo kojoj internet vezi (dial up, wifi, adsl) tako da obavezujući atribut ovog zahteva ne bi trebao da ima bilo kakve negativne posledice po korisničko iskustvo.
  • Da li se moji podaci svih poslovnih godina nalaze u jednoj bazi na oblaku?
    Korisnici sa osnovnom korisničkom licencom sve podatke jedne godine fizički drže u istoj bazi.
    Razlog za to je da je najmanja baza na SQL Azure oblaku veličine 1 Gb i košta 10 evra mesečno njen zakup, što uz trenutno percipiranu mesečnu cenu  zakupa programa od 25 evra je očigledno preveliko opterećenje imati zasebne baze po godini. Ako bi korisnik insistirao na zasebnoj bazi po godini, to bi dodalo po 10 evra na cenu mesečnog zakupa za svaku poslovnu godinu. Po meni je to čisto bacanje para, ali je moguće. Sve ovo se naravno odnosi na to kako su podaci fizički uskladišteni u oblaku. To apsolutno nema nikakvog uticaja na rad programa gde su podaci različitih godina pojavno potpuno razdvojeni. Drugim rečima korisnik ima utisak u radu kao da su zasebne baze.
    Takođe je u planu je da korisnik, nezavisno od toga kako su podaci u oblaku uskladišteni, sam odabere kako želi da ih ima podešene u lokalu – zasebna baza po godini ili ne.
  • Da li se samo moji podaci nalaze u bazi na oblaku?
    Koliko god ja voleo Microsoft, ne volim ih toliko da im poklonim polovinu mesečne pretplate mojih korisnika tako da su podaci više korisnika sa osnovnom licencom uskladišteni fizički u istoj bazi podataka. Logika ovde je da prosečan set podataka po poslovnoj godini je reda veličine 50 Mb, te je korišćenje baze od 1 Gb za skladištenje samo tih podataka bacanje 950 Mb prostora. Tehnika pakovanja podataka više firmi u istu bazu podataka se zove sharding ili horizontalno particionisanje , a u slučaju SQL Azure database se implementira putem korišćenja SQL federacija. Tehnikalije na stranu, ono što je suštinski bitno naglasiti ovde je da iako su podaci više firmi uskladišteni fizički u jednoj bazi u oblaku to nema apsolutno nikakvog uticaja na performanse, sigurnost i pojavne aspekte funkcionisanja programa korisnika. Naravno da i ovde postoji opcija “+10 evra mesečno” ako korisnik želi da ima svoju sopstvenu bazu.
  • Da li mi je potreban administrator mreža da podesim i/ili održavam oblak rešenje?
    Ne. Samo običan kompjuter sa internet vezom preko koga se skine instalacija programa,a program posle sve sam podesi i održava.
  • Da li i korisnici unutar lokalne mreže (npr. komercijala i magacin) razmenjuju podatke putem oblaka?
    Ne. Program podržava da se korisnici unutar lokalne mreže razmenjuju podatke putem servera u toj lokalnoj mreži, a taj zajednički server sve te promene zbirno i nezavisno od korisnika sinhronizuje sa serverom na oblaku.

Bilo je tu još pitanja, ali mislim da je i ovo verovatno već previše za članak, tako da ovde prekidam listu, a ako treba nastavićemo kroz komentare ovog članka ili putem maila.

S glavom u oblacima,
Vaš Nikola Malović

 

Tags:

Pobednik vremena

Moji roditelji su imali Renault 4 koji ja pamtim po udobnim sedištima, naopako jedinstvenom (čitaj: uber cool) menjaču, obliku cipele i reklami iz 80-tih inspirisanu Max Max-om.

Renault 4 – “Pobednik vremena“

Na žalost (ili na sreću – kako ko gleda), Renault 4 nije predmet ovog članka, ne proizvodi se dekadama te ga hajmo ostaviti memli istorije. Umesto njega, ovaj članak će se pozabaviti jednim njegovim ne manje bitnim vršnjakom: matričnim štampačem.

Knjigovodstveni programi sa podrškom za matrične štampače

U 2003-oj, najbolji način da nasmejte knjigovodstvenu agenciju tokom predstavljanja svog programa je da kažete da vaš Windows program ne podržava štampu u tekstualnom modu. “Nema matričnog štampača?” je bio uzvik (uobičajeno par oktava viši) koji je označavao uvek moment kada vlasnik knjigovodstvenog birao prelazi iz “slušam te” moda u “gde-li-ću-za-ručak-razmišljanje-praćeno-gašenjem-čula-sluha-i-slepo-klimanje-glavom”

S obzirom da smo evo već u 2011-oj i da ja nisam video matrični štampač već 5+ godina, ja sam iskreno bio mišljenja da su matrični štampači iščezli čak i kod nas, ali pre nekoliko dana reših da testiram svoj stav. Većina ljudi koje sam pitao (vlasnika malih preduzeća) su potvrdila moj stav: niko više ne koristi matrične štampače, te sam ja do danas verovao da neću morati da se opet zlopatim disproporcionalnim izveštajima za matrične štampače.

Međutim, danas mi je sve to palo u vodu kada mi je Milovan Kick-Ass-Knjigovodja na četu rekao da velika većina faktura koje dobijaju njegovi klijenti od svojih dobavljača je rađena i dan danas matričnim štampačima. Čak mi je rekao da i veći deo njegovih korisnika (neki od njih firme sasvim pristojne veličine) koristi i dan danas matrični štampač.

Naravno da sam ga pitao:”Ali zašto i dan danas se koriste štampači”
Odgovor: ”Jeftiniji su mnogo papir, toner i štampa u više kopija”

Tako sam i ja došao do odluke da, pre nego što kapituliram pred matričnim štampačem, proverim ovu tvrdnju i evo posta.

Koliko se štampači uopšte koriste?

Ako se uzme u obzir da u godini ima 264 radnih dana, mislim da je neki obim od hiljadu faktura godišnje sasvim reprezentativan kao uzorak. Naravno da ima firmi koje štampaju više i onih koje štampaju manje, ali je hiljadu verujem mnogo veća od njihove medijane. Plus, okrugla je brojka pa se lako računa Smeško

Nameće se takođe pitanje u koliko se kopija tih 1000 faktura štampa? Meni je izgledalo logična pretpostavka da se radi u dva primerka (jedan za kupca, jedan za dobavljača), ali mi je Milovan pojasnio da ima firmi koje štampaju u 4 primerka (1 kupcu, jedan komercijali, jedan ide računovodstvu, jedan malom Perici …) Za potrebe ovog članka preskočiću kritiku ovog drugog model i uzeti ga zdravo za gotovo.

Znači, u ovom postu se radi o primeru 1000 računa/faktura odštampanih u 2 i 4 primerka.

Matrični i laserski štampači

Standardni laserski štampač kod nas (kako mi je rečeno) je HP LaserJet 1010, ali pošto se on izgleda ne proizvodi više pretpostavljam da je nov bio u rangu HP 1102 štampača, čija je cena 11.000 dinara. Za firme koje imaju veći obim štampe HP 1010 je verovatno nedovoljan, te se u takvim slučajevima štampači poput Lexmark E260 sa 33 stranice u minuti su verovatno adekvatnije i dalje po prihvatljivoj ceni oko 13.000 dinara.

Cena matričnog LX 300 štampača je skandaloznih 26.000 dinara. O kvalitetu i brzini štampe kao i nivou buke koji kreira mislim da nema smisla trošiti reči

Sapienti sat, idemo dalje…

Tabuliri i tabaci

Jedna od prednosti matričnog štampača je što može da štampa više kopija.
Tabulir kutija a4 formata sa 1 dodatnom kopijom (“1+1”) od 900 preklopa/stranica košta 1330 dinara.
Odštampati 1000 računa u 2 kopije tako sa ovim tabulirom košta 1470 dinara (1.47 dinara po računu).
Odštampati 1000 računa u 4 kopije tako sa ovim tabulirom košta 3940 dinara (3.94 dinara po računu).

clip_image001
.

Tabulir kutija a4 formata sa 3 dodatne kopije (“1+3”) od 450 preklopa košta 1550 dinara,
Odštampati 1000 računa u 2 kopije sa ovim tabulirom teoretski košta 1722 dinara (1.72 dinara po računu).
Odštampati 1000 računa u 4 kopije tako sa ovim tabulirom košta 3444 dinara (3.44 dinara po računu).
.
clip_image001[8]

.
Tabak A4 papira od 500 lista za laserski štampač košta 429 dinara,
Odštampati 1000 računa u 2 kopije sa ovim papirom teoretski košta 1716 dinara (1.72 dinara po računu).
Odštampati 1000 računa u 4 kopije tako sa ovim papirom košta 3432 dinara (3.43 dinara po računu).

clip_image001[10]

Evo i uporedne tabele koja prikazuje cene papira
.
Varijanta Tabulir 1+1 Tabulir 1+3 Tabak laserskog papira
1000 računa u 2 kopije 1470 din 1722 din. 1716 din.
1000 računa u 4 kopije 3940 din. 3432 din. 3432 din.

Ako štampate matričnim štampačem uštedećete u najboljem slučaju na papiru 246 dinara godišnje.


Toneri i ribboni

Ovo je definitivno kategorija gde matrični štampač je neosporno jeftiniji sa svojih 500 dinara cene za traku štampača. Svi moji pokušaji da nađem negde podatak koliko kopija traka izvuče su propali, tako da joj priznajem “neograničen broj kopija” te samim tim cena utrošenog banera po stranici teži nuli.

Toner za HP 1010 štampač košta oko 2000 dinara i može da odštampa 2000 kopija te je cena utrošenog tonera po odštampanoj stranici jedan dinar. (Toneri polovnih i starijih štampača koštaju i manje od 0.5 dinara/stranici, ali za potrebe ovog članka to preskačem)

Dakle, da na laseru odštampate 1000 računa u 2 kopije –> 2000 dinara je vrednosti utrošenog tonera. 1000 računa u 4 kopije –> 4000 dinara vrednost utrošenog tonera.

Suma sumarum

Ako ste neko ko tek otvara firmu, samo odlukom da kupite laserski štampač štedite dovoljno novca da pokrijete utrošak tonera u sledećih 3-5 godina (punjenje za bar 15000 stranica). Ja stvarno ne vidim što bi IKO odabrao matrični štampač u ovom slučaju.

U slučaju da imate već laserski štampač, znajte da trošite mesečno dodatnih 3 evra (4000 dinara ekstra troška za toner) u odnosu da koristite matrični štampač-

U slučaju da imate već matrični štampač, zar je vaš duševni mir vredan tih 3 evra mesečno? Zar je tih 3 evra vrednije od stida koji verovatno osećate šaljući svom kupcu fakturu odštampanu na matričnom štampaču?
Zar nije bolje da platite tih 3 evra više i pošaljete fakturu koja po sadržaju i formi izgleda profesionalno i samim tim širi isti takav utisak o vama?

Posle ove računice koju sam ja izveo, ja stvarno ne razumem ljude koji koriste matrične štampače u 2011-oj.

Šta vi mislite o ovome? Koliko papira odštampanih matričnim štampačem prolaze kroz vaše preduzeće? Da li sam propustio neku prednost matričnih štampača? Da li podržavate matrične štampače u vašem programu /ako ste proizvođač knjigovodstvenih programa/

Hoćemo da penzionišemo već jednom te matrične štampače?

Vaš iskreno skeptičan,
Nikola DotMatrix Malović

 

Posted by on 04.01.2011 in Implementacija

7 Comments

Tags:

Distribuirani knjigovodstveni program

U članku o tome zašto su S+S desktop knjigovodstveni programi pravi put, kao jednu od odlika moje S+S arhitekture sam naveo distribuirani mrežni model koji zahteva malo detaljnije objašnjenje. Opet je poseban naglasak na pokušaju objašnjavanja ove usko tehničke teme na način razumljiv ljudima koji nisu programeri.

Prvo da pojasnim sam koncept, pa onda da pređem na odgovaranje Radenkovih pitanja iz komentara prethodnog posta…

Distribuirani knjigovodstveni program – koncept

Ako uzmemo primer centrale sa izdvojenom poslovnicom u nekom drugom gradu, postavlja se pitanje kako se one povezuju međusobno i kako se povezuju sa oblakom.

LAN/WAN bazirano rešenje

Rešenja koje sam ja viđao 2003-e su se svodila na postojanje direktne VPN veze između centrale i poslovnice sa bazom koja se nalazi na serveru centrale i nju koriste aplikacije i u centrali i u poslovnicama.

image

Suština ovog rešenja je da iako su lokacije geografski udaljene one suštinski su deo iste sigurnosne zone istog LAN-a. Prednost ovog modela je što podaci unešeni i u centrali i u poslovnici su momentalno vidljivi na oba mesta.

Neke od mana ovog modela po mom mišljenju su:

  • performanse –svi se upiti iz poslovnice šalju do centrale odakle onda se vraća set rezultata. Što više poslovnica sve je veći pritisak na računarske i interent resurse centrale itd
  • zavisnost poslovnice od centrale – u slučaju da kompjuter na centrali se ugasi, internet veza se poremeti itd poslovnica postaje neupotrebljiva
  • kompleksnost rešenja – profesionalna VPN mreža podrazumeva Cisco mrežnu opremu koja zahteva posebne stručnjake za administriranje i održavanje.
  • skupo
    Zakupljivanje dovoljno protočne linije u centrali da podrži 50 poslovnica i plaćanje plata Cisco administratorima nisu zanemarljivi troškovi po mom ličnom mišljenju.
  • zasniva se na odnosu poverenja
    Recimo da je sigurnosno prohvatljivo da poslovnice imaju direktan pristup podacima centrale i da je prihvatljivo to što su sve poslovnice u VPN vezi sa serverom. Šta ćemo sa knjigovođom iz knjigovodstvene agencije? Šta je sa distributerima i kupcima koji bi da poruče robu od nas? Hoćemo i njima svima da damo ključeve od našeg sistema?

Internet distribuirano rešenje

Kod mog distribuiranog rešenja, Internet se koristi za asinhronu sinhronizaciju podataka subjekata bez postojanja njihove direktne veze rešavajući na taj način gore opisane mane.

image

Podaci koji se kreiraju u centrali se šalju na oblak bez znanja ko će podatke da konzumira. Što se tiče centrale ne postoji u sistemu niko drugi sem nje i oblaka. Oblak je aplikacija koja “živi” na internetu 24 sata dnevno/365 dana godišnje uvek dostupna na bilo kom mestu gde postoji internet bez potrebe za VPN-ovima itd.

Recimo da se u centrali tako unese novi poslovni partner, koji se iz baze centrale kopira na bazu u oblaku. Svi učesnici u procesu periodično pozivaju oblak i pitaju “Da li ima nekih novih podataka u tvojoj bazi koji me se tiču?”. Oblak odgovara “Da,postoji novi partner. Zainteresovan?”. Recimo da Poslovnica 1 jeste zainteresovana za to te to i javlja oblaku. Oblak onda uzima podatke partnera i šalje putem interneta aplikaciji koja se izvrsava u poslovnici 1. Poslovnica 1 prihvata taj podatak i skladišti ga u svojoj bazi. Na taj način baza podataka u poslovnici 1 je dobila podatak iz centrale što omogućava knjigovodstvenom programu u poslovnici 1 da u svom radu radi samo sa tom bazom u lokalu, bez posezanja za bazom u centrali.

Prednosti ovog modela su sledeće:

  • performanse
    Program u poslovnici 1 se izvršava isključivo korišćenjem lokalnih resursa
  • nezavisnost subjekata
    Poslovnica 1 i centrala nisu direktno zavisne jedna od druge. Ako bi npr. ugasili kompjuter u centrali poslovnica bi i dalje radila. Poslovnica takodje nije zavisna ni od oblaka. Izvucite mrežni kabl i radiće i dalje. Sinhronizacija između subjekata može da se ostvaruje po potrebama subjekata: npr. poslovnice mogu da proveravaju svakih 10 minuta da li ima novih podataka za njih, dok centrala može da preuzme podatke iz poslovnica jednom dnevno nakon završetka radnog vremena. Moguće je odraditi naravno i “sinhronizaciju po potrebi” gde korisnik u Poslovnici 1 bi kliknuo na dugme “Ažuriraj” i inicirao početak sinhronizacione sesije.  To su samo dva primera koji ilustruju mogućnost definisanja dinamike sinhrinizacije za svakog subjekta poslovnom sistema ponaosob po potrebama preduzeća. Samoj aplikaciji je svejedno kad i koliko često se izvršava.
  • kompleksnost rešenja
    Nijedan od subjekata ne treba da radi absolutno ništa da bi se sinhronizacija izvršavala. Svako od subjekata radi svoj posao normalno /npr. fakturiše/, a moj knjigovodstveni program sam ispod haube orkestrira onda sinhronizaciju. Krajnji cilj je da niko u centrali ili poslovnicama ili bilo gde uopšte bude svestan te sinhronizacije.
  • cena
    Nema potrebe više za posebnim IT stručnjacima niti za skupocenim širokopojasnim vezama jer svaki od subjekata šalje i prima samo diferencijale podataka. Npr. poslovnica 2 može biti u nekom selu gde ADSL ne može da se uvede i recimo može svake ponoći da ostavri dial up vezu i dva sata šalje podatke na oblak.
  • poverenje
    Jednom kad imate ažuran set podtaka u oblaku koji predstavlja uniju podataka centrale i poslovnica, knjigovodja iz svoje kancelarije može da im pristupi putem interneta. Nikakv pristup centrali i poslovnicama više nije potreban i podacima može da pristupi bukvalno 24 sata dnevno. Kao što vidite na gornjoj slici i knjigovodja ima lokalnu bazu u svojoj kancelariji/kompjuteru tako da sve što je rečeno o sinhronizaciji centrale i poslovnica vazi i ovde.
    Na gornoj slici takodje možete da vidite i primer dva kupca gde jedan ima bazu, a drugi nema.
    Što se tiče ovog prvog, priča je ista kao i sa poslovnicama i knjigovodjom. Ono što je veoma bitno primetiti ovde je da ne dobijaju svi učesnici u sinhronizacionom procesu isti set podataka. Oblak odlučuje na bazi toga ko je subjekt šta od podataka mu šalje. U ovom primeru tako kupac 1 bi mogao na primer samo da dobije katalog artikala sa njegovim vp cenama. Postoji centralno sigurnosno mesto – oblak  – gde se definiše ko šta dobija.
    Drugi kupac nema bazu na ovom dijagramu jer on podacima pristupa putem B2B web sajta. Jednom kad imate bazu podataka u oblaku, u mogucnosti ste da napravite web sajt za rad sa tim podacima tako da kupac radi sa tim web sajtom vršeći kontrolisane promene nad bazom u oblaku koje se putem sinhronizacije sprovode do ostalih zainteresovanih subjektata (npr. centrale)

Odgovori na Radenkova pitanja

Kako se obezbedjuje pravovremena sinhronizacija izmedju subjekata?

Problem: “Ako se kreira podatak u centrali, do momenta sinhronizacije u poslovnici on se ne vidi u programu…”

Nisu svi podaci jednaki. Neki podaci se češće menjaju neki ređe. Neki podaci su bitni za rad oba objekta, neki su opet kritično bitni samo u radu tog objekta.

Npr. ako kupac dodje u poslovnicu jedan u Beogradu da kupi gradjevinski materijal i recimo nema toga što traži na stanju njega verovatno ne interesuje to što ga ima na stanju u Nišu. Ako vlasnik ima lanac apoteka, da li je bitno to što ima aspirin u apoteci na drugom kraju grada? Verovatno ne, jer ćete otići u drugu obližnju apoteku.

I pored toga što po mom praktičnom iskustvu većina podataka spada u grupu “toleratnih na kašnjenje”, definitivno se ne može tvrditi da su svi takvi u svakom slučaju.

Postoje razna rešenja ovog problema, ali ono koje po meni predstavlja najbolji kompromis izmedju efikasnosti rešenja, jednostavnosti rešenja i realne upotrebe je omogućavanje definisanja frekvencije intervala slanja i primanja na nivou entiteta kobmbinovano sa sinhronizazijom “na zahtev”.

Recimo da je podrazumevano podešavanje sistema da centrala na primer na svaka 30 minuta uzme sve nove podatke, spakuje ih u jedan paket i pošalje odjednom na server. Recimo da je to prihvatljivo za vecinu stvari ali ne i za partnere gde se zahteva uskladjenost podtaka. U tom slučaju bi se sistem podesio da nove partnere šalje u oblak čim su kreirani u centrali, nezavisno od ostalih podataka koji i dalje idu svaka 30 minuta. U zavisnosti od realne situacije knjigovodstevi program u podružnici se može podesiti npr da proverava svakog minuta da li ima novih partnera (ostali podaci se proveravaju na 30 minuta). Recimo da ni ta ažurnost u minuti nije dovoljna i da se ulazi u katalog partnera 30 sekundi nakon što je partner kreiran na centrali. U tom teorijskom slučaju, pre nego što se učita ekran unosa partnera, program u podruznici izdaje zahtev oblaku (“Pošalji mi nove partnere”) potpuno neovisno o osveživanjima koje se izvršavaju svakih 1 i 30 minuta. Ključni momenat je da se tim zahtevom dobija mala količina podataka (“samo partneri kreirani od prošle sinhronizacije”) te to ne utiče na performanse rada računara.

Dvosmerna komunikacija je isto izvodljiva, ali je rešenje koje limitira fleksibilnost sistema u smislu da oblak mora da bude svestan konzumenata što je po meni neprirodno, a srećom i nepotrebno usled postojanhja gore opisanog rešenja. Smile

Rezolucija konflikta

Problem:”Šta raditi kad ipak kad oba objekta kreiraju istog partnera?” (npr. Poslovnica 1 nije imala internet 2 dana.)

Ovo je teško objasniti bez tehnikalija, ali se ukratko svodi na to da programski svaki od partnera ima svoj jedinstveni ID koji je garantovano različit za sve partnere bez obzira kad i gde su kreirani. Sa aspekta sinhronizacije podataka, to bi rezultovalo time što bi spajanjem podataka centrale i poslovnice rezultovalo sa dva reda u bazi koja bi sadržala iste podatke. Sa stanovišta programa to je situacija koja ne pravi nikakve probleme, ali opet nije prihvatljivo imati evidenciju za partnera na više mesta. Taj problem rešavam time što u oblaku u momentu spajanja podataka proveravam postojanje logičkih duplikata – partnera sa istim PIB-om, artikala sa istim bar kodom. Kada se logički duplikat detektuje, duplikati se brišu a sva dokumenta koja su referencirala “duplikate” se prepravljaju da ukazuju na “original”. Sledeća sinhronizacija – sređen set podataka putuje ka svim stanicama što rezultuje normalizacijom partnera iz ovog primera.

Sigurnost podataka tokom sinhronizacije

Komunikacija između oblaka i subjekata sinhronizacije se obavlja sigurnim SSL transportnim kanalom što je samo po sebi dovoljno sigurno. Ipak za svaki slučaj inicijalni prenos podataka (kada destinacija sinhronizacije nema nikakve podatke pa se cela baza šalje) se takođe enkriptuje sigurnosnima sertifikatom radi povećane sigurnosti. Sve sinhronizacije diferencijala nakon inicjalne sinhronizacije se ne enkriptuju zbog performansi jer je potencijalna opasnost mnogo manja (ako neko u teoriji dodje do podataka jedne moje fakture to je manje opasno nego da dodje do svih faktura, svih partnera itd). Uz ovo standarno obezbedjenje transportnog kanala i poruke tu je i jedna moja lična dodatna mera sigurnosti o kojoj opet ovde ne bi da pričam mnogo da ne kvarim zabavu potencijalnim “hakerima”. Sve u svemu, po mom stručnom mišljenju sinhronizacija podataka  pokrivena ovim metodama je potpuno sigurna.

Performanse sinhronizacije i sistema tokom sinhronizacije

Sve se sinhronizacije obavljaju korišćenjem posebnih threado-ova tako da je uticaj na rad sa knjigovodstvenim programom minimalan. Podaci se sinhronizuju po važnosti i obrnuto hronološki. Npr. inicijalna sinhronizacija je definitivno nešto što duže traje, ali ako se npr. podaci pametno sinhronizuju: prvo partneri, pa zadnjih 50 faktura, pa njihovi artikli id. čak i taj jedan jedini put kada sinhronizacija bude trajala korisnik će moći da radi sa računarom. U eri savremenih ADSL veza, poslati nekoliko megabajta preko žice tokom te inicijalne sinhronizacije ne bi trebalo da traje predugo. Čak i da traje, to je samo jednom. Nakon toga se skidaju samo novi redovi kreirani van sistema i šalju novi redovi kreirani na računaru – minimalan set podataka.

Zaključak

Distribuirana S+S arhitektura je arhitektura koja se koristi u veoma malom broju programa, podržana samo od Microsofta itd. Iz tih razloga sam morao da provedem značajniji vremenski period razmišljajući o poslovnom i tehničkom aspektu mog proizvoda, radeći na prototipovima itd pre nego što sam se mogao sa sigurnošću da ustvrdim da u potpunosti odgovara mojim potrebama bolje od ostalih arhitektura koje sam razmatrao.

Idealno dobra i loša rešenja ne postoje, sve zavisi od konteksta i upravo je u tome uloga arhitekata informacionih sistema da usklade potrebe sistema koji dizajniraju sa ponudjenim resenjima.

Moj izbor – distribuirani S+S Smile

Vaš?

Nikola TheDistributed Malović

 

Posted by on 19.08.2010 in Implementacija

3 Comments

Tags: ,