Dexterity "get" statement is lonely

If you've read previous blog entries here you'll know I've had problems with ranges.  I'm sticking with the "range where" construct for the foreseeable future because.

I have a window that the user provided an ID field (a string) to adjust some cost data.  When they provided the ID and processed their first result I clear the window then they would enter the next ID.  Dex promptly kicked an error 18 - Missing.

Turns out what was missing was not the data, but a "first" in my "get" clause.  Because the range included multiple results "get" cannot be used on its own.  Once I provided "first" all was well.

Stored Procedure no results in Dex - results from SQL command line

I was developing code in Dexterity that involves the use of a stored procedure.  Plenty of examples of this but I was banging my head trying to figure out why the code worked and provided results when I ran it from a SQL Query command, but no results from Dexterity.

I should point out that no error was ever returned!  By Dex or by SQL.

Here was the problem in a nutshell - I was not providing values for all fields in the Dex table I was filling in from the stored procedure.  Once I filled all table fields in the stored procedure it worked in Dex.

Lesson for future reference.

Dynamics GP Payroll Integration to Payables

We just upgraded to GP 2018 R2.  Fairly uneventful, except for the nooks and cranny's (always gotta watch for them.)  One area that blindsided us was Payroll Integration to Payables (PIP.)

In our previous GP versions (we came from GP 2015 R2) PIP worked for computer checks (of course), but also for manual checks.  As we processed payroll in the new version it became increasingly clear that PIP no longer worked for manual checks.  WTF?

There is not a lot about PIP online, but I found a reference in the GP docs about manual checks not being supported.  I don't know if that's new and they took the feature away or what but it sure doesn't sit right.

Well, being the happy Dex developer I am this just means more work for me.  So off to school we go trying to figure out how to make PIP work for manual checks.

Don't get me wrong PIP is still an external dictionary and would be no fun to hack.  I'm going to spool my own code to make this happen.  And that starts with a whole lot of reverse engineering.

The first issue is where's the data?  Well the GP SDK won't help as PIP is in a separate dictionary.  Opening that DIC file in Dex shows the following tables:

PIP00400 contains the vendors and the next PIP number that will be assigned to PIP transactions.
PIP40100 stores the setup information from the Payroll Vendor Setup window.

I am focusing on PIP40100 now as that contains reference to payroll history in UPR30300 that will contain the manual checks I need to post.  In that table is a column entitled APR_PR_VendorRecordType that I have deduced to contain the following values.

1=Fed Tax
2=State Tax
3=Local Tax
4=Company Deduct
5=Employee Deduct
6=Company Benefit
7=Employee Benefit

Those will point me to the PYRLRTYP values in UPR30300.  It looks like data that posts to payables is summarized by check date.  I'll have more information as I get deeper into the process but wanted to seed this in case someone else was curious.