Again why not giving both options since it’s a decision you make only once in the settings of the default values?
This could be one of the “rabbit holes” @lubos wants to avoid. Users might make a choice without realizing its implications. The fact is, the difference in behavior you write about did not affect any data. Nor does it prevent any action.
Hole? more like a warren
But it implies a lot of extra work in our workflow. We import invoices from european einvoices portal with batch create.
Obviously hey are not linked to the accounts but they are to vat codes and tracking codes. Setting accounts now implies loosing all imported data.
Our import tool has worked for over three years. So it’s clear that something has changed in the way Manager works and in my point of view in a worst way since we have to rewrite by hand most of invoices’ data… and we are talking of about 1.500 invoices each month.
Can you put the accounts into the import file?
Why not? If you are using Batch Create, you can specify the accounts to which transactions are posted. The invoices may not be linked to the account in your chart of accounts when you import them, but nothing keeps you from allocating them during Batch Create, does it? Even if there were some obstacle to identifying posting accounts, that has nothing to do with tax or tracking codes.
How can an invoice coming from an e-invoices portal already be linked to tax and tracking codes in Manager?
Honestly, I don’t see how this has anything to do with tax or tracking codes disappearing when an account or inventory kit is changed after it is entered. The place to attack this problem sounds like it should be the process that assigns the wrong account or item in the first place. If your automated process has worked so well for three years, why do you now need to be editing accounts and items? Surely you are not saying 1500 invoices every month are wrong and need to be changed.
Simply because the eInvoce portal, since it is not an accounting portal but a tax declaration one, doesn’t give you the possibility to choose an account from a drop-down list, a thing that it is obviously is possible for tax and tracking. And than, again, because those who are in charge of creating the invoices are external property guys that don’t have anything to do with our accounting.
Are we taking seriously? Are we starting again from zero this discussion? I have already explained what happens each time one changes the account without setting an optional field, ie he loses all its data entry, a thing that didn’t happen before (and can be easily demonstrated) and that opens up to infinite possibilities of errors.
Sincerely I’ve just explain every single passage of our workflow not to be checked by you, we don’t want and cannot change it, but to show one of the infinite possibilities of error.
A behavior was broken without an evident reason (again non-setting an optional field in IT and in logic is something very different from setting it empty and, again, it is how Manager used to work till versions 21.4.something) and without any notice to the users.
This thing ended up with extra work in our Company which is something contradictory with the evolution of a software which should simplify the way of working and not adding extra steps.
I’ve just asked for a solution to @lubos not for an inquiry on how we work in our Company. Since this new behavior seems so fundamental for you (strange since you didn’t even notice the change before my post!) I have already proposed a solution. Adding the possibility to distinguish “empty” from “unset” under the presets of items/kits/accounts and so on.
Obviously, if it will remain the same we will try to find a solution internally which can be some extra integrations in our plugin (which will cost us extra money for the developer), changing in our workflow or even giving up with Manager since we are getting a little tired of paying server edition to be used as a beta tester of an accounting software.
These were the points I tried to make. We obviously did not communicate well on this issue. It seemed from your earlier post that you were saying you could get this information from the e-invoices. I did not see how that was possible. Now you seem to be confirming my suspicion. My opinion was that, since you cannot get this information from the e-invoices, it would be better to enter the information as part of Batch Create. I was asking why that could not happen.
Yes, we are serious. No, we are not starting from zero. I completely understand your description of what you are doing in Manager, as well as what happens when you do it. I have duplicated your actions in a test business. Everything happens as you say it does.
What I do not understand is why this is a problem for you. Based on what you have written, it seems to me that correct accounts and items, as well as tax and tracking codes, would all be entered during Batch Create. Therefore, no accounts or items would be changed, and no tax or tracking codes would be disappearing. And once the invoices are created, the tax and tracking codes will remain in place. What am I missing?
Sorry for the late answer but I prefered to do some testing. We are something similar to a real estate property company and our current workflow works like this:
our facility managers create the invoices periodically on the e-invoice portal. It is not an accounting software so the only drop-down field that gets data from an external table. Even customers are not a linked table but are filled each time. You can get their data from previously inserted invoices in a way like Manager did once for the payee, ie it searches in the previously created invoices. Apart from tax codes, we were able to link also our tracking codes since they are not so many and we insert them with code in the begining of the header description of the invoice; than our plugin search for them.
we export a csv in pur pluging which combines the table with data from manager: it adds the tax code and the tracking codes and create the table to be imported through batch create
we batch create the invoices and we control/adjust them one by one by adding the client (we import the client name into a custom field and based on that we create/select the client from the dropdown list)
From these updates point 3 has become very difficult since every adjustment delete already imported data… it’s almost like creating the invoices from scratch. Since it seems that this is only our issue (no words by @lubos on this) we are working on a solution to solve every problem at plugin level.
I am sorry, but I still do not understand where, when, or why your problem occurs. Your point #3 says you adjust the client names. How does that cause tax and tracking codes to disappear when you are not changing the posting accounts or items?
Through all of your explanations, I keep coming back to that same question. The disappearance of tax and tracking codes when accounts or items are deleted or edited is real. I do not dispute that. But you have not described anywhere in your workflow that you are doing that. So what are you doing that causes the tax and tracking codes to disappear? Is it something in your plug-in? Or are you taking a manual step you have not described?
Sorry… I wrote it wrong… I mean we adjust Inventory Kits or Accounts
Now I understand. Thank you.
I need to improve how defaults are set on these forms.
Because right now, it’s not clear whether empty tax code or tracking code should be interpreted as default or not.
I didn’t read the entire topic but my understanding is that @Davide wants default values to be switched off for autocomplete purposes. Is that correct?
If not set the default value should not to overwrite (delete) the existing value.
If set “empty” the default value should overwrite the existing value.
If set to a specific value the default value should overwrite the existing value.
Yeah, I agree. I just need to add ability to “not set” default value at all. Because currently you can either have default value empty or set which will always override existing value.
In the latest version (22.6.7)
Instead of having
Tax code field, there is a checkbox instead on account creation screen in
Chart of Accounts.
Only if checkbox is checked can be tax code selected.
This means tax code auto-selection after selecting an account on transactions is turned off by default.