Kategorie: Softwareentwicklung

E-Rechnung: ZUGFeRD 2.3 verlangt einen Lieferzeitpunkt

Zunächst: Ich kenne mich NICHT gut mit dem aus.

Das Umsatzsteuerrecht verlangt bei #Rechnungen die Angabe eines Leistungs-/Lieferdatums oder eines Leistungszeitraums.

Die Möglichkeit einen Leistungszeitraum anzugeben, scheint in Version 2.3 jedoch nicht zu unterstützen. So steht im Dokument „7. Factur-X_1.0.07_Technischer-Anhang_Profil_EN16931.pdf“ bei BT-72-00 „In Deutschland ist das Liefer- und Leistungsdatum eine Pflichtangabe auf Rechnungen. Diese kann auch auf Positionsebene angegeben werden, muss aber in jedem Fall hier angegeben sein.“. Das Feld BT-72-00 (ram:ActualDeliverySupplyChainEvent/ram:OccurrenceDateTime) unterstützt lediglich ein einzelnes Datum, keinen Zeitraum.

Eine Alternative zur Angabe eines Zeitraums wäre BG-14 (ram:BillingSpecifiedPeriod). Im Dokument steht zu diesem Feld: „Wird verwendet, um anzuzeigen, wann der von der Rechnung abgedeckte Zeitraum beginnt und wann er endet. Wird auch als Lieferzeitraum bezeichnet.“

Neben BG-14 steht auch noch BG-26 zur Verfügung. BG-26 ermöglicht die Angabe eines Zeitraums auf Positionsebene.

Ich vermute, dass die Spezifikation an dieser Stelle einen Fehler enthält und BT-72-00 nicht zwingend ein Pflichtfeld sein sollte, wenn BG-14 (oder ggf. BG-26?) befüllt wird.

Interessanterweise enthält die Spezifikation in Version 2.2 mit der Datei „EN16931_Betriebskostenabrechnung.pdf“ ein Beispiel, in dem ein Zeitraum über die Felder von BG-14 angegeben wird. BT-72-00 ist in diesem Beispiel nicht gefüllt. In Version 2.3 ist dieses Beispiel allerdings nicht mehr enthalten.

PS: Die Spezifikation Version 2.3 enthält ganz andere Beispielrechnungen als Version 2.2. Wer Beispiele für ZUGFeRD sucht, sollte sich daher ggf. mehrere Versionen der Spezifikation ansehen.

Darkpattern: Mehrseitige Formulare, bei denen man nicht umblättern kann

Ich ärgere mich oft über mehrseitige Formulare oder Wizards im Browser, in Programmen oder in Apps, bei denen man nicht zur nächsten Seite wechseln kann, ohne die aktuelle Seite ausgefüllt zu haben. Wenn ich nicht alle Seiten eines Formulars oder Wizards sehen kann, weiß ich nicht, was mich erwartet und wie viel Aufwand es mich kosten wird, alles auszufüllen. Meine Motivation, solche Formulare auszufüllen, ist äußerst gering.

Besonders ärgerlich sind solche Formulare, wenn ich auf Seite fünf erfahre, dass ich zum Ausfüllen noch weitere Unterlagen benötige, die mir (momentan) nicht vorliegen (ist mir bei meiner Krankenkasse passiert). Wenn dann auch noch eine Funktion zum Speichern der bisherigen Eingaben fehlt, wird es natürlich noch nerviger.

Pfandautomat said no

Ich bin heute einem sehr selbstbewussten Pfandautomaten begegnet. Er lehnte eine meiner Flaschen mit der Begründung ab, dass sie nicht zum Sortiment des Geschäfts gehöre. Das stimmte zwar nicht, aber auf die Idee, dass der Automat sich bei der Erkennung irren könnte, ist man bei der Entwicklung der Automatensoftware wohl nicht gekommen…

Karriereplanung für Softwareentwickelnde: Die Arbeit an Open-Source-Projekten ermöglicht es, soziale Strukturen und projektspezifisches Know-how bei einem Firmenwechsel zu erhalten.

M. E. ist der folgende Aspekt bei der Karriereplanung von Softwareentwickelnden unterbeleuchtet: Nur die Arbeit in einem relevanten Open-Source-Projekt ermöglicht es, die sozialen Arbeitsstrukturen (v.a. Kolleginnen und Kollegen) bei einem Firmenwechsel zumindest teilweise zu erhalten. Zudem bleibt das erworbene projektspezifische Know-how bei einem Wechsel des Unternehmens weiterhin nutzbar.
Wer z.B. bei Suse angestellt ist und am Linux-Kernel arbeitet, wird wahrscheinlich auch bei einer anderen Firma, die sich mit dem Linux-Kernel beschäftigt, eine Anstellung finden. Das Arbeitsumfeld und Know-how bleiben beim Wechsel des Unternehmens zumindest teilweise erhalten bzw. nutzbar.
Bei der Arbeit an proprietärer Software dürfte der Firmenwechsel mit einem weitgehenden Verlust der sozialen Arbeitsstruktur und einer verminderten Nutzbarkeit des projektspezifischen Know-hows einhergehen, weil es in der Regel kein weiteres Unternehmen gibt, das an derselben Software arbeitet.