Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×
The Claris Museum: The Vault of FileMaker Antiquities at Claris Engage 2025! ×

This topic is 7223 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

ok here is my problem im importing the information from a csv file from an older program that my company used. So, im kinda limited as to how the infomation comes in there are 8 feilds that contain the information for the billing these 8 feilds import data from 60+ other container feilds

[color:"red"](Ref1 &

Posted

ok here is my problem im importing the information from a csv file from an older program that my company used. So, im kinda limited as to how the infomation comes in there are 8 feilds that contain the information for the billing these 8 feilds import data from 60+ other container feilds

[color:"red"](Ref1 &

Posted

ok here is my problem im importing the information from a csv file from an older program that my company used. So, im kinda limited as to how the infomation comes in there are 8 feilds that contain the information for the billing these 8 feilds import data from 60+ other container feilds

[color:"red"](Ref1 &

Posted

Is the big red part a calculated field containing the data of the 60 fields?

If so, I would put it on a layout covering two pages with the other 8 fields in header and footer. When printing I expect the header and footers to be present on both pages, the big text field split over the two pages.

Posted

Is the big red part a calculated field containing the data of the 60 fields?

If so, I would put it on a layout covering two pages with the other 8 fields in header and footer. When printing I expect the header and footers to be present on both pages, the big text field split over the two pages.

Posted

Is the big red part a calculated field containing the data of the 60 fields?

If so, I would put it on a layout covering two pages with the other 8 fields in header and footer. When printing I expect the header and footers to be present on both pages, the big text field split over the two pages.

  • 3 weeks later...
Posted

yes that is true that is what will happen, but now here is a a problem not all records will be 60 lines, some might be 3 so i need each record to be independant and adjust for printing depending on the size in the current account. And as far as i am seeing if one record has 60 then if you go to anouther record that has less the slide only adjust to the height of the largest amount... ????

Posted

Use merge fields in a single text block and stretch it to the maximum size of a layout, then set the text block to slide up and shrink.

If the data goes beyond that, you can setup additional layouts as part of the print.

Posted

that isn't the problem i can do multiple print pages no problem,,, it is now that i have set it for a size, the other records print out as if having two pages too even thought they should have one

Posted

no my problem is not if the data goes beyond that, it is some of my data is below the higher amount and therefore trys to print to multiple pages too without any info

Posted

Make sure you have sliding and shrinking set for the text block. Also make sure that any other layout items below the text block are also set to slide and shrink.

Posted

OK, Your data structure is not going to work - you're not taking advantage of the good things about using a database. It appears that you are trying to do make your system work the same way that someone would try to use WORD to manage a database.

I think what you are trying to do is develop an invoice/billing system. You need to split up your data into several tables:

Invoice (your main table)

Accounts

Transactions

Each invoice should be a separate record related to an account by a unique key field. Each transaction on that invoice should be a separate record related to the applicable invoice from the transaction table by a unique invoice number field. Since it looks like you only have 2 products (Ad 1.0 and payment) you don't need a products or inventory table, this could be handled by a value list.

Since you are putting all transactions in a text field and stretching it down, you are using those fields like repeating fields - both of which you cannot do anything with that data, such as sums, calculations, scripting based on specific values in those fields - its just there to look at, and as you have found, you can't really print it very well either.

If you do a search for 'invoice system' or 'billing system' on the forum, I'm sure you could find a file already setup to do what you need, which could be adapted for your use.

If I get a chance, I will try and redefine your file with the appropriate tables and relationships, but I don't know when I'll get time.

I hope my response doesn't sound too negative, or that I'm just dumping on you. I don't mean for it to sound that way - I just don't want to see you continue down your current path, which will lead to more and more frustration trying to make this work.

Posted

oh no thank you for your sudgestions, they were very helpful and confirmed my current concerns. Now here is the last of my problem. all the information that is entered is not entered by hand but will be imported via a CSV file exported from the current way of handleing the data which is an old dos based program. Is the importing of this data going to screw me up, since it comes in as if it were a tabs delimited txt file with all the infomation set to records already

Posted

It's because of the way you colored the background of the tall fields. You used a big rectangle of color. That's an object, not a field, therefore it is not going to shrink. Delete those blocks, and set the background of the field to a color instead. Then it works.

For a fine touch you can go to Format, Line Spacing, Custom, and give a few pixels indent to the columns. Keeps the letters from being right up against the side of the field, which is probably why you were using the color blocks.

You also might think of using a Title Header, and possibly a Title Footer. These will print only on the 1st page. Then you can have a regular Header, which will only print on pages 2, 3, etc.. Footer the same. That way you don't have to have the entire title block on the subsequent pages.

Posted

I didn't even look at the structure. I could tell by the columns that it was flat, so I thought I'd better not look. I have to agree with DykstrL, it's shockingly flat :-!

If you have to import from a flat text file I guess you're kind of stuck. It seems to me that this business will have a very hard time analyzing their business, as to what things are selling, how many, etc.. If all they care about is the overall totals I guess it works.

Your Total Lookup field is pretty much a disaster; it's everything, for no reason, including tons of empty lines of only carriage returns. It should be deleted. Saved .5 MB off the file (30%). The test field at the end is also unneeded I think.

The auto-enter by calculation fields should be Unstored calculations. They are based on editable fields; you are basically duplicating everything in the file just for printing. That would save a bunch more, and speed up the import considerably.

Posted

ok i took out those colored blocks and yet im stillgetting the same thing that they aren't shrinking up?

maybe im doing something else wrong any ideas

This topic is 7223 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.