12 Replies Latest reply on Jul 15, 2013 11:50 AM by Tusquittee

    Split single payment across multiple registrations:  portal issues

    Tusquittee

      Title

      Split single payment across multiple registrations:  portal issues

      Post

           Hi all, 

           My goal was to create a way to split a single payment across multiple registrations before supper time.... but, alas.. no such luck.wink  I've got a Payment Detail Layout with portal going to a Line Items Table.  Also have a Registration Details Layout with portal going to Line Items and sorted, in theory, so that only the specific split payments (line items) that had been applied to a specific registration would show up. 

           The difficulty is that for some reason the portal on the Registration Details Layout is showing not only the correct split payments.. but also an almost blank line portal row.  

           For example...From the student page I create a payment.  From the payment detail page the user must apply that specific payment (either all of it, or in portions) to a specific registration.  So far so good... Everything looks fine there.  There's the totally blank portal row at the bottom but that's fine because I need the users to be able to click for another row if they needed to split the check three ways.

           However, when you navigate back to a specific registration... not only do you see the portion of the payment that was just applied, but you also see an extra portal row that makes no sense.  Each of the portions of a payment are given their own Line Item ID yet the magically appearing extra portal row has NO line item ID and NO payment information... but it has duplicated the date of the previous portal row.  

           I don't understand where this odd portal row is coming from but I do know if I disallow the ability to create a new record in the Line Item Table from the Payment side... then the blank portal rows don't show up on the payment layout... nor do the odd magically appearing extra rows show up on the Registration Detail layout either.  This might be a possible solution but I really would prefer the user to be able to input information from one place instead of calling up another layout...

           So, has anyone else had this problem? I'm probably missing something very easy here... or.. if this is indeed about the blank portal rows at the bottom of the payment layout, is there anyway I can sort the portal records on the registraton detail layout so that they show up when they're applied AND when they're not empty?.... I'm guessing that would require some type of not isempty statement?

           Thanks in advance... 

      question.jpg

        • 1. Re: Split single payment across multiple registrations:  portal issues
          Tusquittee

               This is the layout with portal on the payment detail side.

          • 2. Re: Split single payment across multiple registrations:  portal issues
            Tusquittee

                 This is the layout with portal on the Registration side.  Note that there's an extra portal row which duplicates some, but not all, of the information from the previous row... Where is that coming from?

            • 3. Re: Split single payment across multiple registrations:  portal issues
              philmodjunk

                   Sounds like this is the blank bottom "add" row typical of a portal where the relationship enables adding new records directly to the portal. I would guess that the fields that do not appear empty here are not from the same Tutorial: What are Table Occurrences? as that specified in "Show Related Records From" in portal setup.

              • 4. Re: Split single payment across multiple registrations:  portal issues
                Tusquittee

                     Thanks Phil.. 

                     The blank empty portal row on the payment detail layout is exactly as you stated... there because I've enabled adding new records directly to the portal.  But the odd row on the registrtaion detail layout is still... well, odd.  There isn't more than one table occurrence.  I've looked at the Relationship chart... can't find another Line Items TO at all... and.... both the portal on the payment detail and the portal on the registration detail reference the same table... Line Items.  

                     Still Confused... and still searching for that extra table occurrence... 

                      

                • 5. Re: Split single payment across multiple registrations:  portal issues
                  Tusquittee

                       I'm back again Phil... 

                       Are you saying that precisely because I have allowed for creation of records that this is why i'm getting an odd row on the second layout? (Line item portal on the Registration Detail Layout?)... OR... were you saying that I must have more than one table occurrence of the Line Items table somewhere? (The coffee has grown cold and is running dangerously low...and I'm afraid I missed something you were trying to tell me about table occurrences?frown)

                       If the first is true, and considering I really don't want to create a separate layout for the line item data, is there anyway to filter the records on that portal so that only the rows with data in them show up...? Perhpas something along the lines of an isempty ... or rather a not is empty calculation? that would have an AND statement as well....

                        

                       ie... Could I filter so the portal records would be visible when a certain condition is met AND exclude those where the Line Items::Line Item ID is empty... 

                       Thanks again for all the help...

                  • 6. Re: Split single payment across multiple registrations:  portal issues
                    philmodjunk

                         I am guessing that the bottom row in both screen shots appears due to the "allow creation" option. I have suggested that the fields which show data in that bottom row in the second screen shot are due to being fields from somewhere other than the portal's table occurrence. These fields may not be from a different occurrence of the portal's table, they might be from a completely different table all together.

                         I don't know for a fact that this is the case, I am guessing based on very limited info but a great deal of experience with FileMaker.

                    • 7. Re: Split single payment across multiple registrations:  portal issues
                      Tusquittee

                           Thanks for all the help Phil... After reading a few other posts I realized my relationships and portals were set up incorrectly.  Having redone the relationships now I'm struggling with a script that would allow me to add a payment from the student layout.  What I had originally was this script..

                           Add Payment from Student Panel

                            

                           Set Variable [ $$CURRENT_CONTACT_ID; Value:Students::CONTACT ID MATCH FIELD ]
                           Go to Related Record [ From table: “Payments”; Using layout: “Payment Detail” (Payments) ]
                           [ Show only related records; New window ]
                           If [ PatternCount ( Get ( ApplicationVersion ) ; "iPad" ) ]
                           Go to Layout [ <unknown> ]
                           Else If [ PatternCount ( Get ( ApplicationVersion ) ; "Pro" ) ]
                           Go to Layout [ “Payment Detail” (Payments) ]
                           End If
                           Set Variable [ $$SCRIPT_TRIGGER; Value:"Off" ]
                           New Record/Request

                           but this isn't working correctly... It does pull up the payment detail layout.. but on part of that layout i had fields related to that specific student.. so that while you're entering a payment it would be clear who you were entering the payment for...

                           my guess is that now payments are related to registrations not to specific students and that this is where my problem lies? Any suggestions for a script that would work in this scenario?

                           Thanks

                            

                      • 8. Re: Split single payment across multiple registrations:  portal issues
                        philmodjunk

                             You aren't limited to a single table occurrence for Students. You can create a second occurrence and link it directly to Payments by CONTACT MATCH ID FIELD (So cumbersome a name! I'd name it __pkStudentID).

                             Then your script can copy this ID to a variable, change layouts as your script already does, but then start a new payment record and copy the value from this ID field into a match field in the new payment record.

                             Set Variable [ $StudentID ; value: Students::CONTACT MATCH ID FIELD ]
                             Go to layout ["payment Detail" (Payments]
                             New Record/REquest
                             Set field [Payments::_fkStudentID ; $StudentID ]

                        • 9. Re: Split single payment across multiple registrations:  portal issues
                          Tusquittee

                               Okay, So I added another TO for the Student Table.  and changed the fields on the payment layout to pull from that TO (Student2)...I also changed the script as you suggested...(sorry for the crazy naming convention smiley) So far so good.

                                

                                I have a portal on the payment layout that's from the Line Item Table.  It allows me to enter what portion of the payment I want to apply to which registration.  In that portal I have the following two fields..

                               LineItem::Payment Amount... which is the portion of the payment I would be applying to some registration...and then I have the

                               LineItem::REGISTRATION ID MATCH FIELD...which is a drop down list using values from Registration::REGISTRATION ID MATCH FIELD but restricted to related values from Students.  (Even if I change the restricted to the related values from Students2... this still doesn't work.)...

                               Any suggestions?

                          • 10. Re: Split single payment across multiple registrations:  portal issues
                            Tusquittee

                                 Is it correct that I should have to change the payment layout so it pulls from Student2?  or Perhaps I still don't have the script correct? Should I have set the variable in relation to the Student2 Table?

                                  

                            Add Payment from Student Panel

                            Set Variable [ $$CURRENT_CONTACT_ID; Value:Students::CONTACT ID MATCH FIELD ] Go to Related Record [ From table: “Payments”; Using layout: “Payment Detail” (Payments) ]

                            [ Show only related records; New window ]
                            If [ PatternCount ( Get ( ApplicationVersion ) ; "iPad" ) ]

                            Go to Layout [ <unknown> ]
                            Else If [ PatternCount ( Get ( ApplicationVersion ) ; "Pro" ) ]

                            Go to Layout [ “Payment Detail” (Payments) ] End If

                            Set Variable [ $$SCRIPT_TRIGGER; Value:"Off" ]
                            New Record/Request
                                      Set Field
                            [ Payments::CONTACT ID MATCH FIELD; $$CURRENT_CONTACT_ID ] 

                                  

                            • 11. Re: Split single payment across multiple registrations:  portal issues
                              philmodjunk

                                   Starting back with your preceding post...

                                   The basic setup looks correct for setting up a portal to line items for divding up your payment. But there is no relationship in place that will work for geting a conditional value list of just the registrations for that individual. If you link in an additional occurrence of regestrations to the right of students 2, you can define your value list to list values from this new table occurrence and select Students 2 as the "starting from" table occurrence.

                                   In your script, remove the Go to related records step in line 2. You have to have a valid relationship to payment before that step will do anything and you won't always have related records in payments. Either that or you add code that checks for the existance of related payment records and uses GTRR to bring them up in a new window but then you had an Else clause that uses new window/go to layout to do the same thing when their aren't any related payment records.

                              • 12. Re: Split single payment across multiple registrations:  portal issues
                                Tusquittee

                                     You sir are a genius.. Thank you once again...