In Microsoft Dynamics GP 2013 Service Pack 2 – there is a ‘bug’ in the Manufacturing module Labor code maintenance window. The Radio Buttons for selecting if overheads are amounts or percentages are missing on the standard window. This is caused by the Tab Sequence on this window not being set correctly.


To correct this issue temporarily while Microsoft issues a patch – open the window in Modifier, [tools >> Customise >> Modify current window] and select Layout >> Set Tab Sequence. Now the fun begins.

Hit the tab key to start tabbing through the fields. Tab until the Fixed Overhead field gets highlighted. Now is the time to interrupt the tab sequence and set it straight. Double click the Fixed Overhead field [highlighted in Red above] until the Radio Group is selected [Tip: Double click the top right hand corner of the red box above]. Then hit tab. Double click the first Radio option, tab, and double click the second radio button. Then tab through to the Variable Overhead field and repeat. You will need to do this for the 4 Radio Groups on this window.

Once complete, click Layout >> Set Tab Sequence again. save and close the modified window and return to Dynamics GP.  Then go to GP 2013 Security – and grant the user access to this new modified window. It might take a few attempts to get it right. If you get tied up in knots, delete the modified window from Modifier and reinsert the original to start from scratch.

Also take a look at David’s post on setting tab sequences.

Posted by: istewart | February 7, 2014

Smartlist Designer – query truncates

Smartlist Designer for Dynamics GP, a nice addition, has a wee bit of a problem!

There seems to be a limit on the length of the query that can be built when you link one or more tables. So, if you select two tables, link them, mark all fields to be included in the output and then look at the SQL Query at the bottom of the window…the SQL query truncates at a certain number of characters.

By removing sufficient fields from the selection, you will eventually get a complete query. I haven’t bothered to count the max number of characters allowed because I just couldn’t be bothered, and I don’t know if this is a bug or ‘by design’!! But if your new smartlist won’t run correctly – maybe its truncated.

Posted by: istewart | January 15, 2014

How long did it take us to figure this one out?

The Scenario: GP 2013. 2 Terminal Servers that all users use to access GP. They use the Transactions >> Purchasing >> Print Purchasing Documents window to print their Purchase Orders en masse.

The Problem: User opens this window, selects a range of PO’s…and clicks print. The print dialogue window opens as per normal and they select Screen / Printer / File…it doesn’t matter which. They click OK to print and….nothing happens!!

The Weird Bit: One domain User on one Terminal server…can print!! No one else can. It doesn’t matter what GP user ID they use to log into GP…It seems to be connected to the Domain User account. Go figure. Also – all users can print the alignment form from his window, or can go to the PO Entry window and print an individual PO there…but when it comes to printing a range of PO’s, nothing happens.

The Solution! [discovered by Babu] On the ‘good’ Terminal Server that users Date and Time format was set to US – this is the one that worked. On the other Terminal Server it was set to UK. All other domain users…were set to UK on both Terminal Servers. Changing any one of these to US settings – and they could print the PO’s.

The Competition: Guess how long it took us to figure this one out!

Update…..David Musgrave has a post which describes a similar issue and the reasons why!!

Posted by: istewart | October 3, 2013

The Mariano Gomez Dexterity Roadshow is back!

Mariano is running Dynamics GP Dexterity training courses again. Following on from the excellent uptake of courses he ran earlier this year and the renewed interest in Dexterity caused by the Web Client, he is going for a second round. Dexterity seemed to drop off a lot of people’s radars in the last few years but its a hot topic again and Mariano’s courses will now service both beginners and improvers. If you attended the Dexterity Fundamentals course last time, then the Advanced Dexterity Development course might be for you. If you’re comfortable with Dexterity – check out the Visual studio tools for Dexterity Developers course.

Information and scheduling for each of the courses is available here.

The Smartlist Builder module for Dynamics GP will no longer be available through Microsoft come 1 January 2014. On that date eOne Solutions will terminate their OEM agreement with Microsoft [which started in 2006] and take this product in house. Not necessarily a bad thing, this should allow eOne to build more functionality into the product as they will be released from any restrictions – there is even talk of reworking the product to work with other business applications and mobile device delivery. While it may make life a little more complicated from a licencing perspective, the planned new functionality should more than compensate.

Posted by: istewart | September 22, 2013

SEPA – the dust settles a bit.

SEPA [Single European Payment Area] – what is it?
SEPA is a European Regulation that is intended to simplify processing payment and receipt transactions across all 32 EU member states. It affects both banks and their clients. Banks need to be able to accept debit and credit transactions in SEPA formatted files, and their clients need to be able to produce SEPA files. Its coming up hot and heavy with the compliance date for SEPA I [there's always a phase II to these things!!] set for February 1 2014. SEPA I is concerned with transacting in Euro across the EU. SEPA II is concerned with transacting in any currency across the EU.

Grand. But how will it affect us?
All that follows is a brain dump of things we have encountered helping Dynamics GP users in Europe become SEPA compliant. The real big issue is for clients who collect customer payments. Under SEPA the responsibility for maintaining Direct Debit Mandates switches from the Bank to the client. So if today you collect payments by DD – you will need to implement a Mandate process. All banks require to see the confirmation letter you send to new customers. Easiest is to ask them for a copy of their recommended letter and modify it for your needs. Each mandate is required to have a Unique Mandate Reference in order to allow direct debits to be refunded / queried.

So, that said – how does SEPA affect your business? First, contact your bank and see are they SEPA compliant…or when they plan to be. Until they are ready you won’t be able to send a test file [generally...however some may accept files depending on how far down the road they are with their side]. Most of the main Irish banks are SEPA compliant at this stage or will be very soon. We’ve seen some differences in how they interpret the various nodes in the SEPA XML schemas- its supposed to be standardised, right? – well it is up to a point apparently. So don’t take it for granted that a file that works with one bank will work with all.

Some banks are offering a service to clients where existing EFT formatted Credit files will be converted to SEPA by the bank…so clients in theory don’t need to worry about re-configuring their outputs. But there are end dates on these services…and they are not offered for Debit transactions. Additionally, previously there was some elbow room when it came to submitting flat files – not now – the banks have tightened up on the flat file specs if you want to use their conversion process. In all cases so far we have had to edit the existing exports for GP users who have chosen to use this interim bank service.

Some things to watch out for:
There are disallowed characters in SEPA that were allowed in flat files. Get a list of these and make sure you either remove them from such things as Vendor Name, or you engage a utility to remove / convert them prior to producing your SEPA file. Also, in the past DD files survived muster with really any Payment Type ID. Under SEPA these rules are rigidly enforced – so make sure your output uses the correct code.

What are your options in Dynamics GP?
Realistically, you have two: 1. Create an XML EFT output using the XML File types in standard Dynamics GP EFT Module…get your partner to become authorised by the bank…and submit you and your partner to endless testing. 2. Engage the services of an expert in the field that specialises in maintaining all of the file standard outputs including SEPA. Make sure they are authorised by your bank as a supplier. Continue with your current GP process and just modify the output to be an upload to this specialist partners software.

Having reviewed all of the possibilities, our advice is option 2 and we are encouraging all our Dynamics GP clients towards this. Its far more economical [annual usage fees are as low as Euro 250.00] and you’re always up to date…and when SEPA II kicks in, it will be just a matter of applying an update. Anyone who is facing SEPA issues in Europe feel free to reach out to me.


Posted by: istewart | September 18, 2013

Update to Clear Activity in Bank Management

Had a support query today from one of our clients in the UK. They were getting the error message where Bank Management figured a user was still accessing a batch of transactions. This was after a hard close [aka 'crash'!!]. Ran the clear Activity utility in Bank Management to no avail, and then queried the CBEU1020 table – but no records. Searching around I found the User ID and Batch ID in table CB10006. The CBEU1020 table tracks activity for Euro denominated transactions, so this is why the activity record was not in there…the batch was for a GBP denominated bank account.
Delete CB10006 where Dex_Row_ID = ‘the relevant record’…did the trick.

Related post here:

Posted by: istewart | September 9, 2013

Purchase Order Prepayments – Dynamics GP 2013

Another cool feature and one no doubt driven by customer requests. In GP 2013 you can enter prepayments against Purchase Orders. These can be manual payments – or can be picked up by automatic check/EFT runs. If using the Auto Checks/EFT process, the PO appears like any other Supplier invoice and the resultant payment references the PO Number as the Document number on the remittance. When it comes to entering the Invoice[s], until the PO is closed, the prepayment cannot be assigned to unrelated invoices which makes sense.

To set up POP Prepayments go to the Purchasing Setup Window. Down the bottom, there are new fields added where you can enable this feature, add a password if required and dictate the Prepayments GL account to be used.

When in use, on the Purchase Order window – you will see a Prepayments field at the bottom where you can record the prepayment. A red hash to the left of this field tells you the payment hasn’t been made yet – it will disappear when the payment is recorded. Additionally, the GL is updated once the payment is complete – not before, which again makes perfect sense.

One issue at the moment is that the maximum prepayment you can enter seems to be the total of the line amounts. I.e. footer amounts like Purchase Tax cannot be prepaid. I can only assume that this is an oversight? I will update this post when I know more.

Older Posts »



Get every new post delivered to your Inbox.

Join 25 other followers