Spezialfrage zu Excel 10

[Airlag]

Hallo Gemeinde,

 

ich habe ein ganz vertracktes Problem. Ich habe hier eine Datei, die in Excel importiert werden soll. Das Format kann ich noch in gewissem Umfang beeinflussen, solange es ein Textformat ist.

 

In dieser Datei kommen Feldinhalte in der Form "-A" vor. Und da beginnt das Problem. Ganz gleich ob ich Ascii mit Tabs oder eine richtige CSV Datei mit korrekt gesetzten Anführungszeichen mache, Excel 10 macht aus "-A" "=-A", interpretiert dies als Formel und läuft auf einen Fehler bei der Berechnung. Dabei darf es gar nicht erst in eine Formel umgewandelt werden.

Das Problem tritt sogar dann auf, wenn man den Feldinhalt manuell eingibt oder ihn aus dem Clipboard einfügt.

 

Wie kann man diese Autokorrektur abschalten?

[Livia]

Wahrscheinlich zu simpel: Wie wäre es damit, einfach die Zelle als Text zu formatieren? Habe es gerade ausprobiert, ich kann dann -A einfügen.

[draco2111]

Ab Minute 5 wirds interessant:

 

[Airlag]

@Livia das versuche ich gerade, indem ich Excel fern steuere und die Daten übers Clipboard schicke.

 

@Draco2111 Ja, das kenne ich, aber das ist für die hiesigen Anwender zu kompliziert, manuell eine Spalte explizit als Textspalte beim Datei laden zu deklarieren Ausserdem müssten sie da jedesmal dran denken, was sie spätestens nach 3 Tagen nicht mehr tun.

[Sirana]

Könntest du in die zu importierende Datei '-A schreiben? Dann wird das erzwungenermaßen als Text interpretiert.

[sayah]

sag doch etwas mehr über die Ausgangsdatei und welche Technologie/ Datenformate du dort auswählen kannst, respektive aus welcher Quelle/ Programm deine Daten kommen. Angenommen du könntest einen Import/ Export Filter basteln, der die entsprechende Formatierung mitgibt, sollte das alles kein Problem mehr sein. Wenn du dich genau genug auskennst, Microsoft 'liebt' XML. Wenn du also die Daten in ein xml file schreiben lässt, dort festlegst, dass die entsprechende Felder passenden Dateitypen entsprechen müssen, sollte Excel diese Formatierung übernehmen, meine ich. Zugegeben, das ist etwas mühsam aufzusetzen, dafür wenn du alles richtig machst, solltest du die entsprechenden Operationen per VBA steuern können, was heisst, deine Anwender bekommen von alledem nichts mehr mit, sprich können auch nichts mehr falsch machen (dafür haben sie dann auch keinen blassen Schimmer was wirklich geschieht).

Alternativ, du schreibst dir ein Macro (der Macrorecorder von Excel liefert vernünftige Resultate, soll heissen man lässt ihn arbeiten und mistet den Code anschliessend aus, so dass was brauchbares entsteht) dass die Formatiertung der Felder wie benötigt beim öffnen der Datei festlegt. Das sollte dein Problem auch lösen. Oder noch einfacher, du machst ein Template in das deine User die gelieferte Datei laden müssen und in dem alles schon entsprechend formatiert ist.

es grüsst

Sayah el Atir al Azif ibn Mullah

[Kazzirah]

Grundfrage ist ja, was genau soll später mit diesem Wert passieren?

Bzw. ist wichtig, welchen Wert das Feld anzeigt / zurückgibt (also "-A"), oder muss in dem Excelfeld genau "-A" stehen?

Letzteres ist wesentlich schwerer.

Das Problem scheint mir, dass der Wert für weitere Berechnungen verwendet wird, damit dürfte das Escapen mit dem Hochkomma ausfallen. Beim ersten Import wird das dann ja auch meist noch angezeigt, verschwindet dann beim nächsten laden aus der Anzeige.

 

Kann es eventuell helfen, wenn du im CSV-File eine Formel eingibst, die dir genau diesen Rückgabewert hat:

 

=ZEICHEN("45") & "A"

=("-A")

 

beide werden im Excelfeld dann als -A interpretiert. Und in weiteren Formeln auch als solches verwendet.

[Airlag]

Wichtig ist, dass in Excel das steht, was man sieht, weil die Daten später wieder zurück in SAP importiert werden müssen. Und da wäre '-A auch ein legaler Eingabewert, genauso wie =-A oder -A.

 

Ich habe das Problem jetzt so gelöst, dass ich Excel fern steuere, die Felder der Seite vorab zu Textfeldern formatiere und dann die Inhalte gesammelt übers Clipboard rein kopiere. Dann noch abspeichern und gut ist

 

Der SAP standard Funktionsbaustein ging über eine .DAT Zwischendatei, hat dann Excel geöffnet, die Datei geladen und als XLS neu gespeichert. Seit Excel 10 funktioniert der FuBa aber nicht mehr sauber, wegen dem oben beschriebenen Problem.

 

P.S.: ich glaub' dieser Strang kann mit 'Excel - Anwendungsfrage' gemerget werden.

Bearbeitet 13. April 2012 von Airlag

[Kazzirah]

Ah, sag doch, dass du das aus SAP machst.

Scheint, dass ihr da keine Performance-Anforderungen hab bei dem Export.

Wir hatten bei einer unserer Lösungen zum Down-und Upload von Einkaufsbelegen nach Excel auch solche Probleme, insbesondere bei der Kompatibilität der einzelnen Excel-Versionen.

Ich vermute einmal, das entstehende Excel soll Makrofrei funktionieren. Der SAP-Export macht so was, was aber ... unschön ist.

Die gängigen Exporte aus SAP nutzen HTML oder neuer XML. Zumals neues Excel ja selbst eine XML-Datei ist,

Du kannst also eigentlich auch die Tools von SAP nutzen, um ein XML zu generieren. Du kannst z.B. einmal eine für dich korrekte Excel-Datei speichern (als xlsx), dann die Erweiterung in zip umbenennen. Da ist dann je nach Excel-Version vierschiedene Daten drin, vor allem die Daten-XML. Das öffnen und mal schauen, was das da formatiert um deinen Wert rum.

 

Der Schnittstellenzugriff per Fernsteuerung im Excel ist halt extrem unperformant, ich hab schon mal nen halbe Stunde auf ein mittlegroßes Excel gewartet. War da aber der einzige Weg leider.

[Airlag]

Der Schnittstellenzugriff von SAP auf Excel ist langsam, ja.

Aber eine halbe Stunde wartet man nur, wenn man die Zellen einzeln füllt. Man kann problemlos 10.000 Datenzeilen über's Clipboard nach Excel schieben. Das ist dann in 1 Sekunde erledigt. Die Ladezeit von Excel habe ich da jetzt nicht mit rein gerechnet

[Kazzirah]

Mal ne dumme Frage: Im SDN hast du schon mal rumgesucht oder gefragt? Das ist ja jetzt nicht zu speziell. Aber SAP hat unendliche Mengen an mehr oder minder sinnvollen Excel-Export-Bausteinen. Wir exportieren mittlerweile eigentlich nur noch XMLs, die dann in Excel gelesen werden.

Die Kollegen, die ich dazu gefragt habe, haben dein Problem aber auch noch nicht gehabt. Daher kann ich da auch nur im dunklen rumstochern.

Eventuell mal eben das Excel korrekt aufbauen, als XML speichern, daraus ein Template erstellen, und das als Vorlage für den Export benutzen. Für XML-Export bietet SAP auch einige Hilfsmöglichkeiten. (Okay, hängt vom Systemstand ab. Je nachdem wie antiquiert ihr rumfahrt, könnte das natürlich fehlen. )

[Airlag]

Hier im Konzern hat jede Landesgesellschaft ihren eigenen Server, die Releasestände sind sehr unterschiedlich. Deshalb gilt

 

Regel Nr. 1: Benutze nach Möglichkeit keine Features, die nicht schon in Sap R/3 Release 4.6C existierte, weil das das älteste Release ist, das im Konzern eingesetzt wird. Wir machen Service für alle Landesgesellschaften.

 

Dasselbe gilt für Office. Zwischen 95 und 2010 gibts hier alles, je nachdem in welchem Land man ist.

 

Genau darüber bin ich auch bei einer anderen Sache gestolpert. Sachkonten einspielen mittels BAPI - gibts erst seit September 2011 und nur in ERP 6.0. Also zurück zu Batch Input/Call Transaction, weil das Programm auch in anderen Ländern eingesetzt werden soll.

 

Abgesehen davon, das Problem ist gelöst, bin schon am übernächsten.

[Kazzirah]

Dann würde mich dennoch dein Lösungsweg interessieren.

 

Bezüglich Releasestand: Mein Beileid. Lass mich raten, ihr scheut den Aufwand, das zu harmonisieren.

Aber ich kenn das Problem, wir müssen unsere Lösungen ja auch möglichst abwärtskompatibel halten, weil nicht jeder Kunde den aktuellsten SAP Release einspielen will.

[Airlag]

Ich verweise auf Posting Nr. 8 in diesem Strang.

[Kazzirah]

Ah, die "Wurstbrotlösung" Hört sich... experimental an.

[sayah]

Hier im Konzern hat jede Landesgesellschaft ihren eigenen Server, die Releasestände sind sehr unterschiedlich. Deshalb gilt

 

Regel Nr. 1: Benutze nach Möglichkeit keine Features, die nicht schon in Sap R/3 Release 4.6C existierte, weil das das älteste Release ist, das im Konzern eingesetzt wird. Wir machen Service für alle Landesgesellschaften.

 

Dasselbe gilt für Office. Zwischen 95 und 2010 gibts hier alles, je nachdem in welchem Land man ist.

 

Genau darüber bin ich auch bei einer anderen Sache gestolpert. Sachkonten einspielen mittels BAPI - gibts erst seit September 2011 und nur in ERP 6.0. Also zurück zu Batch Input/Call Transaction, weil das Programm auch in anderen Ländern eingesetzt werden soll.

 

Abgesehen davon, das Problem ist gelöst, bin schon am übernächsten.

 

Wie häufig muss denn auf diese Daten zugegriffen werden? könntest du die Daten auf einem zentralen Server verarbeiten (zB jeweils um Mitternacht) um sie dann zu verteilen?

Wie auch immer, ich habe mal folgende Lösung gesehen, es ging dort darum, dass Excel die zu verarbeitenden Datenmenge nicht abspeichern konnte: Im Hintergrund und unsichtbar für den Benutzer lief eine Access Datenbank bestehend im wesentlichen aus einer Tabelle, die die Daten speicherte um sie nach Bedarf an Excel zu übergeben. Für dich, du transferiest alle Daten aus SAP in die Accessdatenbank, die älteste Version die irgendwo läuft und unterstützt werden muss und übergibst die Daten von dort. Richtig, das ist etwas umständlich, nur mit den Formatvorgaben von Access solltest du garantieren können dass alle Daten das jeweils richtige Format haben etc.

Zuletzt, sprich mit dem zuständigen Manager, zeige an diesem Beispiel auf wieviel Kosten, Umstände und Unsicherheit entstehen, weil die Firma keinen einheitlichen Standard durchsetzt und wirb so dafür dass alle Nutzer in Sachen Software auf einen einheitlichen Stand gebracht werden. Wenn du das rhetorisch richtig anrichtest, müsste er für solche Argumente (Kosten, Datensicherheit) empfänglich sein und die für das Update notwendigen Gelder freimachen.

es grüsst

Sayah el Atir al Azif ibn Mullah

[Kazzirah]

@ sayah: Meine Erfahrung mit so Sachen ist, dass die Migrations- und Integrationskosten dennoch so lange absolut abschrecken, bis die Schnittstellen hinreichend viele schwerwiegende Fehler produzieren.

Insbesondere hast du es in einer solchlen Konzernlandschaft selten mit dem einen Manager zu tun, der das entscheidet. Natürlich hat jede dieser Landschaften selbst mindestens einen eigenen zuständigen Manager. Du musst die alle zusammen auf einen Nenner bringen, du musst davon ausgehen, dass kaum ein real lebendes SAP-System ohne zum Teil massive kundeneigene Erweiterungen unterwegs sind, was weitreichende Konsequenzen nach sich ziehen kann, wenn da ein Upgrade stattfindet. Dann hast du selten einheitliche Prozesse abgebildet, bleibst letztlich also auf deinem Schnittstellenproblem auf anderen Niveau hängen, und selbst wenn du das löst, sind einige Tausendschaften meiner Kollegen für die nächsten zwei / drei Jahre vollauf beschäftigt, überhaupt in die Nähe eines Go-Lives zu kommen.

Und dann kommt das, was die eigentlich relevanten Manager, also die nicht-ITler wirklich tangiert: Wie verklicker ich's meinen Mitarbeitern, dass unser gut funktionierender Arbeitsablaufprozess durch neue Oberflächen, verwirrende Meldungstexte, neue Schritte, neue Aufrufe, die aber das gleiche tun, ersetzt werden sollen und sie nun alle damit glücklich sein sollen. Läßt du allen ihre spezialspielzeuge, ist die Harmonisierung wartungstechnisch auch wieder für die Katz, weil du die gleichen Prozesse immer noch mehrfach laufen hast.

Nebenbei produzierst du unmengen an zusätzlichen Fehlerpotentialen (was der Grund ist, dass so eine Harmonisierung in der Regel 2-3 Jahre dauern kann, ich hab auch schon mehr erlebt). Und da sind dann immer noch Nachzügler zu erwarten.

Und nebenbei wirst du immer Prozesse haben, die due auf der neuen Plattform schlechter abbilden kannst.

 

Auch wenn ich zu der anderen Seite gehöre, die an solchen Upgrades (teilweise schon spannend genug, so am laufenden Betrieb) und noch mehr, wenn da verschiedene Systemkonfigurationen mit verschiedenen Releaseständen rumwuseln. Ich kann Airlag da schon verstehen, da will ich nicht ran, wenn ich nicht unbedingt muss.

[Ma Kai]

Insbesondere hast du es in einer solchlen Konzernlandschaft selten mit dem einen Manager zu tun, der das entscheidet. Natürlich hat jede dieser Landschaften selbst mindestens einen eigenen zuständigen Manager.

 

Insbesondere: derjenige, dem die Uraltversion draußen in der Pampa gehört, ist meist nicht derjenige, der die Dreifachmehrkosten für die zentrale Programmierung trägt. Das wird nur ganz selten im Detail heraus belastet (und wenn, dann bezweifelt der in der Pampa die Kalkulation und das Ganze geht am Controllergezerre zugrunde...).

[Airlag]

@sayah, ich mache hier Support und schreibe solche Zusatzprogramme wie oben beschrieben.

Ich habe weder mit den Entscheidern für einen strategischen Richtungswechsel dieses Weltkonzerns zu tun noch habe ich vor, mich in die in diesen Regionen herrschenden Machtkämpfe verwickeln zu lassen. Deine beschriebene Vorgehensweise würde vielen Ländergesellschaften ihre EDV-Souveränität beschneiden, was immer zu ziemlichen Grabenkämpfen führt.

 

Ausserdem lebe ich von deren Mismanagement und der nicht harmonisierten Rechnerlandschaft