+1 800 256 3608 (toll-free in North America) or +49 7531 90 60 10| service@combit.com

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


(Guest) #1

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.


(Guest) #2

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.


(Guest) #3

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.


(Guest) #4

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


(Guest) #5

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