PO & SO Integration By IDOC in CNABB

PO & SO Integration By IDOC in CNABB

话说博主来ABB一个多月时间了，虽然对ABB系统内的流程和配置不是很了解，但对ABB系统内使用的PO和SO通过idoc自动创建的这个solution还是比较感兴趣的，正好抽这个周六的下午来对这种方案做一个总结和demo.

下面这张flow就很清楚的阐述了每一个流程节点和单据是怎么流转的在buyer和seller之间。几乎每一个buyer和seller之间的inter-transaction 都是通过IDOC来实现的。从SO的创建，order acknowledge, shipping notification,以及最终的invoice verification。

下面就以CNABB 向CNIIB(北京低压)进行采购的业务为例，看下系统的配置点和操作流程。

Step1: define partner profile for vendor CNIIB

Port: P06800 definition WE21

The RFC destination was maintained in SM59 with ABAP connection.

Step2: maintain condition record for output type NEU T-code MN04

Step 3: define partner profile for inbound message type; LS Q08800 the name is as same as logical system name.

partner profile status: you need to activate this pratner before use.

This partner profile is responsible for creating incoming SO. And the data is used in outbound IDOC.

STEP4: sales area and order type determination for SO. T-code VOE2;

The sold to party is determined from vendor master data as below:

However in the real case, customized logic exists in user-exit to determine the real sold to party.

FUNCTION MODULE: IDOC_INPUT_ORDERS

EXIT_SAPLVEDA_011

For example, vendor 300004 is maintained with acct w/vendor 3000003. But in idoc sold to party 3000004 is used.

Step 5: ship to party determination; VOE4

Here sap use 3000003 instead of 3000004 to determine ship to party;

External partner: we can get LIFNR from idoc segment E1EDKA1 WE

Get ship to party number by combination of customer and external partner. Here the 1006 is the plant in the purchase info record. You have to maintain this inorder to determine ship to party for incoming SO.

Step 6: how the material no determined in SO.

Use the vendor material no. maintained in info record.

Till now, the internal so will be created by idoc successfully.

Step 7: order confirmation transfer back into po by IDOC

Message type: BA00

Partner profile: 3000004

Partner profile: Q08800

After the message type BA00 was successfully issued, there ‘ll be two idoc generated at the same time.

After inbound idoc has be outputted with status 53. Check up PO confirmation tab in ME23N.

Before OA message issue, the confirmation key needs to be maintain in po# or pre-defined in vendor master data or info-record.

Pls note: if rejection code exist on SO item, the error will be sent in inbound IDOC.

Step8: after OTD is issued, OUTPUT TYPE LALE will be triggered and shipping notification will be created in purchase side.

Message type DESADV is used in partner profile.

Same message type will be used Inbound partner profile.

Two IDOC(Inbox and outbox) will be created simultaneously.

Status 52/53 shows up on the inbound IDOC. Inbound delivery note has been created.

T-code VL33N to check inbound delivery note.

Normally user could user VL32N to post inbound goods delivery. Due to EWM is used in CNABB, so that inbound delivery needs to be posted in EWM.

Step8: After billing create for end customer, IV document will be generated through IDOC.

Message type INVOIC will be used in both inbound and outbound idoc.

Maintain company code for incoming invoice.

OUTPUT TYPE ZRE4 will be triggered in VF03.

If dispatch time is maintained as 1, in vv31. Then you will not get the data in T-code VF31.

Same as above steps, two idoc will be created at the same time.

MIR4: Display the vendor invoice document

这里IV的配置应该和cross-company sales的IV不太一样，cross-company sale因为没有PO所以要设置其他的东西，这个在之前关于cross company scenario 的博文里有讲到。

If the following error shoots, go to t-code SLG1 for more application log details.