Day: January 27, 2018

Overview

SAP ECC and S/4 Invoice have a concept of Invoicing Party when creating an MM Invoice.

The Ariba Network and Ariba Purchasing and Invoicing (P2P, Invoice Pro) has a similar concept, but it is called Remit To ID.

On a scenario where a customer has multiple Invoice Parties (addresses) for a single Vendor, we want the integrated SAP ERP and Ariba solution to handle as the following:

If the Invoice Party is selected on the SAP ERP PO, the Invoice should use that Invoice Party on the Invoice.

If the SAP ERP PO does not contain the Invoicing Party, the Supplier should have the option of informing the Remit to Address (Invoicing Party to be used).

This scenario can be different for other customers, where the IP selected by the supplier may take precedence on what is informed on the PO. Or we can use use SAP Ariba Invoice Management (aka Invoice Pro) to select the correct Invoicing Party during Invoice Reconciliation.

The solution described bellow can be altered to support such scenarios.

How it works on SAP ERP (ECC or S/4)

We can maintain 1 or more Invoicing Parties – as Partner Function “IP – Invoice presented by” – on the Vendor Master / Partner Function area [tr. XK02].

When creating a Purchase Order for a Vendor that has more than 1 Invoicing Party on the Vendor Master Data, by default the system will prompt the buyer to select an Invoicing Party on the PO.

The buyer may or not select the IP on the PO [tr. ME21N].

When creating a PO Invoice document, by default the system will use the Invoicing Party defined on the PO. If no Invoicing Party is defined on the PO, the system will use the Vendor ID as the Invoicing Party. [tr. MIRO]

How it works on Ariba Network

On the Ariba Network, the Supplier can inform the Remit to ID as a free text field or select if from a predefined drop-down list of values.

The drop-down lit of values is maintained on the Ariba Network Supplier Account, on menu path: Company Settings -> Remittances.

The Supplier can maintain several Remit to addresses.

And for each address can maintain 1 Remit to ID for each Buyer that has trading relationships with on the Ariba Network.

Drop-down list

Free text entry

Alternatively, customers may use Ariba Invoice Management (aka Invoice Pro) to select the appropriate Remit to address, and if using the BSAO adapter to transmit invoices from the Ariba Network to SAP ERP, use the solution bellow to handle the Invoicing Party mapping.

How it works on the BSAO Adapter

By default the BSAO Adapter uses the Invoice Vendor ID as the Invoicing Party on ECC.

The Configuration table bellow is used to maintain manually maintain the Invoicing Party per Vendor ID and Sold to name Name attribute. That configuration works if we have a static Invoicing Party for each vendor, but if the IP can be different based on some criteria, the configuration is not sufficient.

SPRO path: Integration with Other SAP Components -> SAP Business Suite Integration Component for Ariba -> Application-Specific Settings -> SAP ERP Integration Component for Ariba -> Integration for Buyers -> Define Mapping Settings for Invoices -> Incoming Invoice: Map cXML Partner to ERP Invoicing Party

Please note that this is also true for the S/4 HANA Native Integration for Ariba Network. And the same code snippet should work there.

BSAO Customization

You can use the following code snippet in the mapping BADI ARBERP_INBOUND_MAPPING, method INVC_INV_PARTY_DETERMINATION, to map the correct Invoicing Party on incoming Invoices from the Ariba Network.

The snippet bellow does the following:

* If the PO has the Invoicing Party partner function informed, use it as the Invoicing Party ID
* Else, use the Remit to ID on the Invoice document from Ariba Network

* If both values are not found, the Invoicing Party will be:

* The value maintained on BSAO Invoicing Party configuration table
* Or the Vendor ID

  method IF_ARBERP_BADI_INB_MAP~INVC_INV_PARTY_DETERMINATION. data: ls_invoice_part type ARBERP_XINVC_S_INVOICE_PARTNER, ls_inv_det_ord type ARBERP_XINVC_S_DTL_ORDER, lc_po TYPE EBELN, lt_po_part TYPE TABLE OF BAPIEKKOP, ls_po_part TYPE BAPIEKKOP. *——————————————————————–* * Get the Invoice Party from the PO document *——————————————————————–* LOOP AT IS_CXML_INVC-INVOICE_DETAIL_ORDER INTO ls_inv_det_ord. IF ls_inv_det_ord-INVOICE_DETAIL_ORDER_INFO-ORDER_REFERENCE-ORDER_ID IS NOT INITIAL. lc_po = ls_inv_det_ord-INVOICE_DETAIL_ORDER_INFO-ORDER_REFERENCE-ORDER_ID. CALL FUNCTION ‘BAPI_PO_GETDETAIL1’ EXPORTING PURCHASEORDER = lc_po TABLES POPARTNER = lt_po_part. READ TABLE lt_po_part WITH KEY PARTNERDESC = ‘IP’ DELETE_IND = space INTO ls_po_part. IF ls_po_part-BUSPARTNO IS NOT INITIAL. CV_INV_PARTY = ls_po_part-BUSPARTNO. exit. ENDIF. ENDIF. clear: ls_inv_det_ord. ENDLOOP. *——————————————————————–* * If there is no Invoice Party on the PO, or if it is a Non-PO Invoice * Get the Remit to AddressID on the Invoice cXML as the Invoice Party *——————————————————————–* IF ls_po_part-BUSPARTNO IS INITIAL. READ TABLE IS_CXML_INVC-INVOICE_DETAIL_REQUEST_HEADER-INVOICE_PARTNER WITH KEY CONTACT-ROLE = ‘remitTo’ INTO ls_invoice_part. IF ls_invoice_part-CONTACT-ADDRESS_ID IS NOT INITIAL. CV_INV_PARTY = ls_invoice_part-CONTACT-ADDRESS_ID. ENDIF. ENDIF. endmethod. http://bit.ly/2njBtYC #SAP #SAPCloud #AI

In the interactions I’ve had with HR professionals, I’ve come to respect the challenges of the profession. Their role is to take a very complex system of processes and tools and simplify the concepts so that their customers – the company’s employees – can understand and use them to make decisions, manage careers, and engage with the organization.

This is a huge challenge, especially when you take into account the role of human capital management (HCM) technology and the multiple screens required in order for employees to have access to HR tools “whenever and wherever they need them.”

Today’s employees have considerable expectations around having constant access to workplace technologies; they come to the job already mobile-savvy due to the apps they use outside of work, which are quickly setting the standard for workplace apps. However, the terms of “whenever and wherever” are outdated, oversimplified mis-characterizations of how mobile software should work. A great user experience, not an over-abundance of capabilities, is one of the key factors ensuring employees will use and enjoy a mobile app.

In my experience, workplace mobile apps often fall flat when it comes to engaging employees because the mobile experience hasn’t been thought through. Many times, mobile features are treated as a checklist, and the assumption is that if a feature is available on the desktop or web platform, it must be made available on mobile. Frequently, I’ve been asked to make mobile work exactly the same as the web platform, at times even getting so granular as specifying the same number of clicks or taps. While general consistency between mobile and desktop platforms is a good thing, the fact is that from the user’s perspective, these platforms are different. Forcing one platform to conform to the other without consideration to how users interact with each is exactly the opposite of providing a great user experience.

At SAP SuccessFactors, our mobile design stems from one key question: What is it that the user wants  to do on mobile?  We’ve found that ultimately, people are not going to use mobile devices to execute every aspect of HR, the way they might use a desktop. But we also know that given how pervasive mobile devices are in our lives, there are some processes and connections that are actually enhanced in a mobile environment—and these are the very ones we focus on incorporating into our app.

First, consider when people typically use their mobile devices. While there may be times when you are stuck at an airport and are forced to work on a mobile device for an extended period of time, this is typically not the usage pattern for mobile software — we are far more often checking our phones during the “in between” moments. We use our phones while in line at Starbucks, and while on the elevator on our way to our next meeting. Most of these interactions are not lengthy.

At SAP SuccessFactors, we’ve spent considerable time understanding the HR processes that match this style of interaction, making them ideal for a mobile environment. Creating a new job requisition with lots of fields probably doesn’t make sense on a phone, but reviewing the job requisition and approving or sending it back for further edits might, and this ultimately informs our thinking around the job requisition capabilities we provide in our mobile app. An app that facilitates easy, intuitive completion of these “in between” activities is ultimately better aligned with how people use the device they are performing them on.

Consider also how people interact with the mobile device itself. On iOS, users swipe up to access the Control Center to turn on airplane mode. On Android, users swipe down from the top to access their Settings to do the same. Anyone who has lost a phone still on contract and were forced to temporarily switch from iOS to Android or vice versa understands the frustration these small differences can cause for the user experience. When workplace mobile apps are not designed to the standards of the mobile platform, this has the same time-consuming and frustrating effect.

The SAP SuccessFactors Mobile app is designed not only to align with when and where people typically use mobile devices, but also how they interact with their operating system of choice. This includes bringing platform-specific features such as 3D Touch from iOS, Android Fingerprint biometrics, and Apple Face ID (coming soon to your iPhone X) into the SAP Successfactors mobile solution. From the perspective of HR these may sound like inconsistencies between our Android and iOS offerings. But from the perspective of your users, these small touches ensure the mobile app is intuitive, familiar, and enjoyable to use.

For a long time mobile was simply thought of as anytime, anywhere access to all aspects of a solution. But the truth is, mobile can’t and shouldn’t be an exact copy of what we enable people to do at their desks. A mobile app is far more effective when it is an extension of the desktop solution, enabling the activities and tasks that make sense in a mobile environment and that match when, how, and why people use their mobile devices.

The SAP SuccessFactors Mobile app is designed to engage 100 percent of your workforce and keep them captivated, enabling instant, actionable access to the processes, data, and information that matter the most when they’re on the go. http://bit.ly/2Ee4RHI #SAP #SAPCloud #AI

After the advent of S4HANA cloud and the benefits that the current and new SAP customers can reap after moving to the cloud is unparalleled. Obviously, there is a huge push from SAP as well so that customers can make the move. When ERP systems were first introduced a few decades ago, clients were reluctant to move to these newly developed systems. The reluctance was not due to the lack of features or unstable product. However, the unwillingness was due to the fact that why bother to change an existing running system. Leaders don’t want to maintain status quo and knew that the technological advancements will lead to these organizational changes. Additionally, few root causes behind those hesitations were the time, money & the effort it took to make these organizational changes.

Today, we know that those changes happened. We also know that the organizations that kept themselves apprised and up to date with technical advancements were flourished. How they took the leap of faith is immaterial for the outcome. But, from the client perspective and as an SAP platinum consultant and program manager, I thought it is important to understand the nuances of these approaches. The question – “Shall we take the big-bang approach or baby steps?” – is an important question that deserves a well-rounded, to the point answer. Based on our prior experience in such a large and organizational change management, we can list down few of the pros & cons either approach. However, critical question is, do we have any other approach? A hybrid one? In next few paragraph, first, we will look into a couple of different scenarios, discuss the two (or possibly three) approaches, their pros & cons and finally read more about the third approach.

Here is a very obvious and a simple scenario. A small manufacturing company pharma manufacturing has one physical plant in the USA and few offices across the United States. Their last year revenue was less than 100M USD and they do not currently use SAP. They are on another ERP system – Finance, Production Planning, Sales & Distribution and Materials Management, strong in their processes and cost-conscious.  Even though they are on legacy ERP system and the key stakeholders/decision makers have mixed feelings about the legacy system but they want to explore the option of moving to cloud and use S4HANA. In this scenario, what would be your approach – a big bang, phased approach or a hybrid one?

Again this is my personal opinion and I would prefer to suggest an incremental approach or a phased approach. I would take something like core Finance and move that to the public cloud. Of course, we need to fit-to-standard but the underlying assumption is that the gap is minimal and acceptable. It should be done more as a POC and integrate the cloud with their legacy ERP application. Here are the reasons

* Since the leadership has mixed feeling about the legacy ERP system, I would prefer to showcase full functionality in greater detail of a specific function rather than going through all the functions superficially. It will help gain their confidence. The idea is not to hide missing functionalities but to show the details as much as needed for the existing functionality that they need most.
* They are cost aware – implementing core Finance on public cloud within 3 – 6 weeks is cost effective. It will help win their vote easily.
* Integration between core Finance on Cloud and their legacy ERP system will definitely create a “WOW moment” for the client.
* In case of any missing functionality, say in Sales & Distribution, we can show them the S4HANA roadmap and built their roadmap in line with S4HANA roadmap. It may or may not acceptable to the client depending upon their need; however, the integration between cloud and legacy ERP will help you win this war.
* Most importantly, it will help you get your foot into their system.

Even though they have only one physical plant, I would prefer to go by the phased approach. Obviously, in this whole process, you need to build relationships with people at a different level within the organization. You can get first-hand feedback about their challenges, their need or if they love, like or hate the new system on the cloud.

This is the first blog in this series. Stay tuned for the following two scenarios in the second & third blog.

* A huge manufacturing company with a global presence is using SAP for decades and has multiple instances. Their key business stakeholders don’t want to move to public cloud however they are open to private cloud.
* A financial services company wants to utilize SAP cloud and move their core finance to the cloud. They have a presence in Europe, USA, and Currently, they are using different localizations for the same SAP instance.

Finally, in the fourth blog, I will conclude the series with outlining the pros & cons of different approaches.

  http://bit.ly/2Eg35G4 #SAP #SAPCloud #AI