By using this website, you agree to our Terms of Use (click here)
I created a Reference Nbr. filter on Bills and Adjustments to hide our conversion data. This was made public and default. Then, surprisingly, discovered that Cheques and Payments had the same filter resulting in by default, all data being hidden by my filter. These are different tables with different numbering sequences so making them both share the same filters makes no sense at all.
Our hopeless Partner tells us this is a "feature" as the 2 pages are "related". This response makes no sense but they are refusing to log a bug with MYOB.
If anyone could spare a few minutes to verify the issue (just create a filter on Bills and Adjustments and then go to Cheques and Payments and you will see your filter) and then perhaps log it with Acumatica support I would be really grateful! Unfortunately, down in Australia we don't have a direct line to MYOB and have to go through a partner. Acumatica also don't want to talk to us.
Hi Royce,
Are you adding a filter to the initial inquiry that you see when you go to the Bill and Adjustments (AP3010PL) screen like this?
Or do you mean adding a filter to the magnifying glass lookup in the Reference Nbr. field on the Bills and Adjustments (AP301000) screen like this?
Maybe it's because you Australians spell Cheque incorrectly 🙂
Just kidding. I see what you mean now. I reproduced this on Acumatica 18.200.0075.
f I go to the Bills and Adjustments (AP301000) screen, set a filter on the Reference Nbr. lookup field, and mark the filter as Default and Shared like this:
Everything is great. But then I go to the Checks and Payments (AP3020000) screen and the filter appears there as well which I totally wasn't expecting:
I submitted this as a bug. Let's see what Acumatica says.
Thank you so much Tim for this!! I hit a brick wall trying to get our MYOB Advanced Partner that this was definitely not a feature.
Lets hope Acumatica will acknowledge the issue and in a year or so we finally get the update!
ps. Who the hell still uses Cheques/Checks anyway? You guys need to start using EFT!! 🙂
It looks like it might be any "shared" selector. I get the same behavior applying the filter in Stock Items and then looking into Non-Stock Items when selecting the Inventory ID.
Actually stock items and non-stock items makes perfect sense as they have common numbering sequences. Bills and adjustments, Chequers and payments do not have common numbering sequences so it doesn’t make sense.
Seriously, tell me about it. We have the same problem on the Invoice side. At the last Acumatica Summit my team did a project on Accounts Payable Invoice scanning where you can scan the paper copies of invoices more easily into Acumatica. We had a few people on our team from Ecuador and they were confused why anyone would even care about such a solution because in Ecuador everything is electronic. They must have been thinking, "those backward Americans." 🙂
Ok, so I heard back on my support case. Looks like this is by design.
So I created an idea that we can all vote on to change the design:
https://feedback.acumatica.com/ideas/ACU-I-1794
I got the same response from our MYOB partner. I can't see the logic in Acumatica's stance on this. They are different tables with different numbering sequences and the filter is on the field with the numbering sequence. Argh!!!
I have added my Vote.
Bummer. This is a situation where the Acumatica application is trying to be "too smart" in my opinion.
I want to explain a bit technical background of the problem. Those entities: Payment and Invoice are related. On the top level they live in different tables: APPayment and APInvoice. But if to go deeper, both of them have the same parent table: APRegister. Your problem arises because filtering is added on the level of table APRegister, which is base table for APPayment and APInvoice as well as for APQuickCheck.
On UML diagram it looks like this:
Nice theory, but it is flawed. If that was the issue, then Quick Checks would also share filters with Bills and Adjustments and Checks and Payments, but it does not. Anyway suggesting that they all have a common key in APRegister and therefore should share filters on the Reference Nbr field doesn't make sense when you consider that they all have different number sequences. If they had common keys, then you could get key violations if the same number was applied to 2 APRegister records from different sources (DocTypes). This implies that they need to have composite key of DocType and RefNbr, which is what they have. Therefore the key values (RefNbr) are unique for different DocType values and once again common filter makes no sense at all.
Hey, Royce Lithgo,
I added some code on mine dev instance and I'd like to invite you to check if split at mine test instance is something that you'd like to get:
https://173.212.243.48/Avocados/(W(3))/Main?ScreenId=AP302000
https://173.212.243.48/Avocados/(W(3))/Main?ScreenId=AP301000
user name: admin
password: @royce-lithgo
In case if yes, I'll provide instructions how to get it on your instance.
I have self signed SSL certificate, so ignore warning message of your browser.
Hey Juriy,
I really appreciate the effort you went to coding a customisation, but I'm really against customising to fix issues in base product. Plus I'm not overfly thrilled about the change to the Reference Nbr field label, although I imagine that could be fixed.
Royce, I can't understand, you need such splitting functionality in Invoice and bill or you just want to understand why Acumatica didn't split it in base product?
Online Members
