AP Batches Are Not Posting

[peterbruce]

JDEList,

AP batches are not posting because of out of balance errors. The automatic entries for the creditors control account are accumulating. This is only happening when the post (R09801) when it is run on the enterprise server. I ran the post locally on the fat admin client and it ran OK and successfully posted the AP batch.

I can see no errors as such in the logs, but I can see when the incorrect amount is appearing.

Has anyone experienced something like this before?

Config:

Oracle JD Edwards EnterpriseOne,
E8.11sp1 8.97.2.1, ES Sun, Oracle DB 10.2, Websphere 6 Win2K3.
Forms: Create!form Server 3/Server 6

 

[peterbruce]

Update - still no resolution.

I thought that there could be a spec difference between the fat client and the server, so I submitted an AP post from the fat client to run on the server - it posted successfully. So we have a situation where the AP post fails when run from the web client. It is only AP batch posts that fail. I re-generated R09801 and the version used for the AP Post, for the web, then restarted the web server. This did not fix the problem. We still cannot post AP batches from the web.

 

[peterbruce]

Update - cause and solution found.

I have confirmed that the cause is a security issue. A change to retrict access to certain cost centres was not applied properly, resulting in the removal of delete action from over half of the the cost centres in the system. We have corrected this with a user who was experiencing the post problem and the problem has disappeared.

 

[Boris G]

Ah, yes. Business Unit security rears its ugly head again.

I've seen something like this once before and it was due to a developer increasing the size of a field via DD. That caused the whole system to become unstable.
Glad you figured it out!

 

[JdeInNJ]

My other thought was a change in users that impacted batch approval/post security.

When you tested to see if the post would run on fat client, you ended up changing one other variable: the user. In hindsight, you should have had the same user try to post from fat client, or you should have had the user who was going to post from fat client post from the web first. It's so nice to be on the hindsight side and have 20/20 vision.

 

[peterbruce]

Brad,

[ QUOTE ]
In hindsight, you should have had the same user try to post from fat client, or you should have had the user who was going to post from fat client post from the web first.

[/ QUOTE ]

This is what we effectively did - sort of by accident. Because the post appeared to work on the fat client, I suggested this to the user as a workaround. When they tried to post from the fat client it failed. I then tried to post from a web client, which was successful. These results triggered my suspicion of a security change, which was confirmed.

 

[JdeInNJ]

Cool. I can't read.

Brad