Koji je programski jezik pogodan za pisanje programa za racunovodstvo

Upravo to prvo sto si naveo :
evolucija jezika ili kako to jos zovu "extremely human readable o.o.p. vs sql code"
al otvara polako vrata za potpuno automatizovanje entity procesa preko razlicitih izvora podataka ili ti pravljenje polimorfnih upita ..
Da ne prevodim bas sve evo linkova o LINQ-u na msdn-u :

http://msdn2.microsoft.com/en-us/library/bb425822.aspx
http://msdn2.microsoft.com/en-us/library/bb308959.aspx




Samo bi da dodam i IQueryable<T> :)

Pozdrav !!!

---

Iskreno rečeno, tko će brže napraviti aplikaciju za računovodstvo: VB programer ili C++ programer ili Java programer?!

Zašto komplicirati kad može jednostavnije i brže.

Predlažem Visual Basic (ver 6. ili .net), u kombinaciji sa T-sql bazom.

Brzina i jednostavnost je danas vrlina dobrog programera.

U protekle tri godine radim sa knjigovodstvenim programima u web okruzenju ( Linux -Apache -PHP -JavaScript - MySQL ) nisam imao nekih vecih problema to sve radi korektno kao i fiskalni stampac, finansijsko ,robno ,obracun zarada,pomocne evidencije .To sve radi na internet konekciji ADSL cak je radilo solidno i na dial-up .Ako se instalira Linux server to radi u lokalnoj mrezi a moze se pristupati i sa udaljenog mesta preko internet konekcije .Ako bi se dodale AJAX metode programi bi dobili na kvalitetu .
Mislim da je ovakav nacin u buducnosti najpogodniji i daje mnogo novih mogucnosti a vrlo lako se prelazi na ovaj nacin rada sa starih DOS programa .

Krenulo je od pitanja "Koji je programski jezik pogodan za pisanje programa za racunovodstvo?" isključi sve što ima veze sa microsoftom, oraclom i ostalim skupim alatima i bazama. Koštaće tebe i tvoje klijente jako mnogo. MySQL, PostgreSQL, ili nešto slično za bazu. Perl, PHP, Java za alat. Ukoliko razvijaš aplikaciju za MSP (sa naglaskom na M) i želiš sutra da je lako održavaš (moraćeš), obezbedićeš sebi i svom softveru lepu budućnost. Brzina razvoja i brzina rada nisu najvažnije. Svi "test piloti" koji brzinu u ovoj vrsti programa smatraju presudnom verovatno NIKADA nisu napisali knjigovodstveni softver koji se koristi.

Kako si resio problem stampe za fiskalni racun iz browsera?



Ova tema se opasno pretvara u advocacy :)

---

samo da odbranim stav " isključi sve što ima veze sa microsoftom, oraclom i ostalim skupim alatima i bazama.". Ako je u pitanju softver namenjen MALIM preduzećima koja svrha je angažovati tešku artiljeriju za teške pare? Takav program NEMA kupca! "Spram sveca i tropar."

Da bi radio fiskalni stampac FP 550 koristim gotov program Metalink a iz PHP generisem tekstualni fajl u folder koji zahteva Metalink .To moze da se resi i na drugi nacin ali tema zakona ,fiskalnog stampaca ,atestiranog softvera i dalje nije do kraja definisana .

@galenit: je'l moguce vidjeti negdje demo te aplikacije ili makar screenshot-ove da okacis?

---

Mikail, da si citao temu video bi da se to sve moze sa MS proizvodima uraditi besplatno, osim samog windows-a.

---

Znaci realno ti nemas konkretnu informaciju da je fikalni racun zaista odstampan ili jos vaznije poslat poreskoj, a vec si "proknjizio" transakciju, a to znaci da je realna situacija da kes u kasi bude veci od onog koji FP550 posalje poreskoj sluzbi kroz "etar". Finansijska obozava takve situacije. Brinete se da klijenta ne osteite za licencu XPa al vam izgleda potencijalne kazne nisu skupe

Ja i dalje ne vidim konkretno resenje ovog problema sa svim tim predlozenim sistemima baziranim na html-u i client side skriptama, jednostavno vam je sandboxing browsera velika prepreka. Osim mozda instalacije trusted koda na krajnjim masinama, u kom slucaju se gubi cela ta prica sa mekanim deploymentom.

---

Nisam bas razumeo ovu recenicu citat Brinete se da klijenta ne osteite za licencu XPa al vam izgleda potencijalne kazne nisu skupe
Kada sam napomenuo atest za softver to se odnosi na knjigovodstvene programe a ne za operativni sistem .Jedna od prednosti pisanja programa u ovom okruzenju je nezavisnost od operativnog sistema ali postoji mnogo vise razloga da se opredeli za ovu vrstu knjigovodstvenih programa i prema tome pripada im buducnost .Konkretan nedostatak u delu programa nije vezan za pogodnost pisanja programa u ovom okruzenju vec se to resava individualno a posto vidite problem lako je naci resenje .

Citat je vrlo jednostavan, od pocetka ove teme slusam price kako je LAMP majka mara svih mogucih aplikacija i sistema i besplatno resenje svih zivotnih problema od spremanja zdravog dorucka do implementacije ERP-a za konglomerate i kako smo svi mi koji se drzimo Windoza ustvari zamracene svesti jer ne vidimo svetlo koje je LAMP. Cinjenice su medjutim daleko od toga, a kontrola fiskalnog printera je samo jedan od tih problema.

Sve web aplikacije (ukljucujuci tu i LAMP a i ASP.NET) imaju dva velika problema, izvrsavaju se u sandox rezimu browsera i na serveru rade u per-request rezimu. Ta dva problema predstavljaju ozbiljnu smetnju za kontrolu externih hardverskih resursa, ukljucujuci fiskalni printer. Ti fiskalni printeri imaju za sebe zakacen GPRS emiter koji salje sve fiskalne transakcije poreskoj, i kad ti predas raw file u Metalink ti mozes samo da pretpostavis da ce taj racun biti odstampan/poslat i da se nadas najboljem i da transakciju "proknjizis" u svom sistemu. A znas sta se kaze za pretpostavke . Ako se racun kojim slucajem ne odstampa iz bilo kog razloga imaces situaciju da se transakciono stanje u tvom programu ne slaze sa stanjem koje ima poresko i ne treba ti inspektor sa PhD iz ekonomije da to iskopa i kazni tvoju musteriju. Mozda ja jesam perfekcionista, ali za mene je to veliki showstopper.

Pogledaj malo i temu Koji je programski jezik pogodan za pisanje programa za racunovodstvo - ekonomski aspekt, za detalje oko "skupoce" i videces da tvog klijenta (preko cene tvog programa) u osnovnoj SoHo varijanti windows based solucija kosta jednokratno oko $100 po masini, sto je definitivno u plateznoj moci i najmanjih preduzeca, i sasvim sigurno kosta manje od kazne poreske inspekcije za neispravne fiskalne transakcije.

---

Ne znam da li Metalink vraca neku povratnu informaciju, u vidu output.txt sa porukom/statusom da li je proknjizio transakciju. Ako vraca informaciju, onda nije nikakav problem procitati je - sa servera.

Nije problem ni stampati na matricnom stampacu, ako je stampac u mrezi deljen,



Web interfejs nije zgodan za POS terminale gde se unosi veliki broj transakcija/vrem.jed - super/mega marketi, salteri, za sve ostalo funkcionise sasvim ok.

Nisam baš upućen u problematiku i ne znam šta je metalink, ali zašto je problem da se na svakoj mašini na kojoj postoji fiskalni štampač instalira i mali server za komunikaciju sa istim, sinhrono, pošalješ zahtev i on ti odmah vrati info šta je bilo sa tim računom? Mislim, znam da se time delimično potire suština veb platforme kao izbora, ali opet fiskalni štampač (a sa njim i taj server koji bi mogao da se nazove i drajverom) nije nešto što zahteva stalne apdejtove. Plus što i on može biti crossplatform.

Nemoj da se nerviras. Meni je bas zabavno da gledam kako ljudi koji ocigledno i ne znaju kakvi su zahtevi pred knjigovodstvenom aplikacijom, imaju "idealna" resenja i predlazu platforme kje nemaju veze sa vezom. Ostalo je jos samo da neko predlozi kao idelno resenje aplikaciju pisanu u BAT ili sh skriptama i celina je zaokruzena :)

---

Nisu zahtevi za racunovodstvene programe samo fiskalni stampac da bi mu se toliko ovde poklanjalo paznje .A ova platforma ispunjava zahteve sa terena koje daju knjigovodje i te zahteve slusam od perioda dBase II i nista se znacajno nije promenilo osim sto se malo slabije placa .Ako ovi programi ne zadovolje neku trafiku gde je po cenu zivota bitno da se izda fiskalni to ce vervatno neko resiti u narednom uredjaju gde ce imati kucica da sedi ispektor i pazi ko je u trafici izdao fiskalni odsecak .Ali i dalje ovde nisam dobio odgovor za koji se programski jezik opredeliti za racunovodstvene programe a da nisu DOS programi samo ofarbani i maske generisane vec da donosi nesto novo u celoj koncepciji koja se za zadnjih 20 godina nije promenila

Problem je u sinhronosti operacije, ovo bi mozda i funkcionisalo u statefull sistemu, ali web to nije. Operacija je u potpunosti asinhrona i ne garantuje procesiranje zahteva za stampom i dobijanje feedback-a u vremenskom periodu alociranom za per-request PHP (ili asp.net) strane, niti postoji pouzdani mehanizam da se operacija stornira. To nije novina, ti timing problemi sa swivel-chair integracijom komponenti sistema postoje jos odavno, real-time distribuirani sistemi i distribuirane transakcije su i osmisljene da bi se prevazisao taj problem. A LAMP to nema.

Metalnik mu dodje neka vrsta interfejsa, bar koliko sam ja to prokapirao, generalno asinhroni system koji prebacuje informacije iz jednog izvora u drugi koristeci metalink xml format da definise izvor, destinaciju i operaciju. Moda negde i gresim, ali generalno mislim da je to to.
A sto se tice tvoje primedbe, generalno da, ali kako? Sad vec pricamo o binarnim programima i nocnoj mori sa komaptibilnoscu distro-a i integraciji sa browserima i pluginima na tim razlicitim platformama. To nije nista manje kompleksno niti jeftinije od recimo pokusaja da se ActiveX podigne na linux-u kroz Wine ili crossover . A ako se fokusiras na samo jedan distro i jedan browser, onda dalje gubis tu sustinu web platforme.

Ma ne nerviram se uopste, samo sam malo cinican Malo me samo generalno iritira sto svi zaboravljaju kakvi su sve problemi bili prosli put dok je trajala groznica intranet-a i kad su svi obecavali da je web buducnost i da cemo cak jednog dana svi imati jeftine thin masine i da cemo sve raditi na webu da bi posle tone problema taj koncept odumro i rich statefull koncept prevagnuo a mi svi sad imamo thick masine sa zverskim procesorima i brdom memorije zbog drasticnog pada cene hardvera. Sad x godina kasnije ponovo se cuju iste price, a ne cuju se resenja tih starih problema, kao da ih nikad nije ni bilo i kao da je prvi pokusaj propao zato sto zvezde na nebu nisu bile postavljene kako treba. A sa druge strane proizvodjaci browsera najavljuju jos grdji sandboxing browsera iz siguronosnih razloga. Nekako mi ta matematika uopste ne stima.

Naravno da ispunjava, racunovodstveni programi nisu rocket science, ali ako cemo tom logikom i dBASEII (ajd da budemo noviji pa da kazemo dBASEIV) jos uvek ispunjava sve te zahteve sa terena, pa sto si onda presao na LAMP? Sasvim sam zapravo siguran da taj dBASE jos uvek predstavlja bolje resenje tog problema nego LAMP.
A to da imas prodate funkcionalne verzije u LAMPu ti naravno verujem, i siguran sam da su svi tvoji klijenti presli na LAMP, ali to nema nikakve veze sa tehnoloskim prednostima i manama istog o kojima ovde pricamo, vec sa cinjenicom da ti kontrolises format baze koja je kod njih instalirana i da tretiras taj format kao proprietary i da time njima uskracujes mogucnost da predju kod drugog proizvodjaca zbog teskoca u konvertovanju baze. Efektivno ti koristis FUD taktiku da "prisilis" svoje klijente da predju na onu platformu koja TEBI odgovora umesto na onu koja bi njima mozda bolje odradjivala posao.

---

Šta znam, ja sam imao drugačiju ideju - da se tom drajveru pristupa ne iz brauzera, nego iz serverske aplikacije (mislim, koliko to ima fiskalnih štampača u organizaciji? Nema valjda svaka klijentska mašina nakačen fiskalni štampač?!) A sa druge strane, ako to rešenje iz nekog razloga ne pije vodu, u drajver se ugradi HTTP serverčić i request/response se obavlja jednostavnim AJAX zahtevom iz brauzera, bez potrebe za Activexom ili čime već. Mislim, sad stvarno ima dosta različitih načina da se obavi ta famozna fiskalna štampa.

A za portabilnost ima takođe više načina, jedan od njih je svakako Java, a što da ne i neki skript jezici tipa perl, python...

Naravno da podrska fiskalnom stampacu nije jeidni zahtev, ima ih jos gomila koji stavljaju na muke i mnogo ozbiljnije igrace, a krpez-resenja kakva se ovde nude ozbiljan projektant i ne uzima u obzir, osim u sali.



Ozbiljno me interesuje kako neko ko se bavi razvojem knjigovodstvenih programa jos iz vremena dBaseII moze da uopste razmislja o krpezu kao zameni za dBase. Pa i dan danas dBase ce da resi svaki zahtev u knjigovodstvenoj apliakciji bolje od LAMP, jedino to ce ruznije da izgleda.



Zaista cudan nacin razmisljanja. :)



Odgovor necesni dobiti jer ima vise platformi koje rade posao kako treba, pa je to sve stvar afiniteta. Stavise, sa razvojem komunikacione infrastrukture sve su cesci zahtevi koje je zaista lakse resiti nekom LAMP platformom, tako da je pravi odgovor u stvari u vise platformi - za jedan deo posla treba razvijati klasicne dekstop aplakacije koje su cvrste, brze i efikasne, a druge delove raditi u nekoj web platformi. To niej stvar izbora vec je postalo uslov: kao sto nikada neces napraviti web apliakciju za unos ogromen kolicine podataka (fakture i slicno), tako nikada neces napraviti ni prakticnu dektop aplikaciju koja treba da radi online, recimo pregled izvestaja i pracenje stanja u knjigovodstvu sa udaljene lokacije, cesto mobilno.

U sustini zahtevi pred knjigovodstvenom apliakcijom se lokacijski mogu svrstati u cetiri grupe:

- rad na jednom racunaru

- radi u LAN-u

- rad na udaljenim mestima gde je neophodna ista funkcionalnost kao i u lokalu ali je komunikacija ogranicena na link ogranicene brzine (iznajmljena linija, VPN preko Interneta i slicno), kao sto su razne poslovnice, ispostave, prodavnice, skladista)

- rad u mobilu, bez zahteva za poptunu funkcionalnost kao u lokalu, vec su uglavnom potrebni izvestaji i povremeni unos manje kolicine podataka, po pravilu na nekom mobilnom uredjaju: laptopu, PDA, ili cak mobinom telefonu.

Svaka od ovih grupa zahteva drugaciji pristup.

Radi pojednostavljenja, obicno se prva, druga i treca objedine pod zajednickim imeniteljem: radom mrezi, gde se aplikacija razvija za prilike ogranicene brzine komunikacije a kada se radi u lokalu, to se samo oseti u brzini protoka podataka. To se najcesce pokaze kao los potez.
Udaljeni rad sam po sebi zahteva kompromise u korisnickom interfejsu, koji nisu potrebni kada se radi u lokalu, a aplikacija koja se razvija za udaljeni rad, obicno u lokalu deluje osakaceno. Ukratko: samim tim sto je ogranicena brzin pristupa podacima, interfejs mora to da ima u vidu i da do podatak dolazi na nacin koji je prihvatljiv i sa stanovista brzine i stanovista upotrebljivosti interfejsa. S druge strane, za rad na jednom racunaru tesko da nekome mozes da prodas potrebu za Oracle serverom na primer...

Na izbor platforme utice i ciljna grupa korisnika programa. Sasvim je jasno da program koji treba da radi u trafici, ne moze da radi posao i firmi koja ima 10.000 zaposlenih, i 100 udaljenih lokacija u kojima knjigovodstvo treba da bude funkcionalno isto kao i u centrali, ali i da je program koji radi posao nekoj velikoj firmi jednostavno preglomazan za trafiku. a opet, cesto, velika firma ima neki zahtev koji se svodi na trafiku.

Bitno je voditi racuna i o medjusobnoj kompatibilnosti platformi koje se koriste. Pre svega je bitna kompatibilnost na nivou podataka ali je dobro ostvariti i aplikativnu kompatibilnost u smislu da ako se radi neka obrada podataka a ta obrada je porebna na obe platforme, valjalo bi da isti kod uvek radi taj posao. Mnogo je nezgodno odrzavati program u kome na dva mesta, dve razlicite procedure rade isti posao.



Kao idealnu platformu za razvoj zamisljam nesto sto se sastoji iz tri platforme:

- jedna, koja veoma lici na mesavinu FoxPro-a i Delphi-ja, sluzila bi za razvoj desktop verzije. Njene karakteristike su: odlicne mogucnosti razvoja korisnickog interfejsa, brz i efikasan pristup bazama, podrska za SQL servere, mogucnost rada sa tabelama u lokalnom sistemu datoteka, ravijen programski jezik, lak za ucenje, kao i otvorenost za prosirenje kako razvojem biblioteka u okviru tog jezika, tako i koriscenjem eksternih biblioteka. Apliakcija bi trebalo da bude viseslojna i modularna.

- druga, SQL server dobrih karakteristika, sa naprednom podrskom za serverske procedure, jednostavan za odrzavanje

- treca, web platforma, nista bolja nego sto je recimo PHP u kombinaciji sa Apache-om


Ne bih uslovljavao da sve tri platforme moraju da rade na istom OS, ali ni da jedna platforma moze da se korsiti na vise OS. To, da jedna alikacija radi na vise OS uvek predstavlja debelo ogranicenje koje za racunvodstvenu apliakciju nije prihvatljivo. Prioritet aplikacije je da se posao obavlja brzo, kvalitetno i sigurno i tome mora biti sve podredjeno.

---

Ili još banalnije, kada se neki posebno formatizovan sadržaj pojavi u prethodno dogovorenom folderu, on izvrši operaciju nad sadržajem, recimo - pošalje na štampu :)

onlile: "Ne znam da li Metalink vraca neku povratnu informaciju"
http://metadata.co.yu/se/fiskal/metalink.htm
"Kao rezultat, program vraca fajl sa odgovorom na postavljeni zahtev."