Inventory Receiving Transactions – Why is my Receipt Split?

In some instances, GP will split a receipt of inventory into 2 receipt lines.  Why does this happen?  There is a great explanation of this in Microsoft Knowledge Base Article 2741489.

Visit link:
Inventory Receiving Transactions – Why is my Receipt Split?

November 6, 2013 · Frank Hamelly MCP-GP MCT MVP · No Comments
Tags: , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 200

Microsoft Dynamics GP 2013 Service Pack 2 Features of the Day

David Meego - Click for blog homepageAfter the release of Microsoft Dynamics GP 2013 Service Pack 2, the Inside Dynamics GP team have released a Feature of The Day series.

In case you missed them, here is a summary post with links to all the articles:

 

Thanks Pam for posting this great info. 

Enjoy

David

See the original article here:
Microsoft Dynamics GP 2013 Service Pack 2 Features of the Day

November 6, 2013 · David Musgrave · No Comments
Tags: , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 158

Step by Step: Installing Dynamics CRM 2013 on Windows Server 2012

This blog covers the procedure to install Microsoft Dynamics CRM Server 2013 on a computer that does not already have Microsoft Dynamics CRM installed.

See original article:
Step by Step: Installing Dynamics CRM 2013 on Windows Server 2012

November 5, 2013 · Niran Belliappa · No Comments
Tags: , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 232

Management Reporter Incorrect Figures Caused By Lower Case

A client reported a problem with Management Reporter returning incorrect figures when a link to the Financial Dimensions on the Row Definition had been entered in lower case. The reports in question had been created in FRx which was rather … Continue reading

See the original post:
Management Reporter Incorrect Figures Caused By Lower Case

November 5, 2013 · Ian Grieve · No Comments
Tags: , , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 168

Quick Tip: Unusual behaviour when working with SQL Server from Dexterity

David Meego - Click for blog homepageToday, I came across an issue where a feature in Microsoft Dynamics GP would work when the workstation had its regional settings set to United States, but would fail to produce any data when the workstation had its regional setting set to Australia, New Zealand, United Kingdom, etc.

We have seen related issues where code would appear to work for the first 12 days of a month, but would generate errors on the 13th day of the month when using non United States regional settings.

We have also seen issues where errors get generated when there is a single quote character in data, or records beginning with Z failing to be included when processing or printing reports.

We have even seen issues where errors are generated when regional settings for time were altered so that the suffixes for 12 hour time were changed from AM and PM to A.M. and P.M.

All of these problems are caused when Dexterity code talks directly to SQL Server and best practices are not followed.

Note: All table access that is handled by Dexterity itself will correctly handle the issues that can cause the above mentioned problems.

 


However, the leverage the functionality of SQL to optimize performance, there are times where developers write Dexterity code that bypasses the Dexterity table handling and talks directly with the SQL Server.

There are many benefits that can gained when using SQL Where clauses with the Dexterity range table where command, when executing pass through SQL commands, or calling stored procedures. But there are some best practice methods which will avoid all of the problems mentioned above.

 

Here is a quick summary:

Strings

  • Always make sure that strings are passed through to SQL using the SQL_FormatStrings() function which will double up single quote characters and also surround the string with starting and ending single quotes. This will avoid the issues caused by a single quote in the data terminating a string early.
     
  • If passing a range by specifying a minimum and maximum value and the maximum is not defined (so we want all records to the end), make sure you use the system 9600 method (see KB 910129) to define the maximum value for the current SQL collation. This will stop records starting with Z from being excluded on DOCI sort orders.
     
  • If writing any SQL code that building statements to be executed with the exec command and there are string values from the data being hardcoded into the code, but sure to use set @variable = replace(@variable, ””, ”””) to double up any quote characters to prevent early termination of a string.

Dates 

  • Always make sure that dates are passed through to SQL using the sqlDate() function to convert the date value to a string and not the str() function. This will avoid all the date based regional settings issues by making the conversion to a string independent of the control panel settings.
     
  • You can then use the SQL_FormatStrings() function add the starting and ending quotes.

Times

  • Always make sure that times are passed through to SQL by creating a sqlTime() function (see KB 929786) to convert the time value to a 24 hour string and not the str() function. This will avoid all the issues caused by non standard suffixes in 12 hour time.
     
  • You can then use the SQL_FormatStrings() function add the starting and ending quotes.

Numbers

  • Using the str() function for numbers works fine. Remember that currency data type fields will be converted to strings with five decimal places.

 

You might have seen all or some of this before, but just in case I wanted to highlight it again as I am still seeing code that does not follow these best practices and so fails under certain circumstances that the developer probably did not test for. 

  

More Information

The following articles on this blog discuss related issues:

 

The following Knowledge Base articles also discuss these issues:

 

Hope this helps you write robust code for all regions and settings

David

Taken from:
Quick Tip: Unusual behaviour when working with SQL Server from Dexterity

November 4, 2013 · David Musgrave · No Comments
Tags: , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 190

eConnect transaction not rolling back

Patrick Roth - Click for blog homepageI ran across an interesting case the other day with eConnect.  I had a similar type of case I wrote about previously, but this one is for a completely different reason.

The ISV was moving his working customization from GP 10.0 to GP 2010/2013.

The Problem

Essentially the customization would use eConnect to create a transaction and then also insert/update a custom table with data that goes with the transaction.

To make sure that both the eConnect transaction and the custom data goes in as one unit, the developer is using the SQL TransactionScope pattern.

ISV Code sample that reproduces the problem

using (TransactionScope oTranSc = new TransactionScope(TransactionScopeOption.Required))

     //create or update a document calling econnect
     bResult1= eConnect.CreateEntity(txtConnString.Text, myXmlDoc.OuterXml);

    //throw an exception if it failed
if (!bResult1) throw new Exception();

//call method to update or create our custom data using normal ADO methods
bResult2 = UpdateCustomData()

//and throw exception if failed
if (!bResult2) throw new Exception();

//if we got here without errors, then complete the scope so that the transactions are committed
if (bResult1 && bResult2)

//success so complete the transaction
oTranSc.Complete();

}
catch

//failure, the transaction will implicitly roll back since the Complete() method wasn't called

I didn’t give specifics on the eConnect XML or what the TSQL that the developer uses in the UpdateCustomData() method because it doesn’t matter.  

In this case, the ISV found the issue because he mistakenly had the wrong column name in the TSQL.  A SQL Exception was properly thrown and he had expected the eConnect document would have been rolled back – just like it did in 10.0.

So he was very surprised to see that it was not!

I was a bit perplexed since we know that eConnect does indeed roll back a failed transaction and it uses the TransactionScope() method exactly the same way the developer is doing above.  Since ours works OK in eConnect, why doesn’t it work when the result of his SQL statement throws an exception?

And of course, why does it work fine in eConnect 10.0?

The Reason Why

The reason is how eConnect 10.0 worked vs eConnect 2010/2013 works.  

In the new versions of eConnect that use the Windows eConnect Service, the “local” call to the eConnect dll actually connects to the eConnect WCF Endpoint the service has created and passes it the connectionstring and XML for the document.

At that point, the eConnect/SQL work is outside of the TransactionScope() defined and so therefore it isn’t committed or rolled back in the ISV code.

In 10.0, we used the Enterprise Library under COM+ and so apparently functions “in scope” in the ISV code.

OK, that seems to make sense but is there a solution?

The Solution

The simplest solution that I can think of that is 100% effective is to disable the WCF communication between the ‘local’ eConnect call and the eConnect WCF service.  Now the transaction is processed locally and we fall within the scope of TransactionScope().

eConnect allows this as an application configuration setting in the app.config file but since we could end up with inconsistent GP/Custom data, changing this in code is the best approach.

The solution is to just add a line to disable the call.

Revised Code

//create or update a customer calling econnect.  Disable the WCF layer first.
eConnect.RequireProxyService = false;
bResult1= eConnect.CreateEntity(txtConnString.Text, myXmlDoc.OuterXml);

//throw an exception if it failed
if (!bResult1) throw new Exception();

 After making this small change, the test exception in the UpdateCustomData() caused the TransactionScope() to implicitly roll back both the failed TSQL and the eConnect transaction.  Success!

Best Regards,

Patrick Roth
Senior Escalation Engineer
GP Developer Support

View original post here:
eConnect transaction not rolling back

November 1, 2013 · Patrick Roth · No Comments
Tags: , , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 209

eConnect error, but not the real error!

One of my customers is doing some Sales Order Processing integrations with GP2010… and for the most part, when we run into eConnect errors, it pretty much tells you what the issue is, and you fix it and move on.

We ran into one the other day and this error wasn’t even the real error, so it wasn’t until I looked at the XML they were trying to pass did I see what the real issue is.

The Issue

The error message was this:

“Error Number = 67  Stored Procedure= taSopHdrIvcInsert  Error Description = Subtotal does not match the line item totals”

The conversation with the developers went like this:

  • Devs: Hey Jen, we’re getting this error, can you help?
  • Me: Sure. This one sounds like you need to check that the sum of the line items you’re passing in match the Subtotal field you’re passing on the header.
  • Devs: It does match.
  • Me: Well, that’s not possible… it’s saying it doesn’t match. Can you double check?
  • Devs: Already did, it still doesn’t work!
  • Me: I’ll be right over to look at it with you.

Troubleshooting

The first thing we checked was that we were all speaking the same language and that the dollar fields they were passing indeed were the same, so this error text itself wasn’t the “correct” error.

Side note: as painful as it is, when you’re troubleshooting, don’t be afraid to start with the obvious.  Had it been a simple “lines not adding up to the subtotal” error, it wouldn’t have surprised me.  It would not have been the first time I’ve helped a client where there was either a misunderstanding of what I meant or that the most basic of things that they skipped trying to find a “rare” error were actually right there like low hanging fruit.

In this case, I said we need to look at the XML they are passing in the SOP transaction.  In this case, here was a sample of the Header code, where they were receiving the error:

We looked at this and kept looking at the dollar fields, since the message was talking about subtotals not matching lines. It was clear that wasn’t the issue so we then looked at the SOP line XML, and there I saw what the issue was:

For whatever reason, the SOPType on the Header and the Line were being passed two different values.  They were passing SOPTYPE 3 on the line (Invoice) and SOPTYPE 4 on the header (Return).  GP in theory was comparing the dollar values in the context of the document type and realizing they weren’t a match.

Of course the error text REALLY should say “The SOPTYPE on the header does not match the SOPTYPE on the line”, and it would be have all been a little more obvious!

Read the original:
eConnect error, but not the real error!

November 1, 2013 · jen@kuntzconsulting.ca · No Comments
Tags: , , , , , , ,  · Posted in: Blogs I Follow Total Views: 285