=?iso-8859-1?Q?=DCbertrag_auf_mehrseitigem_Dokument_=28z.B._Rechnung=29?=

Hallo,

da meine Frage zu einem uralten Beitrag leider auch vom Datum her diesem
zugeordnet wird, hat sie wohl noch niemand gelesen :slight_smile: also folgt sie hier
noch mal, zusammen mit dem Auszug aus dem Original-Posting dazu:

Ich muss hier mal diesen uralten Eintrag aufwÀrmen, da ich in diesem
Zusammenhang ein Problem habe. Ich habe in einem List & Label Projekt fĂŒr
Rechnungen auch einen solchen Übertrag auf genau dem genannten Weg erstellt,
funktioniert auch einwandfrei - fast: Mein Problem ist, dass die einzelnen
Rechnungsposten möglicherweise wenn sie sehr lang werden umbrechen und auf
der nĂ€chsten Seite fortgesetzt werden. In diesem Fall rechnet L&L “falsch”
(aus seiner Sicht natĂŒrlich schon korrekt). Da der Übertrag am Anfang eines
Postens, also OBEN und nicht UNTEN steht, was auch ausdrĂŒcklich so gewĂŒnscht
ist, steht zwar der Preis eines umgebrochenen Postens noch auf der Seite,
wird aber nicht in den Übertrag eingerechnet, weil der Posten ja auf der
nÀchsten Seite weitergeht und der Folgeseite zugerechnet wird. LÀsst sich
das umgehen? Dazu muss ich sagen, dass hier noch die alte L&L Version 11 zum
Einsatz kommt.

Vielen Dank,
Tobias

Bei einer Suche bin ich auf Deinen Beitrag gestoßen.
Habe das Problem kĂŒrzlich gelöst. Der Weg ist wie folgt:

  1. Du legst fĂŒr den Übertrag eine Fusszeile fest. (Bei mir heißt sie
    “Übertrag”)
    In dieser Gestaltest Du die Darstellung deines Übertrages und gibts ihr
    die Darstellungsbedingung >>Totalpages$()<>“1” and not Lastpage()<<
  2. kreierst Du eine Kpfzeile mit dem Übertrag.
    Diese erhÀlt die Darstellungsbedingung Val(Page$())>1
  3. FĂŒr den Übertrag erstellst Du eine Summenvariable in der Du den zu
    Übertragenden Wert aufsummierst
    und den Du dann in die beschriebene Fuß- und Kopfzeile einbindest.

Durch die Bedingungen ist gewĂ€hrleistet, dass im Fuss nur ein Übertrag
erscheint wenn es mehr als eine Seite gibt
und im Kopf der Übertrag erst ab der 2. Seite auftaucht.

Damit sind, zumindest bei mir, alle diesbezĂŒglichen Probleme gelöst.
Wenn Du willst kannst Du auf diese Weise in einer Zeile auch mehrere
ÜbertrĂ€ge (StĂŒckzahl, Rabatt, Preis, etc.) setzen.

Schau mal bei LL_OPTION_CALC_SUMVARS_ON_PARTIAL_LINES nach.
Paulchen (der jetzt grad keine Ahnung hat, ob es das auch bei LL11
gab
)

“Tobias Bucher” <tbucher@g
> wrote in message
news:80022102009135447@combit.net


Hallo,

da meine Frage zu einem uralten Beitrag leider auch vom Datum her
diesem
zugeordnet wird, hat sie wohl noch niemand gelesen :slight_smile: also folgt
sie hier
noch mal, zusammen mit dem Auszug aus dem Original-Posting dazu:

Ich muss hier mal diesen uralten Eintrag aufwÀrmen, da ich in diesem
Zusammenhang ein Problem habe. Ich habe in einem List & Label
Projekt fĂŒr
Rechnungen auch einen solchen Übertrag auf genau dem genannten Weg
erstellt,
funktioniert auch einwandfrei - fast: Mein Problem ist, dass die
einzelnen
Rechnungsposten möglicherweise wenn sie sehr lang werden umbrechen
und auf
der nÀchsten Seite fortgesetzt werden. In diesem Fall rechnet L&L
“falsch”
(aus seiner Sicht natĂŒrlich schon korrekt). Da der Übertrag am
Anfang eines
Postens, also OBEN und nicht UNTEN steht, was auch ausdrĂŒcklich so
gewĂŒnscht
ist, steht zwar der Preis eines umgebrochenen Postens noch auf der
Seite,
wird aber nicht in den Übertrag eingerechnet, weil der Posten ja auf
der
nÀchsten Seite weitergeht und der Folgeseite zugerechnet wird. LÀsst
sich
das umgehen? Dazu muss ich sagen, dass hier noch die alte L&L
Version 11 zum
Einsatz kommt.

Vielen Dank,
Tobias

Bei einer Suche bin ich auf Deinen Beitrag gestoßen.
Habe das Problem kĂŒrzlich gelöst. Der Weg ist wie folgt:

  1. Du legst fĂŒr den Übertrag eine Fusszeile fest. (Bei mir heißt
    sie
    “Übertrag”)
    In dieser Gestaltest Du die Darstellung deines Übertrages und gibts
    ihr
    die Darstellungsbedingung >>Totalpages$()<>“1” and not Lastpage()<<
  2. kreierst Du eine Kpfzeile mit dem Übertrag.
    Diese erhÀlt die Darstellungsbedingung Val(Page$())>1
  3. FĂŒr den Übertrag erstellst Du eine Summenvariable in der Du den
    zu
    Übertragenden Wert aufsummierst
    und den Du dann in die beschriebene Fuß- und Kopfzeile einbindest.

Durch die Bedingungen ist gewÀhrleistet, dass im Fuss nur ein
Übertrag
erscheint wenn es mehr als eine Seite gibt
und im Kopf der Übertrag erst ab der 2. Seite auftaucht.

Damit sind, zumindest bei mir, alle diesbezĂŒglichen Probleme
gelöst.
Wenn Du willst kannst Du auf diese Weise in einer Zeile auch
mehrere
ÜbertrĂ€ge (StĂŒckzahl, Rabatt, Preis, etc.) setzen.

Das klingt gut und nach genau der Option die ich suche - offenbar wurde die
auch genau in LL11 eingefĂŒhrt. Aber kann mit jemand sagen, welchem Wert sie
entspricht? Trotz korrekter usings (c#) usw. gelingt ein Aufruf in folgender
Form nicht:

_ll.Core.LlSetOption(LL_OPTION_CALC_SUMVARS_ON_PARTIAL_LINES, 1)

Weil LL_OPTION_CALC_SUMVARS_ON_PARTIAL_LINES natĂŒrlich nicht definiert ist
und ich auch keine Dokumentation finde, in der der entsprechende int-Wert
stĂŒnde bzw. auch keine Enumeration die das hergibt?!

Viele GrĂŒĂŸe,
Tobias

“Paul Schmidt” <paulchen4@hotmai
> schrieb im Newsbeitrag
news:380802102009154821@combit.net


Schau mal bei LL_OPTION_CALC_SUMVARS_ON_PARTIAL_LINES nach.
Paulchen (der jetzt grad keine Ahnung hat, ob es das auch bei LL11
gab
)

“Tobias Bucher” <tbucher@g
> wrote in message
news:80022102009135447@combit.net


Hallo,

da meine Frage zu einem uralten Beitrag leider auch vom Datum her
diesem
zugeordnet wird, hat sie wohl noch niemand gelesen :slight_smile: also folgt
sie hier
noch mal, zusammen mit dem Auszug aus dem Original-Posting dazu:

Ich muss hier mal diesen uralten Eintrag aufwÀrmen, da ich in diesem
Zusammenhang ein Problem habe. Ich habe in einem List & Label
Projekt fĂŒr
Rechnungen auch einen solchen Übertrag auf genau dem genannten Weg
erstellt,
funktioniert auch einwandfrei - fast: Mein Problem ist, dass die
einzelnen
Rechnungsposten möglicherweise wenn sie sehr lang werden umbrechen
und auf
der nÀchsten Seite fortgesetzt werden. In diesem Fall rechnet L&L
“falsch”
(aus seiner Sicht natĂŒrlich schon korrekt). Da der Übertrag am
Anfang eines
Postens, also OBEN und nicht UNTEN steht, was auch ausdrĂŒcklich so
gewĂŒnscht
ist, steht zwar der Preis eines umgebrochenen Postens noch auf der
Seite,
wird aber nicht in den Übertrag eingerechnet, weil der Posten ja auf
der
nÀchsten Seite weitergeht und der Folgeseite zugerechnet wird. LÀsst
sich
das umgehen? Dazu muss ich sagen, dass hier noch die alte L&L
Version 11 zum
Einsatz kommt.

Vielen Dank,
Tobias

Bei einer Suche bin ich auf Deinen Beitrag gestoßen.
Habe das Problem kĂŒrzlich gelöst. Der Weg ist wie folgt:

  1. Du legst fĂŒr den Übertrag eine Fusszeile fest. (Bei mir heißt
    sie
    “Übertrag”)
    In dieser Gestaltest Du die Darstellung deines Übertrages und gibts
    ihr
    die Darstellungsbedingung >>Totalpages$()<>“1” and not Lastpage()<<
  2. kreierst Du eine Kpfzeile mit dem Übertrag.
    Diese erhÀlt die Darstellungsbedingung Val(Page$())>1
  3. FĂŒr den Übertrag erstellst Du eine Summenvariable in der Du den
    zu
    Übertragenden Wert aufsummierst
    und den Du dann in die beschriebene Fuß- und Kopfzeile einbindest.

Durch die Bedingungen ist gewÀhrleistet, dass im Fuss nur ein
Übertrag
erscheint wenn es mehr als eine Seite gibt
und im Kopf der Übertrag erst ab der 2. Seite auftaucht.

Damit sind, zumindest bei mir, alle diesbezĂŒglichen Probleme
gelöst.
Wenn Du willst kannst Du auf diese Weise in einer Zeile auch
mehrere
ÜbertrĂ€ge (StĂŒckzahl, Rabatt, Preis, etc.) setzen.

LL14 definiert die als 107. Viel GlĂŒck.

Paulchen

“Tobias Bucher” <tbucher@g
> wrote in message
news:222812122009154318@combit.net


Das klingt gut und nach genau der Option die ich suche - offenbar
wurde die
auch genau in LL11 eingefĂŒhrt. Aber kann mit jemand sagen, welchem
Wert sie
entspricht? Trotz korrekter usings (c#) usw. gelingt ein Aufruf in
folgender
Form nicht:

_ll.Core.LlSetOption(LL_OPTION_CALC_SUMVARS_ON_PARTIAL_LINES, 1)

Weil LL_OPTION_CALC_SUMVARS_ON_PARTIAL_LINES natĂŒrlich nicht
definiert ist
und ich auch keine Dokumentation finde, in der der entsprechende
int-Wert
stĂŒnde bzw. auch keine Enumeration die das hergibt?!

Viele GrĂŒĂŸe,
Tobias

Dankeschön, in LL11 ist es auch die 107, wie ich mittlerweile auch dank
diverser Header-Files zu anderen Sprachen als C# feststellen durfte :slight_smile:

Und das wichtigste: Es funktioniert einwandfrei.

Tobias

“Paul Schmidt” <paulchen4@hotmai
> schrieb im Newsbeitrag
news:20790213200995512@combit.net


LL14 definiert die als 107. Viel GlĂŒck.

Paulchen