Application problem - suggestions

[Dave2002]

I have been trying to make up almost identical copies of a document, each with a unique code - possibly in more than one place in the document.

I have now succeeded by using old software - Appleworks, and the Mail Merge in that. It's slightly clunky, but OK. I have to run Snow Leopard (10.6.8) in order for this to work.

I thought it was possible to do the same thing in Word, or indeed other similar tools, and I'm sure it is, but reading manuals etc. is making my head hurt. Most of the modern "easy to use" (ha) tools make assumptions which are incorrect. I don't want to do a Mail Merge with my contacts list, or with fields such as Address, Name etc. I'll settle for a data source with just one field, which could be called UniqNo, which should contain a single 4 digit number, which is intended to be unique for the whole data set.

I can do it using semi-automated processes and Appleworks, and even convert the final output files back into Word or PDFs if I wish. As I suspected it turned out to be feasible, and not too difficult, but other tools seem to delight in making things like this difficult, or if not actually difficult, painfully obscure.

I am trying to make up instructions for new members of a club to send in payments via BACS, so that each member has a unique 4 digit code, which can then be expanded up to 18 characters (BACS compatible) with other identifiers (e.g first name, surname, etc.) so that the club treasurer can identify any payments. The reason for the printout is that each enrolling new member will fill in details on a form, and will be given a tear off receipt with their unique 4 digit code to minimise any possible problems later on. Thus the top and the bottom of the page must have the same number, but no two pages may have the same codes.

Could be done manually by using biro on printed forms of course, to add in the unique numbers top and bottom!

[MrGongGong]

The first question is surely

1: How many people do you anticipate being in this club?

[Dave2002]

The first question is surely

1: How many people do you anticipate being in this club?

130-150, but new members perhaps only 10-30.

The music society is probably going to have to move towards BACS payments anyway, so it makes sense to try to iron out any possible problems before they happen, and to treat new members as a pilot group. Currently payment is by cash or cheque. We do have a little experience of this sort of thing. There's always going to be someone who doesn't provide the right information, or something will go wrong, so it's worth thinking about how to avoid such problems. You might think that with a very small number that there won't ever be problems, but I think that's a mistake.

We can see from the current membership that there are several people who have the same surname, but we know that they are from different families. Thus we can't just use the surname to disambiguate those. Adding in one or two first name initials disambiguates most of the current members, but is not guaranteed for the future. The 18 character limit for BACS reference codes may present problems too. A few members have surnames of 10,11,12 characters, plus there are a few with double barrelled names (hyphens ideally need to be omitted).Thus simple coding may work in some cases, but in others the codes would have to be truncated to 18 characters. It might also be helpful to have a code to indicate what each payment is for, though that information could be exchanged in a "side channel" (form, telephone message, email, web page). The particular objective is to reduce the likelihood of anyone not putting in a suitable reference, so that payments could then only be linked to members with considerable difficulty. Encouraging members to use a unique (say) 4 digit code as well as other identification may help to avoid or reduce problems when reconciling bank statements with member's payments.

The BACS system is perhaps adequate, and has many advantages, but was probably not designed for ad-hoc payments by individuals or small organisations. It was probably intended originally for large volume transactions between commercial organisations which would employ IT staff and systems staff to make sure that transactions and accounting function properly.

As banks now turn their attention towards private individuals, they will simply build on what they already have. Ideally there should be the possibility of larger chunks of information passed between the sender and receiver for each transaction, but that's not what most payment systems provide currently, so a combination of bank reference codes, plus information held at both the sender and receiver end of each transaction are likely to be necessary to ensure smooth operation.