Introduction to Havenstar

Introduction to Havenstar

Introduction

Havenstar is like a hotel reservation system, except it deals with boats and berths rather than people and beds. It can simplify running a marina by tracking the arrival of visiting boats, payments made or due, and charging correct rates on departure.

There are 4 interfaces in addition to an App for Dockside Manager and the web-portal.

  1. Dashboard and Navigation Bar
  1. Active Matrix – a snapshot of boat information presented in a table and Navigation Bar
  1. Graphic – a map of the marina showing berths and boats and Navigation Bar
  1. Havenstar screens – Once a boat is selected, you use the screens to perform functions with the software.

If part of a group, each marina is set up within the database, and a user will log in to the one they work at. Users can have access to more than one marina, which is ideal for centralised functions.

The Havenstar main screen will show you the organisation's selected dashboard and navigation bar. The dashboard comprises of widgets that can be set to reflect the data you wish to see within your organisation. You can set the number visible and its position.

If you prefer, you can opt to work with the Active Matrix or Graphic view if configured.

      


Havenstar is boat-record driven; in other words, you can have several boat records linked to one person. In this situation, one boat (usually the first one created) is the master record, and all the other boats associated with the same person are referred to as “Child”. This means when invoicing a child boat, all charges are redirected to the one master account. Revenue for each marina is recognised by nominal ledger codes assigned to products which are unique to each marina. So, a customer can have boats in different marinas with the income recognised at each one, but all the financial transactions are held under one account.   This makes financial control easier.

Boats are arrived at the marina as either a Resident (Annual) or a Visitor. A Resident has a berthing contract and pays either annually or by instalments according to a contract, whereas a Visitor has their stay time accrued daily. The status of ‘R’ or ‘V’ represents the statuses throughout the system, and boats can be changed from a Visitor to a Resident and back without having to create a new boat record.

 

If boats are in the marina, they will be denoted with the letter ‘I’. Similarly, if they are out of the marina, they will be marked with the letter ‘O’.

i.e., a status of RO would indicate a “Resident” currently “Out” of the marina; therefore, the berth would be available for other bookings up to when the Resident is due to return.

The menu sets in Havenstar are customisable. Within the new navigation bar, every command is initially available on the menu. They may be set so only certain users can access the commands, and if this is the case, you cannot amend the menus without the password.

 

Keyboard shortcuts are supported in Havenstar.

 

Throughout the manual we have documented the quickest method using keyboard shortcuts and shortcut icons. The icons are consistent across the program to make it easier to remember.

Common Icons

 


    • Related Articles

    • Departing a Boat

      Introduction In this video, we'll show you how to depart a boat in Havenstar.

    • Bookings Manager - Creating a booking

      Introduction In the video below, we'll show you how to create a booking in Havenstar.

    • Checking a Boat In and Out

      Introduction In the video below, we'll show you how to check in and check out a boat in Havenstar.

    • Deposit Ledger - Attaching Deposits to Contracts

      Introduction If you're not familiar with the Deposit Ledger - this module logs and tracks customer deposits. Deposits can be categorised by purpose/type, and payment type. For accounting purposes, they can be assigned a unique ledger code that ...

    • Creating a Credit Note

      Introduction A credit note is a formal financial correction. It reduces or cancels part, or all, of a charge already raised against a customer. It is typically used when: An invoice was raised in error A charge was duplicated A service was not ...