Subtotaal na einde pagina.

[hezndepezn]

Voor een factuur die over meerder pagina's (kan) gaa(n)t wil ik aan het einde van elke pagina een subtotaal laten zien. Elke pagina bevat 4 gedeeltes. Op de laatste pagina wordt het totaal getoond (incl. btw etc.) Is dit te doen zonder extra velden waarop gesorteerd wordt?

[Joserpen]

Hallo,

 

heb eenzelfde probleem,

heeft u intussentijd een oplossing gekregen/gevonden?

 

Met vriendelijke groet

Joserpen

[rmw]

Summary veld van het type 'running total' in het footer gedeelte plaatsen?

 

rmw

[Joserpen]

Dank voor u reactie rmw,

 

nee, blijkbaar niet,

een veld met een lopend totaal geeft enkel het gehele totaal weer

 

mvg

Joserpen

[SuperWimmie]

Ik heb ook ooit lang gezocht en niet kunnen oplossen.

Mijn facturen zijn dus zonder bladtotaal en zonder voorgaand bladtotaal.

[burggraaf]

Tja, dus niet de enige die hier tegenaan loopt... Heeft iemand wellicht een workarround?

[Peter Wagemans]

Voor een factuur die over meerder pagina's (kan) gaa(n)t wil ik aan het einde van elke pagina een subtotaal laten zien. Elke pagina bevat 4 gedeeltes. Op de laatste pagina wordt het totaal getoond (incl. btw etc.) Is dit te doen zonder extra velden waarop gesorteerd wordt?

 

Het is wél te doen als je die laatste voorwaarde laat vallen, denk ik. Is het niet mogelijk om een subresumé op een unstored calc "Get(PageNumber)" te maken? ( sla me niet dood als ik mij nu even vergis met de exacte syntax van die get functie ). Die unstored calc zal ook werken in preview mode, dus als je daarop sorteert, dan kan je ook een subresumé erop maken. Allemaal goed en wel in theorie, ik ben niet zeker of dit werkt.

Een andere manier is scriptmatig door de pagina's te lopen als ze in preview mode staan, en de paginanummer te zetten in de records. Als ik me niet vergis, zal een "set field" de eerste record op die pagina aanpassen, en de loop zal door de pagina's lopen in plaats van door de records ( als je "go to record/request/page [next]" gebruikt). Je hebt dan alleen maar de pagina nummer op bepaalde records, maar je kan dit dan verder in browse mode opvullen.

[burggraaf]

Peter,

 

Het zou mooi wezen maar helaas dat werkt niet... Go to next record zal inderdaad inderdaad in preview naar de volgende pagina gaan. Switch je bij elk record van browse naar preview dan komt daar alleen pagina 1 uit.

 

Begin bijna te vrezen dat er geen workarround voor is...

[fmwebshop]

Misschien help dit voorbeeldje aan een workaround

 

Vr groet

Harry

Naamloos.fp7

[burggraaf]

Aardig bedacht, en kan vaak volstaan alleen... het staat of valt met het vooraf gedefinieerde aantal regels per pagina...

In onze case gaat dat niet werken omdat dat niet vastligt. Het aantal omschrijvingsregels per record varieert dus het is niet vast te leggen of er van de bijvoorbeeld 30 factuurregels de 1e 3 of de 1e 10 om de 1e pagina staan. Laat staan welke op pagina 2, 3 of 4...

[fmwebshop]

Hoeveel faktuurpagina'sheb je maximaal?

[SuperWimmie]

Het is feitelijk hetzelfde probleem als dat je op de pagina wilt afdrukken "Pagina 5 van 10". Dat gaat ook niet in Filemaker.

 

Filemaker betrekt de printerdriver niet vooraf in het opbouwen van de layout. Een schermafdruk kan zelfs meer of minder regels bevatten als de definitieve print, ook met precies dezelfde instellingen.

Programma's als Word en Excel doen het anders. Die gaan juist uit van de printerdriver en printerinstellingen en dat bepaalt op basis daarvan al in alle schermen de bladovergangen.

 

Ik heb het zelf maar geaccepteerd. Mijn klanten accepteren het gelukkig ook. Met de komst van computers is zo'n bladtotaal ook wel een beetje ouderwets. Het tonen van dat totaal is gebaseerd op de oude typmachine facturen, waar handmatig alle totaaltjes werden bepaald. Zat er ergens een simpele rekenfout, dan kon je sneller herleiden waar dat dan had plaatsgevonden.

Tegenwoordig is het gewoon knap om een rekenfout te maken op een factuur als de programmatuur stabiel is.

 

Navraag bij één van mijn klanten leert dat het bladtotaal op 60% van de facturen niet meer wordt vermeldt.

[andries]

Het is feitelijk hetzelfde probleem als dat je op de pagina wilt afdrukken "Pagina 5 van 10". Dat gaat ook niet in Filemaker.

 

Dit gaat toch wel? Je kan toch met "##" de het pagina nummer laten afdrukken? Om het einde te weten, moet je inderdaad een veld aanmaken, in preview mode gaan, naar de laatste pagina gaan, en dan met Get (PageNumber) die waarde opslaan.

 

Dan krijg je dus: Pagina ## van <> op je layout te staan.

 

Verder ben ik het eens dat afdrukken met FileMaker niet altijd leuk en handig is

[JeanWM]

Tja, dus niet de enige die hier tegenaan loopt... Heeft iemand wellicht een workarround?

 

Wij bepalen hoeveel regels er max. op een layout kunnen.

 

Een unstored calc veld (prevValues) met het max. aantal reps, bijv. 15. Die waarde kun je ook storen in een interface veld (zi_ifw).

Wij stellen die waarde in op 50 voor veiligheid, maar eigenlijk heb je met 15 voldoende.

 

Let( [
rn =  Get( RecordNumber );
rrn =  Mod( rn - 1; zi_ifw );
rep = Get( CalculationRepetitionNumber ) ];
 If( rep > rrn + 1; 0; 
   GetNthRecord( Extend( Value ); rn - ( rep - 1 ))
    ) //
    )//

 

Dan heb je nog een calc veld:

 

Sum( prevValues )

 

Het zal ook de laatste bladzijde, indien het 'onvolledig' zou zijn, juist behandelen.

[burggraaf]

Jean, redelijk hogere wiskunde... In de basis snap ik 'm wel maar ik zou 'm ook echt uitgebreid moeten ontleden om te doorgronden en toe te passen (als dat al zou lukken) . In ons geval is een record echter niet 1 regel hoog omdat de lengte van de omschrijving kan varieren (wordt in de afdruk met sliding opgelost). Ik vrees dus voor de oplossing...

[JeanWM]

Het maakt niet uit hoe je de regels set.

 

De rrn variable (relative record number) zal detecteren hoeveel regels, records eigenlijk, er zijn.

[burggraaf]

Jean, dan begrijp ik 'm niet... Want in de layout kan 1 record 3, 5 of 10 regels hoog zijn (afhankelijk van de lengte van de tekst). In de volgende afdruk kan dit weer heel anders zijn. Dan weet je toch niet hoeveel regels er op pagina 1, pagina 2, 3 e.v. geplaatst moeten worden? Het kan best zo zijn dat pagina 1, 5 regels heeft pagina 2, 3 en 3, 10...

Ik leer heel graag... dus wellicht kun je 'm dan wat nader toelichten?

[JeanWM]

Kan perfect met varierende velden....

 

zolang je rep calc een hogere waarde heeft dan het aantal lijnen in preview....

 

Daarom dat het best is dat de zi_ifw waarde een variable is. Dan kan het dynamisch aangepast worden.

Het moet enkel lager zijn dan de max rep calcs om de berekende resultaten niet nadelig te beinvloeden.

[burggraaf]

Jean, ziet er indrukwekkend uit... maar ik blijf de aansluiting missen... Heb je wellicht een voorbeeldbestandje zodat ik 'm beter kan bestuderen?

[watertuin]

Via een script is het mogelijk ....

 

Ik neem aan dat de factuurregels of zijn genummerd of zijn voorzien van een ID.

Zo ja, in dat geval het volgende:

 

nieuw veld aanmaken in factuurregels bv running_total

de factuurregels sorteren : sleutel 1 is factuurnummer, sleutel 2 is factuurregelnr of id-nr

 

running_total op nul stellen alvorens loop factuurregels doorlopen per factuurnr

in loop : zet factuurbedrag = running_total + factuurbedrag

 

op lay_out running_total in de footer plaatsen. Sortering als bovenstaand toepassen alvorens de facturen te printen.

 

succes.

[burggraaf]

@watertuin: Het gaat om het totaal per pagina, niet per factuur...

[watertuin]

tik foutje ....

 

running_total = runnung_total + bedrag factuurregel

 

laatste record move "" to running_total

 

Op deze manier krijg je per pagina keurig het op dat moment geldende subtotaal onderaan de pagina

Op de laatste pagina vd factuur wordt het subtotaal niet afgedrukt.

[burggraaf]

Da's nog niet wat ik bedoel want je wilt aan het begin van elke pagina het resultaat van de vorige. Maar... Ik snap je uitleg helaas niet... Je sorteert de records, maakt een leeg veld en vervolgens een script wat het huidige totaal bij het totaal van de volgende regel optelt en dat veld zet je in de voet van de layout? Kun je een werkend voorbeeld laten zien?