Forum » Programiranje » [ Razvoj ] Opensource knjigovodstvo
[ Razvoj ] Opensource knjigovodstvo
Temo vidijo: vsi
BigWhale ::
Z Juretom sva ze nekaj casa nazaj zacela razmisljati o tem, naredila nisva se nic pametnega. Jaz sem ze naredil nekaj stvari na to temo in bi stvar nadgradil.
Nekako takole sem si zamislil stvari:
Prva faza: Izbira ustreznih tehnologij za razvoj. Od programskega jezika, knjiznjic, protokolov, ... In nek grob oris projekt, kaj bi se delalo in kako.
Druga faza: Podroben nacrt dela, definiral bi se 'scope' projekta, bolj natancno bi se povedalo kaj bi se delalo in kako, ter kdo bi to delal.
Tretja faza: Delo. ;)
Tako, precej na grobo in precej na hitro. Jaz bi se v tem momentu odlocil za ene vrste baby steps pristop k vsemu skupaj.
Najprej bi bil cilj narediti aplikacijo za blagovno poslovanje, torej vodenje skladisca, ter izdajo 'vseh' papirjev (dobavnica, racun, predracun, narocilnica, izdaja in prevzem iz skladisca).
Ce je interes, bi naredil nek priblizen 'document-flow' diagram s katerega bi bilo razvidno kako se ti dokumenti med seboj povezujejo in navezujejo ter prvo specifikacijo dokumentov bi naredil, kaj vse mora biti na posameznem dokumentu. Potem bi pocakal na input vseh ostalih, da poveste kaj manjka, kaj je prevec, kaj je narobe in ce je kje kaj, ki se ne sklada s poslovanjem in tako naprej.
Na podlagi tega bi naredili database model. Ko bi bil DB model narejen, pa se lahko zacne resno kodiranje. Server backend/application server, recimo. Vmes bi se pa dogovorili se ostali milijon podrobnosti o sami aplikaciji, APIjih, nacinu dela in tako naprej.
Takole optimisticno receno, bi tako stvar lahko koncali do konca leta, skupaj s testiranjem in z vsaj enim ali dvema testnima uporabnikoma.
Potem bi se pa pocasi spuscali vse globje v knjigovodske/racunovodske vode.... Naslednja stvar, ki jo vidim je applikacija za izracun plac...
Komentarji? Kdo je zraven?
PS: Moderatorje bi prosil za striktno moderiranje, da bo cim manj off-topic zadev... :)
Nekako takole sem si zamislil stvari:
Prva faza: Izbira ustreznih tehnologij za razvoj. Od programskega jezika, knjiznjic, protokolov, ... In nek grob oris projekt, kaj bi se delalo in kako.
Druga faza: Podroben nacrt dela, definiral bi se 'scope' projekta, bolj natancno bi se povedalo kaj bi se delalo in kako, ter kdo bi to delal.
Tretja faza: Delo. ;)
Tako, precej na grobo in precej na hitro. Jaz bi se v tem momentu odlocil za ene vrste baby steps pristop k vsemu skupaj.
Najprej bi bil cilj narediti aplikacijo za blagovno poslovanje, torej vodenje skladisca, ter izdajo 'vseh' papirjev (dobavnica, racun, predracun, narocilnica, izdaja in prevzem iz skladisca).
Ce je interes, bi naredil nek priblizen 'document-flow' diagram s katerega bi bilo razvidno kako se ti dokumenti med seboj povezujejo in navezujejo ter prvo specifikacijo dokumentov bi naredil, kaj vse mora biti na posameznem dokumentu. Potem bi pocakal na input vseh ostalih, da poveste kaj manjka, kaj je prevec, kaj je narobe in ce je kje kaj, ki se ne sklada s poslovanjem in tako naprej.
Na podlagi tega bi naredili database model. Ko bi bil DB model narejen, pa se lahko zacne resno kodiranje. Server backend/application server, recimo. Vmes bi se pa dogovorili se ostali milijon podrobnosti o sami aplikaciji, APIjih, nacinu dela in tako naprej.
Takole optimisticno receno, bi tako stvar lahko koncali do konca leta, skupaj s testiranjem in z vsaj enim ali dvema testnima uporabnikoma.
Potem bi se pa pocasi spuscali vse globje v knjigovodske/racunovodske vode.... Naslednja stvar, ki jo vidim je applikacija za izracun plac...
Komentarji? Kdo je zraven?
PS: Moderatorje bi prosil za striktno moderiranje, da bo cim manj off-topic zadev... :)
BigWhale ::
Pa ze kar takoj moj prvi predlog in nekaj idej...
Licenca: striktno GPL, z moznostjo, da se kak del programa naredi z LGPL licenco. Ali pa nekaj kar je s tem kompatibilno.
Programski jezik: C++, vecina 'thick' klienta narejenega v Qt. Dopuscam moznost kaksnega visje nivojskega jezika, ala phyton za kako interno 'skripting' podporo. Ali pa kaksno 'server side' resitev, ki bi bistveno prispevala k funkcionalnosti sistema. :)
Database backend: Postgresql, ob vsaki omembi stored procedur in ostalih 'server side' SQL zadev bom vztrajno mahal z veliko rdeco zastavo in se bom zelo tezko pustil prepricat v smiselnost takih resitev. Bodo morali biti argumenti RES dobri. Stored procedure ne slovijo ravno po zelo veliki prenosljivosti... :)
Ostale zadeve: Morda bi bilo pametno razmisliti o application serverju in nekem lastnem protokolu s katerim bi se pogovarjala appserver in klient. Tako mogoce pridobimo en nivo abstrakcije pri izdelavi razlicnih klientov. Thin, thick, mobile/offline... (ja, ja, saj vem buzzwordi...) Hkrati pa pridobimo en nivo vec, ki ga je potrebno testirati in en nivo vec kjer se najdejo bugi... ;)
Licenca: striktno GPL, z moznostjo, da se kak del programa naredi z LGPL licenco. Ali pa nekaj kar je s tem kompatibilno.
Programski jezik: C++, vecina 'thick' klienta narejenega v Qt. Dopuscam moznost kaksnega visje nivojskega jezika, ala phyton za kako interno 'skripting' podporo. Ali pa kaksno 'server side' resitev, ki bi bistveno prispevala k funkcionalnosti sistema. :)
Database backend: Postgresql, ob vsaki omembi stored procedur in ostalih 'server side' SQL zadev bom vztrajno mahal z veliko rdeco zastavo in se bom zelo tezko pustil prepricat v smiselnost takih resitev. Bodo morali biti argumenti RES dobri. Stored procedure ne slovijo ravno po zelo veliki prenosljivosti... :)
Ostale zadeve: Morda bi bilo pametno razmisliti o application serverju in nekem lastnem protokolu s katerim bi se pogovarjala appserver in klient. Tako mogoce pridobimo en nivo abstrakcije pri izdelavi razlicnih klientov. Thin, thick, mobile/offline... (ja, ja, saj vem buzzwordi...) Hkrati pa pridobimo en nivo vec, ki ga je potrebno testirati in en nivo vec kjer se najdejo bugi... ;)
OwcA ::
Kar se tiče programskega jezika, sam navijam (in bi v primeru izbire tudi pomagal) za Python.
Čemu ne bi tekla aplikacija kar v brskalniku? To je precej bolj prenosljivo in lažje za podpirat.
Čemu ne bi tekla aplikacija kar v brskalniku? To je precej bolj prenosljivo in lažje za podpirat.
Otroška radovednost - gonilo napredka.
Tody ::
Ja v vsej tej vnemi je nujno da bo zadeva user frendly ker to ne delamo za nas informatike ampak za tajnice in podobno ljudstvo ki ima al pa nima izkušenj oz volje do nekih velkih klikov.
Drugače se bom oglasil potem ko pride kako modelirnje na vrsto
Drugače se bom oglasil potem ko pride kako modelirnje na vrsto
BigWhale ::
Klient v brskalniku, se pravi 'thin client', ce se gremo buzzworde, je precej omejen kar se uporabniskega vmesnika tice in se kaj hitro lahko zgodi, da je vec problemov pri prenosljivosti kot s Qt aplikacijo... ;)
jype ::
Sam sem ze napisal zmogljiv in robusten aplikacijski streznik v Pythonu (deluje tudi nad Apache streznikom), ki zdrzi priblizno 200 (pure python) oz. 1200 (mod_python) zahtevkov na sekundo (skupaj z branjem iz baze, ACLji in vsem ostalim) na dual opteron masini, kar je danes en normalen streznik. Zmogljivost vsekakor doseze vsaj srednje velika podjetja.
Zdaj dokoncujem knjiznico s Qt odjemalcem za ta aplikacijski streznik (in se nekatere druge, recimo za marelo, ki jo je markos predstavil na spletnih uricah).
Tudi Javascript odjemalec je ze napisan (malo ga je treba prilagoditi).
Skratka, na voljo so platforme Qt/PyQt, XUL in ce je kdo dovolj ubrisan je odjemalec lahko tudi ajax based. Qt 4 ima odlicen PDF rendering engine in je nadvse primeren za izdajanje dokumentov na ven.
Sam se javim, da pripravim orodja in dokumentacijo vsakemu, ki bo pripravljen delat odjemalca. Poskrbeti sem pripravljen tudi za varnost (vgrajeno v sam aplikacijski streznik).
A kdo priporoca kaj drugega kot ElementTree za parsanje XML v pythonu (predvsem je pripraven parser, ki na dokumentu omogoca dostop do nodov z XPath)?
Aja, ce Microsoft veseli, mu seveda komot napisem C# odjemalca za aplikacijski streznik, potem pa on naprej razvija UI.
Seveda bi bilo nujno dolociti smernice razvoja UIja. Tako da ce se znajdes pred drugim programom, je zadeva se vedno intuitivna.
Zdaj dokoncujem knjiznico s Qt odjemalcem za ta aplikacijski streznik (in se nekatere druge, recimo za marelo, ki jo je markos predstavil na spletnih uricah).
Tudi Javascript odjemalec je ze napisan (malo ga je treba prilagoditi).
Skratka, na voljo so platforme Qt/PyQt, XUL in ce je kdo dovolj ubrisan je odjemalec lahko tudi ajax based. Qt 4 ima odlicen PDF rendering engine in je nadvse primeren za izdajanje dokumentov na ven.
Sam se javim, da pripravim orodja in dokumentacijo vsakemu, ki bo pripravljen delat odjemalca. Poskrbeti sem pripravljen tudi za varnost (vgrajeno v sam aplikacijski streznik).
A kdo priporoca kaj drugega kot ElementTree za parsanje XML v pythonu (predvsem je pripraven parser, ki na dokumentu omogoca dostop do nodov z XPath)?
Aja, ce Microsoft veseli, mu seveda komot napisem C# odjemalca za aplikacijski streznik, potem pa on naprej razvija UI.
Seveda bi bilo nujno dolociti smernice razvoja UIja. Tako da ce se znajdes pred drugim programom, je zadeva se vedno intuitivna.
Zgodovina sprememb…
- spremenilo: jype ()
jype ::
Tody> Ja v vsej tej vnemi je nujno da bo zadeva user frendly ker to ne delamo za nas informatike ampak za tajnice in podobno ljudstvo ki ima al pa nima izkušenj oz volje do nekih velkih klikov.
Jaz mislim, da bo Brane2 zelo vesel, ce bo zadeva tudi IT expert friendly.
Kaksen bo UI je pa itak odvisno od tistih od racunovodskega foha, ki bodo program testirali.
Jaz mislim, da bo Brane2 zelo vesel, ce bo zadeva tudi IT expert friendly.
Kaksen bo UI je pa itak odvisno od tistih od racunovodskega foha, ki bodo program testirali.
Brane2 ::
Vsi tii priogrami so si po strukturi menijev itd precej podobni.
No, vsaj meni se PCA ne zdi nič kaj posebnega.
Kar se tistih 500 strank kot minimuma tiče, je to že mogoče res, ni pa nujno da bi se OS projekt moral kaj dosti ozirati na to.
Poleg tega bi lahko naredili možnost prenosa podatkov PCA- X in tako pobrali del obstoječih strank PCA.
Slednji hrani podatke v Btrieve bazi, vendar jih lahko z nekaj nepomembnimi izjemami izvaža in uvaža iz CSVja...
No, vsaj meni se PCA ne zdi nič kaj posebnega.
Kar se tistih 500 strank kot minimuma tiče, je to že mogoče res, ni pa nujno da bi se OS projekt moral kaj dosti ozirati na to.
Poleg tega bi lahko naredili možnost prenosa podatkov PCA- X in tako pobrali del obstoječih strank PCA.
Slednji hrani podatke v Btrieve bazi, vendar jih lahko z nekaj nepomembnimi izjemami izvaža in uvaža iz CSVja...
On the journey of life, I chose the psycho path.
Brane2 ::
Me zanima predvsem programska koncepcija in načrt Konta.
Konto ni v osnovi nič drugega, kot par floatov in atribut.
Je zelo podoben npr. stanju na bančnem računu, vendar ga opisujeta dve številki.
Kadarkoli daš kaj "nanj", se poveča ena. Ko kaj dol vzameš, se poveča druga. Razlika obeh števil govori o trenutnem stanju konta.
ID konta je INT32. Potrebuješ še float za začetno stanje konta in pa en enum za naravo konta ( "denarna sredstva na računih", "oprema", "blago na skladišču" itd), način dovoljenega knjiženja ( v "breme/dobro" ali oboje) in string za verbalno razlago konta.
Verjetno sem še kako malenkost pozabil, a to je v osnovi to.
On the journey of life, I chose the psycho path.
Brane2 ::
Še to: V bistvu naj bi se denarne operacije na kontih izvrševale z BCD aritmetiko in ne s floati zaradi možnosti napak pri zaokroževanju, vendar ne vem, kdo danes to še počne, zato ne bi kompliciral, bi pa razmislil, kako bi to implementiral.
Mogoče bi upoarabil int64 za stotine in pa še kak int16 za dele stotinov ? Slednjega ne bi shranil nikamor, le uporabil bi ga pri izračunavanjih in v skladu z jim zaokrožil tavelik int, preden bi znesek spravil kam... Ali pa, tudi če bi ga. Recimo kak int128, ki še gre v SSE register, kjer bi bilo spodnjih 32 bitov za del stotina/centa/etc)
VSe računovodske operacije so itak čisto seštevanje in odštevanje, zato pri uporabi INTov ne bi prišlo do akumulacije napak, obenem bi pa obdržal alicelo povečal natančnost pri pretvorbami med valutami...
Bi blo treba slišat, kaj pravijo računovodski standardi o tem...
Mogoče bi upoarabil int64 za stotine in pa še kak int16 za dele stotinov ? Slednjega ne bi shranil nikamor, le uporabil bi ga pri izračunavanjih in v skladu z jim zaokrožil tavelik int, preden bi znesek spravil kam... Ali pa, tudi če bi ga. Recimo kak int128, ki še gre v SSE register, kjer bi bilo spodnjih 32 bitov za del stotina/centa/etc)
VSe računovodske operacije so itak čisto seštevanje in odštevanje, zato pri uporabi INTov ne bi prišlo do akumulacije napak, obenem bi pa obdržal alicelo povečal natančnost pri pretvorbami med valutami...
Bi blo treba slišat, kaj pravijo računovodski standardi o tem...
On the journey of life, I chose the psycho path.
Brane2 ::
Najprej bi bil cilj narediti aplikacijo za blagovno poslovanje, torej vodenje skladisca, ter izdajo 'vseh' papirjev (dobavnica, racun, predracun, narocilnica, izdaja in prevzem iz skladisca).
IMHO bi moral najprej doreči strukturo konta in operacije nad njim. Nato lahko narediš kontni plan in videiš, če stvari klapajo.
Nato lahko odpreš vrata v dodatne baze (baza kupcev/baza zaposlenih), baza izdelkov/storitev itd), ne da bi jih še kaj posebej definiral.
Nato rabiš mehanizem za prikaz željenih podatkov skozi maske na zaslon, za vnos podatkov skozi maske v te baze in mehanizem za definicijo mask.
Ko enkrat to imaš, lahko večino dolgočasnega dela počnejo drugi- definirajo maske. Ti pa se ta čas ukvarjaš z mehanizmi, ki stojijo za maskami.
On the journey of life, I chose the psycho path.
Ziga Dolhar ::
Brane2: Zrisat konto v real lajfu znam tut jest ;-). Tisto, kar me RES mika, je pa ustrezna zasnova v obliki objekta/razreda.
Še posebej zato, ker je "konto" kot zelo abstrakten "račun" lahko izredno zmogljiva osnova za ostale, naprednejše oblike, kot so npr. "bilance", ali preprostejše, npr. "knjižbe" [oz. zbir knjižb - "dogodek"].
Moč, ki nam jo da pravilna zasnova "konta", je ogromna tudi na področju avtomatizacije pogostih opravil. Poleg "knjiženja" sem štejem še delni (ne popolni!) storno; izdelavo poročil, ki je mogoča le z napredno vdelavo kontnega plana; samodejno ugotavljanje finančnih stanj (npr. kapitalske neustreznosti) in sledenje proizvodnji ...
--
[Čemu ta moj Kult Konta? Ker sem v srednji šoli ob drkanju kontov prebil ca. 525 tednov (če kot šolsko leto štejem 35 tednov - glede te številke nisem prepričan) in bil nad njim fasciniran. Ne vem pa, kako bi to zgledalo danes, saj so jim -- po predmetniku sodeč -- fond računovodskih ur zmanjšal na nekje 2/3 naše generacije.]
-- dodatek: tudi "nabava", "stranke", "izdaja računov" in podobnega je nato zgolj verzija dogodka [extendz konto] in kot tak primarno vmesnik za delo z glavno knjigo.
Še posebej zato, ker je "konto" kot zelo abstrakten "račun" lahko izredno zmogljiva osnova za ostale, naprednejše oblike, kot so npr. "bilance", ali preprostejše, npr. "knjižbe" [oz. zbir knjižb - "dogodek"].
Moč, ki nam jo da pravilna zasnova "konta", je ogromna tudi na področju avtomatizacije pogostih opravil. Poleg "knjiženja" sem štejem še delni (ne popolni!) storno; izdelavo poročil, ki je mogoča le z napredno vdelavo kontnega plana; samodejno ugotavljanje finančnih stanj (npr. kapitalske neustreznosti) in sledenje proizvodnji ...
--
[Čemu ta moj Kult Konta? Ker sem v srednji šoli ob drkanju kontov prebil ca. 525 tednov (če kot šolsko leto štejem 35 tednov - glede te številke nisem prepričan) in bil nad njim fasciniran. Ne vem pa, kako bi to zgledalo danes, saj so jim -- po predmetniku sodeč -- fond računovodskih ur zmanjšal na nekje 2/3 naše generacije.]
-- dodatek: tudi "nabava", "stranke", "izdaja računov" in podobnega je nato zgolj verzija dogodka [extendz konto] in kot tak primarno vmesnik za delo z glavno knjigo.
https://dolhar.si/
Zgodovina sprememb…
- spremenil: Ziga Dolhar ()
Ziga Dolhar ::
> IMHO bi moral najprej doreči strukturo konta in operacije nad njim. Nato lahko narediš kontni plan in videiš, če stvari klapajo.
No ja -- vidim, da se tle strinjava :).
No ja -- vidim, da se tle strinjava :).
https://dolhar.si/
IgorGrozni ::
hm, ...jaz sem Uporabnik:
1. Že če želite doseči tudi samo sub 500 uporabnikov, uporabnikov, ki ne bodo pripadali natančno vaši skupini, morate, morate zagotoviti podporo !
Ne samo, da boste že po naravi stvari delali, testirali .. in puščali napake, najmanj kar boste, če ne drugega, se boste v zapletali v izrazih in ročnosti ˝orodij˝, a tudi zakonodaja in standardi se bodo spreminjali - poudarjam znano in očitno, a vendar.
Skoraj si ne morem misliti, da bi lahko vi ˝simulirali˝ delovanje možganov in rok povprečnega knjigovodje.
( mimogrede, knjigovodstvo je beleženje preteklih dogodkov (dokumentiranih), računovodstvo pa je analiza in napoved bodočih dogodkov, kar pa seveda ne gre brez knjigovodskih podatkov )-tako teorija.
Zato morate, morate zagotoviti kvalitetno podporo, ki pa mora biti, da bi bila kvalitetna, hkrati tudi takojšnja. Instantna.Do zapletov in vprašanj pride največkrat v gužvi, pred oddajo napovedi, ker tudi servisi vse delajo zadnji trenutek. In takrat ostati brez delujočega programa....
2. Ne morem si predstavljati, da bi vi sami postali ˝podporniki˝, ne da bi se prej zdolgočasili do smrti, bili zaradi tega sitni, nerazumljivi in neprijazni. Kar pa je smrt za vsak posel.
Zato potrebujete poleg dela, ki ga boste izvedli nedvomno odlično
, še nekoga, ki bo stvar vzdrževal. Ki ima že sedaj nekaj srednjega IT kadra, kadra, ki bo zmogel vedro in prijazno izvajati podporo samo temu programu, magar do smrti.
Uporabite jype ( zgolj predlog) recimo, ali kogarkoli podobnega, ki bo to organiziral in vzdrževal.
Da bi kdo izven IT expertov tipa Brane2, kupil in uporabljal tak program (brez da bi bil zelo obupan ali pa neodgovoren), brez zagotovljene podpore ni za misliti. Zagotovljena podpora, ki bo imela poleg moralnih zagotovil, kar največ tudi ˝substancionalnih˝ zagotovil. Ker besede prepričajo le naivne. Naivni pa ne preživijo. In če ne preživijo, ne preživi tudi vaše delo. Ali pa ne plačajo. Ali...
Iniciacija ideje je prišla od Braneta2, ki je zaradi naporne migracije, raje kupil še enkrat ˝nadgrajeni crap˝, ˝drek na kvadrat˝.
Pa je to Brane2, kaj bi prisilna migracija( pri kvalitetno nepodprtem programju) pomenila za vaše ˝stranke˝. Propade servisov, odpuščanje, ipd...
Samo moj komentar za premislek. Ne polemiko.
Veliko sreče, IgorGrozni
1. Že če želite doseči tudi samo sub 500 uporabnikov, uporabnikov, ki ne bodo pripadali natančno vaši skupini, morate, morate zagotoviti podporo !
Ne samo, da boste že po naravi stvari delali, testirali .. in puščali napake, najmanj kar boste, če ne drugega, se boste v zapletali v izrazih in ročnosti ˝orodij˝, a tudi zakonodaja in standardi se bodo spreminjali - poudarjam znano in očitno, a vendar.
Skoraj si ne morem misliti, da bi lahko vi ˝simulirali˝ delovanje možganov in rok povprečnega knjigovodje.
( mimogrede, knjigovodstvo je beleženje preteklih dogodkov (dokumentiranih), računovodstvo pa je analiza in napoved bodočih dogodkov, kar pa seveda ne gre brez knjigovodskih podatkov )-tako teorija.
Zato morate, morate zagotoviti kvalitetno podporo, ki pa mora biti, da bi bila kvalitetna, hkrati tudi takojšnja. Instantna.Do zapletov in vprašanj pride največkrat v gužvi, pred oddajo napovedi, ker tudi servisi vse delajo zadnji trenutek. In takrat ostati brez delujočega programa....
2. Ne morem si predstavljati, da bi vi sami postali ˝podporniki˝, ne da bi se prej zdolgočasili do smrti, bili zaradi tega sitni, nerazumljivi in neprijazni. Kar pa je smrt za vsak posel.
Zato potrebujete poleg dela, ki ga boste izvedli nedvomno odlično
, še nekoga, ki bo stvar vzdrževal. Ki ima že sedaj nekaj srednjega IT kadra, kadra, ki bo zmogel vedro in prijazno izvajati podporo samo temu programu, magar do smrti.Uporabite jype ( zgolj predlog) recimo, ali kogarkoli podobnega, ki bo to organiziral in vzdrževal.
Da bi kdo izven IT expertov tipa Brane2, kupil in uporabljal tak program (brez da bi bil zelo obupan ali pa neodgovoren), brez zagotovljene podpore ni za misliti. Zagotovljena podpora, ki bo imela poleg moralnih zagotovil, kar največ tudi ˝substancionalnih˝ zagotovil. Ker besede prepričajo le naivne. Naivni pa ne preživijo. In če ne preživijo, ne preživi tudi vaše delo. Ali pa ne plačajo. Ali...
Iniciacija ideje je prišla od Braneta2, ki je zaradi naporne migracije, raje kupil še enkrat ˝nadgrajeni crap˝, ˝drek na kvadrat˝.
Pa je to Brane2, kaj bi prisilna migracija( pri kvalitetno nepodprtem programju) pomenila za vaše ˝stranke˝. Propade servisov, odpuščanje, ipd...
Samo moj komentar za premislek. Ne polemiko.
Veliko sreče, IgorGrozni
Brane2 ::
Če se že selim, se raje selim na odprto kodo, ki jo lahko spremenim sam ali plačam komu, da jo spremeni.
Kar se migracije tiče, saj pravim, izvoz je, vsaj iz PCA možen in po pregledu materiala ne vidim, zakaj to ne bi šlo tudi v praksi.
Support in podpora sta lahko samo boljša od PCA. Ki je BTW prastari amreriški program, prirejen in prilagojen našemu trgu.
Anter pravi, da so odkupili licenco zanj in da je sedaj PCA3000 nadgradnja obstoječega. V resnici pa tam mnoge stvari niso dorečene in za vsako, še tako majhno spremembo je bilo treba čakati leta. Imel sem feeling, kot da so v SLO samo poslovenili program, roko nad kodo pa držijo tujci.
Kot da bi kdo pri nas reverse-engineeral kodo. da je lahko kaj spremenil. Sam sem raje odvisen od odprte kode kot od blagoslova nekoga, ki je zame ključen, jaz pa zanj sploh ne.
Tudi support drugih ponudnikov je zelo omejen. Če njim stvar dela, tebi pa ne in ne vedo napamet odgovora, "tough luck"...
Zato se mi zdi, da bi bila to lahko dobra varianta za OS program. Pač support bi plačal, če bi ga rabil pri kakem mojstru, ki bi se s tem ukvarjal.
Kar se migracije tiče, saj pravim, izvoz je, vsaj iz PCA možen in po pregledu materiala ne vidim, zakaj to ne bi šlo tudi v praksi.
Support in podpora sta lahko samo boljša od PCA. Ki je BTW prastari amreriški program, prirejen in prilagojen našemu trgu.
Anter pravi, da so odkupili licenco zanj in da je sedaj PCA3000 nadgradnja obstoječega. V resnici pa tam mnoge stvari niso dorečene in za vsako, še tako majhno spremembo je bilo treba čakati leta. Imel sem feeling, kot da so v SLO samo poslovenili program, roko nad kodo pa držijo tujci.
Kot da bi kdo pri nas reverse-engineeral kodo. da je lahko kaj spremenil. Sam sem raje odvisen od odprte kode kot od blagoslova nekoga, ki je zame ključen, jaz pa zanj sploh ne.
Tudi support drugih ponudnikov je zelo omejen. Če njim stvar dela, tebi pa ne in ne vedo napamet odgovora, "tough luck"...
Zato se mi zdi, da bi bila to lahko dobra varianta za OS program. Pač support bi plačal, če bi ga rabil pri kakem mojstru, ki bi se s tem ukvarjal.
On the journey of life, I chose the psycho path.
jype ::
Ja, meni ni problem izstavit racuna za letno vzdrzevanje (in seveda podpisat pogodbo, v kateri za to nekaj nudim). V bistvu od takih pogodb zivim. Seveda se bo od strank, ki bodo zelele "outsourced" podporo zahtevala ustrezna oprema, da meni ne bo treba hodit po Sloveniji in se ubadat s hardverom. Ce kdo ima take potrebe, lahko placa, pa mu jaz najdem izvajalca s kombijem, ki bo zadeve pripeljal in prikljucil na strom in internet.
Simulirati knjigovodje niti ne moremo niti ne zelimo. Vsekakor z BigWhaleom poznava vsaj dva racunovodska servisa, ki bi ju razvoj takega programskega paketa zanimal. Ker sem jaz (pa verjetno tudi ostali, ki bi sodelovali) mahnjen na avtomatizacijo postopkov, bi paket zagotovo znal komunicirat z vsem zivim, uporabniski vmesniki pa bi bili narejeni po "js bi mela najrajs tkole stolpec pol pa tlele izberem, vpisem znesek in potrdim, pa je". Direktno delo z uporabnikom je po moje tudi bistvo razvoja dobrega UI (seveda moras vedno ponuditi boljso resitev, kadar si je uporabnik zaradi navajenosti na dolocen slab UI ne more predstavljati, ampak zgolj ponuditi, ne vsiliti).
Python ima tip Decimal, ki ni najbolj ucinkovit, je pa neomejeno natancen in pri zaokrozevanju ne dela nobenih napak. Napisat Qt class ki implementira tak tip je tudi zgolj par dni dela in en lep zakljucen unit test. Vse kar je zoprno je tak tip implementirat v "pocasnih" jezikih ala Javascript, ampak mislim da to ni problem, ker je najbolje da se rec postavi tako, da s stevilkami zares operirata zgolj aplikacijski streznik in baza (Postgres in MySQL oba poznata tip decimal).
Simulirati knjigovodje niti ne moremo niti ne zelimo. Vsekakor z BigWhaleom poznava vsaj dva racunovodska servisa, ki bi ju razvoj takega programskega paketa zanimal. Ker sem jaz (pa verjetno tudi ostali, ki bi sodelovali) mahnjen na avtomatizacijo postopkov, bi paket zagotovo znal komunicirat z vsem zivim, uporabniski vmesniki pa bi bili narejeni po "js bi mela najrajs tkole stolpec pol pa tlele izberem, vpisem znesek in potrdim, pa je". Direktno delo z uporabnikom je po moje tudi bistvo razvoja dobrega UI (seveda moras vedno ponuditi boljso resitev, kadar si je uporabnik zaradi navajenosti na dolocen slab UI ne more predstavljati, ampak zgolj ponuditi, ne vsiliti).
Python ima tip Decimal, ki ni najbolj ucinkovit, je pa neomejeno natancen in pri zaokrozevanju ne dela nobenih napak. Napisat Qt class ki implementira tak tip je tudi zgolj par dni dela in en lep zakljucen unit test. Vse kar je zoprno je tak tip implementirat v "pocasnih" jezikih ala Javascript, ampak mislim da to ni problem, ker je najbolje da se rec postavi tako, da s stevilkami zares operirata zgolj aplikacijski streznik in baza (Postgres in MySQL oba poznata tip decimal).
Brane2 ::
Ki ima že sedaj nekaj srednjega IT kadra, kadra, ki bo zmogel vedro in prijazno izvajati podporo samo temu programu, magar do smrti.
Support za PCA stane 35 kSIT letno. Seveda za ta denar dobiš zelo omejen support. Recimo da je program zastonj in OS, support pa stane ene tolk, pa kjerkoli ga vzameš.
Recimo da ti ga ponujam jaz, kot zunanji avtor in da imava na to temo pogodbo o delu ali kaj podobnega.
To čez palec pomeni, da bom od tega denarja osebno videl le kakih 60%, torej 21 kSIT. Za neko normalno delo rabim torej reciva 10 strank x 12 mesecev = 120 strank- za 210 kSIT netto na mesec.
Pri tem lahko računam, da me bo vsaska nova instalacija ( ko torej stranka sama inštalira program) "stala" nekaj klicev in živcev prvih nekaj dni, pa še to, če nimam tekoče webstrani, z "Knowledge Baseom", "Troubleshootingom", "FAQom" itd.
Pozneje me folk ne boliko klical. Vzdrževanje 120 strank pa ne bi smel biti tak problem.
PA še tu nismo vračunali dodatnih bombončkov. Ja, program je zastonj. Tudi Linux, če ga kdo hoče. Ampak ni pa razloga, da bi bila montaža in priprava stroja zastonj. Zmontiraš program, skupaj z lokalnim prevozom in pobereš 5 kSIT. Zmontiraš komu cel Linux s programom in pobereš 15 kSIT.
Zmontiraš OS in program na vseh 10 enakih mašin v štacuni in pobereš zlahka 100 kSIT.
Da ne govorimo o tem, da se bodo vsi obesili nate, da jim vzdržuješ tudi rač. opremo itd in o prihodkih iz tega naslova.
S tem bi si zlahka lahko privoščil solidno preživetje in delo, pri katerem si lahko sam narekuješ tempo glede na to, koliko rabiš denar...
On the journey of life, I chose the psycho path.
Brane2 ::
Python ima tip Decimal, ki ni najbolj ucinkovit, je pa neomejeno natancen in pri zaokrozevanju ne dela nobenih napak. Napisat Qt class ki implementira tak tip je tudi zgolj par dni dela in en lep zakljucen unit test. Vse kar je zoprno je tak tip implementirat v "pocasnih" jezikih ala Javascript, ampak mislim da to ni problem, ker je najbolje da se rec postavi tako, da s stevilkami zares operirata zgolj aplikacijski streznik in baza (Postgres in MySQL oba poznata tip decimal).
Ta stvar bi morala biti izpiljena, ker takih operacij je lahko veliko. NE bi blo bolje naredit to v Cju in samo klicat rutine iz Pythona ?
On the journey of life, I chose the psycho path.
jype ::
No, jaz bi bil od tehle postavk precej drazji, nikakor pa ne bi imel nic proti, ce bi kdo isto storitev ponujal ceneje. Moja "glavna dejavnost" je programiranje in vse, kar od takega vzdrzevanja zelim, je dovolj denarja, da pokrivam sprotne stroske. Stranke so pa vec kot ocitno pripravljenje placati tudi 5x visjo ceno za dober support. Jaz imam takih strank zgolj nekaj cez 20, ampak nobena od njih se nikoli ne pritozuje in praviloma napake odpravim se preden jih oni sami opazijo.
Ampak to je ze bolj poslovna strategija, o tem bomo razglabljali, ko bo kaj za pokazat :)
Ampak to je ze bolj poslovna strategija, o tem bomo razglabljali, ko bo kaj za pokazat :)
jype ::
Brane2> Ta stvar bi morala biti izpiljena, ker takih operacij je lahko veliko. NE bi blo bolje naredit to v Cju in samo klicat rutine iz Pythona ?
Saj je implementirana v Cju. Samo da je implementirana kot Python modul.
EDIT: ni v Cju, pure python modul je, sorry. Je pa se vedno dovolj hiter za karkoli, cesar noces delat v bazi :)
10.000x poklicat __add__ traja 4.10 sekunde na enem 2.6GHz p4, kar je po moje dovolj za application server. Vecino teh kalkulacij tako in tako lahko zahtevas od SQL baze, ki je se za par magnitud hitrejsa.
Saj je implementirana v Cju. Samo da je implementirana kot Python modul.
EDIT: ni v Cju, pure python modul je, sorry. Je pa se vedno dovolj hiter za karkoli, cesar noces delat v bazi :)
>>> profile.run('sum([decimal.Decimal(str(x/1000)) for x in xrange(10000)])')
501026 function calls (472022 primitive calls) in 7.890 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall filename:lineno(function)
20002 0.190 0.000 0.190 0.000 :0(__new__)
1 0.000 0.000 0.000 0.000 :0(abs)
10000 0.020 0.000 0.020 0.000 :0(get)
40000 0.240 0.000 0.240 0.000 :0(group)
102005 0.730 0.000 0.730 0.000 :0(isinstance)
29004 0.260 0.000 0.260 0.000 :0(len)
20000 0.130 0.000 0.130 0.000 :0(lower)
19000 0.280 0.000 0.280 0.000 :0(map)
10000 0.110 0.000 0.110 0.000 :0(match)
1 0.000 0.000 0.000 0.000 :0(max)
11000 0.070 0.000 0.070 0.000 :0(min)
1 0.000 0.000 0.000 0.000 :0(setprofile)
20000 0.110 0.000 0.110 0.000 :0(startswith)
29005/1 0.300 0.000 4.220 4.220 :0(sum)
1 0.190 0.190 7.890 7.890 <string>:1(?)
9000 0.170 0.000 0.640 0.000 decimal.py:1472(_fix)
9000 0.230 0.000 0.350 0.000 decimal.py:1492(_fixexponents)
1 0.000 0.000 0.000 0.000 decimal.py:1535(_round)
1 0.000 0.000 0.000 0.000 decimal.py:1837(_rescale)
9001 0.040 0.000 0.050 0.000 decimal.py:2140(adjusted)
9000 0.070 0.000 0.070 0.000 decimal.py:2295(Etop)
26997 0.450 0.000 0.570 0.000 decimal.py:2816(__init__)
8999 0.190 0.000 0.190 0.000 decimal.py:2841(_normalize)
10000 0.080 0.000 0.130 0.000 decimal.py:2904(_convert_other)
10000 0.160 0.000 0.240 0.000 decimal.py:2924(_isinfinity)
10000 0.240 0.000 0.420 0.000 decimal.py:2932(_isnan)
10000 0.750 0.000 1.340 0.000 decimal.py:3033(_string2exact)
20000 0.080 0.000 0.080 0.000 decimal.py:438(getcontext)
20002 1.380 0.000 4.330 0.000 decimal.py:473(__new__)
29004 0.260 0.000 0.450 0.000 decimal.py:636(__nonzero__)
10000 1.160 0.000 4.110 0.000 decimal.py:920(__add__)
0 0.000 0.000 profile:0(profiler)
1 0.000 0.000 7.890 7.890 profile:0(sum([decimal.Decimal(
str(x/1000)) for x in xrange(10000)]))
10.000x poklicat __add__ traja 4.10 sekunde na enem 2.6GHz p4, kar je po moje dovolj za application server. Vecino teh kalkulacij tako in tako lahko zahtevas od SQL baze, ki je se za par magnitud hitrejsa.
Zgodovina sprememb…
- spremenil: Senitel ()
IgorGrozni ::
Ja Brane2, je nekaj prednosti OS programja. Prevzame lahko kdorkoli, razvija lahko kdorkoli. Ne rabi biti ravno ˝od vas˝, ....
PCA so mi pred leti ponujali preko znanke-računovodje, ki naj bi se zaposlila pri njih. Potem, ko se je nenavadno zapletalo pri zaposlitvi, ..finančna situacija,...določen čas...na dva meseca podaljševanje... pozabil..
NORMASoft so moji frendi in delajo, kolikor slišim dobre programe, a vendar se tudi njim zapleta in.....
Birokrat Win je še najbolj pohvaljen,....
Kakšen ˝ pool˝ mojstrov, z imeni in priimki, z telefonom, ki bi bili pripravljeni podpisati pogodbe o vzdrževanju na dolgi rok, ...neka firma z poolom šljakerjev, kakrkoli, le ideja, da je tvoje temeljno orodje odvisno od iskanja pravega mojstra takrat, ko si v težavah, pa še mojstra, ki ne bo imel neke ˝prave˝odgovornosti, da ti pomaga, ko pomoč rabiš.... ne vem, no... zame je to kar grozljivo in bi se počutil precej neodgovorno.
V majhnih pogonih, kakršen je moj, si zaposlitve mojstra ne moreš privoščiti, večji sistemi pa programe in mojstre že imajo, torej...
Vaš doseg bi bil najprej tukaj, majhni in majhni-srednji, šele potem če, ...tako veliki, da bi mojstre zaposlovali. In tako imeli ˝zagotovljeno˝podporo.
Je pa seveda, če želite le izdelati osnovo za ˝mojstre˝,(mogoče tudi za PCA-jevce
) in zadeve ne želite tržiti, to pohvalno.
In je moj komentar nepotreben.
PCA so mi pred leti ponujali preko znanke-računovodje, ki naj bi se zaposlila pri njih. Potem, ko se je nenavadno zapletalo pri zaposlitvi, ..finančna situacija,...določen čas...na dva meseca podaljševanje... pozabil..
NORMASoft so moji frendi in delajo, kolikor slišim dobre programe, a vendar se tudi njim zapleta in.....
Birokrat Win je še najbolj pohvaljen,....
Kakšen ˝ pool˝ mojstrov, z imeni in priimki, z telefonom, ki bi bili pripravljeni podpisati pogodbe o vzdrževanju na dolgi rok, ...neka firma z poolom šljakerjev, kakrkoli, le ideja, da je tvoje temeljno orodje odvisno od iskanja pravega mojstra takrat, ko si v težavah, pa še mojstra, ki ne bo imel neke ˝prave˝odgovornosti, da ti pomaga, ko pomoč rabiš.... ne vem, no... zame je to kar grozljivo in bi se počutil precej neodgovorno.
V majhnih pogonih, kakršen je moj, si zaposlitve mojstra ne moreš privoščiti, večji sistemi pa programe in mojstre že imajo, torej...
Vaš doseg bi bil najprej tukaj, majhni in majhni-srednji, šele potem če, ...tako veliki, da bi mojstre zaposlovali. In tako imeli ˝zagotovljeno˝podporo.
Je pa seveda, če želite le izdelati osnovo za ˝mojstre˝,(mogoče tudi za PCA-jevce
) in zadeve ne želite tržiti, to pohvalno. In je moj komentar nepotreben.
Brane2 ::
Ne razumem, v čem je to drugače od podpore, ki jo dobiš ob denimo Pantheonu.
Kdo da tam jajca na pladenj za tvojo podporo in se obveže na karkoli, kar bi ga lahko ubilo ?
Vedno dobiš pri teh zadevah v najboljšem primeru to, kar si pripravljen plačat.
Pa če plačaš podjetju ali posamezniku. Razlika je le v davkih, ki jih pobere cesar in premiumu, ki ga direktor zažene za kurberaj.
Kdo da tam jajca na pladenj za tvojo podporo in se obveže na karkoli, kar bi ga lahko ubilo ?
Vedno dobiš pri teh zadevah v najboljšem primeru to, kar si pripravljen plačat.
Pa če plačaš podjetju ali posamezniku. Razlika je le v davkih, ki jih pobere cesar in premiumu, ki ga direktor zažene za kurberaj.
On the journey of life, I chose the psycho path.
poweroff ::
Hja, pomisleki, ki jih navaja Igor so na mestu. Jaz pa zadevo vidim takole. Nekdo ima veselje lotiti se česa takega. Če ne bo uspelo, bodo imeli za seboj zanimivo izkušnjo, morda pa se bo ta skupina tudi tako notranje izoblikovala, da bo sposobna izpeljati kakšen drug projekt. Pač, ekipa bo uigrana.
Če pa zadeva uspe, bo pa ekipa gotovo najbolj usposobljena za tech support. Vednar pa bo v primeru uspeha potrebno narediti še en korak. Marketing in support se bosta morala profesionalizirati. To laho pomeni, da se kot nekakšnega partnerja dobi kakšno resno firmo, pač nekoga, ki mu povprečen Jazen zaupa in ta firma bo potem "zagotavljala" podporo in razvoj.
Vprašanje je samo ali bodo člani ekipe to dopustili. Kolikor razumem jypeta in BigWhalea je odgovor da. Tako da kakšnega velikega probelma ne vidim.
P. S. Moja ponudba glede sodelovanja pri perifernih delih (priročnik, testiranje,...) še vedno velja.
Če pa zadeva uspe, bo pa ekipa gotovo najbolj usposobljena za tech support. Vednar pa bo v primeru uspeha potrebno narediti še en korak. Marketing in support se bosta morala profesionalizirati. To laho pomeni, da se kot nekakšnega partnerja dobi kakšno resno firmo, pač nekoga, ki mu povprečen Jazen zaupa in ta firma bo potem "zagotavljala" podporo in razvoj.
Vprašanje je samo ali bodo člani ekipe to dopustili. Kolikor razumem jypeta in BigWhalea je odgovor da. Tako da kakšnega velikega probelma ne vidim.
P. S. Moja ponudba glede sodelovanja pri perifernih delih (priročnik, testiranje,...) še vedno velja.
sudo poweroff
Brane2 ::
Licenca: striktno GPL, z moznostjo, da se kak del programa naredi z LGPL licenco. Ali pa nekaj kar je s tem kompatibilno.
Kot jaz razumem, odprtost zadeve narekuje že licenca. Torej ti nihče ne more razlagat, kako lahko uporabljaš ta program in kdo ti daje support.
On the journey of life, I chose the psycho path.
jype ::
Po moje niti mene niti BigWhalea ne bi motilo, ce bi marketing prevzela kaksna marketing firma. Support contract pac objavis na nekem web sajtu, poleg pa cenik. Ce komu ni vsec, kar za tak denar dobi, lahko se vedno poisce mulca, ki mu bo vzdrzeval ceneje, ali pa kupi konkurencno programje.
Brane2 ::
Še ena OT drobnarija:
Linux v navezavi s Pro/Klikom in knjiženje/izvedba plačil preko tega.
Moja računovodkinja recimo ne uporablja ProKlika ( in plačuje vse s papirno položnico), ker si ne zaupa.
Kar se računalniške pismenosti tiče, je izreden talent za zajebat stvari, tako da ima na mašini stalno kak virus.
Če bi tak program laufal na Linuxu in bi lahko recimo Proklik laufal pod wineom in bi bila zadeva primerno uštimana, ji ne bi blo treba toliko skrbet zaradi virusov in bi lahko praktično takoj prešaltala na Linux.
Samodejno knjiženje plačil/prejemkov iz izpiskov banke in izvedba plačil pa je velik časovni prihranek in praktično nujna funkcija, če ne v začetni, pa vsaj v poznejši fazi.
Seveda bi blo treba imet ob takem folku kak pregledan in požegnan Linux, ki se sicer rad kje zlomi.
Mogoče bi bil čas za ST Linux 2 ? Čeprav jaz že dalj časa razmišljam in nekaj tudi praskam v smeri lasntega Gentoo Linuxa- code name "Gentoo Lina"
No, toliko. Resda rahlo OT, se pa nanaša na program...
Linux v navezavi s Pro/Klikom in knjiženje/izvedba plačil preko tega.
Moja računovodkinja recimo ne uporablja ProKlika ( in plačuje vse s papirno položnico), ker si ne zaupa.
Kar se računalniške pismenosti tiče, je izreden talent za zajebat stvari, tako da ima na mašini stalno kak virus.
Če bi tak program laufal na Linuxu in bi lahko recimo Proklik laufal pod wineom in bi bila zadeva primerno uštimana, ji ne bi blo treba toliko skrbet zaradi virusov in bi lahko praktično takoj prešaltala na Linux.
Samodejno knjiženje plačil/prejemkov iz izpiskov banke in izvedba plačil pa je velik časovni prihranek in praktično nujna funkcija, če ne v začetni, pa vsaj v poznejši fazi.
Seveda bi blo treba imet ob takem folku kak pregledan in požegnan Linux, ki se sicer rad kje zlomi.
Mogoče bi bil čas za ST Linux 2 ? Čeprav jaz že dalj časa razmišljam in nekaj tudi praskam v smeri lasntega Gentoo Linuxa- code name "Gentoo Lina"
No, toliko. Resda rahlo OT, se pa nanaša na program...
On the journey of life, I chose the psycho path.
jype ::
To je predvsem problem (ne)pripravljenosti bank, da bi razvile neko programmer friendly resitev. Mogoce bo kdaj kaj takega razvil halcom, ampak trenutno nisem slisal za nobeno tako rec (vedno pa s tem tezim, ko se s kom relevantnim pogovarjam).
Brane2 ::
Saj ne rabiš pripravljenost bank.
Te stvari je definiral že DURS, mislim. Nekje na naetu je definicija elektronskega obrazca, ki jo tak program mora znati sprejeti ali oddati.
Tvoj program samo pripravi datoteko s plačili. Ti jo iz Proklika uvoziš, pregledaš, če vsa plačila štimajo in odpošlješ.
Ravno tako je s prejemki. Ti iz proklika izvoziš izpiske v predpisanem- standardnem formatu in jih uvoziš v svoj X program.
TA poknjiži prejemke in preveri, če so plačila, ki jih je imel poknjižena na ta dan dejanjsko "šla skozi"...
Te stvari je definiral že DURS, mislim. Nekje na naetu je definicija elektronskega obrazca, ki jo tak program mora znati sprejeti ali oddati.
Tvoj program samo pripravi datoteko s plačili. Ti jo iz Proklika uvoziš, pregledaš, če vsa plačila štimajo in odpošlješ.
Ravno tako je s prejemki. Ti iz proklika izvoziš izpiske v predpisanem- standardnem formatu in jih uvoziš v svoj X program.
TA poknjiži prejemke in preveri, če so plačila, ki jih je imel poknjižena na ta dan dejanjsko "šla skozi"...
On the journey of life, I chose the psycho path.
jype ::
Jaz bi raje videl resitev, pri kateri mi dolocijo XML, ki ga elektronsko podpisanega posljem na bankin application server (tako kot to naredi ProKlik oz. katerikoli drug software) in XML, ki ga dobim v odgovor.
Tako bi izlocil moznost napak pri prekladanju podatkov sem in tja med programi.
Tako bi izlocil moznost napak pri prekladanju podatkov sem in tja med programi.
Brane2 ::
To bi blo lepše, al "o tom potom".
Zelo lepo bi blo za začetek imet standardno varianto. SPloh zato, ker dela ne glede na tip bančnega klienta.
Zelo lepo bi blo za začetek imet standardno varianto. SPloh zato, ker dela ne glede na tip bančnega klienta.
On the journey of life, I chose the psycho path.
PAMarvin ::
Se je kdo kaj ukvarjal z temle:
http://www.sql-ledger.org
Verjetno bi bila stvar uporabna tudi pri nas. Če uporabimo tole kot osnovo, nam bo prihranjeno precej "tople vode" in iskanja napak. Verjetno bomo pa prisiljeni tudi v kakšen kompromis. Zanima me vaše mnenje glede obstoječe funkcionalnosti in kaj mu še manjka ?
Kar se uporabljenih tehnologij tiče so prestale "test časa" in jih je pač treba sprejeti
http://www.sql-ledger.org
Verjetno bi bila stvar uporabna tudi pri nas. Če uporabimo tole kot osnovo, nam bo prihranjeno precej "tople vode" in iskanja napak. Verjetno bomo pa prisiljeni tudi v kakšen kompromis. Zanima me vaše mnenje glede obstoječe funkcionalnosti in kaj mu še manjka ?
Kar se uporabljenih tehnologij tiče so prestale "test časa" in jih je pač treba sprejeti
Zgodovina sprememb…
- spremenilo: PAMarvin ()
CCfly ::
IMHO ste se malo preveč vrgli v gruntanje o implementaciji, namesto da bi skupaj spravili zahteve strank in poslovni model do konca.
"My goodness, we forgot generics!" -- Danny Kalev
poweroff ::
Malce OT. Tak distro, primeren za začetnike se mi zdi Ubuntu. Morda bi poslovni model vključeval tudi prodajo celega sistema za podjetnike: računalnik + Ubuntu + pisariško programje + tale računovodski program + wine in konfiguracija Proklika.
sudo poweroff
WarpedGone ::
CCfly: bingo.
Problem je na OS terenu, kjer maš same freelancarje, dobit ekipo ljudi, ki so sposobni in pripravljeni par mesecev delat zato da na koncu izdajo specifikacijo softvera, brez ene vrstice delujoče kode.
Vsi bi takoj problem napadl tko kot ga vidijo oni sami z orodji, ki jih trenutno uporabljajo.
Debatirajo o najprimernejšem podatkovnem tipu za zneske, še preden je sploh jasno kaj bi ti zneski sploh bili, od kje bi prihajal in kam bi šli.
Po domače povedano: še en 'garažn softver'. Kodiranje ni nobena umetnost več, umetnost je design sistema. Če je želja po drugačnem softveru, pol se ga je nujno lotit drugače. Na tak horuk način je blo delanga večina 'malega' softvera. Ne vem zakaj bi pa tale horuk način obrodil kej bistveno drugačen rezultat.
Problem je na OS terenu, kjer maš same freelancarje, dobit ekipo ljudi, ki so sposobni in pripravljeni par mesecev delat zato da na koncu izdajo specifikacijo softvera, brez ene vrstice delujoče kode.
Vsi bi takoj problem napadl tko kot ga vidijo oni sami z orodji, ki jih trenutno uporabljajo.
Debatirajo o najprimernejšem podatkovnem tipu za zneske, še preden je sploh jasno kaj bi ti zneski sploh bili, od kje bi prihajal in kam bi šli.
Po domače povedano: še en 'garažn softver'. Kodiranje ni nobena umetnost več, umetnost je design sistema. Če je želja po drugačnem softveru, pol se ga je nujno lotit drugače. Na tak horuk način je blo delanga večina 'malega' softvera. Ne vem zakaj bi pa tale horuk način obrodil kej bistveno drugačen rezultat.
Zbogom in hvala za vse ribe
BigWhale ::
Naj me nekdo popravi, ce se motim.
Kaj potrebujes pri materialnem poslovanju kontni plan? Gre se za evidenco skladisca, izdajo racunov in ostalih papirjev.
Tukaj se knjigovodstva/racunovodstva niti dotaknes ne. Mogoce ga samo malo oplazis in to je to. :)
Je pa precej stvari off-topic tukaj in se precej prekmalu, da bi se o njih debatiralo.
Jaz bom ta teden pripravil 'document-flow' shemo in jo poslal sem, da malo pokomentirate.
Vmes bi se pa lahko pomenili o protokolu, ki ga bo govoril appserver. Ki pa je lahko, kar se mene tice napisan v phytonu, ce treba. Ce bo stvar v resnici prepocasna pa se lahko spise v kakem drugem jeziku.
Z Juretom sva ze nekaj razglabljala, da bi moral biti protokol precej preprosta zadeva, string based protokol.
Na primer, da uporabnik lista po sifrantu kupcev in klikne na enega kupca, applikacija pa takrat zahteva podatke o tem kupcu, takrat poslje app serverju string
GET_DATA_BUYER #id
App server, pa odgovori s serijo stringov v katerem so podatko o tem kupcu...
Ko se za protokol zmenimo, se lahko naredi se en communication class, ki bo implementacija protokola.
Zaenkrat to...
Kaj potrebujes pri materialnem poslovanju kontni plan? Gre se za evidenco skladisca, izdajo racunov in ostalih papirjev.
Tukaj se knjigovodstva/racunovodstva niti dotaknes ne. Mogoce ga samo malo oplazis in to je to. :)
Je pa precej stvari off-topic tukaj in se precej prekmalu, da bi se o njih debatiralo.
Jaz bom ta teden pripravil 'document-flow' shemo in jo poslal sem, da malo pokomentirate.
Vmes bi se pa lahko pomenili o protokolu, ki ga bo govoril appserver. Ki pa je lahko, kar se mene tice napisan v phytonu, ce treba. Ce bo stvar v resnici prepocasna pa se lahko spise v kakem drugem jeziku.
Z Juretom sva ze nekaj razglabljala, da bi moral biti protokol precej preprosta zadeva, string based protokol.
Na primer, da uporabnik lista po sifrantu kupcev in klikne na enega kupca, applikacija pa takrat zahteva podatke o tem kupcu, takrat poslje app serverju string
GET_DATA_BUYER #id
App server, pa odgovori s serijo stringov v katerem so podatko o tem kupcu...
Ko se za protokol zmenimo, se lahko naredi se en communication class, ki bo implementacija protokola.
Zaenkrat to...
Ziga Dolhar ::
> Kaj potrebujes pri materialnem poslovanju kontni plan? Gre se za evidenco skladisca, izdajo racunov in ostalih papirjev.
Kaj konkretno pomeni "materialno poslovanje", ne vem. Ampak za "evidenco skladišča" potrebuješ račune, na katerih vodiš samo "skladišče" [zbirni] in posamezne materiale [analitični konto]. "Izdaja računa" pomeni poslovni dogodek, ki je sestavljen iz nekaj [recimo vsaj dveh - če izpustim razred 7] knjižb. Knjižba gre na konto. Pri proizvodnji podobno.
[Tvoje vprašanje se mi zdi tako zelo "čudno", da je precej verjetno, da ga sploh nisem dojel. Če je tako ... izvoliš razložit :)]
Kaj konkretno pomeni "materialno poslovanje", ne vem. Ampak za "evidenco skladišča" potrebuješ račune, na katerih vodiš samo "skladišče" [zbirni] in posamezne materiale [analitični konto]. "Izdaja računa" pomeni poslovni dogodek, ki je sestavljen iz nekaj [recimo vsaj dveh - če izpustim razred 7] knjižb. Knjižba gre na konto. Pri proizvodnji podobno.
[Tvoje vprašanje se mi zdi tako zelo "čudno", da je precej verjetno, da ga sploh nisem dojel. Če je tako ... izvoliš razložit :)]
https://dolhar.si/
Brane2 ::
Mislim, da rabiš kontni plan za vse. Sploh, ker so konti osnova. NE moreš se lotit tam nekega perifernega konca in upat, da bo celota dobro izpadla, ker boš nekako nekaj že zimproviziral.
Če bi šlo samo za izdajo in prejem robe v merilu majhnega podjetna, bi verjetno lahko kaj skupaj zmazal s kako OpenOfficeov preglednico in nekaj ekstra programi ali čem podobnim.
Tudi recimo davki so lahko odvisni od narave nabave. Če gre za blago, ki gre v nadaljnjo prodajo, je to konto 66.
Če gre za opremo firme, ki čaka na skladišču, ker recimo še ni zmontirana, je to verjetno konto 040.
Davek na opremo- osnovna sredstva je drugačen od davka na zaloge. Obračuna se sicer na koncu obdobja, pa vseeno.
Mislim, da morajo biti tudi skladišča za take stvari ločena med seboj.
Če bi šlo samo za izdajo in prejem robe v merilu majhnega podjetna, bi verjetno lahko kaj skupaj zmazal s kako OpenOfficeov preglednico in nekaj ekstra programi ali čem podobnim.
Tudi recimo davki so lahko odvisni od narave nabave. Če gre za blago, ki gre v nadaljnjo prodajo, je to konto 66.
Če gre za opremo firme, ki čaka na skladišču, ker recimo še ni zmontirana, je to verjetno konto 040.
Davek na opremo- osnovna sredstva je drugačen od davka na zaloge. Obračuna se sicer na koncu obdobja, pa vseeno.
Mislim, da morajo biti tudi skladišča za take stvari ločena med seboj.
On the journey of life, I chose the psycho path.
jype ::
OK, blazno siroka razprava nastaja.
Za zacetek mora obstajat dovolj splosna platforma, ki omogoca vse, kar tak program potrebuje, zato sem predlagal, da naredim protokol, streznik in odjemalce, ki bi zgledali nekako takole:
Edini primitivni tip je string (v katerega zapakiras tudi stevilke, ker moras itak omogocat arbitrarno natancnost), obstajata pa se tipa list in map (oz. dict v python terminologiji). List je niz objektov arbitrarnih tipov, map pa so pari imen in vrednosti. Vecina funkcij, ki jih klices na appserverju, vrnejo map, v katerem imas zapisano stanje klica in potencialne podatke, ki jih funkcija na AS vrne.
V AS bo zato lahko implementiran tudi sistem ACLjev, tako da lahko precej natancno dolocis, kaj kdo lahko in cesa ne.
Kar se tice kontov in tega pa lahko poleg BigWhalea se kdo opise, kako naj bi taka rec (materialno poslovanje, flow dokumentov, konti) izgledala in kaj naj bi znala.
Za zacetek mora obstajat dovolj splosna platforma, ki omogoca vse, kar tak program potrebuje, zato sem predlagal, da naredim protokol, streznik in odjemalce, ki bi zgledali nekako takole:
Edini primitivni tip je string (v katerega zapakiras tudi stevilke, ker moras itak omogocat arbitrarno natancnost), obstajata pa se tipa list in map (oz. dict v python terminologiji). List je niz objektov arbitrarnih tipov, map pa so pari imen in vrednosti. Vecina funkcij, ki jih klices na appserverju, vrnejo map, v katerem imas zapisano stanje klica in potencialne podatke, ki jih funkcija na AS vrne.
V AS bo zato lahko implementiran tudi sistem ACLjev, tako da lahko precej natancno dolocis, kaj kdo lahko in cesa ne.
Kar se tice kontov in tega pa lahko poleg BigWhalea se kdo opise, kako naj bi taka rec (materialno poslovanje, flow dokumentov, konti) izgledala in kaj naj bi znala.
BigWhale ::
Ziga,
Ja, izdaja racuna je poslovni dogodek, ki se ga potem knjizi in 'knjigovodsko obdeluje'.
Ampak, na tisti strani, kjer ti izdas racun, ne rabis vedeti nic o kontih, knjizenju in knjigovodstvu.
Ti moras evidentirati racun (oziroma papir, ki ga izdas, ker tukaj se gre tudi za ostale papirje) in poskrbeti zato, da je racun pravilen. Knjizenje se pa izvaja kasneje, takrat sele razporejas cifre, ki so 'na papirju' na razlicne konte.
Ko izdas racun, ne rabis o financnem delu nic vedeti, ker gre samo za blagovno poslovanje. Lahko si kosovnico na racunu naredis tako, da ze evidentiras kam posamezen izdelek spada, ni pa to 'a must'.
Vecina uporabnikov se tako ali tako ukvarja z blagovnim delom poslovanja, knjigovodsko se pa potem s tem ukvarjajo racunovodkinje.
Za vodenje evidence racunov in skladisca tega ne potrebujes. Potrebujes samo dovolj flexibilno zastavljen database model, da lahko to implementiras takrat, ko se spravis delat financno knjigovodski del programa. Ce se ga sploh spravis delat.
Tako da jaz od nacrta ne odstopam bistveno, je pa jasno, da je treba te stvari imeti v mislih ze prej. :)
Ja, izdaja racuna je poslovni dogodek, ki se ga potem knjizi in 'knjigovodsko obdeluje'.
Ampak, na tisti strani, kjer ti izdas racun, ne rabis vedeti nic o kontih, knjizenju in knjigovodstvu.
Ti moras evidentirati racun (oziroma papir, ki ga izdas, ker tukaj se gre tudi za ostale papirje) in poskrbeti zato, da je racun pravilen. Knjizenje se pa izvaja kasneje, takrat sele razporejas cifre, ki so 'na papirju' na razlicne konte.
Ko izdas racun, ne rabis o financnem delu nic vedeti, ker gre samo za blagovno poslovanje. Lahko si kosovnico na racunu naredis tako, da ze evidentiras kam posamezen izdelek spada, ni pa to 'a must'.
Vecina uporabnikov se tako ali tako ukvarja z blagovnim delom poslovanja, knjigovodsko se pa potem s tem ukvarjajo racunovodkinje.
Za vodenje evidence racunov in skladisca tega ne potrebujes. Potrebujes samo dovolj flexibilno zastavljen database model, da lahko to implementiras takrat, ko se spravis delat financno knjigovodski del programa. Ce se ga sploh spravis delat.
Tako da jaz od nacrta ne odstopam bistveno, je pa jasno, da je treba te stvari imeti v mislih ze prej. :)
kopernik ::
Samo to bi dodal ... ne "izumljati" nekih novih protokolov za komunikacijo med app serverjem in clienti. Ni potrebe, imho. Tako bo tudi pisanje odjemalcev za poljuben jezik/os lažje.
Kar se jezika tiče (za app server), pa pomoje ni potrebe, da se gleda samo na hitrost (npr. računanje z velikimi števili). Python je čist ok, za moje pojme. Bolj je važno, da je zadeva robustna(torej, da ne eksplodira pod velikim številom zahtev) in da se jo da enostavno replicirati na več strežnikov. Pač, namontiraš še eno škatlo(ali dve, tri) za morebitni večji obseg zahtev.
Kar se jezika tiče (za app server), pa pomoje ni potrebe, da se gleda samo na hitrost (npr. računanje z velikimi števili). Python je čist ok, za moje pojme. Bolj je važno, da je zadeva robustna(torej, da ne eksplodira pod velikim številom zahtev) in da se jo da enostavno replicirati na več strežnikov. Pač, namontiraš še eno škatlo(ali dve, tri) za morebitni večji obseg zahtev.
krho ::
json
si.Mail odprto-kodni odjemalec elektronske pošte. - http://www.simail.si
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net
Uredite si svojo zbirko filmov, serij in iger - http://xcollect.sf.net
WarpedGone ::
Skromen predlog:
Debata o tem kako in kaj nej stvar zgleda ne sodi ravno na forum, kjer lahko poljubni osebki vmes postamo nepovezane stvari in delamo zmedo.
Moj predlog:
1. izvest rekrutacijo, da se naredi osnovna ekipa in potalat par činov
2. postavt stran projekta
3. postavt mejling listo
4. izvest brainstorming, par intervjujew in pregled standardov
Tule se lahko vodi debata o posameznih ozkih temah, obveščanje o napredku, nadaljna rekrutacija, reklama, etc.
Debata o tem kako in kaj nej stvar zgleda ne sodi ravno na forum, kjer lahko poljubni osebki vmes postamo nepovezane stvari in delamo zmedo.
Moj predlog:
1. izvest rekrutacijo, da se naredi osnovna ekipa in potalat par činov
2. postavt stran projekta
3. postavt mejling listo
4. izvest brainstorming, par intervjujew in pregled standardov
Tule se lahko vodi debata o posameznih ozkih temah, obveščanje o napredku, nadaljna rekrutacija, reklama, etc.
Zbogom in hvala za vse ribe
OwcA ::
json
Se strinjam, zraven bi dodal še REST.
Uporaba obstoječih pristopov in protokolov se mi zdi precej bolj smiselna, kot ponovno odkrivanje tople vode.
Vecina funkcij, ki jih klices na appserverju, vrnejo map, v katerem imas zapisano stanje klica in potencialne podatke, ki jih funkcija na AS vrne.
Bi ne bilo bolje seznam parov? Drugače moraš imeti za vsak klic drugo stanje kar je slabo.
Otroška radovednost - gonilo napredka.
urbecar ::
BigWhaleov prvi post:
Zdej nebi rad bil nekej pameten ampak mislim da je tole nekak obrnjeno.
Prva faza: Izbira ustreznih tehnologij za razvoj. Od programskega jezika, knjiznjic, protokolov, ... In nek grob oris projekt, kaj bi se delalo in kako.
Druga faza: Podroben nacrt dela, definiral bi se 'scope' projekta, bolj natancno bi se povedalo kaj bi se delalo in kako, ter kdo bi to delal.
Zdej nebi rad bil nekej pameten ampak mislim da je tole nekak obrnjeno.
jype ::
OwcA> Se strinjam, zraven bi dodal še REST.
REST je ze. Treba se je zmenit, kako se nad RESTom serializira zadeve.
Zakaj potrebujes za vsak klic drugo stanje? Vedno dobis map (ki ga client library ne pokaze klicatelju, lahko pa ta do njega pride, ce ga potrebuje). Nazaj vedno dobis tisto, kar funkcije na AS vrnejo (in to je vedno natancno dokumentirano).
Ce je karkoli narobe lahko funkcija na AS dvigne exception z nekim opisom napake in programer bo to napako prejel zavito v obliko, primerno za njegovo okolje.
REST je ze. Treba se je zmenit, kako se nad RESTom serializira zadeve.
Zakaj potrebujes za vsak klic drugo stanje? Vedno dobis map (ki ga client library ne pokaze klicatelju, lahko pa ta do njega pride, ce ga potrebuje). Nazaj vedno dobis tisto, kar funkcije na AS vrnejo (in to je vedno natancno dokumentirano).
Ce je karkoli narobe lahko funkcija na AS dvigne exception z nekim opisom napake in programer bo to napako prejel zavito v obliko, primerno za njegovo okolje.
OwcA ::
Če je že REST, čemu potem zahtevki v oblik:
?
Če te prav razumem, so ključi v mapu stanja nekih operacij. Čim bo imel ta map več kot 1 element, bodo morali biti tudi ključi različni.
GET_DATA_BUYER #id
?
Zakaj potrebujes za vsak klic drugo stanje? Vedno dobis map (ki ga client library ne pokaze klicatelju, lahko pa ta do njega pride, ce ga potrebuje). Nazaj vedno dobis tisto, kar funkcije na AS vrnejo (in to je vedno natancno dokumentirano).
Če te prav razumem, so ključi v mapu stanja nekih operacij. Čim bo imel ta map več kot 1 element, bodo morali biti tudi ključi različni.
Otroška radovednost - gonilo napredka.
Zgodovina sprememb…
- spremenilo: OwcA ()
jype ::
Tisto si je BigWhale predstavljal...
Vsak request je obicajen HTTP request, ki v PATH dobi metadata (katero funkcijo iz katerega modula se klice, potencialno se kako so oblikovani podatki, ki sledijo v requestu in kaksen naj bi bil odgovor), v telesu requesta pa REST-like key=value pare.
Kljuci v mapu so vedno isti, ker je ta map zgolj container za podatke, ki se lepo poda RESTu.
Dejanski podatki, ki jih AS funkcija vrne, so lahko vsaj number, string, list ali map. Stevilke se serializira kot stringe v desetiskem zapisu, da je vsak request/response s financnega vidika vedno jasen.
En request vedno prinese en reply in en map, ki ga client library razpakira, pogleda polja v mapu in vrne polje "result" klicatelju, ce je vse OK, recimo.
Vsak request je obicajen HTTP request, ki v PATH dobi metadata (katero funkcijo iz katerega modula se klice, potencialno se kako so oblikovani podatki, ki sledijo v requestu in kaksen naj bi bil odgovor), v telesu requesta pa REST-like key=value pare.
Kljuci v mapu so vedno isti, ker je ta map zgolj container za podatke, ki se lepo poda RESTu.
Dejanski podatki, ki jih AS funkcija vrne, so lahko vsaj number, string, list ali map. Stevilke se serializira kot stringe v desetiskem zapisu, da je vsak request/response s financnega vidika vedno jasen.
En request vedno prinese en reply in en map, ki ga client library razpakira, pogleda polja v mapu in vrne polje "result" klicatelju, ce je vse OK, recimo.
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | T-2 DNS problemOddelek: Omrežja in internet | 1782 (1377) | Ghost007 |
| » | Navijanje Gigabyte 990XA-UD3 in FX8320+Coolink corator DSOddelek: Pomoč in nasveti | 1391 (1203) | gddr85 |
| » | Izračun hitrosti, če imamo podano pozicijo in pospešekOddelek: Šola | 2622 (2517) | c0dehunter |
| » | BSODOddelek: Pomoč in nasveti | 1348 (1112) | Constantine |
| » | Smartbuy cdji (strani: 1 2 3 )Oddelek: Pomoč in nasveti | 8855 (6270) | City |