Security Deposits - Customer & Supplier

I think this is the only option possible at present.

I was hoping to be able to show both under the same statement of transactions for a customer or supplier. That way all the transactions would be dated and tracked easily.
Creating duplicate customer or supplier is ok. But its more tedious when we have to document everything as a hard copy. In our case we file the hard copies of quarterly statements for every record. Also our government rules states that we should maintain all records of atleast 6 financial years. so if we have to maintain two records for a single customer you can very well understand the difficulty when we need to cross-check any old transaction.

1 Like
  1. Why and 2) why not print as a pdf file and store on a USB stick. Then print a hard copy “if” ever required. As long as you can reproduce a hard copy, then maintaining an actual hard copy is excessive.

This is a requirement of most governments, though the number of years may vary.
As Manager is endless, even after ten years all records are still reproducible, this maintaining of records should never be an issue.

No I don’t understand, for either customer record just create and print a statement for the whole ten years if ever required, besides the “deposit” customer record would be fairly static.

USB’s stored off site is probably more reliable then paper being destroyed in the event of an office fire.

Manager is constantly evolving. So it is doubtful the document template we use today will be possible to reproduce in another two years. Moreover, our tax system is changing and I am sure there will be more changes. So nothing is a guarantee. :slightly_smiling_face:

What i tried to explain is that the monthly or quarterly statement of a supplier or customer is exchanged to verify whether the records match. And their transactions are dated which includes the credit, debit and deposits. So checking the transactions with two separate statements, one for credit debit and one for deposits, will cause a bit confusion with the balance.

Also, suppose i have duplicate customers or suppliers as you suggested, how will the available balance in Deposits be adjusted against the outstanding balance at the end of a business?

1 Like

A Custom Field for Customers named " Amount of Security Deposit" will show on Customer Statements.

Of course the information would have to be entered once for each customer, and it would appear as a footnote on the Customer Statement.

The amount would still have to be recorded on the balance sheet. A date or reference number could be included in the Custom Field to help locate the original balance sheet entry, which may have been recorded years before.

There does not seem to be any elegant solution to this.

Users who starting using Manager 4 years ago can still reproduce their first transactions today.
Because the template changes the data hasn’t, the data will be reproduced in accordance with the template of the day.

True but changes in tax systems doesn’t affect data - countries like Australia / New Zealand have gone from non GST to GST, but all those transactions prior to GST remain unaffected.

To accept your argument means that the 6 year requirement for recording keeping dissipates because the tax system has changed - but that is not the case.

But if one customer account only has deposit transactions where is the confusion.

Via a Journal entry - similar to the transfer of balances when you have both a Supplier / Customer relationship with the same business.

I suggest that you stop finding obstacles for obstacles which don’t exist. Businesses such as Real Estates in receiving rental bonds (security deposits) have been dealing with these types of situations for decades if not centuries and they aren’t having your difficulties.

We are collecting Security Deposits from our Customer & Employees which is refundable at the end of services.

We have mapped the process through Non-Inventory and checked ‘item can be sold’ through which we can raise the invoice and a Liability account was selected for accounting.

Today, it is noticed while review that ONLY Income & Expense accounts are appearing in a drop down list. We will appreciate your quick response with guideline to manage the situation.

1 Like

Deposits should be handled by posting the receipt to a Customer’s subaccount in Accounts receivable or to a special account. See the Guides:

Non-inventory items are for things you buy or sell. You are doing neither when you accept a deposit.

Thank you for your response.

It is quoted that ‘the deposit also reduces the total Accounts receivable balance’ which should not be the case. Another option suggested to use Special Account which at-least supports for accounting.

The option was available till last week or so therefore we have designed our process. We tried to implement today for final testing and got stuck! May we know the reason why it is has been changed suddenly?

Following this guideline will only address accounting matter, we have to issue an invoice to Customer separately and through said guideline it is seems not possible.

Yes, it normally should, as money is fungible. If you want to prevent that, read this Guide: Avoid automatic credit allocations with special accounts | Manager.

I do not know. I am not involved with development. If account options were removed, I suspect that is because they should not have been there in the first place. It certainly would not make sense to post purchase or sale of non-inventory items to any accounts other than income or expense accounts.

You are not selling anything when you receive a security deposit, so you do not have to issue a sales invoice. Issue a receipt. But if you want to include the deposit on a sales invoice—knowing you will refund the amount later—post the line item to Accounts receivable or a special account.

Can you please check with development team, if it could have erroneously remove or if they can add the option back. We really need this option enable.

Beside, all your logic, we have to issue an instrument such as memo/invoice first which is ultimately paid in bank otherwise please let us know how we can issue a memo first.

If you need to issue something to obtain the deposit, use a sales quote. You can give it any title you want, and it has no financial impact. See Create sales quotes | Manager.

If you want a change to the program, you need to provide a use case that justifies it from an accounting viewpoint, something more than “we really need this option….”

I have just upgraded to the latest version (21.2.64) and as @Rajwani has stated it is no longer possible to select balance sheet accounts for Non-inventory items.

Existing Non-inventory items, that have a balance sheet account selected, remain intact and can be used as before in transactions.

I use Non-inventory items for most transactions and this change will affect the way I use Manager greatly.

I have checked the guide relating to Non-inventory items and it has been updated to reflect the recent change. I find that the four reasons given in the guide for the (optional) use of Non-Inventory items applies to any accounting item, not just products and services and this is why I use them extensively.

Also, custom fields created in Non-Inventory items enables the creation of more meaningful custom reports for all accounting items.

It would be interesting to know how many users are affected by this reduction in functionality.

It may be that the developer has made these changes to provide better functionality elsewhere in the program and it would be helpful to be informed if the change is permanent so that users can confidently move forward with other techniques to combat the loss of this functionality.

The recent update of that Guide incorporates only changes related to graphical layout of the form for defining non-inventory items. There have been similar updates to graphics over the years. But the basic content of that Guide, with its emphasis on using non-inventory items as shortcuts for sale and purchase of goods and services, has not changed since it was first written in 2016.

So, if you hope for a reversion, you should offer a use case with accounting justification (as I wrote earlier).

I can think of a number of items that would go to the balance sheet and not the P&L.

  1. Security Deposits (inward and outward)
  2. Rental Bonds (inward and outward
  3. Loan repayments (inward and outward)

I don’t doubt that what you say about the guide is correct, but that doesn’t change the argument I put forward.

I realise that the developer will structure the program in the way that he thinks fit, and all I am asking for is confirmation that this change, restricting account selection to P&L accounts, is intentional.

I think, there is an answer in your statement. The option was available till last week; may we know the justification restricting such to P&L only? As this is not enough to justify even that the option is available only for buy and sell.

As it is mentioned by @AJD, there could be multiple user who are using this feature for various reasons and it really supports functionality.

I think, Manager needs to re-assess the change or give such other option to incorporate such concerns.

It is not my role to justify program changes to you. You are the one requesting a change that departs from the intended use of non-inventory items.

Your guesses about other users will not carry much weight. You were asked to justify a use case. @AJD was asked the same thing and offered justifications. I do not know if the developer will consider those to be sufficient. But I suspect that, unless you offer something specific, your request will not be considered.

No they are not, they are requesting for a functionally that previously existed to be re-instated.

This is very clear evidence that Manager did previously permit / allow Non-Inventory items to be allocated to both the BS and P&L. So why does the developer now want to remove the BS selection / flexibility from Non Inventory Items. The conflict described in the second paragraph is particularly concerning.

There is no accounting principle or convention which justifies Users being handcuff this way. This ad hoc changing of pre-existing features once again illustrates how the developer doesn’t fully appreciate how Users have adopted Manager and the impact that these changers have.

In fact, if I was the developer I would have simply modified the tick box description :
This item can be purchased / payable
This item can be sold / receivable

Also, I would have discarded the title Non Inventory Item for Default Account Item.
Where the User allocates a default account for a particular transaction item regardless of it being for the P&L or the BS as illustrated by @AJD

Meanwhile Users can circumnavigate this artificial BS account selection limitation by maintaining an older version of Manager on a separate computer, create their Non Inventory Items within that older version, then via the Batch Create/Update process, transfer those items into the current version.

1 Like

Non-inventory items served as account alias because of the absence of such feature. In our case, non-accountants are using non-inventory items because the items are set using layman’s terms. You cant expect everyone to use the chart of accounts.

Also, details of some account are better expressed in non-inventory items (account alias) rather than subsidiaries. Examples of such accounts are accrued expenses payable, income tax payable, all other tax payables, unidentified deposits and other bank recon items, etc.

1 Like

I used have made a whole list of non-inventory items so than purchasing staff can properly and consistently classify any fixed assets they buy. Sure, you cannot charge them directly to their home account, but in a clearing account that is in the same group which was close enough. I think I already suggested the ability to select control accounts and then subsidiary accounts in non-inventory items just to bring it home but now that’s all out the window. It’s a shame.

Dear @lubos, could you please explain how this change is beneficial to anyone because I fail to see any value in removing such a powerful and useful feature.

1 Like

Unfortunately I fear, that the chance of getting a response to that request will be rarer then having a trip to the moon. Manager has a proven history that they don’t need to be explanatory about programme changes.

It is extremely concerning about the number of programme downgrades that have occurred over the recent months which have had serious impacts upon Manager Users - that is, Users are now prevented from using Manager in ways for which they were previously entitled - for years.

The disappointing aspect about these downgrades is that all of then have ABSOLUTELY NOTHING to do with accountancy, yet Manager which is suppose to be an accounting software, seem to have taken scant regard to that fact. It appears that the programme’s coders seem to be aimlessly rewriting basic and standard account practises, but for what purpose - expect pissing off Users.