Jun 1

Erstellt von: SuperUser
01.06.2010 19:24 

Es ist manchmal wirklich nicht zu glauben, wie eng die Dinge miteinander verknüpft sind und wie vermeintliche Nichtigkeiten zu einem Problem werden können. Wir haben aus der nachfolgenden Begebenheit jedenfalls wieder etwas gelernt, das wir gerne mit Ihnen teilen möchten.

Zum Hintergrund: Wir verwenden bei Anker die SQL Reporting Services, um aus unserem ERP-System Berichte zu erstellen. Ein solcher Bericht, den es zu erstellen galt, hat mit unserer ERP-Zertifizierung zu tun. Wir haben ein sogenanntes MSC “Chain of Custody” – Zertifikat, was besagt, dass wir die notwendigen Kompetenzen haben, um Teil einer MSC Lieferkette zu sein, was insbesondere heißt, dass wir sicherstellen können, dass in einem Produkt, das als MSC-Produkt gekennzeichnet ist, auch wirklich MSC-Rohware enthalten ist.

Dieses Zertifikat wird einmal jährlich durch einen externen Auditor überprüft und ggf. erneuert. Dem Prüfer muss lückenlos die Verwendung der eingesetzten Rohware dokumentiert werden ebenso wie ein Plausibilitätsprüfung der eingesetzten Mengen.

Dieses wollten wir mit einem Report auf Basis der SQL Reporting Services automatisieren. Der Report greift auf die Fertigungsaufträge im ERP-System zu und stellt die IST-Meldungen den gebuchten Verbräuchen gegenüber. Sodann soll in einer Fußzeile für jeden Fertigungsauftrag die Ausbeute, also der Verbrauch pro hergestellter Einheit berechnet werden. Es ist dies die Summe aller Verbräuche dividiert durch die Summe aller Istmeldungen. Siehe nachfolgenden Screenshot.

Das Problem bestand in der Berechnung des Verbrauchs pro Einheit. Da die Istmeldungs- und die Verbrauchszeilen alle in einer Tabelle stehen und nur durch die Spalte “Art” oder das Vorzeichen der Menge unterschieden werden konnten, wurde so etwas wie eine SUMIF – Funktion bei Excel benötigt, die die SQL Reporting Services aber nicht haben.

Wir haben diese Verhalten in den Reporting Services durch folgenden Ausdruck nachgebaut:

=ABS(Sum(IIF(Fields!Entry_Type.Value = 5, Fields!Quantity.Value, 0))/Sum(IIF(Fields!Entry_Type.Value = 6, Fields!Quantity.Value, 0)))

Verbrauchsbuchungen werden im Feld [Entry_Type] mit 5 gekennzeichnet, Istmeldungen mit 6. Ist also im Feld [Entry_ Type] eine 5, wird das Feld Quantity in die zu bildende Summe einbezogen, ansonsten 0. Gleiches wird für die Istmeldungen mit [Entry_ Type] 6 gemacht. Beide Summen werden dividiert und daraus der positive Wert gebildet.

Dieser Ausdruck wird vom SQL Reporting Services Compiler als gültig erkannt und doch wird statt der 0,14 im obigen Beispiel #Error ausgegeben.

Es ist nicht eindeutig, warum.

Nach einigem Probieren kamen wir zu dem Schluss, dass es sich evtl. um ein Typenproblem handeln könnte, da der Ausdruck funktionierte, wenn wir statt des Feldes eine Integerzahl hart codierten.

Wir wandelten den Ausdruck wie folgt um und casteten alle Ausdrücke explizit in einen Integer – Value

=ABS(Sum(IIF(Fields!Entry_Type.Value = 5, CInt(Fields!Quantity.Value), CInt(0)))/Sum(IIF(Fields!Entry_Type.Value = 6, CInt(Fields!Quantity.Value), CInt(0))))

und siehe da. Es funktioniert wie oben zu sehen.

Eines wird deutlich, was formal richtig ist, muss noch lange nicht in der Ausführung richtig sein. Uns wurde jedenfalls vor Augen geführt, wie wichtig die explizite Typenkonvertierung ist. Man muss sicher sein können, was in einer Variablen steckt.

Dieses Beispiel lässt sich interessanterweise auch auf unsere Produkte übertragen. Aber Sie können sicher sein, dass in unseren Verpackungen immer die ANKER-Premiumprodukte stecken. Das “Casten” übernehmen wir.