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.

I find the best way to perform this conversion is within your SAP system.  Mainly because SAP has given you a standard utility to perform the conversion.  All you need to do is populate a few fields of the incoming IDOC and populate the EDPAR table using transaction VOE4 with the internal and external customer numbers.  The Function Module used to process the IDOC takes care of the rest.  SAP uses the Sender Partner Number of the IDOC Control record along with the PARVW and LIFNR elements from the E1EDKA1 segment to look up the correct entry in the EDPAR table.  In your EDI maps you would populate the PARVW element with the partner function code for the external customer number (AG = Sold-To, WE = Ship-To) and populate the LIFNR field with the external customer number received in the EDI file from that partner.  All other fields would remain blank in the E1EDKA1 segment.

Sender Information Partner Number from the Control Record:

E1EDKA1 Segment for the Sold-To Partner (AG):

E1EDKA1 Segment for the Ship-To Partner (WE):

Use transaction VOE4 to populate the EDPAR table.  You enter the value from the Sender Partner Number in the IDOC control record in the Customer field, the function code for the partner in the Ext. Function field.  Note: The Ext. Function field will not be the same as the Partner Function (PARVW) element of the IDOC.  (AG in IDOC = SP on VOE4, WE = SH).  The External Partner is the number received in the EDI data from the customer which is also the number in the LIFNR element of the IDOC.  Int. no is the SAP customer number associated with the External number.

VOE4 transaction with required entries for the Sold-To and Ship-To for IDOC information above:

Using the EDPAR table for customer conversion allows this function to remain in control of those responsible for customer accounts.  Users can be trained to use the VOE4 transaction to update the EDPAR table so when new ship-to or sold-to numbers need to be added they can be done in a timely matter and not rely on other departments.  It also takes this responsibility away from the EDI group so they don’t have to maintain maps or tables for this function.

This function can be used for other incoming IDOCs as well.  You will need to check the Function Modules used to process incoming IDOCs to determine if EDPAR can be used for customer number conversion and on which IDOC segment you would send the external number.

Outbound IDOCs can use either the EDPAR table or the PUMA table to cross reference external customer numbers.  Again, it depends on the IDOC type.  I will cover this topic in a separate blog.

Duration: 1 hour

Speaker:  Craig Stasila, Principal, DataXstream

This one hour webinar will supply you with knowledge of features specific to the new upgrade, as well as an overview of the advantages that come with investing in NCo 3.0.

What Will Be Highlighted:

• Changes and new features brought upon by the NCo 3.0 update
• Demonstrations of best-practices for implementing new and existing NCo code
• Live demonstration of inbound and outbound function calls between a .NET solution and SAP ECC

Visit DataXstream at the IT 2011 Conference

What: IT 2011 Conference

When: March 15 – 18, 2011

Where: MGM Grand Hotel & Casino, Las Vegas, NV

Do More, With Less

Through our industry best practice tailored solutions and our rare combination of project leadership, thorough understanding of business processes and high level company goals, and SAP technical expertise, we allow you to achieve higher business performance,  maximize your return on investment, and truly do more, with less.

Come visit us at Booth 421 to learn more about these featured solutions:

• Server / Storage Virtualization
• SAP Solution Manager / CA Service Desk Integration
• SAP .Net Connector (NCo) 3.0 Upgrade
• SAP Upgrades
• Custom Integration and Product Development

Sign Up Now

Click Here to register for the event as a friend of DataXstream and receive $100 off your conference badge.

Leave Vegas A Winner!

Forget the slots. Fill out the form below and when you come by our booth you will receive a free DataXstream lanyard / flash drive filled with only the information that matters to you and be entered in to win our Grand Prize Giveaway at the end of the conference!

Vera Bradley – SAP EDI Integration As part of Vera Bradley’s SAP implementation, the EDI program was critical to the sales of their designer products. Having no internal resources to tackle this task and being on a tight deadline, Vera Bradley needed a means to rapidly integrate SAP and Gentran Server for Windows.

View More Case Studies

Applied Materials – SAP PI Integration Applied Materials needed to connect various systems to SAP MDM using SAP PI 7.0. These interfaces were mission critical, and needed special consideration in design and implementation. Another team had already began work but had run into problems with interfacing to custom applications communicating with MDM.

View More Case Studies

Greenlee Textron – Xstream Connector Integration Textron needed to enhance their ability to manage accounts receivable collections, disputes and deductions beyond that delivered by standard SAP functionality. Owing to its extensive functionality set and ease of use, Textron chose the Cforia software package for this purpose. Now they needed a means to rapidly integrate SAP and Cforia.

View More Case Studies

Intradeco Apparel – SAP WMS Integration For Intradeco Apparel, the integration of their third-party Catalyst Warehouse Management software was paramount to the go-live of their SAP system. Intradeco had tried twice before to go live with SAP, each time ending in failure as the integration to their legacy system was not done well enough to limit business risk.

View More Case Studies

Pure Fishing, Inc. – Integration with SAP .Net Connector Pure Fishing needed a new and standardized solution to allow seamless interaction between their SAP systems and third-party warehouse management software that was more reliable and flexible then custom integration approach used in the past.

View More Case Studies

Other companies may have consultants that match ours in talent, but no one matches our skill. Talent is natural. Skill is only developed through tremendous work ethic and endless hours dedicated to honing one’s craft. Our craft is SAP: from the program level down to the specific functional, technical, and administrative details. Our depth of understanding and experience in SAP allows us to clearly see the big picture, and our detailed SAP expertise is used to build solutions that match your vision.

Because Experience Matters

DataXstream offers senior level consultants covering many types of SAP consulting services. Our deep domain expertise, particularly in technical activities, enable customers to tackle complex, challenging projects where time is of the essence. Averaging over 10 years SAP experience per consultant, we can fill most roles from analyst to project lead, to solution manager. When hiring DataXstream, you gain the commitment to success that is reflected in our 100% project success rating.

DataXstream’s range of services include:

Infrastructure Assessment and Systems Architecture

Whether you are looking to implement SAP for the first time, perform an upgrade, merge several legacy systems together, or virtualize your landscape (SAP or otherwise), it is critical that you take the proper steps in preparation for your work.  DataXstream can work with you to design a system landscape that is able to meet your business goals and adapt to business growth in the short, medium, and long- term.  We will review your existing hardware, software, systems architecture solutions (SAP and non-SAP) and make recommendations regarding the design of your system and the applications you need.  We will determine the sizing requirements for your new landscape (including the amount of hardware, storage, servers, etc. that is needed), identify gaps in hardware and software between your present system and the one proposed, and obtain all required licenses.  At this stage, we will also make recommendations as to whether to engage in a virtualization process or not.  If you decide it is in your company’s business interests, we will use our technical expertise to virtualize your landscape.

 Project Management

Once you have architected the optimized and efficient IT infrastructure needed to support your SAP system, DataXstream can assist you in the management of your SAP projects.  We work collaboratively with customers to develop and deliver strategies and engagement plans for projects in all phases of the SAP lifecycle; including implementations, development, integration, upgrades, data management, and support. We provide realistic project forecasts, deliverable timelines, estimated costs, and resource needs.  Whether it is during the stage of pre-implementation, execution, or post-implementation of your project, DataXstream remains highly involved in the process and can work with you on strategy, tactics, and execution.

SAP Technical Development and Functional Configuration

Once you have your infrastructure and the specifics of your envisioned SAP solution in place, DataXstream’s SAP experts can do the nitty-gritty work to make your plan into a reality. Our team of senior developers dive into the programming world of ABAP, BAPI, RFC, XI, PI, IDOCS, ALE, .Net, Java Connectors, as well as a number of middleware integration platforms, working to meet all the functional and technical specifications of your SAP system.  Our consultants have the necessary mix of  project leadership, thorough understanding of  business processes and goals, and SAP technical expertise to deliver solutions that are both technically-sound and business-process optimized. This work involves configuring all critical components of the SAP system, developing custom applications to enhance the capabilities of standard SAP solutions to meet your unique needs, and testing each of the SAP components to ensure your system performs as desired.  We integrate all critical process,  data sources, and third party software with SAP; cleanse and migrate data as necessary into your SAP system; leverage SolMan’s rich tool set to better manage and support your system throughout the application lifecyle; and provide the Basis administration to KTLO and support your SAP system’s day-to-day activities.

Support

As you are engaging in your SAP project, DataXstream can assist with every phase of an SAP lifecycle.  Our consultants have been through countless SAP lifecycles and have experienced the details of every stage. We know when certain support activities need to be done and can plan pro-actively to resolve them to eliminate unnecessary issues. DataXstream also understands the need for process discipline, along with clear communication during an SAP lifecycle, and can assist you with putting such critical processes in place. When it comes to your support needs, DataXstream can assist in planning and vision, full post-production support, and adaptation of the support model as you respond to internal and external changes.

Upgrades

At some point in time, it may become necessary to upgrade your SAP landscape.  When that day comes, DataXstream can assist you.   DataXstream has been helping companies with SAP upgrades since 1998.  Consequently, we understand upgrades and the need to execute upgrades quickly and effectively to minimize disruption and ensure business continuity.   Our upgrade process involves understanding your technical and business environment in order to establish an approach that meets your business goals; assessing your existing infrastructure and doing a gaps analysis between what exists now and what is needed for the upgrade; and executing on the upgrade plan.  If it is in your company’s best interest, DataXstream can also virtualize your landscape before executing the SAP upgrade.

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.

Conventional Wisdom: Why You Don’t Go-live Mid-Month

My big disclaimer is that each SAP project has unique characteristics and what worked for us may not work for you, nonetheless I encourage you to keep an open mind and push until you find your insurmountable barrier, if it exists.  I would even contend that one of the biggest barriers may be your most experienced project team members and their gut reaction.  I admit my first reaction to the suggestion was “NO,” but as we drilled into the specifics of our project my inchoate objections crumbled.  The conventional wisdom is typically grounded in truth and experience, but conventional wisdom only applies to conventional situations.  To use a consulting cliché: challenge your assumptions.

In our research we found a consensus that there are three main areas that make a mid-month cut-over a bad idea.

Assets: I’m no expert on assets but the general word was that depreciation gets “messed up” if you cut over mid-month.  Owing to my limited experience in this area I’ll take that on faith, but this was not considered an issue as assets was out of scope for our project and asset postings will be done by journal entries.

Payroll: Again, I’m not an expert on payroll, but this was another situation where payroll was out of scope as the process is outsourced to a third party provider and journal entries are posted instead.  It was not considered a show stopping concern.

Year-to-Year Period comparisons: by cutting over mid-month some folks on the interwebs expressed concern that the month-over-month comparison for the go-live year would be no use until the third year.  Let’s say you go-live in the middle of June 2010 with partial balances in SAP (the remainder being in the legacy system), when June 2011 comes around you can’t compare the two Junes because one month is partial and one is complete.  You have to wait until June 2012 for a meaningful comparison.  This was not an issue for us because we converted three prior fiscal years of account balances with the go-live month balances being the balances as of the go-live date along with the transactional activity for the rest of the month.

Factors Leading to an SAP Mid-Month Go-Live

The ugly truth is that we went live mid-month out of necessity, not by choice.  Our original plan was to go-live on the first of the month, but we weren’t ready and a focused re-planning exercise identified that we could go live three weeks later.  Changing the go-live date to the first of the next month was not acceptable for a variety of reasons, including political considerations – it’s never a purely technical decision, so no surprise there.

Adapting the SAP Go-Live Strategy for Mid-Month Cut-Over

Once we knew we were going live mid-month we had to work out how to handle key areas of functionality: particular areas of interest were open A/P items, inventory balances, customer deposits, and the GR/IR account.  On top of this historical account balances needed to be loaded and we needed to ensure that FI conversions reconciled with logistics conversions.

Finance and Logistics Reconciliation

We came up with an approach that allowed us to readily identify differences between account balances converted by FI compared to the conversion by MM.  Consider the example of inventory conversion.

Standard SAP postings for the initial inventory balance with movement type 561 post to a pair of accounts similar to these:

• DR Inventory (135010)
• CR Conversion account (399175)

Instead of making this posting we changed the account determination for MM conversion to post as follows:

• DR Inventory (135010)
• CR Inventory conversion (135011)

Now when we converted historical balances into FI the inventory posting was:

• DR Inventory conversion (135011)
• CR Conversion account (399999)

The benefit of this approach was that any balance on the 135011 account meant there was a difference between what was converted via MM and via FI.  This became the basis of the work list that had to be reconciled.  The actual operational G/L account for inventory (135010) could be used immediately after the go-live without worrying about it becoming part of the ongoing reconciliation process.

Also, standard SAP does not allow direct posting to the inventory account (135010) and this approach allowed us to leave it as delivered.

We used a similar process, i.e. a conversion account instead of operational account, to support the cut over for accounts payable, customer deposits and the GR/IR account.

GR/IR Conversion

In our environment we are fortunate to have a situation where invoices are not received before the goods.  Consequently at the time of conversion there were purchase orders where goods have been received and not invoiced.  The typical GR/IR process is as follows:

Goods Receipt:

• DR Inventory (135010)
• CR GR/IR (211200)

Invoice Receipt:

• DR GR/IR (211200)
• CR Accounts Payable

At the time of conversion the good receipt has already happened and we did not want to reconstruct the PO processing so that we could use MIRO processing when the invoice is received.  Instead we converted historical balances for the GR/IR account by posting to a new account, 211201 as follows:

• DR Conversion account (399999)
• CR GR/IR conversion (211201)

Now when the invoices are received they will be posted with an FB60 transaction as follows:

• DR GR/IR conversion (211201)
• CR Accounts Payable

We know we are giving up some integrated capability for a period of time until these purchase orders and invoices wash through the system, but it means that once the GR/IR conversion account gets to zero we are done.  The typical life cycle for PO is 6-8 weeks so this is a temporary situation.  The true GR/IR account, 211200, will be used as intended and the benefits of MIGO and MIRO processing will be realized.

Month End Processing in the Old System

Going live mid-month also meant that the prior period was closed in the old legacy system and the month end balances were converted over in the same way as any other period.  It was a straightforward extension of our process to pull the mid-month account balances from the legacy system during go-live weekend and load them into SAP, too.

Financial Statement Impacts

The approach that we took meant we introduced several accounts to the chart of accounts for conversion only.  Consequently we had to update our financial statement versions to include these accounts and assign them to the correct positions in the report structure.  Clearly this is not a difficult task, but one that is needed.

SAP Mid-Month Go-Live Conclusions

I am skipping over some of the detailed considerations of how we made a mid-month go-live work for our project.  The details of how to make it work, the nuts and bolts of reconciliation, how we tested it (iteratively!), how we worked the differences identified between FI and MM/SD conversions, etc. aren’t here.  It wasn’t always easy and we had to do it in a short amount of time, but my key message is that we found a way to do it: the conventional wisdom wasn’t and isn’t necessarily wrong, just we found another path.