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