LogiQ is a windows application which utilises a SQL Server Database Server. So, it is installed in two parts:
1. Database Server: We install Microsoft SQL Server on to a Database Server and the LogiQ database is then installed on to that. It is best that the Database Server is left turned on at all times and be in a back room some where, where it is not used for day to day operations. At present we recommend SQL Server 2005 Express (the Advanced Services edition). This is availabel for free from Microsoft. Ths installation must be carried out either by a QVisual Technical Engineer or by a Qualified Technician (must be a Microsoft SQL Server Expert).The server must not use a Home version of Microsoft Windows.
2. Client Applicaton: The LogiQ client application is installed on each workstation. It is a simple installation. We do not support Windows Vista installations. We recommend Windows XP Professional. We are yet to fully validate the operatiom of LogiQ on Windows 7.
Invoicing will generate a tax invoice for Clubs Corporates or Business entities wishing to have a tax record for a booking or other contract operation. It is not intened as a payment method for personal members/memberships.
An invoice will be printed which should be passed on to the accounts dept for insertion in Detors Ledger. Logiq does not maintain a detors ledger. There is a facility to take cash for an invoice by access the invoicing section but this merely logs and reconciles a cash receipt at Back Office. Once again this information should be passed to accounts for ledger update.
This is quite permissible. To safeguard accounting practice any previous transactions using the old code will still retain the old code. He new code will only be picked up by new transactions.
In a multi venue setup, one of the venues will be situated at Head Office or wherever. It is important that someone has an overall view and access to all the setups and information on each of the other venues. That person is an administrator.
At each venue there will be a manager responsible for that venue who needs higher access rights.
That person has manager rights and can only access that particular venue and no other.
1 General venue policy as to what type of cardholder can gain access.
2 Setting up the Access control PC at the gate to describe its function.
3 Access parameters for members, courses and decrementing passes.
Note too that there is an option in System settings for Course members.
For further info see Access Control Video on this site.
In Sys Nav/Options/Settings there is a parameter that can be set that dictates how many minutes before and after a class time that person can have access through a gate.
This hierarchy is quite important but you can manipulate it according to how you want to see it work.
A Program is literally that. It is a label to cover something that you may run just once or repeat every year.
Example would be: Program =LTS.
During the next year you might run a Program of Courses and Classes covering LTS. However you do not run these all the time only over defined periods during the year eg. School terms etc.
So we then break that Program up into Bands.
Bands in this case might = Spring, Summer, Autumn, Winter terms. We let you keep those Band labels carried on from year to year and all you have to do then is to define the dates each time.
So we let you define Dates for those Bands. Spring term happens every year but the start and finish dates are going to be different each year. So Dates is where you can define that.
Once that is defined you can book Classes. Instructors and locations as you wish within the dates on that Band.
This allows you much greater flexibility. A membership plan has certain Characteristics particular to that plan which will be entirely different to details for the type of payment methods you would like to employ.
You may have a Gold Membership but with two or three or more ways of purchasing that plan.
This format allows better analysis and a more compact way of presenting the numerous combinations you may wish to market.
The first port of call every time without fail is the DD schedule from a button called Direct Debits on the Customer Manager screen.
This is the only view that gives you a concise picture as to what the DD run is going to take from that persons account in any one month.
It also contains a lot of detail as to what makes up that total. Just double click on any month and you will see one or more transactions that make up that account.
Although the basic monthly DD might be $40.00 the total displayed might be different. If you drill down then you might see:
- An additional pro rata amount calculated at start or end of membership
- An adjustment that some one has made either as a credit amount or a debit.
- A cash payment that the Customer has made at reception to cover an outstanding amount or maybe a payment made in advance.
These adjustments or payments may have been entered elsewhere on the system. Some of the those other displays show total transaction detail which can actually be confused with payments owing.
The Schedule is the place to start to see what is owed.
In a Direct Debit process there are a number of event dates that are relevant and need to be recorded. There are three main dates:
Process Date
This is the date that the transaction will be expected to be run. You will have already set up the Customers payment schedule and the dates in this schedule will relate to the dates you have setup in your system for the DD run to take place. I.E. the 5th of every month. This date is therefore the expected run date. It can however change en route for a good reason.
Maybe the first time it was run it got defaulted so is put back into the system to retry for the next process date. This date will therefore change every time it defaults. The Original date however stays the same.
Origin(al) Date
This will be as above and is the very first Process date. The Origin date is always the same. You can therefore see how long the Process date is from the Original date.
Transaction Date
This is the actual date the transaction is run. This can be different from the Process date if say the run took place a day or two earlier or later than the planned Process date.
No. When a members payments are scheduled then Logiq looks for the next available run to slot the payment into and thereafter every month on the same date.
So the pro rata amount will be calculated up to that month. You do have the option when selling the package for the new member to choose a more convenient run, assuming of course it is one of the DD runs you have setup in Sys Nav.