amigotto

Unfortunately, it looks like I have to abandon the switch from using jpeg images to pdfs. The reason is not so much the question of printing multiple page pdfs, since I have abandoned that and have been saving each page as a separate pdf file. The main reason I'm switching back to using jpegs is that pdfs DO NOT PRINT at 300dpi no matter what I do! They only print at low resolution. I have scoured both this site and everywhere else with not even a mention of this problem. Is it possible that I'm the only one who wants to print pdfs embedded in a layout in a container field? Is that just a crazy idea? Am I nuts? This works fine with 300dpi jpegs. OK so where did I put that pdf to jpeg converter app...?

Thanks for your reply. Yes, display pdfs in container fields on a layout and print them, as I have been doing for years with jpegs (which are all 1-page images). Yes I wish to have FM add a header and footer to the multipage PDF. I understand it can't be done, so I'll just split multiple page pdfs into 1 page documents and all will be fine. The reason I was using jpegs is that our environment included Windows, which can't display PDFs natively in FM. But now that the office is all Mac OS there is no need as most of the images are PDFs generated from text, which are much more manageable in terms of file space and overall system load. Also I no longer have to convert PDFs to JPGs, etc. It would be a great feature though...

Anyone?

Im trying out FM12 and have a container field used to hold links (via calculation) to image documents. Up to now, the images were saved in jpeg format (1 image per page) for mac/windows access. I am moving to a Mac only environment and prefer to use PDFs, since most of the documents are originally in PDF format - mostly text, so I won't have to convert them to jpegs as I have been doing. Everything works fine except for printing multiple page PDFs. Is it possible to print multiple page pdfs from a container field optimized for interactive content? The layout adds header and footer data to each page, so printing must occur in Filemaker. Other than saving each page of a multiple page document as a separate PDF, is there any solution available? Thanks, Alvise

That's it - thank you!

How would I report a successful script run? By setting a "successful run" date field with today's date as the last script step?

Hello, I've searched for an answer to my problem here and on Google but have not found one yet. Can anyone help? I have an Open Script that generates a report, saves as pdf and sends it as an email attachment if criteria are met. How do I check if either the file has been opened today or if the script has run today so as to avoid generating the same report and email numerous times on the same day? Cheers, Alvise

OK - I'll try this The fact that it is error prone is what's most important for me - in practice the only fields that describe the overall payment are the date and paymentnumber. But even these are verified at the time of payment or reconciliation, which reduces error to a minimum in this case. So if I create a separate table, that table should include all fields in common between payment items that would need the sam payment number, correct? Bank statements are numbered manually (by hand) on the printed bank statements. These numbers are then entered manually in the database. This is the weakest link in terms of being error prone.

Woops! Spoke too soon. Although a step closer, reimbursements can have 1 payment item as well, so I still need to omit these. :idot:

Got it! Omit the records whose "reimbursement number" field is empty! Thanks guys! Can you explain why having the payment items in a different table is a better model? I should maybe look into this for a future upgrade to the system.

Payments are numbered sequentially according to bank statements upon reconciliation (manually). Multiple payment items are usually (but not always) a result of reimbursement and are grouped by a "reimbursement number" field. For example - a credit card bill will have several individual payment items. Each day when payments are made a report is generated. The credit card items are grouped so that the report shows the total amount for the bill, which is what appears on the bank statement. The final financial reporting for the project includes the individual items (with the same payment number) sequentially listed according to the bank statements, and another report which has a subsummary part by payment number which shows all payment totals according to the statements. Another report shows only grouped payments - which is the one I now manually omit unique numbered payments from. Yes, since there are many accounts it is possible to have the same payment number on the same date in different accounts (event the same chque number!), which is why the find duplicates doesn't work.

Since I have many reports set up which use the database the way it is setup now, it would mean reworking the whole database which is not possible at this time. I can't see how I could generate the reports I do now if I had to use separate tables to do so. (I'm not that proficient yet). The way it is set up each payment item in the table is entered as a separate record (which has specific related documentation, accounts, budget items, tax deductions, witholding caclulations,etc). Tom the find duplicates syntax doesn't work in this case because I'm searching for duplicate entries in one field but at the same time I have to search a specific account (another field). At the moment I just generate the report and omit the unique records manually. I only takes a minute or so (for a 500 record project) but it would be nice if I could automate it. Thanks for your help.

Hi Guys, I have an "expenses" table which includes project, account number, payment date and payment number fields. In the case where one payment may represent two or more expense items, I can have two or more records with the same payment number, such that when those records are added together, the total payment amount for the same payment number matches the amount debited from the account in the bank statements. For example, if a hotel bill containing room charges and restaurant charges is paid with one cheque or credit card transaction, two records are entered with the same payment number, one for the room and another for the restaurant. Or when reimbursing employee expenses, etc. I'm required to produce a report which includes only those payments which represent grouped expenses. In other words, I need to find all payments with the same account name, payment date, and payment number, omitting records which have unique payment numbers. I have a layout which shows the data as required but how can I automate the omitting of unique records?

Thanks to all for your input! I have modified the script so that the record in the credits table is created based on a relationship. All I needed to do was create a field called "Account Credited" in the debits table which is only available on a layout called by a script button to "export record to credits". Once the account is selected by value list and passes validation to avoid selecting an ineligible account, a new entry is created in the credits table and all necessary fields are set via the relationship. As I was wrapping my brain around this problem I realized that both of the remaining 2 fields that required entry in the credits table could only have one "correct" possible choice from their associated value lists based on the data in specific fields in the debits record (one of these require data that is not necessarily the same as the data in the corresponding field in the debits table and the other field does not exist in the debits table and therefore requires entry). So these 2 fields are now set by calculations, which means no user error. HOWEVER, I still need to use the Pause/Resume script step when the script is called and waits for the user to enter the Account Credited field. I have a continue button there so the user can make sure she has selected the proper account. I was trying to avoid this in order to streamline the process earlier but in this case the layout contains only the Account Credited field as a Pop-up menu and the continue button. It is a much more streamlined solution requiring only a verification of the newly created record in the credits table and most likely no modification. So I guess I can live with it. (OK - so I have a cake. I love this cake. I love eating this cake. But I love this cake. It's really good cake...Hey! were's my cake!...)

Splitting the script into 2: I tried Splitting the script into 2 as you describe and that works, but there can be instances where the 2nd part does not trigger or conclude and the final instructions wouldn't be passed to the user. The way I have it now works very well. I see no problems with it. WHY shouldn't I do it this way? Why 2 records for 1 transaction? As for two records for one transaction, it is really two transactions. All records correspond to transactions in bank statements. So I have a record which corresponds to an outgoing sum in one account statement, and one record which corresponds to an incoming sum in another account statement. I guess I could create the incoming record via relationship but I only need to identify which account to credit when I'm transfering funds from one of our accounts to another of our accounts, and not for all payments. In any case I thank you for this suggestion. I will look into doing it this way. I could set the values of 2 of the 3 fields to be modified automatically based on fields in the outgoing record, eliminating the need for both the script as well as manually entering data in the 2 remaining fields. In this case I would add a credit account field in the outgoing table (which is one of the 3 fields to be filled in in the incoming table), which would be the match field for the relationship, correct?