Bokföringsprogram

[djkmmo]

Jag kan meddela att jag åtminstonne lyckats
*konvertera JFS till ett eclipseprojekt
*byta look and feel, till en icke proprietär variant och:
*lyckats kompilera och starta programmet genom att kommentera bort koden som frågar efter licensnyckel

Är du sann? Det är ju fantasktiskt bra! Betyder det att programet nu följer temainställningarna för Gnome/KDE?

Är det svårt att utbyta information mellan HSQL och MySQL eller går det att koppla för ett sömlöst datautbyte? Anledningen att jag frågar är att det finns ju många andra företagsprogram som använder MySQL som datalagring och om det är enkelt med datautbyte så vore ju det guld. Användarcase: En TM-agent ringer via ViciDial (MySQL) och registrerar en respondent som prospekt i VTigerCRM (MySQL), en säljare ringer upp prospektet och omvandlar prospekt-datan till en order varefter admin kan använda samma data sömlöst för att skapa en faktura och bokföra i JFS (HSQL).

farmfield: Om inte annat kanske han/de kan vara villiga att fungera som bollplank och försökspersoner?

[farmfield]

farmfield: Om inte annat kanske han/de kan vara villiga att fungera som bollplank och försökspersoner?

Ja, det var väl det som var tanken, att få med två personer som arbetar dagligen med denna typ av applikation. Min pops kör ju Hogia (Art?) men skall kolla upp vad polarens revisionsbyrå kör - Nordstedts har jag för mig...

[micke_nordin]

Är du sann? Det är ju fantasktiskt bra! Betyder det att programet nu följer temainställningarna för Gnome/KDE?

Nja, jag ändrade så att det i stället för att stå så här:

Kod: Markera allt

 AlloyLookAndFeel.setProperty("alloy.licenseCode"           , "4#JFS_Bokforing#m4zvft#5lkl8w");
       AlloyLookAndFeel.setProperty("alloy.titlePaneTextAlignment", "left");

        try {
            AlloyLookAndFeel iAlloyLookAndFeel =  new AlloyLookAndFeel();
            UIManager.setLookAndFeel(iAlloyLookAndFeel );

            JDialog.setDefaultLookAndFeelDecorated(true);
            JFrame .setDefaultLookAndFeelDecorated(true);
        } catch (Exception e) {
            e.printStackTrace();
        }

står så här;

Kod: Markera allt

        try {
            UIManager.setLookAndFeel( UIManager.getCrossPlatformLookAndFeelClassName() );

            JDialog.setDefaultLookAndFeelDecorated(true);
            JFrame .setDefaultLookAndFeelDecorated(true);
        } catch (Exception e) {
            e.printStackTrace();
        }

Det betyder att den använder javas standardutseende, om man vill kan man i stället byta till SystemLookAndFeel, då kommer programmet använda det utseende som passar systemet den är installerad på, om jag fattat det rätt är utseendet alltså olika beroende på om det är gnome, kde eller windows.

Är det svårt att utbyta information mellan HSQL och MySQL eller går det att koppla för ett sömlöst datautbyte? Anledningen att jag frågar är att det finns ju många andra företagsprogram som använder MySQL som datalagring och om det är enkelt med datautbyte så vore ju det guld. Användarcase: En TM-agent ringer via ViciDial (MySQL) och registrerar en respondent som prospekt i VTigerCRM (MySQL), en säljare ringer upp prospektet och omvandlar prospekt-datan till en order varefter admin kan använda samma data sömlöst för att skapa en faktura och bokföra i JFS (HSQL).

Ingen aning, hsql är någon typ av databashanterare skriven i java, mer än så vet jag inte. Det som verkar vara bra med hsql är att det inte behövs nån installation, utan den ligger i installationskatalogen för jfs som en jar-fil. Vad TM-agent, ViciDial, en respondent som prospekt i VTigerCRM och prospekt-datan betyder har jag ingen aning om

/Micke

[djkmmo]

Är du sann? Det är ju fantasktiskt bra! Betyder det att programet nu följer temainställningarna för Gnome/KDE?

Nja, jag ändrade så att det i stället för att stå så här:
[...]
Det betyder att den använder javas standardutseende, om man vill kan man i stället byta till SystemLookAndFeel, då kommer programmet använda det utseende som passar systemet den är installerad på, om jag fattat det rätt är utseendet alltså olika beroende på om det är gnome, kde eller windows.

Okidok. Då skall det vara väldigt enkelt med andra ord?

Är det svårt att utbyta information mellan HSQL och MySQL eller går det att koppla för ett sömlöst datautbyte? Anledningen att jag frågar är att det finns ju många andra företagsprogram som använder MySQL som datalagring och om det är enkelt med datautbyte så vore ju det guld. Användarcase: En TM-agent ringer via ViciDial (MySQL) och registrerar en respondent som prospekt i VTigerCRM (MySQL), en säljare ringer upp prospektet och omvandlar prospekt-datan till en order varefter admin kan använda samma data sömlöst för att skapa en faktura och bokföra i JFS (HSQL).

Ingen aning, hsql är någon typ av databashanterare skriven i java, mer än så vet jag inte. Det som verkar vara bra med hsql är att det inte behövs nån installation, utan den ligger i installationskatalogen för jfs som en jar-fil. Vad TM-agent, ViciDial, en respondent som prospekt i VTigerCRM och prospekt-datan betyder har jag ingen aning om

/Micke

TM-agent = TeleMarketing-agent = någon som sitter i telefon vid en TM-kampanj.
ViciDial = En predictive dialer byggd på basis av Asterisk. Det är alltså ett program som sköter matning av telefonnummer som skall ringas upp via Asterisk. Att den är "predictive" betyder att den har inbyggda algoritmer för att förutsäga ("predict") när nästa samtal bör ringas upp för att få maximal svarsfrekvens och samtalstid för TM-agenterna/säljarna. De telefonnumer som skall ringas upp lagras i en MySQL-databas, tillsammans med andra data som prospektets namn, adress, kund/personnummer etc. Dessa data bildar tillsammans "prospekt-data". Är FOSS
respondent = Den som besvarar frågor i t.ex. undersöknings- eller försäljningssyfte.
prospekt = potentiell kund.
CRM = Customer Relations Managment. System för att hålla reda på vilka ens kunder är, när man varit i kontakt med dem, varför, vad resultatet blev, vilka arbetsställen de har etc. etc, d.v.s. all data som man finner användbar för att öka omsättningen på kunden.
VTigerCRM = FOSS CRM-lösning som går att koppla ihop med ViciDial så att datan från det ena systemet sömlöst går att överföra till det andra.

Många icke-FOSS-system har möjlighet att integrera alla eller delar av dessa funktioner, så det vore ju inte dumt om det går att koppla ihop de olika delarna, så att de, sett ur användarens perspektiv, blir delar i ett och samma system s.a.s. Bra FOSS ERP- och CRM-program finns ju redan, men det är svårt för svenska företag att använda dem, då det inte finns någon fakturerings/bokförings-"modul" att "koppla på". Om ett företag behöver ett CRM-program är det med andra ord betydligt enklare att köra med stängd programvara (som Hogia, Mamut, Visma etc) för de kan integrera de olika delarna. Man kan börja med ett enkelt bokföringsprogram, bygga på med faktureringsbiten, köpa till CRM-modul när det behövs etc utan att behöva byta ut det man redan har. Om vi (FOSS) redan från början ser till att kunden har en uppgraderingsväg i takt med att behoven ökar så tror jag att det vore en väldig fördel. Det är väl lite med det i bakhuvudet som har gjort att jag kännt mig lite tveksam till JFS. Jag vet ju inte om JFS-programen är byggda för att enkelt kunna kopplas ihop med andra delar av ett fullt affärssystem, eller om de helt enkelt kodat ihop något helt eget, utan en tanke på att det skulle kunna bli en del i en helhet tillsammans med andra program.

För mer info om Tele Marketing, Predictive Dialer och CRM se Wikipedia. .

[micke_nordin]

Jag tror att vi får börja med att få igång JFS så att det åtminstone har den funktionalitet det haft i sin proprietära version. Det vill säga anpassa koden så att den funkar helt och hållet utan att man skall behöva ha licensnycklar och så. Dessutom måste det fixas med installationsfiler så att man kan installera det som ett vanligt program. Jag kommer dock inte ha tid att göra detta själv, eller ens att ha huvudansvar får nått sånt här projekt. Jag kan bidra med kod, visst, men någon annan är nog tyvärr tvungen att vara "projektledare".

Kanske skulle det behöva sättas upp ett sånt projekt, så att det blir lite mer tydligt vad som skall göras och vem som gör det?

/Micvke

[andol]

micke_nordin: Samkört dina resultat med jonasbjork något? (se tidigare post)
Lite osäker på hur mycket han hänger här inne.

[micke_nordin]

micke_nordin: Samkört dina resultat med jonasbjork något? (se tidigare post)
Lite osäker på hur mycket han hänger här inne.

Jag har försökt mejla honom, och även skrivit på Linuxportalen om vad jag gjort, men jag har inte fått nått svar ännu.

/Micke

[djkmmo]

Jag tror att vi får börja med att få igång JFS så att det åtminstone har den funktionalitet det haft i sin proprietära version.

Jo, men det vore nog ett misstag att lägga ner en massa jobb på ett fakturerings-/bokföringsprogram som inte går att koppla ihop med andra program till ett fullt affärssystem Om det inte går att kompletera/integrera med andra nödvändiga affärsprogram så kommer nyttan med programet att bli onödigt begränsad. Men detta är mer en brasklapp från min sida, för att säkerställa att vi inte lägger ned onödigt arbete på ett program som längre fram visar sig bli en återvändsgränd. I vilket fall hittade jag följande:

Transfer Tool is a GUI program for transferring SQL schema and data from one JDBC source to another. Source and destination can be different database engines or different databases on the same server.

Transfer Tool works in two different modes. Direct transfer maintains a connection to both source and destination and performs the transfer. Dump and Restore mode is invoked once to transfer the data from the source to a text file (Dump), then again to transfer the data from the text file to the destination (Restore). With Dump and Restore, it is possible to make any changes to database object definitions and data prior to restoring it to the target.

Dump and Restore modes can be set via the command line with -d (--dump) or -r (--restore) options. Alternatively the Transfer Tool can be started with any of the three modes from the Database Manager's Tools menu.

The connection dialogue allows you to save the settings for the connection you are about to make. You can then access the connection in future sessions. These settings are shared with those from the Database Manager tool. See the appendix on Database Manager for details of the connection dialogue box.

In version 1.8.0 Transfer Tool is no longer part of the hsqldb.jar. You can build the hsqldbutil.jar using the Ant command of the same name, to build a jar that includes Transfer Tool and the Database Manager.

When collecting meta-data, Transfer Tool performs SELECT * FROM <table> queries on all the tables in the source database. This may take a long time with some database engines. When the source database is HSQLDB, this means memory should be available for the result sets returned from the queries. Therefore, the memory allocation of the java process in which Transfer Tool is executed may have to be high.

http://hsqldb.org/web/hsqlDocsFrame.html
Ni som förstår vad det står, betyder det att det går att utbyta data (eller t.o.m. dynamiskt koppla ihop) mellan HSQL och MySQL?

[micke_nordin]

Det går säkert bra att konvertera mellan mysql/hsql, det tror inte jag kommer stoppa någonting.

Vad gäller att satsa på JFS: Nu är det ju inte så att vi har en massa alternativ att välja mellan, det finns inget fritt bokföringsprogram som funkar för svenska förhållanden i dagsläget. Nu finns källkoden till ett av de bättre på marknaden (enligt uppgift) tillgänglig. Då kan vi välja, vill vi ha ett fritt bokföringsprogram eller inte? Vi har inga andra alternativ. När vi har lyckats sätta oss in i källkoden kommer det att bli klart om det går att utöka, eller koppla i hop med andra program. Men där är vi inte ännu. Det vore dock synd att inte sätta i gång och tillgängligöra JFS nu när det finns, just eftersom vi verkar sakna andra alternativ.

/Micke

[omnius]

En liten fråga...

jag har inte hajjat var det är gnucash brister i funktioner, utöver avsaknad av löneprogram antar jag, och något som heter BAS (?) som jag inte vet vad det är. Har inte linuxföreningen en grupp som är tänkt att jobba med att få fram ett bokföringsprogram för svenska förhållanden...men som är lite avstannat?

Tjo.

[djkmmo]

Det går säkert bra att konvertera mellan mysql/hsql, det tror inte jag kommer stoppa någonting.

Vad gäller att satsa på JFS: Nu är det ju inte så att vi har en massa alternativ att välja mellan, det finns inget fritt bokföringsprogram som funkar för svenska förhållanden i dagsläget. Nu finns källkoden till ett av de bättre på marknaden (enligt uppgift) tillgänglig. Då kan vi välja, vill vi ha ett fritt bokföringsprogram eller inte? Vi har inga andra alternativ. När vi har lyckats sätta oss in i källkoden kommer det att bli klart om det går att utöka, eller koppla i hop med andra program. Men där är vi inte ännu. Det vore dock synd att inte sätta i gång och tillgängligöra JFS nu när det finns, just eftersom vi verkar sakna andra alternativ.

/Micke

Nu tycker jag nog att du är lite väl negativ. Inte saknas det alternativ. Gnucash, LedgerSQL och SMBLedger är bara tre andra alternativ vid sidan av JFS. Om man skall hårddra det så är ju det här med kontoplaner och rapporter en ganska marginell sak jämfört med utbyggbarhet. Alla bokföringsprogram som alls kan komma ifråga, har funktioner för anpassning av kontoplaner, hur skulle det annars fungera? I stort sett alla företag måste anpassa de "grundkontoplaner" som levereras med bokföringsprogramen, så att det är bra med en svensk BAS-kontoplan i ett bokföringsprogram betyder ingenting annat än att det är lite bekvämare att det finns en ryggrad att utgå ifrån. Som sagt så tog det mig 1/2-1 dag att sätta upp en kontoplan för K1-företag t.o.m. konto <6000. Bara så att vi får lite proportion på hur svårt olika saker är att göra.

Så med en dåres envishet hävdar jag fortfarande: om det inte finns förutsättningar för att integrera programet (vilket objekt "programet" än denoterar) med andra program som vanligtvis ingår i en full uppsättning affärsprogram, så kommer programet att bli mycket mindre användbart. Men som sagt, jag vet inte att det är så i fallet med JFS, men jag skulle vilja veta att det inte är så.

Jag föreslog ovan att vi skulle börja med att speca upp de saker som vi ser som nödvändiga/bra/onödiga/icke-önskvärda i programet och undersöka hur väl de olika alternativ som finns uppfyller de kraven. Jag började en sådan specning ovan och jag tror fortfarande att det är den rätta vägen att gå. Som jag ser det bör integrerbarhet med andra administrativa affärsprogram komma rätt högt upp på kravlistan.

[djkmmo]

En liten fråga...

jag har inte hajjat var det är gnucash brister i funktioner, utöver avsaknad av löneprogram antar jag, och något som heter BAS (?) som jag inte vet vad det är. Har inte linuxföreningen en grupp som är tänkt att jobba med att få fram ett bokföringsprogram för svenska förhållanden...men som är lite avstannat?

Tjo.

Tydligen fungerar Gnucash inte på det vis som redovisningskonsulter är vana.

Jag tror att Linuxföreningens projekt dog ut rätt omgående efter starten, tyvärr.

[maccaddam]

Så med en dåres envishet hävdar jag fortfarande: om det inte finns förutsättningar för att integrera programet (vilket objekt "programet" än denoterar) med andra program som vanligtvis ingår i en full uppsättning affärsprogram, så kommer programet att bli mycket mindre användbart. Men som sagt, jag vet inte att det är så i fallet med JFS, men jag skulle vilja veta att det inte är så.
Jag föreslog ovan att vi skulle börja med att speca upp de saker som vi ser som nödvändiga/bra/onödiga/icke-önskvärda i programet och undersöka hur väl de olika alternativ som finns uppfyller de kraven. Jag började en sådan specning ovan och jag tror fortfarande att det är den rätta vägen att gå. Som jag ser det bör integrerbarhet med andra administrativa affärsprogram komma rätt högt upp på kravlistan.

Ni får väl bestämma er för ambitionsnivån - Ett program att jämföra med kan vara:
Visma Administration 2000, fullt tillräckligt för merparten av mindre företag i Sverige
Visma Administration 2000 (finns i fyra versioner, där 2000 är mest omfattande) kostar:
Program utan serviceavtal. 10.900:- exkl moms

Om ambitionsnivån är ett fullt utvecklat affärssystem för större företag - verkar inte rimligt. Lite större företag kan faktiskt köpa större Hansa Enterprice eller Garp t ex. Däremot kan man ha ambitionen att fixa import- och exportmöjligheter. Excel och XML finns till i viss omfattning i JFS.

Vad kan man mer önska? Löneprogram. I fallet SPCS kan man köpa till ett separat löneprogram. Löneprogram är det absolut svåraste att underhålla - låt specialistföretagen hålla på med detta.

MPS för tillverkande företag - låt specialistföretagen hålla på med detta.

Säljstöd (CRM) borde vara integrerat i alla administrativa paket. SPCS har det inte, även de som kör SPCS måste sköta säljstöd från annan leverantör!

Min slutsats är att funktionerna i JFS är fullt tillräckliga för sådär en halv miljon svenska mindre företag.
Om du säljer datorer t ex kan du förutom köpa, lagra och offerera och fakturera även montera en dator (paketartikel) och få täckningsbidrag uträknat.

Visma Administration 2000 Innehåller följande funktioner - som även finns i JFS:
Bokföring
Konteringsmallar
Projektredovisning
Budget
Offert
Order
Lager
Fakturering
Paketartikel
Inköp/Beställning
Kundreskontra
Leverantörsreskontra
Utbetalningar
Språk- och valutahantering
Utskrifter

SPCS 2000 innehåller dessutom:
Generell rapportgenerator (I JFS finns en enkel rapportgenerator i bokföringen)
Spårning
Avtalshantering (I JFS finns periodfaktura)
Samlingsfakturering
Streckkod
Utlandsbetalningar
Visma Infoline

Från JFS bokföring går att importera/exportera i SIE
Från JFS produktregister går att importera/exportera i Excel och XML

Därmed inte sagt att JFS skulle vara lika bra som SPCS - det finns säkert brister i kvalitet och finesser i JFS.
I ett annat program som jag känner till var konstruktören alert när det gällde kundanpassningar. Han fixade tillägg i programmet allt enligt kundens önskningar (mot betalning). Ungefär som i Firefox där det går att ladda ner en massa tillägg. Är det någon som skulle vara tekniskt möjligt för JFS?

[StefanB]

Jo, men det vore nog ett misstag att lägga ner en massa jobb på ett fakturerings-/bokföringsprogram som inte går att koppla ihop med andra program till ett fullt affärssystem Om det inte går att kompletera/integrera med andra nödvändiga affärsprogram så kommer nyttan med programet att bli onödigt begränsad. Men detta är mer en brasklapp från min sida, för att säkerställa att vi inte lägger ned onödigt arbete på ett program som längre fram visar sig bli en återvändsgränd.

Direktkoppling mellan olika system förekommer väl bara då det är en och samma leverantör eftersom olika leverantörer inte vill ha varandra grävandes inne i sina databaser? Normalt sker integrering genom att den levererande databasen skapar en vy eller textfil i ett format som kan läsas av ekonomisystemet. Exempelvis lönesystem som levererar textfiler som importeras som transaktioner till ekonomisystemet eller hyressystem som levererar vyer som sedan läses in som verifikationsloggar. Om en kund skulle fråga oss om vi kan integrera mot deras lönesystem så skulle, oavsett lönesystem, sannolikt svaret bli Ja eftersom leverantören sannolikt kan skapa vyer eller filer i det format som krävs för att exempelvis JFS kan läsa det. Direktkoppling mellan databaser kräver att vi har en hel programsvit och det tror jag är en alldeles för hög ambitionsnivå.

[liax]

En erfarenhet från visma enskild firma är den bara generar en SIE-fil, min revisor önskade formatet SIE4. Hans program kunde inte läsa SIE utan bara SIE4.

De jobbar 6 personer på den revisionsbyrån så jag gissar att den klassas som medelstor och gissar därför också att många revisorer vill ha SIE4.

Eftersom jag inte kunde få fram eller konvertera till SIE4 så var jag tvungen att skriva ut hela bokföringen och lämna in och det blev väldigt dyrt, tog längre tid för honom att kontrollera allt än om jag mailat den där usla filen som jag inte kunde framställa :/

[djkmmo]

Så med en dåres envishet hävdar jag fortfarande: om det inte finns förutsättningar för att integrera programet (vilket objekt "programet" än denoterar) med andra program som vanligtvis ingår i en full uppsättning affärsprogram, så kommer programet att bli mycket mindre användbart. Men som sagt, jag vet inte att det är så i fallet med JFS, men jag skulle vilja veta att det inte är så.
Jag föreslog ovan att vi skulle börja med att speca upp de saker som vi ser som nödvändiga/bra/onödiga/icke-önskvärda i programet och undersöka hur väl de olika alternativ som finns uppfyller de kraven. Jag började en sådan specning ovan och jag tror fortfarande att det är den rätta vägen att gå. Som jag ser det bör integrerbarhet med andra administrativa affärsprogram komma rätt högt upp på kravlistan.

Om ambitionsnivån är ett fullt utvecklat affärssystem för större företag - verkar inte rimligt.

Då läser du ju det jag skriver som f_n läser Biblen... Det jag sriver är ju inte att vi skall bygga ett fullt affärssystem från grunden med ett fakturerings-/bokföringsprogram som grund, utan att det redan finns andra bra affärsprogram till GNU/Linux som redan kan hantera de delarna (CRM/ERP etc). Till listan av bef. program skulle vi även kunna lägga WebERP som bygger på LAMP. Det finns redan ett svensk företag som jobbar med WebERP som skriver så här ang. ekonomifunktionerna:

Vi har arbetat en hel del med att göra en svensk version av ekonomimodelerna men är inte helt klart till stor del beroende på att vi ej haft någon kund på dessa moduler.

http://www.opensourceerp.info/?cat=5
WebERP har vissa CRM-funktioner, men går även att koppla ihop med VTigerCRM. Varför inte höra med det företaget också, innan vi beslutar oss för JFS? De påstår ju att de börjat jobba med bokföringsdelarna och skulle kanske välkommna extra hjälp.

Det jag säger är att vi inte från början skall välja att lägga tid på ett system som i grunden inte är utbyggbart. Menar du verkligen att du tycker att det är en fördel att välja att bygga vidare på ett system som inte går att kompletera med de utmärkta FOSS-affärssystem som redan finns? NB att det inte är någon som ännu sagt att detta inte är ett problem, att det går att sömlöst utbyta information. Det närmaste är ett "det går säkert bra". Jag antar att "det går säkert bra" även i det här sammanhanget betyder "jag har ingen aning, men jag vill bli av med dina irriterande frågor"...

[micke_nordin]

Det jag säger är att vi inte från början skall välja att lägga tid på ett system som i grunden inte är utbyggbart. Menar du verkligen att du tycker att det är en fördel att välja att bygga vidare på ett system som inte går att kompletera med de utmärkta FOSS-affärssystem som redan finns? NB att det inte är någon som ännu sagt att detta inte är ett problem, att det går att sömlöst utbyta information. Det närmaste är ett "det går säkert bra". Jag antar att "det går säkert bra" även i det här sammanhanget betyder "jag har ingen aning, men jag vill bli av med dina irriterande frågor"...

Jag vet inte vad du menar med "inte utbyggbart". Ta och ladda hem JFS och testa vilken funktionalitet som finns idag:
http://www.jfsbokforing.se/JFSAdmDemo.html
Kanske går det att integrera med andra program redan idag, eftersom ingen verkar veta får du testa själv.
Om du inte menar funktionalitet som finns idag utan om programmet går att ändra på ett sådant sätt att det integrerar med andra program är det ju bara fråga om kodning. Det går att göra vad som helst med vilket program som helst, det är bara en fråga om arbete och tid. Dock är det ingen som kommer kunna svara på hur lång tid det tar eller hur mycket arbete det är förrän någon satt sig in i koden. Det vill säga att vi inte kommer kunna göra någon bedömning om det är "värt" att satsa på jfs innan vi har satsat på jfs. Men som sagt, ladda hem deras gratisversion och testa själv så kanske du får svar på några frågor. I annat fall kanske du kan ringa JFS och be att få prata med den som utvecklat hittils, den personen kanske kan svara på dina frågor.

/Micke

[djkmmo]

Jag vet inte vad du menar med "inte utbyggbart". Ta och ladda hem JFS och testa vilken funktionalitet som finns idag:
http://www.jfsbokforing.se/JFSAdmDemo.html
Kanske går det att integrera med andra program redan idag, eftersom ingen verkar veta får du testa själv.

Och hur skulle jag kunna göra det när jag inte kan programera? Jag är säljare och företagsledare, inte programerare. Jag använder program, jag skapar dem inte. Men så mycket har jag förstått att det inte är någon barnlek att bara få program att fungera med varandra. Om vi tar exemplet med Vtiger och WebERP så verkar det inte ha varit helt lätt att få ihop de två, trots att

Om du inte menar funktionalitet som finns idag utan om programmet går att ändra på ett sådant sätt att det integrerar med andra program är det ju bara fråga om kodning. Det går att göra vad som helst med vilket program som helst, det är bara en fråga om arbete och tid.

Vilket för ett företag är ekvivalent med pengar. Om programuppsättning ett har goda förutsättningar för integration = lite arbete och tid så betyder det "billigt", om programuppsättning två kräver mycket tid och arbete för att kunna integrera så betyder det "dyrt". Om det kräver mycket kod för att integrera JFS med andra tillgängliga FOSS affärsprogram så blir JFS dyrt, vilket betyder att det blir mindre attraktivt.

Dock är det ingen som kommer kunna svara på hur lång tid det tar eller hur mycket arbete det är förrän någon satt sig in i koden. Det vill säga att vi inte kommer kunna göra någon bedömning om det är "värt" att satsa på jfs innan vi har satsat på jfs.

Och du är naturligtvis välkommen att göra det, om du känner att du har tid med det.

Men som sagt, ladda hem deras gratisversion och testa själv så kanske du får svar på några frågor.

Det är att jag har gjort det som väckt frågorna. Vad jag kan se så fungerar inte ens rapporterna i JFS.

Min slutsats är att funktionerna i JFS är fullt tillräckliga för sådär en halv miljon svenska mindre företag.

Jag missade att kommentera detta tidigare, så jag gör det nu istället. Jag tror för min del inte att det är rätt, av den enkla anledningen att JFS inte verkar kunna hantera kontantmetoden och bokslutsmetoden, om man använder faktureringsmodulen i JFS. När man lägger upp en faktura i JFS så bokförs den inte automatiskt, men om man vill få ett utbyte mellan faktureringsdelen och bokföringsdelen så får man sätta upp en fakturajournal för fakturor mellan vissa datum. Denna fakturajournal kan sedan automatiskt bokföras med ett knapptryck. I ett senare skede, när du fått betalt av kunden, kan du göra samma sak med betalningar; du sätter upp en inbetalningsjournal som sedan bokförs med ett knapptryck. Detta kan ju verka väldigt smidigt och det är det väl också. Det är bara ett litet, litet problem: om man använder sig av kontantmetoden för bokföring och bokslutsmetoden för moms så kommer du att bryta mot bokföringslagen med två små knapptryck. JFS bokför nämligen fakturajournalen som en kundfordran under 1510(D) och inbetalningsjournalen som 1510(K). Jag har inte hittat något sätt att ändra på detta beteende i JFS, så att det bara blir en bokföringspost (vid betalning). Med andra ord får då in kund-/leveratörsreskontra-poster i bokföringen för varje journal. Det får du inte ha om du kör med kontantmetoden, då bryter du mot bokföringslagen. Det gör att du i så fall måste byta till faktureringsmetoden, men för att den skall fungera smidigt så kan du i praktiken inte använda bokslutsmetoden för moms längre. För att göra en lång historia kort så skulle det för många av dessa 600 000 företag du pratar om, innebära potentiellt stora likviditetsproblem, då de kan tvingas att betala mer i moms än de har intäkter (med faktureringsmetoden betalar man moms på det som fakturerats, med bokslutsmetoden redovisas och betalas moms på det du fått betalt av kunder). Alternativet är att inte alls använda faktureringsmodulen i JFS, men då skulle mycket av funktionaliteten falla bort. Så om vi återvänder till utbyggbarhet så förefaller dig mig att inte ens den inbyggda funktionalliteten i JFS kan användas av den största delen av den tänkta användargruppen.

PS. Det går naturligtvis att använda faktureringsdelen i JFS bara för att skriva ut fakturor, utan att göra journaler, men då får man göra allt jobb två gånger, en gång när man fakturerar och en gång när det skall bokföras. DS

[maccaddam]

Men som sagt, ladda hem deras gratisversion och testa själv så kanske du får svar på några frågor.

Det är att jag har gjort det som väckt frågorna. Vad jag kan se så fungerar inte ens rapporterna i JFS.

Rapporterna funkar när jag kör under Windows XP (förlåt de fula orden)

Min slutsats är att funktionerna i JFS är fullt tillräckliga för sådär en halv miljon svenska mindre företag.

Jag missade att kommentera detta tidigare, så jag gör det nu istället. Jag tror för min del inte att det är rätt, av den enkla anledningen att JFS inte verkar kunna hantera kontantmetoden och bokslutsmetoden, om

Det var inte micke som påstod att "JFS är fullt tillräckliga för sådär en halv miljon svenska mindre företag", det var jag. Ingen har väl påstått att JFS är perfekt. Om inte JFS-folket tänkt ut något sätt att fixa kontantmetoden borde det väl inte vara särskilt svårt att programmera in en kontantmetodssnutt?

[StefanB]

Om inte JFS-folket tänkt ut något sätt att fixa kontantmetoden borde det väl inte vara särskilt svårt att programmera in en kontantmetodssnutt?

Har ni testat att fakturera kontantkvitton i JFS?