Da bist Du nicht allein mit Deinem Gefühl und Deiner Entscheidung. Auch ich habe das Fakturama - Projekt bei mir geparkt und zahle noch einmal für ein Update der alten WAWI. Für den produktiven Einsatz kann ich Fakturama nicht einsetzen, zu viel Investition an Zeit und Datensicherheit überzeugt mich  zur Zeit nicht.

Import der alten Daten ist schwierig und aufwendig.

Angebot, AB, Rechnungen dürfen nicht aufhalten, ich habe so schon wenig Zeit für das Büro.

Dafür verzichte ich auf Zugferd (bei mir nur Pdf und XML), Anbindung vom Webshop (meine WAWI unterstützt woocommerce nicht), viele Annehmlichkeiten

in der jetzigen Wawi und Datensicherheit die ich bei Fakturama  vermisse....

Wir wollen nicht vergessen, Fakturama ist ein "Ehrenamts-Projekt", alle Mitstreiter verdienen Ihr Geld in einem Hauptberuf, ich könnte das nicht stemmen neben meiner

Selbstständigkeit.  

Also ein fettes D a n k e an die Macher, Geduld fällt auch mit schwer 🙂 .

VG Guntram

Das Fakturama ein Freizeitprojekt oder ehrenamtliches Projekt ist, ist der Grund warum ich so hin und her gerissen bin mich davon zu lösen.

Noch mehr schade wäre es um das Projekt wenn es keiner nutzt, aber einen Nutzen muss es machen. 😉

Und trial and Error gegenüber Nutzen steht aktuell in keinem Verhältnis, leider.

Das Problem, geht man weg und richtet sich mit was anderem ein, wird man vermutlich so schnell nicht wieder kommen.

Einer der Punkte, die mich derzeit bleiben lassen ist u.a. die Integration von LibreOffice zur einfachen Gestaltung der Dokumente. Da habe ich noch keine Alternative zu gefunden...

Moin, wir sind gerade dran, die ZUGFeRD-/XRechnung-Schnittstelle gründlich zu überarbeiten, deswegen kann es bei den Zwischenständen auch noch Komplikationen geben.

Bei mir wurde ebenfalls eine Zugpferd-Rechnung wegen Fehlern abgewisen. Ich habe Positonen mit unterschiedlichen Einheiten. In der Zugpferdrechnung steht aber bei allen Positonen der BT-Code für Stück.

Ich habe den Fehler gerade auch entdeckt. Zum Glück arbeiten die meisten meiner Kund*Innen noch nicht mit X-Rechnungen, sonst wäre wohl der komplette Mai abgewiesen wurden 😉 

Ich sehe übrigens nicht, dass das jetzt so ein großes Problem ist, denn es ist nun einmal eine Beta und die bringt auch Fehler mit sich. Was mich aber freuen würde, denn vor dem letzten Snapshot waren die X-Rechnungen ja valide, wenn ihr das vorletzte Snapshot noch einmal zur Verfügung stellen könntet. Damit kann in der Zwischenzeit noch ein wenig was gemacht werden, bis die fehlenden Felder wieder normal ausgegeben werden. (Ich wollte eigentlich jetzt immer selbst die letzten Pakete aufbewahren, habe meinen Vorsatz aber auch über Board geworfen 😉 ) 

Scheinbar ist auch mit POST / PRE was nicht in Ordnung, ich hatte in einer LO-Vorlage drin dass ein %NL erfolgt, was es aber nicht (mehr!!) korrekt tut.

Ich glaube PRE war mehr problematisch als POST.

Ich hatte in der Adresse zunächst die Variable für die gesamte Firmenadresse und/oder Kundenadresse, welche generiert wird, drin
Dies erzeugte aber viele Leerzeilen. Dann habe ich die Variablen einzeln eingefügt, das ging einwandfrei, nun sind da neue Zeilen danach drin, die ich nicht erklären kann. Auch weil ich bei einem Kunden regelmäßig wechslende Ansprechpersonen habe, die ich "Ansprechpartner" im Formular setze, das Adress-Feld aber nur die gespeicherten Kundendaten verwurstet.

Leerzeilen und Zeilenumbrüche sind generell ein Problem, auch bspw. in den Artikelbeschreibungen.
Was dort auch nicht in die LO-Vorlage transportiert wird sind TABs.

Das zwischen CRLF und LF unterschieden werden muss bei Win/Linux/MOS ist klar, dann vereinheitlicht die Eingaben bzw. wandelt direkt bei Eingabe / Speichern um.

Vorher

Fa. Xxx
ABC-Str. 13
12345 XXX

Aktuell:

Fa. Xxx

ABC-Str. 13

12345 XXX

Bei STRG + "Produkte+" wird keine Artikelnummer vergeben, gibt man manuell eine ein, die dem Muster folgt, dann wird nicht automatisch erhöht.

Beim danach folgenden Anlegen eines neuen Produktes wird dann die eins niedrigere vergeben.

SHIFT + ALT + C funktioniert scheinbar auch nicht mehr.

can't send mail in: # (-1)

Die Emaildaten sind korrekt, mir fehlt bspw. die Angabe "SSL/TLS" etc. in den Einstellungen, möglicherweise geht es deswegen nicht.

Beschreibung: xx@yy.de
Server: aa.bb.de
Port: 465
Benutzername: xx@yy.de
Authentifizierungsmethode: Passwort, normal
Verbindungssicherheit: SSL/TLS

hinterlegt in Faktura

Host: aa.bb.de:465
Benutzer: xx@yy.de
Passwort: <das korrekte, mehrfach gecheckte>

Moin, SSL/TLS geht momentan noch nicht, weil das von der verwendeten Mailbibliothek noch nicht unterstützt wird. Kommt aber mit der nächsten Version.

So, nachdem ich die Rechnung jetzt drucken konnte, konnte ich mir auch die XRechnung anschauen (neue Beta vom 26.08.):

1. Die Datumsangaben sind noch falsch in der X-Rechnung. Habe ich zum Beispiel einen Leistungszeitraum vom 02.07. bis zum 07.07., wird in der X-Rechnung der Leistungszeitraum vom 01.07. bis zum 06.07. angezeigt. Dasselbe gilt für das Rechnungsdatum
2. Beim Käufernamen wird nichts eingetragen, wenn der Kunde eine Firma ist. ist ein Vor- und Nachname hinterlegt, wird nur der Nachname übernommen. Das ist natürlich ein wenig blöd, weil die X-Rechnung ja gerade für das Versenden von Rechnungen im B2B gedacht ist. Im Feld Name - BT-44 - würde ich also schon den Firmennamen erwarten und dann auch Vor- und Nachname, wenn dieser angegeben ist. 
3. Im Feld Kennung des Lieferorts - BT 71 - findet sich in einigen Rechnungen plötzlich der Firmenname. Ich kann mit dem Feld nicht viel anfangen, könnte mir aber vorstellen, dass das nicht so gedacht ist. 

Das sind so die ersten Dinge, die mir jetzt vor dem ins Bett gehen aufgefallen sind. Ich hoffe, es hilft, damit die finale Version bald kommt.

Alles klar, besten Dank. Wir bereinigen das noch.

@teufel100 Moin, ich versuche die Fehler mal nachzuvollziehen. Bei BT-71 hab ich per copyPaste versehentlich BT-70 eingetragen. Beim Rest muss ich prüfen. Kannst du mir ggf mal per PM einen Screenshot vom Adressfeld im Fakturama senden? mich würde auch interessieren, ob die Daten da derzeit aus einem Kontakt kommen oder manuell eingegeben wurden. Problem hier ist wahrscheinlich das Parsen der Textbox der Adresse (was endlich in 2.3.0 erneuert wird). 

Vielen Dank schonmal für die Mithilfe. 

Boarschti

Darf ich mich mit meiner Frage / meinem Anliegen hier anhängen? Es betrifft auch Zugferd, aber ein anderes Problem:

In der Beta vom 26.08. kann ich keine Zugferd-Rechnung erstellen, weil das Programm bemängelt, dass keine Emailadresse des Kunden hinterlegt ist. Die ist doch auch gar nicht nötig?!

Die E-Mailadresse ist zwingend vorgeschrieben (Wofür benötigst Du sonst eine E-Rechnung - ausdrucken und per Brief versenden?). Bei meiner Warenwirtschaft öffnet sich nach Erstellung der XML Datei das E-Mailprogramm mit der hinterlegten E-Mailadresse und der E-Rechnung schon im Anhang. Das Projekt Fakturama liegt bei mir auf Eis, ich habe viel Zeit investiert, Erfolg sehr ernüchternd. Im Forum treten immer wieder die selben Probleme auf...     Dafür fehlt mir als Soloselbständiger einfach die Zeit. Datensicherheit ist auch ein Thema, 8 Jahre muss alles einer Prüfung standhalten und abrufbar sein.   Vielleicht wird es aber noch und die Beta läuft zufriedenstellend. 

VG Guntram