SoftMaker.de

Warum ich noch nicht voll auf SoftmakerOffice umgestiegen bin, liegt auch an einem technischen Problem: Mein Fakturierungsprogramm (etwas älter, DOS-Version, aber eine Umstellung kommt nicht in Frage) übergibt einen Druckbefehl bisher in eine Datei, die dann von einem kleinen Programm verarbeitet und an Word weiter gegeben wird, welches dann startet und den Inhalt in entsprechender Briefbogenvorlage einfügt. Dieses Programm wurde von unserem IT-Betreuer selbst gestrickt. Nun möchte ich, dass dies nicht in Word, sondern in TM ausgegeben wird. Leider verstehe ich zu wenig von der Problematik.
Ich weiß nur, dass die Datei mit einem Ascii-Zeichesatz und mit einigen Steuerzeichen herausgegeben wird, dass die Umlaute konvertiert werden müssen, dass irgendein com-server Schnittstelle eine Rolle spielt. Das Ganze soll dann formatiert in der TextMaker Vorlage erscheinen.
Wenn es irgendwie Hinweise für eine Lösung dazu gibt, wäre ich dankbar.
Kann man dies mit Basic-Maker alleine lösen, oder braucht man dazu noch ein kleines Zusatzprogramm?
Bin bereit, weitere Information bereit zu stellen. Welche werden noch benötigt?

mfG PeterQ

Das sollte er recht einfach umbauen können, denn die Befehlsstrukturen sind sich sehr ähnlich.


Ohne die vollständigen Details wird das schwierig...


Es ist zwar noch nicht ganz klar, was da genau gemacht wird, aber ich würde mit den vorhandenen Informationen schon darauf tippen, dass es sich komplett über den BM realisieren lässt.

Ist der EDVler nicht mehr greifbar?

Doch ist er noch. Ich habe ihm auch meinen SoftMakerStick überlassen, damit er sich das mal anschaut, aber so richtig will er noch nicht an die Sache ran.
Ich kann hier ja mal eine Testdatei reinstellen. Mit TM konnte ich zwar was lesen, aber ich weiß nicht, was alles noch so unter der Haube steckt.
Ich habe sie gezippt, da die Datei eigentlich keine Endung hat und somit nicht hier hochladbar war.

Und das müsste dann in meine Briefbogenvorlage.

Es handelt sich um eine Text-Datei mit DOS-ASCII-Codierung. Fügt man manuell die Dateiendung .txt an, kann sie mit jedem Editor geöffnet werden. TM kann sie auch richtig öffnen, wenn man bei Laden als Vorgabe einstellt "Textdatei/DOS".

Allerdings sind darin Codierungen enthalten, die aus Buchstaben, dem Zeichen & und Ziffern bestehen. Diese sind offensichtlich Programmspezifisch, und damit kann TM natürlich nichts anfangen.

Zumindest nicht, ohne sie vorher durch ein Skript bearbeitet zu haben.

Nachtrag:

Grundsätzlich gibt es zwei Adaptionsmöglichkeiten:

1.) Man kann schauen, ob und wie sich die seltsamen Codierungen so umwandeln, "übersetzen" lassen, dass TM sie versteht. Da anscheinend ein Programm zwischen die Adressverwaltung und Word zwischengeschaltet ist, könnte das Problem in diesem liegen.

2.) Man könnte versuchen, eine Word-kompatible DOC-Datei erstellen zu lassen. Diese kann TM nämlich öffnen und verstehen.

(Mein Skript zur Umwandlung von DOC zu TMD und umgekehrt muss zeitbedingt allerdings noch warten.)

Die bereitgestellte Datei kommt so direkt aus dem Fakturierungsprogramm.
Das kleine Programm unseres EDVlers fragt periodisch diese Datei ab und konvertiert diese dann erst zu Word um, inclusive Einbettung in eine Wordvorlage.
Zur Zeit wird ja eine Word-kombatible Doc-Datei ja erstellt. Diese will ich ja ersetzen.

Da ich froh war, so ein kleines Programm für die Konvertierung in Word zu haben (ist eine große Arbeitserleichterung), habe ich gerne auch die Lizenz für das Programm bezahlt und ihm auch versprochen, es nicht weiter zu reichen. Sonst würde ich dies hier auch mal einfach reinstellen, damit die Experten unter die Haube gucken können (falls man überhaupt was erkennen kann).

Ich habe noch mal die Datei aktualisiert reingestellt, da die Ausgabe doch einwenig anders ist. Denn obige Testdatei war ein Druck in eine Datei.
Ich habe den Pfad noch mal rekonstruiert und das Progrämmchen mal ausgeschaltet, damit ich die Datei im Original finde. (Sonst löscht das Konvertierungsprogrämmchen immer die letzte Datei). Es sind doch nicht so viele Steuerzeichen. Allerdings müsste der Zeichensatz in den Umlauten geändert werden und es muss der Seitenumbruch verwendet werden (es sind nämlich nur zwei Seiten).

Genau dieses Programm muss er jetzt auch anpassen. Was er da für die OLE-Automatisierung von Word gemacht hat, kann er fast genauso auch für den Textmaker machen. Die Dokumentation des Objektmodells ist in der Hilfe des BM vorhanden. Mit diesen Informationen kann er im Prinzip direkt loslegen. Das wird zwar möglicherweise nochmal ein bisschen Geld kosten, dann hast Du es aber.

Wie bereits erwähnt: TM kann eine Word-DOC-Datei lesen und verstehen. Wenn man diesen "Umweg" gehen will, braucht es also keine Veränderung.

Die Datei "XXST" ist eine reine DOS-ASCII-Datei. Wie ebenfalls bemerkt, lässt sich diese direkt in TM importieren bzw. von diesem öffnen. Eine DOS->Windows-Konversion ist daher nicht unbedingt nötig.
Zu fragen wäre, ob es möglich ist, die Formatvorgaben in der "Quelle", also der Adressverwaltung, zu ändern. Dort müssten ggf. Leerzeilen entfernt werden u. dgl. Wenn das einmal justiert wäre, könnte man jedes "Rohprodukt" unmittelbar wie eben beschrieben in TM übernehmen, das Konversionsprogramm wäre dann überflüssig.

Eine andere Methode käme ebenfalls in Frage:
Kann die Quelle, also die Adressverwaltung, DBF-Dateien exportieren?
Wenn ja (die meisten derartigen Programme sollten das eigentlich können), dann könnten die jeweils notwendigen Adressen in eine DBF-Datei exportiert werden. Der eigentliche Brieftext müsste ein Mal in TM erstellt und gestaltet werden, danach genügte es, jeweils die entsprechende DBF-Datei auszuwählen und die Serienbrieffunktion zu starten. Dafür verweise ich auf Handbuch und Hilfe.

Das Programm übergibt -- das ist einzige Schluss, den die Ausführungen des OP erlauben -- die Daten an eine vorhandene Word-Vorlage, also ganz klassische OLE-Automatisierung.

Ich will dem Programmierer nicht zu nahe treten, aber ich kann mir ernsthaft nicht vorstellen, dass er aus dem nichts ein Word-Dokument erzeugt

Vielen Dank an das rege Interesse an dem Thema. Ich will versuchen auf die einzelnen Antworten einzugehen. Ich freue mich auch über so manches Kostenlose Geschenk, aber ich weiß auch, dass jede Arbeit einen Wert hat und dafür angemessen Geld fliessen sollte. Der Umweg sollte eigentlich nicht sein. Denn auf dem neuen Rechner will ich eben nicht MSO haben (müsste ich nämlich neu lizenzieren und da würde ich doch lieber das Geld bei SM lassen)
Wenn nicht das Problem der Umlaute wäre. Auch kann ich in der jetzigen Lage, den Schrifttyp und die Schriftgröße aussuchen.
Gewisse Veränderungen können auch schon an der Quelle verändert werden, u.a. Leerzeichen.
Nein
Das wird so sein. Es existiert eine Wordvorlage, die ich auch bei Bedarf verändern kann (z.B. Bankverbindung). Die hat er aber irgendwo abgespeichert. Wo eigentlich? Müsste mal auf die Suche gehen. Ich komme jedenfalls über sein kleines Programm an die Vorlage.

Insgesamt klingt es so, als ob es nicht allzu schwierig wäre, Word durch Textmaker zu ersetzen. Falls mein Programmierer nicht zu einer Lösung kommt, könnte ich denn einen von euch Fachleuten ansprechen, um mir so ein Progrämmchen zu stricken?

Schwierig oder leicht - das kommt auf die Optik an.

Grundsätzlich sollte es schon hinzukriegen sein, aber ...

Wir wissen bis jetzt nicht, wie die Sache funktioniert.
Liegt die Datenaufbereitung in der Adressverwaltung oder im dazwischengeschalteten "Programm"?
Handelt es sich um ein echtes Programm oder um ein Skript? Falls um ein Skript: VBA oder ...?
Wird die DOC-Datei mittels Fernsteuerug (Scripting) von Word erstellt, durch das "Programm" oder wie?

Solange diese und ggf. weitere Fragen nicht klar beantwortet sind, stochern wir bloss im Nebel.

Wie ich schon sagte: Umlautkonvertierung ist sicher nicht das Problem, TM kriegt das grundsätzlich selbst hin.

Statt obskure Programme zu adaptieren, stellt sich mir nach wie vor die Frage, ob es nicht einen einfacheren (direkten) Weg zwischen Adressverwaltung und TM gäbe. Wenn die Adressverwaltung Textdateien erzeugen kann, kann sie doch gewiss dazu gebracht werden, Werte als Comma separated value zeilenweise in eine Datei zu schreiben. Eine solche Datei kann man immer in eine DBF-Datei umwandeln. Mit etwas mehr Aufwand könnte man auf dem gleichen Weg evtl. auch unmittelbar eine DBF-Datei erzeugen.
Dann Formular in TM gestalten, DBF verknüpfen, Serienbrieffunktion starten, c'est tout.

Man müsste solche Möglichkeiten einmal seriös prüfen. Ansonsten können wir weiterhin bloss im Nebel stochern.

Eine CSV-Datei kann direkt als Serienbriefquelle verwendet werden, ohne sie vorher in eine DBF umzuwandeln.

_________________
Martin Kotulla
SoftMaker Software GmbH

Das trifft zu.

In TM unter "Weiteres / Datenbank zuordnen" lässt sich auch eine CSV-Datei auswählen. Im "Öffnen"-Dialog muss man nur "Textdatei mit DOS-Zeichensatz (*.txt, *.csv)" als Dateityp auswählen. Damit kommen auch die Umlaute richtig in TM an.

Somit scheint mir mein "dritter Weg": Adressquelle umkonfigurieren und mittels Serienbrieffunktion direkt TM ansprechen, nach wie vor und erst recht der am ehesten zu verfolgende.

Noch ein Wort zu DBF:
Warum ich etwas auf DBF herumreite, hat damit zu tun, dass es eben nach wie vor faktisch der Kompatibilitäts-Standard ist. Viele Anwendungen, die einfachere Datenbankfunktionen benutzen, lesen und schreiben DBFs. Ich habe hier z. B. eine Print-Anwendung eines Herstellers von Druckerpapier, -folien, -klebern usw. und ein elektronisches Zahlungsprogramm für meine Hausbank - beide arbeiten mit DBF.
Der Witz an DBF ist ausserdem, dass die Codierung intern in DOS-ASCII erfolgt, jedenfalls in den meisten Fällen. Dies zum Umlaut-Problem.
TM (wie auch PM) ist insofern etwas weiter, als darin DBF/DOS, DBF/Win und DBF/Unicode unterstützt werden - viele Programme unterstützen aber nicht alle drei DBF-Codierungen.

So, das musste auch mal gesagt bzw. geschrieben sein.

@Panosis
Die Datei, die ich in eine Vorlage von TM einbinden möchte, wird aus einem Fakturierungsprogramm in eine Datei gedruckt. Die Beispieldatei xxst ist das, was aus dem Fakturierungsprogramm praktisch herauskommt.
In meinem Fakturierungsprogramm kann ich selbstverständlich alle Angebote, Auftragsbestätigungen, Lieferscheine, Rechnungen, Mahnungen, Bestellanfrage und Bestellungen über den normalen Drucker ausdrucken.
Aber ich habe auch die Möglichkeit über eine Pfadangabe in xxst zu drucken. Das Ergebnis ist oben angeführte Datei.

Ziel ist es, diese Datei in eine TM-Vorlage zu drucken, damit ich diese, je nach Bedarf faxen oder per pdf versenden kann. (Denn das kann das Fakturierungsprogramm nicht.) Wie es jetzt aussieht ist in folgender Datei "Beispiel_.zip" zu sehen.

Auf welchen Weg das realisiert wird, ist mir eigentlich egal. Es sollte auf jeden Fall komfortabel für mich sein. (Also nicht: xxst öffnen, markieren, kopieren, in Vorlage einfügen, formatieren in eine monospace Schrift incl. Umlaute und Schriftgröße und Schriftgewicht.) Jetzt ruft eben das kleine Programm jede Sekunde wohl ab, ob es eine xxst Datei gibt. Wenn ja macht es alles, was zu der Beispieldatei führt, d.h. es startet Word und ich sehe das Word-Dokument auf meinem Desktop.

Ohne Details zu wissen, könnte ich mir das so vorstellen: Ein Skript erledigt diese oben geschilderten Vorgänge. Zusätzlich sollte dieses Skript auch die xxst Datei nach dem Kopiervorgang löschen, da ansonsten die einzelnen "Druck"ausgaben, hintereinander eingespeichert werden.

So, ich hoffe dass ich den Vorgang etwas erhellen konnte.

Leider kenne ich mich mit BasicMaker nicht so aus und es fehlt mir einfach die Zeit, um mich da einzuarbeiten (obwohl es mich reizt).