By using this website, you agree to our Terms of Use (click here)
I have that my first post has to be a panic post, but oh well.
We go live (2023r1, 23.110.0025) next Tuesday, moving from a different ERP. Most everything is in place; users are (as users do) continuing to find new things that nobody knew about that they're saying are business critical, but I'm past trying to deal with any of those things. I'm down to two business critical issues, both of which I'm relying on third parties for. I'm not going to mention third party names since I don't know for sure the rules about that, but don't get me started on how all of the third party relationships have come to be my biggest pain point in our Acumatica migration.
One of those mission critical items is our Lockbox processing; we picked up a module in the marketplace that appears to handle everything we need. Started working with the vendor back in August; they installed their code, I provided sample data, all the usual. They delayed until almost November to tell me our bank file format wasn't compatible. That started scramble #1, dealing with a major bank to update the file format we use for our lockbox downloads. Got that in place in early December, ran into a strange error when processing and the Lockbox VAR started looking into it. Last week (noticing a pattern?) they tell me that the issue is because our Check payment type isn't defaulting the cash account.
So this is where I actually ask a question. We confirmed--if we enter a payment using any payment method, the cash account does not default. It's setup properly, and I've tried it at every level (first setting up just the default for the payment method, then doing it to a branch level with a branch specific cash account, and finally going to a customer specific setup of the CHECK type with the branch specific cash account for that customer defined). Our implementation VAR tried it on a couple of their 2023R1 tenants, and they say the same thing occurs. The lockbox VAR swears it works, and then wound up telling me that the customer they thought was on 2023R1 recently moved to 2023R2 and so they're not sure.
I spoke with a guy at Acumatica (we also run the Fortis AcumactiaPayments module--which I have tried unpublishing just in case...no change in the cash account selection) and he went right into the code (I didn't ask about the specific build he was looking at) and said that everything looked like it should default. So those of you on 2023R1, can you tell me if your cash account defaults when you select a payment method? If so, how you're default is setup (system, branch, customer specific, etc.)?
What build number are you upgrading to?
I agree, 3rd parties are always the biggest headache with upgrades.
No need to fear mentioning 3rd party names on here. It doesn't bother me. I like transparency.
We're not live on Acumatica yet (we run a totally different ERP today), and we're going live on 23.110.0025 unless I wind up feeling like a rush upgrade to one of the two newer builds is justified.
@timrodman That's in 23.110.0025. But we've found a little more information, too.
The actual culprit seems to be Acumatica Payments. Since we're on the version before it was put into standard, we have a the AcumaticaPayments customization. I had tried uninstalling it once and the issue was still there, but at the request of our VAR I unpublished *everything* and then republished everything except Acupay. The default cash account worked after that. I found that the issue occurs after version 1.0.8 of Acupay; I rolled back to 1.0.8 and the default cash account works for all payment types.
I've already got an updated customization that's supposed to fix it. I haven't had time to test it yet (I figure we can limp along with the older version until I do). I emailed the dev I mentioned in the first post after I discovered this (on Thursday), and by Friday he had the updated code in my email.
Ah, that makes sense. Acumatica Payments is pretty new.