Ubuntu Sverige

maccaddam skrev:

Farmfield skrev:Och sen undrar jag vad som skulle vara fel med Elicon? Att dom inte har ett 'normalt' gränssnitt som HOGIA, SPCS & co..? Det är väl funktionen som räknas och där verkar Elicon ligga längs fram.

Nej - det är inte funktioner som räknas, det användargränssnittet. Det ska inte vara svårare att fakturera än att surfa på Internet eller skriva något i ordbehandlaren. Dessutom ska förstås det fungera det som jag ska använda programmet till. Även om jag är elektriker eller lokalvårdare till exempel.

Det där hade jag missat... Men ett webgränssnitt är ju att surfa och gränsnittet är inte sämre utan ett webgränssnitt och känns därför annorlunda än ett program-GUI - men är inte sämre (var bara tvungen att upprepa mig)...

Bättre bokföringsprogram borde faktiskt vara ett måste tycker jag!

Många Windows användare använder sånt och då skall det finnas bättre i Ubuntu!

Eller vad tycker ni?

Ubuntu33 skrev:Bättre bokföringsprogram borde faktiskt vara ett måste tycker jag!

Många Windows användare använder sånt och då skall det finnas bättre i Ubuntu!

Eller vad tycker ni?

Jag vill bara upprepa mitt tidigare inlägg att GnuCash Finace Management, som finns med som alternativ i Ubuntu. har det mesta som behövs för många mindre företagare, fakturering, leverantörer, bokföring, grafik etc. Faktiskt delvis på svenska, men kan knappast användas av svenska företag förrän det utrustas med SIE-export, svensk kontoplan och lite till.

Försvenska GnuCash Finace Management och det blir ett utmärkt alternativ för sådär en halv miljon småföretagare!

maccaddam skrev:

Ubuntu33 skrev:Bättre bokföringsprogram borde faktiskt vara ett måste tycker jag!

Många Windows användare använder sånt och då skall det finnas bättre i Ubuntu!

Eller vad tycker ni?

Jag vill bara upprepa mitt tidigare inlägg att GnuCash Finace Management, som finns med som alternativ i Ubuntu. har det mesta som behövs för många mindre företagare, fakturering, leverantörer, bokföring, grafik etc. Faktiskt delvis på svenska, men kan knappast användas av svenska företag förrän det utrustas med SIE-export, svensk kontoplan och lite till.

Försvenska GnuCash Finace Management och det blir ett utmärkt alternativ för sådär en halv miljon småföretagare!

Men varför skulle det vara en bättre grund att arbeta i än JFS som redan är 'up to date' och har allt det du efterfrågar? Skall det läggas energi på något så är det väl bättre att den läggs på JFS?

farmfield skrev:

maccaddam skrev:

Ubuntu33 skrev:Bättre bokföringsprogram borde faktiskt vara ett måste tycker jag!

Många Windows användare använder sånt och då skall det finnas bättre i Ubuntu!

Eller vad tycker ni?

Jag vill bara upprepa mitt tidigare inlägg att GnuCash Finace Management, som finns med som alternativ i Ubuntu. har det mesta som behövs för många mindre företagare, fakturering, leverantörer, bokföring, grafik etc. Faktiskt delvis på svenska, men kan knappast användas av svenska företag förrän det utrustas med SIE-export, svensk kontoplan och lite till.

Försvenska GnuCash Finace Management och det blir ett utmärkt alternativ för sådär en halv miljon småföretagare!

Men varför skulle det vara en bättre grund att arbeta i än JFS som redan är 'up to date' och har allt det du efterfrågar? Skall det läggas energi på något så är det väl bättre att den läggs på JFS?

Att JFS delvis bygger på proprietära utvecklingsmiljöer? Bl.a. måste ant. hela användargränssnittet bytas ut förr eller senare, för att programvaran skall kunna fortsätta att utvecklas. Läs lite i tråden som Hund postade; det låter inte som att JFS är ett så lysande alternativ, annat än möjligtvis för stunden...

Jag tycker vi kör på HomeBank istället. Det där med dubbel bokföring är helt klart överkskattat .

djkmmo skrev:Men varför skulle det vara en bättre grund att arbeta i än JFS som redan är 'up to date' och har allt det du efterfrågar? Skall det läggas energi på något så är det väl bättre att den läggs på JFS?

Att JFS delvis bygger på proprietära utvecklingsmiljöer? Bl.a. måste ant. hela användargränssnittet bytas ut förr eller senare, för att programvaran skall kunna fortsätta att utvecklas. Läs lite i tråden som Hund postade; det låter inte som att JFS är ett så lysande alternativ, annat än möjligtvis för stunden...

Jag tycker vi kör på HomeBank istället. Det där med dubbel bokföring är helt klart överkskattat .[/quote]

Det är rätt. JFS använder prop Look and Feel (se min tråd på Linuxportalen, tidigare postad av Hund här). Den släppta källkoden saknar dessutom en del klasser, bland annat den som hade hand om licensen (produktnyckeln). Allt är skrivet med IntelliJ (?) som verkar vara en prop utvecklingsmiljö... Skall man få ordning på det krävs en hel del arbete. Jag har importerat JFS till Launchpad och jobbar med koden med Bzr, https://code.launchpad.net/~jonasbjork/+junk/jfs . Försöker få ordning på hur de har "tänkt" och försöker lista ut hur allt hänger ihop. Jag har varken IntelliJ IDEA eller Install4J tillgängligt, vet inte ens om det är open source... jag skulle vilja konvertera alltihopa till 100% Pure Java (Java 6) och bygga det med ant.. men där är vi inte än

Hur går det med detta? Har du haft möjlighet att gräva fram något mer jonas?

Jag har kollat lite på Gnucash nu med och jag vet inte riktigt om det håller måttet. Det jag reagerat över är att när jag lekt lite med programet så har jag utan problem kunnat ändra och ta bort transaktioner utan att det (vad jag kunnat se) lämnat ett spår efter sig. Jag tror inte att Skattemyndigheten skulle uppskatta om det verkligen är så att det går att ändra hur som helst (om de skulle få för sig att kolla). Däremot är det ju inte programeringsmässigt något svårt alls att lägga upp BAS-kontoplaner i Gnucash, men hur går det med SRU-kopplingar? Dessutom är det nog bra om det är någon som kan bokföring bra (redovisningskonsult eller revisor) kan finnas med som stöd, för att få alla konton rätt. Som budget/bokföringsprogram för privatpersoner som inte måste redovisa till någon tredje part, utan vill bokföra för att själv ha bättre koll på sin ekonomi så verkar Gnucash dock fylla måttet med råge.

För att hålla den här tråden vid liv så har jag kollat lite på det här med SIE och det verkar vara öppna och väldokumenterade filformat. Bland målsättningarna på http://www.sie.se så finns:

• Det ska vara lätt att skriva exporterande och importerande program i de flesta programmeringsspråk.
• Filerna ska ha en enkel uppbyggnad.
• Filformatet ska vara lätt att läsa utan speciell programvara.

Filerna är rena textfiler och går att läsa med t.ex. less (jag har testat med JFSAdmin). Alltså bör inte den delen vara svår att fixa till i GNUCash, förutsatt att min tidigare tveksamhet om ändring av bokföringsposter kan undanröjas.

Uppdatering 2008-12-23
Gnucash sparar alla filer, kontoplan och transaktioner etc, som xml-filer. För att få en fungerande SIE-export bör det alltså räcka med att transformera de filerna till SIE-format m.h.a. sed/awk. Alternativt så kan Gnucash både importera och exportera till från Quicken Interchange Format (QIF):

The Quicken interchange format (QIF) is a specially formatted text (ASCII) file that enables Quicken transactions to be moved from one Quicken account register into another Quicken account register, or to or from other programs that support the QIF format.

Med andra ord: samma sak som SIE-filer, men med annan formatering och ev. inte fullt ekvivalenta, men de grundläggande sakerna (kontoplan, transaktioner etc.) bör vara relativt enka att översätta.

Specifikation QIF-formatet

Kollar jag bara lite snabbt på den data som krävs i en SIE-exportfil så:
1. #FLAGGA - signalflagga lyckad export - Bör inte vara något problem
2. #PROGRAM - Vilket program som exporterat - Bör inte vara något problem
3. #FORMAT - Vilken teckenuppsättnings som använts - Bör inte vara något problem
4. #GEN - Vem har exporterat vid vilken tidpunkt - Bör inte vara något problem
5. #SIETYP- Vilket SIE-filformat exporten skett till - Bör inte vara något problem
6. #FNAMN - Företagsnamn - Bör inte vara något problem
7. #RAR - Räkenskapsår - Bör inte vara något problem
8. #KONTO - Kontonamn+nummer - Bör inte vara något problem
9. #IB- Ingående balans - Bör inte vara något problem
10. #UB- Utgående balans - Bör inte vara något problem

Det var de tio första och datan för alla dessa uppgifter finns i xml-filen och till viss del i de exporterbara QIF-filerna. Alltså bör det räcka att leta upp relevanta data i gnucash-filen och kopiera över till en *.SE-fil så är Bobby din farbror. Import av SIE-data till Gnucash kanske är klurigare?

Anledningen till att jag håller hoppet om Gnucash uppe är att jag dels tycker att det var riktigt lättarbetetat och trevligt och dels att jag tror att de saker som behöver fixas i Gnucash egentligen är ganska simpla. Om vi börjar med SIE-export och rätt kontoplan så ju det relativt enkla sak att fixa. Kontoplan lägger man ju själv upp i Gnucash och det går att exportera en "tom" kontoplan separat. Alltså handlar den delen bara om att sätta upp konton med rätt namn och konto-kod i Gnucash och exportera den, så kan vem som helst börja med en ren kontoplan för t.ex. K1-företag genom att utgå från den.

SRU-kopplingarna används ju egentligen bara vid rapporter som moms, årsbokslut etc, så det bör man ganska enkelt kunna skapa anpassade rapporter i Gnucash där man grupperar relevanta kontokoder för att passa SRU-koderna.

Av de tre saker som alltså behöver fixas kan två av delarna alltså fixas även av någon som inte är programerare (lägga upp kontoplan och fixa anpassade rapporter). Dock känner inte jag att jag vill plöja ner en massa tid på att sätta upp en riktig kontoplan och skapa rapporter om jag inte vet att någon med programeringskunskap tar tag i import/export-delen.

Är det någon som plockar upp handsken?

Som en sista kläm så tror jag också att Gnucash har bäst överlevnadsmöjlighet och utvecklingspotential. Redan idag finns det möjlighet för tyskar och amerikaner att t.ex. sköta sina bankaffärer genom Gnucash via OFX och HBCI. Om vi i sverige kommer att få samma möjlighet så kommer det ant. att följa HBCI-standarden, eftersom att tyskarna är långt framme på området och HBCI är de facto standard bland tyska banker. Standarden är f.ö. även öppen.

När jag började att titta på GnuCash var jag positivt överraskad av faktureringsdelen i programmet. Grunden för företagets verksamhet är fakturering - därför kan man börja med faktureringsbiten.

Däremot är faktiskt inte bokföringsdelen alls bra för svenska företag. Att det går att ändra en verifikationer är inte hela världen, det kan man i viss utsträckning göra i andra bokföringsprogram också. Att komplettera med en bas-kontoplan (se http://www.bas.se/ ) går nog också att fixa. Rapporter bör vara uppställda enligt europeisk standard, borde inte var alltför svårt. Momsrapport borde väl också gå att fixa.

Problemet som jag har med GnuCash bokföring är att jag inte lyckats skapa en numrerad post specifik för varje verifikation. Normalt får man upp en skärmbild för inmatning av text och kontering. Numreringen för verifikationerna ska vara löpande och ska inte gå att ändra.

Kontoplanen heter EU-bas vilket innebär att det finns gemensamma regler som gäller hela EU.Vilket innebär att det finns motsvarande önskemål inom andra EU-länder. Om man t ex i Holland gjort anpassningar av GnuCash är det (nästan) bara en ren översättning till svenska som behövs. Någon som kollat? (Det verkar som om GnuCash i nuvarande form är gjort för USA?)

maccaddam skrev:När jag började att titta på GnuCash var jag positivt överraskad av faktureringsdelen i programmet. Grunden för företagets verksamhet är fakturering - därför kan man börja med faktureringsbiten.

Däremot är faktiskt inte bokföringsdelen alls bra för svenska företag. Att det går att ändra en verifikationer är inte hela världen, det kan man i viss utsträckning göra i andra bokföringsprogram också. Att komplettera med en bas-kontoplan (se http://www.bas.se/ ) går nog också att fixa. Rapporter bör vara uppställda enligt europeisk standard, borde inte var alltför svårt. Momsrapport borde väl också gå att fixa.

Problemet som jag har med GnuCash bokföring är att jag inte lyckats skapa en numrerad post specifik för varje verifikation. Normalt får man upp en skärmbild för inmatning av text och kontering. Numreringen för verifikationerna ska vara löpande och ska inte gå att ändra.

Kontoplanen heter EU-bas vilket innebär att det finns gemensamma regler som gäller hela EU.Vilket innebär att det finns motsvarande önskemål inom andra EU-länder. Om man t ex i Holland gjort anpassningar av GnuCash är det (nästan) bara en ren översättning till svenska som behövs. Någon som kollat? (Det verkar som om GnuCash i nuvarande form är gjort för USA?)

Numrering finns (kolumn två i dagboksbladen). Det räcker t.om. att skriva "+" kolumnen så räknar Gnucash automatiskt uppåt. Dock är det samma sak som med resten av posten, det går också att ändra.

När det gäller faktureringen så är det ju väldigt praktiskt att få reskontrahanteringen smidigt integrerat i programet. Tar bort mycket av argumenten för kontantmetoden, i.a.f. v.g. bokföringen. Man behöver ju inte bokföra vid både fakturering och betalning då den senare bokföringen sköts automatiskt av programet. Det är ju enklare att hålla reda på vad som är betalat och inte också. Sökfunktionen verkar vara en god hjälp i det avseendet också. Det vore guld om vi hade kunnat göra som tyskarna också, få avstämmningen av betalat direkt online från banken.

Rent praktiskt kan jag hålla med dig om det här med möjligheten att ändra. Alla professionella bokföringsprogram har ju SIE-export och med det går det som sagt att få ut hela sin bokföring i rena textfiler, ändra i textfilerna och återimportera en "ren" bokföring. Så egentligen behöver man ju aldrig ha några rödmarkerade eller överstrukna poster, om man inte vill. Men rent formellt så får ju inte ett bokföringsprogram tillåta ändringar genom det vanliga användargränssnittet för att SKV skall godkänna det...

Tydligen finns det även viss skattefunktionallitet i Gnucash. Jänkarna har tydligen mycket mer jobb med sina skatter än vad vi är vana vid, så även privatpersoner måste hålla bättre koll. Det betyder i sin tur att man i Gnucash kan koppla skattekoder (i USA "TXF-koder") till sina konton. Detta borde i sin tur gå att använda för att även skapa svenska skattetabeller (SRU-koder) i Gnucash och koppla dessa till kontona.

F.ö. har jag iaf börjat lägga in en BAS-kontoplan i Gnucash nu (BAS-2009) och jag är uppe i konto 6000. Det blir en kontoplan för K1-företag utan branchanpassning (det får man själv anpassa efter egna behov).

@djkmmo

Skulle det inte vara en idé att skapa ett officiellt 'projekt' kring det du gör, komplett med uppföljning, buggrapporter & hela svängen, typ i LaunchPad eller dylikt..?

Ett bra bokföringsprogram är ju något som behövs och om koden bakom JFS inte duger så måste det ju till något annat, t.ex. en svensk modul för GnuCash.

Om du nöjer dig med funktioner för enskild firma - ladda hem en demo av enskild-firma-programmet från http://www.vismaspcs.se/, ett litet väldigt lättanvänt program med allt från faktura till deklaration. Där kan man hitta ideer som kanske kan tillämpas i GnuCash.

Det finns program där man kan ställa in olika alternativ, d v s tillåta ändringar i gamla verifikationer. Tack vare behandlingshistoriken är det fullt möjligt att tillåta denna mångsidighet. Behandlingshistoriken loggför alla bearbetningar, inklusive förändringar av dessa känsliga uppgifter, vilket omöjliggör okontrollerad manipulation.

Om behandlingshistorik säger lagen följande:
BFL5 kap11 § "…Företaget skall också upprätta sådana beskrivningar över genomförda bearbetningar inom systemet som gör det möjligt att utan svårighet följa och förstå de enskilda bokföringsposternas behandling (behandlingshistorik)…"

Det får ju vara ett system som fungerar med såväl det som HB och AB, annars känns det rätt meningslöst...

maccaddam skrev:Det finns program där man kan ställa in olika alternativ, d v s tillåta ändringar i gamla verifikationer. Tack vare behandlingshistoriken är det fullt möjligt att tillåta denna mångsidighet. Behandlingshistoriken loggför alla bearbetningar, inklusive förändringar av dessa känsliga uppgifter, vilket omöjliggör okontrollerad manipulation.

Om behandlingshistorik säger lagen följande:
BFL5 kap11 § "…Företaget skall också upprätta sådana beskrivningar över genomförda bearbetningar inom systemet som gör det möjligt att utan svårighet följa och förstå de enskilda bokföringsposternas behandling (behandlingshistorik)…"

Ja då är det kanske inga problem med Gnucash heller, det kanske kan anses följa BFL. Anledningen är att det sparas en full backupfil varje gång man sparar i programet. Eftersom att det är gzip:ade xml-filer så tar det inte mycket plats. Med diff borde man utan alltför mycket jobb kunna skapa en textlogg för dessa filer där bara förändringarna listas, exlusive det som sparats i huvudfilen. Har då någon bokföringspost tagits bort elelr ändrats så finns den kvar i loggen med datum för förändringen. Skulle det uppfylla BFL tror du?

farmfield: Det har du nog rätt i, men eftersom att jag inte kan programera så hoppades jag att någon med de kunskaperna skulle hänga på. Nu verkar en hel del kunna gå att fixa utan programeringskunskaper. Den som har lust kan ju sätta tänderna i skattetabellerna (/usr/share/gnucash/scm/txf.scm, med användarhjälpfil /usr/share/gnucash/scm/txf-help.scm). Jag vet inte hur lätt det är, för jag har inte provat, men om jag förstår det rätt från den påbörjade tyska anpassningen (tyskarna har precis som vi Umsatzsteuer (USt) = Moms) så ser det ut som att det enda som behövs är att lägga in svenska skattekoder och beskrivningar. Då Gnucash automatiskt använder sig av de tyskanpassade filerna om localen är satt till de_DE så kan man ju hoppas på att det enda som behövs är anpassningen och att döpa filerna till txf-sv_SE för att skatterna skall funka. Den biten är ju egentligen inget magiskt. Programet gör ju inga beräkningar utan specar bara siffrorna. Behöver man behandla dem efteråt så får man göra det själv. Men man får ju rätt belopp ur bokföringen att föra in på rätt plats i div. rapporter.

Sedan vet jag inte om det vad kontoplanerna du syftade på med HB/AB (antagligen inte, men jag svarar ändå ). Kontoplanen för K1-ftg (enskilda firmor, <3000KKr) är en subset av den fulla kotoplanen. Med utgångspunkt från K1-kontoplanen är det alltså bara att fylla på med de konton som krävs för KB/HB/AB. Själva kontostrukturen går dessutom enkelt att exportera/importera, så det är bara att börja med K1-kontoplanen, fylla på, exportera och ladda upp på något ställe där andra kan få del av dem (Launchpad?).

VismaSPCE kan säkert vara bra, men för min del så handlar det inte bara om vad som är mest praktiskt, utan också om vad som känns bäst och för mig skulle det kännas bäst med ett fritt bokföringsalternativ som vi har greppet om, är lätt att användaranpassa etc. Naturligtvis så spelar det praktiska en viss roll; hade det verkat som att Gnucash hade saknat i stort sett allt och hade krävt väldigt omfattande omarbetning på kodnivå så hade jag inte brytt mig om att göra något. Men jag tycker inte det verkar vara så. Dessutom så är det för mig ett bra sätt att lära mig bokföring på ett lite djupare plan och verkligen förstå BAS-kontoplanen etc.

Avslutningsvis ang. EU-BAS: Jag är inte helt säker på att de anpassningar vi gör här i Sveriga rakt av kan användas av t.ex. fransmän eller holländare. Om jag förstått det rätt så är EU-BAS en anpassning av de svenska BAS-kontoplanerna efter EU-inträdet, men om jag förstått det rätt så används inte BAS utanför Sverige. Med andra ord EU-BAS är som jag förstått det svenska BAS anpassad efter EU-regler, inte BAS-kontoplaner som används i EU. BAS-kontoplanerna är ju en helt svensk uppfinning. Se vidare här: http://www.ejnar.se/3747/globe/kontoplan.html
Däremot så visar vi ju med detta att det går att göra nationella anpassningar relativt enkelt och det kan väl ge programet en skjuts framåt även i andra språkområden. I min fördjupning har jag bl.a. hittat anpassningar för användning av Gnucash i Norge och det gjorde att jag tyckte att det var idé att fortsätta undersökningen för egen del. Kan norrmännen så kan väl vi.

Vad gäller min tanke på ett 'officiellt' projekt runt en svensk modul så krävs ju snarast en projektledare i första hand, programmerare och annan kompetens kan komma i andra hand. Frågan är väl om det är intressant nog? Så...

• Behövs det ett bokföringsprogram?
• Om ja, är GNUCash bästa utgångsläget för denna applikation?
  
  • Om nej, finns det andra program att utgå ifrån med bättre utgångspunkt?
• Om ja, hur mycket jobb behövs det för att få GNUCash i den klass som krävs?
• Är det över huvudtaget genomförbart?
  
  • Vilken kompetens behövs för att skapa en komplett applikation?
  • Behövs det finansiering?
  • Vem skulle vara intresserad av att finansiera?
• Tidsram?

Nu har jag följt era diskussioner ett tag och vill egentligen bara heja på! Om det blir ett projekt med att anpassa GNUCash till Svenska förhållanden (vilket jag tycker låter som en lysande idé) är jag beredd att bidraga med vad jag kan, vilket dessvärre varken är mycket om vare sig programmering eller bokföring. Det sistnämnda är jag dock i behov att lära mig och behöver också ett program för ändamålet varför jag med spänning följer denna tråd!

Behövs det ett bokföringsprogram?

.

För att Ubuntu ska någon som helst chans hos de mindre företagen - absolut. Det vill säga inte bara bokföring, framför allt fakturering med kund- och artikelregister, snygga fakturor etc. Många lämnar över själva bokföringen och deklarationen till sin redovisningskonsult.

Jag förmodar att ambitionsnivån för ett Ubuntu ekonomisystem är mindre företag i form av enskild firma, handelsbolag och aktiebolag.

Sedan skulle det vara kul om ekonomiprogrammet vore så bra att det i sin tur "sålde" Linux. Att det är gratis räcker ju inte, det finns ett antal gratis ekonomiprogram under Windows. Att det inte finns fler Linux på skrivbordet tror jag beror på att Linux, OpenOffice etc bara upplevs som medelmåttiga windowskopior. Att ni som är medlemmar i det här forumet kan peka på ett antal fördelar når knappast fram till den vanliga slutanvändaren.

För de större företagen, eller företag som vill köpa program och support, finns till exempel
Hansa (från cirka 800 kr till riktigt stora system),
Qwert Cyberstore AB som introducerar LINUX på skrivbordet, inklusive affärssystem. Qvert vill leverera en färdig burk med operativsystem och affärssystem samt
Garp som är en klient/server applikation och det är serverprogramvaran och databas som kan köras på Linux (Intel).

- Om ja, är GNUCash bästa utgångsläget för denna applikation?

Vid första påseendet verkade GnuCash vara ett bra alternativ under förutsättning att det gick lätt att anpassa till svenska förhållanden. Ju mer jag tittar på det tycker jag att det verkar svårarbetat. Det känns inte naturligt, man vet inte hur man ska använda det, och då och då kommer det upp konstiga meddelanden typ "This transaction is already being edited in another register. Please finish editing it there first." När rörmokarens hustru (hon som sköter papperen) efter 10 minuter inte begriper hur hon/han ska gå vidare, då väljer hon ett windowsprogram istallet.

- Om nej, finns det andra program att utgå ifrån med bättre utgångspunkt?

Jag har tittat lite på JFS, det har ju vad som behövs för ett mindre företag, ungeför samma som någon av de enklare varianterna av SPCS Administration. Utan några egentliga förkunspaker lyckades jag installera det under Ubuntu, också bra. De som tittat på koden bekymrar sig för kommande underhåll av programmet, vilket är viktigt. Jag har ingen aning om hur man kan göra för att säkerställa uppdateringar som då och då måste till för att följa nya lagar och skatter. Som kund vill jag förstås veta att programmet inte bli omodernt om ett år. Är det något som Ubuntu Sverige tar på sig?

Elikon kanske också kan vara intresserade?

- Vem skulle vara intresserad av att finansiera?

Snarare - det behövs en samarbetspartner typ revisorer, redovisningskonsulter. Kanske finns någon byrå inom Sveriges Redovisningskonsulters Förbund http://www.srfkonsult.se/ ?

maccaddam skrev:Elikon kanske också kan vara intresserade?

Dom lär knappast vara intresserade av att arbeta med ett gratisalternativ till deras egen kommersiella produkt, dock kan dessa möjligen vara intresserade av ett GUI för sitt system under GNU/Linux vilket ger deras system ett 'normalare utseende' då deras webinterface lär verka skrämmande. Elicons lösning tror jag annars är den i nuläget absolut bästa och motsvarar (både i pris och funktionalitet) enligt min far det system från Hogia han kör idag.

Ett säljargument för att köra t.ex. Elicon i GNU/Linuxmiljö är ju stabilitet och säkerhet samt (sett till Elicons system) möjligheten att accessa bokföringen utifrån, t.ex. via SSH - kanongrej för egenföretagande konsulter eller säljare som reser runt mycket t.ex...

maccaddam skrev:

Vem skulle vara intresserad av att finansiera?

Snarare - det behövs en samarbetspartner typ revisorer, redovisningskonsulter. Kanske finns någon byrå inom Sveriges Redovisningskonsulters Förbund http://www.srfkonsult.se/ ?

Det tror jag kan vara en väg att hitta intressenter att sponsra ett dylikt projekt - bra tänkt.

Dom lär knappast vara intresserade av att arbeta med ett gratisalternativ till deras egen kommersiella produkt

Anledningen till att de kan vara intresserade är det svar jag fick när jag mailade en fråga om installationen under Linux, då fick jag svaret:
"Dessvärre har jag tvingats till att driva Elicon på fritidsbasis tillsammans med två tidigare anställda. Vi arbetar med att åtgärda ett par kända fel. "

De var ju Elicon som tidigare utvecklade SPCS bokföring med flera åt SPCS. Elicon har råkat ut för samma problem som en tidigare utvecklare för SPCS, nämligen ekonomiprogrammet Topp, som på DOS-tiden var ett storsäljande program. Om det inte finns kanaler till marknaden så spelar det ingen roll hur bra programmet faktiskt är.

En programutvecklare som vill in på marknaden kan eventuellt vara intresserad av att en enklare gratisversion finns, med möjlighet för senare uppgradering som kostar pengar.