How to Question about Partner Type LI for Intercompany Billing
[SD-IDoc]Question about Partner Type LI for Intercompany Billing
This question is answered
Hi All,
I'm customizing configuration of IDoc for Intercompany Billing of Cross-Company-Code Sales. The purpose is that when the Intercompany Billing is saved, the Billing Output RD04 will generate an Outbound IDoc in the Issuing Company. Then an Inbound IDoc will be automatically generated in the Sales Company. Thus, the Inbound IDoc will trigger the SAP automatically post FI document for Vendor in Sales Company. That's because Issuing Company plays a role as vendor for Sales Company.
Both 2 companies are in the same client. And the test is OK. But, I have a question about Partner Type LI for Partner Profile for Inbound Processing.
As I know, if both sender and receiver of IDoc are in the same client (or we can say, both uses SAP), the Partner Type for Inbound Processing should always be LS. However, after testing and checking, I found that for this case, the Partner Type MUST be LI for Inbound Processing. Is this case an exception to the rule?
Thanks.
Michael Hwang
Former Member
August 05, 2015 at 03:27 AM
0 Likes
Correct Answer
Jelena Perfiljeva replied
August 04, 2015 at 21:06 PM
Michael, searching for logic in the SAP design might be an exercise in futility. If anything, inter-company process ends up with posting an FI document, so there are two different modules involved. These modules were built by different teams who apparently had different ideas (e.g. why FI correspondence doesn't work the same way as Output in SD?). Inbound/outbound deliveries are part of the same SD module, so I guess that team just chose another design. Who knows? From the ABAP standpoint there is no restriction to use either - all the relevant information should be in the IDoc anyway. But when the partner is LI, KU, etc. (not LS) it's just a bit easier because then some data is in the IDoc control record.
For the SAP standard solutions like inter-company we just read the documentation and do whatever is there. For a custom IDoc interface you'd use whichever partner type would be appropriate for the specific interface. If the interface is not with a specific customer, vendor, etc. then it'd be logical to use LS.
1View this answer in context
Helpful Answer
by
Jelena Perfiljeva
Not what you were looking for? View more on this topic or Ask a question
8 replies
G Lakshmipathi replied
July 30, 2015 at 13:35 PM
Similar discussion have taken place here
Message determination and Partner function LS (... | SCN
G. Lakshmipathi
0 likes
Former Member replied
July 31, 2015 at 07:14 AM
Hi Lakshmipathi,
Thanks for your reply.
I'v read the thread you mentioned. But, they are not the same cases.
My point is that, in my case, why the Partner Type for Inbound Process is LI instead of LS?
Hope to get more information from you.
Thanks
Michael Hwang
0 likes
Former Member replied
July 31, 2015 at 11:36 AM
Hello Michael,
Just to help : LS stands for "Logical system" and isn't defined as a Partner role in SAP in the same way a vendor, a Customer is.
'LS' Partner type required correct ALE parameter (Server / port config plus a bunch of other customizing points) and usually represent an external system (Under SAP or not).
If interested, you can define logical system using BD54 tcode.
On your requirement, I'd say than you need to properly customize your Partner LI using the vendor number ID needed.
Please have a look at the following thread : It's "Answered" and seems to be the same issue as yours.
http://scn.sap.com/thread/555215
Don't hesitate to share your solution
Best regards,
Emeric.
0 likes
Former Member replied
August 04, 2015 at 05:01 AM
Hi Emeric,
Thanks for your reply.
In my case, the testing environment is client 800 of IDES with demo data of EHP6 for SAP ERP 6.0. The Logical System is pre-configured and assigned to client 800. Both customer and vendor master data are maintained in this client. And, customer 22000 belongs to company 1000, vendor belongs to company 2200.
Please refer to the following screenshots of key configurations shown below
1.1 Outbound Parameters of Partner Profiles
1.2 Outbound Options
1.3 Outbound Message Control
1.4 Outbound Process Codes
2.1 Inbound Partner Profiles
2.2 Inbound Options
2.3 Inbond Process Codes
3 EDI: View of EDILOGADR for application V3
4. EDI-INVOIC: Program Parameters
5. FI-EDI: G/L Accounts
6. EDI: Conversion of External Tax Rate <-> Tax Code
After the above configurations are done, I had a test for Cross-Company-Code Sales, as the screenshots shown below:
1. Billing Output
2. IDoc Display
3. Accounting Document of Invoice Receipt generated by Inbound IDoc
From the screenshots above, we can see that the IDoc function is working properly.
In order to confirm that Partner Type LI is mandatory for this case, I deleted the Partner Type LI for Inbound Partner Profiles, and created Partner Type LS for Inbound Partner Profiles instead. Then, there was error message during re-test regarding lack of Partner Profile of LI.
My question: Why don't (or why can't) we use Partner Type LS for Inbound Partner Profiles?
Thanks.
Michael Hwang
0 likes
Helpful Answer
Jelena Perfiljeva replied
August 03, 2015 at 22:25 PM
Partner type has nothing to do with the sender and receiver being in the same system/client or not. In the inter-company billing scenario we have a vendor/customer relationship and partners need to be defined accordingly for each company.
It can be a bit confusing because it's logical to think "oh, we are communicating with the system here, so our partner type should be LS", but by that measure why would we ever need any other partner types? All interfaces involve some kind of system, right?
In this scenario we're not actually just dumping data into one system (and let it sort it out), it's a transaction between specific customer and vendor. Even though you could send output to LS partner, I suspect you'd have trouble getting the inbound part to work because there are programs looking specifically for the vendor/customer linkage to the company code in the configuration.
0 likes
Former Member replied
August 04, 2015 at 09:09 AM
Hi Jelena,
Thanks for your help.
In the scenario of Cross-Company-Code Sales, the Partner Type MUST be LI for Inbound Partner Profiles, and it is working properly.
In order to make my question clear to you, I'll show you another scenario which uses Parter Type LS for Inbound Partner Profiles.
In the Cross-Company-Code Stock Transfer scenario, after the GI is done for Outbound Delivery in Issuing Company, an Outbound IDoc is generated through output type LAVA. With IDoc technique, and Inbound IDoc is generated by IDoc Interface. Thus, an Inbound Delivery is created autocally in Receiving Company by function module. In this scenario, the Partner Type MUST LS for Inbound Partner Profiles.
Here comes my question: When do we need a Partner Type LS for Inbound Partner Profiles?
Hope to get your reply.
Thanks.
Michael Hwang
0 likes
Correct Answer
Jelena Perfiljeva replied
August 04, 2015 at 21:06 PM
Michael, searching for logic in the SAP design might be an exercise in futility. If anything, inter-company process ends up with posting an FI document, so there are two different modules involved. These modules were built by different teams who apparently had different ideas (e.g. why FI correspondence doesn't work the same way as Output in SD?). Inbound/outbound deliveries are part of the same SD module, so I guess that team just chose another design. Who knows? From the ABAP standpoint there is no restriction to use either - all the relevant information should be in the IDoc anyway. But when the partner is LI, KU, etc. (not LS) it's just a bit easier because then some data is in the IDoc control record.
For the SAP standard solutions like inter-company we just read the documentation and do whatever is there. For a custom IDoc interface you'd use whichever partner type would be appropriate for the specific interface. If the interface is not with a specific customer, vendor, etc. then it'd be logical to use LS.
1 likes
Former Member replied
August 05, 2015 at 03:35 AM
Hi Jelena,
Thank you very much for your clarification. It's really helpful to me.
Michael Hwang
