Ubuntu Suomen keskustelualueet
Muut alueet => Yleistä keskustelua => Aiheen aloitti: henri_aleksi - 25.05.09 - klo:14.59
-
Mainostetaan nyt vähän tuota projektia:
http://code.google.com/p/finlasku/
Kyseessä on siis uusi projekti joka pyrkii tekemään laskutusohjelmaa linuxille,
projektilla on nyt myös keskustelua varten luotu groupsi googleen:
http://groups.google.com/group/finlasku mutta pyrin seuraamaan myös täällä muodostuvaa keskustelua.
Communityn apua kaivataan niin ideoimisessa kuin koodaamisessakin.
Toi projekti on tehty monon päälle, joten sen pitäisi kohtuu ongelmitta kääntyä myös
windowsille ja macillekkin mutta tarkoitus on kuitenkin luoda viimekädessä yksinkertainen laskutusohjelma linuxille.
-
Laskutusohjelmat on aina tervetulleita.
Yksi ominaisuus tuohon ainakin pitäisi saada, nimittäin tuoteluettelo, mistä voisi klikkailla laskuun laskutettavia tuotteita.
Sitten osamaksu ominaisuus ja että voisi tulostaa kaikki laskut kerralla.
Kai tuohon viivakoodikin tulostuu?
-
Laskutusohjelmat on aina tervetulleita.
Yksi ominaisuus tuohon ainakin pitäisi saada, nimittäin tuoteluettelo, mistä voisi klikkailla laskuun laskutettavia tuotteita.
Sitten osamaksu ominaisuus ja että voisi tulostaa kaikki laskut kerralla.
Kai tuohon viivakoodikin tulostuu?
Tässä vaiheessa ei ole ollut mietinnässä tuoteluetteloa mutta kuulostaa ihan hyvältä ajatukselta.
Viivakoodi tulee varmaankin jossain vaiheessa. Aikataulu riippuu ihan siitä, onko joku jo tehnyt valmiin kirjaston sitä varten.
Tarkoititko, että tulostaa kerralla kaikki osalaskut vai että luo laskuja ensin ja sitten tulostaa jälkikäteen kaikki kerralla?
Osaatko kertoa tarkemmin vaatimuksia osalaskun suhteen? Varmaankin määrittelyt korkoprosentille ja jotain muuta?
Myös ihan apua siitä, mitä laki vaatii laskulta tietyssä erikoistulanteessa tulee tarpeeseen.
Valitettavasti itse en ole (ainakaan vielä) yrittäjä joten,
kaipaamme myös ihan yrittäjän näkökulmaa asiaan.
-
Niin tuo osalasku tai erälasku sillain, että voi summan jakaa haluamaansa määrään eriä ja voisihan siihen lisätä vaihtoehtoisen lisäkoron tai sitten kiinteän osamaksulisän. Tietysti semmoinen mahdollisuuskin olisi paikallaan, että voi muuttaa summia laskuista, jos vaikka haluaa ensimmäisen tai viimeisen erän isommaksi. Tulostus kaikille laskuille joko kerralla tai sitten, kun on aika seuraava erä lähettää. Muistutus toiminto olisi tuossakin paikallaan, kun on tietty aika seuraavan laskun eräpäivään, niin ohjelma antaisi ilmoituksen ja samaten, kun on jo lähetetyn laskun eräpäivä umpeutunut, niin voisi tulla ilmoitus, niin muistaa tarkastaa, että onko maksettu.
En ole itsekään yrittäjä, mutta eräs tuttu on tuommoista kaivannut, eikä PKlasku sille oikein soveltunut, koska siinä ei ollut tuoteluetteloa ja kun tuotteita on laskussa jopa toistakymmentä, niin on aika tuskaista kirjoittaa jokainen tuote erikseen.
Mahdollinen ale% olisi myös kätevä lisä laskuun.
PKlasku osaa tulostaa viivakoodin, joten sieltä varmaan saisi tietoa tuosta viivakoodista
http://pklasku.sourceforge.net/
Tulostettavaan laskuun olisi hienoa myöskin saada yläreunaan firman logo.
-
Joo, ihan hyviä pointteja.
Nyt kun ollaan kuitenkin vielä ihan alkutaipaleella otamme meilellämme apua vastaan niin koodauksen kuin palautteenkin muodossa.
Varmaankin suurin pelko projektin suhteen on se, että lähdetään tekemään sellaista ohjelmaa jolle ei löydy käyttötarvetta.
Koodareitakin tarvitaa, mikäli toivomuslista kasvaa suureksi voi niiden ominaisuuksien saaminen ohjelmaan kestää....
-
Nyt kun ollaan kuitenkin vielä ihan alkutaipaleella otamme meilellämme apua vastaan niin koodauksen kuin palautteenkin muodossa.
Varmaankin suurin pelko projektin suhteen on se, että lähdetään tekemään sellaista ohjelmaa jolle ei löydy käyttötarvetta.
Mikä oikein on projektinne pointti ?
Miten se eroaa pk-laskusta tai pupesoftista ? Pupe on vähän isompi kokomaisuus, mutta ero pk-laskuun ?
K.o kysymykset siksi, ettei ruutia tuhlattaisi toisen pyörän keksimiseen.
Toimivalle laskutussoftalle löytynee käyttäjiä. Tuossa yksi yksinyrittäjä manasi juuri Passelin uuden perusversion alimpaan suohon, siihen tulleiden heikennysten takia (Yrittävät myydä kalliimpaa versiotaan). Hyvällä laskutussoftalla potentiaalinen Ubuntun käyttäjä. ;D
Aktiivisuuttanne arvostaen
Ystävällisin terveisin
Jallu59
wanhempi yrittäjä
-
Mikä oikein on projektinne pointti ?
Vastaan vaikken olekaan missään tekemisissä projektin kanssa.
On tuossa ainakin se pointti kilpailijoihin verrattaessa että kaikki eivät pidä selainkäyttöliittymistä eikä selainkäyttöliittymää saa tehtyä käytettävyydeltään yhtä hyväksi kuin tavallista työpöytäohjelmaa. Jos ohjelmistoa tarvitsee käyttää vain yhdeltä koneelta niin selainkäyttöliittymä ei tuo käytännössä mitään etuja.
-
ja sekin, ett pupesoft on PALJON isompi eikä loppuun asti tuotteistettu. Se on tehty eräälle suomaiselle, kansainvälisesti toimivalle organisaatiolle eikä siksi sovellu läheskään kaiikien - vähänkään pienempien - yritysten käyttöön.
ja mainittu pk-lasku on kuulemma hankalampikäyttöinen kuin esim joku helppolasku, tai mikä se nyt olikaan se ikkaunaruutuun laitettava softa.
ja mun mielestäni, tärkein syy laskutussoftan saamiseksi ja tekemisen kannustamiseksi on HUUTAVA tarve, joka on pienempien toimijoiden suusta kuultu monen monta kertaa.
Sellanen oli jo tulossa talven ja kevään aikana, mutt tekijä on kadonnut, syystä tai toisesta, tietymättömiin ja kevään julkistus 'haudattiin' siksi kaikessa hiljaisuudessa.
Mutt siis projekti on todella kannustettava! Olisin mieluusti tukemassa hanketta jotenkin, jos on joku meille sopiva tapa.
-
Mikä oikein on projektinne pointti ?
Vastaan vaikken olekaan missään tekemisissä projektin kanssa.
On tuossa ainakin se pointti kilpailijoihin verrattaessa että kaikki eivät pidä selainkäyttöliittymistä eikä selainkäyttöliittymää saa tehtyä käytettävyydeltään yhtä hyväksi kuin tavallista työpöytäohjelmaa. Jos ohjelmistoa tarvitsee käyttää vain yhdeltä koneelta niin selainkäyttöliittymä ei tuo käytännössä mitään etuja.
Tuo on nimenomaan yksi pointti, firmassa jossa on vain yksi henkilö joka käsittelee laskutusasioita ei ole mielekästä
pystyttää koneelle LAMP-yhdistelmää ihan vain laskujen kirjoittamista varten. Se syö turhaan konetehoja.
Olen foorumilla aikaisemmin törmännyt keskusteluihin, joissa kaivataan jotain yksinkertaista laskutusohjelmaa.
Apua voi antaa myös muullakin tavalla kuin koodaamalla.
Voitte ideoida ominaisuuksia (ja jos viette sen pidemmälle tehdä ominaisuudesta tarkemmat speksit, eli mitä tarkkaan ottaen se ominaisuus tekee, hakeeko se tietoja vaikka asiakasrekisteristä jne...), käyttöliittymää tai.....
-
Katselin tuossa pikaisesti tuota pupesoftia ja se tosiaan näyttää olevan varsin järeä toiminnanohjausjärjestelmä. Ehkä tosiaan liiankin järeä monelle pienelle yritykselle. Toisaalta kuitenkaan en näe järkeä siinäkään, että yrityksen taloushallinto koostuu useasta pikkusoftasta, jotka eivät mitenkään integroidu keskenään. Näkisin, että finlasku istuu parhaiten sellaisille yrittäjille, jotka tarvitsevat pientä ja näppärää laskutusohjelmaa, jollainen heidän työkalupakistaan puuttuu.
Työskentelen itse koodarina pienessä softafirmassa, jonka "toiminnanohjaus" koostuu "teimme itse ja säästimme web-käyttöisestä CRM:stä", työpöydällä pyörivästä kirjanpitosoftasta ja vielä erillisestä laskutussoftasta (ja ties mistä muusta). Laskuja lähtee kuukausittain vaivaiset kolmisenkymmentä. Tuon laskurumban läpivieminen joka kuukausi tuntuu vievän aikaa kokonaisen työpäivän. Tuollaisella laskumäärällä se on minusta aika paljon aikaa. Henkilökohtaisesti inhoan systeemeitä, joissa pitää samoja tietoja paukuttaa moneen kertaan eri softiin, jotta saa työnsä tehtyä.
Pointtini on siis se tilausta löytyy finlaskun kaltaiselle laskutussoftalle, mutta myös kevyt toiminnanohjausjärjestelmä vois myös löytää paikkansa. Ideana siis se, että siitä vois ottaa vain haluamansa ominaisuudet käyttöön ja jättää muut asentamatta. Olen mukana kehittämässä finlaskua, mutta voisin olla mukana kehittämässä myös järeämpää softaa.
-
Itse haluasin nähdä projektista valmistuvan hyvinkin nopeasti version jolla onnistuu laskujen tulostaminen, vaikka vain manuaalisesti syöttämällä joka kerta.
Mutta kuinka paljon on tarvetta standalone toiminnanohjausjärjestelmälle vai olisiko kyseessä jo sitten web-projekti.
Minulla ei ole mitään sitä vastaan jos projektissa finlaskusta kehittyy myös monipuolisempi työkalu kunhan tietty yksinkertaisuus ja helppokäyttöisyys säilyy.
finlaskuhan tulee pistämään laskut talteen sqllite-kantaan ja on opensourcea joten siltä kannaltahan kenenkä tahansa on helppo lähteä kehittämään samoja tietoja käyttävää kirjanpitosoftaa.
En lähde lupaamaan mitään kirjanpito-ohjelmaa ohjelmasta, koska projekti voi helposti paisua niin suureksi ettei tekijöillä ole mitään mahdollisuuksia saada valmista ennen viimeistä tuomionpäivää.
Ideoita otetaan vastaa kyllä myös kirjanpito ja toiminnanohjausjärjestelmän suuntaan, mutta tärkeintä on saada itse laskutus toimimaan. Ideat jotka parantavat finlaskun käyttömahdollisuuksia, käytettävyyttä jne... ovat enemmän kuin tervetulleita.
Esimerkiksi spark antoi oikein hyvää palautetta jota tullaan varmastikkin hyödyntämään projektin kehittämisessä.
-
ja sitt - älkää unohtako alv:ia ja sitä, että joillekin tuotteille ja palveluille alv on eri suuruinen ja paha juttu vielä - se vaihtelee myös joskus myyntitavan mukaan. Enkä suinkaan tarkoita pimeää enkä edes harmaata kauppaa... vaan kuka myy ja kenelle ja missä yhteydessä myy - palvelun kanssa vai ilman, jne...
-
Joo, itseasiassa alv on jo toteutettu.
Alv:n voi valita tuote/palvelukohtaisesti 22/17/8/0 prosentit.
Tuleeko mieleen jokin puuttuva prosentti?
-
Joo, itseasiassa alv on jo toteutettu.
Alv:n voi valita tuote/palvelukohtaisesti 22/17/8/0 prosentit.
Tuleeko mieleen jokin puuttuva prosentti?
Parasta olisi antaa käyttäjän määritellä ALV-prosentit.
Nythän on kovasti puuhattu ruoan arvonlisäveron alennusta. Olisi hyvä että arvonlisäveromuutoksen takia ei olisi pakko päivittää ohjelmaa uuteen versioon.
Ihan mielenkiinnosta kysyn vielä, että kuinka hyvä käsitys teillä ohjelmiston tekijöillä on laskutusohjelmistolle asetettavista teknisistä vaatimuksista ja tarpeista? Onko teillä aiempaa kokemusta laskutusohjelmiin liittyen joko käyttäjän tai kehittäjän näkökulmasta?
Onko teillä muuten jokin erityinen syy käyttää tietokantapohjaista datan tallennusta xml-serialisoitujen objektien sijasta? Oma tuntuma on että tietokantapohjaisuus tuottaa tässä turhaa monimutkaisuutta ilman että siitä on mitään käytännön hyötyä.
Ja nyt kun rupesin kyselemään niin kysytään vielä sekin että miksi luokan Invoice propertyn Rows tyyppi on muutettu IList<>:stä IDictionary<>:ksi? Versionhallinnan muutoshistoriasta ei löytynyt suoraan vastausta asiaan.
Älkääkä sitten koomatko desimaalien kanssa kun laskette arvonlisäveroa ja summia :)
-
Parasta olisi antaa käyttäjän määritellä ALV-prosentit.
Totta ja nopeasti toteutettavissa
Ihan mielenkiinnosta kysyn vielä, että kuinka hyvä käsitys teillä ohjelmiston tekijöillä on laskutusohjelmistolle asetettavista teknisistä vaatimuksista ja tarpeista? Onko teillä aiempaa kokemusta laskutusohjelmiin liittyen joko käyttäjän tai kehittäjän näkökulmasta?
Itse olen kirjoittanut osuuskunnan laskuja käyttäen excel-pohjaa. Mitään kokemusta laskutusohjelman kehittämisestä ei ole, mutta käsitys löytyy mitä laskulta vaaditaan.
Onko teillä muuten jokin erityinen syy käyttää tietokantapohjaista datan tallennusta xml-serialisoitujen objektien sijasta? Oma tuntuma on että tietokantapohjaisuus tuottaa tässä turhaa monimutkaisuutta ilman että siitä on mitään käytännön hyötyä.
Sekä SQLite ja xml oli harkinnassa, mutta päädyttiin SQLiteen. SQLitessä on jo valmiiksi mietitty suuri datamäärä, haut on helpomia ja se mahdollistaa helposti myös esim. raportointtien luonnin vaikkei kehittäjät olisi toteuttanut niitä. Tämä asia tietenkin voidaan xml:n osalta kiertää LINQ:n avulla. Datan tallennusmuoto on kuitenkin helppo vaihtaa mikäli tarvetta tulee.
Ja nyt kun rupesin kyselemään niin kysytään vielä sekin että miksi luokan Invoice propertyn Rows tyyppi on muutettu IList<>:stä IDictionary<>:ksi? Versionhallinnan muutoshistoriasta ei löytynyt suoraan vastausta asiaan.
Suoralta kädeltä en muista syytä, mutta muistaakseni syynä oli se että alunperin valittu IList ei taipunut siihen mitä tarvittiin.
Täytyy selvästikkin muistaa kommentoida muutoksia tarkemmin, vaikkakin tähän mennessä koodi on ollut melkolailla itsensä selittävää.
Kiitos palautteesta.
-
Ihan mielenkiinnosta kysyn vielä, että kuinka hyvä käsitys teillä ohjelmiston tekijöillä on laskutusohjelmistolle asetettavista teknisistä vaatimuksista ja tarpeista? Onko teillä aiempaa kokemusta laskutusohjelmiin liittyen joko käyttäjän tai kehittäjän näkökulmasta?
Itse olen kirjoittanut osuuskunnan laskuja käyttäen excel-pohjaa. Mitään kokemusta laskutusohjelman kehittämisestä ei ole, mutta käsitys löytyy mitä laskulta vaaditaan.
Jos on tarvetta saada aktivoitua sellaisia forumin käyttäjiä joilla on asiantuntemusta muttei välttämättä osaamista ohjelmoinnin puolella niin projektia voisi olla hyvä mainostaa ohjelmointialueen lisäksi jollakin muullakin alueella (ja ohjata sieltä keskustelu tänne tai projektin omalle forumille). Samalla kannattaa painottaa että apua tarvitaan nimenomaan vaatimusmäärittelyjen tekemiseen eikä varsinaiseen ohjelmointiin.
Sekä SQLite ja xml oli harkinnassa, mutta päädyttiin SQLiteen. SQLitessä on jo valmiiksi mietitty suuri datamäärä, haut on helpomia ja se mahdollistaa helposti myös esim. raportointtien luonnin vaikkei kehittäjät olisi toteuttanut niitä. Tämä asia tietenkin voidaan xml:n osalta kiertää LINQ:n avulla.
En ole vielä hirveästi perehtynyt LINQ:n käyttöön mutta mielestäni se tasaa tilit aika pitkälle SQL:n kanssa jos ajatellaan hakujen tekemisen helppoutta. Puhdas objektirakenne ilman tietokannan vaatimia ylimääräisiä rakenteita ja kikkailuja on kehittämisen kannalta huomattavasti nopeampi ja joustavampi vaihtoehto. XML-muotoon tallennettu data on helposti luettavissa ja ymmärrettävissä. Nämä ovat tietysti vain omia mielipiteitäni.
Mitä tulee datamääriin niin palataan asiaan siinä vaiheessa kun ohjelmistoa käyttää joku jolla on kannassa yli 10.000 laskua :)
Datan tallennusmuoto on kuitenkin helppo vaihtaa mikäli tarvetta tulee.
Tämä tietysti riippuu täsmällisestä toteutustavasta, mutta väitän ettei vaihto tietokannan ja objektirakenteen välillä ole mikään yksinkertainen operaatio.
Ja nyt kun rupesin kyselemään niin kysytään vielä sekin että miksi luokan Invoice propertyn Rows tyyppi on muutettu IList<>:stä IDictionary<>:ksi? Versionhallinnan muutoshistoriasta ei löytynyt suoraan vastausta asiaan.
Suoralta kädeltä en muista syytä, mutta muistaakseni syynä oli se että alunperin valittu IList ei taipunut siihen mitä tarvittiin.
Siksi tuo tuntuikin hieman oudolta kun en keksinyt mihin sellaiseen IList ei olisi tässä taipunut mihin IDictionary taipuu. Äkkiseltään kuvittelisin että propertyn Rows tietorakenne on sellainen että järjestyksellä on merkitystä ja IDictionary on sen oletuksen kanssa täysin ristiriidassa.
Täytyy selvästikkin muistaa kommentoida muutoksia tarkemmin, vaikkakin tähän mennessä koodi on ollut melkolailla itsensä selittävää.
Tämä oli tuon kommentin toinen pointti. Hyvä että osasit poimia sen rivien välistä :)
-
En ole vielä hirveästi perehtynyt LINQ:n käyttöön mutta mielestäni se tasaa tilit aika pitkälle SQL:n kanssa jos ajatellaan hakujen tekemisen helppoutta. Puhdas objektirakenne ilman tietokannan vaatimia ylimääräisiä rakenteita ja kikkailuja on kehittämisen kannalta huomattavasti nopeampi ja joustavampi vaihtoehto. XML-muotoon tallennettu data on helposti luettavissa ja ymmärrettävissä. Nämä ovat tietysti vain omia mielipiteitäni.
Kieltämättä LINQ tekee tuosta XML-vaihtoehdosta entistä houkuttelevamman. Pitää tutkia sitä lisää. Ei tarttis alkaa kantaa väkertämään ja ylläpitämään. :) Lähinnä jonkun fiksun ORM:n käyttäminen vois vähentää kannasta
johtuvaa kikkailua, mutta sellainen taas kuulostaa vähän overkilliltä tuon kokoisessa projektissa. Samassa ajassa, kun säätää esmes NHibernaten tohon niin tekis jo XML:n serialisointiin pohjaavan ratkaisun. Tota datan tallennusta vois olla syytä miettiä vielä uudelleen, nyt kun siihen ei ole vielä juuri mitään tehty ja kelkan kääntäminen on vielä helppoa jos XML:ään päädytään.
Tämä tietysti riippuu täsmällisestä toteutustavasta, mutta väitän ettei vaihto tietokannan ja objektirakenteen välillä ole mikään yksinkertainen operaatio.
Ei tuo mikään ylipääsemättömän vaikeakaan operaatio ole. Niin kauan kun "domain"-objekteihin ei tule suuria muutoksia niin päästään suhteellisen helpolla.
Siksi tuo tuntuikin hieman oudolta kun en keksinyt mihin sellaiseen IList ei olisi tässä taipunut mihin IDictionary taipuu. Äkkiseltään kuvittelisin että propertyn Rows tietorakenne on sellainen että järjestyksellä on merkitystä ja IDictionary on sen oletuksen kanssa täysin ristiriidassa.
Kieltämättä toi IDictionary<>-ratkaisu näyttää omituiselta. Sillä ei tosiaan tuossa tapauksessa saavuteta mitään mihin IList<> ei olisi kyennyt. Pitää fiksata toi tänään rumentamasta maisemaa.
-
Itseasiassa ubuntu-fi.org on tähän mennessä ainoa paikka jossa ollaan projektia mainostettu.
Siis halutaan apua niin vaatimusmäärittelynkin kanssa (muutoin ohjelmaan todennäköisesti päätyy vain ihan perusominaisuudet),
graafikoiden apua arvostetaan ja myöskin ihan koodareitakin otetaan mukaan.
Siis otetaan vastaan apua aika ympäripyöreästi :P
Mikäli yritysohjelmien tekeminen saa tuulta purjeidensa alle, en ole varma olisiko kuitenkin fiksua jonkun tehdä oma
projekti kirjanpito-ohjelmalle ja toiminnanohjaukselle vai ympätä kaikki mukaan samaan projektiin.
Projektin google-code sivuilta löytyy raakiletta käyttöliittymästä. Myös tämän suhteen on hyvä antaa ehdotuksia.
-
Lähinnä jonkun fiksun ORM:n käyttäminen vois vähentää kannasta johtuvaa kikkailua, mutta sellainen taas kuulostaa vähän overkilliltä tuon kokoisessa projektissa.
Se ei myöskään kuulosta KISS-periaatteen (http://en.wikipedia.org/wiki/KISS_principle) mukaiselta.
Tota datan tallennusta vois olla syytä miettiä vielä uudelleen, nyt kun siihen ei ole vielä juuri mitään tehty ja kelkan kääntäminen on vielä helppoa jos XML:ään päädytään.
Jos XML:ään päädytte niin siinä sitten on taas useampi vaihtoehto toteutukseen, mikäli Mono tarjoaa saman määrän vaihtoehtoja kuin Microsoft: automaaginen serialisointi XmlSerializer:n avulla, käsin tehty serialisointi IXmlSerializable-rajapinnan kautta tai data contract serializerin käyttö. No, viimeinen vaihtoehto ei välttämättä sovellu tähän joten valinta on lähinnä kahden ensimmäisen välillä ja nekin voi sotkea ristiin tarpeen mukaan.
Tämä tietysti riippuu täsmällisestä toteutustavasta, mutta väitän ettei vaihto tietokannan ja objektirakenteen välillä ole mikään yksinkertainen operaatio.
Ei tuo mikään ylipääsemättömän vaikeakaan operaatio ole. Niin kauan kun "domain"-objekteihin ei tule suuria muutoksia niin päästään suhteellisen helpolla.
Jo pelkkä tietokannan vaatima id-kikkailu lisää ylimääräistä tauhkaa jota ei suurimmaksi osaksi tarvita puhtaassa oliorakenteessa. Esimerkiksi järjestetty lista ja sen hallinnoiminen on relaatiotietokannassa hirveä hässäkkä verrattuna puhtaaseen oliorakenteeseen.
Tietenkään tuon hässäkän ei tarvitse näkyä koko koodiin vaan se on voitu piilottaa rajapintojen taakse, mutta sen toteuttamiseksi on joka tapauksessa pitänyt kirjoittaa varsin kohtuullinen määrä koodia. Kunnollinen piilottaminen vaatii kuitenkin kurinalaisuutta ja kärsivällisyyttä, joten yleensä tietokannan käyttö heijastuu myös muualle ohjelmaan.
-
Siis halutaan apua niin vaatimusmäärittelynkin kanssa (muutoin ohjelmaan todennäköisesti päätyy vain ihan perusominaisuudet),
Tuo olisi minullakin suurin ongelma jos itse tekisin vastaavaa projektia.
[...] ja myöskin ihan koodareitakin otetaan mukaan.
Ensiksi vaihdatte versiohallinnan johonkin oikeasti toimivaan (lue: git) niin ulkopuolinen kiinnostus voi nousta huomattavasti.
Mikäli yritysohjelmien tekeminen saa tuulta purjeidensa alle, en ole varma olisiko kuitenkin fiksua jonkun tehdä oma projekti kirjanpito-ohjelmalle ja toiminnanohjaukselle vai ympätä kaikki mukaan samaan projektiin.
Minusta noita ei kannata ympätä yhteen.
Ensiksi kannattaa tehdä yksi ohjelma mahdollisimman hyvin. Kun tulee aika kirjoittaa projekti puhtaalta pöydältä uusiksi niin silloin voi miettiä pitääkö iteroida uudelleen laajentamatta vai onko homma niin hyvin hanskassa että mukaan voisi ottaa uusiakin ulottuvuuksia.
Samoin kirjanpito-ohjelman lähtisin tekemään pelkästään puhtaana kirjanpito-ohjelmana. Tavoitteeksi sillä puolella voisi ottaa Tappio (http://www.lahdenniemi.fi/jussi/tappio/):n pieksemisen. Sellaisellekin ohjelmalle olisi kysyntää.
Missään tapauksessa ei kannata alkuun haukata liian isoa palaa vaan kannattaa tehdä ensiksi jotain suhteellisen yksinkertaista ja pientä. Kun se toimii kunnolla ja luotettavasti niin siitä voi sitten lähteä laajentamaan.
Tässä mielessä laskutustakin kannattaa lähteä tekemään ensiksi mahdollisimman yksinkertaisesti eikä välttämättä olisi huono jos alkuun tekisi proof-of-concept -projektin jossa dialogiin täytetään laskun tiedot ja sen jälkeen laskun voisi tulostaa (ja mahdollisesti tallentaa tiedostoon). Jos tämänkin projektin tekisi kunnolla niin siitä voisi olla jo apua monille vähäisiä määriä laskuja kirjoittaville. Samalla olisi luotu pohja varsinaiselle laskutusohjelmalle ja esimerkiksi laskun tulostamiseen tarvittava koodi olisi jo valmiina.
Minulla ei muuten ole mitään kokemuksia GTK#:sta mutta jos siinä jokin Forms:n databindausta vastaava ominaisuus niin opetelkaa sen käyttö. Se säästää paljon vaivaa ja turhaa koodaamista.
-
Joo, täytyy saada löytää fiksuin tapa tulostaa monossa ja silloin toi jo täytyy.
Tällä hetkellä ohjelman raato osaa laskea alvit jne... jo syötetystä datasta.
-
Mistäs näitä nyt putkahtaa :)
Ensin tuli kirjanpito ja nyt laskutus...
Juu, kyllä näille stand-alone paketelle on selkeä tilaus ollut molemmissa eli sellaisissa jotka eivät edellytä LAMPun asennusta eivätkä ole mitään erppejä vaan
tekevät juuri tuon mitä sanovatkin eli kirjanpidon ja laskutuksen.
-
Tervehdys lämmin!
Hienolta näyttää ja valmiin version voisin vaikka ottaa kokeiluunkin, miksen voisi testailla jo kokeiluversiotakin! ;D
Näyttää ulospäin aikatavalla sellaiselta jonka näin silmissäni joskus aikanaan kun sopivaa laskutusohjelmaa visioin vaan jota en ohjelmointitaidottomana osannut toteuttaa! :D
Olen yhden miehen yritys (terapeutti) ja laskutukseni on hyvin yksinketaista mutta totta vieköön tuo helpottaisi kyllä laskujen tekemistä ainakin osan laskutuksen kannalta (lähinnä yksityishenkilöiden) vaan ei sitten yhden isomman laskujen maksajan eli KELA:n, niillä on oma laskupohja ja erillinen tilityskin täytetään vielä siihen päälle! ;)
Täällä hetkellä laskutukseni toimii siten että laskupohjat on OO Writerilla ja laskutustiedot (eli asiakkkaan terpiakäynnit hintoineen) Calc:lla, josta siirrän ne laskupohjalle ja tulostan sitten. Sitten vielä kirjaan laskutustiedot erilliseen calc-tiedostoon.
Joten toden totta juuri tuollaista ohjelmaa olen kaivannutkin, joten kannustusta löytyy ainakin täältä! :D Hienoa!
valoisin kevätterveisin junnuh
-
Olemme Teemun kanssa miettineet miltä laskutuspohjan tulisi näyttää ja haluaisimmekin kysyä teiltä mielipidettä.
Kysymys kaikessa ytimekkyydessään kuuluu: Tilisiirto-lomakkeella vai ilman?
-
Tämä vaikuttaa ihan hyvältä projektilta. Oletteko ajatelleet ottaa mallia suositusta Passeli-ohjelmistosta? Siis sen perustoiminnoista ilman mitään plakiointia. Onko vastaavia ilmaisia laskutusohjelmia Linuksille muuten olemassa englanniksi kuinka paljon? Semmoisenhan voisi kääntää suomeksi, jos tarpeeksi hyvä löytyy.
-
Kysymys kaikessa ytimekkyydessään kuuluu: Tilisiirto-lomakkeella vai ilman?
Lomakkeen kanssa.
-
Kysymys kaikessa ytimekkyydessään kuuluu: Tilisiirto-lomakkeella vai ilman?
Lomakkeen kanssa.
Tilisiirtolomake-esimerkin saat lähimmästä Pankistasi tai ainkin kaupunkisi pääpankista. Niin ainakin luulisin, sillä itse sain sen kohteliaalta pankkineidiltä, kun tarvitsin sitä. Valitettavasti olen hukannut sen, joten en voi sulle lähettää sitä postissa.
Kannattaa kysyä opasta viivakoodin tai viitenumeron laskemiseen. ko. oppaassa oli molemmat.
Viivakoodia ei kannata laittaa ohjelmaan, sillä se ainakin silloin oli tulostinkohtainen. Tarvitsi vähintään 600 dpi:n laser-tulostimen. Esimerkki tulosteita piti lähetellä johonkin osoitteeseen, ennen kuin niitä sai lähetellä asiakkaille. Jokaisessa nykyaikaisessa tulostimessa on kyllä toi 600 dpi:tä, mutta toinen hankalampi vaatimus jää edelleen usein toteuttamatta. Ala-marginaalia ei saanut tulostin jättää kovinkaan paljoa. (En muista maximi marginaalia).
Näitä asioita tuskin kovin moni yksityisyrittäjä tietää, joten viivakoodi on parempi jättää kokonaan pois.
-
Tilisiirtolomake-esimerkin saat lähimmästä Pankistasi tai ainkin kaupunkisi pääpankista. Niin ainakin luulisin, sillä itse sain sen kohteliaalta pankkineidiltä, kun tarvitsin sitä. Valitettavasti olen hukannut sen, joten en voi sulle lähettää sitä postissa.
Kannattaa kysyä opasta viivakoodin tai viitenumeron laskemiseen. ko. oppaassa oli molemmat.
Tilisiirto-opas (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=21398&sec=&ext=.pdf) (pdf)
Laskua koskevat vaatimukset arvonlisäverotuksessa (http://www.vero.fi/nc/viewarticle.asp?article=2423&language=FIN) (html)
Suomalaisten tilinumeroiden rakenne ja tarkiste (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=11347&sec=&ext=.pdf) (pdf)
Viitenumero ja viitenumeron tarkisteen laskenta (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=24400&sec=&ext=.pdf) (pdf)
Kansainvälinen tilinumero IBAN (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=11312&sec=&ext=.pdf) (pdf)
Kansainvälinen maksulomake IPI (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=11344&sec=&ext=.pdf) (pdf)
Pankkiviivakoodistandardi (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=11338&sec=&ext=.pdf) (pdf)
Katsokaakin että viitenumero on ryhmitelty oikein viiden numeron ryhmiin oikealta katsottuna ja ilman etunollia.
Viivakoodia ei kannata laittaa ohjelmaan, sillä se ainakin silloin oli tulostinkohtainen.
Höpö, höpö... Viivakoodia ei missään tapauksessa kannata jättää toteuttamatta mutta se on syytä laittaa valinnaisena. Ensimmäistä kertaa käyttöön otettaessa käyttövaatimuksista voi näyttää dialogin ja samalla kysyä tulostetaanko tarkistukseen lähetettävät koelaskut samantien.
-
Höpö, höpö... Viivakoodia ei missään tapauksessa kannata jättää toteuttamatta mutta se on syytä laittaa valinnaisena. Ensimmäistä kertaa käyttöön otettaessa käyttövaatimuksista voi näyttää dialogin ja samalla kysyä tulostetaanko tarkistukseen lähetettävät koelaskut samantien.
Toi on hyvä idea. Eipä itellä tullu silloin ko. mieleen.
-
Viivakoodia ei missään tapauksessa kannata jättää toteuttamatta mutta se on syytä laittaa valinnaisena. Ensimmäistä kertaa käyttöön otettaessa käyttövaatimuksista voi näyttää dialogin ja samalla kysyä tulostetaanko tarkistukseen lähetettävät koelaskut samantien.
Toi on hyvä idea. Eipä itellä tullu silloin ko. mieleen.
Luulenpa että suurimmassa osassa laskutusohjelmia viivakoodi tulostetaan ilman että käyttäjää valistetaan millään tavalla sen käyttöön liittyvistä vaatimuksista. Minullekaan ei luultavasti olisi tullut mieleen tuo käyttäjän valistaminen jollet sinä olisi ensin ollut ehdottamassa koko ominaisuuden pudottamista käyttäjien tietämättömyyden takia. Siitä sitten tuli mieleen tuo koelaskujenkin tulostaminen suoraan ohjelman puolesta.
Koelaskujen tulostuksen pitäisikin itseasiassa olla ihan valikoista löytyvä toiminto koska laskuille saatava hyväksyntä on tulostinkohtainen ja uuden tulostimen hankinnan jälkeen koelaskut pitää tulostaa ja lähettää uudelleen tarkistettavaksi.
-
Tämä vaikuttaa ihan hyvältä projektilta. Oletteko ajatelleet ottaa mallia suositusta Passeli-ohjelmistosta? Siis sen perustoiminnoista ilman mitään plakiointia. Onko vastaavia ilmaisia laskutusohjelmia Linuksille muuten olemassa englanniksi kuinka paljon? Semmoisenhan voisi kääntää suomeksi, jos tarpeeksi hyvä löytyy.
Itse en ole törmännyt, ja veikkaisin ettei kovin moni muukaan foorumilainen.
Toinen ongelma joka asiaan liittyy on kansalliset säädökset miltä laskun tulee näyttää.
Viivakoodia ei missään tapauksessa kannata jättää toteuttamatta mutta se on syytä laittaa valinnaisena. Ensimmäistä kertaa käyttöön otettaessa käyttövaatimuksista voi näyttää dialogin ja samalla kysyä tulostetaanko tarkistukseen lähetettävät koelaskut samantien.
Toi on hyvä idea. Eipä itellä tullu silloin ko. mieleen.
Totta
Luulenpa että suurimmassa osassa laskutusohjelmia viivakoodi tulostetaan ilman että käyttäjää valistetaan millään tavalla sen käyttöön liittyvistä vaatimuksista. Minullekaan ei luultavasti olisi tullut mieleen tuo käyttäjän valistaminen jollet sinä olisi ensin ollut ehdottamassa koko ominaisuuden pudottamista käyttäjien tietämättömyyden takia. Siitä sitten tuli mieleen tuo koelaskujenkin tulostaminen suoraan ohjelman puolesta.
Varmaankin peruskysymyksiä onko vastuu ohjelman tekijällä, joka ei informoi käyttäjää vai laskujen lähettäjällä.
Joka tapauksessa ihan hyvä idea, asian informoinnin voisi yhdistää vaikka jonkinlaiseen asetus-wizardiin joka suoritetaan ensimmäisellä käynnistyskerralla.
Koelaskujen tulostuksen pitäisikin itseasiassa olla ihan valikoista löytyvä toiminto koska laskuille saatava hyväksyntä on tulostinkohtainen ja uuden tulostimen hankinnan jälkeen koelaskut pitää tulostaa ja lähettää uudelleen tarkistettavaksi.
Onko tietoa tarvitseeko olla yritys, jotta voi lähettää koelaskuja testattavaksi vai voinko itse postittaa heti kun olen saanut ensimmäisen
version ohjelmasta tehtyä? Itselläni on 600dpi värilaser joten...
Mitenkäs muuten mustesuihkut? Kyllähän nekin nykyään kykenee aika tarkkaan jälkeen.
-
Varmaankin peruskysymyksiä onko vastuu ohjelman tekijällä, joka ei informoi käyttäjää vai laskujen lähettäjällä.
Vastuu on laskun lähettäjällä, mutta fiksu ohjelma neuvoo käyttäjäänsä toimimaan oikein.
Joka tapauksessa ihan hyvä idea, asian informoinnin voisi yhdistää vaikka jonkinlaiseen asetus-wizardiin joka suoritetaan ensimmäisellä käynnistyskerralla.
Se kuulostaa järkevältä paikalta tuon tekemiseen.
Onko tietoa tarvitseeko olla yritys, jotta voi lähettää koelaskuja testattavaksi vai voinko itse postittaa heti kun olen saanut ensimmäisen version ohjelmasta tehtyä? Itselläni on 600dpi värilaser joten...
En muista näin suoralta kädeltä. Tuohon liittyvät asiat on kerrottu aiemmin linkkaamassani viivakoodiohjeessa.
Mitenkäs muuten mustesuihkut? Kyllähän nekin nykyään kykenee aika tarkkaan jälkeen.
Pankkiyhdistyksen ohjeissa ei muistaakseni hyväksytä mustesuihkutulostimia. Syyksi taidettiin mainita lähinnä tulostusjäljen tarkkuus mutta myös tulostusjäljen säilyvyys voi olla yksi syy miksi vain lasertulostimet hyväksytään.
-
Tilisiirto-opas (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=21398&sec=&ext=.pdf) (pdf)
Laskua koskevat vaatimukset arvonlisäverotuksessa (http://www.vero.fi/nc/viewarticle.asp?article=2423&language=FIN) (html)
Suomalaisten tilinumeroiden rakenne ja tarkiste (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=11347&sec=&ext=.pdf) (pdf)
Viitenumero ja viitenumeron tarkisteen laskenta (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=24400&sec=&ext=.pdf) (pdf)
Kansainvälinen tilinumero IBAN (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=11312&sec=&ext=.pdf) (pdf)
Kansainvälinen maksulomake IPI (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=11344&sec=&ext=.pdf) (pdf)
Pankkiviivakoodistandardi (http://www.pankkiyhdistys.fi/asp/ida/download.asp?prm1=wwwuser_fkl&docid=11338&sec=&ext=.pdf) (pdf)
Jaa, Pankkiyhdistys on miltei osannut skodata toimivan dokumenttien lataussivun, vinkuu jostain session kuolemisesta, kun noita yrittää himoita. Pitää kaivaa ne muuta kautta.
-
Lähtisin laskutusohjelmasta Asiakas -> Sopimus -> Kulukoodit -ajattelusta. Näin laskutusohjelma sisältäisi asiakkaisiin liittyvät perustiedot ja tiedollinen viite-eheys säilyisi ylläpidettävänä.
Minusta laskutusohjelman, jotta se sopisi mahdollisimman monelle, pitäisi olla joustavasti parametroitavissa. Ainakin tässä yhteydessä tulee mieleen, että laskutettavia kohteita pystyisi luomaan ja antamaan niille erinäisiä hintoja. Käytännössä tämä tarkoittanee sitä, että loppukäyttäjä voisi tuottaa itse laskutukseen liittyviä kulukoodeja, kiinnittää ne sopimuksille, jolloin sopimukset olisivat asiakkaille. Näin lähtökohtana olisi, että laskutusohjelma hanskaisi asiakkaat ja niihin liittyvät sopimukset joista syntyisi sitten laskutusperusteet.
Jokainen laskutustapahtuma pitäisi esiintyä ohjelmassa omana rivinään ja niitä voisi muokata siten että niistä jäisi tapahtumalogi seurantaa varten.
Liittymät olisivat hyvä olla valmiina, lienee olemassa jotain standarteja näihin joilla se toimisi.
Parista tällaisesta on kokemuksia, pyörivät edelleen tuotannossa.
-
Jaa, Pankkiyhdistys on miltei osannut skodata toimivan dokumenttien lataussivun, vinkuu jostain session kuolemisesta, kun noita yrittää himoita. Pitää kaivaa ne muuta kautta.
Katos perkule.
Pääsivulta (http://www.pankkiyhdistys.fi/) valitsee ylhäältä "Julkaisut ja tilastot" ja sitten vasemmalta "Oppaat, ohjeet ja malliehdot" ja sitten keskeltä "Tilisiirto ja lomakkeet" niin pääsee samoihin dokumentteihin käsiksi.
-
Törmäsin tähän finlasku ohjelmaan sattumalta.
Mielessä on ollut myös alkaa toteuttamaan vastaavaa ohjelmaa, mutta näköjään sille ei aivan välittömästi ole tarvetta kun kerta vastaava on jo menossa.
Tuoterekisteri olisi ehdoton lisäys jo melko alkuvaiheessa, itse esim käytän paljon vakionimikkeitä (autohuolto, tarvikkeet, tuntiveloitus, yms) joita ei aina jaksaisi kirjoittaa. Helpompaa valita listasta(tai kirjoittaa lyhyt koodi) ja tämän jälkeen määrä ja asiakkaan mukaan alennus % taikka naputella määrätty summa muuna myyntinä.
Puusilmänä tähän aikaan ei tuo ohjelman svn:stä löytyvän version kääntäminen onnistunut. Olisikohan mahdotonta saada lyhyt tiivistelmä vaikka tuonne google codesin wikiin asentamisesta/kääntämisestä?
Projektia miettiessä mielessä on pyörinyt erillinen tietokanta(sqllite?) ja asiakas ohjelmaa, jolloin yhteyttä voisi ottaa myös tarvittessa tienpäällä internetin ylitse ja tulostaa laskun/käteiskuitin näppärästi vaikkapa asiakkaan luona kotikäynnillä taikka kannettavalla toisella paikkakunnalla kokonaan..
Voisin osallistua ainakin testaamiseen yrittäjän ominaisuudessa sekä jossain määrin myös ehkä ohjelmalliseenkin kehittämiseen..
-
Ohjelmaa ollaan kehitetty monodevelop nimisellä idellä (http://monodevelop.com/ tai asentaa apt-getillä).
Sen saa sillä auki ja käyntiin. Myöhemmässä vaiheessa voidaan tehdä ehkä skripti jolla sen saa käännettyä...
Tarkemmat ohjeet voisin tehdä kunhan pääsen pois työpaikalta ja takaisin linuxin ääreen.
-
Koskas tästä on odotettavissa ladattava versio?
-
Varmaankin heinäkuun loppupuolella voisi olla saatavilla ominaisuuksiltansa ei-täydellisen version alpha.
-
Kiva. Tuleeko koodi myös sitten sivuille, jotta sitä voisi päästä käpistelemään?
-
Kiva. Tuleeko koodi myös sitten sivuille, jotta sitä voisi päästä käpistelemään?
Siellähän se on versiohallinnassa: http://code.google.com/p/finlasku/source/checkout (http://code.google.com/p/finlasku/source/checkout).
-
Se päätteestä kääntäminen jos ei halua käyttää monodevelopia pitäisi mennä tyyliin:
gmcs Main.cs -pkg:gtk-sharp-2.0Tämän jälkeen jos haluaa sen päälle niin komennolla mono <nimi>.exe
Suosittelen kuitenkin käyttämään monodevelopia....
-
Ḿiksi äänestys on suljettu? Laskutusohjelmia tarvitaan +1.
-
Onko projekti jo kuopattu ???
Ei ole ainakaan mitään päivityksiä sivuille tullut.
-
Joo tiedän että valitettavasti päivityksiä ei ole tullut, mutta projekti ei ole kuitenkaan kuopattu.
Yritän ehtiä tekemään lähipäivinä projektia.
-
Mainostetaan nyt vähän tuota projektia:
http://code.google.com/p/finlasku/
Kyseessä on siis uusi projekti joka pyrkii tekemään laskutusohjelmaa linuxille,
projektilla on nyt myös keskustelua varten luotu groupsi googleen:
http://groups.google.com/group/finlasku mutta pyrin seuraamaan myös täällä muodostuvaa keskustelua.
Communityn apua kaivataan niin ideoimisessa kuin koodaamisessakin.
Toi projekti on tehty monon päälle, joten sen pitäisi kohtuu ongelmitta kääntyä myös
windowsille ja macillekkin mutta tarkoitus on kuitenkin luoda viimekädessä yksinkertainen laskutusohjelma linuxille.
Tein aikoinani (1990-luvulla) lopputyönä oppilaitoksessa eräälle yrittäjälle varastonseurantaohjelman. Taisi olla Delphillä tehty. Laskutusohjelman olen tehnyt Excelillä (simppeli versio). Todella vaativampaa laskutusohjelmaa en ole koskaan tehnytkään joten en kyllä rohkene antaa kovinkaan paljon virka-apua tässä asiassa. Työni puolesta en myöskään juuri joudu tekemisiin laskutusohjelmien kanssa. Kovin mielelläni olisin avustanut tässä projektissa (esim. systeemisuunnitteluvaiheessa) mutta taitaa olla niin että tietämykseni modernien laskutusohjelmien suhteen on aika mitätön.
-
Osaisiko joku selittää lyhyesti ja ytimekkäästi, miten nuo selainpohjaiset laskutusohjelmat eroavat standalone-tyyppisistä?
Osaisiko kukaan suositella helposti käyttöön otettavaa laskutusohjelmaa. Törmäsin nimittäin kyseiseen seikkaan, kun yritin ottaa käyttöön goah-nimistä ohjelmaa: Lähes kaikkien tähän mennessä vastaan tulleiden laskutusohjelmien asennusprosessi on joko kryptinen, huonosti dokumentoitu tai molempia. Hyvän ohjelmiston tulee mielestäni olla helposti käyttöön otettava (helppo asentaa ja opetella käyttämään) ja toimia käytännössä, muussa tapauksessa edes ilmaisuus ei pelasta softaa täydelliseltä fiaskolta
Lisäksi hommalla alkaisi olla pahus soikoon kiire. Ei todellakaan ole juhlaa nakutella laskuja käsin tekemääni openoffice taulukkoon joka kerta kun niitä tulee! Voin osallistua ohjelmiston kehitykseen siinä, että olen herkkä epäselvyyksille, ja huomaan varmasti heti, jos jokin asia asennuksessa, käyttöliittymässä tms. ei kohtaa itseni kaltaista tyhmää peruskäyttäjää.
-
Osaisiko joku selittää lyhyesti ja ytimekkäästi, miten nuo selainpohjaiset laskutusohjelmat eroavat standalone-tyyppisistä?
Osaisiko kukaan suositella helposti käyttöön otettavaa laskutusohjelmaa. Törmäsin nimittäin kyseiseen seikkaan, kun yritin ottaa käyttöön goah-nimistä ohjelmaa: Lähes kaikkien tähän mennessä vastaan tulleiden laskutusohjelmien asennusprosessi on joko kryptinen, huonosti dokumentoitu tai molempia. Hyvän ohjelmiston tulee mielestäni olla helposti käyttöön otettava (helppo asentaa ja opetella käyttämään) ja toimia käytännössä, muussa tapauksessa edes ilmaisuus ei pelasta softaa täydelliseltä fiaskolta
Selainpohjaiset on siinä käteviä, että voit asentaa sen palvelimelle ja käyttää ohjelmaa vaikka internetin yli, eikä ole alustariippuvaisia käytön suhteen.
Noiden asennus (PKlasku) kaikkine lamppupalvelimineen on kyllä äkkinäiselle aika haastavaa, eikä asennusohjekaan ole parhaasta päästä.
http://pklasku.sourceforge.net/
-
Osaisiko joku selittää lyhyesti ja ytimekkäästi, miten nuo selainpohjaiset laskutusohjelmat eroavat standalone-tyyppisistä?
Selainpohjaiset on siinä käteviä, että voit asentaa sen palvelimelle ja käyttää ohjelmaa vaikka internetin yli, eikä ole alustariippuvaisia käytön suhteen.
Mikään ei estä etteikö tavallisena sovelluksena toimivassa laskutusohjelmassa voisi olla tukea keskuspalvelimella sijaitsevalle laskutietokannalle. Selainpohjaiseen verrattuna on tietysti se ero että offline-toiminnalle on helpompaa rakentaa kunnollinen tuki eli laskuja voidaan luoda ilman nettiyhteyttä ja tiedot voidaan päivittää palvelimelle silloin kun nettiyhteys on saatavilla. Selainpohjaisessa tarvitaan aina verkkoyhteys palvelimelle jollei palvelinta ole asennettu samalle koneelle. Jälkimmäisessä vaihtoehdossa tietysti menetetään selainpohjaisuuden merkittävimmät edut.
Sovelluksena toimiva laskutusohjelma voi aivan hyvin olla alustariippumaton. LIsäksi käyttäjäkokemus on yleensä parempi pienempien vasteaikojen ja parempien käyttöliittymäkomponenttien ansiosta.
-
Noh, ofline-työskentelyä tuo toiminta tuppaa olemaan suurimmaksi osin, eli nyuo selainpohjaiset olisi poisluettu laskuista samantien. Osaako kukaan suositella ei-selainpohjaista, normaalille ihmiselle suunnattua laskutusohjelmaa ,ei mitään yberlinuxnörtti asennusta kiitos, perus komentorivikikkailut sujuu kyllä, mutta ongelmatapaukset ovatkin sitten asia erikseen (virhe xyz: etpäs tiedäkkään miten tämä korjataan :P)
-
Vinkkejä? Ideoita? Onhan tuolla wikissä toki lista vaihtoehdoista, mutta kaipaisin käyttäjäkokemuksia. Moni kakku päältä kaunis, mutta onko yhtään simppelisti asennettavaa ja helposti käytettävää laskutussoftaa näköpiirissä?
-
Tuli muuten mieleeni, että onkos tähän finlaskuun tulossa kuittien automaattinen juokseva numerointi viiteiden tms. lisäksi??
-
Kunahn työkiireiltäni ehdin tekemään finlaskun perustoiminnot kuntoon niin tuotakin ominaisuutta voidaan miettiä.
Olen pahoillani projektin hitaasta etenemisestä mutta kunhan saan tämän kiirellisemmän deadlinen projektin alta pois alkaa varmaan
tämäkin etenemään taas nopeampaa tahtia.
Apua tietenkin otetaan vastaan ;)
-
Milläs kielellä tota nyt oltiinkaan koodaamassa? itse en osaa kuin C-tä, javaa, ja jonkin verran basicia. Oliko muulle kuin koodausavulle kysyntää?
-
Muullekkin kuin koodausavulle löytyy varmasti kysyntää, ehkä enemmän kun olen saanut tehtyä jo ubuntu-yhteisön ideoimat loistavat ehdotukset ;)
Ohjelmaa on kirjoitettu C# -kielellä.
-
Ei nyt mitenkään ollakseni ilkeä, mutta tuolla Google Coden sivulla on pieni kirjoitusvihre:
Project is done for Linux, but it will be made by mono and gtk#, so porting it to other plantforms should be easy.
Tuossa siis pitäisi olla platforms. :)
Tietysti apu se on pienikin apu. ;)
-
Totta ;)
-
ja toinenkin kielijuttu..."it will be made by mono and gtk#" eikö kuuluisi olla "it will be made with mono and gtk#" vai olenko nyt itse väärässä? :o :)
-
Taidat olla oikeassa ;)
-
Onkos projektissa mitään edistystä? Mikäli ohjelma ei ole vielä käyttökunnossa, pystyisikö joku suosittelemaan jotain jo valmista ja toimivaa laskutusohjelmaa?
-
Valitan myöhäistä vastausta, palasin juuri kertaamasta ;)
Tällä hetkellä ei ole suuria edistysaskelia, itselläni ei ainkaan ole tiedossa mitään muita kuin noita selaimessa pyöriviä jotka vaativat
www- ja tietokantapalvelimen asentamisen.
Enempää en kehtaa tässä vaiheessa edes sanoa, kyllä se vielä valmistuu^
-
Valitan myöhäistä vastausta, palasin juuri kertaamasta ;)
Tällä hetkellä ei ole suuria edistysaskelia, itselläni ei ainkaan ole tiedossa mitään muita kuin noita selaimessa pyöriviä jotka vaativat
www- ja tietokantapalvelimen asentamisen.
Enempää en kehtaa tässä vaiheessa edes sanoa, kyllä se vielä valmistuu^
Näin pienyrittäjänä, olen yrittänyt lueskella tätä, jos vaikka voisi työkoneeseenkin laittaa Linuxin? Laskutusohjelma on yksi ja pahin kompastuskivi. Käytän Passelin halvinta ja kuten tuossa aiemmin joku totesi, että on pakkomyyntiä laajempaan versioon. Minulle ja varmasti useammallekin riittää yhdelle koneelle asennettava ns ikkunaohjelma, johon saa asiakaskortiston, myynti/ työ kortiston, automaattisen viitenumeroinnin ja mielellään myös viivakoodin. Alvi prosentin voi määritellä itse ja sen voi vaihtaa esm työ suoritusten/ myynti kappaleiden välissäkin. Eli samassa laskussa voi olla useampaakin alv.ta . Logo on tietysti kiva. Perussettiin tulee siis yrittäjän tiedot, tyhjä tuote/ työ kortisto, Asiakaskortisto, sekä paikka jossa on laskua koskeva ilmoitusalue, mihin voi kirjoittaa lisäykset. Kone laskee alvit ja loppusummat, sekä antaa paikan joko yksittäiselle alennusprosentille, tai loppusummasta alennusprosentti.
-
En lukenut (pitkää) threadia, mutta mainitsen tässä serverille asennettavan (monen käyttäjän)
http://pklasku.sourceforge.net/
ohjelman.
Olen sitä joskus käyttänyt ja kokemukset olivat erittäin myönteisiä.
(Jos asentaa tuon niin kannattaa varmistua php:n version soveltuvuus.)
-
Onko tästä kuulunut mitään uutta?
Tarvetta ohjelmalle olisi. ::)
-
Ihan mielenkiintoinen projekti tuntuu olevan. Itsekkin olen miettinyt että onko linuxille minkälaisia laskutus / myyntireskontra ohjelmia saatavilla. Näin kesäloman aikana on heränny kiinnosotus open source pohjaisten ohjelmien koodailuun / kehittämiseen, vaikka koodaustaitoa ei vielä löydykkään kuin c++ ja java puolelta. Luultavasti aijon tänä kesänä tai syksyn aikana aloittaa jotain projektia, kunhan olen tutkinut asiaa enemmän.
-
Onko tästä kuulunut mitään uutta?
Tarvetta ohjelmalle olisi. ::)
Pahoittelen tätä erittäin pitkää vastausaikaa. Jotenkin missasin muutokset tässä threadissa aina tähän päivään asti.
Tällä hetkellä projekti on aika lailla "jäissä", sitä on ollut nyt työkiireitä siinä mittakaavassa (ja kun siihen ydistää illat wow:n parissa...), mutta yritän ottaa projektin taas kehityksen alle kesälomalla.
Ja tietenkin kyseessä on OS projekti niin jos löytyy koodaustaitoisia niin sitä voi lähteä viemään eteenpäin. Tällä hetkellähän se osaa tulostaa jonkinlaista grafiikkaa, taisi olla jopa simppeli laskupohja tehtynä. Joten peruslaskujen tekemisen (ilman kummempaa tallennusta) mahdollistavat toiminto olisi nopeahkostikkin tehtävissä.