Pls post ur questions/concerns.

Pls post SD related query and we will try to resolve it ASAP.

Real time scenarios/issues

Pls post real time scenarios/issues, so that other guys/gals can have a idea of real time scenarios/issues and can give their suggestions.

Sample: Sales document type (ZOR1 and ZOR2)  should follow different number range.Sales orders from each sales order types must be consecutively numbered.

SD: Pricing Procedure (Main Screen)

Different fields and their meaning:

• Step: It determines condition sequence in a pricing procedure.
• Cntr (Counter): This is a mini step in original step.
• Ctyp (Condition Type): Self explanatory, here we give condition types.
• Description: This is condition type description; this comes automatically, once we enter condition type.
• Fro & To (From and to): This is used either for calculation basis or for subtotal range.
• Man. (Manual): This ensures that this condition type can only be entered manually.
• Mdt (Mandatory): This ensures, that condition is mandatory and if a mandatory condition dint find, it gives an error.
• Stat (statistical): Statistical condition types will not affect item net value.
• Print: This determines behavior of different condition types in print out.
• Sub to (subtotal): Here we can choose a field and this field will be used for storing condition values and (if required) this filed can be used further for calculation purpose.
• Reqt (requirement): Requirement field can be used to restrict system from accessing condition table.
• AltCty (Alternative Calculation Type): Here we can define a routine, which can be used as an alternative in calculating condition type value.
• AltCBV (Alternative Condition Base Value): Here we can define a routine, which will be used to determine alternative base value.
• ActKy and Accrls (Account key and Accrual account key): Here we give account key, which is used to post amount to different revenue accounts.
  
  
  This is basic info about Pricing Procedure, if you need more information on this, pls email me or reply via comments.

SD: Complete and Partial Delivery

Complete Delivery check: This is required when customer wants order to deliver completely. This can be set either in customer master or Sales Order.

SO Partial Delivery: For SO partial delivery we have following scenarios:

1. Partial delivery allowed
2. A Create a delivery with qty greater than zero
3. B Create only one delivery (also with quantity = 0)
4. C Only complete delivery allowed
5. D No limit to subsequent deliveries

• Indicator - Partial delivery allowed: We can create multiple partial deliveries for SO line item.
• Indicator - A (Create a delivery with qty greater than zero): If due to some reasons, we can delivery only partial quantity, using this indicator we can’t create other delivery for remaining quantity. Order is marked as complete.
• Indicator – B (Create only one delivery (also with quantity = 0)): Same as indicator A, the difference is we can create a delivery with zero qty also.
• Indicator - C (Only complete delivery allowed): System gives a warning message, if we try to create line item partial delivery.
• Indicator – D (No limit to subsequent deliveries): We can create as many as deliveries as we want. We can even do over delivery. Order status is not completed until we assign it manually.
  
  Partial delivery indicator can be set in Sales Order item level, customer material info record of customer master record.
  

Delivery group: This is used when u want to ship few selected lines items together from SO. Delivery group can be set Shipping tab from the overview screen.

This is basic info about Complete and Partial Delivery, if you need more information on this, pls email me or reply via comments.

SD: Forward/Backward Scheduling

From scheduling point of view following dates/time are important:

1. Confirmed delivery date: date on which system confirms good receipt for customer
2. Requested delivery date (RDD): as requested by customer
3. Goods issue date (GI date): date on which goods leaves delivering plant
4. Loading date: at this date picking and packing should be completed and goods are ready for loading.
5. Transportation planning date: at this date we should start arranging transportation.
6. Material availability date (MAD): at this date material is in stock for picking and packing.
7. Order date: at this date customer places order.

Transit time (D23 - difference in RDD and GI date) – Time needed for goods to reach customer. It comes from route
Loading time (D34 – difference in GI date and loading date): Time needed for goods loading. It comes from shipping point
Pick/pack time (D46): Time needed for picking/packing. it comes from shipping point
Lead time (D45): Time required for arranging transportation. It comes from route

System starts from customer RDD and find out MAD and transportation planning date. Delivery must be created on earliest of these dates.

Backward Scheduling:

• If order date is before these dates (both), customer RDD can be confirmed.
• In this case confirmed delivery date and RDD are same
• And as a result a single schedule line is created
  

Forward scheduling:

• If order date is after any one of these dates (MAD and transportation planning date), customer RDD can’t be confirmed.
• In this case system takes order date as base date and calculates confirmed delivery date and this date will be ahead of customer RDD.
• As a result, system will give two schedule lines; one for customer RDD with zero confirm qty and other for new confirmed delivery date with confirmed qty.
  

This is basic info about Forward/Backward Scheduling, if you need more information on this, pls email me or reply via comments.

SD: Invoice List

• As the name suggests, this is list of invoices, sent to payer at specific time interval. Payer pays for all invoices sent to different ship to parties.
• Invoice list type is assigned to billing type.
• Different invoices included in invoice list must be released to accounting.
• Customer calendar must need to be defined in customer master. Invoice list can be created on dates mentioned in this calendar.
• Payer pays for all invoices; payer gets a factoring discount (condition type RL00).
• As per country tax structure, payer may need to pay tax (condition type MW15) for factoring discount.
• Invoice list consists of document header (summary info) and document items (each billing document).
• Output type LR00 is used for document header and RD01 is used for document items (for invoices in invoice list).

This is basic info about Invoice List, If you need more information on this, pls email me or reply via comments.

Pls post ur questions/concerns.

Pls post SD related query and we will try to resolve it ASAP.

SD: Material Listing and Exclusion

• Material listing and exclusion is used in determining which materials customer can buy or which material customer can’t buy.
• It follows condition technique.
• For material listing and exclusion ‘Sold to party’ and ‘Payer’ are important partner functions.   Material listing:
• If sales document have different sold to and payer partner function and sold to party has material listing, it check only for sold to listing (no additional check).
• If sales document have different sold to and payer partner function and sold to party don’t have material listing, it check payer material listing.                                                                                         Material Exclusion:
• if sales document have different sold to and payer partner function, it first checks for sold-to master record if a valid master record is found, it stops further searching, otherwise it check s for payer master record.
• If sales document have different sold to and payer partner function and sold to party don’t have material exclusion, it check payer material exclusion.
  
  

This is basic info about Material Listing and Exclusion. If you need more information on this, pls email me or reply via comments.