PO Authorization Limits - Which SQL Tables?

[Former Member]

Dear All - I'm fairly new to forums - so firstly let me apologise if this message has gone into the wrong section. I am primarily seeking information about SAP SQL tables.

I have been asked to analyse PO's raised by employees over a period of time. The business wants to assess how often authorization limits (spending) are breached by employees splitting invoices against the same supplier.

I am using Intellicorp's 'Live Compare' product to extract data from the SQL Server database. Whilst I am well versed with PO header and detail EKKO and EKPO - I am ignorant of which SQL tables I need to establish PO authorisation limits for a user. I have spent a lot of time trying to find information without success. I've also used DD02 and DD03 to try to establish the relationships but without success. Can anyone help?

Most resources I've found speak in terms of authorisation profiles (configuration) but I don't have access to the SAP front end, as the external auditor I can only see the SQL data. My goal would be to automate the extraction of PO value authorisation limits. But first I need to understand the table structure. If anyone can point me in the right direction, I would be grateful.

I've found one other post - a person seeking the exact same information but to date he's had no reply. This gentleman has raised his query in governance, risk and compliance.

If I get a reply - I will make sure he receives it also.

Many thanks for reading my post.

[lbreddemann]

> Most resources I've found speak in terms of authorisation profiles (configuration) but I don't have access to the SAP front end, as the external auditor I can only see the SQL data. My goal would be to automate the extraction of PO value authorisation limits. But first I need to understand the table structure. If anyone can point me in the right direction, I would be grateful.

Ehem... what kind of external auditor works on basic data structures like database tables?

See, EVERYTHING that adds semantics and meaning to the data that is spread across the tables, is the APPLICATION.

You could just use a hexeditor as as well to access the database files without the database software.

Would be exactly the same.

So I propose you get a valid user to access the data you need.

Everything else would be a breach of all compliance regulations that are out there.

regards,

Lars

[Former Member]

Lars,

Many thanks for the comment - I sensed a sceptical man there I know the word auditor conjures up a terrible images of people asking how long your password is and so on but I'm not one of those I'm glad to say. We do specialist data work - like reveue reperformance and continuous controls monitoring. I regularly work with datasets of 50m+ records from Oracle, SQL Server. I do all my analysis and modelling in SQL Server.

In answer to your question though, many auditors internal and external use database extracts for analytics and detailed analysis - it's very common. Auditors call it CAATs (Computer Assisted Audit Techiques). For example, if I were to be looking to analyse duplicate invoices for a client (not an audit test granted) I might take an extract of all the Invoice table and run fuzzy matching criteria on the PO reference or the Vendor Name. It is extremely effective and the only way to get 100% coverage. Sitting with a user would in no way give me the data I need, as in this case there are several different users and the objective would be to recover money for the client. Don't be alarmed, this isn't in breach of compliance regulations. The data isn't changed or manipulated in any way, only analysed outside of the production environment like a report.

I do appreciate that the application gives the context to the data - but with a technical manual and a bit of help from the client we would normally be able to extract what is required from the database and use it to discover things about the system that could not be discovered in most other ways - in this case I'm only looking to find the table(s) and relationships which would allow me to determine the users PO authorisation limits. At the moment, I've not been able to find anything that is detailed enough to help me in this regard. Maybe this information just isn't available but it's principally why I'm posting.

I have to say that I've only once had to resort to viewing data with a Hexeditor, I believe that data was extracted from an IBM mainframe.

[lbreddemann]

> I might take an extract of all the Invoice table and run fuzzy matching criteria on the PO reference or the Vendor Name. It is extremely effective and the only way to get 100% coverage. Sitting with a user would in no way give me the data I need, as in this case there are several different users and the objective would be to recover money for the client. Don't be alarmed, this isn't in breach of compliance regulations. The data isn't changed or manipulated in any way, only analysed outside of the production environment like a report.

Hmm... then why won't you just do it in a proper ABAP report?

Everything you asked for is there. The full data access, the data dictionary.

You wouldn't have to "sit with the users" - I clearly wasn't talking about using the standard front-end tools

Still - the far I've been in touch with getting systems "audit proove" it was all about ensuring that nobody could possibly change the data unnoticed.

So to me it just looks like a big fat security whole to say: "Ok, for the auditors we let go all of the permission and technical auditing stuff and just hand them over all data".

And that would be exactly what you do when you access the tables directly.

One example: say, there is production data of multiple clients in a ERP system.

You're working just for one of them...

So how can you guarantee that you cannot access the other clients data (besides promising no to do that)?

> I do appreciate that the application gives the context to the data - but with a technical manual and a bit of help from the client we would normally be able to extract what is required from the database and use it to discover things about the system that could not be discovered in most other ways - in this case I'm only looking to find the table(s) and relationships which would allow me to determine the users PO authorisation limits. At the moment, I've not been able to find anything that is detailed enough to help me in this regard. Maybe this information just isn't available but it's principally why I'm posting.

This information is available.

The ABAP stack is a open source system - you can view all coding and data definitions if you like.

Since I'm no application expert, I cannot tell you whether there are already reports doing what you want to do, but I would be surprised if there weren't any.

So maybe you want to post this question in the application forum instead?

regards,

Lars

[Former Member]

Lars,

Appreciate your time in responding.

You're right of course, ABAP reports may well provide the information - I'll look into that. I suppose the main reason for doing it this way is the fact that the tool performs continuous auditing - so some reports may be run daily, some weekly, and others monthly. The Live Compare product allows us to do this quite easily, with audit trail, interface with SQL, and automated reporting. Normally, the client would be free to provide the data extracts in any way they saw fit.

I can understand your concerns re: security. The truth of the matter is for a lot of what we do we couldn't work by directly accessing the production system. It would put day to day operations at risk. The data is extracted at quiet times, and worked on away from the production environment to avoid performance issues. I can imagine the gasps if I said I had to work on the production database.

Could the data be at risk? Yes, I suppose some unscrupulous person might take advantage - but auditors are fairly privileged with the information they are given anyway and precautions are taken. There is also the weight of the law sitting with the client, including the threat of loss of licence for the auditor if things go wrong. But for the most part, it wouldn't be in the interests of the audit to abuse the client's data but I do accept your point.

I have been in situations were multiple entities have been sitting within the same financial application - not SAP though. In that situation the data would need to be filtered with selection criteria. Chinese walls are fairly common I would say. But the transverse is also true. Global clients often have many instances of SAP. The Live Compare product gives us the ability to run tests accross multiple instances of SAP, or to examine the differences between systems. It's a powerful tool.

Thanks for the advice - I will try the application forum.

Best regards,

Ian

Edited by: TotalSAP on Sep 16, 2009 3:38 PM