DIFFERENCE BETWEEN PSA & IDOc

Hello Friends,
Please provide details between PSA& IDOc .
With regards
YADAV.T.TT

Dear Thukaram,
The following update types are available in SAP BW:
1. PSA
2. ALE (data IDoc)
You determine the PSA or IDoc transfer method in the transfer rule maintenance screen. The process for loading the data for both transfer methods is triggered by a request IDoc to the source system. Info IDocs are used in both transfer methods. Info IDocs are transferred exclusively using ALE
A data IDoc consists of a control record, a data record, and a status record The control record contains, for example, administrative information such as the receiver, the sender, and the client. The status record describes the status of the IDoc, for example, "Processed". If you use the PSA for data extraction, you benefit from increased flexiblity (treatment of incorrect data records). Since you are storing the data temporarily in the PSA before updating it in to the data targets, you can check the data and change it if necessary. Unlike a data request with IDocs, the PSA gives you various options for additional data updates into data targets:
InfoObject/Data Target Only - This option means that the PSA is not used as a temporary store. You choose this update type if you do not want to check the source system data for consistency and accuracy, or you have already checked this yourself and are sure that you no longer require this data since you are not going to change the structure of the data target again.
PSA and InfoObject/Data Target in Parallel (Package by Package) - BW receives the data from the source system, writes the data to the PSA and at the same time starts the update into the relevant data targets. Therefore, this method has the best performance.
The parallel update is described in detail in the following: A dialog process is started by data package, in which the data of this package is writtein into the PSA table. If the data is posted successfully into the PSA table, the system releases a second, parallel dialog process that writes the data to the data targets. In this dialog process the transfer rules for the data records of the data package are applied, that data is transferred to the communcation structure, and then written to the data targets. The first dialog process (data posting into the PSA) confirms in the source system that is it completed and the source system sends a new data package to BW while the second dialog process is still updating the data into the data targets.
The parallelism relates to the data packages, that is, the system writes the data packages into the PSA table and into the data targets in parallel. Caution: The maximum number of processes setin the source system in customizing for the extractors does not restrict the number of processes in BW. Therefore, BW can require many dialog processes for the load process. Ensure that there are enough dialog processes available in the BW system. If there are not enough processes on the system side, errors occur. Therefore, this method is the least recommended.
PSA and then into InfoObject/Data Targets (Package by Package) - Updates data in series into the PSA table and into the data targets by data package. The system starts one process that writes the data packages into the PSA table. Once the data is posted successfuly into the PSA table, it is then written to the data targets in the same dialog process. Updating in series gives you more control over the overall data flow when compared to parallel data transfer since there is only one process per data package in BW. In the BW system the maximum number of dialog process required for each data request corresponds to the setting that you made in customizing for the extractors in the control parameter maintenance screen. In contrast to the parallel update, the system confirms that the process is completed only after the data has been updated into the PSA and also into the data targets for the first data package.
Only PSA - The data is not posted further from the PSA table immediately. It is useful to transfer the data only into the PSA table if you want to check its accuracy and consistency and, if necessary, modify the data. You then have the following options for updating data from the PSA table:
Automatic update - In order to update the data automatically in the relevant data target after all data packages are in the PSA table and updated successfully there, in the scheduler when you schedule the InfoPackage, choose Update Subsequently in Data Targets on the Processing tab page.
Do let me know in case of any queries.
Hope this helps you.
Regards,
Rakesh

Similar Messages

Principal difference between an Idoc and a Switch document.

Hello
what is the principal difference between an Idoc and a Switch document.
Thanks

Hi,
A switch document documents a process, such as, switch of supplier, in a liberalized market and can be monitored with own transactions. The process steps are usually controlled by workflows.
An IDoc is used to transfer data from one system to another one in a predefined package. When you import an IDoc containing a market message, a workflow can be started creating/updating switch documents.
Kind regards,
Fritz

Difference between Master Idoc and Communication Idoc.

Can anyone list out the difference between Master Idoc and Communication Idoc?

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. IDocs are used for asynchronous transactions: each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.
Form and content: IDoc terminology
As is often the case with proprietary technologies, SAP assigns specific, object-oriented meanings to familiar terms. When referring to IDocs, the term document refers to a set of data comprising a functional group of records with a business identity. (For example, all the data in a purchase order, or all the profile information of a supplier in a supplier master record.)
A message refers to the contents of a specific implementation of an IDoc; its a logical reference. This differs from a reference to the IDoc itself, which specifies the messages physical representation. Think of it this way: If youre watching a parade pass by, the mayor waving to the crowd from his limousine is the message, and the mayors limousine (which is specific to the mayor) is the IDoc. Youre building a logical object, and the IDoc is both its container and the vehicle that moves it.
The IDoc control record
Each IDoc has a single control record, always the first record in the set. The structure of this record describes the content of the data records that will follow and provides administrative information, such as the IDocs functional category (Message Type/IDoc Type), as well as its origin (Sender) and destination (Receiver) as in conventional EDI
Layout of an IDoc control record
This cover slip format informs the receiving system of the IDocs purpose, and the receiving system uses it to determine the correct processing algorithm for handling the arriving IDoc.
Data records
The data records following the control record are structured alike, including two sections: a segment information section and a data section.
In the first part of a data record, the segment information section describes the structure of the data that follows, for the benefit of the IDoc processor. There is a segment name (like an EDI segment identifier) that corresponds to a data dictionary structure to which the IDoc processor has access. The remaining information is useful for foreign systems, such as a partner companys Oracle system, which has no such data dictionary.
The second part of the record is the data itself, a storage area of 1,000 characters.
Status records
If youve ever ordered a package from a faraway location and tracked its progress using the Internet-based tracking utilities now provided by most major parcel carriers, youre familiar with the list of stops and transfer points through which a package passes on its way to you.
This collection of records is exactly what youll see in an IDoc that has begun its work. Following the data records in an IDoc, status records accumulate as an IDoc makes its way from one point in a process to another.
Typically, an IDoc will acquire several of these records as its does its job. They are simple records, consisting of a status code (there are more than 70 codes, covering a broad range of conditions and errors), a date/time stamp, and some additional status information fields for system audit purposes. In addition, as errors occur in the processing of an IDoc, status records are used to record these errors and the date/time of their occurrence.
IDoc Base
IDocs, as data formatting tools, enable the easy sharing of data between databases and applications within a company as well as being an efficient data courier between companies. Typically in SAP, a database of IDoc definitions exists, to which any application may have access.
This IDoc Base gives all the applications and processes in your company domain the capacity to send, receive, and process a document in a contextually appropriate way, without doing anything to the data. For example, a purchase order IDoc can filter through every process it touches, passing from system to system, accumulating status records to track its progress.
Every department using the data can use it appropriately without any cumbersome intermediate processes, because each department draws its key to interpreting the IDoc from the same source.
Multiple messages
One cumbersome feature of conventional EDI is the embedding of more than one functional record type in a document. The unwieldy X-12 888 Item Maintenance transaction set is an example: It purports to handle so many different configurations of product master data that it is horrifically difficult to integrate into an existing system.
IDocs, on the other hand, handle multiple messages with ease. Given the centralized IDoc interpretation that SAP provides to all its parts, its no problem to define an IDoc that will contain more than one message, that is, more than one data record type.
A customer master IDoc, for example, may contain customer profile information records for a customer with many locations. But it may also contain location-specific pricing information records for that customer in the same document. This is an incredibly efficient way of bundling related records, particularly when passing large amounts of complex information from system to system Records in a multiple-message IDoc

,difference between PSA 3.5 and PSA BI-7

Hi,
Please some one tell me the difference between PSA 3.5 and PSA BI-7 , Actually i searched in the forum also but i didn't get difference but i could find the other Datasorce .... etc differences.
Thanks,
GAL
Edited by: GAL BI on Feb 5, 2009 8:45 PM

Hi,
There is no difference technically as it still remains the flat table structure as it was in 3.5
The kind of partitions and way it was organised in the system is still the same.
Its just that the way it is used now has been changed from 3.5 and again I will give you the same answer of data source.
Now it has been made mandatory to load the data from R/3 first to PSA and then further to the targets.
This PSA has no difference from the PSA in the 3.5 as the deifintion persistence staging area can be given to any table which stores the data in as it is form....and in 7.0 they are doing the same role which they were doing in 3.5 that is storing data as it is.
Now the PSA has become data source specific and not target specific as it was in 3.5.
now the data source in 7.0 are having the PSA and will come into play only when the object will be used as data source for futher updates whereas in 3.5 it was more like a target which use to have a kind of PSA attached to it since the PSA used to have a structure same as transfer structure which was possible to change.
Hope I am clear.
Thanks
Ajeet

Difference between CREMDM04 Idoc and CREMAS04 Idoc

Hi all,
I am creating a vendor using an idoc CREMAS04.
But there are some fields which are not there in that IDOC (fields like Email address , POBOX number for other country) so i want to know that is there any other IDOC which contains all the fields for the vendor creation.
I have found the IDOC CREMDM04 which contains those fields but i want to know the difference between the CREMDM04 and CREMAS04.
I also want to know that will it make any difference is i use CREMDM04 instead of CREMAS04(like is it that all the fields of CREMAS04 is there in CREMDM04 or no).
If anybody knows ,then please let me know.
Thanks in advance.
Shruti.

to name a few:
CREMAS01 Vendor master data distribution ALE
CREMAS02 Vendor master data distribution ALE
CREMAS03 Vendor master data distribution
CREMAS04 Vendor master data distribution
CREMDM01 MDM: Mass Processing CREMAS (Vendor Master)
CREMDM02 MDM: Mass Processing CREMAS (Vendor Master + Addresses)
CREMDM03 MDM: Mass Processing CREMAS (Vendor Master + Addresses)
CREMDM04 MDM: Mass Processing CREMAS (Vendor Master + Addresses)

Data difference between PSA/Query and InfoCube

Hi All!
I have a problem during the data extraction from R/3 to a basic Cube. When the currency is different from EUR, the key figure 0CS_YTD_TC data its different from the others (0CS_YTD_GC and 0CS_YTD_LC). In the cube content the value is correct but in the PSA and in queries is not.
What can I do?

Ricardo,
Do you mean that one of your KF value (for example, in the cube) differs from the value shown in a query 10 times?
If so, look at the table TCURX. In my system PTE has 0 decimals. It means that cube/query will differ 100 times.
Look here at the problem description:
Re: Local Currency COP, KRW values wrong in report
and here for workaround on a query level:
Re: is conditional calculation in the report possible?
Best regards,
Eugene

Difference between two fixed asset idoc

Hi Gurus,
can anyone explain me whats the difference between the idocs u2018FIXEDASSET_CREATEFROMDATA102' and u201CFIXEDASSET_CREATEINCLVALUES02u201D.
I have an scenario where i was asked to use u2018FIXEDASSET_CREATEFROMDATA102' , but all the segments and fields i need was not seen in this idoc . All the details were available in u201CFIXEDASSET_CREATEINCLVALUES02u201D. I want to know the difference between these two idocs.
Thanks & Regards,
Lakshmi Rajkumar.

Hi Lakshmi,
Just go through the documentation.FIXEDASSET_CREATEINCLVALUES02 is BAPI for Legacy Data Transfer.
Regards,
Madhu.

Diff... between ALE, IDOC, RFC, BAPI, BADI --- Not clear and clarify

Hi All
    I am learning XI and the difference between " ALE, IDOC, RFC, BAPI, BADI "
    Not clear and when to use what and how in point of XI ?
   Pl..clarify me
Adv..thanks and points
--- Rakesh Behera

Hi
This will expalin you every thing ...pl..go through
The interface concept of the classic R/3 is based on two different strategies: Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.
While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.
The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.
I hope this will help you to understand the difference bet..those
regards
--- prasad

Difference between Production Supply Area and a Storage Location

Hello Experts,
Basic question but wanted to get more clarity on the concept as i never worked on the PSA
Can someone tell me the exact difference between PSA and a SL. I understand PSA is a Kanban, WM and SL is an IM concept. Can a work center have a storage location assigned or just a PSA? Can a GI be done from PSA or just from a storage location.

Hello
The production supply area is a master data used by WM, while the storage location is used by MM-IM.
Check this link for details:
Production Supply Area - Warehouse Management System (WMS) - SAP Library
The goods issue is done with reference to the storage location
It is possible to assigne a storage location to a production supply area and assign the production supply area to the work center.
BR
Caetano

Difference between Idoc ACC_INVOICE_RECEIPT03 & INVOIC

Hi
I am a total FI ignorant (I know SD so I can answer questions there!); I was asked to think of an interface that posts AP invoices.
Some invoices have a purchase order (and we need to finish the MM flow) so the interface can use Idoc INVOIC01/02 I believe. But some invoices do not have a PO number and need to be either posted or parked.
Can I use the same Idoc for that (with dummy PO), or should I use ACC_INVOICE_RECEIPT03 ? of course I would prefer to use the same Idoc for everything if possible...
I don't understand the difference between the 2 Idocs.
Thanks for your help.
Agathe

Hi,
Chekc the IDoc received, may the amounts are in proper format, check with the ABAPer for correct format.
VVR

Difference between idoc and rfc

what is the difference between idoc and rfc? when and where it is used? when there is idoc, why rfc vice versa?

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system.
IDocs are used for asynchronous transactions: Each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database.
Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.
A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.
IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.
An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication
layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model.
The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system
RFC
Remote Function Calls (RFC) and data exchange through IDoc message documents. RFC makes direct and synchronous calls of a program in the remote system. If the caller is an external program it will call an RFC-enabled function in R/3 and if the calling program is the R/3 system it will call an RFC-function in another R/3-system or it will call a non-R/3 program through a gateway-proxy (usually rfcexec.exe). BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
note:reward points if solution found helpfull.....
regards
chandrakanth.k

Difference between BAPI and IDocs

hello all
what is difference between BAPI and IDocs

Hi,
BAPI
One of the big plusses for BAPIs is that the interface and function are not supposed to change. This is a big plus when you do upgrades or hot packs because the transaction can change (format, required inputs etc) which means you then need to update the call transaction.
Some of the BAPIs are better documented and easier to use than others. You usually need to perform the BAPI that actually does the COMMIT after you call your BAPI.
The Program coding for calling a BAPI is usually cleaner than setting up the screen flow etc for the Call Transaction.
You don't need to worry about special data circumstances interrupting the normal data flow of the screens and causing errors because of that.
BAPIs probably have better performance since they don't do the screen flow processing.
In general if the BAPI exists for the transaction you want to perform and you can figure out how to use it the BAPI is probably the best way to go.
BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
IDOC
IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system. Instead of calling a program in the destination system directly, the data is first packed into an IDoc and then sent to the receiving system, where it is analyzed and properly processed. Therefore an IDoc data exchange is always an
asynchronous process. The significant difference between simple RFC-calls and IDoc data exchange is the fact, that every action performed on IDocs are protocolled by R/3 and IDocs can be reprocessed if an error occurred in one of the message steps.
While IDocs have to be understood as a data exchange protocol, EDI and ALE are typical use cases for IDocs. R/3 uses IDocs for both EDI and ALE to deliver data to the receiving system. ALE is basically the scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. Such a set-up is called an ALE-scenario.
The philosophical difference between EDI and ALE can be pinned as follows: If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data. The difference is made clear, when we think of a purchase order that is sent as an IDoc. If we send the purchase order to a supplier then the supplier will store the purchase order as a sales order. However, if we send the purchase order via ALE to another R/3 system, then the receiving system will store the purchase order also as a purchase order.
Regards,
Bhaskar

Differences between rfc and ale/idoc.

hi ..
       will u please send the differences between rfc and ale/idoc's.

Hi,
Please reward with points if helpful................
ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. There are three layers in ALE system: application services, distribution services, and communication services.
For communication services, ALE performs a Remote Function Call (RFC) using the port definition and RFC destination specified by the customer model. RFC is used to communicate between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system.
Means of creating and operating distributed applications.
The purpose of Application Line Enabling is to guarantee a distributed, but integrated, R/3 installation. This involves business-controlled message exchange with consistent data across loosely linked SAP applications.
Application integration is achieved not via a central database, but via synchronous and asynchronous communication.
Application Link Enabling comprises the following three layers:
application services
distribution services
communication services
Two Development Models
     Distribution using BAPIs
     Distribution using Message type
The programming model "Distribution using message types" contains the definitions of message types and IDoc types and the ABAP code for processing inbound and outbound IDocs.
Defining message types and IDoc types:
If you want to create message type enhancements for master data distribution, you also have to create a new message type for each enhancement.
The ALE interface does not allow you to create different segment data for different IDoc types for the same message type.
Writing ABAP code:
         Outbound Processing
           Inbound Processing
You can find information on other ALE functions under:
                               Master Data Distribution
                              Communicating with Non-R/3 Systems
1. The Remote Function Call facility allows you to call an R/3 Function module on a remote machine.
2. To communicate between two R/3 Systems and also with an External System. External Application program also can call these function module for integration.
3. RFC or sRFC - Synchronous RFC
                 aRFC - Asynchronous RFC
                  tRFC - Transactional RFC
                  qRFC - Queued RFC (I.e. Serialization of tRFC)
Types of RFC Call
Synchronous
CALL FUNCTION Func Destination Dest
CALL FUNCTION func DESTINATION 'NONE' ...
CALL FUNCTION func DESTINATION BACK' ...
Asynchronous
CALL FUNCTION func STARTING NEW TASK taskname
PERFORMING form ON END OF TASK
RECEIVE RESULTS FROM FUNCTION func
Thanks
sivaparvathi

Difference between IDOC & RFC

1. Can someone explain the difference between IDOC & RFC
2. from processing point of view which one would be the best performance

IDOC      BAPI
IDocs are text encoded documents with a rigid structure that are used to exchange data between R/3 and a foreign system.
BAPIs are a subset of the RFC-enabled function modules, especially designed as Application Programming Interface (API) to the SAP business object, or in other words: are function modules officially released by SAP to be called from external programs.
Idocs are processed asynchronously and no information whatsoever is returned to the client,
BAPIs are called synchronously and (usually) return information
The target system need not be always online. The IDOC would be created and would send the IDOC once the target system is available (tRFC concept). Hence supports guaranteed delivery
whereas for BAPIs the client code needs to do the appropriate error handling.
With asynchronous links the sub-process on the client can be finished even if the communication line or the server is not available. In this case the message is stored in the database and the communication can be done later
Problems with synchronous links occur if the communication line or the server is temporarily not available. If this happens, the sub-process on the client cannot be finished (otherwise there would be data inconsistencies).
The disadvantage of asynchronous links is that the sub-process on the server cannot return information to the calling sub-process on the client. A special way for sending information back to the client is required. In addition, a special error handling mechanism is required to handle errors on the receiving side.
Synchronous links have the advantage that the sub-process on the server can return values to the sub-process on the client that has started the link.
IDOCs may
be more changeable from release to release.
BAPIs are not totally immune to upgrades
IDOCs are poorly documented
BAPIs are reasonably well documented.

Difference between scripts and idocs

In real time why we are using scripts and idocs?what is the difference between scripts and idocs?pls tell me where we r using scripts and idocs?

Hi,
IDocs are simple ASCII data streams. When they are stored to a disk file, the IDocs are simple flat files with lines of text, where the lines are structured into data fields. The typical structured file has records, each record starting with a leading string that identifies the record type. Their specification is stored in the data dictionary.
Electronic Interchange Document
IDocs is the acronym for Interchange Document. This indicates a set of (electronic) information which builds a logical entity. An IDoc is e.g. all the data of a single customer in your customer master data file, or the IDoc is all the data of a single invoice.
Data Is transmitted in ASCII format, i.e. human readable form
IDoc data is usually exchanged between systems and partners that are completely independent. Therefore, the data should be transmitted in a format that can easily be corrected by the computer operators. It is therefore mandatory to post the data in a human readable form.
Nowadays, this means that data is coded in ASCII format, including numbers which are sent as a string of figures 0 to 9. Such data can easily be read with any text editor on any computer, be it a PC, Macintosh, UNIX System, S/390 or any internet browser.
IDocs exchange messages
The information which is exchanged by IDocs is called a message and the IDoc is the physical representation of such a message. The name messages for the information sent via IDocs is used in the same ways as other EDI standards. .
Scrpits...
If the user wants to print documents such as invoices, purchase order, all such documents are printed with the use of forms. SAP allows the user to define these forms by using layout sets. SAP script is the tool used to create the layout set.
In order to print the document, the SAP system runs a program that collects the data for the document and feeds it into the layout set. This is called as Print Program.
SAP Provides a standard layout set for every printable document and usually there is no need to create layout sets as such. User just modifies the existing layout sets as per requirement of client.
Regards,
Sam

DIFFERENCE BETWEEN PSA & IDOc

Similar Messages

Maybe you are looking for