Jelle Uenk
Read all my blogsEven after many years working with SAP CRM on Premise, I’m sometimes asking myself why something is not working as expected (or at least not as we thought should be logical). And while we like to build technical solutions to solve these, it is sometimes easier (not forgetting cheaper as well) to accept the issue once analysed – if there are no actual business implications or customer inconvenience, and just continue with more important business topics.
Let’s take a recent example I encountered at a project, where we have a nice CRM on-premise system linked to an ECC back-end. One of the processes implemented in our environment is consignment, with consignment fill-up for putting goods on stock at customers location, and consignment issue when the customer tells us he how much and when he took goods from the consignment stock.
So far – all proven, standard SAP. Below picture from the SAP documentation nicely visualizes the consignment fill-up and consignment issue.
The issue…
Of course this is actually mainly an ECC back-end process, however since Customer Service works mainly from CRM, the consignment order types were implemented in CRM to allow order entry in CRM as well for these.
Customer Service receives an overview of the goods taken from consignment stock from the customer, correctly fills in all the given details in the CRM order, and the ECC back-end system nicely creates a delivery for the goods, and posts the goods issue.
Client expectation was that the billing date should be the same as the date of the consignment issue (the date the customer told us he had used the goods). Still all green lights, I assumed, since we did not get any questions on this process. Until we found out that the billing date on the invoices was not always correct .. Some thinking and testing later it was always the date on which we entered the order, even though the users nicely filled in the requested delivery date (assuming this would be the actual delivery date).
Why didn’t this work as everyone expected?
After some analysis…
Long story made short, we could put anything in the requested delivery date in CRM , that value was nicely copied into the ECC order, however the goods issue (during our daily batch run) was always posted with the current date – not the date the consignment issue was done (as filled in by CS in the requested delivery field).
For regular goods issues which are usually done the same day that the goods are shipped this is logical and also correct. However for consignment (where the customer informs us e.g. what he used during the weekend) this results in all postings for the weekend to be posted as if issued on Monday…. Not exactly what we wanted.
Of course, after some checking and manual delivery processing in ECC we realized that we could fill in the actual goods issue date in ECC before pressing the Post Goods Issue button.
To develop or not to develop…
However our client’s Customer Service employees are working only from within CRM, and should not manually have to update ECC documents. What options did we have here to get our desired result?
Procedural:
- Leave as is, accept (and explain to customer)
- Manually correct each delivery before consignment goods issue
- Process the invoices for consignment issue separately such that we can fill in a billing date during invoicing
Technical (Now it’s getting interesting ….)
- Update copy control from delivery to billing in order to control the billing date using some logic to be specified
- Update copy control from consignment issue order to delivery such that we can control the actual goods issue date (ECC field LIKP-WADAT_IST) from e.g. the requested delivery date
Both these technical options require that we correctly enter the consignment date which the customer told us into the CRM consignment issue order in e.g. the requested delivery date. Then we also need some control table logic needed since we need to trigger this only for consignment issue orders.
In our case, we opted not (yet) to go for the technical solution however to go for a business approach – explaining the SAP processing logic to our client, and where challenged by customers validate whether it is an issue or not.
So for for me this was a good example where our standard approach to start developing a technical solution is not per definition the only way forward – business has often several other priorities both in time and budget, and a choice not to do technical development can be preferable.
Receive our weekly blog by email?
Subscribe here:
2 responses to “Technical solution not always needed…”
Hi Jelle,
great blog and indeed sometimes it is better to understand and accept limitations.
have you considered using the pricing date? and use the service rendered date as your billing date? I am not 100% sure this would the trick.
Best Regards,
Remko
Hi Remko, thanks for your feedback. We indeed had tried the mentioned options, however (at least in our setup) these did not result in the expected billing date.