Reconcile view shows weird values (bug?)

I am playing around and I noticed that reconcile view seems to be broken:

  • Income view shows “total” as a sum of “plan” and “actual”. If you just add displayed numbers (“plan”), they do not match displayed “total”
  • It shows only actual for expenses
  • Reconcile cells tell me I am good but it counts my planned+actual income (so double income at worst) and only actual expenses (not planned ones), which is always wrong. According to the reconcile view I am fine this month while actually I am severely overspending. It should be planned income and planned expenses instead. Otherwise there is no point to have reconcile view at all.

Thank you for the report.
I remember touching the reconciliation calculations recently with the goal of making them more accurate and stable, although it can cause confusion or maybe it introduced a bug that happens here.

In general, reconciliation is based on the “Combined” view algorithm but the actual calculations may be different in the reconcile table vs income/expenses tables, I think. It’s different from Cashculator 1 because of the complexity of having precise dates for transactions and the ability to see stuff at both weekly and monthly resolutions. Before the changes, the weekly and monthly views would give different forecasts to the reconciliation table (because the calculations were based on the date ranges of the column, so different for weeks and months).

The idea now is that everything that’s in the past (up to yesterday) is taken from Actuals and everything from today on is the maximum of actual or plan (so Combined).

Can you send me the document? I’ll need to see the prices dates of the transactions.
If not, then maybe we can test it some other way.

Well, I do not really set dates there because I do not care about them. I only use “money” numbers. So all my dates are usually on 1st of the month. Invoices from the same company come at different times (it can be 5th or 12th), so does income. Therefore date is not relevant.

What I expect from reconcile view is to see if my monthly expenses are good or not compared to my income. If I am severely overspending, I need to replan. That works in Cashculator 1 and I use it all the time. But it does not work in Cashculator 2 now :frowning: It is so important to me that today I switched back to Cashculator 1 and put all data I already have in 2 back to 1.

Suppose I planned $150 for groceries. I will not buy them on 1st or 10th only, right? I will eat the whole month :smiley: So 150 is the total amount that I plan to spend for the whole month. Date is not relevant at all.

So, in reconcile view, expenses should show the most pessimistic number, which would be max(plan, actual). This formula also helps to see how good I am doing this month (overspending or not compared to my income).

For income it would be the same formula because I may expect to receive various amounts that add up to a certain sum. Those can be paid in any amount but they will add up to a certain number. So I would need to see my full expected amount in income for this month.

Yeah, I understand. You’re thinking like in Cashculator 1. But what happens if you switch to weekly view? How would your numbers work then? I wanted to have the ability to make Cashculator 2 work similarly to Cashculator 1 but this may be a problem in some other cases, like switching to a weekly view, unless we make an actual mode of it. But I understand your concern with regards to these calculations. Maybe I’ll switch it back to take the whole period of the column into account, like it was before, or have it an option. It only affects current month/week calculations but I can see how it can be confusing when using Cashculator 1 approach to Cashculator 2.

I would not switch to weekly view :smiley: My planning period is one month. I do not need that weekly view.

Cashculator 2 has too many changes in behavior compared to Cashculator 1. And it makes migration very difficult.

I once read an article on one of UX sites about why macOS users are much happier to upgrade to newer versions and why they do it faster than Windows users. One of “secrets” if “do small updates and no radical changes”. If you compare macOS versions one by one there very small change sin behavior for users. They are very easy to get used to. Then remember how Windows 8 totally changed its UI to those “tiles” (or whatever they were). It was “revolutionary” and Microsoft said that “users will love it”. Users hated it. All of them. Everyone wanted that “Start” button back. In the end Microsoft backtracked and reverted to the original UI and behavior.

Another example. Imagine you have a car. You drive it for 5 years. Now you are told that in your new car your driver’s sit will be on another side, there will be no steering wheel but joystick, no pedals but touch panel for managing speed and there will be no windshield but LCD screen connected to a camera in front of the car. Would you switch? Probably not. Because this is too much of a change.

I understand you want to make Cashculator 2 all cool, fresh and new. But do users want it? They are used to certain behavior. There many accounting apps around. But they chose Cashculator 1 and not some other app in the past. Why? Definitely not because of its look (it looked very dated even 2 years ago). They chose it because of its behavior. It suits them how it works! So if you radically change the way how Cashculator works, it may not be the best choice for users anymore.

Again, I understand you want to make shiny, new, document-based, save docs only if some obscure buttons is checked somewhere in system settings, etc. I am a developer myself and I know the feeling to “do it right”. But users are different. They do not want radical changes. They want it to work in a familiar way without any extra movements from their side.

For me personally, it would be ideal if look of Cashculator becomes more modern. I am ok with category groups too. This is a nice addition. But transaction dates, UI for editing transactions, and especially broken reconcile view are all stoppers for me. I very much like the new look but changes in behavior are not good for me. This is not the app I chose in the past for its behavior.

May be, behavior changes should be reconsidered.

Check: How to perform 12000/12 data entry similar to Cashculator 1

You see? People are asking for familiar behavior.

I understand the sentiment and that people get accustomed to how they use applications. In fact, a weekly planning option and having subcategories were the two most-requested features from v1 customers and v2 development started with having these as first priority. In the end, we decided to have weekly planning work alongside monthly planning, with the option of switching back and forth. This comes with some complexity, unfortunately, that we try to minimize (but we’re certainly not there yet and it may not be possible to eliminate the confusion completely).

I do have a goal of making Cashculator interaction as fast as possible. I think that it was rather fast in v1 with all the keyboard behaviour there and I try to keep as much of it, like the ability to just start typing a number and hit enter to create a new transaction, as you would do in v1. But the support for more of the old interactions, like using /, * or @ signs is not there yet, although I do think of bringing it in. That being said, these interactions will look familiar to existing v1 customers, like yourself, but unknown or strange to v2 customers, unless explained well. In any case, I think many of them deserve to be brought back so that entering transactions could be more convenient.

I was also planning to have tables (in the monthly view, especially) behave similarly to how they are in Cashculator 1, so that if you don’t enter dates (similar to v1), it still makes sense. Now, this is where this change with precise dates for reconciliation went wrong (for the current month), which caused you to start this topic. And it is a valid point because this change broke this contract of behaving similar to v1 if you don’t enter dates.

I will revert this change, bringing reconciliation back to column-based calculation in the next beta, b5. I’ll try to keep the new (b4, precise dates) behaviour under a hidden preference so that users could switch if they contact support. We’ll see how user sentiment goes. I suspect some groups of people will get confused by either of these approaches but the column-based approach (v1 behaviour) is at least easier to understand by looking at the tables.

Thank you very much for listening and taking care :slight_smile: