Mehr BT-Felder (EN16931) in E-Rechnungen nutzbar machen
Aktuell können in Lexware Office nur ausgewählte Felder des E-Rechnungsstandards befüllt werden. In der Praxis fehlen jedoch wichtige standardisierte Felder, die im B2B-Bereich benötigt werden.
PROBLEM
Viele Unternehmen mit zentraler Rechnungsverarbeitung benötigen zusätzliche Identifikatoren, damit Rechnungen automatisch korrekt zugeordnet werden können (z.B. Filial-ID, GLN, interne Referenzen).
Konkretes Beispiel: Ein Lebensmitteleinzelhändler empfängt Rechnungen zentral, ordnet diese aber einzelnen Märkten über eine eindeutige Käuferkennung zu: GLN (Global Location Number) im Feld BT-46 (Buyer Identifier).
Diese Felder sind im EN16931-Standard definiert, können in Lexware Office aktuell jedoch nicht befüllt werden. Dadurch entstehen unnötige Workarounds außerhalb von Lexware Office.
VORSCHLAG
• Unterstützung weiterer EN16931-Business-Terms (BT-Felder)
• oder optional eine flexible Feldzuordnung (Mapping): „Feld X in Lexware Office → BT-46“
• Orientierung an bestehenden Felddefinitionen (siehe OZG-RE Feldübersicht)
NUTZEN
• bessere Unterstützung realer B2B-Anforderungen
• saubere EN16931-konforme E-Rechnungen
• weniger externe Workarounds
• Erfüllung von E-Rechnungsanforderungen größerer Geschäftspartner
Das würde Lexware Office deutlich flexibler im Umgang mit E-Rechnungen machen und mehr Anwendungsfälle abdecken.
buchhaltung.cloud
teilte diese Idee
-
anonym
kommentierte
Danke fürs Einrichten des Bestellnummernfelds BT13.
Wir haben aber außerdem noch das Problem mit den Lieferscheinnummern, zumindest Stand jetzt. Dies soll in einem der folgenden Felder abgebildet werden:
BT-16 Kennung der Versandanzeige … Despatch Advice Referenced Document (Bevorzugt!)
Wird häufig genommen - ist eigentlich die Stelle für ein Lieferavis (DESADV)Alternativ:
BT-11 Projektnummer
BT-12 Vertragsnummer
BT-14 Auftragsnummer
BT-17 Vergabenummer
BT-18 ObjektkennungBitte dieses Jahr noch umsetzen! Dankeschön
-
SandraJ
kommentierte
Insbesondere das Fehlen von BT-13 (Bestellreferenz des Kunden) ist für mich rein fachlich absolut nicht nachvollziehbar. Ich hatte dazu schon vor etlichen Monaten mehrere Telefonate mit dem Support. Antwort: Kann man doch in irgendeinem Text mitgeben.
Mit Verlaub, aber das ist weder plausibel noch professionell.
Diese Information ist weder nice-to-have noch eine Branchenspezifika. Sie gehört nicht "irgendwie" übertragen, sondern in dem dafür vorgesehenen Feld, damit die elektronische Eingangsverarbeitung ohne Probleme, ohne manuelles Eingreifen und auch ohne KI diese Rechnung der korrekten Bestellung zuordnen kann.
Unsere Kunden beschweren sich jeden Monat und schütteln den Kopf über "Lexware sieht das nicht vor". Wenn das nicht bald mal umgesetzt wird, werden wir ggf. gezwungen sein, das Produkt zu wechseln, was wirklich schade wäre, denn von der Usability sind wir echt begeistert.
Ich bin selber Programmierer - das ist nicht schwer umzusetzen! Kleiner Aufwand, große Wirkung. Es wundert mich sehr, dass nicht viel mehr User diesen Punkt kritisieren.
Ich arbeite auf der Eingangsrechnungsseite. Eine der nächsten Aufgaben in der Pipeline:
Rechnungen ohne Bestellbezug automatisch ablehnen! Ab da wird's blöd...
Viele Grüße, Sandra -
H.Häde GmbH
kommentierte
Gute Idee, wir stehen vor dem gleichen Problem. Für unsere E-Rechnungen benötigen wir zusätzliche Felder, damit Rechnungen beim Kunden korrekt zugeordnet werden können. Aktuell müssen wir dafür Wege außerhalb von Lexware gehen – eine direkte Unterstützung wäre sehr hilfreich.
-
WordPress
kommentierte
Bitte ALLE ZUGFERD Felder vorsehen und im Lexoffice Backend z.B. im Rechnungserstellungs-Dialog befüllbar machen.
Es fehlen noch (Beispiele):
- Lieferantendaten BIC
- Lieferantendaten Ansprechpartner Name
- Belegkopfdaten: Fälligkeitsdatum
- BT-13: Rechnungsdaten – Bestellnummer (47XXXXXXXX)
- BT-31: Rechnungsreferenzen – Umsatzsteuer-Identifikationsnummer
- BT-38: Postanschrift des Rechnungsstellers – Postleitzahl
- BT-44: Rechnungsempfänger – NameViele Grüße Andreas