7 Replies Latest reply on Sep 22, 2014 12:06 PM by nihmbrisby

    Appending fields of text to a report.

    nihmbrisby

      Title

      Appending fields of text to a report.

      Post

      Summary: Basically I need receptacles to store text that can be edited and take advantage of filemaker's 'sliding' abilities for printing and have no use after the report is printed:

      I have a report that is the basis for a printout.  It's an invoice.  It consists of:

      Leading grand summary with basic invoice stuff (date, invoice number, 'bill to')

      Body (the items being sold)

      Footer (displays company address at bottom of every page

      Trailing grand summary (totals)

      What I need: After totals, I need to allow the user to input "Terms and Conditions."  For simplicity sake lets say there are 10 standard terms (for instance, one give bank info like routing number, another states the return policy).  The user will select from this set of 10 ( All, some, none- it just depends).  Once selected, the user will occasionally need to edit the terms, however this should NOT alter the terms for future transactions.  The 10 terms have to remain unchanged.

      My idea had simply been this- store the 10 terms on a table I have that is dedicated to these sorts of constants.  After the Total on the trailing grand summary, I need 10 fields (to accommodate any some or none of the 10 Terms and conditions).  The fields all slide up and have the 'also resize enclosing part.'  It all works perfectly.  

      The issue is with the 10 fields.  I can't think of a good way of creating them.  Originally I had just assumed 10 globals (so every user can generate reports at the same time), but the user may have multiple reports open each with different terms- thus 10 globals would not work.

      Then I thought, well I guess I'll have to create 10 new fields on every table whose corresponding layout generates a report.  First of all, I'd like to not create so many new fields and associated info.  Secondly, it would still be a problem if multiple users were generating reports based on the same record (thought that is less likely).

      Is there some elegant way of doing this?  

      Thanks.

        • 1. Re: Appending fields of text to a report.
          philmodjunk

          You need a value list of 10 values with a field defined in you invoices table to receive the value chosen. You can use a check box format and the terms selected will be entered as a list separated by Returns. On your print layout, an edit box format can be used to list the terms if you wish. Since this is data entered into the Invoices record, future changes to the terms in your value list will not change the terms specified for a previous invoice.

          Your list of terms can be 10 entries in a custom values value list or 10 records in a table where you select the "use values from field" option for setting up your value list.

          For more examples of what you can do with value lists, see the Adventures in FileMaking series. Adventures 1 and 2. They are free to download.

          Adventures in FileMaking #1 - Conditional Value Lists (includes details on how to set up a basic field based value list)
          Adventures in FileMaking #2 - Enhanced Value Selection (how to get more out of your value lists and what to do when a simple value list won't cut it.)

          Caulkins Consulting, Home of Adventures In FileMaking

          • 2. Re: Appending fields of text to a report.
            nihmbrisby

            Thanks Phil.  This part is my problem-

            "field defined in you invoices table to receive the value chosen"

            2 things-  

            A single invoice may have multiple users generating docs from it at the same time

            A single user may have multiple docs based on this invoice at the same time.

            Multiple docs can and will have different terms.  The particular set of terms chosen and edited need not be saved. Am I wrong in thinking that a field defined in the invoice table will not allow multiple users to edit different versions at once

            I basically want blank space at the end of the document to contain the terms chosen by the user until they print/save the doc.  Is there some sort of text receptacle that will accommodate my needs?    After that the terms can just disappear for all I care.

             

            • 3. Re: Appending fields of text to a report.
              philmodjunk

              I don't know what you mean by "generating docs at the same time". What does this have to do with 10 fields for listing "terms and conditions"?

              I'm a bit in the dark here as to what you are doing, but as a bit of a guess, this might be a case where you have multiple users creating records in a related table all at the same time and that is quite possible to manage and these records can all be linked to the invoice record.

              • 4. Re: Appending fields of text to a report.
                nihmbrisby

                Sorry I've not been clear- I appreciate your patience.  I've attached an image that I hope will clarify my situation.

                • 5. Re: Appending fields of text to a report.
                  nihmbrisby

                  Looking back at that image I'm still not sure I've fully articulated my problem.  It's like this- one user may be editing multiple bills based on different transactions.  Thus, a global field won't work- each bill needs a unique value.

                  However multiple people may editing bills based on the same invoice- thus a non-global won't work.

                  It's even possible that a user may be editing multiple bills for one transaction- ruling out both approaches.

                  I'm not creating any new records, I'm simply switch to a layout formatted for printing.

                  At the moment I'm guessing I'm just going to have to sacrifice the ability for multiple bills to be open for the same invoice at one time.  I'll probably just have one Terms and Conditions Field for each type of document.  That way at least, a person can be simultaneously working on a bill and a certificate of value based on the same transaction.

                  • 6. Re: Appending fields of text to a report.
                    philmodjunk

                    However multiple people may editing bills based on the same invoice- thus a non-global won't work.

                    But that really can't be done at all. Only one user can edit any given invoice record at a time. The others will be locked out and should be as you would otherwise have a great deal of confusion between users and your customer as to what is going on with that invoice.

                    I think that you need to explain what you mean by "multiple bills for the same invoice" as there is no support for that concept in your current data model. My best guess is that you repeated bill a customer for the same transaction such as sending them a bill once a month until the bill is paid or something similar.

                    If so, it would appear that you need to set up a related table linked to Invoice where you create a related record each time you bill the customer for that one transaction. This then puts your multiple users on the same invoice all in different records of this related table as a way to keep them from locking each other out of the record.

                    PS. Some systems solve the "edit lock" problem by copying the data into a set of global fields where the user edits the data and then a script "saves" the edits by copying this data back to the original record--thus opening the record for editing for only the fraction of a second needed in order for the set field steps to move the data. But this approach must be used with caution as it can result in confusion on the part of users when they see data they entered mysteriously revert to previous values when a second user editing the data at the same time submits their changed data after the first user submitted theirs.

                    • 7. Re: Appending fields of text to a report.
                      nihmbrisby

                      Ah I see- my bad.  I was just modeling it in my head, but I didn't fully grasp the record locking mechanics (up until now, my 'new window' heavy database had only been dealing with new/different records in new windows).

                      I just implemented everything and I see exactly what you mean.  I'll take a different approach.  Many thanks for your patience.