Yes you can! The secret is in the editing of the .package file.
Let's imagine you want to use the rw_SelectAddrLine user-defined function to create the address block in the SOP Blank Invoice Form. KB (862653) entitled "Description of the rw_SelectAddrLine Report Writer function" will show you that 9 calculated fields could be required if you want to use all of the available fields in the address block. If you like going through that drill, the process definitely works.
I prefer the copy and paste method. What you need to do is create a couple of the calculated fields as directed in the article and then export the modified report to a .package file. Open the package file using the text editor of your choice and then copy and past until you have what you need. For the SOP Blank Invoice Form here is the text you can past into the calculated field portion of your report.
The calculated fields below skip the 'Name' field (the first variable)
CalculatedField "Ship To Address Line 1" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 1 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" } CalculatedField "Ship To Address Line 2" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 2 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" } CalculatedField "Ship To Address Line 3" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 3 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" } CalculatedField "Ship To Address Line 4" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 4 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" } CalculatedField "Ship To Address Line 5" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 5 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" } CalculatedField "Ship To Address Line 6" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 6 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" } CalculatedField "Ship To Address Line 7" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 7 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" } CalculatedField "Ship To Address Line 8" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 8 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" } CalculatedField "Ship To Address Line 9" { EvaluateAfter "" Expression "'rw_SelectAddrLine'( 9 \"\" 'SOP_HDR_WORK'.'Contact Person''SOP_HDR_WORK'.'Address 1''SOP_HDR_WORK'.'Address 2''SOP_HDR_WORK'.'Address 3''SOP_HDR_WORK'.'City''SOP_HDR_WORK'.'State''SOP_HDR_WORK'.'Zip Code''SOP_HDR_WORK'.'Country' ) " ResultType "String" }
Wednesday, July 1, 2009
Thursday, May 7, 2009
The Anti-Spec
http://www.willoware.com/docs/Flyer_TheAntiSpec.pdf
This is hilarious - every programmer should take a look at this. Kudos to Benny at Willoware!
This is hilarious - every programmer should take a look at this. Kudos to Benny at Willoware!
Monday, February 9, 2009
Convergence 2009
Who's coming to Convergence? I'll be there and I hope you all will stop by the Hands-on Labs and say 'hello'.
My friend and fellow MVP Mark Polino will be presenting a fact-filled and fun session - 50 tips in 50 minutes. He's a blast, and his session should not be missed!
I still use the image on his last slide from 'SQL Saturday' as my splash screen. "Microsoft - change the world or go home"
If you copy any .bmp file into the GP folder and name it 'splash.bmp' it will display while Dynamics GP is loading.
Look out New Orleans! GP is coming to town!
Leslie
My friend and fellow MVP Mark Polino will be presenting a fact-filled and fun session - 50 tips in 50 minutes. He's a blast, and his session should not be missed!
I still use the image on his last slide from 'SQL Saturday' as my splash screen. "Microsoft - change the world or go home"
If you copy any .bmp file into the GP folder and name it 'splash.bmp' it will display while Dynamics GP is loading.
Look out New Orleans! GP is coming to town!
Leslie
Problem ascertaining product version
Have you ever launched Dynamics GP Utilities and received the error below?
Error message when you access Microsoft Dynamics GP 10.0 Utilities: "There was a problem ascertaining product version information. Microsoft Dynamics GP Utilities will now exit. Check DUinstall.log for more information"
KB article 952054 discusses the error, but doesn't tell you how to fix it. I've had this come up a couple of times. In both cases the client was attempting their own update. Usually they were changing servers or upgrading to SQL 2005 at the same time.
The fix is in. When you are moving your installation of GP, restore the databases FIRST and then install the software. If you do it the other way around you will get this error message and then it's difficult to diagnose.
Remember - databases first, then application.
I hope this helps someone out there in GP-Land.
Kind regards,
Leslie
Error message when you access Microsoft Dynamics GP 10.0 Utilities: "There was a problem ascertaining product version information. Microsoft Dynamics GP Utilities will now exit. Check DUinstall.log for more information"
KB article 952054 discusses the error, but doesn't tell you how to fix it. I've had this come up a couple of times. In both cases the client was attempting their own update. Usually they were changing servers or upgrading to SQL 2005 at the same time.
The fix is in. When you are moving your installation of GP, restore the databases FIRST and then install the software. If you do it the other way around you will get this error message and then it's difficult to diagnose.
Remember - databases first, then application.
I hope this helps someone out there in GP-Land.
Kind regards,
Leslie
Sunday, January 4, 2009
Year end closing Retained Earnings validation
What's this? Two posts in a single day after weeks of silence? Hopefully this will be helpful for someone out there.
This is for those of you who do 'divisional' closings to Retained Earnings. That's where each 'division' has separate balance sheet and income statement accounts. This is a popular technique when clients want to keep several companies in the same database, yet close out each company to its own retained earnings account.
First of all, you can only (out-of-the-box) differentiate according to a single segment of the chart of accounts. So you can't close by the combination of segment 1 AND segment 2. Also, you need to have created an account for each segment whether or not you need it.
Before executing the close, GP searches through the chart of accounts to make sure you do indeed have a separate retained earnings account for each separate 'division'. The surprise to me was how the software determines whether you're good to go. Instead of looking at the account indexes or separate segment definitions, it looks at the Account Number String field in the Account Index table.
I discovered this last year when one of my clients tried to close and couldn't. Earlier in the year we had removed an unused segment from the chart of accounts (more on that later). The Account Number String field still had a trailing dash "-" left over from the deleted segment. So account number 100-4560-090 read in the field as 100-4560-090- . Once we removed the trailing dash from the field, everything closed beautifully. Go figure.
Another related item. The Account Number String field is used by Integration Manager too. When importing account numbers, you have to use the account separator or the integration will fail. Remember when you could just import the string of characters with no account separator? Not anymore. This was changed a couple of versions ago, so everybody who had strings of characters as the source has probably changed the integration by now.
Gee, and here I thought they created that field so we would no longer have to concatenate segments in reporting.
Enjoy those forms 1099 and W-2!
Leslie
This is for those of you who do 'divisional' closings to Retained Earnings. That's where each 'division' has separate balance sheet and income statement accounts. This is a popular technique when clients want to keep several companies in the same database, yet close out each company to its own retained earnings account.
First of all, you can only (out-of-the-box) differentiate according to a single segment of the chart of accounts. So you can't close by the combination of segment 1 AND segment 2. Also, you need to have created an account for each segment whether or not you need it.
Before executing the close, GP searches through the chart of accounts to make sure you do indeed have a separate retained earnings account for each separate 'division'. The surprise to me was how the software determines whether you're good to go. Instead of looking at the account indexes or separate segment definitions, it looks at the Account Number String field in the Account Index table.
I discovered this last year when one of my clients tried to close and couldn't. Earlier in the year we had removed an unused segment from the chart of accounts (more on that later). The Account Number String field still had a trailing dash "-" left over from the deleted segment. So account number 100-4560-090 read in the field as 100-4560-090- . Once we removed the trailing dash from the field, everything closed beautifully. Go figure.
Another related item. The Account Number String field is used by Integration Manager too. When importing account numbers, you have to use the account separator or the integration will fail. Remember when you could just import the string of characters with no account separator? Not anymore. This was changed a couple of versions ago, so everybody who had strings of characters as the source has probably changed the integration by now.
Gee, and here I thought they created that field so we would no longer have to concatenate segments in reporting.
Enjoy those forms 1099 and W-2!
Leslie
Subscribe to:
Posts (Atom)