quinta-feira, 22 de setembro de 2022

Field Service and Repair at Own Service Center

 Todays blog post is a continuing topic from the previous post. My earlier blog post was on the topic ‘Field Service and Repair at On-Site’

This blog post is on the topic of Field Service and Repair at Own Service Center.

When the service order is received from the customer for the repair of the product which must be fulfilled at own service center, In such case location of the service provision will be set to Own Service Center when creating Service Order.

Own Service Center Indicates that the service must be performed at company’s service center.

Process Flow

Figure%3A01%20Process%20Flow%20of%20Field%20Service%20and%20Repair%20at%20Own%20Service%20Center

Figure:01 Process Flow of Field Service and Repair at Own Service Center

 

Customer Return Notification

Inbound Logistics> New Customer Return Notification> Search by sales order ID which needs to be return> click Next> Maintain mandatory details> Finish.

Figure%2002%3A%20Customer%20Return%20Notification

Figure 02: Customer Return Notification

Select Follow-Up Activity as Repair at Own Service Center. Once you fill all the mandatory fields check for consistency and click next and then Finish. It will create Outbound Delivery and Advised Inbound Delivery Notification Automatically.

Process Inbound Delivery

Inbound Logistics> Inbound Delivery Notification> Search for Advised Inbound Delivery Notification created in the previous document> click Post Goods Receipt> Propose Quantities> Save and Close.

Create%20Inbound%20Delivery%20and%20Goods%20Receipt

Figure:03 Create Inbound Delivery and Goods Receipt

Create Service Order

Service Order> New Service Order under common task.

Figure%3A04%20New%20Service%20Order

Figure:04 New Service Order

Select location of service provision as Own Service Center as shown in Figure:04. Also fill all required and mandatory fields under general tab.

Figure%3A05

Figure:05

Under Services and Spare Parts add services and spare parts along with quantity and amount that are required to perform service. Also mention whether the service to be fulfilled by internal or external under service planning tab and service performer. Now for this document lets keep it as internal. Save and Release.

I will post third party field service and repair scenario by choosing fulfillment as external in my next blog.

Assign Service Order reference to Customer Return.

Sales Order> Returns> Search by Customer Return ID> Edit> Assign Reference under items tab.

Figure%3A06%20Return

Figure:06 Return

Select the Sales order ID> Click ok> This indicates that the product returned from the customer is under repair> Save and Close.

Figure%3A07%20Return

Figure:07 Return

Release Service Order to Execution

Service Order> Service Order Processing> Search by service order ID created> Click edit> Submit> Release to Service Execution

Figure%3A08%20Release%20Service%20Order%20to%20Execution

Figure:08 Release Service Order to Execution

When Service Order is release to execution the status of the Service Order changes to in-process from open. And now the Service Order will be available for the service performer in Order Pipeline of the Field Service and Repair work center in not started status.

Service Confirmation

Field Service and Repair> Order Pipeline> Search by Service Order ID> Click Confirm Execution.

Figure%3A09%20Field%20Service%20and%20Repair%20Order%20Pipeline

Figure:09 Field Service and Repair Order Pipeline

Once you click Confirm Execution> New Service Confirmation screen will appear> check and adjust the information if needed> Release.

Figure%2010%3A%20Release%20Service%20Confirmation

Figure 10: Release Service Confirmation

Request Outbound Delivery

Sales Order> Returns> Search by customer Return ID> Click Edit> Click on Request Outbound Delivery, which initiates the creation of an outbound delivery request for the selected items> save and close.

Figure%2011%3A%20Request%20Outbound%20Delivery

Figure 11: Request Outbound Delivery

When the service performer confirms the repair of the returned product with service confirmation which then can return back to the customer by requesting outbound delivery.

Process Outbound Delivery

Outbound Logistics> Delivery Proposal> Post Goods Issue> Release.

Figure%2012%3A%20Outbound%20Delivery

Figure 12: Outbound Delivery

Customer Invoicing

Customer Invoicing> Invoice Request> Search by Service Confirmation ID> Click Invoice> Release.

Figure%2013%3A%20Customer%20Invoicing

Figure 13: Customer Invoicing

I have tried to explain the topic ‘Field Service and Repair(Own-Service-Center)’ in simple terms by replicating the exacts steps. I hope this blog would be helpful for you

Do comment your feedback and thoughts on this blog post in the comment section.

Link for my previous blog post on the topic ‘Field Service and Repair at On-Site’ is mentioned below:

https://blogs.sap.com/2022/09/15/field-service-and-repair-at-on-site/

 

You can find related document regarding this topic from Help Library as mentioned below do refer:

https://help.sap.com/docs/SAP_BUSINESS_BYDESIGN/2754875d2d2a403f95e58a41a9c7d6de/746cdd5f59384a56aae5deaef348aa7c.html?version=2105

https://help.sap.com/docs/SAP_BUSINESS_BYDESIGN/2754875d2d2a403f95e58a41a9c7d6de/2d9bf2de722d1014a851be7c29be0fc9.html?version=2105

https://help.sap.com/docs/SAP_BUSINESS_BYDESIGN/2754875d2d2a403f95e58a41a9c7d6de/2de37352722d10149598854ae28eb782.html?version=2105

Read and follow various topics related to SAP Business ByDesign through the link given bellow.

https://blogs.sap.com/tags/01200615320800000691/

 Source: https://blogs.sap.com/2022/09/19/field-service-and-repair-at-own-service-center/

S/4Hana Busines Partner – Customer-Vendor Integration (CVI) Concept between traditional ECC Vs S/4Hana

 Hello All,

I am again touching base on BP (Business Partner) topic after a few business discussions in recent times.

Please refer to my old blogs on the same topic.

Business Partner SAP S/4 HANA insights | SAP Blogs

Business Partner creation with multiple contact persons/relationships on S4 HANA | SAP Blogs

This time, coming up with much more details and differences and what is the proper way of the business model of Business partner.

I would like to share a glimpse of my current experience with SAP S/4 HANA migration.

I see many of the consultants are treating BP creation is different and customer / Vendor creation is dependent on BP creation, which is a completely wrong assumption.

And this is a basic concept that brought changes from traditional ECC to S/4Hana architecture.

Please refer for the basic changes that took in place in S/4Hana – Business Partner SAP S/4 HANA insights | SAP Blogs

There are redundant object models in the traditional ERP system. Here the Vendor master and Customer master are used which are having several limitations. Limitations of the Customer/Vendor Object Model:

  • Only one single address
  • No relation between a Vendor and a Customer for the same real-world entity (no role concept)
  • No persons (B2C)
  • No time-dependency

The strategic object model in SAP S/4HANA is the Business Partner (BP). Business Partner is capable of centrally managing master data for Business Partners, Customers, and Vendors. With current development, BP is the single point of entry to create, edit and display master data for Business Partners, Customers, and Vendors.

In terms of SAP Business Partner the definition for Customer and Vendor is the following:

Customer:

A Customer is a Business Partner to which goods and services are sold and/or delivered. A Business Partner can be a Customer and a Vendor at the same time if, for example, your Customer also supplies goods to you.

A Customer master holds information about the Customer such as their name, address, bank details, tax details, and delivery and billing preferences. This Customer information is used and stored in transactions such as sales orders, deliveries, and invoices.

Some Customer information is specific to a company (known as company code) or sales unit (known as sales area) within your organization.

Vendor:

A Vendor (or Supplier) is a Business Partner which delivers and sells goods and services to your organization. A Business Partner can be a Vendor and a Customer at the same time if, for example, your Vendor also buys goods from you.

A Vendor master holds information about the Vendor such as their name, address, bank details, tax details, and billing preferences. This Vendor information is used and stored in transactions such as purchase orders, goods receipts, and Vendor invoices.

Some Vendor information is specific to a company (known as company code) or purchasing unit (known as purchasing organization) within your organization.

 

Advantages / New functionality of Business Partner over ECC (Customer / Vendor):

  • A legal entity is represented with one Business Partner
  • One Business Partner can perform multiple roles, e.g., Customer and Vendor (Supplier)
  • General data is available for all different Business Partner roles, specific data is stored for each role
  • Maximal data sharing and reuse of data leads to an easier data consolidation
  • Different Business Partner Categories – Organization, Person, Group
  • Flexible Business Partner Relationships possible like “has contact person”, “is married with” etc.
  • One Business Partner can have multiple addresses
  • Time-dependency on different sub-entities e.g. role, address, relationship, bank data, etc.
  • Provide harmonized architecture across applications

To use the SAP Business Partner as a leading object in SAP S/HANA, the Customer/Vendor Integration (CVI) must be used. The CVI component ensures the synchronization between the Business Partner object and the Customer/Vendor objects.

 

To use the SAP Business Partner as a leading object in SAP S/HANA, the Customer/Vendor Integration (CVI) must be used. The CVI component ensures the synchronization between the Business Partner object and the Customer/Vendor objects.

The diagram below illustrates the context.

CVI%20Complex%20Interface

CVI Complex Interface

How A BP differs from ECC Customer and Vendor:

It is always a false assumption that BP gets created 1st and then followed by Customer and Vendor – false interpretation.

the fact is that a Business Partner is always created when a Customer or Vendor is created.
The complex interface of the CVI (Customer/Vendor Integration) contains Business Partner specific data as well as Customer and Vendor-specific data.

Partially, the data of the Business Partner and Customer/Vendor are redundant (BUT000 against KNA1 & LFA1 data).

For instance, ‘Name and Address specific attributes are available in both sets of tables.

Customer or Vendor-specific data is routed through the Customer/Vendor specific interface and mixed up with the Business Partner central data.

On commit, the Business Partner and corresponding Customer and/or Vendor are maintained/created.

SAP supports the conversion of existing Customer and Vendor data to Business Partner via guided
procedure reports.

 

ECC Transactions that become obsolete:

The following SAP Business Suite transactions are no longer available or redirect to transaction BP:

  • FD01, FD02, FD03, FD05, FD06, FD08 (Create, Change, Display, Block, Deletion mark, Confirm Customer (Accounting))
  • FK01, FK02, FK03, FK05, FK06, FK08 (Create, Change, Display, Block, Deletion mark, Confirm Vendor (Accounting))
  • MAP1, MAP2, MAP3 (Create, Change, Display Contact Person)
  • MK01, MK02, MK03, MK05, MK06, MK12, MK18, MK19 (Create, Change, Display, Block, Deletion mark Vendor (Purchasing))
  • V-03, V-04, V-05, V-06, V-07, V-08, V-09, V-11, V+21, V+22, V+23 (Create invoice recipient, payer, consignee, one-time Customer, ordering party, carrier, sales prospect,
    competitor, Business Partner (Sales/Centrally))
  • VAP1, VAP2, VAP3 (Create, Change, Display Contact Person)
  • VD01, VD02, VD03, VD05, VD06 (Create, Change, Display, Block, Deletion mark Customer (Sales))
  • XD01, XD02, XD03, XD05, XD06, XD07 (Customer: Create, Change, Display, Block, Deletion mark, Change Account Group (Centrally))
  • XK01, XK02, XK03, XK05, XK06, XK07 (Vendor: Create, Change, Display, Block, Deletion mark, Change Account Group (Centrally))

CVI ensures that Customer and Vendor master data tables are updated automatically after a BP is
created/changed. All KNxx and LFxx Customer/Vendor master data tables are still populated as previously in SAP Business Suite.

In SAP S/4HANA BP transaction covers almost all Customer/Vendor master data fields. For additional fields that are not included in the standard SAP S/4HANA BP transaction kindly go over the BDT interface activities in order to add your own custom fields

Now, Let’s talk about the limitations in BP:

Limitations:

there are some functional restrictions compared to S/4HANA to be considered when using BP as a leading object in SAP ERP, e.g.:

  • It is not possible to maintain all the customer- or supplier fields or data needed. There are no plans to implement additional fields here since the xD0x- and xK0x-transactions continue to exist.
  • Field modification from FI (e.g. by account group) is not considered in BP-transaction.
  • Multiple Assignment is not available in SAP ERP.
  • No FIORI-apps to maintain BP, BP-Customer, and BP-Supplier.
  • Neither account group information nor change feature is available in BP-transaction (but XD07/XK07 is available).
  • There is no search help / no locator search or display like “BP by Customer/Vendor”.
  • Accessing Customer/Vendor documents from BP-transaction is not possible.
  • From BP-transaction there is no direct menu link to Customer or Vendor classification data.
  • Forward navigation in partner schema of customer/vendor data is not supported (double click on partner number is not supported).
  • All the SAP Business Suite help documents refer to Customer and Vendor rather than Business Partner for these transactions

A summary of the process:

1. Archive obsolete vendors and customers. This is highly recommended as will reduce the number of customers, vendors to be synchronized. (In some projects it is not possible as the company does not have the archiving procedure set for customers and vendors). All nonarchived objects will need to be synchronized as the installation process will check that.

2. Analyze the ranges. It is recommended that Business Partner ID and Vendor/Customer ID are the same, but this is not always possible as in SAP ECC is normal that customers and vendors have to overlap in ranges. You must plan the new ranges numbers if overlapping exists.

2. Implement pre-checks, Activate Business Functions and  Perform customizing.

3. Execute the Mass Data Synchronization program.

4. If data errors appear (and trust me, they will), be prepared to execute a data cleansing process.

5. Re-execute the synchronization cockpit until everything is synchronized.

 

important considerations:

*Business Partner roles:

The synchronization will create the BP with 2 roles for each object:

  • For customers: FI Customer and Customer
  • For vendors: FI Vendor and Vendor

One corresponds to the FI area and the other one to the sales/purchasing area.

 

*Execution parameters:

In my experience, the performance of the program is not great. For a small number of customers/vendors will not be a problem, but if you have hundreds of thousands of employees/vendors it can be an issue. However, by increasing the number of parameters “Max. Processes”, the performance will improve.

For example, if you change this parameter to 10, the program will parallelize the batch execution, improving the timing. Of course, this must be tested to find the optimal size as might depend on your system architecture settings.

*Ranges overlapping:

When there are ranges overlapping and you need to pick how to maintain vendors’ or customers’ numbers, SAP recommends maintaining customers as usually sales and customers are more important for companies than vendors  (of course, companies prefer to send invoices and collect money than pay them).

 

 

I hope my learning and analysis would help you to understand the Business Partner / Customer Vendor Integration.

In the next blog posts, we can discuss more processing.

That’s all about this blog post.

Thanks for reading, please provide your feedback. ?

Happy Learning, see you in my next blog 🙂

Thanks,

Venkatesh Golla

Source: https://blogs.sap.com/2021/12/12/s-4hana-busines-partner-customer-vendor-integration-cvi-concept-between-traditional-ecc-vs-s-4hana/

How to Remove Discrepancies Related to the Sale orders and Deliveries from MD04

 Hello Everyone,

The following process will shed light on how to remove discrepancies related to sale orders and deliveries.

Problem Statement:

The issue is that when a sale order or delivery has been rejected, blocked, or deleted, the quantity of material related to that sale order or delivery is displayed in MD04. Due to these discrepancies in quantity of a material, the planning/procurement department of an organization is not getting the correct demand for the material, and it causes excess procurement or production of that material, and ATP of that material is not triggered correctly.

Solution:

To overcome the above problem, the following solution is as below to remove discrepancies from MD04 transaction related to Sale Orders and Deliveries.

Step-1:   Run the standard program SDRQCR21 in T code-SE38 and place the sale order/delivery number in the field of Document Number as per the below screenshot and check mark the below options and execute the transaction.

This program can be run for Material/Plant/Creation Date/Sale Orders and Deliveries. It can also be run for a single value or multiple values by selecting multiple options on the screen.

Note: When executing this program, do not select the “Planning Entry” option on the screen.

 

Step-2:        Now check in MD04 that the discrepancies related to Sale Order and Delivery have been removed for which the above program ran.

To Conclude:

Once the above steps will be executed successfully, the business will get the correct demand/planning quantity of the material either to procure or produce that material.

Suggestion:

To avoid any risk in the Production system, instead of running this program-SDRQCR21 directly in SE38, business can make Z T-codes to run this program in the production system and give authorization to the respective user for that T-code to run this program.

Please follow Neeraj Jain for more content on issues & topics related to SAP Sales & Distribution, Material Management and Production Planning.

If any questions, please click here

Thanks for your interest! Please share feedback, comments, or suggestions below.

Best Regards,

Neeraj Jain

SAP Lead Consultant in HCL Technologies Limited

Source: https://blogs.sap.com/2022/09/21/how-to-remove-discrepancies-related-to-the-sale-orders-and-deliveries-from-md04/

quarta-feira, 14 de setembro de 2022

Enhancing The Field Catalog of Condition Tables For Output Billing Documents

 The below steps helps us in adding a new custom field to the existing field catalog of a condition table on Output billing.


          1. Create a new structure (append structure) in KOMBZ – Customer groups. The newly added structure holds the new field.

                    /wp-content/uploads/2013/01/image1_177773.png

          2.  Enhance the structures KOMKBV3 (Header) and KOMPBV3 (Item) with the new field by adding an append structure.

                    /wp-content/uploads/2013/01/image2_177774.png

                    /wp-content/uploads/2013/01/image3_177775.png

          3. Now maintain V_T681F with the new field, this will add the new field to the condition table structure.

                    /wp-content/uploads/2013/01/image4_177776.png

              Click on new entries

                    /wp-content/uploads/2013/01/image5_177777.png

              

Add the new field.

          /wp-content/uploads/2013/01/image6_177778.png


                      

Save it.

4. Coding for filling the new field in RVCOMFZ1 form USEREXIT_KOMPBV3_FILL for the item field.

/wp-content/uploads/2013/01/image7_177801.png

          5.  Coding for filling the new field in RVCOMFZZ form USEREXIT_KOMKBV3_FILL for the header field.

               /wp-content/uploads/2013/01/image8_177780.png

This will add the new field in the field catalog structure for access sequence, now we can create a condition table with this field and assign it to the Output type which will be triggered during the billing document creation.

To create a condition table use the transaction V/62.

/wp-content/uploads/2013/01/image9_177781.png

Give the description and the field catalog will be shown as below with newly added fields.

/wp-content/uploads/2013/01/image10_177782.png

Double clicking the required fields will move the fields to the selected fields list.

The technical view will help us in seeing the technical details of the selected fields.

/wp-content/uploads/2013/01/image11_177783.png

/wp-content/uploads/2013/01/image12_177784.png

The access sequence and output type are assigned to the billing application in NACE configuration and the data for the output type of the billing document is maintained using VV31.

Once this configuration is done, when a billing document is triggered with corresponding output type all the condition records are filled and we can see them from output messages tab on billing document using determination analysis.

/wp-content/uploads/2013/01/image13_177785.png

The output will be seen in the analysis under the output message type with the condition table records.

/wp-content/uploads/2013/01/image14_177802.png

Thank you.

Source: https://blogs.sap.com/2013/01/23/enhancing-the-condition-table-field-catalog-for-output-billing/

Enhancing The Field Catalog of Condition Tables For Output Billing Documents

 The below steps helps us in adding a new custom field to the existing field catalog of a condition table on Output billing.


          1. Create a new structure (append structure) in KOMBZ – Customer groups. The newly added structure holds the new field.

                    /wp-content/uploads/2013/01/image1_177773.png

          2.  Enhance the structures KOMKBV3 (Header) and KOMPBV3 (Item) with the new field by adding an append structure.

                    /wp-content/uploads/2013/01/image2_177774.png

                    /wp-content/uploads/2013/01/image3_177775.png

          3. Now maintain V_T681F with the new field, this will add the new field to the condition table structure.

                    /wp-content/uploads/2013/01/image4_177776.png

              Click on new entries

                    /wp-content/uploads/2013/01/image5_177777.png

              

Add the new field.

          /wp-content/uploads/2013/01/image6_177778.png


                      

Save it.

4. Coding for filling the new field in RVCOMFZ1 form USEREXIT_KOMPBV3_FILL for the item field.

/wp-content/uploads/2013/01/image7_177801.png

          5.  Coding for filling the new field in RVCOMFZZ form USEREXIT_KOMKBV3_FILL for the header field.

               /wp-content/uploads/2013/01/image8_177780.png

This will add the new field in the field catalog structure for access sequence, now we can create a condition table with this field and assign it to the Output type which will be triggered during the billing document creation.

To create a condition table use the transaction V/62.

/wp-content/uploads/2013/01/image9_177781.png

Give the description and the field catalog will be shown as below with newly added fields.

/wp-content/uploads/2013/01/image10_177782.png

Double clicking the required fields will move the fields to the selected fields list.

The technical view will help us in seeing the technical details of the selected fields.

/wp-content/uploads/2013/01/image11_177783.png

/wp-content/uploads/2013/01/image12_177784.png

The access sequence and output type are assigned to the billing application in NACE configuration and the data for the output type of the billing document is maintained using VV31.

Once this configuration is done, when a billing document is triggered with corresponding output type all the condition records are filled and we can see them from output messages tab on billing document using determination analysis.

/wp-content/uploads/2013/01/image13_177785.png

The output will be seen in the analysis under the output message type with the condition table records.

/wp-content/uploads/2013/01/image14_177802.png

Thank you.

Source: https://blogs.sap.com/2013/01/23/enhancing-the-condition-table-field-catalog-for-output-billing/