Anda di halaman 1dari 11

Creation of purchase order at

receiver system through idoc

Mandeep Pal Singh


Creation of purchase order at receiver system through idoc

• Most important transaction is we20 to create partner profile.


• At we20 partner no. and partner type has to be entered.( in our case
partner type is LS and for entering partner no., first partner has to be
defined in system. Logical system can be defined either in bd54 or
wedi transaction. Logical system and partner no. should be same.
• At post processing: permitted agent, type, agent and lang., I’ve used
existing one. At classification, partner status should be active.
• At sending system, two partner profile need to be created. One for
sender logical system and one for receiver logical system. But both
have same outbound parameter configuration
Creation of purchase order at receiver system through idoc

• Now time for outbound parameter configuration:


-> partner function has to be entered. In our case it is LS.
-> relevant message type has to be entered.
-> At outbound options, I’ve to enter receiver port.
-> but before this. We also have to define port. Port can be defined

at we21 ( if not defined already ).


-> before this . We also have to define rfc destination at sm59.
-> At sm59 we have to create R/3 connectiion, enter connection
type ( 3 in our case for R/3) enter description.
At technical setting, target host application server is to be given
(which is blrkecisbank.ad.infosys.com in our case )
At logon/security, user name,pswd,client no. and language has to
be entered .we clicked no at radio button at trusted system.
Creation of purchase order at receiver system through idoc

• After defining rfc destination, port. Back at our outbound parameter


we should enter pack size ( 1 for testing in our case ).
• At idoc type we should enter our idoc. But before this message type
and idoc type must be associated. They can be associated at we82
or at wedi.
• At reciever system, same way two partner profile has to be created.
One for reciever and one for sender. But both have same inbound
parameter configuration.
• At inbound parameter, partner role or partner function has to be
entered. Message type has to be entered. And then at inbound
options, process code has to be entered. At process code functional
module is already been define. We have used a zee process code
so manually created process code by entering functional module
details,description,option ale ( processing ale services) and
processing type( processing by function module).
Creation of purchase order at receiver system through idoc
• But we have to make another association before creating process code.
We have to assign our functional module to respective message type
and and idoc type at we57.
• At bd51- ale attributes, we also have to define our inbound functonal
module and also enter input type ( which is 2 in our case ).

 After doing all these things, I opened we19 which is test tool for idoc
processing. There I entered my basic type- idoc name and then there
are segments in idoc. Mainly control record and data record. Both are
also called run time components.At control record, I entered at
sender,reciever, port no.,partner no., partner type, partner role. And
logical message type, entered message type name.
 We are creating idoc for test purpose, that’s why I manually entered
data at segments at relevant fields and clicked standard outbound
processing. And then idoc sent to external system.
 And application document got posted at reciever system ( which is
creation of purchase order in my case )
Creation of purchase order at receiver system through idoc

• At we02,we05. we can see recently created idoc.


• There there would be 3 run time components- control records, data
records and status record.
• There will be two idoc generated. One at sender system and one at
receiver system.
• At status records, all error messages or success messages will be
displayed.(1-50 for outbound messges and 51-100 for inbound
messages )
• But we have to look for 3 in outbound and 53 in inbound idoc which is
obviously a success post message.
• Bd75 is used to know the status of idoc,whether it has been sent or not.
• SWWL is used to delete idoc number.SM68 to check status.
Main transactions for idoc :

• Bd87 is the transaction for post processing of idoc.


• WE47 is for viewing all idoc status information.

• RSEOUT00 is the program which can send the idocs collectively.


Some extra information about idoc about mm cycle

 Around 1979, The American National Standards Institute (ANSI) designated an accredited standards
committee for EDI .
 The Uniform Communication Standard (UCS) is used by the grocery industry and other retail-oriented
industry sectors. The UCS standards are a subset of the ANSI ASC X12 standards.
 Purchase Orders (ANSI- EDI 850, UCS- EDI 875) detail the items, quantities, actual cost or estimated cost,
Terms, Notes, Ship-to locations, Ship Dates, Cancel Dates, etc.
 Purchase Order Acknowledgements (EDI 855) are used to provide seller's acknowledgment and acceptance
or rejection of a buyer's purchase order. This can be an acknowledgement that the entire ordered quantity will
be shipped and the date when it will be shipped. It can also be a line by line acknowledgment of partial or
complete quantities and single or multiple shipping dates. The 855 Document can also be used as notification
of a vendor-generated order or Reverse Purchase Order. The 855 Reverse PO is used in support of Vendor
Managed Inventory (VMI). The vendor creates this Reverse PO to indicate to the buyer that the supplier has
created a purchase order to maintain inventory levels as agreed to in the VMI agreement between the two
parties. There is usually a minimum time period for the 855 to be sent prior to the sending of the 856 -
Advance Ship Notice, which is sent when the goods are shipped.
 Advance Shipping Notices (EDI 856) tell the customer all the details about the shipment: what items were
sent, how many, when they were sent, etc.
 The Purchase Order Change Request (EDI 860) document is sent by a customer to communicate changes to
a previous Purchase Order. The 860 can be used to cancel the entire order, add and delete items, alter item
quantities and prices, and change dates specifying order shipment, delivery, etc.
Some extra information about idoc about mm cycle

 The Text Message (EDI 864) document is used to communicate plain free-form text
messages. The 864 is often used to communicate information regarding problems
with a received document. It is also used to communicate general business
information about the trading relationship that is not document specific.
 The Credit/Debit Adjustment (EDI 812) document is used to communicate details of
credits and debits for products. It may reference a specific Purchase Order and
Invoice and include detailed information such as item identification and quantity.
Standard codes are used to indicate the reason for the credit or debit request. Some
common reasons are defective product, non-receipt of goods, return of goods, order
quantity shortage or overage, and pricing error.
 The Organizational Relationships (EDI 816) document is used to communicate
location address and relationship information. On the most frequently exchanged EDI
documents (the PO, ASN, and invoice) locations are most often identified only by
codes in order to avoid the cost of transmitting full addresses. Location codes are
unique to a specific trading partner. The 816 document tells trading partners the
address to associate with a particular location code. The trading partner receiving the
816 can use it to maintain a list of the sender's location codes and associated
addresses. An alternate format of the 816 is used to show organizational
relationships, such as stores serviced by a specific Distribution Center or warehouse.
Trading of 816's begins with a full set of the trading partner's addresses, after which
changes may be sent on a weekly or monthly basis, or as needed.
Some extra information about idoc about mm cycle

 The Payment Order/Remittance Advice (EDI 820) document is used in connection with
Electronic Funds Transfer (EFT) in one of two ways. In the first, a Remittance Advice is
sent to the trading partner and a Payment Order is sent to the sender's bank to initiate
transmission of the payment to the trading partner's bank. The second option sees a
combined Payment Order/Remittance Advice transmitted to the sender's bank, which in
turn sends the payment and remittance data to the trading partner's bank, which then
informs the trading partner that the payment has been received. The 820 includes such
data as payer and payee identification, including bank and account IDs, seller's invoice
ID, adjustment amounts, reason codes, and billed and paid amounts.
• The Application Advice (EDI 824) document is used to inform trading partners of errors
in EDI documents they have sent, most often invoices. The 824 differs from the 997
Functional Acknowledgement in that it is created as the result of error checking by the
trading partner's business application program, whereas the 997 generally indicates EDI
standard problems rather than business rule errors. In contrast to the 864 Message
Text document, the 824 provides a fixed format for the identification of specific data
items in error and for their suggested correction, in addition to free-form text message.
• The Product Activity Data (EDI 852) document is used to report sales, inventory, and
ordering information. Data is reported by item and may be broken out by store location.
The 852 is usually sent on a weekly basis. The data is useful to the selling trading
partner for product planning purposes. Normally the purchaser's buyer must approve
the sending of 852 data to the seller.
Some extra information about idoc about mm cycle

 Functional Acknowledgments (EDI 997) are short documents returned to the sender
of an EDI transmission. They indicate that the transmission was received, but do not
indicate agreement with the document.
 Invoices (ANSI- EDI 810, UCS- EDI 880) are issued by the trading partner who has
provided products and/or services as a request for payment. These EDI invoices
include most of the purchase order information as well as Invoice Number, Invoice
Date and Total Amount Due.