Activar Rappel

[femar]

manual Rappel

Pasame un mail que te envio info.

me puedes enviar por favor la documentación de Rappel, mi correo es : familiaarcila@hotmail.com

[itzi2001]

En los Best practises tienen la guia de configuracion como los de user

http://help.sap.com/bp_bl605/BL_MX/html/Content_Library_BL_ES_MX.htm

Prerequisitos
1. The Payer partner needs to have the “Rebate” field checked in the Customer master on the Sales Area>Billing Document tab.
2. The billing type must be marked as relevant for rebates (IMG Sales and Distribution>Billing>Rebate processing>Activate Rebate Processing>Select billing documents for rebate processing).
3. The sales organization must be marked as relevant for rebates (IMG Sales and Distribution>Billing>Rebate processing>Activate Rebate Processing>Activate rebate processing for sales organizations).
To create rebate-related access sequences (AS), use IMG path Sales and Distribution>Billing-Rebate processing>Condition technique for rebate processing>Maintain access sequences. since it is the same one as for pricing. In order to distinguish pricing and rebate specific access sequences, enter “1” in field “Cat” (Category) for rebate specific AS. Select AS “BO01” and double-click on the “Accesses” tab. The big difference between the rebate and the pricing access sequence is that there is no “Exclusion” flag available for rebate-
However, OSS note 105681 explains how to turn on the Exclusion flag, but there are several other impacts in doing this change, which I will address in the last part of this white paper.Rebate-related condition types are identified by condition class “C” (Expense Reimbursement). When you create a new rebate condition type (IMG path Sales and Distribution>Billing>Rebate processing>Condition technique for rebate processing>Define condition types) and you change the class to “C”, you will realize that several fields you can usually use in a regular pricing condition will disappear or become unavailable. For example, you will not be able to use Condition Updates or Group Conditions. Instead, you get a configuration section exclusively available for rebate condition
If the “Rebate proc.” field is blank, accruals will be posted on each applicable invoice. Entering an “A” will prevent the automatic generation of accruals on invoices. The latter would make sense if you don’t base your rebate payment on actual sales, but on the specific performance of the customer (such as a display in a store or an advertisement in the paper). These rebates would be paid out as a lump sum and would require the creation of a manual accrual. For example, you want to give the customer a $5000 rebate if he displays your product at the entrance of his store. You then would create a one-time manual accrual of $5000. Once you have proof of compliance by the customer, you can create a lump sum payment in that amount, which would reverse the accrual and pay the amount to the customer.
With the “Provision con.” Field, you determine if you want to reverse your accruals at time of partial payment (we will cover payments later in that paper). Leaving this field blank will reverse the accrual; a value of “A” will not reverse it.
Now that we defined our rebate conditions, we can add them to our regular pricing procedure (IMG path Sales and Distribution>Billing-Rebate processing>Condition technique for rebate processing>Maintain Pricing Procedures). Please notethat not all configuration fields are available for the rebate conditions in the standard system. Alternate condition type “AltCTy” and Alternate condition base value “AltCBV” will not let you do any manipulations on how the rebate is calculated. Also, you will not be able to do any manual changes to rebate conditions. The requirement “24” in column “Reqt” prevents the rebate condition from displaying on any document type but the invoice. Simply take this requirement off if you want to have visibility of rebates at order entry time as well.
A very important setting for the rebate conditions in the pricing procedure is the account keys. As I mentioned in the introduction, at invoice time, accruals are being created that post to accounting, to give you visibility on how much you owe your customers. The posting of this accrual is done by accounts assigned to the account key in column ‘Accrls’ (Accruals); usually a sales deduction and an accrual account. The settlement document (in form of a credit memo) uses the accounts assigned to the account key in column ‘ActKy’ (Account key), which reverse the accrued amounts and credits the customer.
It is also imperative that any sub-total line a rebate condition refers to needs to be stored in one of the seven available sub-total fields (KZWI1-KZWI6 and BONBA in column “SubTo”). If you are using multiple pricing procedures, you want to keep the sub-total designations common (i.e., 1 for gross price, 2 for net price).

Configuring the Rebate Agreement
You might be familiar with sales deals in SD. The rebate agreement is based on the same principal, but way more powerful in how you can configure it. To maintain rebate agreement types, use IMG path Sales and Distribution>Billing>Rebate processing>Rebate agreements>Define Agreement types. Select “New Entries” to create a new agreement type.

Default values
The first section (Default values) serves to define the defaults that apply for every rebate agreement of that type. You can define the default start and end date of the agreement. The default start date is important in regards to whether or not you want to allow retroactive rebates. For example, if you set the start date of a rebate agreement to today’s date, all invoices from that moment on are eligible for the rebate and will apply on the invoice itself. However, if your default is the beginning of the current year, the system will calculate rebates for all invoices in the past, from that date on, even if they did not apply on the invoice. These rebates are called retroactive.
The other default in this section allows you to set a payment method, which is freely definable to suit your individual situation. Every rebate settlement will create a credit memo request in SAP; however, if you set your default to “C” for check, it will carry this flag forward to FI, to later let you cut a check. Of course, all of these defaults can be overwritten during creation of the actual rebate agreement.
Control data
The “Condition type group” is linked to the rebate agreement type in a different configuration transaction, which we will get into a little bit later. This condition type group defines which rebate condition types are allowed for the rebate agreement type.
The “Verification levels” field is also a default that defines the level of detail you see when you review the applied invoices within a rebate agreement. You can change this default while reviewing the verification level in the rebate agreement.
The “Different val. period” option lets you define whether or not the rebate condition records you create out of the rebate agreement can have validity dates outside of the ones of the agreement. I suggest you leave this field unchecked.
If you want to allow manual accruals (we will get into what these are for), you need to indicate this and define the respective order type. “B4” is the standard SAP order type for manual rebate accruals.
You are able to create the same rebate agreement automatically in regular intervals with the same data (but different validity dates). To turn on this feature, utilize the “Arrangement calendar” field to do that. You can add a standard SAP calendar, or your own defined one, to schedule the automatic creation of rebate agreements. In a separate step, schedule job RV15C005, which can also be accessed via transaction “VB(D” (yes, that’s the left parenthesis in the transaction code), to automatically extend your agreements.

Manual payment
The “Manual payment” section of the rebate agreement defines how much can be paid out during a partial settlement. You would use partial settlements if, for example, the rebate agreement is defined for a full year, but the payouts are supposed to happen on a monthly, quarterly, or any custom defined schedule.
You can choose whether you want to allow partial settlements only in the amount of what you accrued so far. This is a good idea if you don’t want to pay out more than what the customer is entitled to. However, you can also allow any payment amount, if you choose so. As with manual accruals, you need to define the partial settlement order type, which is “B3” in the standard SAP system. If you don’t want to wait to reverse your accruals until the final settlement, you can do so for the partial settlement by checking the “Reverse accruals” box.
Just as with agreements, you can also schedule regular payments by entering the appropriate calendar in the “Settlement periods” field. Use program RV15C001 (accessible through transaction “VB(7”) to schedule your payment runs. This will create automatic payments according to the defined schedule.
The reversal of the accruals is independent from the payment amount of the final settlement. For example, if you accrued $10,000 over a given period, but the customer did not reach their sales goal, you might want to pay only half that amount or nothing at all. No matter what the payment amount is going to be, the total remaining accrued amount for the agreement is reversed.
Settlement
The “Settlement” section defines the final settlement order type (“B1” in standard SAP) and the minimum status that needs to be set in the agreement before it can finally be settled. This will become more clear when we cover the actual settlement of a rebate agreement later in this paper.
getting out of sync. This is mostly the case for retroactive rebates.
Text determination
You can assign text types through standard SAP text determination to the agreement type as well, which will enable you to add comments. These comments will show on a printed rebate agreement
Condition Type Groups
I mentioned the assigned condition type group in the definition of the rebate agreement. With IMG menu path Sales and Distribution>Billing>Rebate processing>Rebate agreements>Condition type groups>Define condition type groups, you can freely define your rebate condition type group Make sure that you leave the “Cat.” (Category) field blank. This defines the Condition Type Group as relevant for rebates. Sales deals share this configuration transaction and would be identified with a category of “A”.

Assigning Condition Types to Condition Type Groups
In this configuration step (IMG Sales and Distribution>Billing>Rebate processing>Rebate agreements>Condition type groups>Assign Condition Types/Tables To Condition Type Groups), you define which condition tables, of which rebate condition types, you allow for a specific Condition Type Group, and in which order they appear in the rebate agreement. Since the standard SAP rebate functionality does not allow exclusions in the access sequence, the order of condition tables can be freely defined here. You can assign multiple condition types that can have different access sequences.

Assignment of Condition Type Groups to Rebate Agreement Types
Finally, we are able to link the Condition Type Group to the Rebate Agreement Type through the IMG menu path Sales and Distributions>Billing>Rebate Processing>Rebate Agreements>Condition Type Groups>Assign Condition Type Groups to Rebate Agreement Types


Saludos,
Paola

[/QUOTE]

[m3mo]

Manuales

Buen día,
Abusando de la disponibilidad, podrían mandarme también los manuales de favor =) el_m3mo@hotmail.com
Saludos!

[Inflosa]

Rappel anual con liquidación parcial mensual

Buenas,

Tengo problemas para definir el rappel. Mi cliente necesita disponer de un rappel que tenga un periodo de duración como por ejemplo un año y que se permita liquidar mensualmente.

He tratado de asignar el calendario de acuerdo AJ (acuerdos por año) y calendario e liquidación parcial AM (liquidación mensual) pero cuando ejecuto la transacción VB(7 no veo la opción de liquidar hasta la fecha, simplemente aparece un literal que indica "Existen mensajes". Pulso sobre el botón "declaración" y me aparece el mensaje en amarillo VK783 Liberación para liquidación realizada.

¿Alguien puede ayudar para poder parametrizar correctamente el rappel?

Adjunto imagen sobre la parametrización.

Gracias de antemano

Saludos