What’s New... List of New Features


This is a list of additions and fixes by completion dates - most recent changes first. Each build date listed below in blue represents a completion date for a feature described just below that date.  If you see a new feature that you'd like to use, but you're not sure if current version of MemSys already includes it, please check the latest build date, as follows:

  1. Run MemSys

  2. Pull down "Help" menu

  3. Choose "About"

  4. Note "Build Date"

If your MemSys application's build date is earlier than a feature below which you would like to start using, please send an email to support@memsys.com to request an update. This assumes that the feature in question is part of a software module that your organization is licensed to use. Be sure to describe the feature in question. You can copy/paste the help description into your email.


New Features by Build Dates, (most recent listed first)




Report... Pledge... Programs by Air Dates: This is a new report available when MemSys is upgraded to version 5.0. It takes advantage of two new fields in the Break table: Pgm_Start_Time and Pgm_Mins. It scans the Break table for every record linked to the entered Source code, drilling down to count pledges for each of those breaks. The final report provides row details for all breaks with the same: Date + Pgm_Start_Time + Prog_Code. Thus, it is not really a break report, but a programs-aired report. In addition to a printable report, the program exports air-date results to a file named "Program_AirDates_yyyy-mm-dd_HH_MM_SS.csv" on the server folder: "..\Data\REPORTS\ProgramsByAirDates". The csv file is suitable for upload to PBS for benchmarking or to station management. This report is not just for PBS stations, radio stations may also find it useful and informative.


In support of the new Air Dates report, two new entries have been added to "Setup... Campaigns... Break Details". For one or more breaks attributed to the same broadcast of a Progra, you may enter its "Program start time" and "minutes" on air... the show's length not the pledge break.




Utility... Import/Export... Import Web Site Pledges: Changed file format "STR" to match the file exported by NPR whose charges are processed by Stripe. The earlier use of "STR" was for pledges exported from PBS TVault which also uses Stripe - that format is now "TVL" for TVault.




Herlick Data Systems has moved its headquarters to Apple Valley, California!

Here's our new address - please provide it to all interested parties in development,

management and your business office - thanks!


Herlick Data Systems

16515 Misanake Road

Apple Valley, CA 92307


HDS also has a new main phone number: 760-946-0636.  

The old Redlands number, 909-798-2898, will forward to the new number.

The HDS toll free number is unchanged: 800-4-MemSys (800-463-6797).




Input... Donors/Pledges/Payments: Sometimes you will know of an updated credit card expiration date, before that information is reflected in the Paya vault record. In that case: While viewing a card pledge, double clicking on "Expires" pops up a panel that compares the pledge's card expiration date with the value stored in the vault. If the pledge has a newer date than the vault, you may click [Update Vault] to store the pledge field in the Paya vault record.




Setup... Skins: Removed the selection of special "skins" (colors and font sizes). They do not play nice with Windows 10 as it has evolved, causing display problems at some sites.




Report... Industry Reports... GP Benchmarks: Upgraded the breakdowns of annual giving by the sum of a donor's payments to accommodate additional high-level giving requested by Greater Public. The top level reported by MemSys used to be "$10,000 or more". As of this update, the new levels are: "$10,000", "$100,000" and "$1M or more".




Input... Donors/Pledges/Payments: (Background)... Sometimes a user, on a case-by-case basis,  wants to reactivate a sustaining pledge whose Status is "W" (written off) and whose Billing Code is "S" (suspended).


First change: The behavior changed by this update reacted to changing Status "W" to any other value as warranting changing Billing Code from "S" to one of the active-plan codes, such as "B" (bill me), "C" (card) or "E" E.F.T.. As of this update, Billing Code is only changed to an active-plan code if Status is changed from "W" to "U" (unfulfilled) or "P" (partially paid). Doing so eliminates the unintended resumption of card auths and EFT debits on a sustaining plan whose Status was changed from "W" to "B" (bad) or "C" (canceled).


Second change: When user changes pledge Status from "W" to "U" or "P", display a query message which asks user to confirm [Yes] or [No] if they want to resume billing the sustaining plan. Clicking [No] leaves Status set to "W" and Billing Code set to "S". Clicking [Yes] accepts the change of Status to "U" or "P" and it changes Billing Code from "S" to "B", "C" or "E" based on other payment method fields.




Utility... Import/Export... Import Web Site Pledges (format "NPR"): Web pledge csv files exported from Springboard provide two opt-in fields: 48 NEWSLETTER_OPT_IN and 87 EMAIL_OPT_IN. Field 87 was overriding 48, so that 48 had no effect on Donor Email_Code1. If field 87 was blank then Email_Code1 defaulted to "Y". As of this update, when reading field 87, also sample field 48 for data. Only move field 87 to the donor's Email_Code1 if field 48 is blank. That way, if field 87 is email opt-in "No" then Donor Email Code1 will be set to "N".




Utility... Import/Export... Export Pending Credit Card Charges: Format "15" (Paya): If a Paya pledge owes a payment, but its card expire date has expired... check Paya vault to see if it contains an active expiration date (not yet saved in the pledge). If so, update the pledge's CardExp field and set its SAU_Updated field to "ATH-yymmdd" based on the current date. Note: "Paya Account Updater" would set it to "SAU-yymmdd". This new logic is processed before a pledge is evaluated for expired-card status. When the export starts, if you respond to the expired card option - choosing NOT to attempt expired cards - the new feature could render some expired-card pledges as being active cards - viable charge candidates - increasing total revenue from a given export.




Utility... Import/Export... Import Web Site Pledges:


1. Added a third export manifest file that is for expired cards only. Added a "CardExpired" column to the csv fields, after CardFlag.


2. When upload Paya charges (Format "15"): After selecting charge candidates, if the user responds [No] to the query about whether or not to process Paya charges, (a) skip the "DEC" export file as there cannot be declines If no charges were attempted - only export "ALL" and "EXP" files; (b) Write "NO AUTH ATTEMPT" in the Approval column and blank in Sage_Ref and Sage_Msg columns, (c) DO NOT process charges for the selected pledges. The [No] response means the export is a trial run.




Help - Remote Connection: The service used by Herlick Data Systems for remote support sessions has changed. We now use SplashtopSOS. To install it on your desktop, please browse to: https://sos.splashtop.com and download the connection program. From the Help menu, choose "Remote Connection" to open the pin code panel, while on the phone with a support technician. Read out the 9-digit connection pin.




Utility... Import/Export... Import Web Site Pledges: Added new file format "STR" (payments processed by Stripe). This file format is supported by PBS Digital and its field set is designed for exports from TVault. The import searches for an existing Pledge record in MemSys by "Customer ID" - one of the fields in the TVault export file. If a pledge is found, the Tvault record will be saved as a recurring payment on that pledge. If no Pledge record is found, the import will create a pledge and credit the first payment. When the import creates a Pledge, it captures "Customer ID" in the EftPlg# field, allowing subsequent imports to add more recurring payments. Click here to view a list of the TVault fields.




Input... Donors/Pledges/Payments: Entering a gift subscriber or gift member card recipient has always been done by entering the recipient's Account number. The idea is to create or find the gift recipient's account first, so it is known when entering the donor's Pledge. Gift subscribers are identified by Gift Type "G", and Gift Member Card recipient's are identified by Gift Type "M".


There are two new features involving gift recipients:


1. There is a new feature involving what happens in the gift recipient's Account on posting the pledge's first payment: The recipient's Donor.Renew field will be set to the anniversary of the payment's Date_Posted, and their Joined field will be set (if it is initially 0) to the YrMo value of Payment.Date_Posted.


2. For a pledge that is a sustaining plan: There is a new "Ren. Ask" code of "A" that impacts gift subscriptions and gift member cards when posting a payment that Auto-Renews the plan: Information about the gift subscriber or gift member card recipient will be cloned into the new pledge, and the gift Account's Renew field will be set to the anniversary of Payment.Date_Posted. If you want there to be a perpetual renewal of the gift account, set "Ren. Ask" to "A"; otherwise, if not, set it to another code.




Utility... Import/Export... Paya Account Updater: This only effects organizations that use Paya as their card payment processor for MemSys payments, and that are subscribed to the Updater service. Prior to this date, the Updater import could update pledges with a change of card expiration date and/or the card's last four digits. As of this version, it can also update the card type and Pledge.Method, if the card type (card number's first digit) has changed.




Mailing... Individual Receipts: On the [Output Options] tab page, added a new one labeled "Member card options".

There are three options:


1 "Donor cards, no gifts" -- The default value, and the way Individual Receipts behaved until now - one payment = one record output, addressed to the paying donor, even if the pledge also has a gift card recipient.


2 "Donor/Gift cards (both)" -- For a payment on a pledge that has gift card data (Gift type "M") on donor screen's Pledge - [Gift-To] tab page, two records will be output, one for the paying donor, and another for the gift card recipient.


3 "Gift cards, no donor cards" -- For a payment on a pledge that has NO gift card information, that record will be excluded, even if it meets the other selection criteria. For a payment whose pledge does have a gift member card recipient, one record is output for that member card recipient.




"Active Forever" Renew YrMo value "202912" extended to "208912" -- As we roll into a new decade, it's notable that the year is now 2020!  We'll be nudging our way closer to 2029, perhaps faster than we'd like to admit!  Because the value 202912 in the Donor.Renew field was intended to mean "active forever", it's time to adjust the database to change "202912" to "208912". Doing so pushes "active forever" 60 years farther out. We've noted that at some stations, groups of donors have been assigned other "active forever" Renew field values that start with 2029, e.g. 202901 or 202902, for reasons of special segmentation. None of those special Renew values have been adjusted. Only 202912 has been advanced to 208912, because it is the Renew YrMo value that HDS has identified as meaning "active forever".  Any instance of 202912 in a donor or fund record has been changed to 208912. If you have any query scripts that apply "202912" as a selection filter, we recommend editing those queries to change the filter to "208912". Mailings and Reports that filter on a Renew YrMo range ending with 202912 have already been adjusted to end at 208912.




Input... Donors/Pledges/Payments: On the "Giving History" tab pages, widened the forms that display dollar totals, so they can display six-digit amounts. Previously, some of the display forms for dollar amounts would truncate six-digit amounts. The previous truncation was especially noticeable on the tabs for "Key Gifts" and "High, Last". Now all of the tabs can display 100,000.00 or more. Note: Dollar signs were dropped, because doing so saves space, and it makes the dollar amounts easier to read.




Utility... Import/Export... Import Web Site Pledges: In prior versions of this program, if the web pledge had an Email address, it would always update the donor's existing email value (if any). Now on the setup panel, there is a new option "How web email should update donor field". In the image below, the first option in the list is "Add email only if donor field blank". The second option, "Always Save as new donor email" would behave as the web import has always done in the past - save the web pledge's email address if any. The third option is to "Never update donor email", which means ignore the web pledge's email field.





Query... Report Writer:  Added a new virtual Pledge field: "Pledge_Pct_Paid". Its value is the percent of Pledge.Amount that has been paid. The formula is: ( (TotPaid / Amount) * 100 ). It could perhaps be used most effectively as a Selection argument. For example "Pledge_pct_paid >= 5" would list pledges for which at least 5% of the pledge amount has been paid. If you also add this selection - "Pstat1 = "H" - and the default percent paid to approve premiums is 5%, it would list pledges with premiums whose status should be "A" (approved), but they are still on Hold for some reason.




Input... Donors/Pledges/Payment: On the "Alt. Addr." tab page, there is a new Action option: "Fulfill Premiums". You may enter such an alternate address record, which is reserved for use as a "ship-to address" when you run "Mailing... Premium Shipments". For a permanent ship-to address, set the range of active months to "1" to "12", with no Until date.

Note: Only "Premium Shipments" knows how to make use of the alternate address table in this way.




Mailing... Individual Receipts: The following mail-merge fields have been added to the existing set of fields output by the "MS Word" format: LTR_DESC6, LTR_DESC7, LTR_DESC8, LTR_DESC9, LTR_DESC10, PREM_DESC6, FAIR_MKT6, PREM_DESC7, FAIR_MKT7, PREM_DESC8, FAIR_MKT8, PREM_DESC9, FAIR_MKT9, PREM_DESC10, FAIR_MKT10, PLEDGE_CODE1, PLEDGE_CODE2, PLEDGE_CODE3, PLEDGE_CODE4, PLEDGE_CODE5, EMAIL_ADDR2.




Report... Industry Reports... GP Benchmarks: One of the payment filters, on the tab page [On-Air / Online Pledges] is "Source types". The entry has been a string of single-characters, each of which is understood to be the first character in Payment.Source codes counted as "On-Air / Online Pledges" (revenue in section 5 of the report). However, some stations adopted the use of Source types consisting of the source code's first two characters. Supporting them as Pledge filters in this report has required an update to recognize a string of one or two-character types.


Now, for example: you may enter "MOPW", to mean that any payment whose source code begins with "M", "O", "P", or "W" is a gift for "On-Air / Online Pledges". As of this update, the alternate entry method will understand that "M,O,P,W,EP" means that any payment whose source code begins with "M", "O", "P", "W" or "EP" is a gift for "On-Air / Online Pledges".




Query... Report Writer: The Donor and Fund tables have picked up some new "Virtual fields". The new fields output Pledge data for the donor's Last Membership Gift. Adding these new virtual fields allows a query of "Donor" as the Main File to drill down into the Pledge table to output specific pledge fields for the Last Membership Gift, including: "Mem_plg_code1" to "Mem_plg_code5", Mem_plg_status, Mem_plg_method, Mem_plg_ibill (Billing code), Mem_plg_isustain ("Y" if pledge is a sustaining plan), Mem_plg_iamt (sustaining plan's recurring amount paid) and Mem_plg_icycle (billing cycle, e.g. M = monthly, Q = quarterly, etc.).


That's nice, but why not just pull the same Pledge fields with a query's Main File set to "Pledge"? Yes, but your export file could list multiple pledges for the same donor. The new virtual fields mean that the main file can be "Donor", so that (a) you only output one record per donor and (b) you are assured that the pledge fields are for the donor's most recent membership gift. That feature is what's new.




MemSys 5.0 - Report... Financials... Installment Plans... Sustainers by Source & Sustainers by Years: This pair of sustainer reports have been added as a new feature in MemSys 5.0. They are similar, except for the base (Year #1) group of sustaining plans. "Sustainers by Source" audits sustaining plans for a specific campaign Source Code as the "Year 1" plans,, followed by subsequent sustaining plans for those donors. The second report, "Sustainers by Years", counts a Year-1 population of sustaining plans that began in a specified 12-month period, followed by subsequent plans for those donors. In "Sustainers by Years", it's recommended to Exclude the source code or source wildcard that would be applied to auto-renewals, so that the Year-1 count is based solely on campaign-oriented source codes.




Input... Donors/Pledges/Payments: This new feature applies to organizations using the MemSys interface with Paya for credit card processing. Sometimes a situation arrises in which you have the Paya GUID for a card that was already swapped in their payment vault, and you want a pledge to assume the use of that vault card. The new feature: Copy/paste a GUID into the pledge Card # field then press the Enter key. It reaches out to Paya to retrieve the vault's masked card number and expiration date. The vault card lookup also updates Method as per the card type.


Note: There is already another entry feature allowing you to clone the GUID and card info from a donor's older pledge into a new one: Identify the pledge number that is already tracking a card that you want the new pledge to inherit. Then, when entering the new pledge, in the Card # field, type in "CARD#####" where "#####" is the older pledge number, then press Enter. Doing so copies all of the card information from the older pledge into the one you are creating. The new pledge now has the GUID, which can be used for card authorizations.




Mailing... Individual Receipts: Added new code filtering on donor Solicitor fields, and added SOLICITOR and SOLICITOR2 to the "MS Word" mail merge export.




Setup... MemSys System File... Business rules... Sustainers: We've added a new feature that has an effect on Pledge.Purpose when creating or auto-renewing) a sustaining plan: This is in support of unusual sustaining plans for special clubs or other giving programs - sustaining plans for purposes other than the donor's annual membership gift. Checking the option "Auto-renew of a purpose "AG" plan continues its use" allows you to create a special purpose sustaining plan with Purpose code "AG", where in subsequent years the auto-renew plans will continue to use Purpose code "AG". Prior to this option, all auto-renewed sustaining plans picked up Purpose code "RE", because sustained giving was assumed to only be for annual membership giving. Now, if the option is checked, an initial sustaining plan for Purpose "AG" will continue to use that purpose code.




Mailing... Pledge Reminders: Added mail merge fields which should help create messaging for requested credit card updates: The new fields have been added to the "MS Word" output format: The new pledge fields are: IBILL (plan billing code), ISUSTAIN ("Y" if a sustainer), DATE_LAST_PMT (date of plan's last successful payment), IDUE_NOW (amount due as of current month), IPAST_DUE (amount past due as of current month), IPMTS_LATE (number of payment cycles the plan is behind).




Input... Donors/Pledges/Payments: Improved the setup of the Payment tab page when loading default fields for the next payment. If the pledge to be paid is a sustaining plan, and the next payment will auto-renew that plan, in some cases the original pledge has been preset with a different payment amount that goes into effect as of the auto-renew. Now the payment tab's Amount field will reflect that change (hopefully an upgrade!). Previously the Next_Iamt" field would be applied to the auto-renew payment, but one didn't see that in advance of saving the payment.




Setup... MemSys System Files... MVAULT: Added a new [Special Offer] button, which when clicked displays this panel...



How it works: Enter one or more source codes, separated by commas, whose paid pledges qualify for the special offer. Enter a "Minimum gift size", which would usually be smaller than the standard Passport qualifying gift. Specify "Gift Type" as being "Membership" or "Member Year Total". Enter a range of qualifying pledge dates. Check "Activate Offer" to put it into effect the next time you run "MVault Startup". When the audit occurs, if the standard conditions do not find a qualifying gift, and "MVault Startup" has the setup of a Special Offer, it will test the donor's paid pledges as per that offer. The offer provides for a fall-back test, a second chance to be activated in MVault or to have the vault record's expiration date extended.




Setup... MemSys System File... Business Rules... Sustainers:  We've added a new option, which updates donors when payments are posted. Check the box "During a recount of a donor's giving history, flag Renew code if they're an active sustainer." If you check the option, it effects what happens when posting a payment to the donor's account: It triggers an audit of their active sustaining plans (if any). If there is an active sustaining plan, the donor's Renew Code field is set to a code that starts with "S" followed by the plan's Billing Code. This is the same update performed for all donors, when you run the recommended monthly audit "Utility... Database Overlays... Update Donor Renew Codes". Checking the new option augments the monthly audit, by coding donors based on subsequent payment activity. The Renew Code field is a popular filtering tool in monthly renewal series mailings. Most users enter the filter as "Exc. (exclude) Renew code S*". Doing so prevents renewal appeals from being sent to donors who are paying by recurring sustainer payments.




Utility... Import/Export... Import Premium Fulfillment Ship Dates: This is the import that uses a Forest Direct API to capture shipping dates. We've added a new feature to the shipping date import: It now captures Forest's "Reference ID", a unique identification number for an individual premium to be shipped. The "Reference ID" can be used when talking to someone at Forest to identify a unique item in their list. The new field has  been added to both [Prem.Hist.] tab pages seen on the donor screen. It appears next to "Tracking#" where it's labeled "Ref ID". The actual field name is Premium.API_Imp_Resp. When displaying a premium that Forest shipped - assuming that the shipping date import has already updated the premium - its "Ref ID" will be set to the unique "Reference ID" assigned by Forest.  


Note: The presence of data in Premium.API_Imp_Resp will prevent "Mailing... Premium Shipments" from exporting a premium - if Output Format is "Forest Direct" - even if it meets all other selection criteria. It's a fail-safe against unintentionally exporting a premium that Forest already shipped. Mind you, one would have to take some deliberate actions for a premium shipped by Forest to be exported again by the mailing program. For example, the premium Status would have to be changed from "S" (shipped) back to "A" (approved). But, even that would not be enough to export the shipped premium again. Now, a user would have to change Status to "A" and remove all data from "Ref ID". These are, of course, NOT recommended actions. They would only be warranted by a delivery failure combined with Forest not being able to reship, using the premium record that they already have.




Utility... Database Overlays... Change a Pledge's Account Number: This is a program that can be used to move a premium, its payments and premiums from one account to another. Using it is limited to operators with Supervisor access rights and who are authorized to open the "Utility... Database Overlays" menu.  The new feature is to record the pledge's prior account number in its Pledge.Notes field, so the change can be double checked anytime later.




Query... Report Writer: For queries based on Donor or Fund as the main table, added two new "virtual fields":


MEM_RES_METHOD Response Method of the donor's last Membership Gift. It comes from the Pledge whose fields are reflected in the earlier "Mem_" fields.
LAST_RES_METHOD Response Method of the donor's last gift for any purpose. It comes from the Pledge whose fields are reflected in the earlier "Last_" fields.


Virtual fields appear in Query after all of the data table fields. Virtual fields are calculated or simply found from data anywhere in MemSys.




Utility... Import/Export... Export Pending Credit Card Charges: Added a warning feature that would appear on starting an export of installments / sustainers. If (A) the range of plan start dates goes back more than 18 months, and (B) user has checked "Catch Up"... The program questions that combination, due to the high amounts that could be charged, especially when an older plan is seriously past due.  The default response is [No] which means: uncheck the "Catch Up" option before selecting records. The [Yes] response means: "Yes, I checked "Catch Up" knowing that older plans that are past due could be charged for a large payment in this run - and that's exactly what I mean to do."




Report... Industry Reports... CPB SABS: The report has been updated to bring it into compliance with new specifications from CPB regarding how to audit sustaining gifts. As of now, the report counts all donors and revenue for sustaining gifts in the revenue source "Other Membership Programs". If you compare a new SABS report with an archived SABS from a prior year, you may see a reduced set of numbers under the primary four revenue sources, and an increase in Other Membership Sources. If so, it would most likely reflect the move of sustaining gifts into "Other Membership Sources". Previously, sustaining gifts were counted along with other types of payments for a donor, in the revenue source based on your source / response method filters.




Utility... Import/Export... Paya Account Updater: Two changes - [1] The entire interface with Paya has been redesigned as per their new specifications and host server. It adds a new layer of data security during the import. [2] The timing of use has changed. The original version of the card update service provided by Paya (formerly Sage) screened cards on the 25th of each month, with the recommended import date being on/after the first day of the following month. But now, Paya screens cards daily, which means the date range one would enter during an import is flexible. The new default dates (inserted automatically as the panel opens) are from yesterday to today - or, on a Monday - from last Friday to today Monday. But you are not limited to those dates  Due to the late receipt of the new specifications, we were unfortunately delayed in publishing the updated import tool. Therefore, we would suggest doing  "catch-up" sessions, to be sure not to miss any Paya updates. Start with 10/25/2018 to 10/31/2018. Import those dates. Then, in one-week segments, work through November and December of 2018, and then January of 2019 until you catch up to the current date. Thereafter, we suggest running the Updater daily or weekly, depending on the timing of your card-auth exports.




Input... Donors/Pledges/Payments: Corrected a condition in which saving a donor whose address had not been changed would log it as a Prior Address anyway. The unwanted behavior has stopped - but in the Alternate Address table some legacy records may be tracking unneeded Prior Addresses. There is a report that will help you discover and de-dupe them.




Input... Donors/Pledges/Payments: There has long been an entry feature on the Pledge - Basic Info tab that allowed a user to "clone" the Paya GUID from one pledge to another, on demand. The only condition has been that both pledges belong to the same account. The legacy method for such cloning involved what one entered at "Card #" on the Basic Info tab page. For example, entering "CARD12345" would instruct MemSys to insert all of the card fields from pledge "12345" including the masked card number, expiration date, Method, and all of the Paya fields including the GUID. That feature still exists - but now it accepts an alternate entry: You may copy/paste the masked card number from pledge A into pledge B, again at the "Card #" entry, and it will clone the older pledge's card fields into pledge B.




Utillity... Import/Export... Import Web Sites Pledges: For some file formats, the final set of manifest fields starting with MKEY_TYPE had an offset in which the data was misaligned with the heading field names. This has been corrected.




Query... Report Writer: In the "Payment" table, added two new virtual fields: Campaign# and Campaign_Desc. It is now possible to select on or export a payment based on the campaign number associated with its Source Code. The new virtual fields are available from the [Fields] tab (to be output) and [Selection] tab (for filtering).




Mailing... Renewal Series: On the Output Options tab page, added a new option "Inst. factor". Its options are "10" and "12". The selected value is divided into the Upgrade Basis to calculate MEM_AMT_INS, the last gift "installment sized". That smaller gift amount is, in turn, used as the basis for looking up suggested installment-sized upgrades using the "RIN" upgrade table. Previously, MEM_AMT_INS was always calculated as being 1/10 of MEM_AMT - now the other choice is 1/12 to calculate a year-round monthly sustainer payment.




Mailing... Individual Receipts: For the output format "MS Word", added five new mail merge fields: LTR_DESC1 through LTR_DESC5. These fields reflect the premium inventory field "Letter Description". It can support a much longer description of a premium, and it is intended for output on forms or mail merge receipt letters. The mail merge file also exports the original, shorter Description fields, giving you a choice.




Input... Donors/Pledges/Payments - [Pledge] - [Acknowledgment / Notes}: The entry label which used to read "Comments.." has been changed to "Pledge Notes" so it matches the tab page label. When one exports the Pledge field is is "notes", not "Comments". Now the donor screen is consistent on that issue.




All Mailings... On the [Output Options] tab page, at "Output Format", if one has not chosen one of the label formats, the screen shadows out and clears the entry "Fields on top of label", because it doesn't apply. Also, if one has not chosen "Form template" the entry for Form template is shadowed out and cleared, because it doesn't apply.




All mailings and reports that provide a [Giving History] tab page providing filtering on a variety of gift types: Two new "Gift Types" have been added to the list: "Single-gift Pledge" and "Sustainer Pledge". Here's an example of how they can be used:



In the example above, the mailing requires that the donor have an active sustaining plan for any amount, whose Pledge.Date is from 01/01/2018 to 09/17/2018t. But in the second row, the donor is excluded if in the same time period they have one or more Single-gift (lump-sum) pledges. Note: Adding the new gift type "Sustainer Pledge" serves the same purpose as excluding setting Donor.Ren_Code to a code starting with "S", by running the database overlay tool "Update donor renew codes".




Report... Major Giving... Payments: This report has undergone a major redesign, allowing it to better inform major giving personnel of actions required as per donor payments. Besides the individual payment qualified by the date and amount range, the report now counts a 12-month payment total which includes the selected payment. Also, and perhaps more helpful, payments are now collated by action groups "A" to "R", with a heading that suggests possible follow-up actions that the MG officer may wish to take, which reflect the realities of each donor's giving. See the payment groups...




Input... Donors/Pledges/Payments: For MemSys organizations that use the Major Giving module, there is a new feature that emails designated staff members and others, when a donor posts a payment. Doing so recounts their giving history, and now, if the total of their payments for the last 12-months meets or exceeds the minimum amount to be treated as a Major Donor, MemSys will send out an email alert describing them and their qualifying payments. The email is to a primary recipient, up to five CC addresses, and up to five BCC addresses. The email is also logged in a table, which can be accessed from a new button on the lower right corner of the donor screen. (How to set up the MG Email Alert System)


Utility... Import/Export... Target Analysis... Export Donor Names: This is of interest to stations that participate in Target Analysis "Donorcentrics". Previously, when a user wanted to create a file of donor names that accompanied their exported payment file, it required using Query. Now there is a dedicated, easy to use program that creates the donor export file. No further need to run a Query.




Report... Financials... Monthly Payment Totals: This is a new report that appears on the "Report... Financials" menu just below "Daily Register". It audits payments in a range based on Date_Posted. The filtering opportunities are very similar to Daily Register. The main difference is that this report only prints payment totals by Months, Quarters or Years. It's the information one sees in Daily Register at the top of the first page of totals. For example, if you run it for the last completed fiscal year, it could break out that year's payment totals for each month of the year, ending with an overall total for the year. To get the same monthly totals out of a Daily Register, for an entire year, you would have to run it 13 times - once for each month, and then again for the entire fiscal year. Note: This report only prints the main totals, it does not do subtotals by source, purpose, method, etc. It does not list payments. For those details, please run Daily Register.


Besides creating a printable report, the program writes a csv file that can be opened in Excel. The output folder and filename are defined automatically. The csv exports are always written to this folder on the server:




The csv filename begins with "Monthly_Payments", "Quarterly_Payments" or "Yearly_Payments", depending on your Time Span selection.




Utillity... Database Overlays... Write Off Pledges: This program has undergone major improvements. It runs faster than before, and it avoids some situations in which, previously, pledges would be report but not actually be marked written off (Status "W"). User choose one of three types of pledges per run. Previously, all three pledge types were processed by the same run.  You should find this a reliable tool to use monthly to (1) write off single-gift pledges in month #7, (2) Installment plans in month #19, and (3) Sustaining plans in month 19, unless they have a recent payment. The latter could happen if the donor gets their card going again after a period of it not working. This was inspired by feedback from the MemSys Users Group Meeting, held July 10, in Chicago, and by Carolyn Jewel, WYPR, Baltimore.




Input... Donors/Pledges/Payments: After finding a sustaining pledge, it is now possible on the pledge's Install tab to (a) enter a monthly payment amount that is different than the current Pledge.Iamt, and then (b) click a new [Upgrade Now] button. Doing so immediately suspends the displayed plan, and then does a forced auto-renewal, setting up a new plan whose Pledge.Iamt reflects the new upgraded monthly amount. Think of this new feature as "Upgrade on Demand". The new plan will take over the processing of sustainer payments, at the changed rate. Previously, such a change in the terms of a sustaining plan required performing all of the steps manually.  This was inspired by feedback from the MemSys Users Group Meeting, held July 10, in Chicago.




Mailing... Pledge Reminders: Added new "MS Word" mail merge field "REMINDER#". The value is based on the "Reminder" number one can enter on the "Output Options" tab page.




MemSys Operator Login: When an operator enters a password to open MemSys, that password is now evaluated in a case-sensitive manner. Previously, although one could create a mixed-case password in "Setup... Operators", the login panel was more forgiving: Before it evaluated the password it converted both the entry and the stored password to UPPERCASE. As a result, it was forgiving of entering letters in a password in the wrong case for an exact match. For example, it would treat "memsys3", "MEMSYS3" and "MemSys3" as all being the same value. That is no longer true.


Due to increasingly stringent PCI regulations, we must now enforce the case-sensitive aspect of matching the password at login with the password stored in the Operator record. After installing this update, if you experience a login failure, please take care to enter each letter of the password with the correct case - exactly as it was entered when it was created using "Setup... Operators". If the stored password is "MemSys3", entering "memsys3" or "MEMSYS3" will not work.




"Input... Donors/Pledges/Payments", "Utility... Import/Export... Export Pending Credit Card Sales", "Export EFT Payments", "Import Credit Card Payments", "Payroll Payments" - (all of the programs that create payments in MemSys):  Until now, if a payment is applied  to a sustaining plan with a balance due, all of that payment would be applied to that pledge and without triggering an Auto-Renewal. Normally, the last payment - the payment that fulfills the sustaining pledge - does not itself trigger an Auto-Renewal. It is the next payment, typically the 13th monthly payment that triggers an Auto-Renewal, because the pledge's BalDue is already zero. Now there's something new involving larger-than-normal "Catch-Up" payments.


Smarter Auto-Renewals:  In MemSys, when saving a payment on a sustaining plan. With the Auto-Renewal feature switched on (recommended), normally one would expect a certain payment (12th if Monthly, 4th if Quarterly) to exactly fulfill the pledge. Doing so means that the next payment in will find that BalDue is already zero and it will be applied to a new pledge record created by the Auto-Renewal process. It was found that some payment anomalies could arise, in which plan "A" was overpaid, while Auto-Renewal pledge "B" had its creation delayed to the next cycle.


The scenario would usually be that plan "A" falls behind due to credit card declines. Then the donor is asked if it's OK to charge enough to catch up. Depending on where the BalDue is, that catch-up payment could pay off plan "A" without doing an auto-renewal (because it has a BalDue when saving the payment). The new feature is the ability of the auto-renew logic to apply a split payment... (A) just enough to fulfill plan "A", which qualifies it for the auto-renewal, perform the auto-renewal, and apply the residual balance the new plan "B". If this new feature posts a split payment it will NOT have a negative impact on daily totals in, for example, "Daily Register". Both payments have the same Date_Posted and, of course, they are both credited to the same Account. When split payments are created, both the old and new pledge record Notes describing how the single payment was split.




Report... Alternate Address Analysis: This is a new report that can identify and fix anomalies in the Alternate Address (AltAddr) table. The report only lists a donor if they have one or more AltAddr records. It can be further limited to accounts with (A) more than one Action "Prior" record for the same address or (B) that match the donor record's address. It can also be told to report only accounts with so-called "perpetual" AltAddr records, whose range of Months span 12 months, i.e. they are always in effect.




Query - main file Pledge: Added a new "Virtual Field" named "Any_prog_pref": It contains the combination of ProgPref1, ProgPref2 and ProgPref3. They are the "Program Preference" codes on can entered in a pledge on the "Gift to" tab page.  The purpose of the new virtual field is to make it easier to select records by a preference code which may be in any of the three ProgPref# fields.




Throughout MemSys and its Help documents: Sage Payments has been acquired by Paya. There is no change to how cards are swapped for GUIDs or how charges are authorized. It is just a corporate name change. But because client emails from them will no longer be coming from Paya.com instead of SagePayments.com, and Virtual Terminal is being rebranded for Paya, we felt it was important to refer to them as Paya in MemSys, for consistency.




"Input... Donors/Pledges/Payments" and "Utility... Import/Export... MVault Startup": The upload of donor Email_Addr1 will now occur only when MemSys is creating a record in MVault. If there is an update of an existing record, the MVault's "email" field will remain unchanged. Previously, every update transmitted the donor record's current Email_Addr1 value to the vault. Now the donor's MVault record can only have its email address changed online by the donor, once a vault record exists.




Utility... Import/Export... Import Web Site Pledges: This same CardExp format test described below at 03-13-18 has been added to "Import Web Site Pledges". Doing so assures that credit card expiration dates are always saved in MM/YY format even if the format online is different.




Report... Pledge... Pledge List: This report now recognizes a unique Description one can enter, telling it to perform data quality checks on Paya (formerly Sage Payments) pledge fields. The Description to be entered is "SAGE INFO REPAIR". One of its abilities is to pull the card expire date from the Paya vault and subject it to a format test. The test looks for month and year values that appear to be reversed. In the pledge record, the CardExp field expects to track "MM/YY" - but some web pledge imports have been known to capture it as YY/MM. The test assumes that whichever piece of CardExp (MM or YY) that contains a number greater than "12" must be the YY element. Based on that, the data may be flipped so that CardExp is stored in MM/YY format. If a change is made, the report also updates the vault date.




Report... Financials... Compare Fiscal years; Report... Pledge... Compare Fiscal Years (pledges): Both reports have always printed dollar comparisons on page 1. Now we have added a second page, which compares the same periods by payment or pledge counts.




Added the ability - implemented on request by a station - to track changes to a Donor or the posting of a pledge or Payment. Use the table tracking those daily changes to export and upload them to a third-party online database or email broadcasting service. The idea is to front load donors and their giving history in the online database, in order to use its trigger algorithms to send email fund raising appeals or announcements. The first implementation of this daily upload is for an email marketing firm called Iterable, in San Francisco. Others may follow.




Report... Renewals... Income Projections: Fixed some data accrual issues, and now it outputs a clean report.




Mailing... Major Giving... Major Donor Segments: Late in the "MS Word" mail merge export, the field names in row#1 got out of sync, by one field, with the actual data fields. This has been fixed.




Mailing... (all programs): Work has been done to preserve special (foreign) characters as they were entered into donor name or address fields. As of this writing, the special characters are preserved in mail merge files exported by the mailing programs, but they are not printed well in the various direct-to-printed label formats. As long as the final output is done in MS Word, e.g. doing a marge-print of Avery 5160 laser labels, that reads the "MS Word" export from MemSys, labels will reproduce the special characters. So, for labels, that is the workaround. The term "special characters" refers to mostly European versions of the alphabet (mostly vowels) - characters such as: à, á, â, ã, ä, å, æ, ç, è, é, ê, ë, ì, í, î, ï, ð, ñ, ò, ó, ô, õ, ö, ø, ù, ú, û, ü, ý, þ, ÿ.




Input... Donors/Pledges/Payments: When editing a sustaining pledge paid by EFT, if one clicks on the Install tab, revealing the masked TRN / Account entries: Double click on either TRN or Acct# to pop up an information box, which can copy both fields (decrypted) to the Clipboard. You may then paste the TRN and Acct# into a new EFT pledge. The scenario would usually be when it is necessary to cancel one pledge and create a new one, e.g. for an upgrade mid-year. It can also come up when one wants to convert a card-based sustaining plan to EFT, although in that case we still recommend suspending the card plan and creating a new plan based on EFT. Sometimes a donor will have their EFT data in an older pledge. This feature can be used to tap that EFT information for use in a new pledge.




Report... Financials... Income Analysis... Income Performance by Years: This report audits payment income for two succeeding years. The report calculates annual totals and many other data points.




Utility...Database Overlays... Change a payment's Pledge Number:  Available to the system administrator - enter a payment number for a payment record that is attached to the wrong pledge. Then enter the new pledge number, which must be for a pledge in the same account.  On changing the payment's pledge number, it also recounts all of the account's pledges to adjust TotPaid and BalDue.




Report... Financials... Daily Register:  Made some changes to the progress monitor that should allow the report to run faster than in the past. Instead of updating the display with every payment, it will either be every 5th or 10th payment, depending on the date range. User will still see payments advance by date, just not at every record."




Report... Financials... Geographic... Cities: New report counts payments and donors by Cities and States, for payments in a specified range of payment dates posted and dollar amounts. The report filters on payment Fund numbers, donor Type codes and donor Mail codes. Options are provided to output a printable report or CSV Format, that latter intended for output to a File. The program exports the csv file for Cities to the path\filename entered on the Output Selector. It also writes a csv file for States, appending "_States" to the "city" filename. Both files are written to the folder chosen on the Output Selector. For example, if one enters "C:\MyReports\Payments_by_Cities.csv" on the Output Selector, as the primary output File (results by Cities), the report will also create "C:\MyReports\Payments_by_Cities_States.csv" (results by States). Either ".csv" file can be opened in Excel or used as a data source in mapping software.




Report... Financials... Geographic... Zip codes: New report counts payments and donors by zip codes, for payments in a range of dates posted and dollar amounts, said payments being for donors who are in a specified range of zip codes. The report filters on payment Fund numbers, donor Type and donor Mail codes. Options are provided to output a printable report or CSV Format for output to a File. In an early test, the csv file was used with ARCGIS from esri to generate a color coded area map, based on data in the csv file.




Query - Report writer: Added five new virtual fields in the Contact table - Move_Date, Move_Type, Move_Priority, Move_By and Move_Subject. For these fields to contain any data, the system must be using the Major Giving module, and the Contact record must be part of a group that are associated with a "Move". The term "Move" refers to a development activity such as cultivating a major gift, a bequest, etc.




Utility... Import/Export... Import Credit Card Sales:  Added new file format "AUP" to update pledge card fields. Reads a CSV file consisting of: Pledge#,CardNum (Masked), CardExp (MM/YY)  No payment is posted.  This format is limited to updating a pledge's visible (non-sensitive) masked card information.




All MemSys entry panels and reports: Every reference to "Lump-sum gift" has been changed to "Single-gift", to more closely align MemSys terminology with industry vocabulary. This is strictly a cosmetic change to text labels; it changes nothing in how such gifts are identified and counted.




Utility... Import/Export... Export Pending Credit Card Charges: [1] Added a tab page filter on Pledge.Cardflag, permitting one to restrict an export to one or more values such as "PS". An older selection option - the check box labeled "Bill PS Again?" is not the same thing, since it has to be checked to include any pledges whose Card flag field is set to "PS", but that would be in addition to other pledges. The ability to e.g. Include only Card flag value "PS" provides a way to only attempt authorizations on cards whose prior attempt was declined.  [2] Added a tab page filter on External list, permitting one to limit a card authorization export to pledges that were imported from a specific outside list, usually a web pledge form hosted by an outside service, such as "NPR" for pledges from Springboard, or "WEB" for pledges from WebSys.




"Report... Financials... Compare Fiscal Years" and "Report... Pledge... Compare Fiscal Years (Pledge)": Added filtering on donor Solicitor codes. Note: Despite their titles, these reports can compare any pair of 12 month periods - any two adjoining years. They are not limited to fiscal years.




Utility... Import/Export... Export EFT Payments: Added filtering on Pledge.ExtList codes. These codes are set by "Import Web Site Pledges" to flag sustaining plans with the web pledge file format. It can be used to export EFT debits separately based on the source of the pledges.




Donor screen, and all imports that can add or edit an address: Added a new zip code validation that watches for numeric zip codes whose length is less than five digits. In that case, if Donor.State is one of 11 for which USPS has zip codes beginning with zeroes, the validation assumes that a zip code is shorter than five digits due to missing leading zeroes. The zip code damage usually happens when one opens and edits a csv file in Excel, causing it to lose leading zeroes in New England and Puerto Rica zip codes. The file is saved that way and then imported.


Note: Excel seems to lose leading zeroes only in zip codes that do not have an extension. For example, when you open a donor/pledge import file in Excel, zip code "00123" will be reformatted as "123" while "00123-5252" will not be changed. That is why the new zip code repair only acts on zips shorter than five digits. The 11 states/territories with zip codes that have leading zeroes include: AE, CT, MA, ME, NH, NJ, NY, PR, RI, VI, VT.




Utility... Import/Export... Export Pending Credit Card Charges: added a new check box option "List donor Level/VIP/Major/MD-Status if declined". If your organization does not use the Major Giving module, the option reads "List donor Level/VIP/Major if declined". If the option is checked, when the export report lists a decline it will list donor fields: Level, VIP, Major and MD_Status (the latter if one uses the MG module). Only fields containing data will be listed. The intent of this addition is to help identify card declines involving high-level donors who should be contacted by someone who specializes in major donor relations.




Utility... Database overlays... Geographic... Zipcode to Donor: This new data overlay tool scans donors in a range of zip codes. User checks whether to copy COUNTY from the master zip code table and/or STATE. If all zip code records have correct State and County data, one may use this tool to assure that Donor records also reflect the correct values of County and State for the donor's zip code.


Note: If you think that your zip code master table does not include a record for every U.S. zip code found in donor records, HDS can assist you with a statewide data overlay, for a set of states that you request. Send an Email to support@memsys.com to inquire.




Utility... Import/Export... Export Pending Credit Card Sales: Restored the ability of authorization exports for Sage Payments to log results in comma-delimited files. For a time those log files were not being exported as we began to add error logging to reports, mailings and exports. Now they are being exported again. Sage authorization log files are written to the folder: \\<your_servername>\<your_sharename>\MemSys\Data\REPORTS\CardAuth_Sage.




Utility... Import/Export... Import Web Site Pledges: WebSys pledges can now print an import manifest to a csv file.




Utility... Import/Export... MVault Startup: (for PBS stations) Added a new column for the "Last Date Paid". This was added because the entered date range searches the Fund table on Date_Last_Paid, while it tests dollars paid referencing Mem_Plg_Amt (amount of last membership gift) or Mem_Yr_Amt (member year total). There was already a column in the list based on Mem_Plg_Date (date of last membership gift). But because the search validates Date_Last_Paid as being within the specified date range, it was not always obvious that the listed records were consistent with the date range. The search for Passport-qualified records is done by Date_Last_Paid, in case a donor's mid-year additional gift raises their member year total to meet the minimum qualified for Passport streaming. The new column does not mean there was a change to how MVault Startup selects qualified records. The new column just makes it clear why the Fund record is within the specified date range.




Input... Donors/Pledges/Payments: Moved the entry for Donor.Solicitor2 from the "Personal" information tab page to the main panel, in the column of donor code fields on the right side. Both fields - Solicitor and Solicitor2 track codes identifying personnel authorized to solicit major gifts from the donor. The two fields share the same code table, however, just like Major and Major2, each donor field can track a different code.




Setup... Major Giving... Major Giving System File: Expanded the number of operator I.D's authorized to use the tools in the Major Giving module. including: One additional admin-level operator, ten additional non-admin operators, and five more operators who may view/create pledges and payments for major donors, but not access the MG menus and tab pages providing access to confidential MG information.




Error Logging - by all reports and mailings: For brevity, this description will use "report" to mean any item on the Mailing or Report menus.  MemSys now logs any errors as a report runs. Error logging replaces the original messaging, in which an error appeared on a pop-up display, waiting for as long as it took for a user to click [OK] to clear it. Now, errors are silently recorded, without pausing the report, in an Error Log table. After completion of a report, to view its error log, open "Help... Error Logs". An error log is recorded, whether or not running a report generates any errors. If you open "Help... Error Logs" immediately after completion of a report, it should already display the Job number for that report. Also, if the report generated any errors, and your Operator record has an email address, the contents of the Error Log job will be emailed to you from "Errors@Memsys.com".


Please note: Silent error logging has NOT been implemented, so far, for data import processes that update MemSys data tables. The reasons behind that is that (a) data imports should never be allowed to run unattended; and (b) it is desirable to immediately see any import errors, which are often evidence of data format or field mapping issues that could save bad data to records in the donor, pledge, payment or premium tables. The immediate error display allows an operator to Cancel the import early.




Mailing... (all seven programs that search Donor as the main file): Added "COUNTY" as the final mail merge field, in formats "MS Word" and "Wordperfect". While a county name would not normally be needed as a field in a letter, it could be useful when the file will be opened in Excel for viewing and analysis. One could sort the list by the COUNTY field. FYI - if you do that, the best sort would be "STATE" as level one, and "COUNTY" as level 2. Some adjoining states have counties of the same name.




Utility... Import/Export... Import Donor Telemarketing Pledges: We have introduced a new "RUF" file format, which refers to Ruffalo Noel Levitz. They can perform multi-purpose outreach in the form of Gift Solicitation, Donor Profile Updates and to flag donors who want to opt out of telemarketing. Any one file downloaded from RuffaloNL can contain a mix of the three types of records to be saved by "Import Donor Telemarketing Pledges". Due to the loss of ComNet for telemarketing, we wanted to provide MemSys sites with a robust alternative service by way of this new import format. The pilot station is WFUV, at Fordham University, Bronx NY.




Report... Pledge... Fulfillment Reports... Pledge Payments by Any Period: This report has long had an option to export selected pledges to a csv file, for review in Excel. Now it also provides a link "CSV File Destination". Click on this link to open the standard destination folder for csv files exported by this report. The standard folder path is <MemSys main folder>\Data\Reports\PledgesByPeriod.


Note: After running this report, you may click on "CSV File Destination" to open the standard export folder. The report always writes new csv files to ".\Data\Reports\PledgesByPeriod", so please do not navigate to a different folder before the reporting, thinking that new csv files will be written there. The link is provided only to make it easy to find and open csv files after running a report.




Utility.. Import/Export... Upload CDP Files: Some sites report trouble uploading files. It was found that the presence of a file "cdp.ppk" in the server's "<MemSysPath>\Data\cdp" folder could cause it to try using that public key - unsuccessfully - for secure SFTP transmission. Our assistance for that situation was to ask the user to rename "cdp.ppk" as anything else, such as old-cdp.ppk". Doing so forced the "Upload CDP Files" program to use generic SFTP credentials that the host site would prefer be used. As of 01-20-17 the export program has been modified to ignore "cdp.ppk" as a public key file, and instead to only use the generic credentials.




Mailing... Tax Receipts: Added the ability to filter selections on donor fields .Ren_Code and Email_Code1. Now it will be possible to run year end tax statements for two Ren_Code segments: (a) active sustaining donors, (b) everyone else; and you can create two lists: (a) gets an email, (b) gets a printed statement. In Mailing... Tax Statements, context help for the code filter tab pages provides more information on how to implement such segmentation.




Utility... Backup Data Tables: It is now possible to set up this backup tool to be launched as a scheduled task on the file server. The utility run from MemSys can only be run on demand. On the file server the command line would be:


(64-bit server)


"C:\Program files (x86)\HDS\MemSys\Programs\MemSys_Backup.exe" \\<server>\<share>\MemSys\<datapath> SILENT <password> <target-folder>\MemSys_Data_WEEKDAY.zip


(32-bit server)


"C:\Program files\HDS\MemSys\Programs\MemSys_Backup.exe" \\<server>\<share>\MemSys\<datapath> SILENT <password> <target-folder>\MemSys_Data_WEEKDAY.zip


Memsys_Backup will replace "WEEKDAY" with a 3-character abbreviation for the current weekday.




Mailing... Additional Gifts, Lapsed/Rejoins, Renewal Series: Added new YEARS mail merge field. It's the same count as the Years field seen on the donor screen. Years tracks a count of annual membership gifts (paid/paying pledges), whose Purpose code starts with "N" (new member), "L" (lapsed-rejoin), or "R" (renewal). For first-year donors the YEARS mail merge field will be set to "1". For multi-year donors the field will be set to "2" or greater. The higher the value of YEARS, especially for active donors, indicates their level of loyalty and longevity.


NOTE: If you filter the mailing on a Fund number, the new mail merge field will reflect Fund.Years for the fund record matching the filter. If no Fund number is entered as a filter, the YEARS merge field will be based on Donor.Years, reflecting gifts for all fund numbers.




Adjusted how MemSys ages sustaining plans. This effects how pledge fields: IDUE_NOW, IPAST_DUE and IPMTS_LATE are calculated. They will now age in a manner that reflects the full amount due now and any amount past due, so e.g. as viewed on the donor screen, a pledge's Install fields will reflect the true financial condition of that plan as of the current month. This is helpful, especially if a plan has fallen behind due to declined card authorizations or rejected E.F.T. debits. NOTE: This revised plan aging method does NOT change how sustaining plans are billed. Two outbound exports are still set to charge or debit only the standard installment - the amount a donor agreed to pay per month, quarter, etc. "Export Pending Credit Card Charges" and "Export E.F.T. Payments" bill sustaining plans only PLG.IAMT - the standard installment. However, reports such as "Install Plan Listings", "Current vs. Past Due" and "Monthly Cashflow" account for sustaining plans as they are truly aged, including any past-due amount.


Mailing... Installments: Added new mail merge field: DATE_LAST_PMT, which is the date of an installment or sustaining plan's last successful payment.




Report... Pledge... Pledge List:  Improved the underlying filtering when a user checks the option "Limit report to donors with multiple open pledges". The report originally regarded as "open" any pledge with a positive amount in Pledge.BalDue (Balance Due).


Now, for Single-gifts and non-sustaining install plans: The report regards a pledge as being "open" if all of these conditions are true:

  1. it has a positive BalDue amount

  2. its Status is not B, C or W

  3. its Ibill is not "S" (suspended install plan)

Now, for sustaining plans: The report regards a pledge as being "open" if all of these conditions are true:

  1. its Ibill is not "S"

  2. its Status is not B, C or W

Note: Sustaining plans are regarded as "open", even if their BalDue is zero, which is true for a plan whose next payment will trigger an auto-renew.


11-21-16 (ongoing project):


Complete review of all MemSys view panels with an eye toward entry form size, alignments within the view panel; assuring that code entry forms are large enough to rarely truncate long codes, and other considerations involving polishing visual consistency. This work is being performed by our newest programmer, Randy Bruck (randy@memsys.com).




Utility... Import/Export... Import Web Site Pledges - format "NPR": The original specifications from NPR Digital called for the import of records of status "Payment Received" or "Bill Me Later". This import has been expanded to also capture and correctly report records whose status is "Partially Refunded", "Refunded" and "Canceled". If a pledge and its first or only payment are partially or fully refunded on the same day the pledge is created in Springboard, the original payment and the subsequent refund will both have the same status, that is, there may never be a record whose status is "Payment Received". The import recognized that condition and creates the pledge and its payment just as if its status was "Payment Received". The subsequent transaction for the same Order_ID, which  will have a negative Donation Amount, will post as a "progress payment" in the same pledge and be applied as a partial or total reversal payment.  If the Springboard record's status is "Canceled", it will expect to find an existing pledge in MemSys and change its Billing Code (Pledge.Ibill field) to "S" for suspended, its Why suspended (Pledge.Isuspend field) to "C" for canceled, and its Pledge.Status field to "W", meaning a write-off. These actions only apply to web pledges imported from Springboard, using file format "NPR".




Input... Donors/Pledges/Payments: Added a new entry trick at the Pledge - Install tab page. When setting up a new pledge paid by electronic fund transfers, if the same account has an older EFT pledge, it is now possible to copy its EFT fields to the new pledge. Confirm the Pledge# of the old pledge. Start entering the new pledge. On the Install tab page when the cursor reaches "Transit routing number", type in "EFTxxxxxx" - where "xxxxxx" is the older record's Pledge#. - then press the Enter key. Doing so will copy in both the masked and encrypted version of the EFT fields from pledge "xxxxxx" to the pledge being entered currently.


FYI - that same cloning feature is already available for credit card information. Same method as above, but at "Card #" enter "CARDxxxxxx" in the old pledge, to clone pledge "xxxxxx"'s card information into the pledge being entered currently. The cloning includes a Sage GUID if one exists in the old pledge.


Help... Help F1: In "Contents... Video Tutorials": Added Webinar 06: Query Basics. This is a good primer for anyone new to the use of Query... Report Writer. It would also be helpful for long-term users who may have seldom or never run a Query. This recording does not cover advaced features such as Expression Fields or Selectikon Expfressions. That will be included in a separate webinar video. The live webinar series will get back in business in early 2017.




Utility... Import/Export... Import Web Site Pledges (Springboard pledges imported using format "NPR"): We made an adjustment to the program, when importing a record of Status "Refunded" or "Partially Refunded". In the original samples, even for credits the Donation field contained a positive amount. We added special handling to reverse the amount to save a negative amount - a reversal payment. It appears now that credits and other refunds export the Donation field already set to a negative amount. This build watches for a negative Donation amount, leaving it unchanged. Only a positive Donation amount in a "Refunded" or "Partially Refunded" record will be reversed.




Toolbox: The MemSys Toolbox is not inside MemSys. It is a separate application a user can run if they know how to log in as operator "SYS". The new feature is a program to "Delete Activities". It can search for them by Date and Source. On starting the process it counts matching Activity records, reporting that count for the user. It then asks for confirmation to delete that group of Activity records.




Setup... MemSys System File... Business Rules... Sustainers: Added a new check box option whose checked value means "Auto-renew sets donor Renew YrMo to a year from payment date". When an update adds this option, it leaves it unchecked so that auto-renew advanced donor Renew YrMo as it has in the past - add one year to its existing value. Setting it to a year from the payment date is more conservative and it calibrates Renew to be when the new plan is itself likely to auto-renew.




Utility... Import/Export... "Import Web Site Pledges" and "Import Donor Telemarketing Pledges": If the import is creating a new sustaining plan, and the Purpose code would be calculated as "AG" based on the donor Renew YrMo, do not allow that to happen, changing Purpose to "RE". The logic behind this is that all sustaining plans are by their very nature "sustained, open-ended annual giving". That cannot be true AND the same pledge is just a mid-year Additional Gift. What is it in the middle of, if the plan IS the donor's annual gift?




Custom... Import Lockbox Payments: - For most sites has been moved to - Utility... Import/Export.




Report… Pledge… Fulfillment reports… Pledge Payments for Any Period: This audit report has been available for years to calculate balances due as of any date in arrears. It’s most common use is to quantify unpaid balances to be written off as of a date in arrears. One of its more recent additions has been an option to export pledges to a csv file. If the box is checked, the report exports selected pledges to a csv file intended for review using Excel. The csv file is always exported to the ..\Data\Reports” folder on your server. The new fields appended to those pledges include:

  1. Pledge.Ibill (plan’s Billing code)

  2. Pledge.Method (payment method)

  3. Pledge.Isustain (“Y” for a sustainer)

  4. Pledge.Date_1st_Pmt (date posted, pledge’s first payment)

  5. Pledge.Date_Last_Pmt (date posted, pledge’s last payment)

  6. Mos_Since_Pledged (calculated as the number of months from Pledge.Date to the Pledges “to” date in the report)

  7. Mos_Since_Last_Pmt (calculated as the number of months from Pledge.Date_Last_Pmt to the Pledges “to” date in the report)

  8. Pledge.Ipmts_Late (as the plan is aged, to the Pledges “to” date in the report)

The csv record begins with Pledge#, Account, Name, Pledge Date, Pledge Amount, Total Paid, Balance Due and Deferred Balance, followed by the new fields listed above. It is intended to help the reader make decisions about what pledges to write off and the unpaid balances, perhaps for different months based on aging the pledges. The new fields help one accomplish that, working in arrears.




Utility… Import/Export… Import Web Site Pledges: The latest file format to be added is “PBS” which assumes it is importing pledges and their payments generated by the PBS Gift Portal. It is an optional pledge form hosted by PBS for a station account. It is tied to the station’s Passport account and MVault. There has been a technical issue in one of the fields that PBS exports, which has prevented pledge imports. While PBS works on a fix, we’ve added a new program just for use by PBS stations wanting to import gift portal pledges. It is “Fix PBS Gift Portal csv file”. It repairs the “Status” field so the records can be imported.




WebSys: Added the ability to design an online pledge form that accepts a donor’s EFT bank information, and permission to process recurring debits, so that during the import, the pledge record is fully set up for EFT processing.




Donors/Pledges/Payments, Export Pending Credit Card Charges, Import Web Site Pledges and Import Donor Telemarketing Pledges: Every tool in MemSys that can swap a card number for a Sage GUID or process a vault bankcard sale, void or credit has had its Internet processing made more robust regarding the handling of a “Soap Fault Error”. While the additions cannot make a network connection that is prone to dropped data packets more reliable, they do upgrade MemSys fail-safe methods to deal with the issue of lost return data.




Mailing… Installments: It is now possible to leave “Billing Code” blank to select all billing codes. Doing so is subject to confirmation as the job starts to make sure the blank value was not accidental. While it would not be normal to ignore Billing Code when generating installment invoices, it would be useful for other types of mailings sent to all types of installment/sustaining plans..




Help… Error Logs: Added view panel to check error logs created by processes that log errors as they run. As of now four processes log their runtime errors:

  1. Input… Donors/Pledges/Payments… Options & Tasks… Recount Donor Totals

  2. Report… Segmentation… Membership Levels

  3. Utility… Import/Export… Upload CDP Files

  4. Utility… Import/Export… Export Pending Credit Card Charges



Report… Financials… Install plans… Sustainer Review: Expanded the ability to filter pledges by up to five Fund numbers. The prior version offered a single Fund entry, so that it could count pledges for a single Fund number or all funds (by leaving the entry blank). Now the Fund numbers filtering appears on the first tab page.




Report… Financials… Daily Register, and all Income Analysis reports: Previously, these reports, which audit payments by Date_Posted, have allowed one to filter on a single Payment.Fund or, by leaving that entry blank, count all Fund numbers. These reports have all been upgraded, to Include or Exclude up to five Fund numbers. It’s the same flexible code filtering commonly found on report tab pages.




Input… Donors/Pledges/Payments: On finding a donor record with an active sustaining plan, append “[SUSTAINER]” to the panel’s main label. The program watches Donor.Ren_Code, and on displaying a record whose Ren_Code field begins with the letter “S” an active sustaining plan is presumed. This assumes that one runs “Utility… Database Overlays… Update Donor Renew Code”, to audit donors, searching for records with an active sustaining plan. Finding one, its Ren_Code field is set to a two-character code beginning with “S” followed by the plan’s Billing Code. And so, the appearance of “[SUSTAINER]” in the donor screen’s main label is as current as the last run of “Update Donor Renew Codes”.




Input… Donors/Pledges/Payments: On the Pledge – Install tab page, added a new field in the “EFT/Sustaining” box: “Permission form”. As the new pledge field is implemented, any existing E.F.T. plans with a transit routing number and bank account number will have “Permission form” checked. Moving forward, as you create new EFT pledges, checking the box will be a user task. If the field is checked it means that the donor returned a permission form stating that you may debit electronic funds transfer payments from their account. The pledge field name is EFT_Permission and it is set to “Y” if the box is checked. It is set to blank if the box is unchecked.


Utility… Import/Export… Export E.F.T. Payments: Added a new checkbox field “Permission form required”. If the box is checked, only pledges whose “EFT_Permission” field is set to “Y” will be exported to the NACHA file (seen as “Permission form” checked, on donor screen’s Install tab page. If the new export option is unchecked, then the EFT export will ignore a pledge EFT_Permission field – meaning that it won’t matter if the pledge field “Permission form” is checked or not. In this way, MemSys gives you the option of treating “Permission form” as an export filter or just a way to note that a donor returned the EFT permission form.




Report… Donor Information… Active Donors: This is the report that resets Donor.DonStat, a field displayed at the top of the donor screen as “Status”. Until now the user would enter a Renew YrMo that is treated as the earliest value a donor can have for Status “A” (active). The prior 12 months were counted as Status “I” (inactive), and all months before that (13 or more months prior to the entry) were counted as Status “L” (lapsed). Now it is possible to stretch or compress the Inactive period. Any value from 0 to 24 may be entered as the “Number of Inactive months”. It is still possible to leave the new entry set to “12” so that Inactive spans one year prior to the start of the Active Renew YrMo. However, entering “15”, for example, would extend the Inactive period to 15 months, delaying the transition to “L” for Lapsed. It is even possible to enter “0” and have no Inactive period. In that case, donors would transition from Status “A” (active) directly to “L” (lapsed).


Note: Donor.DonStat displays on the donor screen – but it plays no role in selections in any mailings or canned reports. It’s only use as a selection filter would be in a Query. DonStat is updated on posting a payment, but otherwise the only change to it is done by running “Active Donors” – it’s the only way to “age” the DonStat field for the entire donor table.


Input… Donors/Pledges/Payments… Mvault… [Dupes]: This is the button one clicks to search MVault – part of the PBS Passport streaming service - for duplicate vault records using the same Email address. The email dupe resolution process will sometimes display an “Error 903” condition, but the dupes are resolved anyway. It can happen when the activated vault record is one created by the PBS Gift Portal. Because the “patch” of that gift portal record succeeds in reassigning it the Donor.Account, we have eliminated the visual error display. It’s a situation – not an error.




Error Logging: We are starting to implement error logging – replacing on-screen error displays – in mailings, reports, and import utilities as they run. The project, as of 07-12-16, has implemented error logging in these programs:

  1. Input… Donors/Pledges/Payments… Options & Tasks… Recount Donor Totals

  2. Report… Segmentation… Membership Levels

  3. Utility… Import/Export… Upload CDP Files

  4. Utility… Import/Export… Export Pending Credit Card Charges

Error logging has begun first with the four processes listed above, because feedback has indicated they take the longest time to run - a fact that sometimes motivates a user to start the process just before leaving for the day. Before error logging, any error during the process would be displayed - waiting forever for someone to click [OK]. In other words, the task would stop and wait until a user to return the next day, when they discovered it had not been completed. As of the 07-12-16 build, errors in the four programs listed above will be logged without interrupting processing.


Where can you find the error logs? They are under the server’s “..\Data\Error_Logs” folder. Open the subfolder for the process that was run, and look for the log whose date and time confirm it was the job you ran. Double click on the filename to open it in Notepad. Besides listing any errors, the task start and end times are noted, as well as the total time required to run it.




Utility… Import/Export… Import Contacts: This is a new import program that can create complete, individualized contact records from information read from a csv file. It differs from the older program “Contacts by Tag File” where the latter read a list of account numbers but it could only save the same contact information in each of the accounts.




Input… Donors/Pledges/Payments: On saving a payment, ask for confirmation if Payment.Date_Posted is prior to Pledge.Date. It would be unusual for a payment to be dated prior to the pledge it is fulfilling. Responding [Yes] proceeds with the save, [No] cancels it to correct Date_Posted or Pledge.Date.


Help… MemSys modules: This NEW menu item displays a list of the MemSys modules that your organization is licensed to use. All checked modules are registered, and they should be available in MemSys. For more information about any of the modules, click the Info link next to each checkbox.




Utility… Import/Export… Import Web Site Pledges: re file format “NPR” for pledges from Springboard: We’ve had a first case of adding a set of custom fields to a station’s import file. It is possible to request additional fields by submitting a request to NPR Support.

This was the advice from Sara Terpeny of NPR Digital Services:


“Stations cannot add new fields to the form on their own, but they can submit a support ticket to us have one added for them:  https://nprsupport.desk.com/customer/portal/emails/new

We ask stations to expect a 2-day turn-around on routine requests like a new field.  We will frequently respond sooner, but sometimes need to prioritize requests depending on what else is going on.”

When you submit a request to NPR Digital, please also open a MemSys support ticket by sending an email to support@memsys.com. Please list the fields to be added. We will consult with you regarding field mapping and valid codes, so the import saves the new information correctly.




Utility… Import/Export… Export Pending Credit Card Charges: In addition to the printable reports, the export of transactions to Sage Payments now also logs them to a pair of csv files. They can be used for audit purposes and outreach for the declines. The files are written to this subfolder on the server: “..Data\Reports\CardAuth_Sage”. File example: “CardAuth_Sage_ALL_2016-06-09_T15:40:25.csv”, where “ALL” means all exported records. Another file includes “DEC” in its name, for Declines only.




Utility… Import/Export… Import Web Site Pledges: Added file format “PBS”, to import pledges and payments from csv files downloaded from the PBS Gift Portal. The import also searches for and lists any duplicate MVault records (matching emails) in the Pledge.Notes field and the long-format report.




Utility… Import/Export… Contacts by Tag File: In the report listing donors for whom the template contact was created, it ends with a sample of the Contact record. The results of “Setup… Contact Template” now provides a source of content to be used in “Contacts by Tag File”. Previously, the program did not have a way to select from a library of saved templates, now it does.




Setup… Contact Templates: Previously seen in “Setup… Major Giving”, this panel has been moved to the main Setup menu. Use this panel to create or edit templates that make it easy to create a set of the same Contact records in many accounts. Its general layout is the same as the donor screen’s Contact tab page. Set as many default field values as needed then save the template.


Utility… Import/Export… Contacts by Tag File: This import utility has been in MemSys for quite some time, but it only supported composing a contact template manually on the setup panel. Now it can load a template created using “Setup… Contact Templates”. After displaying a template, one can modify any of the field values before processing the tag file, with or without saving those changes back to the template.




Utility… Import/Export… MVault Startup: When one uploads updates to MVault, and the process appends records to “postal” mail merge files. Those files now include two new fields: Addressee and Salutation, which appear just after a donor’s last name.




Report… Pledge… Fulfillment reports… Sustainers by Source: This report audits an entered source code as the “initial effort” gathering new sustaining plans. It then counts those plans and all subsequent sustaining plans appearing in the same donor accounts. While most subsequent plans should be auto-renewals stemming from the original plan, the report counts all subsequent plans with any source code other than the initial effort. Doing so means the report will reveal both the expected auto-renewals, and any other sustaining plans triggered by e.g. online giving or call center imports. As such, the report can identify donors who have multiple active sustaining plans. In addition to a summary report, it generates a csv file listing every pledge counted by the audit. The csv file is written to a “Data\Reports” subfolder on the server, under the main MemSys share folder. In other words, you will find the “Reports” folder under “Data”, on the same level as “Query Output”. In the future, when a summary report also writes a csv file, it will be written to “Data\Reports”. So, it could be helpful to create a desktop shortcut to that folder. MemSys support can help you create the shortcut. Just email support@memsys.com.




Setup… MemSys System File… Business Rules… Posting Rules: Added a new check box option to require confirmation before saving a very large Pledge amount. After checking the box labeled “Before saving a Pledge record, confirm entering a large pledge amount.” Enter an “Amount” which is the minimum amount to require confirmation when saving a pledge. This option is intended to intercept a user who may have meant to enter “50.00” but left off the decimal point. Requiring confirmation at “5000.00” or more would provide a check against saving (and possibly charging) a very large amount, in error.


Setup… Operators… Special Features: Added a new check box option to control whether or not an operator is allowed to post Voids and Credits at Sage Payments. If the box is unchecked, they may not post Voids/Credits. There is a separate check box option permitting an operator to save regular credit card payments if they are approved by Sage Payments.




Input… Donors/Pledges/Payments: [MVault] tab page: Added “Member has access” as a prominently display vault field. It will read “YES” or “NO” as a quick confirmation, about whether or not the donor has Passport streaming access. Added an “Access” column to the MVAULT reports.




Help… Update Help Document: This new option allows you to download the most current MemSys help document, without having to install a full update of MemSys. The latest help document displays the Contents item “What’s New” as an online document (this document!). Doing so means that What’s New will be kept current even if you do not update MemSys. As such it will provide a look ahead at what would be added to your MemSys application by installing an update.




Query... Report writer: (for PBS stations using MVault for the Passport streaming service): We've added new virtual Donor fields, who field names begin "MVault". They appear at the end of the "Donor" field list. The field data comes from MVault, via its web API. It is not stored in a MemSys table. So, the information is real time, but the web services access does slow down query's processing. To save time, if possible, if your selections include MVault fields, please enter those Selection arguments last. The query should run faster if a record can be skipped based on a field in the donor table, that is, before it would have to test an MVault field.


Report... MVAULT: This is a new Report menu category. We've added four reports to help stations audit MVault records by these categories: "Activated since", "Last updated since", "Provisional since" and "Deleted since". User enters a value, for the number of "Days ago" at which to start the search. The report lists qualified vault records in a grid; where one can double click on a row to open that record on the donor screen. Note: That feature doesn't work for vault records with a "temp" membership_id, only when the membership_id is the Donor.Account.  There is also an option, in all of the new reports but "Deleted since", which limits the list to vault records using the same Email address. That option make the new reports a useful tool to find and de-dupe "temp" records created by the PBS prospect portal.




Utility... Import/Export... MVault Startup: In the past this audit searched the FUND table on Mem_Plg_Date looking for donors whose last membership gift qualified them to create or update a record in MVault. It has worked fine for most donors. However, if MemSys is configured to qualify members for Passport streaming based on Member Year Total, it may take a mid-year additional gift to raise Mem_Yr_Amt to the minimum amount required. In order to accommodate that possibility, the FUND search has been optimized to search on Last_Date_Paid, allowing it to react to records whose Mem_Yr_Amt qualifies them for Passport as of a mid-year add-gift. This change has no downside for stations that qualify records based on last membership gift, since a paid membership gift also shows up in Last_Date_Paid. This change is simply more inclusive.




Input... Donors/Pledges/Payments: During the entry of a pledge and its premium requests, any of up to five premiums may be sent to different gift recipient accounts. The gift recipient accounts must already exist - either found or created - prior to entering the sponsoring pledge. Please stop entering information about a gift premium recipient on the Gift-To tab page. Please enter gift recipient account numbers only on the "Premium" tab page at the "Gift Acct." fields. Any premium with no "Gift Acct." will be sent to the paying donor. When you create a gift account, please assign Class "7" to that record; but if you find a gift recipient account which is also a paying donor, please do not change their Class code


Note: After saving a pledge with one or more Gift Acct. numbers, you may find the pledge later, click on the Premium tab and double click on "Gift Acct." to display the premium detail tab page. From there, you may click [View] to view the gift recipient account - and then click again on [View] to return to the sponsoring pledge.




Utility... Major Giving... Major Donor Audit/Import: Filter pledges or payments by up to five Fund numbers entered on the setup panel.  Entering one or more Fund numbers overrides the audit's original method of Fund filtering. The original method has been to audit gifts whose Fund numbers match a set in the FUNDMAST table flagged "Y" in the FUNDMAST.MD_AUDIT field. Open "Setup... Campaigns... Fund Master" to review fund validation records and their MD_AUDIT fields, where a checked field is set to "Y". If you enter Fund numbers on the audit's setup panel, those numbers only will be used as filters instead of the "Fund Master" set.




Utility... Import/Export... MVault Startup: The condition that had caused some PBS stations using the "MVOD Services" module to experience at "Out of Memory" error has been resolved. It was happening after uploading about 400 donors to the vault. Once this build - 4.2.1602.1702 - has been installed, the memory error should stop, and you may upload batches of new qualified donors - more than 400 records at a time,and with no need to close and reopen MemSys. Thanks for your patience as we ran down the cause.




Input... Donors/Pledges/Payments and all imports that post payments: When a hard credit pledge is for an amount that differs from the soft credit pledges, some payoffs of the hard credit pledge - which have to calculate a proportionate TotPaid and BalDue ended up with a small residual balance caused by rounding errors. While a soft credit pledge of a different amount than its hard credit pledge carries a balance, the soft credit's TotPaid will continue to be calculated proportionately. But when the hard credit pledge is fulfilled, the soft credit pledge will also always be fulfilled, leaving a zero BalDue.




Query... Report Writer... Donor & Fund tables: added new "Virtual fields" Plg_pmt_cy to Plg_bal_life_sc_new. The fields Plg_pmt_cy to Plg_pmt_cy7x track the sum of payments posted against pledges also created in the specified Calendar years. The fields Plg_amt_fy to Plg_amt_fy7x track the sum of payments posted against pledges also created during the specified Fiscal years. And then similar fields were added whose field names include "sc" - they include any soft credit pledges in the account.


Note: Other legacy fields such as Tot_amt_cy and Tot_amt_fy also count payments by years, but they are not limited to pledges created during the same dates. They just require that Payment.Date_Posted be within the specified year. The difference between Tot_amt_cy and Plg_pmt_cy is that the latter field, the new virtual field, only counts payments in the year associated with pledges that were also created during the same year.




Improvements made to selection options in the following mailing and pledge reports::

  1. Mailing... Pledge Reminders

  2. Report... Pledge... Fulfillment reports... Pledge Payments by Any Period

  3. Report... Pledge... Fulfillment reports... Detailed Totals by Source

  4. Report... Pledge... Fulfillment reports... Pledges by Zip

  5. Report... Pledge... Pledge List

  6. Report... Renewals... New Member Disposition

Here are the changes:


* "Pledges paid by credit card" - added a pop-up entry selector


* "Pledges with premiums" - added a pop-up entry selector


* "Pledge/Plan Types" (formerly "Pledges paid by Install Plan"), two changes: added a pop-up code selector and expanded the options. This change is important, because the all-inclusive entry used to be "I" (Include) and now it is "A" for "All Pledges". If you display a saved script with this option set to "I" (Include) previously, please change it to "A" to mean the same thing.


Here are all of the filtering choices at "Pledge/Plan Types":




Entering "A" will select All Pledges (Single-gift and installment and sustaining plans).

Entering "E" will exclude all installment and sustaining plans (output only Single-gift pledges).

Entering "I" will only select Installment plans (no sustaining plans, no Single-gifts)

Entering "O" will only select a combination of Installment and Sustaining plans (no Single-gifts)

Entering "S", will only select Sustaining plans (no installment plans, no Single-gifts)




Report... Pledge... Compare Fiscal Years (Pledges): This is a new report similar to the report on the Report... Financials menu. But this one audits Pledge record by Pledge.Date.




Query... Report Writer... Donor & Fund tables: added new "Virtual fields" Plg_amt_cy to Plg_amt_life_sc_new. The fields Plg_amt_cy to Plg_amt_cy7x track the sum of Pledge.Amount for all pledges whose Date is in the specified Calendar years. The fields Plg_amt_fy to Plg_amt_fy7x track the sum of Pledge.Amount for all pledges whose Date is in the specified Fiscal years. And then similar fields were added whose field names include "sc" - they include any soft credit pledges in the account.




Report... Segmentation... Membership Levels: Previously, the main report file was Fund, which could count the same donor separately for each qualified fund number. Now the main file is Donor, so that the giving level counts can only count a given donor once, even if gifts for multiple funds are taken into account to rate their level..




Utility... Import/Export... MVault Startup: As per specs from PBS, filter out Canadian zip code. It's a licensing issue.




Report... Major Giving... Contacts: Added option to export information to a csv file, improved filtering options.




Major Giving module - Dashboards: Added filtering the results by Fund number.




Query... Report Writer: Reports to printer or preview that output integer columns such as Account, Pledge# and Renew will no longer use commas a thousands separator. Currency fields accurate to 2 decimals will continue to print the decimal values and commas as thousands separators. The trade-off is that integer fields that are e.g. pledge and payment counts will also output without commas as thousands separators. Because so many queries print out fields such as Account, Pledge# and Renew, we felt it was a good trade-off. Please email support@memsys.com if this change results in any undesirable formatting in your queries. Note: Canned reports have their own formatting controls. This change was just for Query.


Utility... Import/Export... Import Web Site Pledges: Most imports from csv files or from WebSys do not return a Purpose code. And in that case, the import calculates a default Purpose code same was as the donor screen... it refers to the donor's Renew YrMo to calculate NW, AG, RE, or LR. Until now, if the csv file included a Purpose code, that code has been imported as is - without further testing. This has resulted in some sites saving pledges with inappropriate donor-chosen Purpose codes. As a result, the web import has been modified to watch for any imported Purpose codes, and if they begin with N, A, R or L they will be ignored. Doing so will force the import to calculate pledge Purpose based on donor Renew YrMo. Other imported Purpose codes - which do not begin with N, A, R or L - will continue to be saved as is.




Input... Donors/Pledges/Payments... MVault tab: Added the ability to create a new vault record for a donor directly from the tab page, and without an audit requirement. This will allow you to provide Passport subscriptions to volunteers who might not meet the minimum gift requirement. Starting with a blank MVault tab page, you may double click on each of the entries from "First name" to "Expires" to insert a default value, if possible. Please review the context help for the donor screen's MVault tab page for more details. Note: For a volunteer with no membership gift, the double-click action will be to insert today's date as the Start date and its anniversary as the Expires date.


Utility... Import/Export... MVault Startup: In training sessions, the advice has been to select all listed donors by right-clicking anywhere in the list and choosing Select All. Doing so highlights all displayed records in blue - a required action before uploading them to the vault. It's also possible to check the "Select All" box, just to the left of the [Update MVault] button. However, until now, checking the box highlighted the selected rows in brown, which was confusing. It's been fixed - to display them in blue, same as the right-click Select All.




Utility... Import/Export... Import Web Site Pledges:  Added new option: "Check multiple matches?". If the option is checked, and a web pledge's name, address, phone or email fields match two or more donor accounts, user will be shown all matching records. It allows one to choose which account to declare as the match. If the option is unchecked, the import will automatically choose the first match it finds.  Fields shown to user, if they contain data: Name #1, Name #2, Company, Delivery Address, Secondary Address, City, State, Zipcode, Evening Phone, Daytime Phone, Cell Number, Email Address.




Query... Report Writer: Added new virtual fields to the RENACCT table. This is the table that tracks every Renew YrMo that has ever been assigned to a donor, during their lifetime giving. It's the table used by "Report... Renewals... Mailing Analysis" to audit donors who belong to each renewal "universe". Again, that is the set of accounts that had a given Renew YrMo at any time in a the past. Normally, RENACCT serves as an under-the-hood table serving the audit needs of "Mailing Analysis". But now the addition of the new virtual fields allows one to check the current status of donors who were ever assigned a Renew YrMo. The new fields include current Renew YrMo, date and amount of their last membership gift, date and amount of a recent unpaid pledge (well used as a exclusion filter in "Mailing... Renewal Series"). One useful query of RENACCT would be to analyze unexpected results running that mailing. The new fields also include the current value of donor code fields commonly used as filters.




Utility... Import/Export... Upload CDP Files: As the Community Development Partnership expands past it initial market of PBS stations, an increasing number of public radio stations are participating in monthly CDP file uploads. The setup screen now includes a new entry "Station affiliation". Valid entries include "TV" and "RD". For single-membership organizations, only the new entry will be exported as the station affiliation value. At dual-membership organizations, station-specific fund numbers will determine the exported station affiliation values.




Report...Pledge... Fulfillment reports... Pledge Payments by Any Period: added new option "Create CSV file" to export report data to a pair of comma-delimited text files. Checking the option creates the files in addition to output of a printable report. The csv files will always be written to a "REPORTS" subfolder under your file server's MemSys\Data folder. The filenames will be (pledge list) Pledges_by_Period_Pledges_yyyy-mm-dd.csv and (source code totals) Pledges_by_Period _Source_Totals_yyyy-mm-dd.csv, where yyyy-mm-dd is today's date.




Mailing... (all mailing programs that output donor fields): Added "CELL_NUMBER" as a mail merge field. It's now included in these output formats: "MS Word", "WordPerfect" and "Telemarketing".  




Utility... Import/Export... Export E.F.T. Payments:  Added a new check box option "OK to export with no bank TRN/Acct#".  Check this box to export an E.F.T. plan even if the pledge does not contain a full transit routing number and bank account number. Normally, with the option unchecked, such pledges would be filtered out, so that only pledges with complete bank account information would be exported to a NACHA file. The only case in which it would make sense to check this option is (A) the exported NACHA file will not be submitted to a bank or service for debit processing, and (B) you are only running the export to force the program to create payments in MemSys. The assumption, if you check the option, is that a service or your bank is set up to process recurring debits in their system, but that their database cannot export payments to be imported.




Utility... Import/Export... Import Web Site Pledges: Clicking the button [Emails to Ignore] has long supported the entry of a list of bogus email addresses to be ignored during pledge imports. Now, that list also accepts entry of @domain strings, in order to exclude ALL email addresses at the specified domain. The case that prompted the @domain filter involved the use of a back office form managed by Springboard. For example, when no donor email address has been entered, Springboard returns a calculated string, such as "1440430261@sb-offline-donation.com". Springboard requires there to be a unique string in the email address field. But that example is, of course, not a donor's true active email address. By entering a domain string such as "@sb-offline-donation.com" in the "Ignore List", any email address whose domain is "@sb-offline-donation.com" will be ignored, meaning: (a) the email address will not used to search for a donor, (b)  the email address will not be imported as a donor field. Be sure to start the domain entry with the "@" character, followed by the full domain value.




Query... Report Writer: When a query is run for the first time, after opening a query definition file (qdf), its path\filename will print at the end of the report after the totals and selection criteria. The limitation is one report. Running a second report for a setup that originated as a qdf file will omit path\filename. The qdf path\filename only prints when output is to Preview or Printer.




Utility... Import/Export... Target Analysis... Export Payments: At the request of Denise Santoro at Target Analytics, exported payments will now include the pledge's installment frequency code, if the pledge is an installment or sustaining plan.


(1) Mailing... Installments; (2) Utility... Import/Export... Export Pending Credit Card Charges, (3) Export EFT Payments: Previously, when aging a sustaining plan, it could end up with an Amount Past Due greater than the pledge's overall Balance Due. It was a left-over from the days before MemSys would auto-renew a sustaining plan, preventing it from owing more than a year of payments. Aging of a sustaining plan has been modified so that the Amount Past Due cannot exceed a pledge's Balance Due amount.




Mailing... Tag Files: When the mailings starts, it loads up to four tag files of account numbers, merging any repeat instances the same account number. Previously, during that initial loading process, if a file contained an empty row, the loading process would stop at that point. This has been fixed. The loading will continue to the end of each tag file, and it will simply ignore empty rows.




Mailing... Renewal Series and Lapsed/Rejoins: When mail merge field were introduced for the installment value of a donor's last membership gift and six installment sized upgrades, it was based only on 10% of the amount of their last membership gift.  Now, it works from the choice made at "Upgrade Basis". This still allows one to choose "Membership Gift" as the installment/sustainer upgrade basis, but now one could choose "Member Year total" and it would influence the installment-sized upgrade levels.




Report... Major Giving... Contacts: Added option to filter MD contacts by Donor.Fund number. At dual station sites entering the TV fund number applies to the donor fund for TV and for both, entering the radio fund number applied to radio or both.




Major Giving module - Pledge and Payment Dashboards: Added filtering the search list by Fund number. Blank means any fund, or enter a single fund number.




Input... Donors/Pledges/Payments & Utility... Import/Export... Export Pending Credit Card Charges: The donor screen and card export tool are both capable of capturing payments processed by Sage Payments. The recent addition of a web pledge import for Springboard (SB) has found that SB performs an authorize-only transaction when they swap card number for a Sage GUID. The rub is that auth-only looks like a charge on a donor's card statement... and historically, MemSys has done its own authorization-and-capture.


The web import's "NPR" format now maps field 59 - Transaction Reference number  - to a new Pledge field: SP_Trans_Ref. The new field links that pledge back to the Springboard authorization. As a result, when the donor screen or card export captures a payment, it uses SP_Trans_Ref to perform a "Prior Auth Sale". Doing so captures a payment, without a new authorization. The change has two beneficial effects: (a) donor doesn't see what would otherwise look like a dupe charge on their card statement; and (b) the organization saves money by eliminating a second authorization fee.


All legacy Sage payments in MemSys have been done in the manner of a point-of-sale authorization-and-capture. Only the first payment on a Springboard pledge would use "Prior Auth Sale". All of the pledge's subsequent payments will use the original mode: authorize-and-capture.


NOTE: Springboard card pledges must be charged within seven days of SB's authorization for Prior Auth Sale to work! Please do not delay the import of web pledges - and also, don't wait for the regularly scheduled monthly installment run to process first-payment on new plans. If that delay lasts longer than seven days, the "Prior Auth Sale" will fail and the donor may see both authorizations, not realizing that the first one was an auth-only. If a donor's card statement is printed after the SB auth-only expires, it should drop off that statement, but we can't be sure. Some donors view their card statement anytime, online, so it's best to run those "Prior Auth Sales" immediately after the import of Springboard pledges.


There is NO change to payment posting procedures, other than being mindful of the seven-day SB auth-only expiration. MemSys automatically detects a pledge with an unpaid SP_Trans_Ref, and it chooses "Prior Auth Sale" automatically. After that payment has been captured, the pledge is a sustaining plan, all subsequent charges use the original mode of payment capture.




Report... Segmentation... Donors by Zip: There has long been a check box option to "Count donors with gifts". Checking it caused the printable report to print donor counts and average gift for each of the four years reported under "Annual Totals". But it did not effect the format of a csv file for Excel if that option was chosen. Now the set of columns output the csv file has been expanded to include annual donor counts and average gift.




Report... Pledge... Pledge List: If a pledging donor has an email address, print it below their name.




Donor screen and other imports of payments - the sustaining plan auto-renew feature: If a sustaining plan is a hard-credit pledge attached to a soft-credit, and the hard-credit does an auto-renew, it was not updating the soft-credit. That has been fixed. Now the new auto-renewed plan - the new hard-credit pledge - takes over and is attached to the soft-credit pledge, updating its information. Note: The auto-renew updates the original soft-credit pledge record, it does not create a new soft-credit pledge.




Utility... Import/Export... Import Web Site Pledges: [A] Format "NPR" for Springboard: Contents of field 22 (Payment_Method) can now set Pledge.Method to codes other than "CK" or a code based on type of credit card. If the field contains "EFT", set Pledge.Method to "EF" and set plan type and billing code to "E". If field 22 contains "Payroll" set Pledge.Method to "PY" and set plan type  and billing code to "P". [B] The reports have a NOTE column which prints a special flag for new sustaining plans, followed by an add-on tag if the account also has another open pledge which could warrant special attention. The NOTE column had printed a number such as -655, in error. That's been fixed, and the report now ends with a description of all codes that could appear in NOTE. Please use it to identify e.g. donors with duplicate open sustaining plans and other potential issues.




Setup... MemSys System File... Business Rules... Sustainers: After entering an auto-renew source code, on saving your changes: if the code is not already in the Source master file, it will be added automatically with the description: "Sustainer Auto-Renew: <code>".




Utility... Import/Export... Import Web Site Pledges: Format "NPR" (Springboard): We changed the expected field order of the Sage GUID to field 88 and the Remote_ID to 89. Doing so adopts a change made by Springboard. If this applies to your station, please open "Help... About" and check your current build number. Any station using Springboard and Sage Payments should be running MemSys 4.2.1506.1726 or later.




WebSys - added support for the import of additional donor fields: Type, Mail, VIP, Ren_Code (renewal mail preference), Agf_Code (add-gift mail preference), Tmkt (telemarketing preference), Challenge, Survey1 and Survey2. Other fields such as Fund, Source and Res_Method (response method) were already being imported.




Utility... Import/Export... Import NCOA/Standardized Addresses:  Added a new check box option "Close MemSys on completion". If the option is checked, you may run import at the end of the day, unattended, and on its completion MemSys will close. This will allow the import to run into the evening hours but close before the server runs any late-night backup or virus scan. There is no communications between MemSys with third party server tools - this feature is limited to making the computer running the import close MemSys tables immediately after completing the import task.  Note: If the "Report" option is also checked, the final import summary report will be written to a text file on the same folder as the import file. Its filename will be based on the import file but end with "_report" to avoid its having the same filename.




Mailing... Installments: Mail merge files will no longer export full decrypted credit card numbers. This change is in response to PCI security regulations which are growing more strict on a continuous basis. The CARDNUM field will consist only of the masked version seen on the donor screen's Pledge tab page. This limitation is a moot point for sites that vault store credit card numbers and who do not export pending files. If you have depended on the mailing to export full card numbers for payment processing, please send an email to support@memsys.com to discuss options.




Utility... Import/Export... "Export Pending Credit Card Charges" and "Export E.F.T. Payments": After aging the plan (sustaining or non-sustaining) to calculate Pledge.Idue_now... if the remaining balance (Pledge.BalDue) would be less than one installment (Pledge.Iamt), and that amount would be less than $2, add it to Pledge.Idue_now. Doing so will reduce BalDue to zero as of the current payment, fulfilling the pledge. This will adjust for some odd final-payment situations that can otherwise occur.


For example, take the case of a sustaining plan based on an annual commitment of $1000 with monthly payments of $83.33. Payments #1 to #11 would be for $83.33, but (as of this update) payment #12 will be for $83.37 to reduce BalDue to zero. Doing so sets up the sustaining plan to auto-renew as of the next payment. Otherwise, the original plan's resudual $0.04 BalDue would collect another $83.33 payment, applied as payment #13 on that original plan, overpaying it, delaying an auto-renew to the next (14th) payment. This change assures that installment/sustaining plans whose Pledge.Amount is not evenly divisible by Pledge.Iamt are fulfilled with the same timing as plans that "pay off" evenly with a year of payments.




Utility... Import/Export... Sage Account Updater (SAU): There was a recent issue in which the SAU service exported blank expiration dates; that problem was fixed as of April 7, 2015. We've added a fail safe to the import tool, should that problem ever happen again. If the downloaded SAU batch has missing expiration dates, the import will automatically use a different web service to retrieve the expiration date from the Sage vault.




Utility... Import/Export... Import Web Site Pledges: Changed the "ROLL" column to "SUS.". Changed its contents to contain one or more status codes that inform the reader about the imported plan and possibly other open plans in the donor's account. These are the possible codes that can appear in the report:


"SUS." code



Auto-renewed plan, first payment, source matches auto-renew code


New plan, First payment, source does not match auto-renew code


Existing plan to be paid off with one more payment


Existing plan paid off, next will auto-renew if sustainer


Attention required, donor has open Single-gift pledge <= 60 days old


Attention required, donor has 2nd open sustaining plan (any age)


Attention required, donor has open install plan <= 18 mos old




Input... Donors/Pledges/Payments: When finding a donor record that contains data in any of the fields seen on the [Alerts] tab page, place a green check mark next to the tab label. This is similar to the use of green contains-data checks seen on the [Pledge] tab pages. But, on the other row of tabs, starting with [Summary] only [Alerts] is picking up the same feature, due to screen size limitations.


All Dashboards in the Major Giving module: Added columns for donor RFM Score, Type and Mail codes. The records listed on a dashboard can be sorted by or subtotaled on the values in any of the displayed fields.




Query... Report writer: Added a new virtual Donor field: Mem_ag_upgrade. It is the difference between Mem_Yr_Amt and Mem_Plg_Amt. Mem_Yr_Amt would track a positive amount because of one or more additional gifts posted after the last membership gift. For example, if a donor's last membership gift was for 100.00 and they subsequently donated 50.00 and 30.00 additional gifts, Mem_ag_upgrade will return 80.00. The difference between Mem_ag_upgrade (the new field) and Add_Plg_Amt (amount of last additional gift) is that Add_Plg_Amt could be an add-gift from a prior year. Mem_ag_upgrade is only the amount of one or more add-gifts received since the last membership gift. The new field provides a good way to select donors whose current member-year value has upgraded due to one or more recent additional gifts.




Query (main menu): Added a new menu item "Saved Queries", which opens a submenu listing the folders containing saved query definitions. Most of those subfolders will be named to match your computer/network user names. However, one submenu and folder will be "Memsys-Published"; and it will contain special query definitions installed by MemSys Support when we install a MemSys update.


Utility... Import/Export... Sage Account Updater: Changed the default selection date range to a starting date of the 25th of the prior month through today's date.  Changed the import so that it will compare a pledge's existing CardNum (last 4 digits) and CardExp (mm/yy) with the SAU record downloaded from Sage. If they already match, it skips the SAU record and retains the existing value in Pledge.SAU_Updated. This change will make it easier to identify pledges whose card information was changed by the current SAU import. Previously, if the user entered a date range which overlapped two monthly updates, the import would change Pledge.SAU_Updated to reflect the current import date even if the pledge had been updated previously.




Utility... Import/Export... Import/Update Donors: added a new tab page "Information field" where it is possible to enter a template to be saved in the new Donor.Information field. It is a 255 text field that can track information seen on the donor screen's Alerts tab page. The template can include csv fields to be merged into the field. For example, this entry "Type [4], Mail [7]" would merge in fields 4 and 7 from the csv file and save them plus the surrounding descriptive text to Donor.Information.




Report... Financials... Daily Register: Added check box option "List Discrepancies". If the box is checked, the report will list any payments or donors that are missing important (required) data.  The report prints the discrepancy list after the final totals and before the report descriptions. Conditions that can list a payment as a discrepancy: Missing data in these Payment fields: Fund, Source, Res_Method, Method, Purpose; and these Donor fields: Type and Mail.  Other conditions: Pledge or Donor record cannot be found.  Note: If the option is checked, all payments in the date range will be inspected for discrepancies, even if they do not meet all of the selection criteria..




"RFM_SCORE" is a new field added to Donor and Fund tables. Calculated for each donor on creating a payment. The field can also be recalculated for the entire database by running "Recount Donor Totals" at the donor screen [Options & Tasks]. The RFM_SCORE is a number from 0 to 100, where a higher number is a better score. The letters "RFM" refer to a combination of three scores for giving Recency, Frequency and Monetary Value. After installation of a MemSys update on or after 11/09/2014, please run "Recount Donor Totals" for all donors. Doing so will assign every donor their first RFM_SCORE. It will then be visible on the donor screen and it will be available as a selection filter in mailing programs such as Renewal Series, Lapsed/Rejoins and Additional Gifts. More information about RFM_SCORE.




Input... Donors/Pledges/Payments: (if using the Soft Credits module): If user attempts to create a payment in the account of a soft-credit pledge, cancel the save and redirect the screen to the hard-credit account and pledge. Only enter payments applied to a hard-credit pledge pledge, doing so automatically applies it to the soft-credit pledge.




Input... Donors/Pledges/Payments and all payment import tools: If one is not using the sustaining plan auto-renew feature, plans' roll-over source code is now based on the same code entered for global use in "Setup... MemSys System File... Business Rules... Sustainers". The legacy pledge field (Pledge.Iroll_Src) has been retired, and now only the global roll-over source code is used when posting a payment on a sustaining plan that has already fulfilled its first year. HDS recommends activating auto-renew for sustaining plans for the many membership tracking solutions that it brings to donor giving histories.




Input... Donors/Pledges/Payments - An addition to the Pledge - Basic Info tab page: For sites using Sage Payments for card processing: If the pledge's card number and/or expiration date have been changed by Sage Account Updater, and the new information has been imported, a change indicator formatted "SAUyymmdd" will appear to the right of card expiration date. For example, "SAU141026" would mean that the card's expiration date or last four digits (or both) have been updated in the Sage vault, and new information has been imported to the pledge, on 10/26/2014.




Utility... Import/Export... Import donor telemarketing pledges:  Added a check box to the right of the filename entry, labeled "Field names in first row".  Check the box if the pledge import file's first row contains a set of field names - not a pledge. Leave the box unchecked if the first row is an actual pledge record.  Normally, firms such as Tele-Direct do not start their pledge files with a row of field names.




Added new Pledge fields: Idue_Prior, Idue_LastFY, Idue_CurrFY, Idue_NextFY, Paid_Prior, Pair_LastFY, Paid_CurrFY and Pair_NextFY. These new fields track the amount that is/was due as of a fiscal year in the past, the present or next year, and also the amount paid in those same years. The new fields were added to make it easy for a Query of the Pledge table to list and total amounts to be expected this and next fiscal year. That can be useful information if you list only your active sustaining plans.


Loading the new fields for the first time -- If you have just installed a MemSys update whose build is 4.2.1409.1723 or later, and you have not yet done so, please...

  1. Open the donor screen,

  2. Choose [Options & Tasks],

  3. Select "Recount donor totals",

  4. Click [Start],

  5. Choose "All donors starting at account 0":,

  6. Click [Start].  

NOTE: Before starting the audit, you may check the option to close MemSys when it finishes the recount. Doing so means that you can launch the recount then leave, knowing that MemSys will close automatically when it is done. It's recommended, if a backup will start later the same evening.




Mailing... Installments:  The new feature usable, if sustaining plan Auto-Renew is active: This is the mailing program originally created to mail installment reminders to donors who have to be billed. The growing popularity of sustainer programs has prompted the addition of new features. Setting the "Sustaining" filter to "O" (only sustaining plans) now means that when you click [Start Mailing] it will ask "Is this mailing a solicitation for sustaining plan renewal upgrades?".  Answering [Yes] pops up a small entry panel, where you can enter a range of future auto-renew months. The program assumes that a sustaining plan's auto-renew date is the anniversary of its Start Date. For example if a plan's start date is 12/01/2013 then its predicted auto-renew date is 12/01/2014. If the entered Statement Date is 10/15/2014, and you want to send an upgrade appeal to plans due for auto-renewal in October or November, the range would be "1" to "2". This provides some lead time in which to get a response to the upgrade ask.


So.. what to do when someone says they will upgrade from 5.00/month to 10.00/month? We have added a new pledge field for the next installment amount when the plan auto-renews.  The idea is that the existing plan is close to being paid off, and the upgrade will happen during the auto-renew. When that month arrives, the card authorization or EFT export will detect that it should start using the upgraded installment amount. It will charge that amount and apply it to the auto-renewal plan - the new pledge. The trick would be to set that range of auto-renew months close to but not the same as Statement Date. Perhaps a range of "1" to "2" would be ideal, where "1" means the next month after Statement Date. Experiment with the range of months to find the best result.


When a sustaining plan is output, knowing that the mailing is "a solicitation for sustaining plan renewal upgrades", the mail merge record exports six additional fields: UPGRADE1 to UPGRADE6. The values in those fields are selected by: (a) use of Upgrade Table type "RIN" for Renewal Installments, (b) use of Pledge.Iamt to jump into that table at the nearest match on Upgrade.Orig_Amt, (c) export Upgrade1 - Upgrade6. Before you start to use "Mailing... Installments" for sustainer upgrade asks, please open "Setup... Campaigns... Upgrade Levels" and find upgrade table type "RIN - Renewal Series Installments". That is the table used for the suggested upgrades. Please adjust its values to best fit your program.


NOTE: The recommended way to ask donors with sustaining plans to upgrade is to (a) use "Mailing... Installments", and its new features as described above, and to (b) exclude such donors from regular renewal series mailings. The recommended way to exclude sustainers from "Mailing... Renewal Series" is to [1] use "Utility... Database overlays... Update donor renew codes". It saves a code starting with "S" in the Donor.Ren_Code field if they have an active sustaining plan. With that overlay completed first, then [2] in "Mailing... Renewal Series", exclude "Renew code" value "S*" to filter out the donors with active sustaining plans.




Input... Donors/Pledge/Payments: For sites using Sage Payments for credit card authorization: When displaying an existing credit card pledge, if the user double clicks on the Card number field, MemSys will compare the pledge's masked card number and expiration date with data stored in the Sage vault.  If there is a difference, user will see a message showing the difference. It will ask if they want to update the pledge. Doing so is recommended, especially if the Sage vault's expiration date is later than the pledge.  After the question about updating the pledge, MemSys displays the Sage Payments information panel.  If there is no difference between the pledge and vault-stored card information, user will see the Sage information panel immediately,




Utility... Import/Export... Export Pending Credit Card Charges: For format "15" (Sage Payments), added the same payment flags described below on 08-21-14, for authorized Sage payments. Sites that use format "15" use Sage as the payment processor, and they therefore do not use "Import Credit Card Sales".




Utility... Import/Export... Import Credit Card Sales: When importing installments or sustaining plan payments, certain payments will cause a special FLAG to be printed in the import report. The new payment flags include:


NF = Non-sustaining, First payment

NL = Non-sustaining Last payment

SA = Sustaining, Auto-renew

SF = Sustaining, First payment (new)

SL = Sustaining, Last payment (next will auto-renew)


When saving the installment/sustaining payment, if any of the five flags are printed for that payment, it will also be saved in the pledge record's CardFlag field, and in the payment record's Card_Flag field. The flags will make it easier to select certain types of payments or pledges in mailings.


Note: The import report has been redesigned to make room for the new FLAG column on the far right. Where previously the card number column printed a full masked card number, now it prints payment Method followed only by the card's last 4 digits. The report also prints payment counts by the various FLAG values.




Query... Report Writer:  In the "Donor" table, added four new virtual fields: Renew_date, Joined_date, Renew_mos_left and Joined_mos_left. Virtual fields are listed at the end of the field list and they start at the heading "(virtual fields)...".  These new fields appear at the very end.


Renew_date: This is Donor.Renew expressed as a full date value.  For example, if a donor's Renew field is set to "201410", then Renew_date is output as "10/31/2014". For a single-membership organization, that is the final date of their membership. For a dual-membership organization that is the final date of their primary membership.


Joined_date: This is Donor.Joined expressed as a full date value. For a single-membership organization, e.g. if Joined is set to "200302" then Joined_date is set to "02/01/2003", reflecting the true date that they joined.  For a dual-membership organization, the Joined field was repurposed to track the final month of the secondary membership; for those sites if Joined is set to "201409" then Joined_date returns "09/30/2014".


Renew_mos_left: Number of months from their last membership gift date to Renew_date.  Most memberships should return a number close to "12". If this field returns a much smaller or larger number, you may want to inspect the account to make sure everything is correctly dated. For a single-membership organization, this is the length of the current membership in months.  For a dual-membership organization, this is the length of the current primary membership in months.


Joined_mos_left: For a single-membership organization Joined_mos_left returns zero, to indicate that it is not measuring "months left" to the date they joined.  For a dual-membership organization, this is the number of months from their secondary membership gift date to Joined_date, which for them tracks the final date of that membership.  Most secondary memberships should return a number close to "12". If this field returns a much smaller or larger number, you may want to inspect the account to make sure everything is correctly dated.




Input... Donors/Pledges/Payments: Added new field labeled "CDP Cat." in the lower-right corner of the [Pledge] / [Basic Info] tab page. As of this update, "Utility... Import/Export... Upload CDP Files" saves the calculated CDP source category code in the new field Pledge.Cdp_cat.  Prior to this update the program wrote the category code to the exported BIO and TRN files, for upload to CDP (Community Development Partnership). Now it also saves the code in each exported pledge record.


Note: After installing this update, and after your next CDP export, you may wish to query the Pledge table. At the Fields tab, choose Source, Res_method, Purpose, Fund, Pledge# and Account.  At the Selection tab, set up "Cdp_cat = X" followed by Date >= the "Earliest pledge date" that was entered on "Upload CDP Files" before launching the export.  At the Ordering tab, choose the index whose first field is ":Date".  Run the query.  Because category "X" means "Miscellaneous member revenue". It is a catch-all code for any pledge that was not matched with another, more specific category.  If the query lists any pledges you believe should have been assigned a more fitting code - that "X" should not have been assigned - the query list let's you look donors and pledges in question, to correct any field value that is inconsistent with the expected CDP category.




Utility... Import/Export... Payroll Plan Payments:  Prior to this update is did not act on the sustaining plan auto-renew feature. All other programs that create payments were set to act on auto-renew, but not Payroll Plan Payments. That has been fixed as of this update.


Added to: "Report... Financials... Income Analysis... Source by Purpose" and the following "Acquisitions & AddGifts" reports: "List Performance" "Gift Purpose", "List Life", "Response by Dates" and "Purpose by Locations": After their totals, output selection entries used as filters in the report.  This is an ongoing project; and over time all reports will output their selection filters at the end.




Input... Donors/pledges/payments, on the tab page "Options & Tasks", "Recount donor totals": added a check box option to "Close MemSys on completion".  Some users start a full recount of donor annual giving totals, which may take an hour or more for a large database.  They like to start the recount at the end of the day, so it runs overnight. Checking the new option will exit the MemSys application at the end of the recount. Doing so can be important if - even later overnight - the file server will run a backup or a virus scan.




Report... Major Giving... Compare FY Giving: Added a new report to the Major Giving module. It is based on a spreadsheet developed by Deb Turner at Greater Public, which compares major giving between four succeeding fiscal years. The MemSys version creates a report that is designed the same as the spreadsheet's cells in which a user keys in numbers which then calculate year to year comparisons and net revenue. Recommended use is to write the report to a text File, open it in Notepad, and then copy/paste the entry values into Deb's spreadsheet.




Report... Pledge... Fulfillment reports... Pledges/payments by any Period: Entries of "Response method" filters were not being acted on during the report. This has been fixed.




Mailings and Reports offering selection by pull-down lists: Previously it was possible to manually key in a value even if it was invalid, although most users chose a value from the pull-down list.  This update limits the user to choosing one of the listed values - no manual entry permitted.




Utility... Import/Export... Import Web Site Pledges: Added the entry of a default Fund number, when setting up to run an import.  If user enters a Fund number, and the file does not provide a Fund field, the import will save the entered value to each pledge record. If no default Fund is entered, and the file itself does not provide a Fund field, then the legacy logic applies, in which MemSys will save the Source code's default fund number, if there is one. So, an entered Fund overrides Source.Fund, but a Fund in the file overrides all possible default values.




Any screen, export or report that can age an installment plan: After calculating Pledge.Idue_Now (the amount to charge, debit or bill), if the residual balance is 10% or less than one full installment, add the residual balance to Idue_Now. This avoids waiting a month to collect a small residual balance due. Previously, aging an install plan would behave that way if the residual balance were any amount less than one installment. But some odd pledge amounts and plan terms caused there to be a residual balance just slightly smaller than one full installment. The new change limits the tack-on action to a very small residual balance.




Utility... Import/Export... Import Web Site Pledges: When importing a pledge whose Method code is "EF" or "FT" if it is an installment plan, set Pledge.Itype to "E" which in turn sets Pledge.Ibill to "E".  Not all web pledge import files return a pledge's payment Method, but the aforementioned change will be acted on when it does.


Report... Pledge... Fulfillment reports... Aging Pledges: Replaced check box options to include or exclude certain pledges by their Status. It's been replaced by a row of Status code entries. Entering any codes limits the report to pledges with those status codes. Leaving the entire row blank means "include any Status code". This is simpler and more flexible than the former check boxes.




Query... Report Writer: Added more virtual fields for the Donor table: "Prefix1_proper" to "Sal_informal_proper".  These new fields convert name, address and salutation fields to Proper case.  The new fields may be useful at organizations whose donor name and address fields are entered all UPPERCASE.  MemSys mailing programs have always provided an option to convert fields to Proper case.  Now, Query can also provide the same case conversion.  Note: If you already enter donor names and addresses in Proper case, the new "_proper" fields will not be beneficial, because your own version of a donor's name should be more accurate than what is possible with the  standard Proper case conversion (only capitalize the first letter of each word).




Setup... MemSys System File... Operators:  Added new option to enforce expiration of operator passwords after a specified number of days.  As the update is installed, this option is not active. Whether or not to implement a periodic password-change requirement is up to the management of your organization.  HDS recommends that each MemSys operator be required to change their password on a periodic basis.  In "Setup... MemSys System File", click on the "Operators" tab page. The new option is labeled "Operator password expires in ## days (0=no expiration)".   Setting the option blank renders the change-password requirement inactive.  Otherwise, enter the number of days, from 6 to 9999.  The recommended number of days before a password expires is "60"; but that is at your discretion.




Utility... Import/Export... Import Donor Telemarketing Pledges:  For clients that use Sage Payments, added logic that allows the imported GUID (globally unique i.d.) to change an install plan's Billing Code (Pledge.Ibill) from "B" to "C", and change Pledge.Method to the correct code for the card type.  Prior to this addition, Pledge.Method could be set to "CK" and, if the pledge is an installment or sustaining plan, Billing Code could be set to "B" (send bill).  This change allows imported donor telemarketing pledges to pick up the correct plan billing code and payment method, with no card number present in the file received from the telemarketing firm.  Note: This capability was already present in "Import Web Site Pledges". This only applies to sites that use Sage Payments to vault-store donor card information.




Input... Donors/Pledges/Payments... on the Pledge record's "Install" tab page: Added "External list" below "Ext. pledge#", the latter a field that was already visible on the page.  The two fields relate to each other.  The entry labeled "Ext. pledge#" displays the Pledge.ExtPlg# field.  The new entry, labeled "External list", displays the Pledge.Ext_List field.  Although both fields permit a manual data entry, they are usually populated by the import of a web pledge.  


Pledge.ExtPlg# field tracks the web service provider's version of a pledge number; it is an i.d. number that remains the same for all recurring payments the provider may process on an installment or sustaining plan.


Pledge.Ext_List field - the one we've just added as "External list" - is also populated during the import of a web pledge; and it should reflect the web import's "File Format". For example, on finding a pledge record, if "External list" displays "PI" that's the file format when one imports web pledges from Quick Pledge - the NPR Digital online pledge form.  The letters "PI" are a legacy of when QP was owned by "Public Interactive".  The two fields combined - ExtPlg# and Ext_List - allow progress payments, in a web pledge import file, to look up the correct MemSys pledge record and its donor, using only service provider information.  It is a system that supports the import of pledges paid by single payments or a year or more of installments, without having to upload any information to the service provider.  


NOTE: If your web import captures progress payments on installment or sustaining plans... please DO NOT change the data already found in either field. Doing so could prevent the successful import of future progress payments. When a web pledge is a sustaining plan, and it auto-renews, the number in Pledge.ExtPlg# is moved to the new plan and removed from the suspended plan. In this way, MemSys continues to perform clean posting of sustaining plan payments without having to change anything in the pledge record maintained by the service provider.




Input... Premium Inventory: Added two new check box fields on the right side of the entry panel. The two are related to how MemSys will handle premiums in sustaining plans that auto-renew. The first check box is labeled "Recreate premium in auto-renewed sustainers". Check that box to identify that the premium must be copied from one sustaining plan into the next auto-renew plan.  One example of such a premium might be an annual member card which a donor should receive every year. In other words, you would recreate the premium code in each new sustaining plan created by the auto-renew process.  The second new check box field is labeled "Approve premium recreated by auto-renewal". Check that box if, when the premium is added to an auto-renew sustaining plan, that its Status should be set immediately to "A" for approved. If the "Approve premium.." box is unchecked, but the "Recreate premium.." box is checked, the new premium request will have its approval subject to the normal business rules used to approve premiums for shipment.


Note: Checking the "Recreate premium.." box does NOT mean that MemSys will automatically add the premium code to a donor's first sustaining plan. It only means that when a sustaining plan auto-renews, if the premium code is already in than plan, it will be created again in the new sustaining plan.  If the premium code is not entered in the existing plan, it can't be set up again in the new plan.




Input... Donors/Pledges/Payments:  On the [Options & Tasks] tab page, added a new check box option labeled "Set Date Posted to today, if no operator default".  Check this new option to insert today's date, when clicking [Pay] at the Pledge record sets up the Payment tab page.  Checking the option assumes that you do not have a stored default value for Date_Posted. When you check this option, if your operator I.D. does have a stored default for Date_Posted, you will see a message asking if you want to remove it. If you remove it, and this option is checked, when MemSys sets up the Payment tab page for a new entry, it will insert today's date in the Date Posted field. Otherwise, if your operator I.D. still has a stored default value for Date Posted, that date will continue to be used in the Date Posted field.  


Note: Use a stored default Date Posted, to more easily create payments which are back-dated to a bank deposit date. To store a date in arrears as the default Date Posted, type in that date on the payment's Date Posted entry form and while the cursor is still in that form, press F11 to save the date as your operator default.




Utility... Import/Export... Upload CDP Files:  This is of interest only to stations that participate in the Community Development Project (CDP). Previously, the program was modified to eliminate "db_" from the names of exported files. However, if a user clicked [Upload Files] to upload an existing pair of files, the pop-up panel still expected the filenames to contain "db_".  The discrepancy caused the upload function not to recognize newer export files. This has been fixed so that all functions in the program work with files whose names do not include "db_" in the filename.




Input... Donors/Pledges/Payments:  Minor changes were made on the pledge record's "Install" tab page: The field previously labeled "Roll-over" has been changed to "Sustainer", to be more consistent with industry terms.  There is NO change to its function. If the field is checked, the pledge is recognized by MemSys as a sustaining plan.  The field name as seen in Query is still "Isustain" and the "checked" value is still "Y". Other minor adjustments were made to field positions on the "Install" tab page including the date fields labeled "First payment" and "Last payment".  Those changes were made to improve readability.