JAWALL

The rebate functionality is something which the students normally get lost in the mid-way especially when you try to incorporate the manual accruals in the regular scenario. But once the motive of each step is understood, then the proceedings will be smooth and normal. Each rebate has to be created, status of the rebates to be changed for settling, run the settlement and get the corresponding rebate documents from each rebates. As long as the number of rebates is lesser, it can be processed manually by a team of members. But in real time we have a huge number of rebates to process (i.e create, settle)

I was always fascinated about how SAP handles the cash Sales because in Cash Sales there is no credit management involved because the cash is supposed to be received upfront. In my previous Jaleel holdings implementation, to differentiate between the cash customers and credit customers, we populated one of the unused fields in the General Data of the customer. The using the user exit, we disallowed the Standard Order type if that field was populated. So the Salesman HAD to use the Cash Sales document type for Cash customers. But my current cient wanted to take the advances first, post them in the special G/L account and then create the Sales orders. As far as I know (from SD perspective), the advance payments are posted in a special G/L account and when the actual (final) payments are recieved, those entries are knocked off and taken to the customer's General account. I was curious to know about how the advances and the credit management are linked together.

In the SAP Training, we have a detailed chapter for the condition types in pricing which covers the Pallet Discounts/Surcharges, Customer Expected price, Minimum Price and Rounding off. The students used to get bored studying the same kind of descriptions and more than that, most of those condition types are not used in the real time scenarios. Ideally those condition types are more of "nice to have" functionalities. In my recent project I had a chance to use the DIFF for the "Rounding off" functionality.

It is one of the most important functionality in real time but that was leat touched in SAP Training academy. Because of its importance, I always make sure that this topic is well discussed in my online classes. I always take Rebates immediately after I complete "Pricing" and "Condition types grouping". In my latest project I had to explore some functionality about Rebates as the client wanted some rebate conditions and my project's previous consultant had his own understanding and he configured the rebates in certain way. By the time I came, there were few new requirements but the contstraint of multi-level approvals to make any new changes made me try to work within the existing parameters.

It had been really a long time away from the blog. Meanwhile I joined a new company in Chennai and immediately got into an ongoing implementation project. SAP Consultants will know how demanding and consuming the implementation projects are, that too when you join a project that already somebody was working on, the catching up is still more exhausting. Before I could realise, within 20 days of joining I travelled to Nigeria as a part of the assignment. Never in my wierd dreams I have thought that I'll travel to the dark continent at some point of my life. So the travel itself was almost a shock. Also it happened so suddenly that I didn't get time even to pick my camera from home. So this time my LG Optimus P500 came to rescue.

Today we had an account determination issue that made the day interesting... The problem was that the invoice document was not posted to accounts because of the 'Account Determination Error'. When there is an Account Determination Error, the first place to look at is the 'Account Assignment' field in the Customer and Material Masters, whether anything had been changed? Because if a smooth working system suddenly stops working the first casualty could be the master Data. When I checked that there was no change in the Customer Master. However there was a change in the Material Master Data that it was set for deletion. I was tempted to buy that reason but I realised that the efforts to post to Accounts was done much ahead of the deletion flag indication being set. However that was also a learning point - when you can't process an article that was marked for deletion in Sales Order itself, there is no way that the article came via Sales Order.

Cross Selling is a concept where the companies / sellers try to maximise their revenues by proposing materials that are related the products which their customers buy. Example - If a customer buys a TV set, the seller can propose additional materials like Speaker System, Extended Warranty at extra cost etc. This is also an useful feature in SAP SD that was not mentioned anywhere in the TSCM60/62/64.

SAP SD Course (TSCM60/62/64) touches the concept of Item Proposal in the Sales Document types topic. The "Implementing SAP SD" written by Glynn C Williams, normally called as 'Bible of SAP SD Consultant', elaborates more on this Item Proposal through the document type PV. However I feel that SAP Academy is missing out an intresting topic / concept of Dynamic Product Proposal and Cross Selling in its course. Wherever I showed this demo to my SAP Academy students, I was always asked "Why SAP didn't include this functionality in the course?" What is there in these topics that fascinated the students.

Once there was a scenario presented before us which was as follows:- The customer places the order over the phone and the whole subsequent processing must be actioned only after the receipt of full amount in advance. In other words the client wanted the goods to be "invoiced" before delivery creation. We were asked to address this scenario with least or almost no standard deviations/developments and we came up with the following responses.