GPUG Pre-Game General Session

The GPUG Pre-Game general session came in with some nice announcements – most importantly – Dynamics GP 2013 SP1 will be available mid April.

image

Jesse Byam, Etelligent Solutions, Inc set things off. Canadian guy in shorts, in freezing weather, certain thing – nobody got bored.

image

image

 

Jay Manley – took over with the important announcements.

image

Kim Peterson- came in to start the MVP session

image

 

The MVPs tacking the questions

 

image

 

I was thrilled to be in such fantastic company, and we took upon interesting questions ranging from – “What keeps you up at night” to “Impact of new limited users”.

Also announced was the shiny new GPUG Community site – http://community.gpug.com

Continue reading here:
GPUG Pre-Game General Session

March 18, 2013 · Jivtesh Singh · No Comments
Tags: , , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 219

RapidStart for Dynamics GP–A must see set of tools

Imagine configuring new companies in Dynamics GP in minutes rather than hours or days. In the Rapid Implementation session at (GPUG Pre-Game) – Jay, Gloria and Scott showed how they have done this in the past few months. Dynamics GP has great new tools for speeding up configurations, migrations for new implementations – RapidStart. Microsoft is going to start marketing this tool heavily, so make sure you are up to speed with the tool!

This session had the following stalwarts –

  • Jay Manley (Sr. Product Manager – Microsoft)
  • Gloria J. Braunschweig, (CMA President)
  • Scott Dimmick (Practice Manager – Tribridge)

 

image

Naturally, the seasoned Dynamics GP consultants would go – well that would only work in some cases. And, you would be absolutely right! What I loved in Rapid start was the ability to create templates that you could reuse across industries.

RapidStart comes with inbuilt integrations for Quickbooks, Peachtree and excel templates that can be used with other software.

 

image

However, this being the first version there are some caveats –

  • Not all modules are supported (project accounting / canadian payroll, australian GST to name a few )
  • The tool does a complete sync of all setups supported (not a partial sync)

Still it would be a great starting point, and all GP Partners should be looking at this. Get the tool for FREE at 

RapidStart Download Page
https://mbs.microsoft.com/partnersource/deployment/resources/migrationtools/MSDGP2013RapidStart

For more information about the Rapid Implementation Tools, please visit
http://www.microsoft.com/en-us/download/details.aspx?id=4071

Gloria has written a book on Rapid Implementation – check it out at http://rapidimplementation.com/

ERP Software Blog has a video at

 

RapidStart for GP 2013

Read more here:
RapidStart for Dynamics GP–A must see set of tools

March 18, 2013 · Jivtesh Singh · No Comments
Tags: , , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 284

Will Your Existing GP Customizations Work in GP 2013‌?

With the recent release of Microsoft Dynamics GP 2013 comes an exciting new feature: the Web Client. We’ve all longed for the Web Client, dreaming of a day when we could access our system from any web browser without being tied to our desktops and office networks, and now it’s finally here! Before we all begin to jump for joy, there is one thing to realize before making the switch to GP 2013—some of the customizations that you’ve made over the years to your existing Dynamics GP installation may not be fully compatible in the new Web Client.

Before going further, let’s take a look at the different ways that GP can be customized, which of those ways will present an issue moving over to the new GP 2013 Web Client, and the next steps to make the transition.

4 Types of Dynamics GP Customizations

There are four ways that Dynamics GP software can be modified or customized:

  1. Modifier – Allows changes to be made to the user interface (UI). Examples include adding new fields, moving fields around, and changing field labels, etc. Customizations made to GP using Modifier will be compatible with both the GP 2013 desktop version as well as the Web Client.
  2. Dexterity –This is the programming language in which Dynamics GP is written and customizations to the code level require a Dexterity developer. Example of changes to Dexterity code include things like adding new business logic or capturing business domain specific data through alternate forms or window modifications. The possibilities are endless. Customizations made to GP using Dexterity will be compatible with both the GP 2013 desktop version as well as the Web Client.
  3. VBA – Is most often used to add additional functionality to fields such as disabling a field or automatically populate fields from a database, etc. Although customizations made to GP using VBA will be compatible with the desktop version of GP 2013, at this time they are not compatible with the GP 2013 Web Client.
  4. VST – Allows the same type of changes that would be made with Dexterity but with the .NET programming language. Although customizations made to GP using VST will be compatible with the desktop version of GP 2013, at this time they are not compatible with the GP 2013 Web Client without additional modifications.
Type of Customization
Compatible with GP 2013 Desktop Version
Compatible with
GP 2013 Web Client
How to tell if you have this customization
Modifier
Yes
Yes
The page title of the window will have a dot in front of it
Dexterity
Yes
Yes
The dexterity modification will be listed in the Dynamics.set file: C:Program FilesMicrosoft DynamicsGP (or the application directory where you installed GP)
VBA
(Visual Basic for Applications)
Yes
No
The page title of the window will have a dot at the end of it
VST
(Visual Studios Tools)
Yes
No
All customizations are stored in the AddIn subfolder of the Microsoft DynamicsGP folder.

How to Tell What Kind of Customizations You Have

There are a few simple ways to tell what type of customizations you have in Dynamics GP.

1.       Modifier – The Customization Maintenance window will list modified forms, modified reports, and custom VBA code and references that are active on the workstation.
Tools -> Customize -> Customization Maintenance

If you have made customizations to GP using Modifier, there will be a dot in front of the window’s page title.

2.       Dexterity – The Customization Status window will list Dexterity customizations, as well as the Dynamics GP modules and Dexterity-based ISV solutions that are installed and active.
Tools -> Customize -> Customization Status

3.       VBA – The Customization Maintenance window will list modified forms, modified reports, and custom VBA code and references that are active on the workstation.
Tools -> Customize -> Customization Maintenance

If you have made customizations to GP using VBA, there will be a dot at the end of the window’s page title.

4.       VST – All customizations made to GP using VST are stored in a folder called AddIns. If you have VST customizations, you will find them inside this folder located AddIn subfolder of the Dynamics GP client installation. This is typically C:Program Files (x86)Microsoft DynamicsGPAddIns.

Next Steps

If GP customizations exist that may not be compatible with the new GP 2013 Web Client here are a few suggestions to preserve your customization’s functionality.

Business Process Analysis
Is this functionality still needed‌? Can it be improved‌?


Determine if the customization is still needed. New releases are packed with new functionality and the task that the old customization helped accomplish may now be handled out-of-the-box in the new version.  Or, your business may have changed and it is simply not needed any longer! A business process analysis against the new version will help identify which customizations are no longer needed. After reviewing the new release’s capabilities, you may find that there are many other new features offered that you hadn’t even thought of before.

It’s like trading in your old 1994 Honda Accord for the 2013 model—you were excited about the built in navigation system (no more Garmin attached to your windshield) and heated seats but you had no idea that it had blind spot detectors and could park itself! So when you’re ready to make the switch, make a point to learn about all the new features of the software, not just the ones you already know about and you may be pleasantly surprised. Sometimes you don’t know what you don’t know!

Spend Time on Design

If a customization is going to be re-implemented it makes sense to spend a little extra time on the design of the customization. Ask yourself if there are any features that have been lacking that need to be added or can the functionality be changed to make it more user friendly. By making sure you have got the most value out of your customization it will pay off in the long run when you don’t have to continuously make changes to it again and again in the future.

Use Case Documentation

As with all customizations, it is a best practice to document, document, and document. Before sitting down with a developer take screen shots of the areas you want to change and document the business process flow. This will provide clear communication between you and your developer and help to ensure there aren’t any discrepancies between what you are trying to achieve and what the system ends up doing. It’s great to keep them on record as well!

Hire a Professional Dexterity Developer

Now that you are ready to move forward with your customizations into GP 2013’s Web Client, you’ll need to hire a Dexterity developer. Dexterity developers aren’t as easy to come by as other programming languages, but the good news is that if you’ve found one, they probably know their stuff (this isn’t something your neighbor’s nephew in high school can do for you on the weekends). It’s a sophisticated programming language that takes years of experience to learn.

After having completed all of the leg work; conducting your business process analysis and providing your developer with use case documentation, the dexterity changes should be a breeze!

Here are a few things to look for in a Dexterity developer:
·         Is the programmer certified in Dexterity or Microsoft Dynamics GP‌?
·         How many or how long has the programmer been working with Dexterity‌?
·         Will the programmer provide documentation of their changes‌?
·         Will the programmer, or company they work for be able to support you in the years to come‌?
 

 

http://mbsguru.blogspot.com/atom.xml

Follow this link:
Will Your Existing GP Customizations Work in GP 2013‌?

March 17, 2013 · Bryan Prince · No Comments
Tags: , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 449

Extender 2013 Has Arrived – Thanks eOne

Awesome news to me this afternoon…

eOne Solutions has released Extender 2013 for Dynamics GP 2013 today (late yesterday for some regions). Read their official blog post here: Extender Delivered.

Instructions on how to get the new version and license keys can be obtained from either your Partner or eOne directly. Shoot an email to them and they would be more than happy to guide you.

Let me continue with my customisations’ upgrade. Hectic times ahead.

VAIDY

Read More:
Extender 2013 Has Arrived – Thanks eOne

March 15, 2013 · Vaidyanathan Mohan · No Comments
Tags: , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 206

Quick Tip: Handling scripts that use old() when using triggers to set default values

David Meego - Click for blog homepage This Quick Tip comes to you after I faced this issue in a recent customisation project. I had seen this issue before and knew the approach required to solve it, but I don’t think it has been document publicly till now.

 

The Scenario

The customisation required is fairly common. The customer wanted a batch number to be automatically generated for Purchasing Invoice Entry (Purchasing Invoice Entry) window.

The usual method for setting default values on a window is to trigger after the WIN_PRE event for the window and the set the values for the fields you are interested in and then run the change script for the field.

For example:

‘Batch Number’ of window POP_Invoice_Entry of form POP_Invoice_Entry = MBS_Generate_Batch();
run script ‘Batch Number’ of window POP_Invoice_Entry of form POP_Invoice_Entry;

However, for our customisation, we wanted the user to have the opportunity to override the default setting and did not want the “Do want to add this batch?” dialog to pop up when the window was first opened.

So we decided to use the approach of triggering on the PRE event for the ‘Batch Number’ field which runs when the field gains focus, we could then set the default value (if the field was empty) and issue the force change command to make sure that the change script executes even if the user does not change the value and just tabs off the field.

default form to POP_Invoice_Entry;
default window to POP_Invoice_Entry;
 
if empty(‘Batch Number’) then
    ‘Batch Number’ = MBS_Generate_Batch();
    force change field ‘Batch Number';

end if;

This code did set the value as desired, but when the user tabbed off the field, the change script appears not to run as the user is not asked to add the batch (if it does not exist).

 

The Problem

Using Dexterity’s built in Script Debugger, we logged the scripts and confirmed that the POP_Invoice_Entry Batch Number_CHG script was being executed. So I checked the source code and found the following lines right at the top of the script.

if (‘Batch Number’ = old() ) then
    Chose same batch from the lookup
    abort script;
end if;

What was happening was that the ‘Batch Number’ and old() values were the same and the script was being aborted as the script decided no action was required.

So now what?

 

The Cause

The cause of the issue all comes down to the timing of when Dexterity obtains a copy of the field value to use for the old() value. The capture of the previous value happens when the field gains focus and the cursor is moved to the field. The cursor is only moved when the user interface gains control again…. once all the scripts being executed have completed.

So how can we have our scripts complete but continue executing after control has been returned to the user interface?

 

The Solution 

The solution is the run script delayed command. The “delayed” keyword means that the existing scripts will finish before the field’s change script will be executed.

For this method to work, you will need a hidden field somewhere that you use with the run script delayed. This field could be added to an alternate window if you are using an alternate window. If you not using an alternate window, you would need to have a hidden form somewhere with a window (AutoOpen=false) to contain the field. If you have a command form for your menus, a hidden window on that form works well.

In our case we were using an alternate window, so we added a local Batch Number field to the window and registered a change trigger against it. We could have added a script directly on the window, but best practice is to use triggers (see my Knowledge Base Article KB 929211 on the topic).

Now the code is in two parts. First is the PRE trigger on the ‘Batch Number’ field:

default form to POP_Invoice_Entry;
default window to POP_Invoice_Entry;
 
if empty(‘Batch Number’) then
    run script delayed ‘(L) Batch Number';
end if;

This allows the focus to be set to the ‘Batch Number’ field and the value for old() to be set to an empty string. Then the second trigger on the ‘(L) Batch Number’ field change event runs to complete the customisation:

default form to POP_Invoice_Entry;
default window to POP_Invoice_Entry;
 
if empty(‘Batch Number’) then
    ‘Batch Number’ = MBS_Generate_Batch();
    force change field ‘Batch Number';

end if;

This time the POP_Invoice_Entry Batch Number_CHG script continues passed the old() check and works as desired.

 

More Information

You might notice that the final method used does not have a run script command in it. When a field change script uses the old() function, you might get an error message if you execute it with a run script command. This method using force change, makes Dexterity execute the change script for you without manually using a run script command.

 

Hope you find this technique useful.

David

See more here:
Quick Tip: Handling scripts that use old() when using triggers to set default values

March 11, 2013 · David Musgrave · No Comments
Tags: , , , , , , ,  · Posted in: Blogs I Follow Total Views: 225

Australian Goods and Service Tax (GST) Business Activity Statement (BAS) XML File fails to import into the Electronic Commerce Interface (ECI)

David Meego - Click for blog homepageToday I am going to discuss a support case where we found an issue with the XML file created when exporting the Business Activity Statement (BAS) tax return report for Australian Goods and Services Tax (GST).

So, if you don’t have to work with Australian companies and the rest of this article does not make sense, please don’t worry.

Before I start, I should explain that the issue discussed below has been fixed for GP 2010 (v11.0) Service Pack 3 and later as Problem Report 63031. If you are still on version 10.0 read on, if you are on GP 2010, install SP3 or later (or read on).

Get ready for lots of TLAs (Three Letter Acronyms).

 

Background 

Tax returns for Australian Goods & Service Tax (GST) are called Business Activity Statements (BAS) and there are a number of different forms based on what components of the tax legislation the business needs to report on. The Australian Taxation Office (ATO) provides software called the Electronic Commerce Interface (ECI) which allows the BAS data to be sent electronically to the ATO. The ECI also allows you to export and import the data using XML files.

Microsoft Dynamics GP has an additional BAS Report module for Australian installations. This BAS Report module will gather the data for the required date period in the form needed by the ATO from the source transactions in Microsoft Dynamics GP. Once the information has been collected, it can be either:

  • Manually transferred on the hand written paper form. While the BAS Report module can print a form that looks very like the real paper form, only the real paper form from the ATO can be lodged.
     
  • Manually transferred (cut and paste) directly into ECI software and lodged electronically.
     
  • Automatically transferred via XML files to the ECI software and lodged electronically.

It is this last method that we are interested in.

The way that the XML file method works is as follows:

  1. In Microsoft Dynamics GP, process the BAS data for the desired date period.
  2. Once complete, Edit the Business Activity Statement to see and adjust the data as needed.
  3. From the ECI software, locate the form provided by the ATO which needs completion and export it to an XML file.
  4. Back in GP, import the XML file to populate the BAS header information.
  5. Then export from the BAS a new XML file which now contains the additional transaction data.
  6. From the ECI software, import the updated XML file.
  7. From the ECI software, send the document to the ATO via the internet.
  8. Back in GP, mark the BAS as lodged and close the appropriate Tax Periods.

Note: There is a method of automating the export/import processes to combine steps 3 & 4 into a single step and steps 5 & 6 into a single step.

 

The Problem 

The issue we are seeing occurs at step 6 above. When you attempt to import the XML file into the ECI software it generates an error similar to the one below:

Error – BT – E104
An unexpected error occurred while opening a form.
Further details: unable to access form resource archive for NAT4235-0.2001.V2

Notice that it has a Document Type Description (DTD) of NAT4235-0.2001.V2. All of the different BAS forms have a number similar to this. This number is for a BAS-G type form. However, if we compare the XML exported from the ECI software (step 3) and compare it to the XML exported form the BAS software (step 5) we can see a difference in the headers:

Original ECI Software exported XML


V5>

 

Updated BAS Software exported XML


V2>

 

There is a difference in the DTD with the version number.  The “V5″ in the original XML file has been changed to “V2″ in the updated XML file. “V2″ is incorrect and so when you attempt to import the XML back into the ECI Software, it generates the error.

 

The Cause

OK, so the version has been updated and the BAS code was written using the old version. However, this was something that we expected and the BAS code had special handling exactly for this situation. There is a BAS_Report_Forms_SETP (BAS40200) table whose only job is to store the latest updated DTD version numbers for the different BAS forms. If you import a form with a higher number than the one the BAS code was expecting, it will write it into the table and then use that DTD when exporting.

So what went wrong, why did the “future proofing” code not work?

Well, I have worked it out, it took a while, but the cause is very subtle. Firstly, you have to understand that the BAS code that is reading the XML file is not actually an XML processor. To use the XML libraries requires Dexterity to use COM (Component Object Model) calls, but the BAS code was written before Dexterity supported COM. So the XML file is just read as a Text file and the BAS code interprets the XML tags accordingly.

This is import because the code that handled the “future proofing” of the Document Type Descriptions (DTDs) is looking for the “looking for it at the beginning of a line! Look closely at the XML excerpts above and you will notice that the “

This is why the DTD version check was being skipped and why the updated version was not getting written to the BAS_Report_Forms_SETP (BAS40200) table.

 

The Solution

In GP 2010 Service Pack 3 or later, the code has been fixed in two ways. The default Document Type Descriptions (DTDs) have been updated to the latest versions AND the “future proofing” code that updates the BAS_Report_Forms_SETP (BAS40200) table has been adjusted.

However, if you can’t install GP 2010 SP 3 or later, you can manually fix the issue by populating the BAS_Report_Forms_SETP (BAS40200) table with the updated DTDs.

The SQL script below can be executed against each Australian Company database to update the contents of the table.

  

Transact SQL Script

delete from BAS40200
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
 values (1, ‘NAT4189-9.2001.V5′) — BAS_FORM_A
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
 values (3, ‘NAT4195-9.2001.V5′) — BAS_FORM_C
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
 values (4, ‘NAT4191-9.2001.V5′) — BAS_FORM_D
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
 values (6, ‘NAT4190-9.2001.V5′) — BAS_FORM_F
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
 values (7, ‘NAT4235-9.2001.V5′) — BAS_FORM_G
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
 values (8, ‘NAT4236-4.2001.V5′) — BAS_FORM_H
insert into BAS40200 (BAS_Form_Type_Number, BAS_Form_Type_Code)
 values (16, ‘NAT4646-3.2005.V2′) — BAS_FORM_P
select * from BAS40200

/* Copyright © Microsoft Corporation.  All Rights Reserved.
   This code released under the terms of the
   Microsoft Public License (MS-PL, http://opensource.org/licenses/ms-pl.html.)
*/

 

I hope you find this interesting and not too confusing and more importantly… useful. 

David

Read More:
Australian Goods and Service Tax (GST) Business Activity Statement (BAS) XML File fails to import into the Electronic Commerce Interface (ECI)

March 1, 2013 · David Musgrave · No Comments
Tags: , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 395

Copying Report Formats between Reports… and a warning about Word Templates

David Meego - Click for blog homepageThere is an unsupported method of copying report formats between reports that is very commonly used (and even recommended by me), but we recently had a case that highlighted a problem with the technique. This blog post will discuss the method and the issue we have seen.

 

The Situation

The situation is very common and can have two variants. I will use the Sales Order Processing Reports for my example, here are the scenarios:

  1. You have modified the SOP Blank Invoice Form to meet the requirements of your customer (either as the final document or for use with Word Templates). You now want to duplicate the format changes to other document types (Blank, Long, Other, Short, with options, etc.).
     
  2. You have modified the SOP Blank Invoice Form to meet the requirements of your customer (either as the final document or for use with Word Templates). You now want to duplicate the format changes to the historical version of the report: SOP Blank History Invoice Form.

Next, we will look at how the report formats can be duplicated. 

 

The Method

Before we go into details, I must emphasize that this method is not officially supported as it required direct editing of Customization Maintenance packages.

Below are the steps to copy a report format from one report (Source Report) to another report (Target Report):

  1. Ensure that both the Source Report and the Target Report have both been inserted into the Modified Reports list (right hand pane) in the Report Writer. The Source Report should already be there, inserting the Target Report makes one of the following steps easier.
     
  2. From the Microsoft Dynamics GP application, select Microsoft Dynamics GP >> Tools >> Customize >> Customization Maintenance and export both reports separately as packages. You can locate the files on your Desktop for ease of access.
     
  3. Open Notepad.exe and drag and drop the Target Report’s package into the Notepad window.
     
  4. Then copy the report naming line(s) to your clipboard.  For example:
     

    Report “SOP Blank History Invoice Form”
     
  5. Drag and drop the Source Report’s package into the Notepad window.
     
  6. Select the report naming lines(s) and paste from your clipboard to replace the information.
     
  7. Optional Step when changing report from Work to History: Perform the appropriate Find and Replace steps to update the tables used on the report:
     
    Find: SOP_HDR_WORK    Replace with: SOP_HDR_HIST
    Find: SOP_LINE_WORK    Replace with: SOP_LINE_HIST
     
    Tables which are used for Work and History do not need changing, such as SOP_LINE_CMT_WORK_HIST, SOP_Serial_Lot_WORK_HIST, sopUsrDefWorkHist.
     
  8. Select File >> Save As and save the updated package file as a new file with the name of the Target Report plus “Updated”. Keep the original Target Report’s package file as a backup in case you need to restore it.
     
  9. Back in Microsoft Dynamics GP, import the updated Target Report package via Customization Maintenance.
     
  10. Adjust Alternate Modified Forms and Reports security settings to use the now modified version of the report. 

Note: You must also ensure that the Main Table (as shown on the Report Definition window in Report Writer) is the same for the two reports involved. If the main tables do not match, it is very unlikely that the target report will print successfully.

 

The Problem 

While the method above works extremely well for the Report Writer reports, we have found that reports updated using this method do not always work with Word Templates. If you go back to the original report, the Word Templates work, but with the modified report the Word Template does not always work. This is often noticed when the Historical versions of the reports fail to email.

Our case had the issue that the SOP Blank Invoice Form would print and email via Word Templates, but the SOP Blank History Invoice Form would print but not email. Research found a blog post by Andrew Hall from Touchstone in the UK (see below) that highlighted the issue.

To understand what is happening you need to understand a little about how Word Templates work. Word Templates are tied into the Section Breaks of a report. When the different sections print, events fire in Dynamics which are picked up by the Word Templates handling code and are used to capture details about the key fields upon which the section breaks are based. The code in Dynamics and the section breaks in the reports match so they both refer to the same field in the same table.

If you start changing the sections, or the fields upon which section breaks are based, the code and section breaks no longer match and Word Template functionality will start to fail.

The problem as highlighted in Andrew’s blog post is that the Section Breaks in the Work SOP reports are subtly different from the matching Section Breaks in the History SOP reports. When we used the method above to copy the report format, we unintentionally broke the Word Template Email functionality by changing the Section Breaks.

Below are screenshots of the Dummy1 Header and the Back Order Footer from the Work Invoices that show that the SOP Number field is being captured from the Sales Transaction Work (SOP_HDR_WORK) table.


Dummy1 Header from SOP Work Invoice (SOP Number from SOP_HDR_WORK)


Back Order Footer from SOP Work Invoice (SOP Number from SOP_HDR_WORK)

Below are screenshots of the Dummy1 Header and the Back Order Footer from the original (unmodified) History Invoices that show that the SOP Number field is being captured from the Sales Transaction Amounts History (SOP_LINE_HIST) table, which is not the Sales Transaction History (SOP_HDR_HIST) that came across when we copied the format.


Dummy1 Header from SOP History Invoice (SOP Number from SOP_LINE_HIST)


Back Order Footer from SOP History Invoice (SOP Number from SOP_LINE_HIST)

As the report is not breaking on the correct field in the wrong table, the data passed to the Word Template code is incorrect (blank) and the Email functionality fails to work.

 

The Solution

The fix for this issue is to edit the Section Breaks for the History Report so that the Dummy1 Header and Back Order Footer use the SOP Number field in the Sales Transaction Amounts History (SOP_LINE_HIST) table again. 

The exact steps are listed in Andrew’s Blog:

 

The Warning 

The lesson learned here is to avoid changing section break tables and fields for reports that are used with Word Templates. If the Word Templates fail to work in any way, test with the original Report Writer report and see if that works. If it does, compare the table and field for each section break with the original report and make sure they match.

A good method would be to never remove fields or change section breaks. You can always hide fields or supress section breaks if you want to make changes. Also keep testing (and saving packages) as you modify the reports to make sure you have not broken anything. If you test as you go along, it will be easier to remember the last changes made so they can be backed out.

 

More Information

Below are some blog articles which discuss aspects related to this post:

 

Thanks to Andrew Hall for his troubleshooting on this issue, hopefully I have clarified the reasons and a possible cause in duplicated reports.

David

See more here:
Copying Report Formats between Reports… and a warning about Word Templates

February 26, 2013 · David Musgrave · No Comments
Tags: , , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 388