Type in your suggestion - new feature or improvement idea

Situations and scenarios for not using financial module

In our 4.3 release back on Dec 14, 2011 we have changed payment workflow - it now always goes through the following steps:start the transaction (e.g. event registration), fill out appropriate fields, confirmhave the invoice generated and displayed on a special page which lists full history of invoices and payments, highlighting open invoicespay for this invoice right away - or proceed to another transactionBefore 4.3 release, people had no ability to see invoices, only administrators was able to do it.

New workflow resolves many frequent requests we had, including: People can pay for several invoices with a single paymentThey can always retry later if their original attempt at online payment failed Administrators can manually create invoices, email them and have them paid onlineOverpayments and credits some members might have on their accounts can now be applied to future payments. Visitors can apply for membership, then register for an event and pay for both. (When a visitor starts event registration and there are member-only registration types, system suggests to apply for membership and after application shows him a button to continue event registration.)Member can see his payments and invoices history, including registration details without having to contact administratorsAll contacts, not only members can log in, view invoices and pay online We have now received a number of requests from people who want to completely disable these new capabilities and not show invoices and payments to their members/contacts. We have started our conversation about possible solution options here - http://forums.wildapricot.com/forums/308920-archive/suggestions/8835424-dealing-with-messy-financial-history-shown-to-cont - but soon realized that we need to address a basic question first:
Why do you need to disable this new functionality? What are your internal processes and how does this functionality interferes with them? Until we have a clear understanding of this, we can’t design a proper solution (e.g. simply ‘disabling everything’ would break all self-service transactions workflows). Here are some questions we would like to understand in regard to these requests:Do you accept only offline payments, only online payments or both? How do you keep track of unpaid invoices? (Especially, If you don’t do it in Wild Apricot) How are your internal workflows structured? (E.g. what people should do after entering a transaction in your Wild Apricot site, who/how/when enters payments and communicates with people who sent them) Do you use different payment methods for your membership and event registrations? (For example, you accept checks for membership but for event registrations you only take online payments.)What is your ideal picture of payment workflow in Wild Apricot? Please tell as as much as you can about your organization setup - this will help us to figure out the best solution.

4 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Evgeny aka Apricot KernelAdminEvgeny aka Apricot Kernel (Product Manager, Wild Apricot) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    4 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Dmitry ButerinDmitry Buterin commented  ·   ·  Flag as inappropriate

        Thanks for posting. From our perspective invoice is just a mechanism to distinguish between registrations that were paid online from those that weren't. Do far I can't think of a way around this. If you do not record payments, how do you track and reconcile your cash receipts and your event income?

        Can you elaborate - what do you find onerous about applying payments to invoices?

        The typical process is like this:

        1) Find the invoice, go to its details (this can be done from the list of invoices, from a particular contact, from event registrations)

        2) Click on Record payment

        3) If desired you can add information about payment tender etc. Or you can skip this.

        4) Click on Save.

        So recording payment for an invoice is two button clicks.

      • agosnellagosnell commented  ·   ·  Flag as inappropriate

        For events, we encourage our members and quests to prereqister online. Our meeting price is structured to encourage preregistration. So most do preregister. Some prepay - some do not. And for those that wait and pay at the door, we simply collect at the door.

        We do not want a billing and/or A/R process which generates an invoice which we must later apply what we collect at the door or cancel. We simply do not have that sort of operation. Ours is a professional association but not like a country club where there is a contractual obligation to pay dues.

        We do not want invoices generated for our events and we do not want to have to go apply a payment to an invoice later (by the way - that is a very painful process in WA and part of the reason why we do not want to do this).

        With your last update, now we have invoices being generated that are not cleared (partly because it is such an onerous process) and our members are starting to no longer use the site for pre-registering for our events - just the opposite behavior from what we want.

        To answer your questions.

        1) we accept on line and off line payments

        2) We do not want to generate invoices to our members - ever. So we will never track an unpaid invoices. For our purposes - for events - ie meetings and training events - we use WA for preregistration and to hook into paypal for those that want to prepay. At the event, we will bring with us a print out from paypay (or WA) showing who has paid for the event and use that at the door to determine who we need to collect from at the door.

        3) Our member registers for the event. The system offers the opportunity to prepay. if they choose to prepay, WA interacts with paypal for collecting the funds. Rather they prepay or not, WA captures the registration event and we are done.

        4) We allow payment in advance and we take payment at the door.

        5) I think I answered this already in #3.

        I think the simplist way to say this is - make an option to turn off the invoice generation process. Provide an option that allows for registration with no collection or A/R consideration. Allow for payment of the event - but do not require payment.

        I am happy to supply any additional information. You may email me at vp_finance@pmi-charleston.org or call at 843-745-4065.

        So you know - this is having such a bad impact on our membership and operations - and because we can find no soluition to turn off the invoicing process - we are actively looking for a solution to replace Wild Apricot. We encourage you to provide an answer quickly.

        Thanks, Alan Gosnell

      • VCOMAVCOMA commented  ·   ·  Flag as inappropriate

        I know we are getting a ton of complaints about all the emails our members get now with each transaction. Wouldn't it make more sense to have a "Print Invoice" button on the "registration pending" email (whether event or membership)?

      • JenniferConklingJenniferConkling commented  ·   ·  Flag as inappropriate

        I believe this situation is affecting our account. We use Quickbooks for all of our accounting and while we have considered invoicing through WA, we are not ready to do that yet. We accept on-line payments but through a separate cart since you do not link with FirstData.

        I just realized that a member can go into their profile and generate their own invoice and attempt to pay it, even though I have on-line payments disabled. If we aren't using the invoice feature, there should be away to disable it and should also be able to determine whether or not we want our members to have that capability.

        Thank you!

      Feedback and Knowledge Base

      Wild Apricot Inc. 144 Front Street West Suite 725, Toronto, Ontario, Canada M5J 2L7