Wie Hybriden aus XSL und C# ein Buchhaltungschaos verhindern können

Der Erfahrung nach sind Entwickler und Buchhalter wie Katz und Hund. Und als Entwickler neigt man natürlich dazu, Partei für die Entwickler zu ergreifen. Man muss allerdings einräumen, dass nicht allein die Buchhalter an diesem Kleinkrieg schuld sind. Aus ihrer Sicht gehen Entwickler eben zu schlampig mit Zahlen um – der Grundlage des Buchhalterberufs.

Man schaue sich dazu einmal die XPath-Funktion sum() in Microsofts MSXML an, welche die Summe des numerischen Werts jedes Knotens in einer Knotengruppe wie unten gezeigt ausgibt.

Beispiel für eine Knotengruppe

<value>4.42</value>
<value>25.00</value>
<value>0.60</value>

Das sieht doch ganz einfach aus, oder? Die Summe für die in Liste A gezeigte Knotengruppe müsste 30,02 lauten, richtig? Was aber, wenn diese Summe je nach verwendeter MSXML-Version 30,02 oder 30,020000000000003 lauten könnte? Vielleicht haben die Buchalter ja doch nicht ganz Unrecht.

Einem Entwickler, der zum ersten Mal auf dieses Problem stößt, ist sofort klar, dass dies ein Fließkommafehler in Microsofts Implementierung der XPath-Funktion sum() ist. Mit XSL Version 1.0 lässt sich das Problem wie folgt beheben: Man schreibt eine JavaScript-Erweiterungsfunktion, um den Fehler zu umgehen, was besonders schlau erscheint. Leider ist Microsoft ausgerechnet in diesem Fall bei seinen Lösungen konsequent vorgegangen: So enthielt die damalige Implementierung von JavaScript (Jscript) genau denselben Fehler.

Eine praktikable Lösung ist der folgende Hybrid aus XSL und C#

<?xml version="1.0″ encoding="UTF-8″?>
<xsl:stylesheet version="1.0″ xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:cs="urn:cs">
<! -- C# extension function used to avoid rounding errors in the sum function -- >
<msxsl:script language="CSharp" implements-prefix="cs"><![CDATA[
public string sum(System.Xml.XPath.XPathNodeIterator xni)
{
 double sum = 0;
 for (int i = 0; i < xni.Count; i++)
{
try
{
 xni.MoveNext();
 if(xni.Current.Value != "NaN")
 sum += double.Parse(xni.Current.Value);
}
catch(Exception ex) { }
}
 return sum.ToString();
}
]]></msxsl:script>
<xsl:template match="/">
<xsl:element name="sum">
<xsl:value-of select="//value"/>
</xsl:element>
</xsl:template>
</xsl:stylesheet>

Dieser Code funktioniert überraschenderweise und liefert auch noch das korrekte Ergebnis von 30,02.

Als Entwickler muss ein wenig mehr Verständnis für die Probleme von Buchhaltern aufbringen. Aus ihrer Sicht gehen sie mehr oder weniger auf gut Glück vor. Da viele Entwickler aber Anhänger von Sir Terry Prachett und der funktionalen Programmierung sind, greifen sie gerne auf Erweiterungsfunktionen zurück. Schließlich soll man es mit dem Verständnis für die Buchhalter nicht übertreiben!

ZDNet.de Redaktion

Recent Posts

Studie: Ein Drittel aller E-Mails an Unternehmen sind unerwünscht

Der Cybersecurity Report von Hornetsecurity stuft 2,3 Prozent der Inhalte gar als bösartig ein. Die…

3 Tagen ago

HubPhish: Phishing-Kampagne zielt auf europäische Unternehmen

Die Hintermänner haben es auf Zugangsdaten zu Microsoft Azure abgesehen. Die Kampagne ist bis mindestens…

4 Tagen ago

1. Januar 2025: Umstieg auf E-Rechnung im B2B-Geschäftsverkehr

Cloud-Plattform für elektronische Beschaffungsprozesse mit automatisierter Abwicklung elektronischer Rechnungen.

4 Tagen ago

Google schließt schwerwiegende Sicherheitslücken in Chrome 131

Mindestens eine Schwachstelle erlaubt eine Remotecodeausführung. Dem Entdecker zahlt Google eine besonders hohe Belohnung von…

4 Tagen ago

Erreichbarkeit im Weihnachtsurlaub weiterhin hoch

Nur rund die Hälfte schaltet während der Feiertage komplett vom Job ab. Die anderen sind…

5 Tagen ago

Hacker missbrauchen Google Calendar zum Angriff auf Postfächer

Security-Experten von Check Point sind einer neuen Angriffsart auf die Spur gekommen, die E-Mail-Schutzmaßnahmen umgehen…

6 Tagen ago