I have a customer that issues thousands of invoices to a handful of customers. So when they receive a payment from a customer, they have to apply the payment to hundreds or thousands of invoices.
To accommodate this high volume / bulk payment apply process, I developed a custom AR apply window. The window works well on its own, but the customer wanted the ability to launch the custom apply window from the Cash Receipts Entry window, immediately after they enter the payment.
When the user launches my custom apply window, they wanted the customer, payment doc number, check number, and payment amount from GP all pre-populated so that they could immediately start applying the payment, which makes complete sense.
No problem, I thought. Easy peazy lemon squeezee, right?
In my VS Tools AddIn project, I added the Menu Handler to the Cash Receipt window so the user could open my custom window. Very straightforward and worked fine.
I then added some code to read the field values from the Cash Receipt window so that I could populate the fields on my custom apply window. That was simple as well and everything looked good.
But when I tested the code, it didn't work. My window would launch, but the fields on my form weren't populating.
In Visual Studio, I attached to the Dynamics.exe process and started debugging. I found that an If statement was being skipped:
if (rmCashReceiptWindow.CustomerNumber.Value != string.Empty && rmCashReceiptWindow.DocumentNumber.Value != string.Empty && rmCashReceiptWindow.CheckNumber.Value != string.Empty)
That was odd, since I had populated all of the fields on the Cash Receipt window.
The customer number, document number, and check number were all populated.
I checked the field values in Visual Studio, and to my surprise, the DocumentNumber field value was empty.
I could read the Check Number and Customer Number just fine, but the Document Number field had no value, even though it was displayed in GP.
Um, what gives?
Just to make sure I wasn't making a silly mistake, I fired up Andrew Dean's very cool VSTools Object Explorer that we demonstrated at our reIMAGINE session last week.
Sure enough, the Object Explorer confirmed that the Document Number field had no value, and that the value wasn't stored in any of the other fields accessible through VS Tools.
This confirmed that with an UNSAVED cash receipt, the Document Number field value was not accessible in VS Tools.
But after I saved the cash receipt, then pulled the receipt back up in the Cash Receipt window, I could read the Document Number value in VS Tools.
Not sure what is going on. My two wild guesses are that during data entry, the field value is being stored in some temporary field--which seems really strange. Or, the VS Tools field value is somehow wired up to the underlying Dex table buffer, and that table buffer value is not populated until the transaction is saved. Which seems like a stretch as well.
I'm going to dig into it further and see if other windows have this issue, but this definitely complicates things if you are trying to trigger events in VS Tools that depend on the GP document number during data entry.