Invoice Payment Method in TNEW v7?

I wasn't even aware that payment plans didn't work in V7. Ugh! We are going to be entering renewal season here shortly and need this functionality. Have you heard mention of when this will be available?

- Chris

Hi Sara and Chris, 

Integrating payment plans into v7 is one of our top priorities as we know many organizations require them in order to go live with v7. Our current target is having them in Beta by end of Q1 2019. If you are already on v7, we would suggest adding messaging and/or materials to your website in order from them to contact you or submit their order via mail although we recognize this isn't ideal. 

If you would like to keep track of our progress on this feature and others on our roadmap, you can check this page on our website: https://www.tessituranetwork.com/Support/Roadmap/TNEW. We also conduct sprint reviews so you can see our team's progress and learn about the features as we develop them. Our next one is actually this Monday, 12/3 at 12:00pm ET if you can attend. 

If you have further questions, let us know and our support team can help you!

- Nara

Hi Nara,

Unfortunately, the volume of paper registrations would be overwhelming for our small staff so that's not really an option for us. I've been attending as many sprints as possible, which is how I realized (after we went live with v7) that payment plans weren't an option. I'll definitely be on today's call :-)

If the Invoice Payment method won't work online, then our next best case scenario is to create a dummy registration deposit perf where patrons would pick the class and pay the appropriate deposit. This isn't ideal though as we use packages to sell the actual summer programs and add-ons and I'm worried about capacity issues. There are also different deposits based on the add-ons selected. Additionally, this workaround would require the Registrar edit the orders to move the student from the deposit class to the package and add-ons they really intended to purchase (in addition to manually creating payment plans in the application).

Thanks,
Sara

Sorry to burst your bubble Chris. I wished I'd paid better attention as it's going to cause problems all over the place for us as the Education Dept and Sub Renewals both start major on-sales right after the 1st of the year.

In more bad news, after some testing, it doesn't look like I can enter anything other than credit card payment types in the LTR_TNEW_DYN_PAYMENT_METHOD table so that doesn't look like it'll work.

A workaround I've seen in this scenario, which does not require a dummy perf or exchanging seats, is to have a "deposit" price type. In the cases I'm thinking of there was not the extra complication of add-ons affecting the deposit amount, so this may not be adequate, but it's worth considering. You would have your same real performances (and packages) and when folks go to register online, they have a choice between a "full" price type and a "deposit" price type, mapped to the applicable amounts. You might even be able to use pricing rules to manipulate the amount on the "deposit" based on your add-ons. You'd likely still need some human intervention after the fact to edit the orders and switch them from the deposit to the full price type and then set up a payment plan for the remaining due amount, but it would potentially solve the capacity concern.

Thanks Amanda. I'll give that a try.

Amanda Freeman's Deposit payment types for the win! I created pricing rules that force the add-ons to have the same price type in the cart (though patrons can select either price type when selecting the add-on). May be a web developer could figure out how to hide price types through the API or with CSS. That's a goal for me :-)