User Experience Insights
eDocument History reached sequence No. 999 – What now?
Hello SAP Community,
If you have manual activities that you often need to do at a specific time, the Schedule eDocument Jobs app can reduce your workload by running these tasks smoothly in the background. You can plan regular jobs which keeps you free to concentrate on other tasks.
However, plan wisely the frequency which you schedule the jobs of your eDocuments. If you select a job to be performed with high frequency, i.e. many times a day (1), and this document has an error, it is likely that this app will keep on processing this document until it reaches the number 999 (2), like Image 1, below:
Image 1: EDocument History
Once a document reaches 999 entries, there is nothing left to do, unfortunately. This document cannot be cancelled, deleted or resubmitted to the tax authority.
So, what can you do to prevent this from happening?
Well, one solution is not to schedule jobs to be performed with high frequency. Perhaps your jobs can be performed, let’s say, every one hour (1 & 2), as Image 2, below:
Image 2: Scheduling Information
In the example above, even if there was an error, and your job was running throughout the weekend plus a holiday, the number of entries in EDocument History would be way lower than 999.
Conclusion:
By setting your jobs to be performed with as little frequency as possible, it is very unlikely you run into this kind of issue.
I hope you find this information useful. Do feel free to write me a comment if you want me to write on another topic related to eDocuments for SAP S/4HANA Cloud.
Additional Information:
Schedule eDocument Jobs – General
Hi Eduardo,
Thanks for the post and the comments on the topic, it's indeed a very interesting discussion. I personally did not have this problem with eDocuments, but I have seen it in the past with other e-Invoicing solutions.
I also imagine depending on the business context sending documents only every hour does not make much sense as there activities that are time critical, like e-Invoicing where companies really need it every single minute. For other cases like ePayment in MX sending it once per hour would be really enough.
For those time-critical ones, would not make sense also to have a logic in the program that prevents the attempt 999 from being reached?
I can you give 2 examples:
1-The program could cap the maximum number of retries using the document history, at for example '950', and give an error status to the document once it's reached so that the user can manually work with it from the cockpit.
2-Another option is to define a configuration object where the user can define the maximum number of automatic retries for a certain process, to ensure 999 is not reached. After that the edocument stays with error status in monitor.
I think these options would also make sense in a business context, maybe more than just running longer intervals. I also understand this is an exception scenario that does not occur very often, but it can cause big issues in case it happens.
Regards,
Renan Correa
Hi Renan,
Thanks for reaching out.
I see from your profile picture that we have one more thing in common other that eDocuments 😉
There is another way to avoid running into the issue of 999 entries of a document containing errors being stuck. I can share one that probably will meet the expectations of both of your examples.
If you really need to run a job every single minute, you can set a limit of 950 occurrences, as the image below:
That way, once a document has reached 950 entries, and the error still persists, the job will stop running and the document will be available in the cockpit for future actions, featuring an error message.
The purpose of this post was essentially to state that by reducing the frequency of jobs, you would be more likely to avoid this issue.
I think your insight was great and I much appreciate it. I think now readers can find another way to minimize the risk of reaching 999 entries.
Stay in touch!
Regards,
Eduardo
Hi Eduardo,
Thanks for the effort and the analysis of the example.
I really don't think setting the job to 950 occurrences in the scheduler would solve the issue in case it existed. That would just stop the job after 950 occurrences ( 950 minutes in the example ) .
The job scheduler is not connected to the history entries of the edocument, so to stop it in the case of history entries growing too much it would be necessary to have this logic programmed in the eDocument program logic. For NFe there is a similar configuration with maximum number of tries and retries for a given scenario. Anyway, that's an hypotethical example, with eDocument I have never had the system to go until 999 entries and hopefully it will not happen.
I do generally agree that it's always wise to save system resources and only schedule jobs every 1 minute if they're really needed.
Regards and Stay heavy \,,/
Renan Correa
Hello
In our case, we have some custom logic, which raises an error before the edoc is actually sent. Because no one was checking it regularly , we are getting now the error messages about to many entries in the history table for a few invoices. Solution to solve the original error is simple, and we don't need to reverse the invoices.
What would happen, if we simply delete entries from EDOCUMENTHISTORY? Would there be any undesired consequences? I assume then it won't be a problem to finally sent the invoices.
Thank you