Jump to content
Sign in to follow this  

Script to Print Records - Need Help

Recommended Posts

Hi All,

I'm struggling with a script. I have three tables - Clients, Progress notes, and Add on progress notes. From a layout on the clients table I want to go to related records in the Progress notes table and if a field (Set AON) is set to "1" the script will print the progress note and then go to the add on progress notes table and print the related record(s). Then back in the Progress notes table, if the field (Set AON) is blank, print the progress note record.

Below is what I have but it's not working as I expected. It is printing each of the records from the progress notes table first, then prints the record from the Add on Progress Notes (I'm actually not printing them but trying to save them all to a PDF file which can be saved or printed).

I know this seems convoluted but I need these steps to happen in this order because I need the Add On Progress Note to Print right after the the Progress Note since they go together. Also I need the Progress Notes to be in order by date.

I'm using FM Pro 13 Advanced (13.0v9) on a MacBook (other users are running XOS and Windows) with macOS Sierra Version 10.12.2.

Any help would be greatly appreciated. I have struggled with this for several days with no luck. I would say I'm a beginner to intermediate with FM. Scripting in FM comes after my real jobs of being a mental health professional and a small business owner so I go for several months at a time between working on the development side of FM. Actually, I could use some therapy myself after fighting with this script!




Print Progress Notes.pdf

Share this post

Link to post
Share on other sites

It would be easier for me to fix the script with a sample file, but I see a few problems.

First may be structure.  I wonder about Progress notes and Add on Progress notes being in separate tables.  But that aside a few questions.

If a Client has Progress notes, can I assume AON (add on notes) is set to 1 when there are add on notes in a related table?  If so, how is it set, and do you even need to set this flag field.

Also what happens after you print all of these records.  Are you omitting them or marking them in a way that prevents them from reprinting when the client has more Progress Notes?

I see you flipping back and forth between layouts when it may not be necessary.

Are you only printing one client at a time?

A simpler way may be to forget the flag field and check for related records in the Add on notes table.

From the start I would first check for related records in an If statement, then set the client ID, then go to related records.  This way if there are no related records, you don't enter the loop.

Sort records instead of Sort Records by Field

Then I would enter the loop and Print (save to PDF) the first Note.

Then I would check for related records with an IF statement for Add on Progress Notes.

If Add on Notes, you enter the inner loop and you go to related records, new window, to the proper layout, and print (append) each on of those, then close window.

If No add on notes, you continue on outer loop, to next Notes related record.

Share this post

Link to post
Share on other sites

Steve, thanks for responding. I will give your suggestions a try.

In response to your questions:

I have two separate tables for the Progress Notes and Add On Notes as separate tables for a couple of different reasons. The Add On Notes takes place at a later time on the same day as the original note and it impacts the CPT coding in yet another table (Claims). I have thought of creating one table to hold both but that would require a major change to the structure of my tables (I just don't have time to make those changes and I'm worried about what kind of problems will occur with that kind of change). 

The AON field is set to 1 via a script initialed by the user when they create the Add on Note.

Once the notes are printed (saved to PDF) they are either emailed to someone or printed out and given to someone. We often get requests for records from attorneys, disability admin, and others. So at any given time all the client's progress notes might need to be printed or emailed. So these records might need to be printed again in the future with any additional notes. 

I would only ever need to print one set of notes for a given client. So only printing one client at a time.

Thanks again for the suggestions which I will try. What really drives me crazy is that what is inside the Loop works in a separate script when I just print one record. 


Share this post

Link to post
Share on other sites

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
Sign in to follow this  

  • Similar Content

    • By stan111
      I created a dashboard with a bunch of buttons, attached script to every button, which allows me navigating to specific record of the Products table. Basically, every script is the same, with minor changes (only record ID field changes).
      The process of creating a script to every button is a very time consuming as I need to write a script that  a) goes to layout b)finds the certain record 
      1 "Step: Go to Layout
          Layout: Products
      2 Step: Perform Find" 
      Is there a way to simplify the task?
    • By Jonathan Ackerman
      is it possible to append text or images to the end of a loaded doc. (not just another document)-
      i.e. something like--
      $result=ScribeDocAppend ("new stuff")
      it seems the function only looks to append other files, not text
      what i need is to be able to add custom text to the end of some documents-
      not sure how to do this.
    • By kims
      I am working on a script that will build a document based on a value from a drop down list.
      I have a layout that contains a Document Subtype. If a certain subtype is selected from the drop down list for this record, then I want my script to be able to pull from a specific container holding the appropriate document for that type. Then I can use Doc Append to combine the two documents. Each document would be custom then to the subtype.
      I'm pretty new at FileMaker so I'm still trying to figure a lot of things out and still trying to understand how to put things together and why it will/will not work.
      I was originally using Case but then I realized that was probably not the correct thing to do. It would either append both types of documents or one, but it wasn't always the correct one.
      Any guidance would be greatly appreciated.
      If this helps, I want something that will do this:
      If Subtype = a, b, or c, then append Doc 1
      If subtype = d, e, or f, then append Doc 2
      and so on...
    • By Asu
      Hello FM experts, 
      this is a concept step for a more complex script but I need a script that has 2 independent features:
      1: it selects the field it is attached to as a button
      2: it can be attached to any arbitrary field and it does the same on that field.  
      The imaginary script step would be this:
      Select field [the one I am attached to] The problem I am running into is that "go to field" can not be defined by calculation, while "go to object" gets confusing between the script and the field being grouped, as the problem detailed here [https://www.soliantconsulting.com/blog/story-about-go-to-object] seems to be a complicating factor.
    • By Asu
      Hi FM Mavens, this will be long, I am sorry. The following is the setup:
      Small medical office database I am writing for myself. 4 tables: "Pts", "Encs", "Rxs/RxDup" (patients, encounters, prescriptions - patients have several encounters, encounters have several prescriptions.) RxDup is a duplicate of Rxs but that is not why it is called RxDup, it is called that because it is used to duplicate individual medication orders. 
      Mac OS 10.13.2, FMPro Advanced
      Task: (a) selecting an arbitrary number of records in a portal within Pts that looks at Rxs by setting the match field to a certain value (b) going to the records that become related via this act and (c) doing something with those records (duplicate them). (c) is not problematic. (a) and (b) are.  
      Relationships: Pts - Encs via _PtID, Pts - Rxs also via _PtID, Encs - Rxs via _RxID and Pts - RxDup via _RxDupID.
      _PtID is a serial number of patients. It is added to every new encounter record for any patient in table "Encs". This is clear and it works as it should.
      _RxID is a combination decimal number obtained as  _PtID + encounter serial for that patient * 0.001. So for patient #25, prescriptions written on visit 1 will be matched between "Encs" and "Rxs" via 25.001, etc. This also works as it should.
      As table "Rxs" also has _PtID,  all prescriptions are visible from table "Pts".  This also works as it should. 
      All these are static values. I mention these only for the sake of completeness, there are no problems here. 
      _RxDupID is the value of _PtID combined with the term "dup" (a text field) e.g. "25dup". It is the match field between tables "Pts" and "RxDup".
      In table "Pts" _RxDupID is a static calculation text field.  In tables "Rxs/RxDup" it is a text field that can be set to the match value or to "". The setting occurs via clicking a checkbox on or off in the portal looking at "Rxs" from "Pts" via the _PtID relationship.  The value list attached to the checkbox is the value of _RxDupID in the active "Pts" record, obtained via a Pts-to-Pts self-relationship using PtID.  This also works, i.e. the value of the match field in the Rxs records seen in the portal is correctly set to the single value that shows up in the value list. I assume that this occurs in RxDup as well necessarily and simultaneously. (Am I correct?)
      The following happens:
      I open the database, go to today's set of patients. I go to one of the 5 patients whose records are in today's found set. Let's say it is Pt #25. I tab to the portal showing Rxs, let's say there are 30 previous rx orders showing. I click the checkbox in 3 records. I see it confirmed that the match fields are set to what they should be (PtID & "dup"). I run the script 
      Go to Related Record [ From table: “RxDup”; Using layout: “Rxs DUPLICATOR” (RxDup) ]
      [ Show only related records ]
      Do (c)
      It does what it is supposed to do. It goes to the 3 related records in the correct layout and does (c) on them.
      Then I go to another one of the 5 patients in the found set. Let's say it is Pt #56. I tab to the portal showing Rxs, let's say there are 50 previous rx orders showing. I click the checkbox in 6 records. I see it confirmed that the match fields are set to what they should be (PtID & "dup"). I run the script again.
      Here it becomes dicey. There are a few ways things can go wrong here:
      - The script takes me to the 3 related records of Pt #25 and does (c) on them. 
      - The script takes me to the related records of Pt #56 but not all 6 show. If I go back to the portal in Pts and run the script again, this time it may show all 6 records.  
      - The script takes me to some or all of the related records of Pt #56 but in some records the match field is blank. (This really baffles me)
      Then it becomes really interesting. 
      I go to a third patient in today's found set, lets say it is Pt #77. I run the script again.
      I get a 101 Error. The script does not go to the related records in table "RxDup", it stays in table "Pts" and runs (c) on the 5 records there. 
      This repeats reliably. On first run, and sometimes on second, the script works well. On runs 2 - 4 it makes an error in going to the correct (or correct number) of related records. Eventually it does not go to the related records at all.  
      The indexing of both match fields are set to "All". I tried "None" with "automatically create indexes" but the result is the same. 
      My guess is that something goes wrong with the indexing but I could be wrong of course. Any help would be much appreciated. 
      Thanks, Asu

Important Information

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