My first suggestion, to make your code more comprehensible to yourself and others, is to work on your indentation and code style; they are a part of your coding standards, along with capitalization, line-breaking, use of whitespace, etc. Frankly, the indentation is all over the place and I can't understand why many lines have the indentation that they do. Indentation should convey a sense of the block structure of the code, where you have conditional execution, etc.
Consider the last five lines of the screenshot above. There the indentation makes sense to me. You have a condition (
IF NOT AVAILABLE binmst THEN
) followed by a DO block with two indented statements. Their indentation visually conveys that they are within that block and subject to that condition. But the first visible IF statement (
IF NOT AVAILABLE ITEM...
) uses similar indentation but puts the line break after the DO: rather than between THEN and DO:. This inconsistency adds to the cognitive load on the reader.
You have a couple of instances of indenting the statements following a FIND statement, as if it were the beginning of a block like DO, FOR, or REPEAT; it is not.
Looking at your REPEAT block near the top, you indent the following IMPORT statement by 4 spaces, then the following ASSIGN (which should not be further indented) by 8 spaces, then the following DO statement (which also should not be further indented) by a further 7 spaces. Then the next two statements, despite being within that DO block, are not indented at all. It is a bit of a mess.
You might be inclined to argue that all of these criticisms are about cosmetic things and they do not affect the code that the compiler emits. That's true. But you and I, and whoever is given that task of maintaining this code after you, are not compilers. Coding standards exist for a reason. They ensure consistency and comprehension. They facilitate static analysis. They are important.
Certainly there are many differences between one coding standard and another, and people much more knowledgeable than me will argue their relative merits. The point here is that having just about any coding standard is better than having none.
So while you consider this one particular case (what is happening with my UPDATE statement?), take a step back and think about how this code, whether semantically correct or not, could be made much more readable and thus easier to debug. And think about whether that problem is limited to this one particular procedure or whether it is much larger in scope within your application.