Is there a way to format a layout so that it will dynamically change when printing a receipt?

I am in the process of creating a POS for a quick service restaurant where the receipt needs to show any modifications to the customers order? As of now, I am contemplating building a field which would build the order in html to print, but that doesn't sound efficient. I was hoping someone could point me in a direction where this could all be handled within filemaker.

Here's an example.

A customer orders 3 lattes, one with 2% milk and no foam, one with skim mik and caramel the other just normal...

Receipt says:

Latte........$3.50

Skim

Caramel

Latte........$3.50

No Foam

2%

Latte........$3.50

Subtotal...$10.50

I need to receipt to be able to dynamically change so that any order with modifications will be reflected this way. Ideas?

This is a data entry issue, not a layout issue. Each item purchased should have a list of options that can be selected. These can then be printed on the receipt.

And that is how they are set up. Each Line item has a related table with all of the modifiers that have been selected.

I am working on having the printed receipt show these modifiers when they are present, but not when they haven't been selected. (i.e. I don't want to have an inch and a half of blank space on the receipt below each line item when there is nothing to print.)

Each line item should be recorded as a separate record - in your example there should be 7 records. The receipt layout needs to be sorted to reflect the desired order of items.

There will be no blank spaces as the receipt layout should be based on the line items.

Great, Thank You IdealData. I've been stuck in a rut of thinking about this the wrong way. Just needed an a new perspective.

OK quick question, How do you print a variable length receipt with a footer for subtotal and total? I can only get it to print a certain length...

Nevermind, got it. Stupid questions should be googled first. Thanks for both of your helps!

Nevermind, got it. Stupid questions should be googled first. Thanks for both of your helps!

well, this is gonna make me sound/feel stupid, but apparently my google fu is rather weak...

 

I'm trying to do exactly that--make a receipt which changes length based upon the number of items in the invoice..

This is essentlially a POS receipt thermal printer, and I'm trying to make the lenght of the printed receipt be relative to the number of items on the invoice....

 

The invoice/receipt layout is based on a portal from "invoiceitems" table, which are layed out on the receipt...

 

am working in a mixed version environment--several users on 11 and 12, but the server is on 9.03..

 

any help would be greatly appreciated!

 

the only initial idea I've had is to replicate the receipt layout multiple times with multiple qty of invoice items, then do a row count of related invoiceitems, then choose the corresponding layout...

 

can somebody toss a bone my way??   thx!

Create your receipt layout as a list view in your invoice items table, not in a portal. Use Go To Related Records starting from your customer record (using the same relationship as your portal) to populate the invoice. In the header section of the receipt layout, place customer info from the related fields in the customer table.

wow, thx for the fast response!

 

that makes sense completely..

 

Only one more question (somewhat related on this): how do you get your printer layout to accurately reflect the length of the list?

 

do you set the page layout to a very short page, so it just prints x number of pages until it prints the whole thing?

I assume that the receipt will consist of several blocks of text such as restaurant header, item details, cash tendered and so on.  You want the item details text block to just accomodate the items purchased, and the cash tendered block to be immediately below this. This can be handled easily using Filemaker's ability to slide layout items when printing, and also allowing them to reduce to the size of the text they enclose. Set the item details field to slide up and to adjust to the size of the enclosing part, and the cash tendered block below it to slide up as well.

 

You may find it easier to build the receipt data into a set of temporary variables and print using these. Have you looked at Virtual Lists as a way of solving this? Bruce Robertson developed the technique back about 2009 - I can't find his original posts but there is an example file here which might help

 

http://fmlayoutmode.com/wp/?p=1799

 

HTH

 

Brian

ok, i've tried this numerous ways.

 

1. a form view in Invoice table, with items as a portal..

 - doing this i have to make multiple forms of multiple lengths, do multiple page length layouts with various length portals (zebra printer lengths, say 3.25x6", 3.25x7", etc), then choose between them based on the qty of items in the portal ... restuts work but require numerous diferent lenth layouts, a counting operation, etc.....

 

2. I tried a list view in the InvoiceItems table, but (n00b here!), can' get it to print all records at the same time.. still not sure what i've done wrong in that..... layout looks great (on the screen), but wll only print ONE record per page! I chose "print all", "all records', etc....

 

what am i doing wrong?
 

#1 Forget about the portal--it'll only give you angina.

 

#2 Make sure the layout is set for View as List, not View as Form in the View menu. 

thx.. yes, i fully understand the direct show as a LIST view.. I've turned off FORM and tABLE views, and showing only as list.

 

The issue is that when it prints, it shows the header area (with customer data) and the footer (grand trailing summary) with final info, but only shows ONE record in the BODY area....   go figure.

 

during the print process I'm choosing "print all", "ALL records", and have gone back thru this process a dozen times, rather unsuccessfully.

 

I *AM* becoming proficient at pulling my hair out though!

 

Any thooughts?

 

 

#1 Forget about the portal--it'll only give you angina.

 

#2 Make sure the layout is set for View as List, not View as Form in the View menu. 

 

The issue is that when it prints, it shows the header area (with customer data) and the footer (grand trailing summary) with final info, but only shows ONE record in the BODY area....   go figure.

 

 

Do you have sub-summary part?  Have you sorted by this part?  Have you selected all items and set them to slide up?  

 

It would help if you provided a screen shot in layout mode of your layout in the InvoiceItems or SOME information so we can SEE what you are doing.  Otherwise we are throwing darts at a dartboard and, I don't know about others, but I'm a terrible shot blindfolded. :-)

This is essentlially a POS receipt thermal printer, and I'm trying to make the lenght of the printed receipt be relative to the number of items on the invoice....

 

I think you ought to do separate troubleshooting for the file and for the printer. What do you see when you switch to preview mode? If you see multiple records per page, than the problem is (very likely) with the printer. I'm afraid I don't know enough about thermal printers to be more specific. There seems to be a requirement for "unlimited" page size here - I am not sure how you tell Filemaker something like that.

Do you have sub-summary part?  Have you sorted by this part?  Have you selected all items and set them to slide up?  

 

It would help if you provided a screen shot in layout mode of your layout in the InvoiceItems or SOME information so we can SEE what you are doing.  Otherwise we are throwing darts at a dartboard and, I don't know about others, but I'm a terrible shot blindfolded. :-)

 

thanks for the note.

 

in the header, i have the related Invoice ID record locator - that's how i "create the record" for the client.  THen the records in the list (iinvoiceitems table) are each records which have that same invoiceID on them... So they show up as unique records in the list view.

 

Sorry-i didn't know i could post an image.... will figure that out shortly..

 

 

NOTE:  a slight error was just noted:  I mentioned previously that the footer was a grandtrailing summary.. it's not.. i'm running it as a 'footer", and getting the invoice totals & tax data from the Invoice table (separate table) based on the InvoiceID relationship.....

 

 

 

 

 

I think you ought to do separate troubleshooting for the file and for the printer. What do you see when you switch to preview mode? If you see multiple records per page, than the problem is (very likely) with the printer. I'm afraid I don't know enough about thermal printers to be more specific. There seems to be a requirement for "unlimited" page size here - I am not sure how you tell Filemaker something like that.

 

this brings up TWO issues.

1. the page layout seems to be what is determinning the legnth of the actual receipt... so if i make a 'paper' that's 3.25x4" long, the receipt will print on it.. but i really need a variable length (because the printer can print essentially ANY reasonable length of a page)..

So how do I tell the printer what length to run on (ie., how does the printer know the length of a sheet of paper)??  Do i have to create multiple lengths for Page Setup, then choose each based on the # of records? or is there a better way to do this?

 

 

2. I'm trying this out on both a thermal printer AND a conventional letter sized laser, using conventional paper.. it's printing the same on both pages..

 

 

Images below:

 

1. this is the List view layout as recommended above, shown in edit mode.

2. This is the same, seen in browse mode....

3. this is how it looks when actually printed..... only ONE record shows up. AND it doesn't "slide up" to keep the sheet clean...

I'm trying this out on both a thermal printer AND a conventional letter sized laser, using conventional paper.. it's printing the same on both pages..

 

Then it's probably not related to the printer (or you haven't got to the issues related to the printer yet...).

 

It would probably be best if you posted your file or - preferably - a simplified version thereof. Otherwise we could be here all week.

I see no leading sub-summary part.  Your InvoiceID must be in sub-summary and sort by it as well.  And did you select all objects and set them to slide up and also check 'resize enclosing part'?

 

As Michael says, seeing the actual file might be quickest.

Hey, we'll help you figure it out; no worries.  

Ok,

 

it's attached here..

 

user name is x

password is x

 

 

invoice.fp7.zip

I have a better idea: try reproducing the problem in a new file. Or download the file from here and see how that goes:

http://fmforums.com/forum/showpost.php?post/309136/

The easiest way is to save a copy the file as a "no record" or to save a copy and remove any confidential information.

invoice.fp7.zip

 

 

username & password are both x

 

 

Please confirm that this is all you need....  thx!

I have a better idea: try reproducing the problem in a new file. Or download the file from here and see how that goes:

http://fmforums.com/forum/showpost.php?post/309136/

Thx... I tried this copy.

 

1. They don't show totals/summaries in this layout.  And their location for totals is in the Invoices (just like mine), but when installed in either theFooter or Trailing Summary, it doesn't appear either.

 

2. BUT it does show all related records in the print, whereas mine shows only ONE at a time....

 

i've tried adding a few things ontheirs to get it to work, but unsucessful.... 

 

3. I'm still at an impasse on how to force FM to get my printer to print varying length product. anybody got any ideas?

  My current "only" working solution is to go back, create this whole thing in 5-10 different layouts (with portals, each of different lengths), and build one at a time.. then create corresponding length PageSetup configs, and run a script to jump to the appropriate page setup config and matching layout during the print sequence......

 

Thoughts?  i saw a couple folks downloaded this--was hoping to NOT have this hounding me while knawing on turkey tomorrow...

I only have time for quick look ... heading out the door ... but your sub-summary is based upon Invoices::InvoiceNo and it should be based upon InvoiceItems::ID.  And the sort needs to be changed to point to InvoiceItems:ID also.

 

Also your fields in the body that are grouped - they need to be set to slide up and reduce enclosing part.  That may not be necessary since I couldn't really review it but those things will help.

 

Also in part setup, select the sub-summary and set page break before and set allow breaking across parts.  I can't try any of that but I think it'll move you forward.  BTW, if you see Comment's file, you will see his sub-summary is based upon LineItems (I believe).  So again, if it works in his file then you know it is simple implementation you are dealing with.  Gotta run.  I hope this helps.  Happy Thanksgiving!

Also, 'ID' usually indicates the primary unique ID of a table.  When using a foreign key, it is best to indicate the foreign key's table name.  So in InvoiceItems, I suggest InvoiceID instead of ID.  Wishing you the best with your design!

Sorry it is segmented ... your InvoiceItems table ALSO needs a primary key (unique auto-enter serial or UUID) and *it* can be called simply ID.

Edited November 28, 201312 yr by LaRetta

I only have time for quick look ... heading out the door ... but your sub-summary is based upon Invoices::InvoiceNo and it should be based upon InvoiceItems::ID.  And the sort needs to be changed to point to InvoiceItems:ID also.

 

Also your fields in the body that are grouped - they need to be set to slide up and reduce enclosing part.  That may not be necessary since I couldn't really review it but those things will help.

 

Also in part setup, select the sub-summary and set page break before and set allow breaking across parts.  I can't try any of that but I think it'll move you forward.  BTW, if you see Comment's file, you will see his sub-summary is based upon LineItems (I believe).  So again, if it works in his file then you know it is simple implementation you are dealing with.  Gotta run.  I hope this helps.  Happy Thanksgiving!

Also, 'ID' usually indicates the primary unique ID of a table.  When using a foreign key, it is best to indicate the foreign key's table name.  So in InvoiceItems, I suggest InvoiceID instead of ID.  Wishing you the best with your design!

Sorry it is segmented ... your InvoiceItems table ALSO needs a primary key (unique auto-enter serial or UUID) and *it* can be called simply ID.

tx so much!

 

"And the sort needs to be changed to point to InvoiceItems:ID also."

 

where is this??

There's no script to print in your file. I tried to print manually and I got only one record in the body part, just like you said.

 

The reason for this, AFAICT, is that the file has a "memory" of print options from the last performed print - and it has "Current record" selected in the "Print" radio button set. Once I changed that setting to "Records being browsed", it printed all records as you would expect.

 

 

I'll try to address your other points later - i too must rush now. Happy Thanksgiving!

Sort by InvoiceItems::ID (hopefully changed to InvoiceID)  :-)

And no, I don't know if this is the issue (along with my other suggestions) because I'm bopping in and out while I have a house full of guests, LOL.  I'll try to look at the file again later.

But in truth, if Comment is on it, you are in good hands.

There's no script to print in your file. I tried to print manually and I got only one record in the body part, just like you said.

 

The reason for this, AFAICT, is that the file has a "memory" of print options from the last performed print - and it has "Current record" selected in the "Print" radio button set. Once I changed that setting to "Records being browsed", it printed all records as you would expect.

 

 

I'll try to address your other points later - i too must rush now. Happy Thanksgiving!

tx

 

i was practicing printing manually... hadn't thought that doing a script would net a different result than simply doing it manually (bad assumption i think!)...

 

I manually set to "Records being browsed", but still got only one record...

 

BUT, i'll make it a script and give that a shot..  thx! and hope all are enjoying the holiday!!

 

 

Anyone got thoughts on how to dynamically tell the printer to use a different page length in page setup?

I've been testing out the process of simply creating a dozen different thermal paper sizes (ie.,  3.125x5.25", 3.125x5.5", etc), then using a "Get(count) of records to determine WHICH page setup to use... this of course seems (in my opinion) to be abit of a rube goldberg method.... 

I manually set to "Records being browsed", but still got only one record..

 

Well, that's strange because that's definitely NOT how it behaves here. I haven't made any scripts either - just changed the setting once and from this point on it prints all found records.

 

 

Re the invoices demo file:

 

They don't show totals/summaries in this layout.

 

That's not quite true: the total is shown in a trailing sub-summary part. You won't see this unless records are sorted by InvoiceID. In version 8, you might also have to enter Preview mode - I don't remember exactly. There's a script called 'PrintOneInvoice' that does all that for you - just call it from the 'Invoices' layout.

2. I tried a list view in the InvoiceItems table, but (n00b here!), can' get it to print all records at the same time.. still not sure what i've done wrong in that..... layout looks great (on the screen), but wll only print ONE record per page! I chose "print all", "all records', etc....

 

So please can we just walk through this together and you make these changes to your file (as I indicated above)?  Here is everything you should need (well maybe not everything, LOL):

1. Naming:  change your InvoiceItems::ID field name to InvoiceID.  ID by itself indicates the primary key in a table and, in InvoiceItems, the invoice is a foreign key.  
2. Sub-summary part:  change your leading sub-summary from being based upon Invoices::InvoiceID and base it on LineItems::InvoiceID.  
3. Create trailing sub-summary:  Add a trailing sub-summary based upon InvoiceID. Place your sub-total and total fields from Invoices inside this sub-summary part.
4. Page breaking:  while there, set page break on LineItems::InvoiceID.
5. Oversize your fields:  Drag your field(s) in the body (Precio) a bit taller (to maybe 35 pt in height)  The fields will REDUCE in height if not needed but never expand so always make them maximum height that you will need.
6. All fields must slide:  Select Precio field and in Inspector, set to Sliding up based upon all objects and be sure to check 'also reduce enclosing part'  This is critical that all objects slide, text labels, lines and all fields.
7. For test, show all:  Just so you can see it working, show all records here in InvoiceItems table.
8. Sort:  Sort all records by InvoiceItems::InvoiceID (you  MUST ALWAYS sort by the break field for summaries to work).
9. Go to Preview Mode: page through the records.  What does it show?

 

In your current file, you only had ONE invoice in your found set (of its items).  If we can get the above squared away AND if you have good data in your file (you currently lack good data except for the last invoice) then you should see it reduce as you wish and you can print & review multiple invoices.

 

But until you have a better grasp of reporting, we aren't going to move forward. Hopefully this will help. If still stuck, please attach a NEW file with these changes in place so we can take it from there.

 

The idea is to find the invoices first, then GTRR to their InvoiceItems, sort by InvoiceID (from LineItems) then print.  

Edited December 2, 201312 yr by LaRetta

BTW, please do not feel bad about feeling very confused and lost with reporting.  It is probably the least intuitive, clunkiest process in FileMaker second only to Import/Export mapping junk.

2. I tried a list view in the InvoiceItems table, but (n00b here!), can' get it to print all records at the same time.. still not sure what i've done wrong in that..... layout looks great (on the screen), but wll only print ONE record per page! I chose "print all", "all records', etc....

 

So please can we just walk through this together and you make these changes to your file (as I indicated above)?  Here is everything you should need (well maybe not everything, LOL):

1. Naming:  change your InvoiceItems::ID field name to InvoiceID.  ID by itself indicates the primary key in a table and, in InvoiceItems, the invoice is a foreign key.  
2. Sub-summary part:  change your leading sub-summary from being based upon Invoices::InvoiceID and base it on LineItems::InvoiceID.  
3. Create trailing sub-summary:  Add a trailing sub-summary based upon InvoiceID. Place your sub-total and total fields from Invoices inside this sub-summary part.
4. Page breaking:  while there, set page break on LineItems::InvoiceID.
5. Oversize your fields:  Drag your field(s) in the body (Precio) a bit taller (to maybe 35 pt in height)  The fields will REDUCE in height if not needed but never expand so always make them maximum height that you will need.
6. All fields must slide:  Select Precio field and in Inspector, set to Sliding up based upon all objects and be sure to check 'also reduce enclosing part'  This is critical that all objects slide, text labels, lines and all fields.
7. For test, show all:  Just so you can see it working, show all records here in InvoiceItems table.
8. Sort:  Sort all records by InvoiceItems::InvoiceID (you  MUST ALWAYS sort by the break field for summaries to work).
9. Go to Preview Mode: page through the records.  What does it show?

 

In your current file, you only had ONE invoice in your found set (of its items).  If we can get the above squared away AND if you have good data in your file (you currently lack good data except for the last invoice) then you should see it reduce as you wish and you can print & review multiple invoices.

 

But until you have a better grasp of reporting, we aren't going to move forward. Hopefully this will help. If still stuck, please attach a NEW file with these changes in place so we can take it from there.

 

The idea is to find the invoices first, then GTRR to their InvoiceItems, sort by InvoiceID (from LineItems) then print.  

 

 

thx.. this makes sense. Some of this I've gotten to work properly, some note.

 

I ran out of time this weekend, so I bit the bullet, made 12 different length reports (with portals), arranged the scrip to do a record-count, then choose the appropriate length invoice based on this..  It's ugly scripting,  but it works. And, unfortunately I didn't have the time to wait..

 

One thing that's been really perplexing was that if I did a Preview, it looks perfect.. it only didn't work when I actually printed (or did a print-to-pdf preview).....

 

i'm wondering if it's tied to the issue mentioned previously, that the FMP app is "remmebering" a previous, incorrect page setup format..... 

 

either way, will get back to you asap. tx!

And it looks to me like Comment properly interpreted the deeper issue to begin with.  Let us know how it goes.  :-)

Well, I **THINK** i fixed the first part of the issue -  the printing issue where it was printing ONLY one record (even when chosen to print all returned records). Mavericks wasn't implementing my preferences properly (silly me for installing it, I thought that Apple would have actually made an OS that was problem-free!)...

 

The issue which i still haven't resolved is that of effectively PRINTING a dynamic-length layout. 

 

This solution is running thermal paper printers, but in effect, they still operate much the same as a standard conventional printer--you have to tell them what size paper to print.  So if your layout is always 3" wide, but may be 4" long, 4.5", 6", 7.25, etc ---- the printer has to know what length, or it's going to only assume what you told it previously... The issue gets a bit more complex with thermal printers that have cutters built in (I'm running both the old Zebra 2844's that are dirt cheap and run forever, and the Star TSP100's, which have built-in cutters, and are config'd to auto-cut the paper at the page-length point)....

 

From what I can tell, Filemaker wants a page setup that defines length & width, and won't adjust these dimensions "on the fly".

 

So the bigger question remains--is there a way to force FMP to adjust page sizes based on content, and stretch/downsize layouts accordingly?

 

In conventional printing, we are used to adjusting a layout but leaving the paper size as a static component - but this is a need to force the papersize to change in dynamic proportion...

 

 

The final target output of this is as follows..

 

We sell a single widget, and the full size of the receipt should be say.....3.25" wide by 4.0" length..  The list layout with summary creates a beautiful product*, but unless I script out a page setup change that correlates to it, the print job is still going to run with my previous Page Setup settings...

 

In a small solution environment (1 or 2 systems) this isn't a big deal..

 

My current process is to create the same Custom Paper sizes on every system, which means manually creating them on each system (or if they're on comparable Mac OS versions, there's a way to copy them over), and giving them a uniform name set (ie Z3x6, Z3x6.2, Z3x6.5, etc)..  I can then script out an adjustment based on length of receipt (count rows then choose layout based upon row count, then tell PageSetup to choose one of these Custom sizes by the name, based upon my Layout choice)..This method works but it's neither intuitive nor clean.. And if some user decides to reinstall an OS or replace a machine, well, then the custom pages have to be reinstalled on that local machine before it'll work again...

 

Is there a way to force the Page Setup operation to create its own custom paper size, to avoid having to manually install these parameters??

 

 

*there is a bit of a caveat with the "beautiful list view/summary" option product. This client has requested a method of watermarking their receipts (apparently fraud is pretty high in their country), so our solution was to throw their logo in a VERY LIGHT (10-15% ) version beneath the back of the invoice, on an angle, in a way to prevent someone from scanning/copying, & changing the items on the invoice. It's not fool-proof, but it prevents the quickest/easiest method of fraud....

 

This is quite simple to do in a static layout where the items showing up are brought in by portal (ie, you can throw the logo on the back of the page, build a transparent portal, and display the portal on the page over the logo).

 

BUT in the list/summary view (as Comment & LaRetta described), i can't seem to figure out  a way to make a logo reside in this view without forcing EACH record to become the size of the entire logo.. 

 

So while the list view/summary setup SHOULD work, our logo watermark issue creates a complication..

 

Any thoughts on this?

 

AND, is this something that's addressed by FMP13?

A few thoughts:

1. Contact the printer manufacturer; surely they have encountered this issue before.

2. Use a layout with no header and no footer (use only sub-summary parts and body); try setting the page height to equal the height of a receipt with one line item (i.e leading sub-summary + body + trailing sub-summary).

3. Re the logo, I don't see how it can work unless your portal is of fixed height (non-sliding). It seems to contradict your purpose of matching the page height to the number of items. Couldn't you use a tiled logo (or some other pattern)?

 

---

BTW, a while back there was a request here (from Bolivia, I think) to produce a RC4 hash string for an invoice that would prevent tampering with the invoice's data. This was mandated by the tax authorities there, I presume due to high fraud rate.

Edited December 5, 201312 yr by comment

A few thoughts:

1. Contact the printer manufacturer; surely they have encountered this issue before.

2. Use a layout with no header and no footer (use only sub-summary parts and body); try setting the page height to equal the height of a receipt with one line item (i.e leading sub-summary + body + trailing sub-summary).

3. Re the logo, I don't see how it can work unless your portal is of fixed height (non-sliding). It seems to contradict your purpose of matching the page height to the number of items. Couldn't you use a tiled logo (or some other pattern)?

 

---

BTW, a while back there was a request here (from Bolivia, I think) to produce a RC4 hash string for an invoice that would prevent tampering with the invoice's data. This was mandated by the tax authorities there, I presume due to high fraud rate.

 

 

Thx.

 

1. The printer per-say isn't really the problem.. It'll churn out a page as long (or as short) as you tell it to. Printers with cutters will cut the page whenver they see an "end of page" line, all of which is controlled by page setup. Perhaps I'm wrong, but I think the problem is tied to PageSetup settings....

 

2. I'll try the layout arrangement you describe.  But what do I tell "page setup" to consider the size of the paper to be?  If I tell it the paper is say, 1" tall, it'll come along and cut the page at every 1" until it's printed the whole layout in 1" increments...

 

3. I had in my mind a layout which could resize graphics according to the size of static data which would be on it (ie., if say, only 3 lines of items, a much smaller graphic centered on the page, on a page which is much shorter).... of course my ability to dream **MAY BE** a bit out of proportion to reality..

 

 

As to the idea of digital tampering process, I have fixed that to an extent.. I've got a hidden (non-visible to anyone but [full access] level field which contains a date/time stamp which is auto generated when the file is modified, which is then copied over to a static field at such time as the file is locked.  IF original stamp doesn't match current stamp, the file can't be modified or adjusted....

 

This however isn't the reason for the logo in the receipt -- -the idea is to make it difficult for average crooks to create (or modify) a fake copy of the receipt to make demands of the company.  With a light shade watermark, it's significantly more difficult, as it won't copy well, and is far more difficult to replicate.

 

 

 

 

At this point I'm seeing the issue of the watermark as more important than using a pretty/flexible "list view", so i'm running with my duct-tape model of multiple sized static pages with portals.

 

BUT the outcome of this is going to mean the issue has to be resolved in the future, as the client is going franchised, and the printer/page setup issue is going to have to be resolved prior to that......

Re #1, I don't know. It doesn't seem like a reasonable behavior for a continuous feed printer. I mean what's the point of being continuous, if you going to stick to a preset page size? Unless they expect you to provide an end-of-page character in the feed - which (I think) is not feasible in Filemaker, or any other application I can think of. Soooo 80's.

Aggggg.. i'm gonna kill myself!  just accidentally deleted a LONG series of questions about this, because I got interrupted!  (anybody else find it easier to lock the door and turn off the phone to prevent interruptions?)

 

1. Comment, thanks.. YES, indeed, i found a firmware bump on the TSP100 that allows it to automatically chop off the page at the end of the label ... so there's no need to tell it a static layout size (I think).. (I'll report back on this when I've successfully finalized it and proven it to be working!)

 

2. LaRetta, i'm still lost as to part of your statements. AND my layout STILL isn't working. and I don't know what's the cause. And another week has come & gone.... argg!!!

 

a few questions:

1. You said:  "I only have time for quick look ... heading out the door ... but your sub-summary is based upon Invoices::InvoiceNo and it should be based upon InvoiceItems::ID.  And the sort needs to be changed to point to InvoiceItems:ID also."       Now I don't know what you meant by "the sort needs to be changed to point to InvoiceItems:ID also."....  can you explain WHERE to set a sort?  What is a sort? Where do you find it? I'm guessing you're referring to the Part setup? On Body, it only will refer to whatever the whole layout is based on. am I doing something wrong there?
2. I'm chasing my tail on getting a layout which properly returns the records in preview mode.
3. If my records ((invoice items) are the repeating target, then (I'm assuming) I should make the ENTIRE layout based on the InvoiceItems Table --  correct??
4. The Header should be based off the Invoice table, (Invoice::InvoiceID), right? (because it's a single summary item)
5. The Leading Summary should ALSO be off the Invoice::InvoiceID, correct?
6. The Body Should be off InvoiceItems::InvoiceID, ?? (yes, i went back & corrected the field name)..
7. The Trailing summary should be Invoice::InvoiceID??
8. THe Footer Should be Invoice::InvoiceID?

 

What I'm getting is a bunch of varying results which never return the correct item.. Its' not for lack of effort. I litterally printed out ALL your notes on this topic, taped them to my monitor, and worked till 3this morning.   and still not ending with anything that's usable....

 

1. can you explain WHERE to set a sort?  What is a sort? Where do you find it? I'm guessing you're referring to the Part setup? On Body, it only will refer to whatever the whole layout is based on. am I doing something wrong there?  Sort the records - Records > Sort and select InvoiceItems::InvoiceID.  When you have a sub-summary, the records must be sorted by the field defined in the sub-summary part.  It is called the 'break field' because it is the field which breaks the records into their sub-summary group.
2. I'm chasing my tail on getting a layout which properly returns the records in preview mode.
3. If my records ((invoice items) are the repeating target, then (I'm assuming) I should make the ENTIRE layout based on the InvoiceItems Table --  correct??  Yes and that is what you have from the file you presented - I checked it.
4. The Header should be based off the Invoice table, (Invoice::InvoiceID), right? (because it's a single summary item)  Headers are not summaries.  But no, the entire report should be based upon the table it represents - InvoiceItems.
5. The Leading Summary should ALSO be off the Invoice::InvoiceID, correct? No.  INVOICEITEMS::INVOICEID
6. The Body Should be off InvoiceItems::InvoiceID, ?? (yes, i went back & corrected the field name)..  The body is always based upon whatever table occurrence the layout is based upon.  In this case, you are working in the InvoiceItems table so yes, body is based upon InvoiceItems.  The entire report should be based upon InvoiceItems.  You can place fields from Invoices in the sub-summary part (such as ShipMethod) but the sub-summary parts must be based upon field in INVOICEITEMS.
7. The Trailing summary should be Invoice::InvoiceID?? No.
8. THe Footer Should be Invoice::InvoiceID?  No.

 

I had reviewed your file and presented step by step  ... please re-read my post #31. 

so there's no need to tell it a static layout size (I think).. (I'll report back on this when I've successfully finalized it and proven it to be working!).

 

Please do, as it may help others as well as satisfy my own curiosity.

 

 

A note about headers/footers: a header is something that repeats on every page. As such, it has no logical place when printing to a continuous printer. At best, it will appear several times at seemingly random places in the printout. In the worst case, it may signify a premature "end of printout" to the printer. This is assuming that my hunch is correct and that you CAN print several pages "continuously". In any case, I would take them out of the equation - at least until you can figure out the printer's behavior in more detail.

First, a BIG thanks to LaRetta for giving me direction.  And **I PROMISE** I did exactly what she said! Well, mostly . But I had another issue in my own db which was killing the sort.. go figure.

 

Apparently I had something messed up in my db file, because I eventually re-created the entire layout and page in a new virgin FMP db, then copied it into mine, used the same scripts for sorting, etc, and it worked..  But I wouldn't have figured it out without her. Thanks!

 

Comment, you're dead-right on Footers... but apparently Headers don't act quite like footers (WRT summary list printing anyway).

 

 

IF there is a footer on a page (with thermal printing and cutting), it seems that the printer doesn't recognize an "end-of-page", so it just runs eternally (and it's a pain to re-roll a 200' spool of thermal paper to stuff it back in the printer)..    

 

Apparently this isn't the case with headers (why? I dunno). In my own rendition, I can't set any "page break" settings on the header (before or after), but it's a mute point (in my case anyway) - because one can't really "print multiple receipts" in this view (without the aid of a script to do the dirty work of collecting the correct LineItems, sorting by InvoiceID, and switching layouts).

 

Because you can't specify a pagebreak after a footer for some reason (nor can you specify BEFORE a header), the only solution (that I've found) is to have one or the other, but not both (ie., don't have both in the layout). So, I stuff my "static" info into the subsumm (trailing), and specify a break after it, so that fixes the end-of-page question....

 

 

On paper sizes.  I've simply chosen a very long length paper (2000mm), and set all to sliding up.. so it cuts off at the end of the data on the trailing sub-summary. (after experimentation, I put a tiny invisible part of a graphic lower on the page, to force it to give  a bit more clear space, though I suspect one could fix this with proper margin size adjustment)..

 

So... As long as your cutter-equipped thermal printer can be setup with a "continuous feed option" (in the print dialog under printer options), it should cut the paper as soon as it hits the end-of-page..   (Star didn't have this in the original firmware so it wasn't recognized for Mac PPD, but subsequent releases fixed this).

 

 

 

 

So I've attached a couple screenshots of a setup, that shows it in action... I've got a header, Sub (leading), Body, and Sub (Trailing), and it prints perfectly well.

 

 

So this is the process for the print script: start in Invoices table, GTRR to the layout, sort, do AppleScript [lpoption] to choose correct printer, do PageSetup, do print, return to original layout...

 

Voila!

 

All said it's a fast operation now.  I've got multiple layouts (one being the end-user receipt,another being a warehouse pick-sheet, and a third being the shipping dept's copy with barcode for scanning).  The script jumps to each one, spits out a copy, then at the end goes back to the invoice layout. And with the speed of modern thermals, it's a solution that appears seamless to the user..

 

 

"Related thermal printer stuff"  (for those in the future who wander past in search of help)..

 

 - -

 

First, because of the unique paper sizes in thermal printers (2.25" and 3.125" wide being primary sizes) there is a challenge with paper sizes as they're NOT standard call sizes within the OS. Ideally this would be done via script (Perform Applescript ["do shell script "lpoptions -d Star_TSP143__STR_T_001_ -o media=Letter""] ), but from what I can tell Apple decided to have the OS ignore 'lpoptions -o ' calls.. (perhaps someone can fill this in later??).

 

I haven't figured this out completely yet and am resorting to having to create Custom Paper sizes on each machine that's actually printing (to call the printer PPD and choose the correct paper size).. BUT this also requires me to have installed the CUPs drivers on every system on the network which may access that printer, and I'd love to bypass this... A bit annoying, but it works for now.

 

(If any folks figure this answer out, I'd love to hear it)

 

- -

 

Second - a footnote for those not familiar with lpoptions in Applescript or Terminal:  an lpstat -d command will return your OS-level default printer name. But that's the actual device name, NOT the "nice name" (as generally seen in System Preferences). 

 

AppleScript (and Terminal shell scripts) have to know the actual device name.. You can find it by going to Terminal ("lpstat -d " for default or "lpstat -p" for ALL)  OR, by opening the printer in Sys Preferences, and looking at Options & Supplies > General.

 

 

Hope this helps somebody else!