Grouping Like Items in a Repeating Group

Since adding deposits into my app, I’ve had to rework how transactions are saved and displayed.

My database is setup as

  • Clients
  • GroomingAppointments
  • TransactionHistory

When payment is accepted, a TransactionHistory is saved inside that GroomingAppointment.
It’s possible to check all Appointments out at once, if the Client is assigned to each Appointment. But, when displaying the Receipt, I’m having this issue;

I have a Repeating Group inside a Repeating Group. The first Repeating Group is the GroomingAppointment, inside that RG is TransactionHistory. This way, the Options applied to that pet are grouped together.

When each appointment is created, it’s separate, therefore each transaction is singular to that appointment, but when it’s checked out it’s grouped, so as you can see the final payment is being displayed twice which makes it look like the customer paid 2x the amount.

I’ve tried everything I can think of, but I just can’t seem to get it right. Each transaction has a TransactionHeader, and I need to skip repeating TransactionHeaders, but I can’t figure out how to check the first RepeatingGroup for repeating TransactionHeaders. Is it possible with the way I’ve set it up?

The solution lies in the data source of your nested RG. It needs to have a constraint that is equal to the parent RG’s GroomingAppt. What is this currently?

So the source order goes;

Initial Page is Client (User), with a date constraint under a custom state.

The first Repeating Group is searching for GroomingAppointments Where Client=Current Page User, and AppointmentDate=Current Page’Appointment Date.

The Nested Repeating Group is searching TransactionHistory’s that are inside that GroomingAppointment.

The explanations you’ve provided should result in the outcome you’re looking for. It would be more helpful if you shared screenshots of the datasources.

Well the problem is, when each appointment is created with a Deposit, 1 Transaction is added to it, so they are both unique.
When they are checked out, it’s designed to check out multiple appointments at once, so each appointment gets that same Transaction added to it.

Here is the initial RG Source

And Nested RG
Screenshot 2021-02-06 134336

I thought about making the Transaction History the initial RG, and then the appointment, but that would only work if the Deposit was created the same day the Appointment is settled for it to show both.

Why are you “adding transactions” at check out? The check out workflow should just be updating an existing transaction that it has been paid.

It’s possible for an Appointment to be booked a month in advanced where a Deposit is taken, then a month goes by and the Client comes in and completes the transaction.

I guess what I could do is, the initial transaction is all the deposit information, and then update the transaction with the remainder of the total in all the usual spots.

My only concern for this was that if my customer is printing off their End of Day statements or Transaction History, it would become incorrect the second a transaction is updated.
And then I do keep the Stripe Response, but I could convert that to a list that would just add the new stripe response when the transaction is updated. But that makes a lot more sense. Just another case of tunnel vision.

It dawned on me after looking into editing existing transactions.

I already had the date range, so now I have 2 separate RG’s. One for the Appointment, the other for the Transactions associated to the dates of those appointments which gave me the result I was looking for.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.