Laskutusohjelma linuxille

[henri_aleksi]

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.

[spark]

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?

[henri_aleksi]

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.

[spark]

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.

[henri_aleksi]

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ää....

[Jallu59]

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ä.

Aktiivisuuttanne arvostaen
Ystävällisin terveisin

Jallu59
wanhempi yrittäjä

[mgronber]

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.

[jake]

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.

[henri_aleksi]

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.....

[Ronko]

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.

[henri_aleksi]

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ä.

[jake]

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...

[henri_aleksi]

Joo, itseasiassa alv on jo toteutettu.
Alv:n voi valita tuote/palvelukohtaisesti 22/17/8/0 prosentit.
Tuleeko mieleen jokin puuttuva prosentti?

[mgronber]

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

[henri_aleksi]

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.

[mgronber]

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ä

[Ronko]

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.

[henri_aleksi]

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 

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.

[mgronber]

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 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.

[mgronber]

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: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.