If you have used the NAWS Export Functionality of the BMLT to send synchronization dumps to NAWS, you have received a spreadsheet in reply, with a series of meetings that have revised or newly-assigned Committee Codes (what we call “World ID” in the BMLT).
These are fairly long sequences of numbers, prefixed by one or two letters, like so:
- Regions are listed as “RGXXX“, with “XXX” being 3 digits (with leading zeroes). For example: “RG001”, “RG123”.
- Areas are listed as “ARXXXXX“, with “XXXXX” being 5 digits (also with leading zeroes). For example: “AR00001”, “AR00123”, “AR12345”.
- Groups are listed as “GXXXXXXX“, with “XXXXXXX” being 7, leading-zero-padded digits. For example: “G0000001”, “G0001234”, “G1234567”.
These need to be assigned back to your BMLT database in order to ensure continued synchronization with NAWS.
It should be noted that NAWS tracks GROUPS, not MEETINGS.
Groups are Service entities. They are the driving force behind meetings, and often a single Group can have multiple meetings (like clubhouses, or lunchtime meetings).
In these cases, you may apply the same World ID (NAWS Committee Code) to multiple meetings.
IT IS EXTREMELY IMPORTANT TO DO THIS! DON’T IGNORE THE SPREADSHEET RETURNED TO YOU BY NAWS!
It is very much worth it to keep NAWS in sync with your database, so this operation is important.
Thankfully, NAWS has agreed to do a certain thing that makes this process fairly easy to automate.
This post will spell out a somewhat “high geek factor” way of doing it. I will be working on a tool to abstract the complexity, but that will be a little while in coming.