14. April 2013 18:31
Hi,
welch gar nicht so ungewöhnliche Aufgabe... ;) Dürfte mir auch noch zufallen. Das wird machbar sein, aber etwas gewöhnungsbedürftig. Erstmal eine kurze Vorab-Betrachtung:
1. Die. 2.60-Geschäftslogik in der Fibu ist ja schon recht brauchbar. Vereinfacht funktioniert sie genauso wie ein aktuelles NAV. Die Anbindung des Zahlungsverkehrs erfolgt beim buchen dann über T81/CU12, in der 2.60 halt ohne Dimensionen. Auch die Selektion von auszugleichenden Posten funktioniert ähnlich.
2. Um SEPA abbilden zu können braucht man die Stammdaten und die entsprechende Clearing-Codeunit, die das Format abbildet. Den Rest könnte man eigentlich so lassen wie er ist. Oder eben auch nicht (s.u.)
3. Das ganze ist einfacher, wenn die 2.60er DB technisch schon auf einem aktuellen Stand (2009R2) ist. Dann gibt es weniger Schmerzen mit geänderten Objektformaten.
Ich würde mir die aktuellsten Objekte holen die ich bekommen kann, und das gesamte Paket (nicht nur SEPA) entsprechend integrieren. Warum das? In der Hoffnung, bestehende Fehler wurden mittlerweile behoben und durch neue ersetzt
- fob Tabellen einlesen, um fehlende Felder ggf. erweitern: ZV-Bereich (5001900..5001999 oderso) und auch "Standard"-Bereich, aber nur die neuen Felder. Das kann eine ziemliche Fummelei sein.
- fob neue Codeunits einlesen: nur ZV-Bereich - wenn unverändert, dann überschreiben
- fob Reports einlesen: nur ZV-Bereich - wenn unverändert, dann überschreiben
- fob Forms einlesen: nur ZV-Bereich - wenn unverändert, dann überschreiben
Damit sollte man alle Felder und Objekte haben und erstmal nicht in die "Objekt/Feld fehlt" Falle laufen. Diese Objekte müssen auch alle in der Lizenz zugreifbar sein, sie sollte also aktuell (2009R2) sein. Das einlesen der Fobs hat die Feldnamen der ZV-Objekte im C/AL Code durch die in den Tabellen vorhandenen, deutschen ersetzt. Hier hoffe ich einfach mal das kein Feld wiederverwendet wurde und jetzt in der 2009 eine ganz andere Bedeutung hat (nach bisheriger Erfahrung wurde das nicht gemacht).
Dann kommt der anstrengendere Teil: Merge der neuen Funktionalität in die 2.60er Codebasis. Jedes einzelne Objekt mit AR-Kürzel muss überprüft werden. Je nach Vorliebe und Erfahrung mit Versionskontrollsystemen gibt es da unterschiedliche Methoden. Ich benutze z.B. eine Mischung aus Mercurial und Subversion. Was gut ist wenn man es hat sind Textexporte der Basisversion und der jeweiligen Version mit Zahlungsverkehr-Modul, das macht die Vergleiche einfacher. Man kann auch das Mergetool nehmen, das ist ziemlich gut. Für den Hand-Merge kommt dann gelegentlich noch UltraCompare dazu. Allen Methoden gleich ist das man zum schluss eine Textdatei hat, die man wieder in NAV importieren können muss. Das geht aber nur wenn das Objekt schon da ist (nicht eigener Nummernbereich der Lizenz) und man nicht aus versehen Standardfelder löschen oder anlegen will.
Wenn sich dann alles wieder compilieren lässt und auch die Forms wieder schön aussehen, gibts nen Funktionstest.
Es gibt auch für die AR-Objekte ein Upgrade Toolkit. Das könnte bei der Migration der Echtdaten hilfreich sein.
Wenn man wirklich nur die SEPA-Funktion haben will ists evtl. einfacher (keine Migration), der Merge-Teil ist aber trotzdem da - nur nicht so umfangreich.
Ich hoffe das reicht so als Anregung.
LG Jens