Beware the .NET Framework 3.5 sp 1

DEX.DIC version 10.0.320.0 is not compatible with executable version 10.0.324.0

This error came up yesterday while trying to load the 2009 year end update. Going from build 1237 to build 1400 I did not expect any problems (my first error of the day).

This only happened on the new machines, not on the older ones. hmmm.

It turned out that the culprit was .NET Framework 3.5 sp 1. Every machine with 3.5 sp 1 on it threw an error. There was an old machine that I installed 3.51 on just to check, and sure enough, the same error. What to do . . .

I tried a variety of things, but here's what worked for me.

Choice 1 -- Download and install build 324 of Dexterity.

Choice 2 -- Simply copy the files from one of the functioning workstations to the one giving you a problem. You need to go as far as you can with the installation before doing this in order to load the Dex components.

Tomorrow we'll see if the Forms 1099 and W-2 print correctly after all of this effort.

Until next time!

Leslie Vail

Can't Import Excel Budget??

Here's the story. You export a 'blank' budget to Excel to make sure you have the format correct. You make all of your adjustments, save it and then try to import it back into GP.

Have you ever been thanked for all of your budgeting efforts with the message above?

You think -- but I exported the format from GP and then tried to import it back in, I didn't change it!

And I believe you :)

Check your column headings in Excel. If even one of your period descriptions is interpreted as a date by Excel, you will get the above message. Easy to fix, just turn it into a string and you're good to go. Don't forget to go into your Fiscal Periods Setup screen and modify your Period Name(s) so that it doesn't happen again.

Until next time!

Leslie

Wasted, Unused or Voided Checks

This is a little tip for anyone who wants to keep track of all of their check numbers to account for 'voided' checks. By 'voided' I mean checks that were not actually used in a transaction, they were wasted. Like when someone prints a report on your check stock.

The method I use to record 'wasted checks' is very simple, here it is:

Go into Bank Transaction Entry, fill in everything except the amount. No
need to deal with the distribution accounts, leave everything zero. I usually
put 'wasted check', or something to that effect in the description field. It's nice to have something show up on reports. Post the check; boom, you're done.

I've recorded the wasted check and I don't have to do anything else.

I think this works very well and it keeps the auditors happy :)

Dynamics for Manufacturing - Understanding the difference between NAV, GP, SL and AX

The link is to an article by Houston Neal comparing the 4 products in the area of Manufacturing. I'd love to see more like this. If you have any articles comparing the products, Please send me the link.

Thanks!

Leslie

http://www.softwareadvice.com/articles/manufacturing/understanding-the-difference-between-gp-nav-sl-ax-1111709/

Dex.ini Switches Part 3

Now that I have figured out that I can't attach a file to this blog, I thought now would be a good time to add more to the list. Hopefully I haven't included any repeats (or if I did I gave the same explanation).

ADCProcessor=TRUE
You will see this line in the Dex.ini file if you are using Manufacturing and have the checkbox marked in ADC Preferences.

AdvLookups=FALSE
New Users created will NOT be granted access to the Alternate lookup windows in the SmartList dictionary and will instead be assigned the old ‘green bar’ lookup windows.

AllowBCPTest=FALSE
Prevents utilities from running the BCP test.

AllowWrongDex=TRUE
Will allow Dynamics GP to launch with mis-matched versions of dexterity. This switch can get you in trouble, so make sure you know if this is OK. It should NOT be used just to get rid of the error. If you are getting the error, something is amiss.

ApplicationName=name
Changes the name the runtime engine displays when it is launched. Without this setting the name “Dexterity Runtime” is displayed. Kind of fun, but you have to watch carefully because this isn't displayed for very long.

AutoDisplayUpdate=TRUE
Automatically redisplays the process monitor queue.

AutoInstallChunks=TRUE
Causes Dynamics to automatically include the *.cnk file not prompting the user for 'Add New Code to Dynamics.set' during launch.

BTInterface=NoLoad
This applied to the old Btrieve file handler (PSQL 2000) as to whether the interface would load when Dynamics was launched. This one only applies to versions 7.5 or before, assuming PSQL 2000 is being used. It's out of date, but hey, it was on the list.

Buildphantom=TRUE
Allows creation of a Manufacturing Order for a Finished Good Phantom Item.

BuildSQLMessages=TRUE
This one will copy the Dexterity messages to a SQL table on next login and then it will set it back to FALSE. Once in a SQL table the messages can be used in stored procedures. The table is DYNAMICS.dbo.MESSAGES. Give this one a try, it's pretty neat. It's also a very good way to easily 'browse' all of the message resources. If you have Modifier, these are fun to change. I especially like changing the droll descriptions Check Links adds to recovered records. Be sure to keep track of what you changed so you can change it back if you did something for a laugh.

DebugFonts=TRUE
This setting causes Dexterity to generate a trace file named "debuglog.txt". This file lists the fonts that were considered and why particular fonts were chosen or rejected.

DebugRW=XXX
Where XXX equals the sum of the values you want to trace from below.

1 = QueryOK Specifies if the report will use a single query or not
2 = Sanscript Logs the run report statement as the Report Writer sees it
4 = RW Query Logs all API calls from RW to the Data Manager
8 = RW Setup If used with RW Run, logs all data returned by Data Manager
16 = RW Steps Logs internal RW steps in processing the report
32 = RW Run Logs all RW runtime calls to the Data Manager
64 = DM SQL Logs internal Data Manager structures and SQL Generation
256 = RW Frames Logs the beginning of each report frame
512 = Tab Delimited Logs output as tab delimited output

Output will appear in a log filed named DebugRW.txt next to the application dictionary.

Example: If you want to log if a report is using a query and the SanScript and SQL code used, then add the following line to your Dex.ini file:
DebugRW=67 ; 1 + 2 + 64

To help in trouble shooting problems related to the generation of reports, before printing a report you may choose to mark the Where XXX equals the sum of the values you want to trace from below.
Value = Name Description
1 = QueryOK Specifies if the report will use a single query or not
2 = Sanscript Logs the run report statement as the Report Writer sees it
4 = RW Query Logs all API calls from RW to the Data Manager
8 = RW Setup If used with RW Run, logs all data returned by Data Manager
16 = RW Steps Logs internal RW steps in processing the report
32 = RW Run Logs all RW runtime calls to the Data Manager
64 = DM SQL Logs internal Data Manager structures and SQL Generation
256 = RW Frames Logs the beginning of each report frame
512 = Tab Delimited Logs output as tab delimited output

Output will appear in a log filed named DebugRW.txt next to the application dictionary.

Example: If you want to log if a report is using a query and the SanScript and SQL code used, then add the following line to your Dex.ini file:
DebugRW=67 ; 1 + 2 + 64

To help in trouble shooting problems related to the generation of reports, before printing a report you may choose to mark the Suppress SQL Query option on the Report Definition window. This will force the system to perform individual table operations instead of creating a query. If you have the SQLLogSQLStmt = TRUE setting included in your DEX.INI. The individual select statements are then included in your DEXSQL.LOG file and can be analyzed to uncover any potential problems.

DebugUnknownFile=TRUE
Returns a Btrieve or Ctree error code to help track problems with table errors back in the day of Btrieve and Ctree. (version 7.5 and previous)

DevAssistHide=TRUE
This is a 'Dexterity' ini switch used to keep the Developer Assistant window from automatically opening after you login to a company when you are running in test mode.

DexHelpPath=pathname
Path to Dexterity help files.

Dictionary Version=
This isn't a switch you can set, it is set for you by the application. It displays the current version of the Dynamics.dic file.

DisplayTableErrors=TRUE, ALL or OPEN
This is used to display an ID for an unknown table error when the Dexterity Database Management Subsystem encounters one. The ID that's displayed can be used to determine the cause of the error.
TRUE – Displays only unknown errors.
ALL – Displays all table errors except the two most common: “duplicate” and “not found”.
OPEN - Displays all table errors for an open operation.

DPSInstance=number
Where number indicates the instance number. This tells the engine which instance of the Dynamics Process Server to use.

DynHelpPath=pathname
Path to Dynamics help files.

EmailStmtStatusPath=pathname
The path for the delivery of e-mail statements.

EXTPRICINGQTYFREEISADDER = TRUE
The EXTPRICINGQTYFREEISADDER option is included in the extended pricing component to let you type a negative value in the Maximum Quantity Free box. The extended pricing component uses a negative value in this box to let the Maximum Quantity Free field behave in an additive manner instead of as a multiplier. Refer to KB article 910125.

FAGroupPath=Pathname\filename
FAPhysicalInventoryPath= Pathname\filename
FAPhysInvInfoPath= Pathname\filename
FAAssetImportPath= Pathname\filename
FAAssetIDExportPath= Pathname\filename
FAAssetLabelExportPath= Pathname\filename
FAMacroPath= Pathname\filename
FASampleDataPath= Pathname\filename
This is the group of settings that determine the import/export file names for user preferences in Fixed assets. Setup>>Fixed Assets>>User Preferences

FHCheckRanges=TRUE
This setting specifies whether to log the instances when Dexterity decides which type of range to use for tables that use the SQL database type. The log will list all instances when Dexterity detected a range that was not “well-behaved” and whether Dexterity used an exclusive or inclusive range. The FHRANGE.LOG text file to be generated in the same location as Dexterity or the runtime engine. This setting is pretty much outdated too, because now SQL is the only allowed database type.

FileHandler=database type
This used to be the Database Type that was used to determine, in part, what kind of tables to create when Ctree and Btrieve (PSQL 2000) were supported. Now the FileHandler type will always be SQL.


That's all for now. Until next time . . .

Moving from Work to Open to History

This article started from a question posted on the newsgroup. There doesn't seem to be any summary of how transactions move from Work to Open to History.

I put together this document attempting to address this for the following series:

• GL
• CM (Bank Transactions)
• AR
• AP
• SOP
• POP
• Invoicing
• Inventory

I haven't worked on Payroll yet.

GL

Work - Unposted GL Transactions
Open - Posted GL Transactions
History - When GL Fiscal Year Closes


Until the year closes all of the GL transactions are in the Year to Date Transaction Open table. You cannot move them back to the Open table after the year end closes. Entries cannot be ‘unposted’ and moved back into the Work table.

CM (Bank Transactions)

Work – Unposted Deposit Transactions
Open – Posted Bank Transactions
Posted Deposit Transactions
Reconciliations
History – There is no history table

AP

Work – Unposted AP Transactions
Open – Posted AP Transactions that are not yet fully applied.
Posted Purchasing Invoices that are not yet fully applied.
History – Transactions automatically move to history when the document is fully applied (a transaction is a check, credit memo, invoice, etc.) For a check or credit memo it is when the amount is fully applied to an invoice or invoices. For an invoice it is when it is fully paid off, or a credit memo, or memos takes the balance to zero. Voiding a document in the Open file moves it to history. Documents can be voided after they have been moved to history and that moves them back to the Open table. Documents cannot be 'unposted'.

AR

Work - Unposted
Open - Posted AR Transactions
Posted SOP Invoices
Posted SOP Cash Receipts
History - You need to run the 'Paid Transaction Removal' routine in order to move transactions to History. Nothing automatically moves to history. This routine will only move 'fully applied' documents to history. So if you still have a balance on an invoice it stays in the Open Table. If a credit memo or receipt has not been applied to an invoice, it will stay in the Open table. The fact that the customer's net balance is zero does not impact whether the document moves to history.


When you run the Paid Trx Removal you specify a cutoff date that applies to
NSF checks
Voided documents
Waived (finance charges)
Paid Transactions

You specify a separate date for:
Checks

Once AR transactions are moved to history - they cannot be voided thereby moving them back to open. This is why the checks have a separate date - what if they bounce!



Documents can be 'unapplied' only while they are in the Open file, not after they have been moved to history. For instance, if you applied a cash receipt to the wrong invoice, you can change it to the correct invoice only if it has not been moved to history.



Documents can be voided only while they are in the Open file.

SOP

Work - Unposted documents
Open - There is no Open file (when SOP docs are posted the transactions go into the AR Open file)
History -These transactions automatically move to history:
Posted SOP Invoices or SOP Returns
Voided SOP Documents
Orders whose items have been fully transferred to other documents
Quotes that have had any item transferred to another document
Backorders that have been fully transferred to other documents
For documents that do not automatically transfer to history, run the Reconcile-Remove Sales Documents utility.

The following documents cannot be posted
Quotes
Orders
Backorders

POP

Work - Any document that has not been moved to history
Open - There is no open file
History –
Posted Receipts automatically move to history
Posted Purchasing Invoices automatically move to history
Voided Purchasing Documents automatically move to history
Purchase Orders - You must run the Purchasing Routine 'Remove Completed Purchase Orders'. This will move all of the closed or canceled POs to History. If a PO is not closed or canceled it will not be moved, so there is no danger of moving a PO that doesn't qualify. You can set restrictions on which POP docs are examined for removal.

IVC (Invoicing)

Work – Unposted Documents
Open - There is no open file (posted transactions update receivables, like SOP)
History –
Posted Invoices automatically move to history
Posted Returns automatically move to history


IV (Inventory)

Work – Unposted Adjustments
Unposted Variances
Unposted Stock Counts
Unposted Transfers
Open - There is no open file
History – Posted Transactions

Database Maintenance Utility

After you load GP 10 you will notice a little extra item has loaded. That extra item is called the Database Mantenance Utility. I've been asked many times of late as to what it does and why we should care. Here goes. When the databases are created by GP several other objects are created as well. Views, Triggers, Stored Procedures and functions. Sometimes these objects become corrupted or messed up in some other way and need to be reloaded. The Database Maintenance Utility is the tool for the job. Before running this utility please be sure to back up your database. Also script out any customizations you have made to any of these objects, because they will need to be reapplied.

As an aside, you want to script any changes made to table keys and indexes because you will most likely need to re-run those modifications after any table update.

That's all for now, I'm heading to the Tech Conference Friday.

Hope to see you there!

Using the Adjust Costs inventory Utility Warning!

Adjust Costs.

It looks like a simple enough tool and it does exactly what you tell it to do. However, read on, what it does may not be exactly what you want it to do. Here's what it does. Say you have a purchase receipt that went through the system at $1465. Several of the items were sold but now the inventory is obsolete and the powers that be task you to write it off. They still want the items in inventory in case they can sell them later, but the carrying value should be zero. No Prob! you say. You open up the adjust cost screen and take each of the receipts that have not been completely sod and adjust the cost to zero. A bunch of reports print, you check that your stock status shows zero and you think you are done.

Not so fast. When you make a cost adjustment to a receipt in the Adjust Cost window you are telling the system that the entire receipt had a bad cost, not just the items left over. Dynamics GP will go back and attempt to adjust the cost on the posted sales from this receipt to the new cost (in our case $0). You may not want that. If all you are trying to do is write the current inventory down to zero cost, make Inventory Transaction Entries. First, a negative entry which will pull the correct cost. This will give you your 'write off' journal entry. Next do an increase adjustment at $0.00 cost. Now you have written off exactly the inventory you want and the carrying value is zero.

You can go home fulfilled from a good writeoff :)

UPDATE! I read a post on the GP Forum the other day that was posted by fellow MVP Mahmoud M. AlSaadi  where he provided an excellent explanation of how the Adjust Cost Utility worked. I've modified the post only slightly, but this is what it told us.
The Inventory Adjust Cost Utility primarily does the following;
· Update the (UNITCOST) field  in IV10200 | Inventory Purchase Receipts Work. (The old Unit Cost will be reserved under ADJUNITCOST field ) 
· Since the purchase receipt within the IV10200 is linked to the Inventory Purchase Receipts Detail, these cost layers will be updated accordingly.
· A new Cost Adjustment Record is written to the HITB | Historical Inventory Trial Balance either to decrease or increase the cost.
· A Corresponding Journal Entry to adjust the Purchase Receipt Cost in General Ledger is created. That Journal Entry is linked to the cost adjustment record in the HITB
· No changes at all to the IV30300 | Transaction Amounts History
In summary, if you have received and invoiced the items, but the cost is not correct and needs to be adjusted, the best way is to correct this is to use the "Adjust Cost Utility". If the cost had been corrected through the Enter/Match invoice transaction, then the cost adjustment record and all of the corrections mentioned above would have been applied. However, if the invoice cost was not corrected at the time of invoicing, the Adjust Cost Utility is your answer for fixing it.

Until Next Post

Leslie

Dexterity Training in Orlando Oct 5 - 9, 2009

Come to Florida for Dexterity Training!

This class is only held once per year, so please don't miss it if you are interested in learning Dexterity.

If you want to sign up please call Roxanna at 407-677-0370 or ralvarez@ibgnet.com.

This is a hands-on programming class using Microsoft Dexterity. This class will take you from creating the initial development environment to delivering a fully integrated .cnk file.

This week-long Class will include several programming projects such as:

• Creating a data-entry window project
• Using the debugging tools
• Creating a lookup window project
• Understanding multi-user record locking
• Creating a transaction entry project
• Using Dexterity Utilities
• Creating an integrating application project using object triggers
• Creating integrating reports with Report Writer

For more information look here:
http://www.ibgnet.com/images/pdfs/Dexterity_I_Synopsis.pdf

To sign up for the class look here:
http://www.ibgnet.com/IBG-Training-GP.html

Copy Fields for Jocelyn

Here's what the Calculated Fields section looks like for the Direct Deposit Earnings Statement:
This to answer Jocelyn's question on Copying calculated fields.

CalculatedFields
{
CalculatedField "SickAvail"
{
EvaluateAfter ""
Expression " ( 'UPR_WORK_Check'.'Sick Time Available' - 'UPR_WORK_Check'.'Sick Time Hours' ) * 0.01000 "
ResultType "Currency"
}
CalculatedField "VacAvail"
{
EvaluateAfter "SickAvail"
Expression " ( 'UPR_WORK_Check'.'Vacation Available' - 'UPR_WORK_Check'.'Vacation Hours' ) * 0.01000 "
ResultType "Currency"
}
CalculatedField "Sick Time Total"
{
EvaluateAfter ""
Expression " ( 'UPR_WORK_Check'.'Sick Time Available' - 'UPR_WORK_Check'.'Sick Time Hours' ) * 0.01000 "
ResultType "Currency"
}
CalculatedField "Vacation Time Total"
{
EvaluateAfter "Sick Time Total"
Expression " ( 'UPR_WORK_Check'.'Vacation Available' - 'UPR_WORK_Check'.'Vacation Hours' ) * 0.01000 "
ResultType "Currency"
}

Copy Calculated Fields in Report Writer

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" }

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!

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

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

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

Dex.ini Switches - Part 2

I'm finally getting back to posting. Here's the second installment of the .ini switches. My favorites were posted with part 1, but I'm always on the lookout for more. I've got some for VBA and IM as well.

ADC Processor=TRUE
You will see this line in the Dex.ini file if you are using Manufacturing and have the checkbox marked in ADC Preferences. (dah!)

AdvLookups=FALSE
New Users created will NOT be granted access to the Alternate lookup windows in the SmartList dictionary and will instead be assigned the old ‘green bar’ lookup windows. Very useful if you want to use Dex and try to do a lookup.

AllowBCPTest=FALSE
Prevents utilities from running the BCP test.

AllowWrongDex=TRUE
Will allow Dynamics GP to launch with mis-matched versions of dexterity. DANGER, this is not such a good idea.

ApplicationName=name
Changes the name the runtime engine displays when it is launched. Without this setting the name “Dexterity Runtime” is displayed. With versions 9 and higher this doesn't display very long so it's hard to spot. Hardly worth the effort anymore. It used to be quite fun.

AutoDisplayUpdate=TRUE
Automatically redisplays the process monitor queue.

AutoInstallChunks=TRUE
Causes Dynamics to automatically include the *.cnk file not prompting the user for 'Add New Code' during launch.

BTInterface=NoLoad
This applied to the old Btrieve file handler (PSQL 2000) as to whether the interface would load when Dynamics was launched. Version 7.5 was the last version where PSQL could be used.

Buildphantom=TRUE
Allows creation of a Manufacturing Order for a Finished Good Phantom Item. Sounds spooky.

BuildSQLMessages=TRUE
This one will copy the Dexterity messages to a SQL table on next login and then it will set it back to FALSE. Once in a SQL table the messages can be used in stored procedures. The table is DYNAMICS.dbo.MESSAGES.

DebugFonts=TRUE
This setting causes Dexterity to generate a trace file named "debuglog.txt". This file lists the fonts that were considered and why particular fonts were chosen or rejected. This applies to Report Writer reports.

DebugRW=XXX
Where XXX equals the sum of the values you want to trace from below.

Value = Description
1 = QueryOK Specifies if the report will use a single query or not
2 = Sanscript Logs the run report statement as the Report Writer sees it
4 = RW Query Logs all API calls from RW to the Data Manager
8 = RW Setup If used with RW Run, logs all data returned by Data Manager
16 = RW Steps Logs internal RW steps in processing the report
32 = RW Run Logs all RW runtime calls to the Data Manager
64 = DM SQL Logs internal Data Manager structures and SQL Generation
256 = RW Frames Logs the beginning of each report frame
512 = Tab Delimited Logs output as tab delimited output

Output will appear in a log filed named DebugRW.txt next to the application dictionary.

Example: If you want to log if a report is using a query and the SanScript and SQL code used, then add the following line to your Dex.ini file:
DebugRW=67 (which is 1 + 2 + 64)

To help in trouble shooting problems related to the generation of reports, before printing a report you may choose to mark the Multi-Login Report option on the Report Definition window. This will force the system to perform individual table operations instead of creating a query. If you have the SQLLogSQLStmt = TRUE setting included in your DEX.INI. The individual select statements are then included in your DEXSQL.LOG file and can be analyzed to uncover any potential problems.

DebugUnknownFile=TRUE
Returns a Btrieve or Ctree error code to help track problems with table errors back in the day of Btrieve and Ctree. (version 7.5 and previous)

DexHelpPath=pathname
Path to the Dexterity help files. Consider using this if you want to 'share' help files. This defaults to the application folder on the local client.

Dictionary Version=xx.xx.xxxx
The current version of the Dynamics.dic file. Changing this value will not change the dictionary, but this value is updated when a service pack is installed.

DisplayTableErrors=TRUE, ALL or OPEN
To display an ID for an unknown table error when the Dexterity Database Management Subsystem encounters one. The ID that's displayed can be used to determine the cause of the error.
TRUE – Displays only unknown errors.
ALL – Displays all table errors except the two most common: “duplicate” and “not found”.
OPEN - Displays all table errors for an open operation.

That's all for now. Please let me know if there are any errors in any of the switches so I can be sure to correct the post.

Thanks for "listening"!

Leslie