SAP EDI Mapping: An IDoc for Every Interface - Toolbox.com [PDF]

Jul 24, 2009 - The key is ensuring that you select IDocs that meet the data requirements of the business process designe

61 downloads 14 Views 197KB Size

Recommend Stories


EDI)
The only limits you see are the ones you impose on yourself. Dr. Wayne Dyer

5 lcd interface pin mapping
Never wish them pain. That's not who you are. If they caused you pain, they must have pain inside. Wish

SAP 101 SAP Overview [PDF]
Dec 20, 2000 - Internet-Business Framework. (through SAP Products and Services). Value Creation. Integrated end-to-end business process. COLLABORATIVE ...... Workflow. The SAP Business Workflow is a support tool that can be used to optimize the execu

EDI
The wound is the place where the Light enters you. Rumi

[PDF] Download Surviving an SAP Audit
No amount of guilt can solve the past, and no amount of anxiety can change the future. Anonymous

SAP Engineering Control Center Interface to SOLIDWORKS
It always seems impossible until it is done. Nelson Mandela

every every every
Raise your words, not voice. It is rain that grows flowers, not thunder. Rumi

an interface for annotating natural interactivity
You have survived, EVERY SINGLE bad day so far. Anonymous

An interface interaction method for compressible multifluids
Never let your sense of morals prevent you from doing what is right. Isaac Asimov

READ PDF SAP Plant Maintenance (SAP PM)
What we think, what we become. Buddha

Idea Transcript


ENTERPRISE SOFTWARE

SAP EDI Mapping: An IDoc for Every Interface By Emmanuel Hadzipetros 9 years ago

39

0



A common request often voiced on list groups and other professional forums is for a standard cross-reference between SAP IDocs and EDI transaction sets and messages. Over the years I've seen some spreadsheets that link IDocs to X12 transaction sets and I've built my share of IDoc to EDI cross-reference spreadsheets that meet the needs of a particular project. But here's the rub. There's no official standard cross-reference out there. You can literally map anything to anything. IDocs and EDI transactions are only data structures, after all. The key is what do you do with their data in the backend SAP system at your site. This is what the business process is all about. SAP sends and receives IDocs. But SAP is generally introduced into an environment where EDI is already being used. So the EDI transactions have been already agreed to with the trading partners and are already being used in legacy. The key is ensuring that you select IDocs that meet the data requirements of the business process designed in your SAP system and then figuring out how to map them to your existing, and any new, EDI transactions or messages. In other words, like everything else you do in SAP, you need to understand the underlying business process before you can select the appropriate IDoc to map to EDI. The business process drives everything. On the inbound, that means understanding what document the IDoc creates when it hits SAP and what data that document needs. On a deeper technical level, that means knowing the code, the processing function and the create transaction that the IDoc calls to create the business document. The EDI team may not need to know this, but somebody on the SAP team does. This knowledge drives the mapping requirements. On the outbound, it's all about the business document that generates the IDoc and the configuration and/or code needed to collect the application data and output the IDoc. In general, but not always, virtuall all the data in a business document is sent in an outbound IDoc. This data must then be matched up to the EDI data that is being sent to the trading partner by the legacy system. A Team Effort The key take-away in all this is that it's not just about about mapping messages and transactions. It's about how the data being exchanged is processed and consumed in SAP and by the trading partner. Selecting the correct IDoc to map is a team effort that requires both EDI and SAP skills and input. If you understand these pieces, and if you know what EDI transactions or messages you need to exchange with your trading partner, you can make an intelligent decision about what IDocs to use, assuming you got out of the right side of your bed that morning or that you don't have a hang-over or some other self-inflicted malady. Having said all that, there are some commonly accepted pairings between IDocs and EDI transaction sets and messages. So I consulted a few sources and came up with a starting point cross-reference for inbound and outbound interfaces. I began with two OSS Notes from the SAP Support Portal: 104606 maps IDocs to X12 transaction sets and 150009 lists IDocs that are commonly used in EDI. I also consulted ERP Genie which has a very useful SAP EDI portal with a number of spreadsheets that map IDocs to different EDI standards. Then I dug through some IDoc tables and code in SAP, ransacked my own experience and knowledge, such as it is, tweaked a little here, a little there, and came up with a mapping that I hope you find useful. I used the most recent IDoc versions wherever appropriate, confirmed by consulting SAP. I'm a firm believer in using the latest IDoc versions. Some of these choices are arbitrary and some you may not agree with. Some pose design issues that some may not want to pursue. Message type TXTRAW, for example, can be mapped to any EDI text report. But would you want to do it? TXTRAW formats a text message that is distributed through SAPOffice email. I normally handle these kinds of interfaces in the EDI subsystem, by designing a report with a map and attaching it to an email sent through the regular email system. But you never know what opportunities circumstance will throw your way. If you have any additions to this mapping, or if you object strenuously to some of these choices, I'm all ears. Feel free to comment or to send me an email. One last point: this mapping is IDoc centric because SAP is the business system of record. We begin with the IDoc and map its associated EDIFACT messages and X12 transaction sets. It could just as easily be displayed from the EDI perspective. So without further ado, Odysseus is pleased to present this preliminary SAP IDoc to EDI mapping. Enjoy. Inbound Interfaces MsgType

BasicType

Description

EDIFACT

X12

ACLPAY

ACLPAY01

Freight invoice

INVOIC

210

CREADV

PEXR2002

Credit advice

CREADV

812

CREADV

PEXR2002

Extended credit advice

CREEXT

812

CREADV

PEXR2002

Multiple credit advice

CREMUL

812

CREMAS

CREMAS04

Vendor/Org info

PARTIN

816

DEBADV

PEXR2002

Debit advice

DEBADV

812

DEBADV

PEXR2002

Multiple debit advice

DEBMUL

812

DEBMAS

DEBMAS06

Customer/Org info

PARTIN

816

DELFOR

DELFOR01

Delivery schedule

DELFOR

830

DELINS

DELFOR02

Delivery schedule

DELFOR

830, 862

DELJIT

DELFOR01

Just in time delivery

DELJIT

830, 862

DELORD

ORDERS05

Delivery request

ORDERS

830, 850

DESADV

DELVRY03

Delivery (Despatch Advice)

DESADV

856, 940

DIRDEB

PEXR2002

Direct debit

DIRDEB

828

DIRDEB

PEXFI03

Direct debit

DIRDEB

828

FINSTA

FINSTA01

Financial statement

FINSTA

821, 822

GSVERF

GSVERF03

Credit memo procedure

ORDERS

861

IFTMIN

SHPMNT04

Forwarding order

IFTMIN

204, 304

INVOIC

INVOIC02

Vendor Invoice

INVOIC

810, 880

LOCKBX

FINSTA01

Lockbox

PAYORD

823

MBGMCR

MBGMCR03

Post Goods Mvmt & PGI Del

RECADV

856, 867, 945

MBGMCR

MBGMCR03

Goods Mvmt & Goods Receipt PO

RECADV

867, 944

ORDCHG

ORDERS05

PO Change Request

ORDCHG

860, 876

ORDERS

ORDERS05

Customer PO

ORDERS

850, 875

ORDRSP

ORDERS05

PO confirm

ORDRSP

855, 865

PAYEXT

PEXR2002

Extended payment order

PAYEXT

820

PAYEXT

PEXR2002

Multiple payment order

PAYMUL

820

PAYEXT

PEXR2002

Payment order

PAYORD

820

PROACT

PROACT01

Inventory Report

INVRPT

846, 852

PROACT

PROACT01

Sales forecast

SLSFCT

852

PROACT

PROACT01

Sales report

SLSRPT

852

REMADV

PEXR2002

Credit advice

CREADV

820

REMADV

PEXR2002

Payment advice

REMADV

820

REQOTE

ORDERS05

Response to request for quotation

REQOTE

840

SDPICK

SDPIID01

Pick/Ship confirm & PGI

RECADV

856, 867, 945

SHPADV

SHPMNT05

Advanced Ship Notification

SHPMNT

856

SHPCON

DELVRY03

Ship confirm/PGI

RECADV

856, 867, 945

SHPMNT

SHPMNT05

Advanced ship noticifaction

SHPMNT

856

SHPORD

DELVRY03

Delivery despatch order

DESADV

830, 850, 856, 940

STATUS

SYSTAT01

Acknowledgement

CONTRL

997

STATUS

SYSTAT01

Functional acknowledgement

FUNACK

997

TXTRAW

TXTRAW02

Error report (text msg)

APERAK

824, 864

TXTRAW

TXTRAW02

Error report (text msg)

GENRAL

824, 864

WHSCON

DELVRY03

Stock confirmation & PGI

RECADV

856, 867, 945

WHSORD

DELVRY03

Delivery stock order

DESADV

940

WMTORD

WMTOID02

Transport request (goods movement)

RECADV

856, 867, 945

WMMBXY

WMMBID02

Post goods receipt (goods movement)

RECADV

867, 940, 945

Outbound Interfaces MsgType

BasicType

Description

EDIFACT

X12 Txn

BENREP

BENEFIT3

Benefit enrollment

N/A

834

CREMAS

CREMAS04

Vendor/Org info

PARTIN

816

DEBMAS

DEBMAS06

Customer/Org info

PARTIN

816

DELFOR

DELFOR01

Delivery schedule

DELFOR

830

DELINS

DELFOR02

Delivery schedule

DELFOR

830, 862

DELJIT

DELFOR01

Just in time delivery

DELJIT

830, 862

DESADV

DELVRY03

Delivery (Despatch Advice)

DESADV

830, 856, 940

DESADV

DELVRY03

Delivery (Despatch Advice)

IFTMIN

830, 856, 940

EXPINV

EXPINV04

Export invoice

INVOIC

810, 880

IFTMIN

SHPMNT04

Forwarding order

IFTMIN

204, 304

IMPINV

IMPINV01

Import declaration

CUSDEC

N/A

INVOIC

INVOIC02

Customer Invoice

INVOIC

810, 880

MATMAS

MATMAS05

Material master/product data

PRODAT

832

ORDCHG

ORDERS05

PO Change Request

ORDCHG

860, 876

ORDERS

ORDERS05

Vendor PO

ORDERS

850, 875

ORDRSP

ORDERS05

PO Response

ORDRSP

855, 865

PAYEXT

PEXR2002

Extended payment order

PAYEXT

820

PAYEXT

PEXR2002

Multiple payment order

PAYMUL

820

PAYEXT

PEXR2002

Payment order

PAYORD

820

PRICAT

PRICAT02

Price/Sales Catalog

PRICAT

832, 879, 888, 889

PRICAT

PRICAT02

Product data

PRODAT

832, 879, 888, 889

PROACT

PROACT01

Inventory Report

INVRPT

846, 852

PROACT

PROACT01

Sales forecast

SLSFCT

852

PROACT

PROACT01

Sales report

SLSRPT

852

QUOTES

ORDERS05

Quotation

QUOTES

843

REMADV

PEXR2002

Credit advice

CREADV

820

REMADV

PEXR2002

Debit advice

DEBADV

820

REMADV

PEXR2002

Payment advice

REMADV

820

REQOTE

ORDERS05

Request for quotation

REQOTE

840

SHPADV

SHPMNT05

Advanced Ship Notification

SHPMNT

856

SHPCON

DELVRY03

Ship confirmation

RECADV

856, 867, 945

SHPMNT

SHPMNT05

Advanced ship noticifaction

SHPMNT

856

SHPORD

DELVRY03

Delivery despatch order

SHPORD

830, 850, 856, 940

SHPORD

DELVRY03

Delivery despatch order

DESADV

940

SYIDOC

SYIDOC01

EDI/IDoc Guidelines Defintion

IMPDEF

N/A

SYRECD

SYRECD02

EDI/IDoc Guidelines Defintion

IMPDEF

N/A

WHSCON

DELVRY03

Stock confirmation

RECADV

856, 867, 945

WHSORD

DELVRY03

Delivery stock order

DESADV

940

SAP

ABOUT THE AUTHOR

Emmanuel Hadzipetros

More by this Author ENTERPRISE SOFTWARE

ENTERPRISE SOFTWARE

ENTERPRISE SOFTWARE

Blogging for a Cause: Risk and the Ineffable Art of Success

Looking to a New Year Playing in the Cloud with SOA Integration

Odysseus is Still Here ... Thinking ... But Still Here

Saturday, December 3, 2011

Sunday, December 26, 2010

0

Sunday, November 7, 2010

2

1

39 Comments Write Comment Newest Comments First

Sign In to Post a Comment Sign In

BJ

Becky Jones commented a year ago

"it would be nice to have this chart updated with current basic types. does the PEXR2003 replace the PERXR2002? I have your book but couldn't find any processing of a bank 820 remittance advice, only one to/from a trading partner. Would it be the same? "

Emmanuel Hadzipetros commented 6 years ago

"Thank you for your comment. You're right about GSVERF. But it's an interesting IDoc. Functionally it's described in SAP as a credit memo procedure and there are EDIFACT messages that could match up. You'd think, for example, CREADV, Credit Advice. But check out the structure of basic type GSVERF03. It's almost identical to ORDERS05, with some additional segments to support bank details, foreign trade, packaging data, and so on. This business of mapping format to format is an inexact science. The key thing is what data are you trying to bring into your system or send to your partner's system. Obviously if you're doing point to point with a specific partner you have a lot of freedom of action. But if you're trying to write a generic map that will work for a lot of different partners it's a little more difficult and standards a little more useful. Good luck! And watch for my new book over the next few months! "

R

Rusty_Cage commented 6 years ago

"Hello Emmanuel, at first thank you for great article :) I am now concerned about message type GSVERF and its EDIFACT mapping. I have been searching about this message type and there is not much on internet. However on your blog I found some good information. What is though interesting is, that EDIFACT type is ORDERS, even though GSVERF is for invoices, credit memo, etc. Do you know why is it so? On other hand, some message types appear only in inbound (just like GSVERF :) ) and some only in outbound. Is there some limitation/restriction with other direction? Thanks a lot, LS "

Emmanuel Hadzipetros commented 6 years ago

"Hey Wolfgang: thanks for your comment. The short is no, I don't have any programs that directly map X12 to IDocs. I do have maps that I've built in external mapping tools such as Sterling Integrator and Contivo (which can also generate java class files that can be run standalone at the operating system level). You can write programs, of course, in ABAP or java or whatever language you're comfortable with but if you have access to any mapping tools it's probably easier. There are freeware tools out there. But you need to get the schema or IDoc description files to do it. I like to work with XML because the schema or guidelines are freely available for most standards. Unfortunately, X12 guidelines are very expensive. Good luck. "

K

krishn9 commented 6 years ago

"Hello Experts, Can anyone pls. provide inputs on 861 with appropriate steps? Thanks "

Emmanuel Hadzipetros commented 6 years ago

"The easiest thing to do is to write a custom ABAP report on the IDoc database. I've written reports like this before where you read the Idoc into an internal table, loop on the segments, and pull out, count, aggregate (or not), and format any data you want to into a report. Use the ALV grid: it does formatting for you and let's subtotal and total by column without having to write any additional code. It's not that difficult writing these kinds of reports. Of course it depends on how complex you want them to be. But this is straightforward ABAP. "

K

kawalsethi commented 6 years ago

"Hi I like to your advice for reports. We are working on 860 inbound 810 inbound and 850 outbound idoc.Business wants to see the some kind of reports to see the errors which are related to these IDOC message. I know standard SAP has EDIDS ,EDID table which can be used but doesn't help for business to see the PO number,Vendor Number ,Line item and in case of ASN price difference,Qty,delivery date or unit of measure difference . Can you please guide me how I can achieve this ? Thanks "

K

kawalsethi commented 6 years ago

"Hi I like to your advice for reports. We are working on 860 inbound 810 inbound and 850 outbound idoc.Business wants to see the some kind of reports to see the errors which are related to these IDOC message. I know standard SAP has EDIDS ,EDID table which can be used but doesn't help for business to see the PO number,Vendor Number ,Line item and in case of ASN price difference,Qty,delivery date or unit of measure difference . Can you please guide me how I can achieve this ? Thanks "

Emmanuel Hadzipetros commented 6 years ago

"Thanks Robyn. I've never implemented an 861. I just googled it and it's described as a Receiving Advice/Acceptance Certificate. To be honest, I'm not sure what IDoc it would map to in SAP but it appears to have something to do with shipping. There are a lot of guidelines on its use on the web and you'd need to comb thru some of those to figure it out. I'd also analyze the structure of the message. The thing about IDocs and EDI messages is that in the end, if the structure more or less fits, you can use them to map to pretty well anything. You may need to write some custom code on the SAP side, but if it works with your business process, you're good to go. Some SAP sites may even build a custom IDoc, and the custom code behind it, for every interface they run. "

Emmanuel Hadzipetros commented 6 years ago

Map to an IDoc in Informatica and send it to SAP. You generally use ORDERS.ORDERS05 to post the sales order.

Emmanuel Hadzipetros commented 6 years ago

"It's not the IDoc, dude, it's the data. It's always best to use the most current version of the IDoc and SHMPMENT05 is more current than SHPMENT03. I don't know enough about the way your system is set up but chances are there are problems with the way the shipping document is being populated in SAP, particularly with all those text elements, perhaps with the way the IDoc is being generated out of SAP, and quite possibly with the mapping between the IDoc your OB EDI transaction. Good luck! "

K

kamatninad commented 6 years ago

"Hi, I am new to EDI. My client is currently using idoc type SHPMNT05 to send shipping instructions to his carrier. There has been no update to this process for the past 10 years and a lot of data is entered as a text field in the idoc and sent across. Their carrier interprets this text data and enter information into their system. The process generates a million errors (obviously). Now they want to map thei shipping information in such a way that all information is sent automatically from the shipment document and the user does not need to enter anything manually. I dont think all of their outbound info is mapped correctly. They want to use a standard idoc type so that even if they wish to change their carrier in the future the EDI mapping would be simpler. Right now no carrier wants to work with this EDI set up due to the manual processing. Do you think using SHPMNT03 would be better to map all required data? Please advice "

Emmanuel Hadzipetros commented 6 years ago

"What you need to do is test this with your SAP team. E1EDL44 links the handling unit with the item in a document. It has both VBELN and POSNR in it. Bottom line: SAP posts E1EDL24 against the item level of the delivery document. The way the handling unit is structure in the IDoc, it looks like it can reference multiple document items. I haven't gone into the code to research this but my suspicion is that you populate your item level (E1EDL24), populate your handling units (E1EDL37 and whatever else under it), then enter your delivery document number and item in E1EDL44 referencing the item in E1EDL24. The DELVRY07 (or whichever version you're using) IDoc does repeat the delivery document in a number of segments. This is only a guess but it's something that you can test. You need to work with the SAP team. Good luck. Let us know what you come up with. "

KN

Kim Neal commented 6 years ago

"Thanks for your response. So let me give you some more information. SAP resides on a ISeries and they are using Tli as the translator. The issue is that the items come after the pack level and the L24 is above the Pack/item level in the standard IDOC. Below is the other blog addressing this same issue. 856 ASN- SOIP to SOPI the items(EDL24 group) are listed a second time under each pack(EDL37 group, EDL44 is the item record). The item sequence number on the EDL44 record will match the item sequence number on the EDL24 record. If you have no other issues it will be SOPI if you use the EDL37/EDL44 record rather than the EDL24 group. The E2EDL44 appears to have the same fields to accommodate the qty, uom, and part numbers and the documentation states the E2EDl44 is for the delivery items. The E2EDL24 documentation states Order item.

"

Emmanuel Hadzipetros commented 6 years ago

I don't know any of the details of your system but item level data in the DELVRY04 basic type is mapped to the E1EDL24 segment. The SAP team knows -- or should know -- what it needs in the IDoc. Good luck.

KN

Kim Neal commented 6 years ago

"We are receiving 856 in a SOPI structure. The SAP team is having me map to the DELVRY04 IDOC. The issue is that the IDOC seems to be in the SOIP structure. I read another post to accommodate SOPI I need to map the Pack/item in these segments E1EDl37, E2EDL44, and E1EDL44. The SAP team is telling me that they tested this in their testing tool and it did not post because it needed the Items in the ED1L24. Help "

Emmanuel Hadzipetros commented 6 years ago

"The key question is what document are you trying to post to in SAP? IB ORDERS generally posts to an SAP Sales Order but it can also post to other types of documents, depending on configuration, some mapping tables in SAP, and underlying custom code written to handle special circumstances. Your target IDoc is dependent on the target document and business process. Understand that and you should be able to answer your own question. "

CV

Chowdary v commented 7 years ago

"Hi, I am new to EDI. My requirement is to find the Standard message type and IDOC to send data between systems .i have to find out the Standard ones based on below details.Kindly help me on this. Please find below the draft list of the planned EDI messages: MSG Code Message Name __________________________________________________ 990 N/A Vehicle Transportation Forecast Message 991 N/A Ready for Pickup Message 992 N/A Shipping Advice Message (ASN) 993 N/A Receipt at ISP/Dealer Delivery Message 994 N/A Shipment from ISP Message 995 N/A Vehicle Damage Report 996 HO Special Instruction Message Hold 996 RH Special Instruction Message Release from Hold 996 DP Special Instruction Message Disregard Pickup 996 DA Special Instruction Message Disregard ASN 996 DC Special Instruction Message Dealer/Dest. Change 996 CO Special Instruction Message Call Off 996 IN Special Instruction Message Information 996 LM Special Instruction Message Load Make-up 996 VA Special Instruction Message Value 996 RN Special Instruction Message Registration Number Update. 996 CC Special Instruction Message Color Change 996 EV Special Instruction Message Event Update 996 MC Special Instruction Message Marketing Model Update 996 MY Special Instruction Message Model Year Change 996 TC Special Instruction Message Trim Update 996 EC Special Instruction Message Engine Update 996 TT Special Instruction Message Transmission Update 996 OS Special Instruction Message Option Update 996 NC Special Instruction Message Completion Date Update 996 CU Special Instruction Message Request for Customs Clearance 996 PD Special Instruction Message Request for PDI 996 RR Special Instruction Message Request for Repair 997 HO Response to Special Instruction Hold 997 RH Response to Special Instruction Release from Hold 997 DP Response to Special Instruction Disregard Pickup 997 DA Response to Special Instruction Disregard ASN 997 DC Response to Special Instruction Disregard ASN 997 IN Response to Special Instruction Dealer/Dest. Change 997 LM Response to Special Instruction Load Make-up 997 VA Response to Special Instruction Value 997 RN Response to Special Instruction Registration Number Update. 997 CC Response to Special Instruction Color 997 EV Response to Special Instruction Event Update 997 MC Response to Special Instruction Marketing Model Update 997 MY Response to Special Instruction Model Year Change 997 TC Response to Special Instruction Trim Update 997 EC Response to Special Instruction Engine Update 997 ET Response to Special Instruction Transmission Update 997 OS Response to Special Instruction Option Update 997 NC Response to Special Instruction Completion Date Update 997 CO Response to Special Instruction Planned Pickup Date 997 CU Response to Special Instruction Customs Clearance 997 PD Response to Special Instruction PDI completed 997 RR Response to Special Instruction Repair Completed 998 Shipping Advice Update Message Help is appreciated . Regards, Chowdary "

MM

Mohammed manan commented 7 years ago

Need to know the 828 file format and its mapping to target system

MM

Mohammed manan commented 7 years ago

IDoc to EDI Mapping SAP X12 EDIFACT EDI Interfaces cross reference spreed sheet please

Emmanuel Hadzipetros commented 7 years ago

"Thanks for your comment, Achim. I'm glad you're finding this mapping useful. Sorry about the SHPMNT. I must have been thinking IDocs, since they more or less follow EDIFACT naming conventions. Oh well ... we all make our little booboos. I should go over this list again and see if I can add anything to it and identify any other little glitches. Good luck in all you do! "

MM

Mohammed manan commented 7 years ago

I am trying to write functional specification for supplier payment EDI 820 out bound.I am not able to understand where to start from and what information I need to know? what do i need to know in mapping? i mean start to finish.

Emmanuel Hadzipetros commented 8 years ago

"Thanks for your comments. I would recommend my book, Architecting EDI with SAP IDocs. It's got a lot of programming stuff but also a lot of functional stuff. It also has an interface blueprint section with the most commonly used interfaces in the Order to Cash cycle from inbound PO to invoicing and payment. This section includes functional and tech specs and basic X12 to IDoc maps. There''s a link to my book in my Links roll. Not that many tutorials about what to map to what. You need to know the target and the source and your partner's usage. Good luck. Thanks again. ejh. "

JC

Joni Coble commented 8 years ago

"This is indeed a great post. One question that we are grappling with is how can you map a specific transaction to a particular IDOC type. We are entering freight invoices via FB60 and ACLPAY01 seems to be a direct hit but INVOIC02 seems to be a potential candidate as well. Regards, Joni "

Emmanuel Hadzipetros commented 8 years ago

There are a couple that you can use but you need to work with your functional people because they drive the business process. Another question of course is what EDI transaction is being sent to trigger the goods receipt? The key is that you need to understand the business process and the data required to complete it. You can use message type MBMGMCR if all you want to do is post the goods receipt. It supports inventory movements and can be used for a GR. You can also use SDPICK if you're also updating the pick quantity before triggering GR. You can also use message type SHPCON if you're receiving an EDI txn that confirms shipment to the customer of your order Good luck.

M

mfhepp commented 8 years ago

"Dear all, if you are interested in what the GoodRelations ontology can do for EDI in the early stages of doing business (partner search, partner ranking) and for product master data exchange with seldomly used partners, please watch this Webcast: http://www.slideshare.net/mhepp/a-short-introduction-to-semantic-webbased-ecommerce-the-goodrelations-vocabulary-presentation Recipes for typical scenarios are at http://www.ebusiness-unibw.org/wiki/GoodRelations#CookBook:_GoodRelations_Recipes_and_Examples If you have any questions regarding GoodRelations, please contact me; see http://www.heppnetz.de/contact/ for details. Best wishes Martin Hepp http://www.heppnetz.de PS: I will speak your language; my background is Business Information Systems, despite having worked in the SemWeb field for several years. "

Emmanuel Hadzipetros commented 8 years ago

"Sajeesh: Sorry I didn't get back to you sooner. In true Socratic fashion, I'll answer your question with another question: what document are you posting to in SAP? As I have indicated before, the question is not so much what IDoc can you map to which EDI transaction because you can map anything to anything. The question is: what are you going to do with it once it's mapped? If you know what document it's posting to in SAP, then you can easily determine what IDoc you'll need or if you'll need to build a custom IDoc. Are you updating the delivery document with this information? You need to discuss this with your SAP functional folk. Good luck. "

Emmanuel Hadzipetros commented 8 years ago

"Yeah ... uhh ... Lotus, dude ... I responded to your question when you asked me yesterday in my earlier posting The Metamorphosis of an X12 820 to an SAP IDoc: Contivo Translation Files in GIS You can check my response there. Have a nice weekend. "

Emmanuel Hadzipetros commented 8 years ago

Yeah Lotus ... I responded to your question when you asked me yesterday in my earlier posting The Metamorphosis of an X12 820 to an SAP IDoc: Contivo Translation Files in GIS">The Metamorphosis of an X12 820 to an SAP IDoc: Contivo Translation Files in GIS. You can check my response there. Have a nice weekend dude.

L

lotuszhang commented 8 years ago

"Do you have any outbound 810 Sterling GIS map from iDOC to EDI 810? I am developing a new map, like to have some references. thanks Lotus "

Emmanuel Hadzipetros commented 8 years ago

"Thank you for your comment, Sankar. FedEx should have guidelines for their usage of the 110 freight invoice. FedEx publishes its specs on in pdf format on the web. I found a copy by searching Google for ""X12 110 Invoice"". Check out the document at http://fedex.com/us/account/invhome/Elec_Inv_Remit_Overview.pdf. As for what you would map it to in SAP, I haven't worked with it but my guess would be either the a vendor invoice (IDoc message type INVOIC) or an FI invoice (message type ACLPAY). But probably a vendor invoice. But you'll need to work with your SAP functional folk to figure out where they want it to post and from there you'll be able to figure out the IDoc and the mapping. Good luck. "

SP

Sankar Ponnar commented 8 years ago

"Hi Odysseus, Excellent info. Thanks! I need some help. I am looking for guidelines on implementing EDI 110 (FedEx vendor invoice) in SAP. Please advise if there are any standard guidelines / methods available. Thanks, Sankar "

Emmanuel Hadzipetros commented 8 years ago

"Thank you. To paraphrase the Beatles, I am he and he is me ... That's my SDN blog as well. I've been blogging on SDN now since September. The url is: http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/u/252038725 I actually owe a copy of this blog to EDIGenie as well. I'll get around to it. Good luck. "

Emmanuel Hadzipetros commented 9 years ago

"Thank you. Great question. I don't really know the 835 but if it's a Payment Advice probably REMADV because that will create a Payment Advice in SAP that you can then clear in AR. It's a flexible IDoc so unless there's some data in the 835 that can't be accomodated in the IDoc and that is required for AR clearing, you're probably OK. And remember ... all IDocs can be extended to accomodate anything. The key is what data does the SAP business process need for the inbound. For the outbound, it's what data does the recipient need for his backend process. Once you understand that, you know what you need to do with your IDoc. Good luck. "

PM

Paula macklefresh commented 9 years ago

"I am trying to find out what the functional differences are are behind the delivery advice, the shipment confirmation and the shipment advise. Trying to find the best fit for series of inbound 856's that will we are wanting to use for tracking the progress of inbound shipments from overseas. Can anyone shed some light on this for me, or point me in the right direction? "

Emmanuel Hadzipetros commented 9 years ago

"Thank you for your comment, Chandrasekhar. Message type WMMBXY with Basic Type WMMBID02 works. It's pretty well covered by MBGMCR with basic type MBGMCR03. The processing function for WMMBXY -- L_IDOC_INPUT_WMMBXY -- posts its goods movements through function MB_CREATE_GOODS_MOVEMENT. MBGMCR, on the other hand, which is processed by function IDOC_INPUT_MBGMCR, calls BAPI_GOODSMVT_CREATE. MBGMCR was generated from a BAPI. Both message types do essentially the same thing: post goods movements through a number of inventory transactions -- MB01, MB31, and so on -- and movement types. The supported transactions for MBGMCR are listed in table T158G. These transactions have all been incorporated into MIGO in the front end but are still called by the functions and BAPIs that update the inventory through the IDocs. I prefer MBGMCR because it's simpler and more recently introduced. Both will work, however. As for the EDI, you can use any of the transaction sets you'd use for MBGMCR, and more. You can, as I have been saying, essentially map pretty well anything to anything. Thanks again for your comment. "

Emmanuel Hadzipetros commented 9 years ago

"Daniel: Thanks for your comment. You illustrate my basic point: you can pretty well map anything to anything. It's the business process, or application architecture, that determines what you need to map in any particular instance. Having said that, mapping DESADV to IFTMIN makes sense. I'll add it to my table. Thanks again for your input and I'd love to hear back from anybody else out there with further mapping suggestions. "

Alan Wilensky commented 9 years ago

"People ask me, ""why no canonical transaction library in EDI, and standard doc mappings to popular ERP?"" My, answer, ""there are conventions, not canons"". Other industries have Ontologies, where the meaning of field X is always X and can appear anywhere in any order. There is a new standard coming out of w3c (and believe me they can screw up a wet dream), called the Linked Data standard, which is kind of beyond me, but should allow the automatic, or rather simplified reconciliation of docs between trading partners. I think one semi beta org is called Good Relations, they are pushing a Linked Data implementation that works with X12 and EDIFACT/ early days yet. Will we ever have a world where the BPM will be in place so that an unknown, unapproved Trading (provisional) partner can push a button and get set up? Get the credit approved, automatically create doc exchange sets? You tell me. see http://www.heppnetz.de/projects/goodrelations/ "

Related SuccessFactors Compensation Tool Invalid username and password error while installing SAP Portal on RHEL6 with HANA DB.

That New SAP Cloud Acquisition PO Creation after Goods Receipt Taking the settlement - AB InBev In Data We Trust: Coming to Grips with Application Data CRM Pricing - Add Contdura Field

PLAY HOT FULL TRACK ARTISTS POUYA MOHAMMADI POUYA MOHAMMADI DAR SAYEH-E SARV DAR SAYEH-E SARV

About Advertise Guidelines Terms Privacy Feedback

© 1998-2018 Toolbox is among the trademarks of Ziff Davis, LLC and may not be used by third parties without explicit permission.

Smile Life

When life gives you a hundred reasons to cry, show life that you have a thousand reasons to smile

Get in touch

© Copyright 2015 - 2024 PDFFOX.COM - All rights reserved.