SAP Sales Rebates vs Vistex Sales Rebates (Sales Rebates)

Below are a few differences between SD rebates and Vistex, Vistex has evolved over a period of time and the product has matured based of organizational requirements unlike SD rebates is at a stand still.

In short, SD Rebates can be implemented for organizations for simple rebate processing and low document volume, whereas Vistex handles complex business processes with very high data volumes.

Processes	SAP Rebates	Vistex
Flat Rebates	Handles simple and straight forward requirements. Simple to Configure and Maintain Tracking is very easy Partial settlement Possible by default	Medium level configuration but provides multiple called transnational model options and screens for additional maintenance. Tracking is also simple but complex config. Additional config to handle Partial settlements
Scales or Tier Based	Limited functionality where accrual is per document No functionality exists for volume, growth or target based rebates	Complex, called composite model and can handle excellently Examples include growth based, volume based,target based rebates The most robust feature of Vistex and complex maintenance on the other hand.
Rebate Recipient	Payment to only one recipient	Payments can be made to multiple recipients
Reports	Limited functionality Customer reports for specific requirements	Standard reports available Customer reports for specific requirements Vistex provides standard BI extractors
Accrual Process	Easy to trouble shoot	Complex
Retroactive	Execute a report to correct data	Implement a functionality to handle retroactive rebates. Process the invoices for subsequent IP processing
Accrual Postings	Posting to FI based on service rendered date	Posting to FI on billing date
Currency Conversion	Posting based on service rendered date by default	Posting based on billing date
Credit Memo generation	Creates SD billing document by default.  Payments made only to recipient which is normally a customer	Default config to create direct FI invoice Custom development to process for SD billing.  Can make payments to customer or Vendors as per business requirements via config.
Re-process documents	Cannot re-process/change once billing document has been created	Easy to troubleshoot Can reverse FI postings like accruals mainly and re-price/re-create documents
Exclusions	No material or customer exclision from group if rebates maintained at group level	Handled by standard configuration
Customer & Material Groups	Customers and materials are grouped at master data level	Ability to group customers via Membership lists for customers or Product lists/ Flexible grouping for Materials.
Buying groups or GPO's Note: There are situations when the rebates are to be processed for a buying group who does not actually purchase the products but gets a royalty for introducing customers to manufacturers.	No standard functionality exists.	The invoices can be process separately for buying groups and individual customers. Accural/settlements can be handled accordingly.
Stop Rebate payments	Manual check for Customer AR Clearance.  Cannot stop payments to customers even if customer AR due.	Vistex Payment schedule process handles payments Ability to stop accural if AR not cleared.
Manual Claim process	Standard process part of rebate configuration	Additional configuration to handle manual claims for positive and negative postings
Sales Commissions	Normally clients use the SAP rebates module and generate credit memos for payments	Vistex Payroll profile integrates with HR and payments processed from HR module as part of Payroll
Note: Vistex provides additional modules such as Chargebacks, billbacks, Sales Commissions, Purchasing Rebates and Data Maintenance module (Price optimization tool) that have been implemented by clients for business specific requirements.

SAP Revenue Accounting and Reporting (RAR) - Definitions or Keywords

Operational Document: It represents a contract that an enterprise has with its customer to deliver goods or service within a stipulated time. This could traditionally represent a sales order/delivery/invoice.

Transaction Price: This is the price of the item determined in the operational document (Sales Order/Invoice) via pricing conditions and cannot be maintained within Revenue Accounting

Stand Alone Selling Price: This is the ‘fair value” price of the distinct item when sold individually which can be maintained in the operational document or within Revenue Accounting.

Revenue Contract: This is an automatically generated number created within Revenue Accounting. This number could be unique per operational document (Sales Order) or a combination of operational documents. The subsequent processing of the operational document (Delivery or Invoice) will update the same Revenue Contract.

Performance Obligation (POB): This is a promised item in the contract to the customer to deliver transfer goods or perform service. It is also an automatically generated number created within Revenue Accounting under the contract.

Distinct or Indistinct: Distinct POB is goods or service always sold by itself independently and Indistinct POB’s are goods or service that are combined with other items and does not need individual tracking.

Note : Source SAP Help

SAP Revenue Accounting and Reporting (RAR) - Introduction

SAP Revenue accounting and reporting, RAR in short is an SAP delivered software designed specifically to help businesses comply with new statutory IFRS revenue standard (ASC 606) for revenue recognition and also has the flexibility to support existing requirements. 

Revenue Accounting can be installed on SAP ERP 6.0 Enhancement Package 5 or higher. If your Financials system is below that system level, you must first upgrade the system to at least SAP ERP 6.0 Enhancement Package 5 and install integration on top of your ECC system.

Revenue Accounting Integration and Revenue Accounting communicate by using RFC function calls. If these two instances are installed in different systems, you need to define an RFC destination with connection type 3 (Connection to ABAP System) in the system where Rev. Accounting Integration is installed, pointing to the system where Revenue Accounting is installed.

The new SAP RAR has been decoupled from the SAP SD  environment and the revenue account process runs in silos with some integration configuration within SD area and involves five basic steps.

1. Identifying the contract

2. identifying the performance obligation

3. Allocation of Transaction Price

4. Fulfillment of performance obligations

5. Revenue Postings

Note: Source from SAP Help

SAP SD Integration with SAP Revenue Accounting and Reporting (RAR)

• SAP RAR engine has provided three default Revenue Item classes (RAI) one each for Order, Delivery and Invoice documents.
•  RAI Class contains interface program and data base tables ​ and RAI data base tables hold the raw, processable or processed data from source systems​.
• Class Type relates RAI Class to Interface Component​
• Custom Revenue item class are used either for conversion or data flow from external systems (Non-SAP) when integrating with SAP RAR for its revenue recognition purposes and Generate and Activate RAI Class for any non-SAP Systems.
• These item classes act as interface points and help the data flow from ECC to SAP RAR alongside some other essential configuration.
• Interface Component contains data structures, interface programs and possible program enhancements

Note: Source from SAP Help

SAP Intercompany Billing : Automatic Posting to Vendor Invoice (SAP-EDI)

EDI outbound processing for intercompany billing links to EDI (Output Type RD04 for billing type IV for Intercompany Billing Revenue and IG for Intercompany Credit Memo/Returns) inbound processing for invoice receipt in FI and posting to vendor account is carried out in the selling company code. The EDI then creates a BDC job to trigger an FI posting using FB01 with an IDOC.
When posting the Vendor Invoice there is one key configuration that is necessary for the copying of the Profit center, Cost center, projects, PA Segment or Business Area for the Vendor Invoice to be posted automatically and that is to "Activate the Account Assignment" using menu path in SD Billing or simply via TCode VOFC.


The indicator specifies whether account assignments from the customer billing document are copied during credit-side offsetting entries in the sales company code. Only on checking this flag, the IDOC E1EDP30 with QUALF "046" for PA Segment, "078" for Profit center or "049" for Business area are populated and this data is used to populate some mandatory fields for the Vendor Invoice creation.



 

SAP: Firefighter ID locked

Issue: I had my FireFighter ID got locked and I was unable to logon. The partial screen is show below with the Logon as “Greyed Out” and the Status would show up with a RED Traffic light stating user still logged in. I checked SM04 to view the list of users with my regular user id and could not find my FireFighter ID in the list and then it struck to me that the server my user id was connected to was different to that of my FireFighter.




Reason: I happened to execute SE16 to extract data and my internet got disconnected. This caused an abrupt closing of the session keeping the SE16 still in execution mode on the server.

Solution: 

1. Execute AL08 to check the list of all users logged onto all the servers.
2. Search for the FireFighter ID the server where the user id has been locked.
3. Execute SM51 to view the list of the SAP Servers.
4. Select the appropriate server name from step 2 and click on the ‘User’ icon to display the users.

This actually calls TCode SM04 to display the list of users of that particular SAP Server (the server which my firefighter was logged on)and select the user id and kill the sessions.

SAP : Error in external tax system: Line: 0 - 0440 TxJCdSTIO The fleximap module / FS861

The error is caused in the sales orders due to a change in the customer jurisdiction code and sets the sales document to an  incompletion log for pricing. Changing the Jurisdiction code in the Sales order does not undo the incompletion. The customer ship-to jurisdiction code (If Ship-to is different from Sold-to) has to be changed appropriately and later the order has to be re-priced with price type 'G'.


Regards,
[V]