sapscript splitt Standardtext- geht das? Wie?
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Beitrag
von sap_inchen (ForumUser / 21 / 1 /
0
)
»
Hallo Schwestern und Brüder 
Ich habe ein SAPScript-Formular - wie im folgenden dargestellt habe ich auf Wunsch des Anwenders den &PTEXT& an einer anderen Stelle im Formular ausgegeben.
Der einfachste Weg war der dargestellte.
"Unschönerweise" entsteht dadurch an der Stelle von &PTEXT& ein "Loch" (da durch den weiteren Tab hier nichts angedruckt wird.
/* &VBDPL-LFIMG(6.0)&,, ,, &PTEXT& &VBDPL-MATNR&,,&VBDPL-BRGEW(13.2)& LB
VL &VBDPL-LFIMG(6.0)&,, ,, ,,&VBDPL-BRGEW(13.2)& LB
/: INCLUDE &RDGTXTPRT-TDNAME& OBJECT &RDGTXTPRT-TDOBJECT& ID &RDGTXTPRT-TDI
Danach kommt ein Standardtext.
Dieser hat links und rechts entsprechende Ränder das das ungefähr so aussieht:
Gibt es eine Möglichkeit den Standardtext so zu splitten, dass die erste Zeile zwischen die Zeile 1... 100 Kg kommt und der Rest darunter?
Der Standardtext ist ja eine Variable und somit der "ganze Text".
Oder gibt es die Möglichkeit ist im gleichen Textelement (/E)...
Die Problematik ist ja wahrscheinlich auch der Zeilenumbruch zwischen der 1. und 2. Zeile. Man weiß ja nicht sicher, was im Standardtext in der 1. Zeile steht und wenn das zu lang ist, dann muss das ja irgendwie korrekt umgebrochen werden....
Das Include aus dem gedruckt wird ist dazu noch ein Standardinclude...
Bisher habe ich dem Anwender abgeraten, das umzusetzen. Lieber an die Leerstelle irgendetwas bedeutungsloses andrucken - das Loch sieht halt irgendwie "komisch" aus.
Eine Idee wäre vielleicht ein PERFORM aus SAPSCRIPT raus, der den Stadardtext in eine interne Tabelle bekommt. Aber wie drucke ich dann die Tabelle aus...
Oder müsste ich das Standardinclude das dieses Textelement druckt kopieren....
Und dann hier den Splitt durchführen. Aber dann habe ich das gleiche Problem, wie bekomme ich das richtig gesplittet und dann korrekt gedruckt?
Vielleicht hat jemand eine gute Idee?
Vielleicht interessiert die Lösung auch noch andere?
Vielleicht gibt es eine einfache Lösung und ich sehe sie einfach gerade nicht...
Danke für jeglichen Input.
Einen guten Wochenendspurt und einen gutes Wochenende
Tschau
Ich habe ein SAPScript-Formular - wie im folgenden dargestellt habe ich auf Wunsch des Anwenders den &PTEXT& an einer anderen Stelle im Formular ausgegeben.
Der einfachste Weg war der dargestellte.
"Unschönerweise" entsteht dadurch an der Stelle von &PTEXT& ein "Loch" (da durch den weiteren Tab hier nichts angedruckt wird.
/* &VBDPL-LFIMG(6.0)&,, ,, &PTEXT& &VBDPL-MATNR&,,&VBDPL-BRGEW(13.2)& LB
VL &VBDPL-LFIMG(6.0)&,, ,, ,,&VBDPL-BRGEW(13.2)& LB
/: INCLUDE &RDGTXTPRT-TDNAME& OBJECT &RDGTXTPRT-TDOBJECT& ID &RDGTXTPRT-TDI
Danach kommt ein Standardtext.
Dieser hat links und rechts entsprechende Ränder das das ungefähr so aussieht:
Code: Alles auswählen.
Menge Text Gewicht
1 100 KG
blablabla blabla bla
bla bla blablabla bla
Der Standardtext ist ja eine Variable und somit der "ganze Text".
Oder gibt es die Möglichkeit ist im gleichen Textelement (/E)...
Die Problematik ist ja wahrscheinlich auch der Zeilenumbruch zwischen der 1. und 2. Zeile. Man weiß ja nicht sicher, was im Standardtext in der 1. Zeile steht und wenn das zu lang ist, dann muss das ja irgendwie korrekt umgebrochen werden....
Das Include aus dem gedruckt wird ist dazu noch ein Standardinclude...
Bisher habe ich dem Anwender abgeraten, das umzusetzen. Lieber an die Leerstelle irgendetwas bedeutungsloses andrucken - das Loch sieht halt irgendwie "komisch" aus.
Eine Idee wäre vielleicht ein PERFORM aus SAPSCRIPT raus, der den Stadardtext in eine interne Tabelle bekommt. Aber wie drucke ich dann die Tabelle aus...
Oder müsste ich das Standardinclude das dieses Textelement druckt kopieren....
Und dann hier den Splitt durchführen. Aber dann habe ich das gleiche Problem, wie bekomme ich das richtig gesplittet und dann korrekt gedruckt?
Vielleicht hat jemand eine gute Idee?
Vielleicht interessiert die Lösung auch noch andere?
Vielleicht gibt es eine einfache Lösung und ich sehe sie einfach gerade nicht...
Danke für jeglichen Input.
Einen guten Wochenendspurt und einen gutes Wochenende
Tschau
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Hallo,
in der Ausgabezeile wo steht den da die Materialnummer ?
/* &VBDPL-LFIMG(6.0)&,, ,, &PTEXT& &VBDPL-MATNR&,,&VBDPL-BRGEW(13.2)& LB
VL &VBDPL-LFIMG(6.0)&,, ,, ,,&VBDPL-BRGEW(13.2)& LB
Mir erscheint die Zeile in der Kopie nicht vollständig oder doppelt wieder gegeben (BRGEW) und (LFIMG).
Bitte um weiter Infos.
Danke und Gruß
in der Ausgabezeile wo steht den da die Materialnummer ?
/* &VBDPL-LFIMG(6.0)&,, ,, &PTEXT& &VBDPL-MATNR&,,&VBDPL-BRGEW(13.2)& LB
VL &VBDPL-LFIMG(6.0)&,, ,, ,,&VBDPL-BRGEW(13.2)& LB
Mir erscheint die Zeile in der Kopie nicht vollständig oder doppelt wieder gegeben (BRGEW) und (LFIMG).
Bitte um weiter Infos.
Danke und Gruß
Beitrag
von sap_inchen (ForumUser / 21 / 1 /
0
)
»
Sorry, habe mich da wohl wirklich vertan:
Gehen wir davon aus, dass wir 2 Felder rausgenommen haben
Gehen wir davon aus, dass wir 2 Felder rausgenommen haben
Du könntest für die Belegzeile ein Absatzformat der Höhe 0 mm definieren.
Dann wird alles, was danach gedruckt wird sozusagen drüber gedruckt.
Allerdings musst du dann auch sicher sein, dass als nächstes ein Text und nicht die nächste Positionszeile...
Dann wird alles, was danach gedruckt wird sozusagen drüber gedruckt.
Allerdings musst du dann auch sicher sein, dass als nächstes ein Text und nicht die nächste Positionszeile...
Beitrag
von DeathAndPain (Top Expert / 1939 / 257 /
412
)
»
Ich finde das so klasse, dass immer noch Leute in SapScript entwickeln. 
Ich habe vor über 10 Jahren damit aufgehört wegen (damals schon) Steinzeit und kann daher nicht wirklich mehr dabei helfen.
Trotzdem sollte sich jeder, der noch mit SapScript arbeitet, überlegen, ob es nicht mal an der Zeit ist, zu was anderem zu migrieren. Wer auf kein Adobe-, Java- oder Webgeraffel setzen mag (wofür ich durchaus Verständnis habe), dem seien Smartforms ans Herz gelegt. Perfekt ins SapGUI integriert, super zu entwickeln und zu warten (was man von SapScript wahrhaftig nicht sagen kann) und vor allem ist das fertige Dokument auch superleicht zu nutzen, da es in Form eines automatisch generierten komfortablen Funktionsbausteins vorliegt, dessen Output wunderbar weiterzuverarbeiten ist. Da lohnt wirklich auch, bestehende Dokumente zu migrieren. Wie gesagt, habe ich vor über 10 Jahren schon gemacht und es nicht bereut.
Ich habe vor über 10 Jahren damit aufgehört wegen (damals schon) Steinzeit und kann daher nicht wirklich mehr dabei helfen.Trotzdem sollte sich jeder, der noch mit SapScript arbeitet, überlegen, ob es nicht mal an der Zeit ist, zu was anderem zu migrieren. Wer auf kein Adobe-, Java- oder Webgeraffel setzen mag (wofür ich durchaus Verständnis habe), dem seien Smartforms ans Herz gelegt. Perfekt ins SapGUI integriert, super zu entwickeln und zu warten (was man von SapScript wahrhaftig nicht sagen kann) und vor allem ist das fertige Dokument auch superleicht zu nutzen, da es in Form eines automatisch generierten komfortablen Funktionsbausteins vorliegt, dessen Output wunderbar weiterzuverarbeiten ist. Da lohnt wirklich auch, bestehende Dokumente zu migrieren. Wie gesagt, habe ich vor über 10 Jahren schon gemacht und es nicht bereut.
wenn SAP nur SAPScript Formulare liefert, dann bleibt einem keine andere Wahl.DeathAndPain hat geschrieben:Ich finde das so klasse, dass immer noch Leute in SapScript entwickeln.
Trotzdem sollte sich jeder, der noch mit SapScript arbeitet, überlegen, ob es nicht mal an der Zeit ist, zu was anderem zu migrieren. Wer auf kein Adobe-, Java- oder Webgeraffel setzen mag (wofür ich durchaus Verständnis habe), dem seien Smartforms ans Herz gelegt. Perfekt ins SapGUI integriert, super zu entwickeln und zu warten (was man von SapScript wahrhaftig nicht sagen kann) und vor allem ist das fertige Dokument auch superleicht zu nutzen, da es in Form eines automatisch generierten komfortablen Funktionsbausteins vorliegt, dessen Output wunderbar weiterzuverarbeiten ist. Da lohnt wirklich auch, bestehende Dokumente zu migrieren. Wie gesagt, habe ich vor über 10 Jahren schon gemacht und es nicht bereut.
Gruß
coco
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
2748
Views
Views
0
Antw.
Antw.
1068
Views
Views
2
Antw.
Antw.
911
Views
Views
GuiXT Standardtext erfassen bei SD Aufträgen
von dagmard » 10.09.2020 13:59 • Verfasst in ABAP® Core
von dagmard » 10.09.2020 13:59 • Verfasst in ABAP® Core
1
Antw.
Antw.
1686
Views
Views
Standardtext aus So10 in einem cl_gui_textedit darstellen?
von Nordlicht » 11.10.2006 16:20 • Verfasst in ABAP Objects®
von Nordlicht » 11.10.2006 16:20 • Verfasst in ABAP Objects®
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 9 Stunden von DeathAndPain 4 / 685
vor 9 Stunden von DeathAndPain 4 / 685
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 9 Stunden von DeathAndPain 4 / 685
vor 9 Stunden von DeathAndPain 4 / 685