Deprecated: Return type of Requests_Cookie_Jar::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Cookie/Jar.php on line 63 Deprecated: Return type of Requests_Cookie_Jar::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Cookie/Jar.php on line 73 Deprecated: Return type of Requests_Cookie_Jar::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Cookie/Jar.php on line 89 Deprecated: Return type of Requests_Cookie_Jar::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Cookie/Jar.php on line 102 Deprecated: Return type of Requests_Cookie_Jar::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Cookie/Jar.php on line 111 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetExists($key) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 40 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetGet($key) should either be compatible with ArrayAccess::offsetGet(mixed $offset): mixed, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 51 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetSet($key, $value) should either be compatible with ArrayAccess::offsetSet(mixed $offset, mixed $value): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 68 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::offsetUnset($key) should either be compatible with ArrayAccess::offsetUnset(mixed $offset): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 82 Deprecated: Return type of Requests_Utility_CaseInsensitiveDictionary::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /usr/www/users/datatvvwuz/wp-includes/Requests/Utility/CaseInsensitiveDictionary.php on line 91 Master and sub-accounts – DataTill

1. Master and sub-accounts

Master and sub accounts video: https://youtu.be/PzxNG9kMnAY

In DataTill, we’ve upgraded our features to include master and sub-accounts. This is especially helpful for businesses with various branches that are connected to a main profile.

With this new capability, you can choose how billing works. You can either have separate billing for each sub-account or group all billing under the main account. If the main account handles billing, each sub-account gets its own invoice. If sub-accounts manage their own billing, each of them receives a separate invoice. This feature gives you more control and flexibility in managing billing for various parts of your business within DataTill.

2. Master accounts

To be able to mark an account as a master account, you need to go to the customer’s profile. Look for the “Account Details” section and then click on the “Edit” button.

On the following screen, navigate to the “Master” tab. On this screen you will need to complete the following settings:

Red:To mark the customer as a “Master Account” switch the toggle button to yes.
Pink:If the master account should be billed for all the sub-accounts, switch the toggle button to Yes. This means that the master account will receive an invoice for each sub-account linked to it. If each sub-account is responsible for their own account, leave the toggle button on No.

Click on the “Save” button found at the bottom of the screen to mark the customer as a master account. After the customer profile has been marked as a master account, an orange banner will appear on top of the customer profile to inform you that “This is a Master Account”.

3. Sub-accounts

To link a sub-account to a master account, you will need to go to the master account profile. From there, go to the “Account Details” section and then click on the “Edit” button.

On the following screen, navigate to the “Sub Accounts” tab. On this screen you will need to complete the following settings

Click on the “Add” button to link a sub-account to the master account. On the pop-up screen, look for the relevant customer in the drop-down menu and then click on the “Add” button.

After you have added a sub-account, you will see the following screen:

You will now be able to view a list of all sub-accounts linked to the master profile with their contact details. To go to that particular sub-account’s customer profile, click on the black button found on the right-hand side.
To remove a sub-account from a master account, click on the red x. Remember to click on “Save Changes” after adding or removing sub-accounts from the master account.

After marking a profile as a sub-account, the sub-account will have a banner on top of the profile to mention that “This is a Sub-Account of (master account name)”.

4. Billing

Now, you get to decide how billing works. With the master and sub-accounts feature, you can either group all billing under the master account or have separate billing for each sub-account. You set this up when you first mark the profile as a master account (see section 2).

4.1. Bill all to master account:

When bill all to master account is enabled, all invoices from sub-accounts will be made out to the master account. Your invoices for will look similar to the screenshot below:

In the pink section, you will be able to see the master profile’s account code, as well as the “Origin Ref” which will be the account code of the sub-account from which this invoice was generated. As mentioned above, when the bill all to master account function is enabled, all sub-account invoices will be made out to the master account. You will be able to view the master account’s details in the orange section.

4.2. Bill each sub-account individually:

When bill all to master account is disabled, all sub-account invoices will be made out to the sub-account instead of the master account. Your invoices for will look similar to the screenshot below:

You will notice that this invoice will look like the normal monthly invoices that your ISP sends out. In the blue section, you can see that the invoice is made out to the sub-account and not a master account as there is no origin ref section as per section 4.1.

4.3. Suspending customers for non-payment:

Before suspending master accounts or their sub-accounts, it is suggested that there is good and clear understanding with regards to non-payment, overdue accounts, and suspensions.  With the new suspension module, you now have the ability so either suspended single sub-account or to bulk suspend the master account and all sub-accounts linked to their profile.

For more information on how to use the new suspensions module, please refer to the suspension manual.