Hello Kishore,
<b>Returns process: RE</b>
1. The returns order is created with reference to an invoice to ensure the traceability and transparency of the process and is suggested to keep a different number range when configuring.
2. The returns process is very much similar to the credit memo process except for the fact that the actual goods are returned by the customer to our plant.
3. VA01 (RE) – VL01N (Post Goods Receipt) – remove billing block from sales order (VA02) – VF01 (RE) credit for returns, which is in turn is forwarded to the finance company to where a credit note is issued to the customer. Returned faulty goods that are brought back to the plant are not added to the existing stock in the plant, instead you could see them as returns stock when you double click on plant material in MMBE and then after issue a credit note for the retuned value of items.
4. item category – REN; schedule line category – DN; movement type – 651; delivery type – LR and billing type (invoice) – RE (which is either a delivery related / order related billing type)
5. it is recommended to create a returns process order (OR – doc.type – RE) with mandatory fields of reference to the invoice, returns order reason and billing block to prevent a credit for returns being created until an authorised person releases the billing block.
6. The material should be used as goods movement back into stock (651) and inspection is carried out before making them available for the next sales order.
7. it is advisable to indicate a shipping point that is specifically used for returns,. Thus all return deliveries or goods receipts can be done by a specific shipping point. This is useful when running the delivery due list, where you can select - only to process the returns deliveries as well as offer better visibility of stock movements.
8. After the creation and goods issue of the delivery, the billing block is removed from the sales order and the invoice is created with reference to the sale order. This way you can create a credit for the return in the sales order, which in turn has the order quantity copied from the preceding invoice.
<b>Pricing Limits –</b>
Condition types offer an automatic or manually determined value according to their determination. Condition types can also be manually altered, enabling the user the opportunity to overcharge or undercharge a customer. For instance, should we have a discount and do not control its upper and lower limits, the user may incorrectly offer a 100% reduction. For this reason we govern a condition type with a limit.
Menu path – IMG - sales & Distribution - Basic Functions – pricing – pricing control – define condition types – define upper/lower limits for conditions – (OVB2)
Should one have a condition type that can be altered manually in the sales document, one needs to ensure that there is no room left for abuse. For example – condition type RB00 (manual discount), which is the customer and material based discount; we can restrict the user by fixing an upper and lower limits for offering discount. Should the user try to create a condition that falls outside the limited range, he will receive an error message.
The calculation type that you come across while fixing the limits for the condition type be a percentage, the limit will also be based in percentage terms.
It is often recommended to keep the discount in a pricing procedure – percentage based – as it is easier and maintain. Unlike the percentage discount, the value based discount condition type doesn’t take the quantity of items purchased in the sale.
<b>TOLERANCE GROUPS</b>
Tolerances are used for dealing with differences in payment and residual items which can occur during a payment settlement. Tolerance groups represent the difference sets of tolerances to be used in the organisation.
<b>
Examples:</b>
Each vendor should be allocated a tolerance group. The tolerance limits defined for a tolerance group will determine whether an over or underpayment may be processed without being rejected or requiring further authorisation.
<b>DUNNING</b>
Dunning is the process of reminding customers that they owe you money for overdue invoices. The system processes line items and prints dunning notices (reminders) with the name and address of the customer, the text you specify, and the overdue line items from customer invoices.
Dunning is carried out automatically using the dunning program. The program determines the accounts and items to be dunned, the dunning level of the account and the dunning notice based on the dunning level. You print the dunning notices using the print program. The dunning data determined is saved in the items and in the accounts.
The basic parameters for dunning are set up in the dunning procedure. Several dunning procedures can be assigned to one customer. Only those customers that have a dunning procedure defined in their master record are included in the dunning run.
The most important parameters of the dunning procedure are:
• The dunning interval (i.e., level of severity of reminder notice)
• The number of dunning levels
• The grace periods
• The specification of what items may be dunned
The dunning level is determined by the number of days in arrears. Dunning charges can be separately specified for each currency, and can be made dependent on the dunning amount at each level. The dunning charge can also be determined as a percentage of the items due.
Minimum amounts may be specified so as to prevent sending dunning notices for immaterial amounts. Furthermore, a dunning block can be set in the document or the customer master record to prevent a dunning notice from being generated for a particular customer.
<b>How many servers a client can use</b>
totally depends on the project size and the business requirement. In any normal scenario you have Development, Quality and Production servers.
<b>Reward if helps</b>
Regards
Sai
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.