Read 126web.book text version

10 Technical Implementation -- Software

This chapter describes the software you must use in order to carry out the business processes described in this book. In addition to standard SAP software, you need a number of other software products as well. First, you must integrate the mobile devices to the SAP system. The best way to do that is to use SAP WebConsole or its older brother: SAP Console. But even today, offline solutions are commonly used in warehouses, so it's worthwhile to discuss the generally required software components for this kind of solution here as well. Then we'll provide you with a systematic description of the available options for enhancing the standard SAP system by using user exits, Business Add-Ins (BAdIs), or custom transactions. In this context we will once again refer you to the custom developments described in the individual chapters of this book. Another important topic -- particularly in a warehouse -- involves label printing, which has a rather complex software-related aspect in addition to the hardware issues described in Chapter 9, Technical Implementation -- Hardware. Finally, this chapter will provide you with an overview of the bar code standards that are commonly used in warehouses.

SAP Console is a server component that is independent of the SAP GUI. It is only delivered with the SAP GUI for the sake of guaranteeing convenient distribution/installation. However, SAP Console has in fact been unnecessarily installed on numerous clients and not just on a few servers. Using the new installation (NWSAPSetup), which is available since SAP GUI for Windows 7.10, you can now very simply add other "products" to an existing installation server. For this reason, as of Release 7.10, SAP Console is no longer delivered with the SAP GUI. Instead, a separate installation for the SAP Console is in development. This will be available during the course of 2007. This note will contain the exact dates, once these have been defined. SAP WebConsole converts the SAP GUI data provided by the SAP server into HTML code that can be displayed on the respective devices by using a browser application. In the opposite direction, the data that is entered through the browser is converted into the display format of the SAP GUI. Alternatively, the display of SAP GUI data in HTML format could also be attained by using Internet Transaction Server (ITS). ITSmobile replaces SAP WebConsole

10.1 Online Connection via SAP WebConsole

Installing SAP WebConsole SAP provides SAP WebConsole as a component of the SAP GUI. At first glance, this seems to be unusual because from the point of view of the devices, the software is server-based. As a matter of fact, SAP changed that as of SAP GUI Release 7.10. OSS Note 1017827 reads:

As of SAP NetWeaver Release 7.1, SAP WebConsole (in contrast to SAP Console) is no longer supported. It will be succeeded by ITSmobile, which is based on Internet Transaction Server (ITS), SAP's standard technology for Web-enabling applications on an ABAPDynpro basis. You can find further information on this in SAP Notes 1070064 and 1070064.

www.sap-press.com 11

10

Technical Implementation -- Software

Basically, all you need to install SAP WebConsole is a normal PC. The hardware requirements depend on the number of mobile devices that are connected to the system. However, because SAP WebConsole is supposed to establish a connection between the SAP server and the mobile devices, it makes sense to install the software on a server, for instance, on an SAP NetWeaver Server. Differences Between SAP WebConsole and SAP Console Originally, SAP had developed the predecessor -- SAP Console -- for the integration of scanners that have textbased displays. But SAP Console is not able to display HTML code. Meanwhile, scanners with text-based displays have almost completely disappeared. However, you can use SAP Console for graphical displays, the only restriction being that the data can be displayed only in lines. But in many cases, this option is absolutely sufficient for SAP applications. Because of the use of colors, link smoothing, and contrast selection, the readability has been significantly improved compared to the text-based displays. Of course, the Web-based display is even better, but its installation is more complex, as we will see in the following sections. Browsers on the Devices Whereas you can install SAP WebConsole without any problem, selecting a browser for the respective device is a rather complicated task. By default, Windows CE scanners use Microsoft Internet Explorer (IE). Unfortunately, however, IE has two major disadvantages: The mapping of the F keys differs from that in SAP applications. Browser functions that aren't needed can nevertheless be accessed. The following sections describe various different

usually enter the mouse commands through the touchscreen by using a stylus. However, a warehouse is a working environment in which the speed and user-friendliness of applications are essential. A touchscreen that is too small to be operated by a person wearing gloves would be useless. Neither is a stylus the appropriate tool to use with this kind of clothing. Consequently, warehouse workers usually prefer using F keys to using mouse commands. Thus, full of enthusiasm and having installed your new scanner, when you decide to use the (F1) key in a mobile SAP transaction in order to save a posting, you will experience an unpleasant surprise: (F1) does not conclude the transaction at all. Instead, it opens the IE help. And so, what do you do then? Before we introduce alternative browsers in the next section, we first want to describe a possible solution to this problem when you use IE. What you need to do is map the (F1) command with a different key combination that is unknown to IE so that it forwards this command directly to SAP WebConsole instead of processing it by itself. However, because we want the user to continue to press the (F1) key, we must manipulate the key mapping of the scanner. Doing so enables us to use (F1) to save data instead of calling IE's help function. Depending on the manufacturer of the scanner, the key mapping process can vary. We have successfully carried out the process for Intermec scanners using a file that was provided by the vendor. Browser Functions If you use IE on a terminal device, you can, of course, use all other functions of the browser as well, such as saving files, favorites, calling URLs, and so on. However, it often happens that this is not what is wanted at all. Companies want their scanners to be used only for warehousing transactions and not to make available any other operations. To a certain extent, IE allows you to deactivate or hide functions. However, you cannot entirely prevent people from using the other browser functions. To solve this problem, some vendors of terminal devices have developed alternative browsers in which you can deactivate the usual browser functions and protect the settings using a password (see Table 10.1). The drawback of these solutions is that you usually have to pay for the software licenses for these browsers.

approaches to eliminate these disadvantages. F Keys The majority of standard SAP transactions can be controlled via the mouse or by using F keys. Although there is no mouse connected to the terminal devices, you can

12 © Galileo Press 2008. All rights reserved.

10.2

Alternative: Offline Solutions

Vendor Naurtech Symbol

Device CETerm PocketBrowser

Key Mapping Yes Not supported, but possible via Wavelink emulator Possible via handheld software (depending on the device) Possible via handheld software (depending on the device) Not needed

Menu Bars Yes Yes

Scroll Bars Yes (single) ?

Display Yes No

Lock Yes Yes

Intermec

iBrowse

Yes

Yes

No

Yes

Microsoft

Internet Explorer

No

No

Yes

No

Synactive

GuiXT Mobile

Not needed

Not needed

Yes

Table 10.1

Comparison of Browsers for Mobile Devices

Intermec iBrowse Let's take a closer look now at Intermec's iBrowse as an example of a vendor-specific browser. Intermec iBrowse allows an administrator to control which pages a user has access to. This means that a user can only access the pages that are made available on the Start menu. In addition, all status bars can be completely hidden in order to provide more space for displaying information that's actually required. If necessary, the administrator can even install a password-protected deactivation of the closing command so that the user cannot exit the browser. This way, the browser can be turned into the GUI for the user. No other functions than the ones that are required can be accessed.

connection can be guaranteed. Commonly used examples of this are mobile sales and plant maintenance. However, with regard to the subjects treated in this book, we can safely assume that you work on your company's premises and can therefore provide and control an online connection. For this reason, we only want to briefly touch upon the offline solution as a possible alternative. Each offline solution must contain the following components: A local application on the terminal device A synchronization program between the terminal device and the server Figure 10.1 illustrates the entire process. Local Application on the Terminal Device

10.2 Alternative: Offline Solutions

This section provides an overview of the different concepts of offline solutions including the respective local applications, synchronization, and error handling. Overview We use preprinted storage unit (SU) labels for the assigned (external) number range, which allow us to ensure that no SU number is repeated and that the number range is adhered to. Up until a few years ago, this concept was the only possible way to implement mobile applications. For this reason, it has been well developed and can be used with different technologies. Even today, offline solutions are used wherever no permanent online

The terminal device runs a complete, independent application. This application can be implemented using C# or Java, for example. Whereas the strengths of C# lie in the design of visual components, Java has a better developer community and provides a greater number of available open source libraries that you can use in your developments. Java Swing GUIs can no longer be distinguished from C# GUIs. The free-of-charge Eclipse development environment contains very convenient GUI design tools. Moreover, Java applications are always platform-independent. You can also find older applications that are based on C++ or Visual Basic. Prior to the synchronization process, the recorded data must be temporarily stored. This usually happens in a database. If the data quantity is small, you can also use a

www.sap-press.com 13

10

Technical Implementation -- Software

Scanner Mobile Devise Database

ABAP/4 Dataset

SAP Transaction

Posting

FTP Tool SAP Server

SAP Database

Figure 10.1

Synchronization Process in Offline Solutions

file instead of a database. Saving the data to a file requires less installation and programming work than saving data to a database. On the other hand, using a database increases the performance of the synchronization process, provides better standardization, and thus makes it easier to enhance the interface. The offline application and each updated version must be installed separately on each terminal device. To reduce the installation effort, many vendors offer additional software. Synchronization Program The synchronization of data between the terminal device and the SAP server can occur on the server or on the client. A server-based synchronization program is typically implemented in ABAP/4. Every time the mobile device is placed into the charging station, the data is transferred to the SAP server via FTP, where the ABAP/4 synchronization program can access the data. Moreover, the opposite direction can be used to transfer data to the mobile device, such as updated inventory data. The data that is imported into the SAP system is formatted and converted into SAP posting records. Traditionally, Call Transaction or batch input sessions are used to post the recorded data. Meanwhile, however, there are also Business Application Programming Interfaces

(BAPIs) available for many transactions, which increase the efficiency of the postings and reduce their errorproneness. A client-based synchronization program is part of the application that runs on the terminal device. The application detects that the device is connected with the SAP system and calls Remote Function Call (RFC) modules in the SAP system. Alternatively, the data can also be exchanged via Intermediate Documents (IDocs). If there aren't any appropriate RFC modules or IDoc formats available, you may have to develop an additional ABAP application on the side of the SAP system. Error Handling In principle, you must clearly define the way in which incorrect postings should be handled. In an offline solution, it can always happen that a posting that could be saved locally without any error cannot be processed in the SAP system. One of the causes of this is that at the time when the (local) posting was made, the last dataset from the SAP system was not available. Examples: Inventory is supposed to be put away, but the storage bin was already used by someone else. Inventory is supposed to be removed from stock, but someone else has already posted it earlier. A sales order is supposed to be entered, but the customer has been locked.

14 © Galileo Press 2008. All rights reserved.

10.3

Extensions to the Functionality

Especially the first two examples show that an offline solution is not ideal in a warehouse since it will always involve a certain amount of extra work for the correction of errors. Inventory data, in particular, is continuously subject to change. Here, a real-time check using an online application is the much better solution. The third example above originates from a mobile sales application. In this context, errors occur less frequently. Sales orders that are posted by different employees must first be considered independent of each other and can therefore be posted offline. However, the situation is different if you want to directly promise confirmation dates to the customer. In that case, conflicts arise immediately if multiple customers receive confirmations for the same product that is not available in an unlimited number. However, it would go beyond the scope of this book to describe all the things you need to know and how to proceed in this context. In an SAP system, errors are usually handled on the side of the server. Postings via Call Transaction generate so-called error sessions that can be postprocessed centrally using Transaction SM35 (Batch Input Monitoring). In this context it is important that you use a meaningful naming convention for the error sessions because SM35 references all error sessions in the entire system so that a specific selection based on the session name is inevitable. Postings via RFC modules do not include error sessions because it would involve too much work to create the batch input logic for such error sessions. For this reason, it is useful to temporarily store the data that is transferred from the terminal device in a Z table prior to the actual posting. Then, all postings that were successful are either marked with a "Completed" flag in the Z table or deleted immediately. This way you can repeat postings that contained errors. The posting program must provide a comprehensive log that includes a description of the error messages, which makes it easier for you to correct the errors. If the synchronization program runs on the client, you can, of course, view the errors right away. This is particularly advantageous because the user of the mobile device (the sales employee, for example) wants to make sure that his or her postings were successful so that they can react directly and clarify what was the cause of an error.

10.3 Extensions to the Functionality

User Exits or New Implementation SAP offers numerous user exits for the mobile transactions. However, if extensive modifications become necessary, you should first ask yourself whether it does not make more sense to completely develop a new transaction. The effort involved in implementing user exits and the associated integration into the logic of standard transactions must not be underestimated and can quickly outdo that of a new implementation. Available User Exits The Warehouse Management (WM) environment predominantly contains the "classic" user exits, which must be maintained using Transaction CMOD (Project Management of SAP Enhancements). For standard mobile

transactions, SAP specifically offers the extensions listed in Table 10.2.

Exit Name MWMRF001 Short Description RF: Manipulate Display Material short text Explanation MWMRF001 enables you to control how the 40character material short text should be shortened so that it fits into the small screens of the mobile transactions. MWMRFCOD allows you to disable the function codes in the delivery header. MWMRFDLV enables you to manipulate the delivery according to user criteria. MWMRFPRT allows you to implement the printout of shipping labels from within the mobile transactions (see Chapter 6, Loading and Shipment). MWMRFSSG enables you to manipulate the sorting process in the queue in system-guided putaway or picking (see Chapter 8, Standard Customizing).

MWMRFCOD

Extension for disabling function codes

MWMRFDLV

Select delivery by user criteria

MWMRFPRT

Printing extension

MWMRFSSG

User exit for sorting transfer orders (TOs) in systemguided radio frequency (RF) transaction

Table 10.2 User Exits for Mobile Transactions

www.sap-press.com 15

10

Technical Implementation -- Software

Exit Name MWMRFUP

Short Description Customer-specific, general pushbutton called from screen

Explanation MWMRFUP allows you to control which transaction should be called using a customer-specific pushbutton.

digm of data consistency. By no means should you implement direct database updates "on the side," as it were, as that can easily violate the data consistency! Moreover, using standard function modules is permitted only if the function modules are RFC modules, that is, if they can generally be called remotely. Calling any internal function modules directly is as risky as a direct database update! Table 10.3 provides a list of some "secure" function modules that you can use to post the different business processes.

Task Confirmation Creation of TO for transfer requirement (TR) Goods receipt (GR) posting for delivery GR posting for purchase order Goods issue (GI) posting for delivery Creation of TO for delivery Packing/Unpacking Function Module L_TO_CONFIRM L_TO_CREATE_TR

Table 10.2 User Exits for Mobile Transactions (cont.)

In addition, you can complement each screen of standard mobile transactions with your own fields. You can then implement the data supply and customization check of these fields in a screen-specific user exit. However, this procedure is only useful if the modifications are less complex. For major customization projects, you should directly use your own, custom transactions, as this procedure provides a higher degree of flexibility with less work. Apart from that, user exits from other modules can also play a role in an integrated SAP system since they can indirectly affect the mobile transactions. For example, in Chapter 6, Loading and Shipment, we implemented the time control function for IDoc dispatch via a customerspecific condition in the message schema. The classic SAP extensions based on CMOD have been replaced by BAdIs. The purpose of BAdIs is similar to that of CMOD extensions; however, they are coded as definitions in ABAP Objects and can therefore be used in a much more flexible way. You can activate a BAdI by creating an implementation of the definition (Transactions SE18/SE19). It is possible to create and activate multiple implementations simultaneously. If the BAdI definition is based on a filter, you can use filter values in Customizing to assign implementations to specific business processes. The only BAdI that's available in SAP 4.7 Enterprise is the filter-independent definition, LE_WM_RF_QUEUE, for the determination of queues (see Chapter 8, Standard Customizing). New Implementation of RF Transactions A new implementation of RF transactions provides a higher degree of flexibility regarding the GUI design and is often easier than the adaptation of standard transactions via complex screen control logics. However, you must make sure that you post all transactions correctly and in compliance with the SAP para-

WS_DELIVERY_UPDATE_2

BAPI_GOODSMVT_CREATE WS_DELIVERY_UPDATE_2

L_TO_CREATE_DN BAPI_HU_PACK (only with full handling unit management -- HUM)

Table 10.3 Function Modules for Postings

If no function module is available (such as, for instance, for packing without full HUM), then there is no other way but to implement a complex Call Transaction programming. In that case, it may even make sense to customize an existing standard transaction via user exits. In real life it often turns out that the mobile transactions provided by SAP do not contain the required functionality. To a certain extent, this depends on companyspecific requirements; however, the functions that are missing are not very unusual and are commonly required in the industry. In any case, you can solve this problem either by implementing the user exits described above or by creating an entirely new transaction. The latter makes sense if you want to change the screen sequence of standard transactions.

16 © Galileo Press 2008. All rights reserved.

10.4

Label Printing

You can find an overview of the user exits described in this book in Appendix A of the printed book.

pret and implement the specific commands sent to it by a program. Because this "machine-based" way of coding is rather tedious, it is common practice to use a specific label design program provided by the printer vendor, which needs to be purchased as well (see also the section

10.4 Label Printing

If you use a scanner, you will also have to use a printer. In this context it is not relevant whether you want to print a traditional EAN128 bar code or a fancy special bar code, such as UPS Maxicode. In principle, printing a bar code does not differ from printing a text, the only difference being that a different character set and font is used. However, in contrast to printing texts, the printing of bar codes requires that the right font be produced by the printer hardware. And that is exactly where the problem begins. Not every printer that's available on the market is prepared to print bar codes. This is not a technical problem, but rather a commercial one. Because bar codes are hardly used by private individuals, the prices for printing bar codes can be set at a much higher level than those for printing "normal" characters. Hardware: A Strategic Decision At the start of a project, you must decide whether you want to continue using the existing printer hardware or if you want to purchase new label printers. Of course, purchasing new hardware incurs additional costs. However, these costs are compensated by the fact that you can save a significant amount of costs during the project if the new hardware simplifies the installation and form design -- at least for small quantities of goods. The basic problem is that SAP applications must trigger vendor-specific printer commands. Unfortunately, there is no general standard in place, even though each vendor tries to sell "its" own standard as the generally accepted one. Hardware-Based Bar Code Generation In order for you to enable printers to print bar codes, most of them must be equipped with an additional module, which must be purchased separately. However, the main problem is the communication between the SAP system and the printer. The printer must correctly inter-

"Label Design Using SAPscript"). Software-Based Bar Code Generation Generating a software-based bar code means that the code is transferred to the printer as a graphic, which then only needs to be printed out. The advantage is that the printout can be formatted regardless of the hardware used. The disadvantage is that the only solution that's currently available (TEC-IT) requires the use of SAPLPD, which means that the printing process must be carried out via a Windows PC. For printers that are directly connected to an SAP server, this is not a viable solution. However, according to TEC-IT, a server-based solution is currently being developed. In any case, TEC-IT represents a very good testing tool because it enables you to generate and save printouts in PDF format. Moreover, we also think that TEC-IT is a good alternative for professional warehouse environments, which should be taken into consideration. Just compare the additional licensing costs with the increase in productivity regarding the development of forms. Label Design Using SAPscript Concerning label printing, the printer hardware you use significantly affects the installation and form development. For this reason, we will now provide you with a brief overview of different hardware vendors' printer hardware with regard to their use in an SAP system. In OSS Note 135894, SAP provides an overview of the specific characteristics of the different vendors and printers. For each vendor, SAP refers to an associated OSS Note. The list is updated continuously. Table 10.4 shows the current status (valid as of February 21, 2006).

Printer Type Avery TTX 450 CAB Apollo 2 DatamaxI-4604 OSS Note 136846 137431 490295

Table 10.4

Printer Types and Associated SAP OSS Notes

www.sap-press.com 17

10

Technical Implementation -- Software

Printer Type IBM 4400 Intermec EasyCoder 501 XP Intermec EasyCoder 4420 Printronix T3204 SATO CL408 SATO MR410e TEC B-572-QP Zebra Z4000

OSS Note 390473 137069 183777 137372 177807 368131 137614 179534

the SAP system without using any additional software (see OSS Note 750002). Background: SAPscript and Print Controls You can generate a bar code from within an SAPscript form by using print controls. A print control represents a sequence of nonprintable special characters that define, for instance, the position, size, or coding of a bar code before the actual content data of the bar code is sent to the printer. The problem here is that each hardware vendor uses different, hardware-dependent print controls for each specific purpose. In order to avoid having to adjust the forms that were created using SAPscript with each modification of the

Table 10.4

Printer Types and Associated SAP OSS Notes (cont.)

Each OSS Note listed here refers to exactly one vendorspecific PC program for the creation of labels (see Table 10.5). After creating a draft label with this program, the draft must be uploaded to the SAP system in a more or less difficult manner where it can no longer be read in plaintext.

Printer Vendor Avery CAB Datamax Software Jetmark 32 EASYLABEL SAPscript-ITF Printer Code Template Codesoft 6.0 LabelShop PRO Codesoft Pro Dynamic Publisher PCLabel Gold Software Vendor Avery Dennison Tharo Systems BarTender

printer hardware, SAP has mapped the hardware-specific print controls in a very elegant way in the system, namely, via a multilayer configuration. In the SAPscript form, a character format is defined for the bar code, which references a system bar code. The system bar code is stored in a configuration table (Transaction SE73, SAPscript Font Maintenance), and it initially contains only general attributes such as the height and width (see Figure 10.2). As the name suggests, the system bar code is applied across an entire system, which means it is independent of the printer and does not contain any printer-specific print controls. The hardware-specific connection to a print control is established using a printer bar code. Printer bar codes must be maintained for each specific device type. The device type is an attribute of the printer. For each system bar code, you must create a printer bar in conjunction with the device type and store a specific print control (see Figure 10.3). SAP provides the respective device types and print controls for the various hardware vendors for download from the SAP website. Printer bar codes must also be stored in Transaction SE73. This enables you to develop the SAPscript form irrespective of the hardware because you only need to store system bar codes. If you send the same form to a different printer with a different device type, the SAP system automatically uses the print controls from the printer bar code that correspond to the other device type. This logic is illustrated in Figure 10.4.

IBM Intermec Printronix SATO

Teklynx International Intermec Teklynx International Dynamic Aviator

TEC

Image Computer Systems Zebra

Zebra

BAR-ONE

Table 10.5 Printing

Overview of Printer Vendors and Software for Bar Code

Label Design with SmartForm for Zebra A real innovation is the integration of the Zebra printer language in SAP SmartForms. For the first time it is now possible to carry out a direct What You See Is What You Get (WYSIWYG) form development for a label printer in

18 © Galileo Press 2008. All rights reserved.

10.4

Label Printing

Figure 10.2

System Bar Codes: Printer-Independent Parameters

Figure 10.3

E73: Hardware-Specific Print Controls Are Maintained for a Combination of Device Type and System Bar Code

www.sap-press.com 19

10

Technical Implementation -- Software

provides a high degree of reading accuracy and can be easily generated.

SAPscript Form System Bar Code Printer Bar Codes

For new SAP applications, you should use Code128 unless the bar code leaves the company and the recipient requires you to use Code39. But that no longer happens very often. Even the German Association for the Automo-

Print Control

Device Type

tive Industry (VDA) and the pharmaceutical industry have switched from Code39 to Code128. Linear Bar Codes Linear bar codes represent an old way of coding, which is predominantly used in the retail industry. Here, only the item number is coded, for instance, as EAN-8 or EAN-13. The corresponding code that's used in the United States is the UPC number. Two-Dimensional Bar Codes

Printer

Figure 10.4

Determination of Print Controls from Type of System

Bar Code and Device

10.5 Bar Code Standards

For printing out bar codes, there are numerous so-called symbologies available, that is, interpretations of fonts or symbols. The following sections describe the codes that are commonly used in the warehouse and shipping areas. Code128 Code128 is defined in the ISO/IEC 15417 standard. This code is primarily used as a basis of EAN128. Whereas Code128 represents a purely technical font, EAN128 defines an additional unique format for the content. A data prefix indicates whether the coded information represents, for example, a material number, a batch, or a reference number. Of course, you can use Code128 for any other content as well. In warehouse-internal applications, the data content to be used is entirely up to the enterprise which can freely define it. The situation changes when the bar code leaves the company premises and must be read on the recipient's side. Code39 Code39 is defined in the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 16388 standard. This code is older than Code128 and consists merely of numbers, uppercase letters, and seven special characters. On the other hand, it

Compared to the one-dimensional bar codes described above, two-dimensional bar codes have a big advantage when it comes to data content and error-proofness. In a two-dimensional bar code, up 25 percent of the entire code can be destroyed without affecting the readability. However, this holds true only for the "real" matrix bar code, which is contained in arrays. In addition, there is the "stacked" two-dimensional bar code, in which the individual bars may contain gaps, whereas the entire bar code looks like a one-dimensional bar code. A major disadvantage is that the printout of twodimensional codes requires more sophisticated hardware or software equipment. For this reason, these bar codes aren't used much in companies yet. Here's a list of some sample areas of application for two-dimensional bar codes: Goods receipt/issue slip: Code PDF417 (stacked bar code) UPS label: Maxicode (real two-dimensional code) German Railway Systems, online tickets: Aztech code (real two-dimensional code)

10.6 Summary

This chapter has described the software requirements for implementing your mobile solution. Whereas we generally prefer the online solution via SAP Console or SAP

20 © Galileo Press 2008. All rights reserved.

10.6

Summary

WebConsole, we also briefly described the requirements of an offline solution. After describing the standard SAP transactions, we discussed ways to systematically extend the functionality

and mentioned examples of references from the printed book. Two sections on label printing and different bar code standards rounded off this chapter.

www.sap-press.com

21

Information

126web.book

11 pages

Report File (DMCA)

Our content is added by our users. We aim to remove reported files within 1 working day. Please use this link to notify us:

Report this file as copyright or inappropriate

1231493


You might also be interested in

BETA
126web.book
BlackBerry Enterprise Server for Microsoft Exchange - 5.0 - Upgrade Guide