Benachrichtigungen
Alles entfernen
Fehler & Verbesserungsvorschläge
12
Beiträge
5
Benutzer
0
Reactions
1,201
Aufrufe
Topic starter
17. Juni 2011 22:02
Bisher habe ich meine selbstprogrammierte Filemaker Datenbank im Einsatz. Habe sie allerdings nach dem Umstieg auf Mac nie von Access richtig in Filemaker umgesetzt (jaja, wer hat schon Zeit). Also hangelte ich mich mit eine ständig offenen und bei Bedarf eben umprogrammierten Datenbank so durch.
Durch Zufall bin ich auf Fakturama gestoßen. Bin zwar keine Freund von OO bzw. LO, aber ich muß sagen, Fakturama hat die komplett gleiche Konstruktion, wie ich sie immer verwendet habe, was natürlich mir entgegen kommt.
Ich möchte auch bei Gelegenheit umsteigen.
Es gibt aber einige Kleinigkeiten, die mir Aufgefallen sind:
1. Lege ich einen Artikel an, sagen wir zu 46,50 (netto) und gebe 19% MwSt an, berechnet er bei einer typischen Anzahl von 160 die MwSt falsch. Hintergrund: Der Artikel kosten incl. MwSt 55,335. Nun rundet er auf 55,34, was nicht tragisch ist, aber in der Rechnung addiert er das gerundet Ergebnis, was dann bei einer Anzahl von 160 eine Fehlberechnung von 0,80 macht.
Gebe ich aber den Artikel direkt in die Rechnung ein, dann berechnet er richtig.
2. In OSX 10.6.7 friert Fakturama ein, wenn man es mit dem roten Knopf schließen will. Also das Fenster schließt, aber das Programm bleibt im Hintergrund aktiv, wie bei Mac üblich, lässt sich aber nicht mehr ansprechen und muss ge"killt" werden. Ist keine große Sache, wenn man es weiß, aber vielleicht kann man das mal ändern.
3. Bei der Eingabe von Ausgabebelegen muß man die Belegnummer manuell eingeben. Das hatte ich früher bei Filemaker auch mal so. Habe allerdings dann eine automatische Belegnummernvergabe einprogrammiert. Wäre es eigentlich viel Aufwand, in einer der nächsten Revisionen eine Auto-Belegnummernvergabe zu implementieren?
Hintergund:
Bei mir bekommt jedes Dokument eine einmalige Nummer. Ausgabebelege eben eine über die Jahre fortlaufende. Ebenso werden die dazugehörigen Buchungen auf den Bankbelegen nummeriert. So ist jeder Vorgang mit dieser Nummer ohne großes Lesen aufzufinden.
Bei der Handvergabe ist mir in der Vergangenheit ab und an passiert, das eine Nummer doppelt vergeben wurde. Eine automatisch erstellte Belegnummer würde dies wirksam vermeiden.
Trotzdem, ich finde das Programm gut und werde mal einen längeren Test wagen.
18. Juni 2011 13:30
Hi, Punkt 1 find ich interessant, aber kann ich nicht nachvollziehen
wenn ich in der Rechnung 160 produkte zu 46,50(netto) eingebe wird die MwSt.(19%) mit 1413,60 richtig berechnet und addiert...
Oder was meintest Du?
Gruß, OHo.
Topic starter
18. Juni 2011 15:42
Habe jetzt nochmel Produkt neu angelegt und Rechnung neu angelegt. Jetzt macht er es richtig.
Sorry, vermutlich habe ich irgendwo beim Anlegen des Produkts einen Fehler gemacht.
(Ich habe noch alle Einstellung durchgeschaltet (brutto/netto) und auch den Artikel nicht geändert und komplett neu angelegt.)
Topic starter
18. Juni 2011 16:00
Nochmal zu Punkt 2:
Mit dem roten Knopf schließt es ordnungsgemäß, hängen bleibt es beim Apfel + Q (Tastenkürzel zum Programmschließen)
Topic starter
18. Oktober 2013 19:00
Der Fehler von Punkt 1 ist bei mir auch. Das Problem ist daß bei der Eingabe der Preise bei Produkten nicht nach 2 Kommastellen abgeschnitten wird. So steht beispielsweise auf der Rechnung Einzelpreis: 7,48€ ; Stück: 10; Gesamtpreis: 74,79€. Habe dies mit selber eingegebenen Produkten probiert. Die Nettosumme der gesamten Artikel ist um 2 Cent fehlerhaft und der Rechnungsbetrag auch. Sowas darf nicht sein!
18. Oktober 2013 20:55
Sowas darf nicht sein!
Ist ja schon erkannt und in der Mache, wie du hier sehen kannst.
Jetzt mal Nerven behalten. B)-
Topic starter
24. Oktober 2013 10:37
Fakturama ist ein tolles Programm. Nur sind da noch diese Rundungssachen daß die Summe der Rechnung nicht stimmt. Eigentlich ein schwerwiegendes Problem mit dem Fakturama (für mich) unbrauchbar wird. Wir wollten eigtl. ab Jänner 2014 damit starten, ich hoffe daß bis dahin dieser Fehler behoben ist. Danke und schöne Grüße
25. Oktober 2013 23:04
Hallo pcda,
das kommt ganz auf unsere Kapazitäten an. Und die sind recht eng bemessen. Deswegen kann ich nicht hundertprozentig versprechen, daß die neue Version im Januar steht. Wir geben unser Bestes. Die Suche nach Alternativen wäre aber aus Deiner Soicht sicher angebracht (guck Dir mal http://openyabs.org/ an).
Mich wundert allerdings, daß anderen Anwendern dieser Fehler noch nicht so gravierend aufgefallen ist (halt nur einigen). Kann das manchmal auch an den Einstellungen (brutto/netto) liegen?
Viele Grüße,
Ralf.
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
26. Oktober 2013 20:17
Den Gedanken hatte ich auch schon, hab auch schonmal angefangen, einzelne Beispiele aus dem Forum nachzuvollziehen. Es gelang mir bisher allerdings nicht, den Fehler nachzustellen. Dennoch hatten wir bei uns auch mal den Fehler , da ging's aber nur um 1 Cent. Können wir aber auch nicht mehr reproduzieren.
Sieht also nach viel Arbeit aus...
Gruß,
Sven
26. Oktober 2013 21:34
Ich kann das Problem nachstellen, aber bei mir kommt auch bloß eine Differenz von einem Cent raus. Aber es geht mit den derzeitigen Mitteln nicht richtig zu reparieren.
Viele Grüße,
Ralf.
Viele Grüße
Ralf.
Wichtige Infos zum Posten im Forum.
Fehler gefunden?
Topic starter
28. Oktober 2013 09:33
hallo, das problem ist glaube ich gelöst.
es tritt nur auf, wenn man eine rechnung erstellt und den MwSt.-Satz der Produkte in der Rechnung ändert (z.B. von 19% auf 22%)
Topic starter
28. Oktober 2013 11:06
pcda Wrote:
-------------------------------------------------------
> hallo, das problem ist glaube ich gelöst.
> es tritt nur auf, wenn man eine rechnung erstellt
> und den MwSt.-Satz der Produkte in der Rechnung
> ändert (z.B. von 19% auf 22%)
ach gott. ich nehme die obige aussage wieder zurück. wenn man zB. von der Drossel (Standardvorlage) über 100 Stk. eingibt, stimmt der Betrag nicht.