|
Newsletters
(Marts, 2001)
- Implementing The EURO
- Replacing Middleware Solutions with SAP
- SAP R/3 - Quality Assurance on ABAP/4 Development in Connection with Upgrade from 3.1/4.0 to 4.5/4.6
- To Upgrade Or Not?
Implementing The EURO Tilbage
123
This article relates to problems and issues that can occur when implementing the Euro.
In 1998 I was maintaining a world-wide document print system running on an IBM mainframe (MVS, DB2, IMS environment) for a large shipping company.
The system primarily printed manifests, invoices and freight documents (>20 mill reports a year). The main concept behind the report system was that reports consisted of boxes and fields that could be customized down to customer level. New boxes/fields were implemented on a regular basis to satisfy large customers and to keep up with the ever-changing world.
PROJECT START
As the US dollar was the company currency the Euro was, as the business representative said, quote ‘just another currency’. Lots of new boxes and fields were ordered to contain the new Euro fields and the business representative made it clear that new change requests most likely would arrive at short notice. Our group was enhanced with 2 programmers for the needed changes.
Local Euro agents decided when to use Euro as local currency and since the currency boxes/fields were set-up for local and US$, we decided to replace the local boxes/fields with Euro and traditional. A German office would set-up boxes to show Euro, DM (the traditional currency) and US$ and hence system-wise no further changes would be needed when local currency is set to Euro.
The exchange rates were user input (per vessel, voyage, port both inbound and outbound) – however, the system was changed so when creating exch. rate, Euro currencies were displayed with the official exch. rate and this Euro exchange rate could be altered manually.
A new EUR currency was created due to business and system requirements, as the Euro is two currencies - a pre-1999 currency with ISO code XEU and a post-1999 one named the Euro.
The new conversion of exchange rate rules was not done by our group. The rules state that all exch. rate conversions for a traditional currency have to be done through the Euro. Exchanging DM to US$ will be by converting DM to Euro and then Euro to US$.
IN PROGRESS
The entire initial requested boxes and fields were done in due time; however, we found that the freight document de-sign could cause serious confusion. The freight document shows freight charges that are very often in multiple currencies, a subtotal per currency and a total. Exch. rate conversions are done per freight charge but the exchange rates are shown in the subtotal. US$, traditional and Euro are shown in subtotal and total (all op-tional – but often the case). For e.g. Ger-man customers a subtotal or total that shows 100 Euro the customers will normally presume that the DM value would be 51.13 (as the fixed rate is 1.95583); however, due to rounding this will often not be the case. The exchange rate showed in the subtotal field together with total amounts caused similar problems.
New boxes and fields were created that showed the exchange rate independently (not in subtotal). Boxes were done that showed the Euro calculated directly, based on the traditional total, for use by customers that did not use Euro value elsewhere. These customers were also instructed that this Euro value was not the chargeable amount (as ‘real’ amount figures the Euro calculated on the freight charges).
Simple example:
Charge1 10.99 DM
Charge2 10.99 DM
Charge3 50.50 NLG
Charge4 30.00 NLG
Subtotals
21.88 DM 11.24 Euro*1
Rate 1.95583
80.50 NLG 71.45 DM*3 36.53 Euro*2
Rate 2.20371
Total*4 93.33 DM 47.77 Euro
*1 (10.99/1.95583)+(10.99/1.95583)
*2 (50.50/2.20371)+(30/2.20371)
*3 DM converted from *2 Euro values (22.92x1.95583)
+ (13.61x1.95583)
*4 93.33 DM converted directly is 47.72 Euro
PROJECT END
Customers kept coming with new requirements, demands and questions well into 1999 until they had everything they needed (as the company ofte
Replacing Middleware Solutions with SAP Tilbage
123
NO FICTION
It sounds like fiction – can the big ERP system SAP really replace dedicated middleware solutions? For some very specific applications with high real time input, then yes – it might still be fiction. But, for many practical purposes, SAP can actually handle the situation without any problems – it is not fiction!
I had the opportunity to realize this with one of my customers, where SAP 4.0B was used to interface directly with hardware scales and handheld R(adio) F(requency) terminals.
The scales are placed in the goods receipt area as well as in the packing area, and the RF terminals are used in the picking and goods issue situations.
RF TERMINALS
The solution uses the SAP Console program to communicate with the RF terminals, emulating a SAP GUI on a very tiny screen. Input from the RF terminals comes from their keyboard and their built-in barcode reader.
A normal SAP dynpro program was developed to send screens to the RF terminals and to receive and handle the input. The end result would be a posting in SAP of a transfer order.
As it turned out, the solution is faster than the previous procedures. Of course some limitations had to be overcome due to the limited hardware in the RF terminals, but that was fairly easy. The whole solution was ready within a couple of months!
The main problem in the solution was the extended use of function keys, some of which were located on the “shift” posi-tions on the keyboard. Also, SAP 4.0B reserves several function keys for its own use, and the SAP Console works best with newer SAP versions like 4.6B.
Another major task was to fit all the necessary information into the tiny screen area, both input and output fields as well as lead texts. I am sure we invented quite a few new abbreviations there!
By the time you read this, the solution should be in production.
THE SCALES
The other part of the solution, with the scales, posed completely different problems. There were no tiny screens or other hardware limitations, but it turned out that a rather complicated posting in SAP was necessary. Deliveries had to be changed, packing materials had to be added, transport orders were generated, and finally everything was confirmed, resulting in a goods issue being made.
As it turned out, this posting process was the only real bottleneck in the solution, so it had to be done offline in a background task. I suggested an IDOC solution due to the extended error handling facilities available, but I do not know whether it was actually used in the final solution.
The online part of the solution communicates with the scale software using OLE2 technology. Had the scale vendor had more time, then a RFC communication with less overhead than OLE2 would have been preferred. But it turned out that the OLE2 protocol was fast enough for the purpose.
Several weightings could be performed for each delivery item, and to speed up the data entry on the clumsy industrial keyboard, connected to the scales, the SAP GUI logic had to be bent to allow the Enter key to be the main navigation key.
Despite all the internal administration necessary in the SAP dynpro program, the solution was up and running within a couple of months, and it is faster than the old middleware solution!
BENEFITS AND LESSONS LEARNED
The benefits of this solution are several, suffice to mention a few: There is no need for extra inhouse expertise on some third party software. The number of vendors involved is reduced. Changes can be made fairly quickly to accommodate new needs.
The lesson to be learned from all this rather technical stuff is that even senior consultants like myself have to modify our old learning. What used to be rules of thumb may no longer be valid! This constant change in our work environment gives great pleasure, and we do not have to remember things that we tend to forget anyway! What<
SAP R/3 - Quality Assurance on ABAP/4 Development in Connection with Upgrade from 3.1/4.0 to 4.5/4.6 Tilbage
123
For a lot of SAP R/3 customers the time has now come to where they plan (or are already planning) to go through an upgrade from 3.1/4.0 to 4.5/4.6. The entire upgrade process in itself can be quite complicated, and which requires attention from both the business and the technical sides. But it is also a process which can be affected by the QA standards for customer-development which you previously might have defined for the SAP R/3 system when it went live in the ‘old’ version of SAP R/3.
EVALUATION OF CUSTOMER-DEVELOPMENT
Part of the upgrade process will be an evaluation of the customer-development which exists in the system. You have to find out which object requires changes/reprogramming in order to work properly after the upgrade process has taken place.
During this evaluation you could run into development with quite different programming quality standards. Some might look like the quick-and-dirty solution which was sent into production as a short term solution. – And was never replaced with a long term solution!
You might find objects with wrong naming standards or missing technical/functional documentation (which could be quite important for the upgrade project). Or objects which are no longer needed in your system or which have a bad performance. You might find interfaces that are build upon several different strategies for system-to-system communication. In fact, the list can be quite long.
The programming quality might not affect the upgrade process directly as such. But it is seldom that you have the chance/time to evaluate all the customer-development in the same process. And it gives you an opportunity to re-evaluate the QA standards for customer-development, which should exist for a SAP R/3 installation. You can ask yourself, were the existing QA-procedures sufficient to obtain the requested result?
You might also end up with a long list of objects/concepts which needs a review. And the question is – why?
WHY SUCH A NEED FOR REVIEW?
Well, I think for most SAP R/3 installations the picture is similar. In connection with the initial SAP R/3 implementation the project had a lot of focus on the business side from day 1 – and less focus on the development side. But as the project went along requirements appeared which could not be covered within the SAP Standard. Customer-development was needed – and the first part of this development process was not covered by a clear technical strategy for the handling of customer-development. This situation could lead to a lot of ad-hoc solutions, which poses a lot of questions. For example:
- some interfaces were implemented using ALE/IDOC, others with file up/download
- how should we document the usage of user exits?
- how do we handle customer-development for SAPscript?
- should we build our development upon existing authorisation objects?
- how do we handle customer-development for reporting?
- is it allowed to use ABAP query?
- do we have a clear strategy regarding modifications?
- etc..
DIFFICULT TO UPGRADE AD-HOC SOLUTIONS
Today you might have the answer to all of these development ad-hoc questions. Today you might even have a written QA-standard for all of the above. But if the list of object/concepts needing a review is long, you might also have a backlog of issues which suddenly takes longer to handle in connection with the upgrade process.
In other words, the ad-hoc solutions are difficult to upgrade or fit into an up-graded SAP R/3 installation. Or you might not find sufficient documentation to determine the importance of a specific object.
LOG THE BACKLOG!
Part of the technical upgrade process would also be to document this backlog in order to have an overview of the issues found in connection with the evaluation.
After a successful upgrade you could use this overview to determine which ac-tions are needed in order to consolidate the customer-dev
To Upgrade Or Not? Tilbage
123
An interesting question, and from a consultants point of view, the answer could be ‘Yes’, well-knowing that it will generate extra workload to the staff and thereby a new contract for the consultant.
But seriously, the question could be more relevant rewritten: ‘To upgrade, but when to upgrade?’. Often you spend a lot of time, money and effort to get a system working with the desired functionality, and the same amount of resources to get the system finely tuned and people educated, and your goal is to be finished some time in the future.
Somewhere in the project you perhaps begin to consider whether an upgrade could be the solution to some of your problems or would it be less expensive to invent some functionality yourself in an old system/release.
In a SAP environment the upgrade solution could be strengthened by the fact that the answer to some of your OSS´s regarding the industry solution would be like: ‘The functionality you desire is implemented in new release XXB’, or ‘No further development is made to release XXA’.
BUT WHEN?
A company made the decision to up-grade with a newer release of SAP and of the industry solution. The only time possible to do it, regarding the downtime for the system, test and finally go or no-go, was set to be over Easter.
Due to lack of time, the upgrade should be a 1:1 upgrade i.e. no implementation of new functionality should take place in phase 1.
From a programmer’s point of view it was interesting how many of the own developed programs were able to run in the new release and how many had to be corrected.
HOW TO DISCOVER IN ADVANCE THE PROGRAMS NEEDING ATTENTION
A small program was developed, joining tables TADIR & TRDIR to select the programs to investigate; all the selected programs were then checked with the function module ‘EXTENDED_ PROGRAM_CHECK’ and a simple analysis of the result would reveal the action necessary to be taken.
The first thought we had on the challenge was:
1. Copy-programs where a std. program is copied to a new Z-version
2. Z-script’s, and printing programs for these as point 1.
3. Programs containing Batch/Input.
4. Programs using CALL TRANS-ACTION
5. General compile error due to new syntax.
And the priority came out to be almost like that; the Z-script’s only needed a few changes and the programs using CALL TRANSACTION needed more attention than expected.
The small check program made it possible for the programmers to be a little ahead in the beginning of the upgrade project and to stay a little ahead by solving some general errors fast and get some experience in the new syntax.
CONCLUSION
In general the upgrade was solved with more small practical and non-fancy tools and a lot of know-how exchange between the programmers. As a side-effect when correcting the programs for the new release, some hidden errors were revealed and corrected and some performance-tuning added to the programs.
So, the conclusion to the question ‘To upgrade, but when to upgrade ?’ must be ‘Don’t wait too long’ but consider if not even a 1:1 upgrade takes you far into the future for your company.
By the way: A relevant article when considering upgrade is found in SAP Professional Journal July/August 2000: ‘Upgrading to R/3 rel. 4.5 and Beyond: An ABAP Developer’s Guide’ by Steven Shi & Jun Qian. This article is a well written guide to get started on the project and contains some helpful hints.
Return to Newsletters
|
