If you create multicurrency payables (PM) transactions using eConnect, and you are passing in the distributions manually (by setting CREATEDIST to 0), you may have encountered the same issue I encountered today. When the transaction was created, eConnect also (correctly) added in a ROUND distribution, to account for 0.01 cents worth of FX related rounding on the transaction. Unfortunately, eConnect did not populate the distribution with an account.
If you run Dynamics GP and have more than a handful of companies, I am sure you have felt the pain of installing or upgrading a 3rd party product, and then having to log in to each company as “sa” to complete the install process. I had to do this recently for a new 3rd party we are using ( SmartView from eOne Solutions ). Once the install is complete, a log in to each database as “sa” is required to create the necessary tables to support the tool.
We are looking to deploy SmartList Builder + SmartView as an enhanced reporting solution for our internal customers. One of the things I have seen floating around the net is that you can’t use SmartList Builder with a SQL Linked Server. In fact, a number of Dynamics MVP’s alluded to this in a support thread at http://www.ms-news.net/f1610/smartlist-builder-odbc-error-8692687.html .
A user complained about a batch not being able to be posted. The error message is something like this: This batch is currently receiving transactions . Normally when a user complains about something like this, a GP Administrator or Consultant’s immediate step is to check what the *Batch Status* field holds in SY00500 (Batch Header) table.
You can easily check list of companies accessible to a GP user using Company Access Window. Or you can use a small query on table sy60100 Something like SELECT * FROM sy01500 WHERE cmpanyid IN (SELECT cmpanyid FROM sy60100 WHERE userid = ‘LESSONUSER1′) However, recently I needed a list of companies a SQL user (not
Today, I thought I would spend a little time explain how to read a Dexterity Script Profile to resolve a performance issue. To demonstrate this I will use a support case I had where the customer was intermittent long delays when clicking on the checkbox on the Apply Sales Document window. The customer in this case had made a decision not to run Paid Transaction Removal every month as they wished to continue displaying closed transactions on their statements for a longer period.