We are using Payables 8.1A

Yesterday we had a major problem with our Payables module.

First we had a problem when two small cheque runs were entered into AP and posted (one for CDN and one for USD). Both batches performed as normal (print/post) in AP, but the batch refused to retrieve to the ledger. We were able to clean this up only by deleting the file in our data, reversing the batch in AP, then deleting the second corrupt file that that generated for ledger, and then beginning again.

The second problem occured at posting invoices at day end. A batch was created for yesterday's invoices for all four branches (as we always do, everyone adds to this batch all day, it gets posted at day end.) When we went to post this batch, it said there was an error in the batch, and it left the batch there. At the time I believed that there was something wrong with one of the invoice numbers, and so we amended each invoice in this batch with an "A" at the end of it, and reposted. Again we had the error. At this point, we abandoned the idea of posting this batch, and finished off our day end by retrieving to the ledger and looking over all the reports that were then generated. Turns out that the batch that AP refused to post, had retrieved to the ledger (yes, the same batch that had refused to post, TWICE, because of errors.) Since it had retrieved (twice to the ledger) I went and investigated each vendor affected. Sure enough, the batch posted twice in AP. Yet it was still sitting there in AP looking like an unposted batch.

The only thing we did differently yesterday (than normal) was post batches DURING THE DAY while other users were in AP.

This feels exactly like the problem we had in inventory when multiple users were posting. The same sort of odd error problems.

To test this theory, I took our live AP data this morning and dumped it into our test data. We then made sure TWO people were in the test data, and reposted the batch that was acting so oddly yesterday. The batch posted WITH ERRORS. All invoices except one did post and clear out of this batch this time. One person then exited the batch and tried reposting the left over transaction. No problems this time.

It seems that we are now able to post in AP regardless of how many people are in that module. But we are also getting errors when this happens. I know you are working on a "hot fix" for inventory because of the same type of errors when multiple users are accessing and posting.

Could the same thing be happening in AP? There was an upgrade that we put in the same day we put the upgrade in for inventory...

Barb

Hi, Barb,

The problem you had earlier with IC adjustments is not related to AP at all.

You are able to post batches in AP with more than one user in AP at the time of posting -- depending what the other user(s) is doing. For example, if they have a vendor record open or a batch open (not just the batch list window) and you post, AP will give you an error message telling you why you can't post the batch.

What happens if you open AP sample data and post with more than one user in AP? And, again, if one of those users has another batch open? Have you checked to ensure that opportunistic locking is turned off on all workstations?

Also, check the Tasks path in the data's ADSPROF.xxx file (where 'xxx' is the 3-character extension of the data) and make sure it is pointing to a network drive and not to a local drive.

to answer your question
We do not run from the desktops. Applications are on the server & point correctly. op's locks are off & nothing has changed on our system. Our proceedure on this day did change but prior to the update we had never done this as it was not possible. The two problems are not related by module interaction but the cause is in our opinion the same. this is the "multi user" function added in the last update. please check with the "fix" people & see if this could be the same situation. I know they are working on the IC one now.

Thanks Bruce

Hi Bruce,

Unfortunately, there is little in Barb's post to help us track down any specific issue. What actually happened when the batch "refused to retrieve"? Was there an error message? What did it say? What were people doing in each module at the same time? While we have been working hard in the 9.0 versions to relax th multi-user record locking, I don't believe we made any intentional changes in the AP release in this regard. By any chance, did you make a backup of the data before attempting the post? Was the problem repeatable?

When a batch has errors, the transactions that are not in error are posted, and the error transaction are written to the error batch. It sounds like every transaction failed to post. Is that the case? What was the specific error you had during posting in AP? What about in your test data?

I think we'll need more details to try and track this down.

Are we talking about Payables V8.1A or V8.1B? If this is really V8.1A then something must have changed in your environment to break the multi-user record locking. Verify that two workstations cannot edit the same vendor at the same time.