=?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