Hi again Michelle,
Say you have a Sap implementation for order mgmt and manufacturing. You want to create a hub and spoke distribution center at the local FedEx office. In order to do this, FedEx has to set a field in a table (record, whatever) to indicate that this pick released product has actually shipped. While FedEx is implementing this hub and spoke thing, they decide they need to generate a bunch of reports based on hourly pick releases etc.
Let me make sure I am understanding you.
1)Dell wants FedEx to deliver their products.
2)FedEx then acts as a distribution plant/center for Dell.
If so, you are implying that the product is located on FedEx property. So, you are saying Dell does the picking, FedEx picks up the picked product and drops it off at their own plant and awaits shipping instructions.
3)FedEx is responsible for indicating to Dell their product has been shipped.
4)FedEx requires they may need an hourly reporting of pick releases.
5)FedEx does not have R/3, but does have their own oracle DB running Oracle ERP for example.
6)The FedEx guys can connect to Dell/SAP and update fields on the Oracle-level of their system, outside of R/3. (they would be tripping "product shipped" flags and producing picking quieres.
7)This is what you call the old way, back in the Man Man days. Voila!
OK, All this could/would work. Kind of ridiculous in days both present and past R/3, but that is a different topic. Now can you help me here? What point did you want to make with using this scenario?
Im talking about the early days of Sap on the porting stuff... Abap was not devised as a superior alternative to SQL - come on!
ABAP stands for "Advanced Business Applications Programming" language. ABAP does however accept a variation of SQL to maximize the efficiency of the client server network when it comes to finding data. When this variation is used, and the system decides data needs to be taken from the physical DB, the code is transformed into std native SQL and the query is sent off to the DB.
This is why you as a Peoplesoft consultant, knowing std SQL, can just as easily connect to an SAP/Oracle database instance and extract any data you want independent of R/3. Things have been this way since day 1. So now in summary, ABAP/SQL is in supporting the access of volatile data residing in R/3 memory. If the data does not exist there, it is transformed into std SQL and sent off to the DB.
Anyway as I said I dont think at this point this stuff much matters to Sap as an investment. It was an opportunity for Oracle, and they blew it. Sap is a platform in itself now, it doesn't matter what their architecture is.
I still don't understand what point you are trying to make? I engaged you because you said R/3 has a week point with their architecture and Oracle wont capitalize on it. I am still looking at your post hoping to find the week point you are referencing. But honestly, I don't see where you are putting your finger on anything. Could it be a misconception you may have had about the way R/3 really works?
J
|
