Retro active billing

[Former Member]

Hello SAP Prof,

1. what is retro active billing? who is will create this?

2. What is the use of Terms of Payment in CMR.

3. . In TOR, what exactly is REQUIREMENT CLASS and REQUIREMENT TYPE? give a brief explanation?

[Former Member]

HI Rajesh,

Retro billing

1) define the order reasons for retrobilling, I usually adopt the standard one s 100 and 200 (see in customizing there is some speciel flag for them)

2) define Credit e debit memo doc.

3) run VFRB, when you have the output list goto menu settings->change and set the default document types and reasons. Save. go back

PDIF is the condition type used to bill the customer for the difference.

PDIF is a standard condition tyoe that you have to insert in your credit/debit pricing procedure.

cond. class=B

calculat.type=B

item conditon=on

you can find it in std procedure RVAA01

Requirement type

For every transaction system determines requirement type that specifies what

kinds of requirements are available like Sales Order Requirement, Delivery

Requirement or Customer Specific Requirement.

• Requirement type is going to be determined automatically by following a search

strategy

1. System checks “Strategy Group” in MRP 3 view of the material master.

2. Then it will go to MRP Group in MRP 1 view of the material master.

3. Then it will try to determine using Material type.

4. Then it will go to Item Category + MRP type (SD Assignment).

5. Then it will go to Item category to determine and finally

6. System will assume that the transaction is not relevant for TOR and

Availability Check.

• Requirement type points towards Requirement class that specifies whether the

system has to carry out TOR and AC functions. And also it specifies

configuration process, costing, assembly order processing, special stock details

etc.

• The configuration settings for TOR and AC from Requirement class globally

copied into schedule line category as system takes same factors to determine

requirement type as well as schedule line category

• At schedule line category level fine tuning off Transfer of Requirement and

Availability Check functions can be carried out for particular transaction i.e. for

particular transaction if the user does not want to carry out TOR and AC functions

that can be deactivated.

Requirements Class

The requirements class contains all control features for planning such as relevance for

planning, requirements planning strategy and requirements consumption strategy. In

addition, it is specified at a global level whether an availability check is to take place for

the material in the sales and distribution documents on the basis of the ATP quantity

(ATP = available to promise) and whether requirements are to be passed on. A finer

degree of control can be obtained for sales documents using the schedule line category

Reward points pls.

Regards,

Govind.

[Former Member]

Hi Rajesh,

Regarding Requirement Class

Requirement Class is the key factor in TOR.

It is based on Requirement Type.

The system uses the entries at Requirement class as default and brings the data into the sales order.

Thanks

Mohan

[Lakshmipathi]

Hi Rajesh

<b>Answer to Q1</b>

Check the link

http://help.sap.com/saphelp_47x200/helpdata/en/f5/54a679e4c111d1954200a0c9306667/frameset.htm

<b>Answer to Q2</b>

It is used in sales orders, purchase orders, and invoices. Terms of payment provide information for:

--> Cash management

--> Dunning procedures

--> Payment transactions

<b>Procedure</b>

Data can be entered in the field for the terms of payment key in various ways as you enter a business transaction:

--> In most business transactions, the system defaults the key specified in the master record of the customer/vendor in question.

--> In some transactions (for example, credit memos), however, the system does not default the key from the master record. Despite this, you can use the key from the customer/vendor master record by entering "*" in the field.

--> Regardless of whether or not a key is defaulted from the master record, you can manually enter a key during document entry at:

• item level in sales orders

• header level in purchase orders and invoices

<b>Note</b>

Master records have separate areas for Financial Accounting, Sales, and Purchasing. You can specify different terms of payment keys in each of these areas. When you then enter a business transaction, the application in question will use the key specified in its area of the master record.

<b>Answer to Q3</b>

Check the following link

http://help.sap.com/saphelp_47x200/helpdata/en/93/744c86546011d1a7020000e829fd11/frameset.htm

Thanks

G. Lakshmipathi

[Former Member]

Hi

<b>Regarding Requirement Type</b>

For every transaction, system determines requirement type that specifies what

kinds of requirements are available like Sales Order Requirement, Delivery

Requirement or Customer Specific Requirement.

• Requirement type is going to be determined automatically by following a search

strategy

1. System checks “Strategy Group” in MRP 3 view of the material master.

2. Then it will go to MRP Group in MRP 1 view of the material master.

3. Then it will try to determine using Material type.

4. Then it will go to Item Category + MRP type (SD Assignment).

5. Then it will go to Item category to determine and finally

6. System will assume that the transaction is not relevant for TOR and

Availability Check.

• Requirement type points towards Requirement class that specifies whether the

system has to carry out TOR and AC functions. And also it specifies

configuration process, costing, assembly order processing, special stock details

etc.

• The configuration settings for TOR and AC from Requirement class globally

copied into schedule line category as system takes same factors to determine

requirement type as well as schedule line category

• At schedule line category level fine tuning off Transfer of Requirement and

Availability Check functions can be carried out for particular transaction i.e. for

particular transaction if the user does not want to carry out TOR and AC functions

that can be deactivated.

This requirement type is assigned to a requirement class in t.code OVZH.

and requirement results with the combination of

item category + MRP type -

---

> Requirement type

and also same is the case with regards to schedule line category.

item category + MRP type -

---

> Schedule line category

Thanks

Mohan

[Former Member]

Hi rajesh,

Regarding Retro Active Billing

Hi

Retro Billing is a special type of Billing which is used in Scheduling Agreements.

We may change the price of a material after it has already been billed and settled. In this case, we create a retro-billing list to reevaluate billing documents with the new price. we create an additional billing document to settle the difference. The retro-billing list function is only available for the standard self-billing procedure.

Because of the long validity periods of scheduling agreements, the system carries out a second pricing run during billing. This ensures that any changes to pricing agreements are taken into account.

New pricing agreements that made with the customers may affect billing documents that have already been processed and settled. If a new pricing agreement is effective before the pricing date of the billing documents, we can perform retroactive billing to call up a list of these documents and reevaluate them with the new price. we can then create additional billing documents to settle any differences.

With the retroactive billing type we can perform

1. Call up a list of documents affected by price changes

2. Trigger the system to create the necessary retroactive billing documents directly from the list

3. Create credit or debit memos directly

4. Review any errors in a log

5. Simulate the retroactive billing process for any document

You can call up a list using selection criteria instead of accessing it through a billing list (choose Logistics - Sales and distribution - Billing - Billing document - Retro-billing).

You can now trigger the system to create the necessary retro-billing documents directly from the list. You can review any errors in the log.

New pricing agreements that you make with your customers may affect billing documents that have already been processed and settled. If a new pricing agreement is effective before the pricing date of the billing documents, you can perform retroactive billing to call up a list of these documents and reevaluate them with the new price. You can then create additional billing documents to settle any differences.

Integration

Retroactive billing is a special billing function often used in scheduling agreement processing.

Features

With the retroactive billing function, you can:

Call up a list of documents affected by price changes Trigger the system to create the necessary retroactive billing documents directly from the list

Create credit or debit memos directly

Review any errors in a log

Simulate the retroactive billing process for any document

Terms of Payment in CMR are taken into prioroty while doing a sales order.

Award points if it adds information.

Thanks

Mohan