There is no standard automation around the External Document No. because this is an external number normally provided by your external customer/vendor.
But you want to create the functionality you describe above, then you should create the code on the “onDelete” trigger in the table. Here you need to create new code to update the numbers on the remaining lines.
So I really have two separate trains of thought going here. In the first, I’ll beg the question and, in the second, I’ll attempt to answer it.
First, let’s ask WHY you want to do this (other than the obvious possibility that it simply offends your sense of order.) What’s the point? You’ve already said that, in the case where you delete a line that has an Ext Doc No value of anything other than the Last No Used, you don’t want to do anything; and that you only want to act if the Ext Doc No value matches the Last No Used. If I’ve understood you correctly, then you must not be concerned about gaps. And if you’re not concerned about gaps then why do you need to treat the two deletion events differently? The only thing that comes to mind to possibly answer that question would be that you’re worried about running out of numbers. If that’s the case, then it would be far easier to change the series definition to include a few more digits. You have lots of space available to do that. If, on the other hand, you really are doing this because it offends your sense of order, then maybe you might consider an alternate venue for addressing this kind of hitch in your mental get-along? If you don’t have a solid business case for dealing with this, then leave it alone. If you do have a valid business case, maybe you could let us in on it?
On the second train of thought - suggesting actual answers to your question - I can think of a couple of options. To begin with, you might try not assigning values to the Ext Doc No field until you post the journal. If that doesn’t cause issues elsewhere, it would certainly solve the problem. Or, you can build a function that returns the highest value of Ext Doc No within the current journal batch, and then call that function in the OnDelete trigger of the form or page. For the function design, you would pass the rec variable to the function, and return a Code10 which would represent the value you’re looking for. The process in the function would either make use of SETCURRENTKEY and FINDLAST, or wheel through the recordset using REPEAT…UNTIL and testing to see whether the Ext Doc No value in the current record is the highest and, if it is, updating your function return variable accordingly. The choice of which approach to use would depend on your aversion/attraction to the idea of declaring a local copy of the t_81 object and creating a key for that table that appropriately includes the Ext Doc No field and, alternatively, your feelings about wheeling through the entire journal just to find a single value. Or, you could create an entirely different function, in which you inspect the value of the Ext Doc No field in the line being deleted, compare it to the value of Last No Used in your No Series, and decrement the Last No Used value if they match. I’m sure there are many other options too, if you must.
I think that you and I have said the same thing. You want to roll back the value of the Last No Used field in the No Series record under certain circumstances.
The methods I offered for doing this are still valid (although the scenario where you’re deleting multiple lines simultaneously would probably require some additional coding if you opted for a method other than not populating the Ext Doc No until you post), as is the challenge to your reason for wanting to do it in the first place.
I tried your solution. I wrote a method to get the last Ext. No from the current journal batch, and call it inside the Ondelete method as you said. But still it returns the External Document No. that I’m deleting (If I’m deleting the last line of the journal batch).
What I want is to get the Ext. No of the line remaining after deletion.