Client Concept within SAP

[Rima]

Hi all,

I remember that many, many years ago I learned that "clients" within an SAP system are used to legally separate different companies from each other.

But not so many years later, I read that since within SAP there are quite a few Cross-Client Business Customizing tables (-> Factory Calendar, Plant Tables and the like), that those "business" can only be logically separate, not legally.

Now the issue has arisen where the claim is made that you can store the data from completely unrelated companies in one SAP system, not while e.g. doing accounting for them, but e.g. while only being their Application Server Provider.

So in essence these companies would "do as they please" in their respective clients and no harm would come out of it.

Now I am very sure that I read somewhere that such a setup is not possible and/or in some countries even illegal.
That you can store different subsidiaries, sub-divisions or even partnerships within the same SAP system, but not have totally unrelated corporations (maybe even from different countries) use the same SAP system, just separated by client # from each other (because of those Cross Client Customizing Settings).

Is there any OSS Note dealing with this?
I tried to Google for something definite, but could only come up with the very unspecific 31557.

Thanks for any enlightenment on this subject.

Rima.

[SAPMM]

Now, I am not a FI-person or anybody who knows about legal implications (much) - but: if you were to host several (independent, in different countries located ...) companies on the same system, but in different clients - I would very much wonder how that could be accomplished - e. g.:

Different countries have different country versions, some of which contain repository objects = cross client affecting things, meaning in said imagined system you'd have all country versions, all add-ons, all industry solutions, all languages of all customers that 'inhabit' separate clients? and no software-conflicts at all?

How'd you deal with upgrades or support packages or note-corrections that one client wants, but all the others refuse?

How'd you deal with downtimes (in case of daylight saving)? shut down all companies whilst ... whilst doing what exactly? you'd have one system, right? so one time one the server, right? so all posting goes with server time - and all customers suffer that time? I'd understand that for cross-company processes, where one of the daughter companies has to use whatever 'mother' dictates - but with independent companies?

What maintenance window(s) would you have?

Imagine, all of those companies would like to do IDOCing to various other systems ... that'll be intransparent as hell, having the same SID, but different clients - still, it would work ...

Of course, there would not be any of those convenient settings for the instance parameters as:

individual passwort lenght/expiry date
pre-allocated values for the logon client
customer individual system messages (SE61)
... and there would be noooo customising/development ... SAP standard it is ...



I think it possible, not very likely... really. But possible. Maybe the most expensive ASP you ever came across

[Rima]

What about the issue of Native SQL statements (bypassing the client limitation of SQL queries & updates)?

I know that e.g. in Germany it is not legal to store the data from two separate business entities within the same system if there is not a 100% guarantee that they will stay separate.
But with Native SQL cmds, one can bypass the client limitations within the SAP system, and since even in a schema driven DB, all tables from the same SAP system could be accessed this way, I wonder if such a setup could possible pass that legal test...

PS: Thnx for the reply so far. This issue is kind of important, because the discussion here goes about the number of system you would need for any specific number of customers.

[SAPMM]

Native SQL cannot be an issue here - access to the database is usuallly for admins only and if they were to abuse that, there'd be no more hosting companies. as it is, there are -even in Germany- so I think we can rule that one out.

Native SQL from Abap ... well, obviously in such a system landscape, none of the UserIDs of the clients can have development access - for reasons that such access could ruin functionality for the other clients. Again, development access would go to the admins only, which makes it kinda 'secure'.

That would leave queries (forbidden, then), debugging, execution of OS-commands (SM49/69) and -of course- user-administration - can't have the clients administrate their own users, can we now? Would enable access to SAP_ALL which brings the SQL-debugging-developing issue up again, so whoever is the admin has to do user-administration of all clients (and get paid for it - hopefully).

which brings us next to audits. who is going to give the thumbs-up to the setup? who would risk such a thing. I think, Al can help us here - I'm going to point this thread out to him.

Cheers,
SAPMM.

[Rima]

I think indeed the whole issue can the boiled down to this question:
Could such a (productive) system pass a legal audit in e.g. Germany, specially if there would be no such guarantees for "customer cooperation" in place as you have listed?
Meaning, the customers would still perform their own customizing (including User Master Records), would still have access to all transactions (only excluding absolute Basic TAs like DB13, RZ10 and such) and would still be doing development and/or debugging of their own.
The whole thing would just be a classical Application Hosting Scenario, where everything above Operating System level is the customer's own concern.

I am sure that with 1000+1 cooperation agreements in place between all parties, that you could pull of such a configuration.
But the issue here is if this could be (legally)implemented as a real world scenario under a plain, straight forward ASP agreement?

I just don't think that the separation by client alone would provide sufficient enough isolation for each company's ongoing business processes.
Now there must be some sort of rule or legal standard for this in countries like Germany (they even regulate the shape of their bananas).

[SAPMM]

you are asking specifically for Germany, aren't you?

ASP service providing contracts are (as of 2007) 'rental agreements' which outlines that the contracting parties have to define everything they want to be part of the agreement by themselves and put it in the contract. there's no 'laws' or regulations of that - more like guidelines - FWIW here's some German Sites:

http://www.itmittelstand.de/startseite/ ... ?tx_ttnews[pS]=1249665746&cHash=6713d6f297
http://www.recht-freundlich.de/download/Asp.pdf
http://www.openpr.de/news/115552/Der-Bu ... -sind.html

[Rima]

So the rule is there are no rules?
That is double weird, as it basically means that even sap totally independent customers couldn't be clearly kept separate in their SAP client, such a setup would still pass an accounting audit even in a bean counter country like Germany?!

Hard for me to believe that this is possible...

[Portal]

He He, this area is quite open for interpretation at the moment and is more related to tax law than the audit areas that I am involved in.

Rima - from a financial accounting perspective there is no reason why this can't pass an audit. A company code often represents a legal entity and could potentially be the entire scope of an audit. What is important is that there are adequate processes and controls in place to be able to place reliance on the figures produced by SAP.

As a bit of background, there are a growing number of organisations in Europe who have centralised operations in European countries who have relatively low levels of tax on profits. Legally, they need to prove that the central company takes the risk and therefore should take the profit (and benefit from the lower tax rate). An offshoot of that is that the overseas subsidiaries are in many cases required to be dealt with as completely separate operations.

As an example of where this can relate to SAP is that people in these subsidiaries (could be a manufacturing plant for example) cannot see data relating to the central organisation that other unrelated external companies would not be able to see. It is a massive departure from the standard data sharing principles that ERP's are supposed to promote.

At the moment there are a fair number of companies running this setup and I can only see it increasing. From this perspective, yes it can be legal but there are big caveats (like those Fish has already pointed out). Furthermore, the companies who are running "different" companies on a single client are sharing config. From an operational point of view, it would be a nightmare to have different config per client, especially as you cannot guarantee that all the config will be client dependent.

Lastly, I think this is the first time I have said this on SF, but anyone even vaguely considering this should take professional legal advice in the related jurisdictions!