I have a question for @lubos about the logic behind the new “shared” custom fields.
Let’s take for example a Customer and a Sale Invoice. I create a Custom Field shared between the two. If I fill the field both in Customer and then in the transaction (the invoice) which will have the priority?
In which context?
There is no “priority” logic and to my knowledge there doesn’t have to be. Even in the upcoming implementation of custom reports, you will have to choose whether you are filtering by custom field defined on sales invoice level or customer level.
But in this logic is like having completely distinct custom fields like before.
At least at transaction level they should be in the same column.
For example sales invoices, credit notes, purchase invoices, debit notes, journal entries should have the same custom field jn the same column like a tracking code, a project code, a tax code in order to make a proper query.
And they do.
For example, if you want list of transactions where certain custom field
XXX has value
YYY, then you will be able to get that across all transaction types. That’s the idea (among others) behind shared custom fields.
You need to wait for new implementation of custom reports to see how it’s all going to be working out.
Thanks. That’s what I wanted to know. One last clarification.
How are you going to handle the same custom field at header level and at line level of the same transaction type?
Just wait for new implementation of custom reports. The current implementation is very much about general ledger only. New implementation is approaching custom reports from completely different angle which I think will be more logical, more intuitive and easier to use for everyone.
A lot of issues that I was struggling with in current implementation are basically non-issues in new implementation.
You are looking at current implementation and trying to understand how shared custom fields fit that paradigm. There is no need for that because new implementation is different paradigm.