Receipts and Payment qty / unit price column

  • If Column - Qty remains unchecked, old data appears, in the sense that Amount now shows the same value as the previous Amount field did.
  • If Column - Qty is checked, but Column - Unit price remains unchecked (the default condition after update), Amount appears.
  • But, if Column - Unit price is checked, everything goes to zero.

Granted, neither of those new check boxes seems to be checked after update. But the performance is unexpected and confusing. And some users describe behavior consistent with both fields being checked.

The entire change seems unnecessary. It addresses something that was not a problem. Irrespective of the philosophy of minimizing presentation of unnecessary fields, the program is now very inconsistent. In one receipt/payment, you might enter a number in the Amount field. In another, you might enter a quantity, but unless you had another box checked, you have nowhere to enter a unit price, so you have to enter a total amount. On the same receipt, if you then check the second box, you have to change the total amount to a unit price.

@lubos, I think this was a very poor idea and definitely not up to Manager’s usual standards for intuitive use.

2 Likes

I couldn’t agree more, this new convoluted way has opened the door for lots of things to go wrong without any real benefits to 99.9% of users.

I believe that this is making a tangled mess out of receipts and payments.

For one, the behavior of quantity column checkbox is being overly complicated for no reason. It’s purely a display issue that’s now affecting the core functionality of the entry form and that’s not good at all. Alternatively, if we put this display issue in context, this is what should have been made, imo:

  • The Qty Column checkbox should have ZERO bearing on how calculations work. It should be purely cosmetic.

  • The amount column should always equal Qty × Unit Price regardless of what box has been checked. The Qty should always default to one.

  • When Qty column is hidden, the Amount column is also hidden, which leaves the Unit Price visible. The heading of Unit Price column can be changed to Amount for cosmetic purposes.

As for the Fixed Total issue, I hate to go back full circle, but this seems like a workaround for manager not tracking bank discrepancies on transactional level.

I’m not going to bring back my proposal for matching BUT what if:

  • We recognize the Fixed Total issue for what it truely is – a reconciled amount and it’s related discrepancy.

  • The fixed total is renamed Reconciled Amount and placed alongside cleared status and cleared date.

  • This new reconciled amount should have ZERO bearing on how the form works or on how figures are calculated and instead, a discrepancy figure is shown in red after the totals much like how imbalanced Journal Entries work.

This is useful for bank rules where total amount is known from imported transaction and you just want bank rule to assign inventory item and quantity and leave it at that.

Or in general… you know you have purchased 2345 widgets for $987.65. I’m not forcing users to try to figure unit price so they arrive at the right total. They just enter total, qty… and that’s it.

As per response to @Tut . Some users know Qty and line total. They don’t know Unit price. They’d have to try to calculate it to arrive at the right total. Extra work for no added benefit.

I don’t see it as a workaround because I don’t agree that bank reconciliation matching on transactional level is good approach. It sounds good in theory but if something goes wrong you won’t even know something is wrong.

Just because you have matched all your bank statement lines to receipts and payments does not mean you are actually reconciled. What if your bank statement lines are not imported correctly, what if some are missing? The software will tell you you are reconciled even though you are not. This is problem in every accounting software that does bank reconciliation matching on transactional level. People just don’t know it’s a problem until they get biten by it. Then they wonder what’s the point of reconciling on transactional level if it gives you no guarantees anyway.

Not necessarily. Fixed total would be useful for purchase invoices too. It’s just extra safeguard to make sure transaction total is what it should be after all the splitting.

I don’t want to make it compulsory. Most users would not understand why the same amount is entered twice until it saves their day.

Out of balance amount is posted to Suspense account on journal entries too. I think Out of balance transactions need to be as loud as possible so they are noticed fast.

I can’t see how typing in X/Y in the amount field is extra work but fine, I’ll give you that. But is that worth having a chameleon of form that keeps changing on you? I don’t appreciate this trade-off.

That could be handled in much less intrusive way as well similar to Journal Entries example.

I see that you might have some strong opinions here, but I will leave it at this: spoon feeding exceptionally low skilled users is only going to dumb down and overcomplicate the software and make it less suitable for professional use – which I reckon is what most users are using manager for.

Just some suggestions how to make this more intuitive. When Qty column checkbox is checked but Unit price unchecked.

Then we can still show unit price “auto-calculated”:

image

Sure, this implementation seems possible but my problems are these:

  1. What’s the fixed user input in this case? Is it always the Amount and never the unit price? or is it the other way around? I don’t have a problem with any of those options as long as it isn’t both at the same time because this will not preserve user input.

  2. In case the unit price input is dropped, how can the user adjust the set unit price of an inventory item?

  3. If a user opted to hide the Qty column, why would they need to calculate the unit price?

1 Like

Sorry but the alternative you are putting forward is worse and an oversimplification. Any serious auditor will track and trace at transactional level. If you did not import your bank statements well, the original will trap you and as a user you should just check that all is there. I do not see any value in further simplifying that is already basic enough. If anything I fear that erroneous reconcilliations are easier this new way. Sorry but I do not think this fix fixes the real issues.

@Ealfardan check the latest version (21.11.84) where you can test this auto-calculating unit price column to see for yourself the mechanics and then comment on that.

Yes. It is simpler concept. Is it oversimplification? I don’t think so. When you receive supplier statement and want to reconcile their statement with what you have in your accounting software, are you going to be pairing each transaction on their statement with what you have entered into your accounting system?

Don’t think so. You will look at the closing balance, then look at closing balance in your accounting system and if the figures match, you do not look any further and simply assume it’s reconciled.

Is this oversimplification?

Sure. But they will not rely on your imported transactions. They will do their own matching with actual bank statements.

Actually, it works and user input is preserved :+1: but I have to admit … I still don’t like it. :grin:

It’s just that it’s way too many options for layout and it’s making things a bit unwieldy.

Maybe if somehow we could get some of those options to disappear from the entry form and just reside in form defaults where tweak freaks can play with them?

Anyway, enough of me being a buzz kill. Let’s hear what others think of this.

1 Like

I’m not convinced it is an improvement.

  • It is more complicated.
  • It assumes a particular work flow.

The problem with the old way was that if someone entered data incorrectly then the records were wrong. But that’s still and always the case. Bank imports contain only what the bank knows. It does not contain invoice breakdown or stock control information. That has to be user supplied (complete with operator errors).

Imo it would be more useful to have a bank import rule option which entered a default multi line template but required user confirmation / editing of the distribution.

1 Like

Maybe I am not understanding but is that not the purpose of reconciling a statement? For example Investopedia states that

In general, reconciling bank statements can help you identify any unusual transactions that might be caused by fraud or accounting errors. This process can be done formally or informally. This is true for both businesses and individuals, who should both verify every transaction individually, making sure the amounts match perfectly, and, if not, making note of any differences that need further investigation.

1 Like

Reconciling by comparing every bank account entry with Manager entries (by matching a bank download to Manager bank records, then highlighting the least matchable entries on both sides), has been suggested but unfortunately was rejected. Imo matching bank download provides a better bank reconciliation that’s just my opinion.

1 Like

To explain why I think it is superior

  1. Comparing Managers records to a bank import is an end to end test. It detects all changes made at any time. Storing the initial bank imported line amount then comparing to that, does not detect errors made when the transaction date or amountis changed for any reason (valid or in error).

  2. Comparing Managers records to a bank import also check manually entered data.

  3. Comparing Managers records to a bank import could be used to add bank clearance date.

@Patch the way I see it is that single receipt or payment in Manager represents single bank statement line. The existence of receipt or payment which Cleared status already indicates that there is 1:1 match. Importing your bank statements automatically creates 1:1 match.

The reason why some accounting systems have “matching” layer is because they are unable to have 1:1 match. They will have special transaction types when receiving payment from customer, different one when selling goods, and yet another transaction type when purchasing fixed assets etc. So then you have to “match” all these little transactions scattered around the system to single bank statement line.

But in Manager, you can make single payment transaction which can be split so you can record payment to supplier, purchase of fixed asset and sale of inventory item all within one transaction. And this transaction represents bank statement line. So it’s implied 1:1 match.

I guess some users really like the process of “matching”. Must be fun. But to me this is useless because whatever bank statement lines you have imported for matching is not source of truth anyway. The import could have been wrong or incomplete. Now you’ve matched everything but you are still unreconciled. But accounting software would not know because you’ve matched everything.

The only correct way to match would be against the source of truth that is physical bank statement. But that’s not fun.

That’s what computer matching of bank statement import does. It automates the old manual process, matching the easy matches first, then successively harder. Eventually leaving the hardest which are either an error or require external knowledge to justify.

Btw I can’t see it happening now.

@Patch bank statement import is not source of truth. The source of truth is physical bank statement.

Here are some Xero topics on this issue where users have realized this the hard way:

https://community.xero.com/business/discussion/37344472
https://community.xero.com/business/discussion/4438292

Xero is implementing “matching” mechanism you propose. Does this change your mind at all?

Matching bank statement line amounts checks the lines in that bank statement only.

To check for data in other bank statements the starting / closing balance also need to be checked. Which is why I continue to use Managers bank reconciliation tab.

Zero’s system is worse because

  1. bank import is a once only process. The test can not be run again at a later time to check for subsequent alterations.

  2. People assume a bank feed includes all the data a human can see from the bank. And as it’s automated with no manual control / checking, it is assumed to be error free. Unfortunately I assume it just includes bank statement lines not a running total so it won’t pick up errors in starting balance, feeds not received, and probably transmission errors.

  3. As far I’m aware Zero relies on bank feeds (ensuring Zero always has current bank data) but does not have a bank reconciliation tab. In contrast Manager does have a reconciliation tab (so can detect missed imports) but does not have bank feeds, so often does not have current bank information (increasing the use of mixed manual data entry and bank imports).

So no, the limitations of Zeros implementation of bank feeds, does not change what I think would be best for Manager.

1 Like

That’s not entirely true. Unable to have 1:1 match and allowing many to many matching are two different things. If you completely rely on bank imports in Xero (and any other software for that matter) that completely guarantees 1:1 correspondence between bank and books. This isn’t any different from what Manager is doing.

The difference becomes apparent is when the bank summarizes batches. Xero and other software allows many to many matches while Manager refuses to accommodate those. The user is left with a dilemma:

  • Opt for a completely manual process and completely forgo the efficiencies of bank imports.

VS

  • Rely solely on imports thereby accept all bank statements as true and forgo the detailed nature and timeliness of manual receipts and payments.

Xero here is a bad example, why not take Odoo, Dynamics, NetSuite; they all rely on matching and have perfected it – where’s their commercial? :grin:

That aside, let’s say Manager comes up with a way around the many to many matches. For instance, bank lines can be split or merged to match the books – and not the other way around because receipts and payments are legal documents and can’t be altered this way.

Let’s say we have that. Now there’s no need for matching but why do we have to discard the bank details altogether? Why not embed the entire bank line inside the receipt or payment?

We already have the bank date, and bank amount disguised as “Fixed Total” so why not add the bank description and have the full picture contained within Manager. This way we don’t need the cleared field.

Advantages:

  • 1:1 matching and no need for any complexity.

  • Self contained as you previously described here. This is better suited for the structure of Manager.

  • Fully documented bank statements within Manager, the user can easily view and verify the bank statements from within Manager. This is more integral and transparent than what we currently have.

  • Most importantly, Manager can then track down discrepancies to individual transaction level. This is the holy grail of all reconciliations.

It check all users’ boxes and it also check your boxes, @lubos. Why not consider it? That’s provided we can transform bank lines to enable 1:1 matching (i.e. splitting and merging).

I forgot to mention, I object to the “Fixed total” forcing suspense lines. I’d rather have a discrepany shown as I mentioned earlier.

@Patch to summarize…

You agree that bank reconciliation should be done against the source of truth and you agree that imported bank statement lines are not source of truth.

If this is correct. Then “matching” process where you match general ledger transactions to imported bank statement lines is not bank reconciliation.

So what benefit does having bank statement lines separate from general ledger transactions provide? I honestly see extra work (because now you have to match) for no benefit. Could you provide some real-world scenario where is that useful? Where it saves your day? Or time or decrease chance ending up with bookkeeping errors?