Hello Everyone,
I just wanted to share my experience regarding one interesting scenario happened in my project.
Sales Department end user raised an issue where in the sequence of numbering newly created Invoices is not happening properly. Suppose if Invoice 1000 is created successfully, the next 1001, 1002 gets missing and we have Invoice 1003 created successfully. This is happening quite from a month back and surprisingly this issue didn't get noticed. Recently there has been an Audit happened and department guys questioned about the inconsistent sequential order of Invoice numbering. This has been escalated to higher departments and a critical incident has been raised to get some resolution.
Analysis done from Functional Consultant Point of View:
As soon as this got created, my OTC consultant started looking out for exhaustion of Number Ranges if any, but still there wasn't warning and ranges looked alright. They tried to create invoices manually but then created successfully as well.
And then further analysis resulted in finding out one background job which is for Automatic Invoice creation and Printing. The Automatic Invoice is running successfully and the problem is with the printing Job. And here comes the role of Technical consultant to do the task of debugging and finding out the problem.
Actual problem:
There was a custom output type linked to this invoice and there is custom smart form developed for printing the Invoice. The output type is not getting processed successfully. This is because of problem with logic in Form Initialization code. Hence it resulted in an error, even though the invoice created successfully the output type processing type is "Send Immediately" which alerts the system to process it the next second the invoice created. This happens in an update task and if any problem occurs ROLLBACK WORK happens which leads to invoice getting prematurely deleted even though there isn't any problem with invoice header/Item data. This leads to a creation of ST22 dump as well as SM13 queue update error.
Closer analysis of ST22 dump gave a clear picture that the code is actually converting the quantity into a different measurement unit as per custom requirement. This conversion was done using the function module "MD_CONVERT_MATERIAL_UNIT"
There after a CEIL function in ABAP has been used to get the next largest number if conversion results in decimal values so it has to be rounded off to the next largest number. The resulting value is put into a variable which is of type UMREN. From an ABAP'er perspective, here the length becomes too large which leads to OVERFLOW_CONVERSION_ERROR dump. The proposed solution is obviously fixing the custom code by changing the length of variable.
Here comes the actual twist,
OTC SME's rejected the solution saying that it worked all the way until now, but why it's not working at this time. Yes, of course the Job was built almost 7 years back and never encountered such a strange problem. They further analyzed and came to know that the form was changed exactly a month back and they started suspecting the Developer who actually did the change committed a mistake. But that wasn't all, after careful analysis the change has nothing to do with the error. No where in this change, neither the quantity was re-calculated nor any change in measurements unit. But even after this the SME's weren't completely convinced. This has to be fixed within 8 hours as it's the SLA resolution time for our project for P1 CRITICAL tickets. For temporary resolution the Output processing type was changed from "Send immediately" to "Send with periodically scheduled job".
But then the ticket wasn't closed yet and we're looking for alternative ways to get rid of the error. We came to know the material number which was actually causing the problem . We checked all the ST22 dumps and this same material was the culprit allover .We tried to replicate the scenario in Quality using the data that was captured in SM13 , but no luck since this material wasn't existing and newly created 2 months back. Data refresh happens in an interval of 4 months and this Material wasn't there in quality.
Somehow we navigated to MM03 and we got a thought of checking recent changes to the material and here comes the end of the show, End used changed the quantity conversion factors in units of measure
This has led to quantity becoming too large which ultimately resulted in this error.
Last but not the least point , During audit if this was questioned there was a report which shows the missing invoice information RFVBER00 . This report can be extracted and be used to share with Audit teams so they believe that it caused due to some inconsistent data and not because of fraudulent practices.
Cool Regards,
Lakshmana
I just wanted to share my experience regarding one interesting scenario happened in my project.
Sales Department end user raised an issue where in the sequence of numbering newly created Invoices is not happening properly. Suppose if Invoice 1000 is created successfully, the next 1001, 1002 gets missing and we have Invoice 1003 created successfully. This is happening quite from a month back and surprisingly this issue didn't get noticed. Recently there has been an Audit happened and department guys questioned about the inconsistent sequential order of Invoice numbering. This has been escalated to higher departments and a critical incident has been raised to get some resolution.
Analysis done from Functional Consultant Point of View:
As soon as this got created, my OTC consultant started looking out for exhaustion of Number Ranges if any, but still there wasn't warning and ranges looked alright. They tried to create invoices manually but then created successfully as well.
And then further analysis resulted in finding out one background job which is for Automatic Invoice creation and Printing. The Automatic Invoice is running successfully and the problem is with the printing Job. And here comes the role of Technical consultant to do the task of debugging and finding out the problem.
Actual problem:
There was a custom output type linked to this invoice and there is custom smart form developed for printing the Invoice. The output type is not getting processed successfully. This is because of problem with logic in Form Initialization code. Hence it resulted in an error, even though the invoice created successfully the output type processing type is "Send Immediately" which alerts the system to process it the next second the invoice created. This happens in an update task and if any problem occurs ROLLBACK WORK happens which leads to invoice getting prematurely deleted even though there isn't any problem with invoice header/Item data. This leads to a creation of ST22 dump as well as SM13 queue update error.
Closer analysis of ST22 dump gave a clear picture that the code is actually converting the quantity into a different measurement unit as per custom requirement. This conversion was done using the function module "MD_CONVERT_MATERIAL_UNIT"
There after a CEIL function in ABAP has been used to get the next largest number if conversion results in decimal values so it has to be rounded off to the next largest number. The resulting value is put into a variable which is of type UMREN. From an ABAP'er perspective, here the length becomes too large which leads to OVERFLOW_CONVERSION_ERROR dump. The proposed solution is obviously fixing the custom code by changing the length of variable.
Here comes the actual twist,
OTC SME's rejected the solution saying that it worked all the way until now, but why it's not working at this time. Yes, of course the Job was built almost 7 years back and never encountered such a strange problem. They further analyzed and came to know that the form was changed exactly a month back and they started suspecting the Developer who actually did the change committed a mistake. But that wasn't all, after careful analysis the change has nothing to do with the error. No where in this change, neither the quantity was re-calculated nor any change in measurements unit. But even after this the SME's weren't completely convinced. This has to be fixed within 8 hours as it's the SLA resolution time for our project for P1 CRITICAL tickets. For temporary resolution the Output processing type was changed from "Send immediately" to "Send with periodically scheduled job".
But then the ticket wasn't closed yet and we're looking for alternative ways to get rid of the error. We came to know the material number which was actually causing the problem . We checked all the ST22 dumps and this same material was the culprit allover .We tried to replicate the scenario in Quality using the data that was captured in SM13 , but no luck since this material wasn't existing and newly created 2 months back. Data refresh happens in an interval of 4 months and this Material wasn't there in quality.
Somehow we navigated to MM03 and we got a thought of checking recent changes to the material and here comes the end of the show, End used changed the quantity conversion factors in units of measure
This has led to quantity becoming too large which ultimately resulted in this error.
Last but not the least point , During audit if this was questioned there was a report which shows the missing invoice information RFVBER00 . This report can be extracted and be used to share with Audit teams so they believe that it caused due to some inconsistent data and not because of fraudulent practices.
Cool Regards,
Lakshmana
- SAP Managed Tags:
3 Comments
