So great to get some fabulous news about upcoming enhancements to the Human Resources and Payroll modules in Dynamics GP 2013 from Terry Heley at Microsoft. On my list of things to be really excited about....
1. Including the deduction, benefit, and pay code modifier tools directly in the product! This is such a HUGE thing in terms of ease of use and end user satisfaction. So you will be able to change pay codes, deduction codes, and benefit codes using these tools. Very cool.
2. Another one that scores high in my book when it comes to end user satisfaction is the option to turn off the printing of alignments for checks and earnings statements. Yay! We are moving up in the world and past the age of dot matrix printers that needed alignment :)
3. All of the scripts I have saved over the years may not be needed any more, since we will also have the ability to edit pay history for FUTA, SUTA, and Workers Comp. So if pay codes are set up incorrectly, you will be able to fix previous payrolls through the interface itself rather than using scripts, or having to back out and re-enter transactions.
4. Enhancements for payroll extensions, too! We will be able to disable Deduction In Arrears reports from printing! And Payroll Integration to Payables can summarize federal taxes in to a single voucher, to minimize the number of entries in payables (I just had a client last week who was thrown off by the number of vouchers created by federal tax, so this is a timely announcement in my book).
.
Lots of quality report fixes too, including those in Benefit Self Service in Business Portal (we love those bug fixes!)
Also, just a reminder that a 2012 Year End Update will be provided for Dynamics GP 20.0 customers, as well as Round 1 tax tables for US for 2013. Then that will be the end of mainstream support (no more tax updates or code updates), although extended support will continue through 10/10/2017. As always, contact your Partner or Microsoft if you have specific questions about the product support lifecycle.
https://mbs.microsoft.com/customersource/support/selfsupport/hottopics/HOTTOPIC_MDGP10_SupportLifecycle
https://mbs.microsoft.com/partnersource/support/selfsupport/hottopics/HOTTOPIC_MDGP10_SupportLifecycle
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
My blog has moved! Please visit the new blog at: https://blog.steveendow.com/ I will no longer be posting to Dynamics GP Land, and all new posts will be at https://blog.steveendow.com Thanks!
Saturday, March 31, 2012
Saturday, March 24, 2012
eConnect 2010 Does Not Properly Validate Purchasing Invoice Numbers
I developed a very interesting Purchasing Invoice integration using eConnect 2010 that recently went live after many months of work. It was incredibly complex due to the client's unique business requirements and data, and the integration had to automatically handle a lot of unusual exceptions.
One situation was that vendors would sometimes split an invoice. So on Monday, they may send data for Invoice 12345 that matches to 10 purchase receipts. But then on Wednesday, they may send data for Invoice 12345 that matches to 5 other purchase receipts. All of the data is technically valid, but because the data for Invoice 12345 is being received at two different times, Dynamics GP thinks that the second set of data for Invoice 12345 is a duplicate (since the client, like most GP customers, has enabled the option to not allow duplicate vendor invoice numbers).
To address this issue, I had to add a routine that would add a suffix to the invoice number when necessary, such as 12345-1, 12345-2, etc., so that we could avoid a duplicate invoice number error. Because the import was for Enter/Match Invoice, we were matching against receipts, so there was little to no risk that a duplicate invoice would get imported.
This worked great, and handled the occasional situations where the same invoice number was transmitted on two different days.
So after quite a bit of testing, the integration went live this week, and we were able to import invoice data for the prior few weeks. The import went very smoothly, bringing in thousands of vendor invoices. The batches were reviewed and then posted, and we sighed in relief at the conclusion of a challenging project.
But when the client opened the Purchasing Batch window, some of the imported batches were still listed, and they contained some transactions. When the client tried to post them again, the batch posting progress window would appear and the status would fly by quickly, but the transactions would still be sitting in the unposted batch.
I ran an Edit List on the batch, and to my surprise, the report said this under every transaction:
This was odd, since during testing, we had obviously discovered that eConnect prevented the import of duplicate Purchasing Invoice document numbers, hence the need to add the -1, -2 suffix.
I checked the POP10300 and POP30300 tables, and confirmed that the invoice numbers were not duplicates. But clearly GP thought they were, so it was obviously doing some type of additional validation.
So I opened SQL Server Profiler to start up a trace, and then opened the Purchasing Invoice Entry window to see what was going on. When I modified my "duplicate" invoice number to a new value, then changed it back, sure enough, the GP UI gave me an error indicating that the number was a duplicate, even though eConnect had no problem importing the document.
I then looked at my SQL trace and found that in addition to checking POP10300, GP is checking for the invoice number in PM00400. Okay, that makes sense, but these particular invoices had never been entered before, so they shouldn't be in Payables either.
I then did a few inquiries on the invoice numbers, and sure enough, there they were. They were brought in as Payables vouchers back in 2009. Apparently, the vendor is re-using invoice numbers for some reason, and some of the numbers were now conflicting with invoices from 3 years ago. This is the first time I've run into a vendor that re-issues invoice numbers, let alone a 7-digit invoice number in the course of 3 years.
When we looked back at the Purchasing batches that were still remaining, only transactions for one vendor were left. So the problem is isolated to the one vendor, and only affected a few dozen invoices.
So, I learned that eConnect 2010 does not properly validate Purchasing Invoice numbers during import. I now have to add extra validation to detect if the invoice number has been used in either Purchasing or Payables Management, and add a suffix to make it unique.
And we learned that when eConnect imports the Purchasing Invoices with duplicate invoice numbers, there will be no errors or warnings during posting. We have to run the Edit List report to see the problem.
It has been an interesting journey...
Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles. He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.
http://www.precipioservices.com
One situation was that vendors would sometimes split an invoice. So on Monday, they may send data for Invoice 12345 that matches to 10 purchase receipts. But then on Wednesday, they may send data for Invoice 12345 that matches to 5 other purchase receipts. All of the data is technically valid, but because the data for Invoice 12345 is being received at two different times, Dynamics GP thinks that the second set of data for Invoice 12345 is a duplicate (since the client, like most GP customers, has enabled the option to not allow duplicate vendor invoice numbers).
To address this issue, I had to add a routine that would add a suffix to the invoice number when necessary, such as 12345-1, 12345-2, etc., so that we could avoid a duplicate invoice number error. Because the import was for Enter/Match Invoice, we were matching against receipts, so there was little to no risk that a duplicate invoice would get imported.
This worked great, and handled the occasional situations where the same invoice number was transmitted on two different days.
So after quite a bit of testing, the integration went live this week, and we were able to import invoice data for the prior few weeks. The import went very smoothly, bringing in thousands of vendor invoices. The batches were reviewed and then posted, and we sighed in relief at the conclusion of a challenging project.
But when the client opened the Purchasing Batch window, some of the imported batches were still listed, and they contained some transactions. When the client tried to post them again, the batch posting progress window would appear and the status would fly by quickly, but the transactions would still be sitting in the unposted batch.
I ran an Edit List on the batch, and to my surprise, the report said this under every transaction:
**ERROR: Can't post a document that uses a duplicate vendor document number.
This was odd, since during testing, we had obviously discovered that eConnect prevented the import of duplicate Purchasing Invoice document numbers, hence the need to add the -1, -2 suffix.
I checked the POP10300 and POP30300 tables, and confirmed that the invoice numbers were not duplicates. But clearly GP thought they were, so it was obviously doing some type of additional validation.
So I opened SQL Server Profiler to start up a trace, and then opened the Purchasing Invoice Entry window to see what was going on. When I modified my "duplicate" invoice number to a new value, then changed it back, sure enough, the GP UI gave me an error indicating that the number was a duplicate, even though eConnect had no problem importing the document.
I then looked at my SQL trace and found that in addition to checking POP10300, GP is checking for the invoice number in PM00400. Okay, that makes sense, but these particular invoices had never been entered before, so they shouldn't be in Payables either.
I then did a few inquiries on the invoice numbers, and sure enough, there they were. They were brought in as Payables vouchers back in 2009. Apparently, the vendor is re-using invoice numbers for some reason, and some of the numbers were now conflicting with invoices from 3 years ago. This is the first time I've run into a vendor that re-issues invoice numbers, let alone a 7-digit invoice number in the course of 3 years.
When we looked back at the Purchasing batches that were still remaining, only transactions for one vendor were left. So the problem is isolated to the one vendor, and only affected a few dozen invoices.
So, I learned that eConnect 2010 does not properly validate Purchasing Invoice numbers during import. I now have to add extra validation to detect if the invoice number has been used in either Purchasing or Payables Management, and add a suffix to make it unique.
And we learned that when eConnect imports the Purchasing Invoices with duplicate invoice numbers, there will be no errors or warnings during posting. We have to run the Edit List report to see the problem.
It has been an interesting journey...
Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified IT Professional in Los Angeles. He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.
http://www.precipioservices.com
Thursday, March 22, 2012
Forecaster Line Sets With a Period
Back in the days of Forecaster 6.7, I used to really emphasize the need to avoid special characters when naming or entering just about anything. There were such a myriad of issues caused by special characters, that even (.) periods were to be avoided. Admittedly, I have loosened up a bit with Forecaster 7.0 but still try to remind users that special characters aren't a great idea in name/ID fields. And so it was that this week, a special character (in this case, a period), once again was the cause of a lot of confusion in Forecaster.
So here is the scenario...
1. Set up a line set, and end the name with a (.). For example-- HR.
2. Specify the line set as an override on the input set.
3. Enter data in to the budget for the department.
All appears fine if you review the data in the input set (Data>>Input). However, if you open the line set (Build>>Lines), it will appear blank. All in all, this does not seem to cause an issue, unless....
you modify the line set. So, in this case, our line set was blank but we needed to add a new account to it. So we added a new account to the line set and saved it.
When we returned to Data>>Input, our input set (with the exception of the one new account we added) was now completely blank (account numbers and all). And if we were to look at the line set in the database, it was also blank (with the exception of the one new account we added).
We were able to track it back to the fact that the line set ended with a period. It doesn't appear to impact line sets that have a period in the middle of the name only. And, if you happen to catch it BEFORE you make changes to the line set and save it, you can actually recover the line set by right-clicking and renaming it without the ending period. However, if you make a change to the blank line set and save, you will have to recreate the line set.
While at Convergence, I was able to talk with Darian Hanson from support about this and hopefully it will end up as one of those odd little quality reports out there. And, for now at least, it reminds me to be vigilant when it comes to special characters, even periods :)
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
So here is the scenario...
1. Set up a line set, and end the name with a (.). For example-- HR.
2. Specify the line set as an override on the input set.
3. Enter data in to the budget for the department.
All appears fine if you review the data in the input set (Data>>Input). However, if you open the line set (Build>>Lines), it will appear blank. All in all, this does not seem to cause an issue, unless....
you modify the line set. So, in this case, our line set was blank but we needed to add a new account to it. So we added a new account to the line set and saved it.
When we returned to Data>>Input, our input set (with the exception of the one new account we added) was now completely blank (account numbers and all). And if we were to look at the line set in the database, it was also blank (with the exception of the one new account we added).
We were able to track it back to the fact that the line set ended with a period. It doesn't appear to impact line sets that have a period in the middle of the name only. And, if you happen to catch it BEFORE you make changes to the line set and save it, you can actually recover the line set by right-clicking and renaming it without the ending period. However, if you make a change to the blank line set and save, you will have to recreate the line set.
While at Convergence, I was able to talk with Darian Hanson from support about this and hopefully it will end up as one of those odd little quality reports out there. And, for now at least, it reminds me to be vigilant when it comes to special characters, even periods :)
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Back from Convergence 2012
So, next year, back to New Orleans for Convergence 2013. Admittedly, I did like New Orleans a lot, although I have to say that San Diego has been my favorite. Overall it was a good Convergence, although I feel like it went by so quick. Working in the hands on labs was fun as always, meeting with attendees, partners, and old friends. This year we were closer to the product groups, so it was nice to spend some time chatting with all of those folks that dig us out of holes year after year after year.
I am very excited about Management Reporter 2012 for a number of reasons, including...
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
I am very excited about Management Reporter 2012 for a number of reasons, including...
- Improved performance across the board, including a datamart for AX and NAV
- Drillback to Dynamics GP from a report (ala FRx)
- Quick charts and comments allow users to collaborate on published reports
- Multiple destinations for a report definition, including SharePoint and a network share
- Identify missing accounts across all building blocks
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Monday, March 12, 2012
Quick Journal Oddity
We had a client come up with an odd issue with quick journals, and my colleague Nathan Hayden spent some time researching the issue with Microsoft. As it turns out, it is a quality report (with a low possibility of being resolved due to the low number of customers reporting the issue).
But, first, for those of you that are not familiar with quick journals...
A quick journal allows you to set up a self-balancing journal entry template. So you enter all lines of the jounral entry except one, and the journal entry automatically balances to the specified offset account. The templates are set up using Microsoft Dynamics GP-Tools-Setup-Financial-Quick Journal. Entries are then enterered using Transactions-Financial-Quick Journal.
I have found over the years that most users prefer using recurring batches in Financial instead, especially now that you can choose to "Clear Recurring Amounts" when you set up the recurring batch, Transactions-Financial-Batches. But some users do still prefer quick journals, which is how we ran across the issue.
The symptom that the client was reporting was that there were batches being left in the general ledger with no transactions. The batch ID was the same as the quick journal ID, and the batch could not be selected in the Batch Entry window for deletion. What we found is that this was caused by overriding the journal entry number in the Quick Journal Entry window before posting. Very odd.
Here are the details of the quality report:
4444 Empty Quick Journal Batch left behind in Fin. Series Post
Description: 1
1. Go to Setup--financial--quick journals.
2. Setup 2 new quick journals. Test1 and Test2 will work.
3. Go to Transactions--Financial--Quick journal
4. Using TEST1, enter 1 transaction (example: Journal ID 800) and click on the post button to post.
5. Using TEST1, enter another transaction (journal ID 801) and save it.
6. Using TEST2, enter another transaction (Journal ID 802) and save it.
7. Check Financial Series Post. Should see 2 batches (TEST1 and TEST2) with 1 transaction each.
8. Go back to quick journal. Select journal 801 from the lookup. Do not save it again and do not post it.
9. With 801 selected, manually type in 802 and click on the post button to post it.
10. Close the window and go back to Financial Series Post. You should see batch TEST1 with 1 transaction and TEST2 with 0 transactions.
Expected results, the batch should not be there if there are no transactions in it. Seems to only get left behind if the journal ID number is manually overridden and posted from the screen.
If you are experiencing this issue, contact support so you can be added to the quality report :) Fortunately, it does not impact data integrity and you can delete the batch from the SY00500 table (always make a backup first, and then run SELECT * FROM SY00500 to locate the batch's dex_row_ID, and then run DELETE SY00500 WHERE DEX_ROW_ID=insert ID here).
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
But, first, for those of you that are not familiar with quick journals...
A quick journal allows you to set up a self-balancing journal entry template. So you enter all lines of the jounral entry except one, and the journal entry automatically balances to the specified offset account. The templates are set up using Microsoft Dynamics GP-Tools-Setup-Financial-Quick Journal. Entries are then enterered using Transactions-Financial-Quick Journal.
I have found over the years that most users prefer using recurring batches in Financial instead, especially now that you can choose to "Clear Recurring Amounts" when you set up the recurring batch, Transactions-Financial-Batches. But some users do still prefer quick journals, which is how we ran across the issue.
The symptom that the client was reporting was that there were batches being left in the general ledger with no transactions. The batch ID was the same as the quick journal ID, and the batch could not be selected in the Batch Entry window for deletion. What we found is that this was caused by overriding the journal entry number in the Quick Journal Entry window before posting. Very odd.
Here are the details of the quality report:
4444 Empty Quick Journal Batch left behind in Fin. Series Post
Description: 1
1. Go to Setup--financial--quick journals.
2. Setup 2 new quick journals. Test1 and Test2 will work.
3. Go to Transactions--Financial--Quick journal
4. Using TEST1, enter 1 transaction (example: Journal ID 800) and click on the post button to post.
5. Using TEST1, enter another transaction (journal ID 801) and save it.
6. Using TEST2, enter another transaction (Journal ID 802) and save it.
7. Check Financial Series Post. Should see 2 batches (TEST1 and TEST2) with 1 transaction each.
8. Go back to quick journal. Select journal 801 from the lookup. Do not save it again and do not post it.
9. With 801 selected, manually type in 802 and click on the post button to post it.
10. Close the window and go back to Financial Series Post. You should see batch TEST1 with 1 transaction and TEST2 with 0 transactions.
Expected results, the batch should not be there if there are no transactions in it. Seems to only get left behind if the journal ID number is manually overridden and posted from the screen.
If you are experiencing this issue, contact support so you can be added to the quality report :) Fortunately, it does not impact data integrity and you can delete the batch from the SY00500 table (always make a backup first, and then run SELECT * FROM SY00500 to locate the batch's dex_row_ID, and then run DELETE SY00500 WHERE DEX_ROW_ID=insert ID here).
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a supervising consultant with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Monday, March 5, 2012
eConnect 2010 / 2013 Error: There was an error writing to the pipe: The pipe is being closed
By Steve Endow
When you run an eConnect 2010 or 2013 integration, it may display this error when the code calls CreateTransactionEntity:
I recall seeing this a while ago in some testing, but I didn't think much of it at the time. Well, it cropped up again, this time on both my development server and the client's workstation for a GL JE integration.
The quick fix to this is to close the integration and relaunch it, and it will then import fine.
Fortunately, there is a publicly accessible KB article available that describes the issue and the resolution.
http://support.microsoft.com/kb/2539263
I'm not a WCF expert, but it seems odd that this is happening since my code is re-instantiating the eConnect objects each time it is run, so it isn't as if my code is somehow hanging on to an idle instance of eConnect--at least not explicitly. What is also odd is that I've developed dozens of integrations, but haven't had to deal with this error before. I'm pretty sure this isn't the first customer that has left the integration open for more than 10 minutes, so it could be that the error does not occur for some integrations.
Fortunately, the fix described in the KB article is very simple, and should resolve the issue permanently.
Locate the eConnect service config file in the eConnect service directory:
GP 2010: C:\Program Files\Microsoft Dynamics\eConnect 11.0\Service
or
GP 2013: C:\Program Files\Microsoft Dynamics\eConnect 12.0\Service
And then add the receiveTimeout="infinite" parameter to the config file, save the file, and then restart the eConnect service.
<binding name="eConnectNamedPipeConfig" closeTimeout="00:10:00" sendTimeout="00:02:00" receiveTimeout ="infinite" transferMode="Buffered" hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="2147483647" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
That should resolve the "pipe is being closed" issue.
When you run an eConnect 2010 or 2013 integration, it may display this error when the code calls CreateTransactionEntity:
There was an error writing to the pipe: The pipe is being closed.
I recall seeing this a while ago in some testing, but I didn't think much of it at the time. Well, it cropped up again, this time on both my development server and the client's workstation for a GL JE integration.
The quick fix to this is to close the integration and relaunch it, and it will then import fine.
Fortunately, there is a publicly accessible KB article available that describes the issue and the resolution.
http://support.microsoft.com/kb/2539263
I'm not a WCF expert, but it seems odd that this is happening since my code is re-instantiating the eConnect objects each time it is run, so it isn't as if my code is somehow hanging on to an idle instance of eConnect--at least not explicitly. What is also odd is that I've developed dozens of integrations, but haven't had to deal with this error before. I'm pretty sure this isn't the first customer that has left the integration open for more than 10 minutes, so it could be that the error does not occur for some integrations.
Fortunately, the fix described in the KB article is very simple, and should resolve the issue permanently.
Locate the eConnect service config file in the eConnect service directory:
GP 2010: C:\Program Files\Microsoft Dynamics\eConnect 11.0\Service
or
GP 2013: C:\Program Files\Microsoft Dynamics\eConnect 12.0\Service
And then add the receiveTimeout="infinite" parameter to the config file, save the file, and then restart the eConnect service.
That should resolve the "pipe is being closed" issue.
Steve Endow is a Dynamics GP Certified Trainer and Dynamics
GP Certified IT Professional in Los Angeles. He is also the owner of
Precipio Services, which provides Dynamics GP integrations, customizations, and
automation solutions.