Scripting

Looking for some guidance on writing to another table while running a pre-delete script. @Sage100AdvancedScripting On SO_InvoiceHeader, we have added a pre-delete script with the intention of writing new or updated records to BR_Transaction. The problem that we have encountered in v2013 (the client's system) and also my test v2016 system is that although the posting process seems to complete successfully, it leaves XD invoices in the SO_InvoiceHeader table. Not sure why. The invoice appears correctly posted in IM, AR history, GL, and also the BR table that we want. Because the SO_InvoiceHeader table shows each invoice now as an XD invoice (except the last one which remains as IN), something clearing isn't working. To make matters worse when credit cards are in use, SPS shows the transaction also being voided. Any direction or guidance would be appreciated.

My scripter-guy also added this comment too Also note that when I have this line in the script, the Pre-Delete script only fires for the first invoice, and all subsequent invoices within the batch do not trigger the script (confirmed with pop-ups). retVal = oBRTransaction.Write() When commenting out this line, the batch processes properly, but obviously without the write the script is not going to do what we want.

Can you post a snippet or more of it? The first thought is to turn off the infernal feature to Retain Deleted Invoices in History in A/R Options.

You could try doing a oBRTransaction.Clear() after the oBRTransaction.Write()

Aren't XD from SO Setup Option set ""Y"" to track deleted invoices? Can you turn off tracking deleted invoices?

The Retain Deleted Invoices Option does not seem to be an issue. We tried with and without that. My scripter-guy also pointed out that the original sales orders don't get updated with the quantity shipped, Last invoice number,etc. Will upload a copy of the script when I am back at my laptop for all to see! (After I try Alnoor's Clear() idea)

The Clear() option didn't work, so I'll post the full script here for any input. The overall summary for this script is that we are trying to post payments (either credit cards or other) from the SO_InvoiceHeader and SO_InvoicePayments tables to BR_Transaction if the payment type GL account is also associated with a bank code letter. I've written a very simple version of this, too, but get the same error.

I did a bunch of testing based on the shorter version of the script you sent me and also looked at the Write() method code of BR_Transaction_bus.pvc and compared it to others. To make a VERY LONG story short BR_Transaction_bus will not work with scripting. It's not restricted to working from the Check / Dep / Adj Entry UI screen but it does not have all the event scripting hooks necessary to work beyond the 1st Write as you saw. Also your starting object and procedure call does not matter. In your case it was Pre-Delete of SO Invoice Data Entry but it could have been Post-Write of A/P Invc Data Entry and same thing would've happened. The XD hanging invoice phenomenon I didn't run into but if you moved the script to Post-Delete that should get avoided but the central B/R problem is unsolvable through scripting. What I suggest is have your script populate/append to a CSV file or UDT on Pre-Delete. Then as a separate step, run a V/I to import into BR_Transaction from that source. V/I will definitely work. BOI should work too. This is a design bug with scripting.

Thank you, @AlnoorCassim for your research. We have a button script working (from GL GJE, on top of the Accept) to post to BR, but we don't have a similar option available in the SO Invoice Posting. My interim solution was the nightly automated export/import so we'll continue to use that for now.

Glad you mentioned that. To summarize, V/I, BOI, and button scripts will work (any UI script) but not event scripts. Just to be complete there is a 4th option which is ask your regular MD / ISV to create a program override for SO_SalesJournal_Upd based on your script.