Membership Profile (Roster) Information (posted to) the Website:

Includes such things as Member-Individual Names, ID #s, Address(es), Phone, Fax, Email, Personal Website, etc.

When the time comes, the Client will need to decide which (from amongst alternate variations of Names, Addresses, Phones, etc. -- inclusive of consideration of Primary Member vs. Individuals within the Membership) would be the appropriate ones.

Monthly Member A/R Statements (per Member):

Includes selected Statement 'Header' and 'Footer' information -- plus all itemized detail and chits.

The Client will need to decide whether to have Prior-Month Statements available in addition to Current-Month Statements.

Typical Approach:

The typical scenario is to do things on an 'automated' batch-update basis -- typically implying that every night the pertinent (xml) files are updated onto the Client's LAN Server -- to be 'picked up' and 'parsed & presented' by your Website Developer whenever desired.  The 'batch' method is the typical means of 'prepping' the files.

Roster -

In the Roster scenario, we typically create one csv or xml file (with the 'latest' Roster information for 'everyone') and put it somewhere on the Network.  The Club can have this set up by their Network Administrator to re-fresh itself every night.  Then the Club's Website Developer can 'pick it up' whenever desired-- or the Network administrator can set it up to automatically zip and transfer every night -- for example.  The typical methodology for doing this is a 'batch' process (we also offer 'dynamic')... and the formats are either .csv (normally) or xml (also available).

If the Client allows the Members to 'change' any of their Roster information, then it is common 'not' to allow these changes to be made dynamically (and 'posted' to the formal LAN Abacus database) -- but rather treated as 'submitted requests' for the respective changes... which would be reviewed and effected by Client administrative personnel.  Abacus 21 also offers a more-live-interactive style.... which requires question-answer exchanges with the Website itself.

On-Line Statements -

A similar concept is pertinent with the Member Statements -- except in this case each (iteration) of a Statement is (normally) created in a separate file -- indexed by Member and Statement Date.  (We also have a technique for creating 'one complete file per Month' with all Members in it.)  Both of these approaches include the 'current' Month Statement (which, during the current month, is in need of constant -- typically daily -- refresh).

• Generally an automatic nightly refresh is established to create and re-create the 'current Month' -- until such time as it becomes 'last month' (or in general a past month) -- and, once the file reaches that status, it doesn't normally need to be re-freshed.
• All of these Statement Files (by Member by Month -- or per Month) are on the Server...  again waiting for the Website Developer to pick them up.
  • Note, each of these files has everything in it that is needed to do the Header, the Body, the Tail, and the Ticket Explosion into Detail.
  • These files can be 'picked up' one-by-one or en-mass -- whatever serves the Client and Website Developer best.
  • And, under this scenario, Client & Website Developer are totally in control of the Web-Firewall security aspects.

Abacus 21 also offers a more 'dynamic' you-ask, we-send mechanism -- but that in most cases is not the typical approach.

How and in what format(s) are requests made of the software to obtain specific data elements?

In the 'Batch' mode described above, Abacus 21 merely tells the Website Developer the File Name, Formats, and where they are on the Server -- and the Developer can go get them desired.  The files themselves are in xml or csv for Rosters... and xml format for On-Statements.

For the 'Dynamic' mode, in simplistic terms the Website Developer submits to us (in XML format) a Web Address, a Type of Request Indicator, and pertinent information to be 'passed'.

• For example, for the Roster, the particular 'passed info' would be the Member (or perhaps Member-Individual) Code -- if you wanted just a 'single' one...  or just the 'Roster' request if you wanted the whole thing.
• For the Statements, a Member Code and Month (perhaps with a suffix indicating a particular Ticket if it is desired to siphon a POS-Ticket's detail only when clicked upon).