SAP IDOCs for Customer Number with different Sales Organizations to different External Partnerships

Have you ever implemented an outbound  EDI process from SAP for a single customer number where the customer has multiple EDI trading by Sales Organization or Division?  It can be done.  In order to accomplish this you will need to create separate output types for each Sales Organization/Division and then set up the Access Sequence/Output Determination in order to create the IDOC for each partnership.  You can then use the Message Variant and/or Message Function fields of the Partner Profile to differentiate between the two Sales Organizations/Divisions.  Finally, you would set up your EDI Mapping to look at the Partner Profile fields in order to route it to the correct partnership.  Let’s take a closer look at this process.

Let’s say that Customer 15 in your SAP system buys products from your company.  It sends inbound EDI Orders to you using three different partner IDs because they have 3 internal divisions and they want all transactions to be separate.  You want to keep all sales data for this customer under one customer number in your SAP system and just separate them by a different division.  You are required to send out EDI invoices to this customer, but they must go to the correct EDI Partner ID.  Let’s say you would normally use the Standard SAP Output Type RD00 and  Access Sequence 0003 (Sales Org, Distribution Channel, Division, Customer Number) for producing your INVOIC IDOCs. [Read more...]

SAP EDI EDPAR Table Walkthrough – How to Cross Reference External Customer Number to SAP Customer Number (Part 2)

Let’s say you are receiving EDI ANSI X12 850 Sales Orders from you customers that need to be uploaded into your SAP System using the ORDERS05 IDOC.  Most customers will have their own internal customer numbers that they send in their EDI transmissions to represent the Sold-To and Ship-To partners.

How do you convert these external customer numbers into your internal SAP customer numbers?

Some may hard code these conversions into their EDI maps.  This approach can be very high maintenance as customers can add new ship-to locations or reorganize their internal numbers which would require changes to your maps.

Others may set up a cross reference table within their EDI translation table to perform the conversion.  This works well at times, but then you are at the mercy of your EDI group to update the table with any new additions or changes to existing entries. [Read more...]

SAP EDI EDPAR Table Walkthrough – How to Cross Reference SAP Customer Number to External Customer Number (Part 1)

When creating IDOCs in SAP to send Invoices to customers via EDI you will likely have to send the customers their internal partner numbers on the EDI ANSI X12 810 Invoice Document.  In almost all cases this will not be the same as the SAP partner numbers.  So how can we set up a cross reference of SAP and external partner numbers?  Well, the answer is simple because SAP has set up a utility to handle this for you.  All you need to do is populate the EDPAR table in SAP using the VOE4 transaction.  Once this is completed the IDOC_OUTPUT_INVOIC function module will read the EDPAR table when the Invoice document output is processed and populate the LIFNR element of the E1EDKA1 or E1EDPA1 segments of the INVOIC IDOC with the external partner number.  Entries in EDPAR can be set up for multiple partners including the Sold-to, Ship-to, and Bill-To numbers so that external customer number cross-references can be passed on the IDOC if needed.

Let’s look at how this process works.  Let’s say we have created an invoice document in SAP.  In this case, the Sold-to, Ship-to, and Bill-to partners are all SAP customer number 15.  If we want to create an INVOIC02 IDOC on which the external customer numbers are populated for all three of these partners we would have to set up three EDPAR entries as displayed on the below screen shot.  The Customer field will contain the SAP partner number (Sold-to, Ship-to, Bill-to).  The Ext. Function field will contain the Partner Function (SP = Sold-to, SH = Ship-to, BP = Bill-to).  The External Partner field will contain the external partner number that the customer is expecting on the EDI file.  And the Int. no. field will contain the SAP partner number (Same as the Customer field).

[Read more...]

Discussing SAP SOLMAN Service Desk Integration Scenarios

When you purchase SAP ERP, you get SAP Solution Manager (SOLMAN) as part of the deal – ostensibly for free (although it is really included in the purchase price).  SOLMAN provides a wealth of functionality to help manage the technical environment as well as project processes like testing.

Service Desk functionality is delivered as part of SOLMAN for use as a ticketing system.  One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already.  In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP.  Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes, which obviously reduces the risk of transcription errors.  And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management. [Read more...]

SAP Go-Live Lessons Learned

In real estate the key factors in making the sale are location, location and location.  In an SAP project I’m coming round to believing that success requires testing, testing and testing.

A Short Selective Retrospective on Key Constituencies

All project events and project success stem from testing and testing well.  I’ve written about various types of testing before and how that can lead to some confusion because of issues with definitions.  Here I want to discuss some areas where testing really can make or break a project and ideas for how to minimize the chances of things turning out badly. [Read more...]

Introducing SAP .NET Connector (NCo) 3.0

This past summer, SAP announced a new version of SAP Connector for Microsoft .NET — NCo 3.0.  SAP decided to give us an early Christmas present when they officially released NCo 3.0 on December 22, 2010.  You can download NCo 3.0 at http://service.sap.com/connectors (you will need an OSS logon).

Included in the downloads are documents that discuss the notable changes from .NET Connector 2.0 and a very comprehensive help file (in .chm format).  Noticeably absent are complete samples, although SAP claims that the included tutorial will be updated.

Additionally, I already have my first NCo 3.0 project under way, so check back soon for more information about NCo 3.0!

Happy Coding!

[UPDATED]

Additional Information

Follow these links for more information about NCo 3.0 programming:

SAP Mid-Month Go-Live: Got the T-shirt

Conventional wisdom says you don’t go-live with SAP financials in the middle of the month (strictly speaking I should say the middle of the accounting period, but I’ll say month as a generic term for the posting period).  I recently went through a mid-month SAP financials and logistics go-live and so far it has been a success.

Initially the project team had the expected you-can’t-do-that reaction when the idea of a mid-month go-live was suggested.  We took three main steps to determine whether or not we were crazy or had a viable go-live option:

  1. We asked SAP.  As one of the main participants on the project we got them to do an internal review with some platinum consultants with the objective of telling us why we could not go-live mid-month.
  2. We asked our project team, both client and consulting resources.  Again, the goal was to tell us why we couldn’t do it.
  3. We Googled like maniacs to find something to support and justify the conventional wisdom.  We failed to find anything substantial that would deter us.

Armed with the conviction that there was no reason we couldn’t go-live mid-month we set about defining the details of how we would pull it off.

[Read more...]

SAP Project Management Consulting Clichés – Part 2

Following my previous post I got a couple of responses from folks out on the interweb and decided I’d steal their suggestions and expand on their consulting clichés.  After all repetition and overuse are the start point for any cliché and this means I’m doing my part to sustain the cycle – reuse, recycle, renew!

Is Your Project a Hotbed of SAP Consulting Clichés?

I felt compelled to come up with a 2-by-2 matrix to help you decide whether your project is cliché generator or a cliché consumer.

[Read more...]

SAP Solution Manager Service Desk Integration

Nowadays when you install SAP ECC 6.0 you get SAP Solution Manager (SOLMAN) as part of the deal – ostensibly for free (although it is really included in the purchase price).  SOLMAN provides a wealth of functionality to help manage the technical environment as well as project processes like testing.

Service Desk functionality is delivered to you for use as a ticketing system.  One of the features of it is that it can be used as a ticketing system for both SAP and non-SAP systems as well as in conjunction with other ticketing systems that may be in place already.  In this blog post I’ll briefly touch on some of the scenarios I have encountered and show that there are several ways to deploy Service Desk.

Using Service Desk is beneficial because it can automatically capture a wealth of information about what a user was doing when a problem occurred if the ticket is created directly from SAP.  Also, Service Desk can communicate directly with the SAP mother ship to log issues and manage OSS notes which obviously reduces the risk of transcription errors.  And Service Desk can be extended to include functional components from non-SAP systems which in turn leads to the possibility of one-stop-shopping for ticket management. [Read more...]

SAP PI CTS+: Letting CTS+ Out of the Bag to Get Better Change Management

Anybody familiar with older versions of SAP XI/PI understand that transporting interface development and configuration changes is often a prickly situation.  Standard change management in PI relies on the manual packaging and processing of changes into files.  These files have many issues:

  • No documentation
  • A different means of transport than standard SAP transports (need some training people used to ABAP transports)
  • Manual audit accountability (what do you do if you lose an exported PI .tpz file)

To help resolve these issues, SAP released CTS+.  But, what is CTS+ and how can it help?

[Read more...]