One of my duties at work is managing shipping printouts, such as labels and delivery notes. And, a common task that I have had lately is printing out test labels or performing reprints, so I decided to write a post about the procedure I have been using in SAP to accomplish this.

First, I use the transaction SE16 (SAP data browser) to view the table NAST. I believe that the table NAST simply contains the output from messages. On the selection screen I enter the Application (KAPPL), which for me is normally either V2 (shipping) or V6 (handling units). Next, I select the Message Type (KSCHL), which is normally something like ZLnn. Then I am shown data that fits that criteria. The third column (OBJKY) on the entries screen shows delivery numbers (for V2 types) that have messages meeting my criteria. So, I copy one of the latest delivery numbers for the desired message type.

Next, I go to transaction VL71 (for V2 messages - it would be VL74 for V6 messages), which is to display output from deliveries. I use the default sort order of 01, enter 2 (repeat processing) for the processing mode, and then paste the delivery number from the previous step into the delivery box. F8 executes the transaction and gives me a list of message type. I check the message that I want to reprint and hit SHIFT-F5 (Edit - Print Default) to select the printer. Hit SHIFT-F2 or click the execute button, and the prints will be sent. I could also use the print preview button to save paper, but bar codes do not render properly in the preview.

I have come to the conclusion that many times business owners and managers unwittingly allow software programmers to determine their long-term technology strategy. Programmers are hired just to write software, so how could they be steering a business' technology strategy?

The explanation is really quite simple. Depending upon how the software is written and what tools are used in the process, it could be establishing some deep rooted dependencies. And, it seems that programmers are often given too much leeway in selecting their tools.

If a program is written with the intent of being installed on client computer, then there would be an obvious lock-in to the platform for which it was designed. It makes sense that if a program is written for Windows XP, then it will not run on OS X. Most managers would say that is acceptable since they must be currently using the system for which the software was designed. But, it has been my experience that software is always around for longer than the original designers intended. This was a major factor in the scare leading up to Y2K.

Furthermore, as people become more accustomed to using mobile computing platforms, their use will become more widespread and corporate software will be expected to become mobile as well. In my opinion this represents the most likely scenario where a company would want to use it's software outside of the platform for which it was designed.

There are ways to avoid platform dependencies. A cross-platform language, such as Java could be used. Or, as is becoming more common, application servers can be used. The most common application servers are web application servers. In a previous post I explained why I felt web applications represent the future of software applications, and more progressive managers are already looking to exploit web applications. But, just taking advantage of web applications does not guarantee that your software will be client independent.

I was recently talking to people from a company where they had two major web applications projects underway. One project was based on LAMP (Linux, Apache, MySQL, PHP), and the other project was being built with Microsoft based technologies. The LAMP based project was great, there was a LAMP server that the company had to support, but other than that there was no requirements. The application could be run from any modern web browser, on any platform. The Microsoft based project was also very good, it had a great interface and there were Microsoft servers on the back-end. But, there was one major problem that I saw. The application had to be run inside of Internet Explorer. So, with this project the company was paying a huge extra expense for the Microsoft technology, and they were locking themselves into using platforms that had Internet Explorer.

This situation is not a big deal now because Microsoft Windows is so ubiquitous. But, it severely limits the company's future flexibility. Ideally, a company could make all of their applications web-based, and then purchase dirt cheap netbooks with Linux on them. All they would need is a computer capably of surfing the web, and they could save a lot of money over time. But, because of the Internet Explorer requirement the company will forever be forced to maintain some sort of Microsoft licensed software.

The moral of this story is that you have to be careful with giving contracted programmers too much room to be creative. And, I am using the term programmers, but I also mean analysts and architects as well. Think of your strategy, think of the impact of client-side dependencies, and don't work with programmers who play down this issue.

Since I have had a lot of traffic going to my page on business cost saving ideas I thought that I would share other cost saving activities I have seen happening where I work. Our division has always pushed for generating and utilizing ideas from all levels within the organization, and the president is pushing everyone to come up with two cost saving ideas a month. He has set a goal that everyone in the company save two dollars a day. Our organization was lean to begin with, so now we are taking extraordinary steps to reduce overhead costs.

I work in IT, so I mostly see things that relate to information technologies. One big item that has been cut is printing. First, we removed almost all the color printers. Then, we started trimming down the number of monochrome printers. We have also switched to draft mode printing in order to save a small bit of toner on each print. And, I think that we have gone so far as to ask people to shake the toner cartridges to get every last bit of toner out of them. We also have reduced the number of business copiers that we have, which was a bigger savings since most of those fell under maintenance contracts.

Another huge expense is communications. The companies cell phone bill is in the range of hundreds of thousands of dollars, and they would like to at least cut it in half. We already have negotiated rate plans, so the next step was to simply reduce the number of phones. The first milestone was the elimination of all the floater and spare phones. After that each manager was asked to evaluate his employees' phone usage and take back phones from people who don't need them on a very regular basis. Now very few people still have corporate cellphones, not that the cellular companies should worry, as I have said before that reduction is apparently being offset by workers buying personal phones.

But, there are still quite a few people with Blackberrys. So, that is now one of our larger communication expenses, excluding the items that are hard to reduce such as dedicated lines. The company was always very strict on who would qualify for a Blackberry, so now comes the tough decisions. If the company pulls Blackberrys back, then they won't be able to get as much work from employees. But, it is tough to value that against the hard costs of paying for Blackberrys. I have suggested that our data security policy be loosened during these tough economic times so that the company may be able to have it's cake and eat it to. Currently, anyone who turns in their corporate Blackberry has no other way of accessing that type of data on the go. Even if an individual decides to buy his own smart phone, it is against our security policies to forward corporate communications to personal devices. Sure, an employee could ignore the policy and just do it. But, who is going to risk their job in order to help the company, that is a crazy predicament.

Moving to the topic of software, we are trying to reduce the amount of software that is installed. At first look, this may seem crazy, but so is life at a gigantic global company. The company purchased licenses for software, and most commercial software does not have associated maintenance fees, so there should be no ongoing costs. Right? Well, in our case the parent company in Germany manages all the software licenses, which itself doesn't make sense since the cost of software in Europe is frequently higher than it is in the US, but that's another topic. In any case, since the software is payed for at headquarters, they send us monthly bills for usage. Each software has a monthly fee for each installed copy. If an employee installs a piece of software for one day, his department will be charged for a month of usage. In order to reduce the amount of money that we are paying to headquarters we are trying to remove as much unused software as possible. Of course this could have a funny side effect. The parent company in Germany, who is feeling more financial pain than we are, may end up further in the hole if they can't act as quickly as we do to reduce what their overhead on this software. So, in the end, they may end up just charging us a higher monthly rate for software.

Our company also has larger software packages that require ongoing maintenance fees be paid to external companies. For these packages we are attempting to reduce the bill by dropping to lower levels of service. We may have server operating systems with service level agreements providing for 4 hour resolution windows, but because are systems are already redundant we may be able to get away with accepting a 24 or 48 hour resolution windows. This could drastically reduce our maintenance bills.

Our company is also doing everything it can to reduce energy consumption. The IT department has helped work towards this goal by finally utilizing the computers' inherent power saving features. We also encourage users to physically power down monitors and computers when they are not using them.

In general, we are doing everything we can do keep our money under our roof. The company fired the external cleaning company and now has internal employees perform the basics of that work. In IT we are drastically reducing the number of consultant hours used, which means that existing staff will have to learn some more varied and specialized skills. It also means that the business will have to go without some of the improvements it would like to see.

Those are the big actions that I can see occurring now, as I learn more I will write about what I learn.

This weekend I finally had a chance to migrate the nortonsoccer.org domain from the old static hosting provider over to Google Sites. And, I am quite pleased with the results. Now, the Norton Amateur Soccer Club is using the full compliment of Google services. And, since they are a registered not for profit organization, Google generously donates all of the services for no charge.

There were a couple of reasons that I wanted to move the website, the most important of which was that I wanted the content to stay more up to date. Previously, changes would have to be submitted to me and I would update the site as soon as I had time. Now, authorized members of the organization can update the website on their own.

The new website now has some great new features. There is now a site search that will allow visitors to quickly search the site to find specific content that they are looking for. There is also an embeded calendar, which functions much better than the previous bullet list of important dates. And, each of the sponsors now has their own page on the site, so the board could add additional information about the sponsors and provide them with greater value for their sponsorship dollars.

The new site did lose a few features, but through Google Analytics I knew that these features were not really being utilised much. One of those missing features is the photo gallary, but this will be coming back online once I set the club up with a Picasa web account.

Along with setting up the new website, I also set up the club to take advantage of Gmail for their domain. Now each of the board members has their own email address (e.g. president@nortonsoccer.org), and when people leave the board the new members should be able to quickly pick up where the last left off.

Finally, I am also quite proud of the logo which I designed. The previous logo, which I also designed, did not work well with the new layout, so I needed a new one. It's a small thing, but considering that I am a technology person and not a graphical designer, I think it turned out quite well.

This was a great project for me, not only did it improve the Norton Amateur Soccer Club's technology, but it also gave me the opportunity to learn more about Google Apps. From my experience setting all of this technology up for NASC, I have come to believe that many small organizations and businesses could greatly benefit from these services. There seems to be a great potential to reduce an organizations technology costs while actually improving the level of service.

This series of articles has been sitting as draft for a while, I guess I've been too busy to proofread it all. But, since I am on to another SAP training class, I thought that I should get these published.

I was in SAP training course BC400 this week to learn SAP ABAP. It was taught by Peter Walters, who seemed to have a thorough understanding of the subject mater. The course was a good introduction to the ABAP language and all of the various tools, or SAP transactions, that are required to write ABAP. In all I took about twenty pages of notes and I wanted to post the highlights here so that I will be able to refresh my memory once I actually need some of this knowledge. I am not an ABAP expert, so the information here could have some inaccuracies. If you need precise information I suggest visiting help.sap.com or sdn.sap.com.

• Introduction
• ABAP Language (Part 2) (Part 3)
  

As with most technical SAP classes, the instructor began by explaining SAP's three tiered architecture. I relate the three tiered architecture to the MVC (model-view-controller) paradigm, it is just on a larger scale. SAP holds the model in database work processes on the database server, the view in the SAPGUI on the clients PC, and the controller is the ABAP programs that we will be writing on the application server. Database access is abstracted on the application server by the use of SAP Open SQL, which is converted to native SQL for the various databases that SAP supports.

After giving an overview of how SAP systems are setup, the next basic SAP topic is that of mandants. Everyone who uses SAP is familiar with mandants, but most people have no clue what it really means. Mandants were originally used for separating companies on time sharing servers. Two companies could use the same server to run SAP and mandants would keep their data completely separate. This seems a little dated, but technology is moving back towards time-sharing via cloud computing, so it may be more useful again.

Every client specific table has MANDT as it's first column, which contains the mandant. Development objects are client independent so that they can be used across all mandants, and thus have no MANDT.

Development objects, such as packages are kept in the repository, and you can access the repository information system using transaction SE84. But, if you want to see the hierarchy for an application you would use SE81, and if you want to see the data dictionary you would use transaction SE11. All of these transactions are generally required for writing ABAP programs, though the main ABAP programming transaction is SE80, the object navigator.

Like everything in SAP, writing and storing ABAP programs is very structured. Generally, you can't just start writing a program. First, a package is created from a change request, and inside of the package is where the SAP applications are written. There are three types of packages. The structure package is for organizational purposes and contains other packages. The main package falls under a structure package and contains standard packages. Standard packages are where actual programs are created and stored. The program code is stored in the database when you click save in SE80, then it is compiled into executable code when you click the activate button. Therefore, a program cannot be run without first being activated. Furthermore, a program requires a transaction code in order to be of use to users.

An ABAP statement always begins with a keyword and ends with a period. There is a little quirk caused by using the period as a statement terminator, floating point numbers must be enclosed in single quotes as if they were strings. Otherwise the period would be treated as a statement terminator and you would receive an error. This was probably not a big issue when the language was originally developed since in Germany commas are used as the decimal separator.

In ABAP, any line that has an asterisks (*) in the first column is considered a comment line. To place a comment at the end of a line you must use double quotes ("). Multi-line comments are not supported.

ABAP is a typed language, meaning that variables and their types' must be declared before they can be used. There are elementary or simple variables, structure variables which contain simple variables, and internal tables which contains structure variables.

Since keywords are determined by position there is no technical restriction on using them as variable names, but best practices dictate that this should not be done. The only restriction on variables is that they cannot be longer than thirty characters. SAP has ten standard variable types. Of these types there are two categories: complete and incomplete. Complete variable types are completely defined by themselves, whereas incomplete variable types need some additional information to be properly defined. Incomplete variables must have some sort of specification on the length of the variable.

• D -- an 8 character date (complete)
• T -- a 6 character time (complete)
• I -- a 4 character integer (complete)
• F -- an 8 character float (complete)
• STRING -- a string of characters (complete)
• XSTRING -- a hexadecimal string (complete)
• C -- characters (incomplete)
• N -- numeral (incomplete)
• X -- hexadecimal (incomplete)
• P -- packed number (incomplete)

It is possible to define local variable types in an ABAP program, but these are only valid within the program in which they are defined. The data dictionary (transaction code SE11) must be used to define custom variables types if a broader scope is desired. To define a local type within an ABAP program the following syntax is used:

TYPES my_new_type TYPE C LENGTH 5.
TYPES my__type TYPE P LENGTH 3 DECIMALS 2.

The default value for numeric variables is zero (0), and the default for character types is space ( ). Strings do not have an initial length, so the default value is not space. To set a default value the value keyword is used, this is shown in the following constant declaration. Below that are two variable declaration statements.

CONSTANTS my_const TYPE STRING VALUE 'my val'.
DATA my_float TYPE F VALUE '12.34'.
DATA: my_integer TYPE I VALUE 1234,
my_characters TYPE C(3) VALUE '123'.

When making variable assignments in ABAP, SAP tries to convert the source type into the destination type. SAP has 62 conversion rules that it follows when doing this. There are two methods for making variable assignments. In both of the examples below variable_two is assigned to variable_one:

MOVE v_two TO v_one.
v_one = v_two.

In order to reset a variable to it's default value ABAP provides the CLEAR keyword.

CLEAR my_variable.

For arithmetic expressions ABAP provides the COMPUTE keyword, however it's use is optional. Compute supports the following operators: +, -, *, /, ** (exponentiation), DIV (division without remainder), MOD (remainder of division).

COMPUTE my_v = another_v * 5 / 100.
my_v = another_v * 5 / 100.

SAP ABAP supports modularization by implementing subroutines and functions, and since it was modified to be object oriented it also supports methods. Subroutines are local to the ABAP program (technically they can be called form other programs, but this is only for backwards compatibility and should not be used), while function modules are shared. Methods can be either local as part of a local class or shared as part of a global class.

A subroutine has the following format,

FORM form_name.
(actions)
ENDFORM

and is called thusly.

PERFORM form_name.

The format above is simplified, and not very useful. Most likely the subroutine will need to have variables passed back and forth, below is the extended syntax.

FORM my_form
USING
value(variable_one)
CHANGING
value(variable_two)
variable_three.
(actions)
ENDFORM.

In the above example variable_one and variable_two are passed by value, whereas variable_three is passed by reference. The USING section is for read-only variables, while the CHANGING sections is for variables which will be modified.