Optional payee data entry

[pvphome]

Hello
For a long time I used the old version of the application, 2019 year or such. Now I switched to the new one and found an annoying innovation: now when entering transaction data, you must enter the payee.
This adds an action to each transaction that the user does not necessarily need. I think I'm not the only one who only needs to specify the category to control expenses (that's why the first payee I added was "Never mind" :) ).
Therefore, a request: please make entering the payee optional. Perhaps this is a good feature, but forcing the user to use it is inhumane. :)

P.S. I translated the rest of the lines not translated into Russian on Crowdin and corrected several errors in the translation. Please take a look.

[guanlisheng]

hi @pvphome, thanks for the translation for Russian

you need to set payee once time as default, please refer to #1634

Settings -> General -> Default Payee

[pvphome]

@guanlisheng
This scenario only works if you do not use payees at all. But I have a limited list of them, the choice of payee is a way to specify a category. This list includes the most common payees, it is much shorter than the list of categories, and the category itself has to be entered much less often.
The method with a single payee by default leads to the fact that the category will always have to be entered, and this will increase the time for entering all transactions, and not just rare ones.

[guanlisheng]

you want to decouple the connection between the payee and the category.

can you share more detailed cases on how to enter your transactions?

@vomikan here who is also from Russian.

[pvphome]

@guanlisheng
If you select "no" in the last payee settings, the payee and category fields are empty when creating a transaction. If you select a payee, the program substitutes the category that was used in the last transaction with this payee. That is, you can create a list of frequent payees and use it to substitute frequent categories.
At the same time, quite often you have to enter transactions that are not related to a specific payee. When entering a payee was optional, this was not a problem, I just selected the category separately. But now it has been made mandatory. Of course, I can make a "fictitious" payee just to select it and substitute the desired category, but this will be somehow inaccurate. :)
If you select substitution of the last payee in the settings, when creating a transaction the program substitutes the values ​​​​in the payee and category fields that were used in the previous transaction. When changing a payee, the transaction category does not change and vice versa. That is, the described method with a short list of payees stops working.

[guanlisheng]

ok, it is not to substitute anything as both payee and category are independent entities in MMEX.

When creating a new transaction, mmex first tries to guess the possible payee and category. and the continued editing will be left to users. for guess methodology or algo, the category does rely on the payee guessed earlier.
hence, it does not substitute any thing, might be some misunderstanding

in your case, it is expected and the following transaction would take advantage of the updated payee -> category linkage.

[pvphome]

@guanlisheng

Yes, I may have expressed myself incorrectly, sorry. English is not my native language.

1. My example is a special case. The general case I started with: not all users need payee tracking, for various reasons. Why force the user to enter it?
2. In my example, I described how to enter a limited list of frequent categories using a limited list of payees. To enter a transaction with which the counterparty is not associated, I can create a "fictitious" payee and enter a category for it separately. At the beginning of the discussion, you recommended me to "set payee once time as default".
   But in both cases, we create a non-existent payee simply to bypass the program limitation. So wouldn't it be easier to remove the limitation itself?

[guanlisheng]

hi @pvphome
No.1 understood. it is mandatory in MMEX while there is an option to set it as Last Used to mitigate it.
No.2 I believe you can feel it is not easy, and it is MMEX's design philosophy and data models.

it should be affordable to just set up a default dummy payee to pass by some rules. this is also a common workaround in the real world.

[scaidermern]

Same for me. I used the 2019 version for a long time, mostly without a payee. Now I can't do that any longer. However, my old transactions (spanning many years) are still there. Since now I have to specify a payee, some payee-specific reports will show wrong results.

[guanlisheng]

yes, this rule was introduced early this year. per #1589

a default payee would mitigate most of them, the only thing in this thread is the category though you always need to assign a category

[scaidermern]

I don't mind assigning a payee and a category. But I can't find anything to migrate/fix my old entries so that all the reports are useful again.

[guanlisheng]

Historical data migration is an issue as there is no tool in handy for batch update.

How many transactions do you have per month? We may need to consider a batch update function for such case.

[scaidermern]

How many transactions do you have per month? We may need to consider a batch update function for such case.

About 1-2 per day.

[guanlisheng]

thank you, We will consider a batch update function in the future.