You are trying to view the source of the call stack for the Acumatica code which you don’t really need to do. The call stack will show the method calls leading up to the error. Attempting to inspect the source of the method calls won’t work unless you are decompiling Acumatica code. 

Presumably you already checked that the field isn’t null on the APAdjust object so something would have to be setting it to null. You can put a debug point on the DAC setter and then look at the call stack to determine where it is getting set to null. You could also create your own event and intercept it there(again looking at the call stack).

I would also verify that manually triggering the action isn’t causing the same error. That would indicate that something is going wrong when you are initiating the graph before calling the action.

Also I’m probably repeating myself but Voiding and Reversing the Application are not the same thing. Reversing applications will re-open the payment but not void it. Voiding the payment will reverse applications as well as cancel the payment. You are saying you want to void the payment yet you are calling ReverseApplication above. 

I was able to reproduce your issue locally and just debugged it myself.

            APPaymentEntry graph = PXGraph.CreateInstance<APPaymentEntry>();

            graph.Document.Current = graph.Document.Search<APPayment.refNbr>(YourRefNbr);

            graph.UnattendedMode = false;

            try
            {
                graph.voidCheck.Press();
            }
            catch (PXRedirectRequiredException) { }


            graph.release.Press();

So I had to set the UnattendedMode to false on the graph after instantiating it. There is an event handler that doesn’t set the value of the AdjdCuryRate field if the UnattendedMode is set to true(it interprets that as an internal call).

You will also want to catch the redirect exception and then release the document afterwards. 

That would seem to be a bug on 21R2, I’d check with Acumatica and see what they say. I was able to replicate it on my 21R2 instance. The same issue doesn’t seem to be happening with ARPayments. I’m guessing there is an issue with how they are checking for documents being out of balance for APPayments.

It could be related to your issue, but I would expect to get the same error via code as in the UI. 

You already added that

graph.APPost.Current = graph.APPost.SelectSingle();

The Update and Insert methods aren’t changing the values, they raise events and event handlers modify the values. One of those event handlers is setting that value to null during:

Adjustments.Update(adj);

What I am saying is using the call stack and debugger you can see the method chain when that value is set to null and then figure out which event handler is the cause and why. 

That being said if it is working in the UI for the same record the issue is likely with the surrounding code or the context from which you are invoking the action. 

What is the status of the ap payment you are trying to void?

I would probably recommend stepping through the VoidCheck method. It sounds like something might be going wrong there. Assuming it succeeds it would create a voiding document and set the current document to that new voiding document. That is the document you want to release. If that method skips or fails to create that document it would be attempting to release the original closed check which is why I think you are getting that error.

The VoidCheck method is a method in APPaymentEntry, what you posted was the PressImpl code. You should be setting a breakpoint at the top of the VoidCheck method and then walking through it. 

You have to release the document afterwards, reverse application just creates the reversal under Documents to Apply. APAdjust is the adjustment that you are reversing(APPost is the view where you are setting the current APAdjust). 

You don’t really need to see the actual value, you just need to figure out what methods are changing the value(visible in the call stack).

You extended APReleaseProcess instead of APPaymentEntry.

Hi @markusray17 

I have an extended Payment entity

However the debug does not step here after action calls

It’s not a copy it is a voiding document. To void a check the system creates a Voided Check document that mirrors the original check, until that document is released though the original check is not voided.

@markusray17 

Ok

One moment to clarify - why it is needed to call release after voidcheck action ? In interface I just pressed Void button and it created copy of existing payment, why in code we must use release ?

You shouldn’t be modifying APPaymentEntry, you would put that code into a graph extension of APPaymentEntry. If you have trouble with that the Open University has courses on extending/modifying graph logic(T210 I believe). 

        public delegate IEnumerable ReleaseDelegate(PXAdapter adapter);

         PXOverride]
        public IEnumerable Release(PXAdapter adapter, ReleaseDelegate baseMethod)
        {
            foreach(APPayment apdoc in adapter.Get<APPayment>())
            {
                var inv = apdoc;
            }

            return baseMethod(adapter);
        }

It will not allow me to modify ApPaymentEntry due to Acumatica project can not be fully built with all packages , I built only my solution, not Acumatica site . It gives hundred errors when I try to built Acumatica website

That’s exactly what it should be doing.

Try overriding the Release method on APPaymentEntry and then inspecting the invoices, something like:

        public delegate IEnumerable ReleaseDelegate(PXAdapter adapter);

         PXOverride]
        public IEnumerable Release(PXAdapter adapter, ReleaseDelegate baseMethod)
        {
            foreach(APPayment apdoc in adapter.Get<APPayment>())
            {
                var inv = apdoc;
            }

            return baseMethod(adapter);
        }

You would need to put the above code inside a graph extension for APPaymentEntry but that should allow you to inspect the apdoc variable without it being optimized away. It should be a void check with a balanced status.

@markusray17 

At this part

    APPayment voidcheck = Document.Search<APPayment.refNbr>(Document.Current.RefNbr, APPaymentType.GetVoidingAPDocType(Document.Current.DocType));

void check is null

this part gives error at that part

@markusray17 It is needed to use APReleaseProcess to support my custom logic

Maybe there is again some issue with parameters as it was with voidCheck method ?

@markusray17

After void payment has status Hold

I tried to set balanced manually but it did not help

You probably have the Hold Documents on Entry option selected in the AP Preferences.

You would have to use the Remove Hold action before releasing then. 

The reason for extending APPaymentEntry wasn’t related to your business logic it was a temporary method to allow you intercept and debug the Release call.

@markusray17 

I entered to this method

In what part exactly document creation is happening 

This code partly solved my issue

It voided some payments if I missed removefromhold and release steps

At this screen 001989 and 001989 items were voided 

But if I leave all my code to execute payment will appear closed 

What I must change in order to make payment availble after hold ? I mean to make it open or balanced (justnot being closed)

There’s no reason to put the voided check on hold, you can just check if it is on hold and then if it is call the release from hold action. 

You have asked this a few times now but:

Reversing the applications will move a payment from closed → open. Voiding a payment will reverse the applications and cancel the payment moving it from closed → voided. There is no way to move a payment from closed → balanced. 

If the payment is still closed then the voiding didn’t work, judging from your screenshot the voided checks didn’t get released.

If you need to reverse payments you will likely run into an error(“document is out of balance”) I believe they are changing it in future versions but currently the system doesn’t allow AP payments with open balances. Meaning you would have to reverse and re-apply the payment at the same time in order to persist it. 

Also I have probably said it before but I would suggest you take a step back from the code and take a second to understand what you are doing and what you are trying to accomplish. You seem to be unsure on whether you want to re-open payments or cancel them and you seem to have little understanding about how the payments work in the system. I can try to point you in the right direction but your lack of understanding is likely to result in problems for you down the line. This is also one of the more complicated and sensitive parts of the system so you really don’t want any potentially critical bugs. 

@markusray17 

“Closed” state

hi @markusray17 

I am sincerely  grateful for all provided help, thank you for your professionalism and patience.

I have accomplished logic that I must have been implemented.

Best regards 

Hi @markusray17 

I checked manually in UI reverse application action and it worked.

You were right, the error happens after this part as you mentioned : “I would suspect it is happening in the Adjustments.Update call after the AdjgCuryInfoID value is set.”

You suggested me that DAC for my case will be APAdjust class, where exactly I should set a breakpoint ? I do not know which field is responsible for putting null to NewValue field