In many cases, a solution is developed with great re-use potential. These articles each describe an idea in a blue-print format. With a description, goal and objectives, the blue print, pro's and con's and success stories.
An order, delivery or an invoice, SAP supplies them all and the (customer) company wants to change their appearance to match company requirements. As the system is set up to suit company requirements, these are very likely to have an effect on the actual output as well. This article describes a step-by-step approach that achieves goals: stay with Standard SAP where possible, get the look and feel that is specific to the company, translation into all relevant languages, work with a flexible Master document, control specifics using customizing settings.
Every implementation project will produce a wide variety of developments that will require settings to be stored somewhere. Numerous tables will be created, more often than not holding only a handful of records. This blue print should be implemented very early on in the project...
Description
A solution for "development customizing" is remarkable easy to implement and has enormous advantages. In effect a single table will be created which will hold the "development customizing" settings for the whole implementation. 1 table to control all, set up in a clever way.
Worried about someone stealing your code ? Do you want to copy-protect your coding ? But SAP is an open source system: Abap developers can look under the rug and sift through all coding with great tools like the Abap editor and the debugger. So what's to stop a third party from stealing your ideas ? The copywiter.
The life of an ABAP development is like many things only temporary. This topic is about phasing out "old" developments, an approach where users are stopped and pointed to the alternative development.
Description
Implementing a project or implementing projects in SAP can involve version change of programs and even phase out the use or programs (classes, methods or function modules). This is part of the normal life-cycle of developments and can be regarded as such. In fact, on larger implementations, it's a good idea to take control over which development supercedes other developments. A simple central administration can be set up do activate and de-activate developments along with a hint pointing to the new version.
This way you can ensure the latest version of software is being used, and when an upgrade is knocking on the door, the development team will know which bits can be ignored (or eventually even removed).
Where outbound Idoc's are concerned: the CDM (customer distribution model) is very powerful. More power could be added by introducing filter control
Description
When working with Idocs the CDM (Customer Distribution Model) can be used to distribute outgoing Idoc messages. Using filtering (all standard SAP so far) certain segments (parts of an Idoc message) or whole Idoc messages can suppressed per message recieving partner. This messaging system is very strong, but we've found the need to enhance it with a bolt-on solution that controls the fields that are used for filtering Idocs. So in effect, the field that standard SAP uses to allow or hold back Idoc messages (or parts of Idoc message) - is populated via "Filter control" - "Controlling what is filtered".
Where solutions are implemented that are a little larger than normal, the concept of Health check report or Diagnostics report should be introduced.
Description
SAP implementations are never perfect. They are implemented by people. No shame of course, but a simple fact that should be accepted and for which a safety net approach can be set up quite easily. For many problems an investigation will include the query "how often does this happen" - which invloves chacking table content using transaction SE16(n). Where these selections become time consuming and involve multiple tables, the actual knowledge on how to check a certain problem can become something the sysyem needs to hold by itself. The health check report should handle them. Health check reporting is a very effective way to position knowledge on problems into the system, in the form of a check that can be re-applied over and over again. Instead of a virus scanner - you would have an automated health scan.
A blue-print solution that allows mixed use of user exits, this article describes a setup where the "module(s)" to be called is(are) determined at runtime allowing activation of user exits per country. The user exit is where SAP allows the customer system to interfere (in a good way of course) with the system, which does not really take into account the country split - unless the developer defines it (in ABAP coding). A centralized solution for this would:
Sometimes an interface is more than an interface - it's 15 files instead of one or two and there is great added value in making how the interface works clear to the daily-operations user. I've created a customizable interface or mappable interface for HR data, that serves it's purpose: it makes a complex and difficult task easy to build and easy to maintain.
There is a series of articles on this tool available on AbapcadabrA - HR Channels