There are different ways to extend Generic Microsoft Electronic Reports (GER), depending on your needs. If you need to modify the data source, you would extend the mapping, while if you need to modify the design, you would extend the format. However, both approaches have limitations; for example, you cannot add a new field.
In this post, I’m going to explain a pattern I usually follow, even for small changes, because I know it will allow me to extend the report without limitations in the future. This pattern has a couple of variations, depending on whether I want to reuse Microsoft’s format or not. Additionally, there is a minor bug associated with this pattern, which can be a bit annoying but has an easy solution that I will explain at the end.
Let’s start with a newly imported report, “Sales order packing slip (Excel),” and its references:
We start by extending the model. I always use the company acronyms as the prefix because this way I can easily identify which ones are extensions:
Now let’s extend the mapping by pointing it to our new model. This way, our new mapping will retain the bindings of the original:
Finally, let’s extend the format, also pointing it to our new model:
Now it’s a good moment to complete the three nodes and test if the report looks the same as the original. Since we only have one mapping for our new model, there is no need to check it as “Default for model mapping.”
Now with our pattern complete, let’s add this field from the legal entity:
Let’s start with the model:
We can proceed by completing the model, rebasing the mapping, binding it, and completing it:
Now, we should also rebase the format, but from the inside. Then add the new field to an existing format node, and complete it:
If we don’t want to use Microsoft’s format because we need a completely different design, we can create the new format under our model extension:
And let’s not forget the tags if we want to integrate it into the business documents (we can just copy them from the standard format):
Problem on moving the report to another environment
If we manually transfer our model, mapping, and their parents to another environment, downloading only the newest version of each node, and then validate or run our mapping, we will encounter a “Path not found / Data model does not exist” error:
This problem occurs because some enums point to a model version that doesn’t exist in the new environment. We can either repoint them to a newer version:
Or import the version of our model extension that our enum is pointing to (in most cases, they’ll be pointing to version 1). After importing it:
Final Thoughts
When I need to modify a GER, I usually follow one of the patterns we discussed. This approach gives us total control to extend and change the generic reports. The principle of ER extensibility is very powerful, enabling users to modify reports without altering the original. However, I wish Microsoft would put more effort into fixing the rebase issues we encountered in the mapping and also in the format.
Leave a Reply