23.3.11

SAP Note 25504 - CCMS: Archive not started automatically

Symptom:

Via CCMS (transaction DB13) an archive of the database was scheduled.
At the entered point in time, a background job was started (see Background job logs) but the corresponding database archive was not executed.
In the log file '/home//archive.log' no error message is listed. Indeed, an onarchive request was created, but this request was not executed, that is, it retains the status "NEW" ("onarchive>list/request=*/user=*").

Cause and prerequisites

For the backup scheduled under CCMS, a logical device was used that does not end with the string "_VOP".
As the request generated via CCMS can be started in the so-called "unattended" mode via 'onautovop', only the requests which should be run on a logical DEVICE whose name ends with the string "_VOP" are started.
In other words, the volume set used for a CCMS archive must be defined with a logical device that ends with the character string "_VOP".

Solution
When scheduling an archive via CCMS, a volume set defined for a logical device which ends with "_VOP" must be used (DEVICE_TYPE=..._VOP).
If no such volume set exists, a corresponding one must be created.

Additional key words

archive, backup, onarchive, dba

SAP Note 25502 - Net value for alternative items

Symptom:

Preconditions: Quotation with alternative items where the alternative item contains subitems. When determining the net value, the alternative item is not taken into account. The subitems of the alternative item are included although they are allocated to the alternative item.

Cause and prerequisites

Program error

Solution
Make the following preliminary correction.

SAP Note 25501 - CO reports: Long runtime of cost center report

Symptom:

CO reports on cost centers or activity types have a very long runtime. The runtime is also extremely long if only a few totals records are selected (see menu option 'Report -> Display statistics' in the report display).
Online it is possible that the report terminates with TIME_OUT.

Cause and prerequisites

Preconditions: A large number of cost centers and activity types are created in the master data (approx. >1000 objects).
Cause: When converting the cost centers and activity types in object numbers, the master data tables CSKS and CSSL are read. The read operation is possibly started repeatedly. For individual values, the RANGES tables for selecting the cost centers and activity types also only contain interval conditions ('BT' instead of 'EQ').

Solution
Make the corrections specified in the next section in the Includes FK21RE10 and FK21RE05 of program SAPFK21R. The modifications are indicated with "H25501. The lines indicated with "2.2 must not be inserted in Release 2.1!
Instead of the manual changes in program Include FK21RE10, described below, you can also import the transfer order P22K012019 into your system. Both transfer files of the transfer order are located in the directory /dist/permanent/Note.0025501 on the respective SAP server (SAPSERV3, SAPSERV4, ...). Please refer to OSS note 13719 for further information on importing the preliminary correction. Before importing the transfer order, you should reset all of the system buffers with the entry /$SYNC in the command field (OK-Code).

Additional key words

REPORTWRITER
RW_PERFORMANCE, RW_MODIFICATION
TIME_OUT, conversion, V

SAP Note 25498 - BOM explosion in scheduling agreement

Symptom:

The target quantity of the subitems stayed equal to zero when exploding a bill of material in a scheduling agreement. The target quantity of the subitems was only set when changing the target quantity in the main item.

Cause and prerequisites

Program error

Solution
The error can be corrected by the following repair as of 2.1D.
Up to 2.2E, you must apply note 20348 first.

SAP Note 25493 - Credit: VKM1, VKM2: Selection customer credit group

Symptom:

The selection on customer credit group does not function for transactions VKM1 and VKM2 or for reports RVKRED02 and RVKRED03.

Cause and prerequisites

Program error

Solution
Correction in 3.0 and 2.2G with P22K008821.

SAP Note 25488 - Overhead surcharges: Detailed credits

Symptom:

Different cost centers should be credited for one overhead rate within a costing sheet

Cause and prerequisites

The products must have different overhead groups and allocated to overhead keys with them.

Solution
Several overhead lines which can contain the same overhead rate but refer to different cost centers to be credited are defined for an overhead basis.
Example:
Line Basis Surcharge Description From To
Cred. 10 B000 Material costs
20 Z001 Overhead for Group1 10 E01
30 Z002 Overhead for Group2 10 E02

Z001 only calculates one surcharge for overhead key Z1
Z002 only calculates one surcharge for overhead key Z2

E01 refers to cost center 1
E02 refers to cost center 2

In this way, cost center 1 is credited with overhead key Z1 and cost center 2 is credited for overhead key Z2.

The costing sheet of course bigger.

SAP Note 25486 - Country version program does not convert RSCICO02 O035

Symptom:

  • The program is started online:
    The country version program does not convert anything and leaves the program without issuing a message.
  • The program is started in the background:
    Message CZ090 appears: 'Program SAPLSENQ already being processed'.
Cause and prerequisites

Error in the program coding.

Solution
Add 2 lines to the program coding:

SAP Note 25493 - Credit: VKM1, VKM2: Selection customer credit group

Symptom:

The selection on customer credit group does not function for transactions VKM1 and VKM2 or for reports RVKRED02 and RVKRED03.

Cause and prerequisites

Program error

Solution
Correction in 3.0 and 2.2G with P22K008821

SAP Note 25486 - Country version program does not convert RSCICO02 O035

Symptom:

  • The program is started online:
    The country version program does not convert anything and leaves the program without issuing a message.
  • The program is started in the background:
    Message CZ090 appears: 'Program SAPLSENQ already being processed'.
Cause and prerequisites

Error in the program coding.

Solution
Add 2 lines to the program coding:

SAP Note 25483 - SAPSQL_ARRAY_INSERT_DUPREC for inv. support accts

Symptom:

When maintaining the account control for investment support, this runtime error could occur during a repeated save.

Cause and prerequisites

Program error

Solution
Advance correction: Call the transaction again after saving.
Advance correction in module MA04CI01; the syntax check is only possible in main program SAPMA04C.

Additional key words

SAPMA04C OAI3

SAP Note 25481 - Characteristics: Charac. group not via batch input

Symptom:

Structure BIMST does not contain the field for the characteristics group. For this reason, the characteristics group cannot be set via batch input.

Cause and prerequisites

The function is not yet implemented in 2.1 and 2.2.

Solution
Include an additional field GROUP with data element ATKLA in structure BIMST.
Then activate structure BIMST.
This change is not critical.

Additional key words

Batch input characteristics

SAP Note 25477 - Abend when maint. long texts: M3 514 missing index

Symptom:

1)
When maintaining a material master record, you maintain a long text. However, this results in termination message M3 514, "System error: incorrect index structure for table STHEAD".

2)
When maintaining a material master record, you switch from a long text screen (such as the "Purchase Order Text" screen) to SAPscript long text maintenance to create a new long text. However, the system displays message M3 787, "You cannot execute another function after deleting a long text".

Cause and prerequisites

This problem occurs if you delete an existing long text by overwriting it with blanks and if you simultaneously execute a specific function (such as "Create") relating to long texts.

Solution

Problem corrected in Release 2.2H and Release 3.0D.

Additional key words

Transactions: MM01, MM02; program SAPMM03M, M3514, M3787

SAP Note 25474 - Inc. op. time when cumulating via hierarchy

Symptom:

When cumulating the available capacity via a hierarchy, an incorrect operating time is calculated if reference capacities are involved. This can cause a termination because the screen field is too small to contain the too large opersting time (>= 100).

Cause and prerequisites

The hierarchy contains work centers with reference capacities.

Solution
The correction sets the operating time for a hierarchy to a default of 24 hours during cumulation as described in the manual Work Centers (one operating time is not defined for several work centers).

SAP Note 25472 - Valuation of absences on public holidays

Symptom:

You want to calculate the number of public holidays (paid days off with day type 1) for monthly factoring. To do this, you use operation RTE=vnAXyy, where n specifies whether the value is to be calculated in calendar days (n=K), work days (n=A), or work hours (n=S). yy stands for the counting class to be considered; v specifies whether the partial month parameters should be processed for the partial month (v=T) or for the whole month (v=G). However, the operation only returns the number of holidays that do not overlap with an absence (for example, leave).

Example
Accounting month May 1995 with paid public holidays on May 1 and May 25.

Absence from May 22 - May 26, 1995. May 1 and May 25 were public holidays.
Using operation RTE=GAAX**, 1 is placed in the RTE field since, on May 25, 1995, an absence overlapped with a public holiday and, consequently, only May 1, 1995 counts as a public holiday.

Cause and prerequisites

The fact that absences override public holidays is preprogrammed and cannot be set using parameter tables.
As of Release 4.0, you have other control possibilities with the allocation of daily cycles to counting classes.

Solution

There are several possible ways to solve this problem:

    1. You enter absences that are not supposed to override public holidays in such a way that they never contain public holidays. In the above example, this would mean that you would have to create two absence records, one from May 22 through May 24 1995, and the other for May 26, 1995.
    2. You save the values of the public holiday counting classes before you call up function PAB. (This solution is dependent on the implementation of the calculation of counting classes, which could change with a Release change but which functions for Release 2.2-3.1).
    3. AS of Release 4.A, with table T554C, additional a counting class only for absences on public holidays can be filled (by allocating a daily cycle). This replaces the use of a correction wage type.
    4. You form a correction wage type (for example, 47yy) and place the number of all public holidays that overlap with absences of one particular or of all counting classes in the accounting period into this correction wage type.
    To do this, use the record layout field ABWAF if you want to calculate in calendar or work days, and the record layout field ABWSF if you want to calculate in work hours.
    If you want to query the number of absence days in your monthly factoring formula, you must carry out the following calculation:
    RTE=vnAPyy RTE- 47yy
    Correspondingly, you must calculate the following as the number of
    holidays: RTE=vnAXyy RTE+ 47yy.
    Please remember that you must replace yy with the counting class here. If you use RTE=vnAP** to calculate the total of all counting classes, you should not use 47** as the correction wage type since only numeric wage types are allowed as user wage types.

    Form correction wage type 47yy, by accessing a cycle as special processing in table T554C.

Example
The absence types with evaluation class 01 (for example, paid leave) should be counted in counting class 01 and should not overlay with public holidays.
The evaluation of absences takes place in work days.
Correction wage type 4701 can be formed with the following cycle: VarKey NL T Operation Operation Operation Operation O
-------------+---------+---------+---------+---------+
D ABCLS KLBW
*
01 RTE= ABWSFADDWTI4701

SAP Note 25467 - G/L account fast entry: Additional account assignments

Symptom:

Additional account assignments are not copied from the preceding line (for example cost center)

Cause and prerequisites

You cannot copy additional account assignments without further ado into subsequent lines if they are derived automatically. Example:You enter line with an account as primary cost element and a cost center that is derived automatically. The cost center may not even be included on the fast entry screen.
In the subsequent lines, amounts and changing account types/primary cost elements are specified, the tax indicators, for example, are copied. Since the cost center of the first primary cost element is replaced in the background, this would be copied automatically in the background into all subsequent lines if you copy the data from the preceding line.If you then do not perform a check on the detail view of the line item, it is very likely that you post factual errors.
For this reason, it was not yet implemented in the standard system.
Notes:

    1. If you enter a line with the required data and if you only enter the amount in the subsequent lines, the following fields are copied automatically:
    posting key, account, account type, tax indicator.
    2. The definition as a required entry is not relevant for the copying procedure.
Solution
There is no possible solution.

Additional key words

Post document, FB01, fast entry

SAP Note 25466 - Bills of material: Copy or extend references

Symptom:

References for a bill of material are only displayed for the key date although the text says valid-from date.

Cause and prerequisites
Solution
The items of the reference are transferred into the bill of material to be maintained on the valid-from date of this. The valid-to date is not taken into account. This has the result that the changes in the reference cannot be transferred in one step.
Therefore, it is not useful to display all the items from the valid-from date since this frequently leads to a confusing combination of the "versions" of the reference.
Expressed differently: The transfer of the items of the reference works like the function "New item".

Additional key words

Change, create

SAP Note 25463 - inf750: Invalid distribution format found

Symptom:

After zooming a table column with
ALTER TABLE MODIFY ( CHAR ())
where, "new_size" > "old_size" is valid,

  • the following SELECT statement SELECT * FROM WHERE ='value'
  • as wells as the call of dbschema -hd

leads to the error: inf750: Invalid distribution format found for

Cause and prerequisites

The Informix query optimizer attempts to access the changed column of this table using old statistics information. (Bug in Informix online 6.x/7.x)

Solution
Execute an "UPDATE STATISTICS MEDIUM/HIGH" on the affected columns. Should that not help, please do an "update statistics low for table drop distributions"
before doing an "update statistics medium for table ".

Additional key words

PTS PTS_BUG PTS_BUG_xxxxx

SAP Note 25456 - Credit values for partially delivered sales orders

Symptom:

VKM1, VKM4, RVKRED01: The credit value for sales orders with several items is too low, and in the extreme case zero.

Cause and prerequisites

Program error: If an item was marked as completely delivered, the following were no longer taken into account.

Solution
Correction in 3.0 and 2.2G with P22K008675.

SAP Note 25444 - SDRQCR21: Recovery of sales and delivery requirements

Symptom:

There are too many, too few or simply incorrect sales document (quotation, sales order, scheduling agreement) or delivery requirements. You can detect or check this using Transaction MD04 (Stock/Requirements List). These inconsistencies may trigger follow-on errors in planning, procurement (production, purchase order) or document processing (availability check).

Other terms

Sales document, sales requirements, outbound delivery, delivery, delivery requirement, reconstruction, reorganization, VBBE: Sales Requirements Individual Records; VBBS: Sales Requirement Totals Record, summation SUMBD, individual requirement, total requirement, daily requirement, weekly requirement, customer requirement, sales order requirement, ATP availability, batch input, collective processing, /SAPAPO/CIF_DELTAREPORT3: CIF - Comparision/Reconciliation of Transaction Data, VBUK: RFGSK, LFGSK, WBSTK, ABSTK; VBUP: RFGSA, LFGSA, WBSTA, ABSTA

Reason and Prerequisites

The problem may be caused by a program error or an operating error.

Solution
Cause of Error

Try to discover the cause of the error and then try to correct it to avoid new requirements errors. If you cannot correct the error yourself, create a customer message and describe how the error can be reproduced (for further information see Note 547277, point 1).
If errors occur repeatedly in the requirements update that you (still) cannot reproduce, save the log of correction report SDRQCR21 (see below) so that this data may be used when troubleshooting.

Correcting the Error
  • Correct the requirement errors using the SDRQCR21 report in accordance with "Instructions for Using SDRQCR21". To improve system performance, make sure that you have implemented Note 820823 (as of Release 4.5B).
  • If the ATP server is active in your system, update the data in the ATP buffer (see Note 163819).
  • If your R/3 system transfers sales and delivery requirements to an APO system (using an active integration model for the "Sales order" object), adjust the data in APO using Transaction /SAPAPO/CCR (Report /SAPAPO/CIF_DELTAREPORT3). If this does not work, see Note 444641.
Instructions for Using SDRQCR21
  • Material and Plant
    If you enter selection criteria for "Material" or "Plant," the report processes the requirements according to this selection only. If you do not enter a selection criterion, the report processes all sales and delivery requirements.
    By severely restricting the selection criterion "Material," you may be able to reduce the runtime of the report. In general, selecting the "Plant" criterion only does not shorten the runtime period. For more information, see the section entitled "Performance of SDRQCR21".
  • Data transfer
    Select the "Data transfer" parameter so that the report updates the requirements on the database.
    If you execute the report without selecting the data transfer parameter, the report simulates the update only (that is, it checks the requirements and issues a log, but it does not make any changes). In this way you can also use SDRQCR21 as a pure check report for sales and delivery requirements.
  • Compare
    Always select the "Compare" parameter to improve the performance (runtime) and to restrict the scope of the log.
    The report then corrects, deletes and creates only the requirements affected by the correction. If you do not select the parameter, the report completely reconstructs the database (for the materials/plants selected).
  • Planning entry
    If you select the "Planning entry" parameter, the report creates planning file entries (entries for the planning run) for the materials/plants affected (and relevant according to the MRP type).
  • Processing for material
    If you select the "Processing for material" parameter, the report saves the requirements (database commit) one after the other for each material/plant, instead of saving all the requirements in one step. Correspondingly, the log issued by the report is also sorted according to material and plant.
  • No parallel processing with a data transfer!
    Only execute the SDRQCR21 report with a data transfer once you have made sure that no-one will process sales documents or deliveries (for the materials/plants according to the selection) whilst the report is running, either in the foreground (dialog) or in the background (rescheduling, collective run for creating deliveries, EDI-IDoc and so on)!
    Reason: The report does not read or set blocks. It therefore produces correct results only if no other program updates sales or delivery requirements, or checks availability while the report is running. If you execute the report with a data transfer during production operation, the system may even generate new requirement errors!
    Additional Information: If you run the SDRQCR21 report twice at the same time, enter the relevant selection criteria Material/Plant for the same reason, so that they do not overlap during simultaneous processing.
  • Recommendation
    To execute the SDRQCR21 correction report easily, securely and completely, do not enter any selection criteria for "Material" or "Plant," select all four checkboxes and make sure that the report is not running during production operation. If runtime problems or other problems occur, see the following explanations in the sections entitled "Performance of SDRQCR21" and "Solving SDRQCR21 Problems."
  • Comments
    • Even if you execute the report without a data transfer, you should still select the "Compare" parameter.
      However, it is irrelevant whether you select the "Planning entry" parameter in this case, since the report without a data transfer does not create any planning file entries.
    • The "Compare," "Planning entry" and "Processing for material" parameters are available as of R/3 Release 3.1I only.
Performance of SDRQCR21

The report may require a long runtime. Since you can only execute it at specific times (you cannot use parallel processing, that is, you cannot execute the report with a data transfer during normal production operation), bottlenecks may occur.
In this case, attempt the following solutions:

  • Execute the report with a data transfer only for materials with requirement errors. To do this, proceed as follows:
    • Step 1: Execute the report without a data transfer (!) and without the selection criteria 'Material/Plant', but with 'Compare' and with 'Processing for material'. You can also do this during production operation.
    • Step 2: Outside production operation (!), execute the report with a data transfer only for those materials (or material/plant combinations) for which step 1 logged requirement errors.
    • Step 3, only if you use total requirements (Table VBBS, daily/weekly requirement) and not individual requirements (Table VBBE):
      Outside of production operation (!), repeat step 1 without 'Processing for material' for test purposes. The report should no longer log any errors.
    • Comment 1: If step 1 logged several materials with requirement errors, repeat it (several times if necessary) with selection(s) according to these materials. By repeating the step in this way, the system may log fewer materials with requirement errors. (During production operation, the report usually logs more requirement errors than actually exist. If data was transferred, the report would then create new errors.) Carry out step 2 only for those materials for which the report has logged permanent requirement errors.
    • Comment 2: If the time outside production operation is insufficient for step 2, divide the step into several substeps. That is, divide the material list determined in step 1 into sections that do not overlap and execute the report for each corresponding subsection. You can execute these substeps in succession, if necessary over several days, or partially at the same time depending on your system capabilities.
    • Comment 3: If, contrary to expectations, step 3 logs materials with requirement errors, (repeatedly) treat this step as step 1 of a new correction process. Outside production operation, reduce the list of materials with requirement errors as described in comment 1, and so on.
  • Do not select the 'Planning entry' parameter.
    The report then does not create any new planning file entries (see above). However, you must be aware of the risks involved in doing this!
  • Archive sales documents and deliveries.
    We recommend that you archive sales documents and deliveries. Document archiving reduces the database for the SDRQCR21 report and for other programs, and therefore significantly improves performance.
  • Optimize database performance.
    The tables that the report uses to approximately preselect the relevant document items are the most important:
    • VBUK and VBUP (without a selection according to Material/Plant)
    • VAPMA, VLPMA and VBUP (with a selection according to Material/Plant)

The report still reads entries from tables VBAK, VBAP, VBEP, LIKP, LIPS, as well as VBPA, VBUP and VBFA (if necessary).
Finally, it reads and updates tables VBBE (requirement individual records) or VBBS (totals records for each day/week).
Solving SDRQCR21 Problems

  • Document status
    The report returns correct results only if the statuses of the documents affected are correct (with regard to reference, delivery, goods movement, reason for rejection). This prerequisite is usually met. Only if you have good reason to suspect that the statuses are inconsistent or that the report has returned incorrect results because of inconsistencies, see Note 207875 and/or 506510, to check and, if necessary, correct the statuses of sales documents and/or deliveries.
  • Item Material Index
    If you enter the 'Material' or 'Plant' selection criteria, the report returns correct results only if the document items affected are contained correctly in the relevant material index (VAPMA, VLPMA). This prerequisite is usually met. Only if you have good reason to suspect that the index is inconsistent, that the report has returned incorrect results because of inconsistencies, or that the report terminated with SAPSQL_ARRAY_INSERT_DUPREC because of inconsistencies, check the TVIND Customizing table and see Note 128947 and/or 33267 for information about correctly reconstructing the material index.
ATP server: After the run of SDRQCR21 (if you use the ATP server), you must load the requirements for the combinations from material and plant for which SDRQCR21 was started to the ATP server.

SAP Note 25443 - Termination when creating a service contract

Symptom:

Termination with the following error message:
CALL_FUNCTION_CONFLICT_LENG

Cause and prerequisites

Program error

Solution
An incorrect table structure is referenced in the interface of some function modules. The table structure must be changed. To do this, you need to change the interfaces of the following function modules:

SD_VEDA_MAINTAIN
SD_VEDA_DIALOG
SD_VEDA_CREATE
SD_VEDA_SET_DATA
SD_VEDA_FILL_FROM_MAINITEM

SAP Note 25436 - Compaq SMART Arrray Controller Error Handling Issue

Symptom:

FATAL ERROR status on I/O commands

Cause and prerequisites

It appears that the SMART Controller resets the SCSI bus and does not resume operation properly. Then it returns a fatal error status on the calling driver.

The SMART Controller may occasionally retrun FATAL ERROR status on I/O commands under circumstances that may be recoverable.

This is NOT a RAID failure! RAID is still doing its job, but the communication between the disks/controller/driver/OS will be impaired resulting in the above mentioned scenarios.

Solution
In order to protect the data, upgrade the SMART CONTROLLER firmware and the ProLiant System firmware as follows:

SMART SCSI-2 Controllers:
Firmware version 2.22 found in Option ROMPaq V. 2.24 Rev A (SP1318)

ProLiant 2000/4000:
System ROM version 07/18/95, found in ProLiant 2000 and 4000 System ROM (18 July 1995) Ver. 18 July 1995, E10 (SP1305)

ProLiant 4500:
System ROM version 06/23/95, found in ProLiant 4500 System ROM (23 June 1995) Ver. 23 June 1994, E14 (SP1298).

PROACTIVELY UPGRADE ALL SMART CONTROLLERS TO FIRMWARE REV. 2.22 IMMEDIATELY!!

At the same time upgrade the ProLiant 2000/4000/4500 to the above mentioned versions.
If a newer version of the firmware is available at the time of installation, please use that.

Additional key words

Compaq, Smart, Arraycontroller, Raid, ProLiant, I/O. Diskcontroller

SAP Note 25435 - Acct.assign.item screen control in background

Symptom:

When entering the account assignment data for an order item, you change from SAPMV45A 0457 to screen SAPLKACB 0002 which only appears in the background. After entering a profit center and OK code /8 (Continue), you return to screen SAPMV45A 0457.
It then does not matter which OK code you use on this screen, you always first return to screen SAPLKACB 00002 that you have just left. If you process such sessions in the foreground, you can end them cleanly. During the Call transaction in mode N however, you always get an error (Sy-Subrc <> 0).

Cause and prerequisites
Solution
Enter the OK code BACK when you first leave the screen SAPMV45A 0457. This then causes you to reach the item overview screen when leaving screen SAPLKACB 0002.

SAP Note 25428 - Setting productn order del. flag w. PPREOSEL, CO78

Symptom:

When setting the deletion flag with PPREOSEL, the table for the locked entries overflowed. Only deletion flags for production orders with system status TECO were set during this background processing run. This means that the problem becomes even more drastic if you set the deletion flag for production orders with system status DLV.

Cause and prerequisites

Locks remain in existence although the order is not updated.

Solution
Correction: P22K008780 (only install together with P22K007225 also contained in this note)

SAP Additional key words Call stack points to slow_move

Symptom:

Program RSMVPROJ terminates with the error 'TSV_TNEW_OCCURS_NO_ROLL_MEMORY'
Program RSMVPROJ terminates because of report RSTSTAT0

Cause and prerequisites

1. There is not enough storage space available to execute report
RSTSTAT0 which is started by report RSMVPROJ.
2. Report RSMVPROJ was started twice

Solution
The customer must edit report RSTSTAT0

SAP Note 25416 - segmentation violation

Symptom:

segmentation violation, signal 11

Cause and prerequisites

The segment in question is created with a delay (LAZY_LOAD) during the 1st access to a TABLE-CONTROL (TABLEVIEW). If a reallocation of the segment table is carried out during this phase, the above termination occurs.

Solution
Corrected in 3.0B

Additional key words

Call stack points to slow_move

SAP Note 25412 - Nametab interface provides incorrect field catalog

Symptom:

When mass activation programs run in parallel, errors occur because the SQL statement for different tables is incorrectly set up, e.g. a SELECT for DD03L may use the field list of DD41V. Every table used in these SQL statements is described in the SAP data dictionary.

On an INFORMIX system, this causes SQL errors such as INF254, INF217 or INF608. SYSMASTER tables can never be involved.

On an ORACLE system ORA904 can be expected.

Cause and prerequisites

There is an error in the Nametab interface.
In certain situations, the pointer which should refer to the required Nametab information is set incorrectly.
The error occurs if
( i) this particular Nametab information has already been requested once for the table (for example, the field catalog) within the transaction,
( ii) then, the same Nametab information is accessed for a second table,
(iii) the Nametabs for the second table are invalidated,
( iv) the Nametab information for the first table is requested again.
In this case, an incorrect pointer can be returned due to an error in managing the Nametabs last addressed in the process.

Solution
Corrected starting with releases 30A and 22G

Additional key words

dbntab, dbtran, dbtrtab, dbrsql, dbrtab, field catalog, NT_RDFBASE

SAP Note 25406 - Termination in VA01 Create sales order

Symptom:

Runtime error after VA01: Create sales order termination message: ABAP/4 runtime error PERFORM_NOT_FOUND
"E04_MAKE_BOOL_FILENAME_VALUSER".
or
"GBTxxPC0" where xx stands for the client

Cause and prerequisites

The report RGXGBR15 did not run within the XPRAs

Solution
Please start the report manually (transaction se38) in every client.
This report generates the missing objects.

SAP Note 25404 - More than 8 or 7 wage elements in infotype 1015

Symptom:

A maximum of 7 wage elements can be saved in infotype 1015 (cost planning).

Cause and prerequisites

The database does not allow more entries.

Solution
The time constraint of infotype 1015 can be changed from 2 to 3 in table T777Z. This allows several infotype records to be created at the same time.
Please consider the changed behavior of an infotype with time constraint 3: When creating a new record, existing records are no longer automatically limited or deleted. The same applies when activating.

22.3.11

SAP Note 25398 - General information on error message AA394

Symptom:

In the depreciation key, you can choose that acquisitions should only be allowed in the acquisition year of the fixed asset.
This is absolutely necessary in various constellations of the depreciation calculation, for example, for an activity-related depreciation or different forms of special depreciation.
If, however, a subnumber is now created, and it is required that the depreciation start date of the main number be copied via the screen layout rule, error message AA394 then occurs during the initial access to this subnumber.

Additional key words

T090C-XNAZUG SAPMA01B

Solution
This should be the case, and it is justified that the check refers to the depreciation start date and not to the acquisition date for the above-mentioned reasons.
In this respect, the error message, the description in Customizing and the documentation for this constellation is misleading. This will correspondingly be changed.
If you can only actually allow acquisitions in the acquisition year for organizational reasons, you must not pass the depreciation start date from the main number to the subnumber.

SAP Note 25391 - VA01: Termination V1331 for config.material

Symptom:

Create sales order With a configurable material. Termination message V1331 occurs when saving: "Item ... does not exist."
Performance Problem: The quantity correlation is carried out too often, as is the transport of fields from the main item into the sub-items.

Cause and prerequisites

configurable material or BOM

Solution
Repair as follows:

SAP Note 25388 - MD01, MD02, MD03: Rescheduling proposals: Docum.

Symptom:

In the rescheduling check, the system checks - starting with the first requirement - whether all requirements can be covered by firmed receipts (purchase orders, production orders, firm planned orders, firm PReqs, firm delivery schedules). If this is the case, the firmed receipt is assigned a corresponding rescheduling proposal by materials planning, and a new order proposal (planned order, PReq, schedule line) is not created for the requirements.

The rescheduling check is carried out from the planning date up to the end of the replenishment lead time (from the material master) + rescheduling horizon.

If the firmed receipt is dated before the requirements, then the receipt is not needed until later; the rescheduling check is always carried out this way. Exception message 15 and the rescheduling proposal are then displayed.

If a requirement is not covered by a firmed receipt before the requirements date, then the system searches for firmed receipts that are further in the future and meet the following preconditions:

  • The firmed receipt is within the rescheduling horizon. The rescheduling horizon is set in Customizing for the MRP group (Transaction OPPR, Table T438M). A default value can be predefined in the Customizing of plant data (Transaction OPPQ, Table T399D).
  • The firmed receipt (the MRP element) participates in the rescheduling check. You can set which MRP elements participate in the rescheduling check in the Customizing of the plant data (Transaction OPPQ).

If an appropriate firmed receipt is found, it is assigned exception message 10. The exception messages can be changed in Customizing (Transaction OMD3 or table T458A). Thus, you can differentiate from the standard setting.

The rescheduling check is carried out before the actual materials planning, that is, before creating new order proposals. The rescheduling check for moving and for the cancelation check is carried out over the entire time axis. The rescheduling check for shifting forward is carried out over the area of the rescheduling horizon. The planning horizon has no influence on the creation of rescheduling proposals. It is therefore possible for rescheduling proposals to be carried out outside of the planning horizon. This is certainly very useful if requirements within the planning horizon are to be covered.

I would like to explain the following points in more detail:

    1. Requirements planning creates a new order proposal (planned orders, order requirements, or delivery schedules) although sufficient firmed receipt elements (firm planned orders, purchase requisitions, or schedule lines, production orders, shipping notifications, and purchase orders) exist.
    2. In the requirements planning run, a new order proposal was created for a particular date, although on this date, a firmed receipt element with the same quantity already exists. However, this firmed receipt element has been given a reversal proposal in the planning run.
    3. A requirement which cannot be covered by the current warehouse stock is in the past. Also in the past is a firmed receipt which covers this material shortage. The receipt, however, is after the material shortage. Materials planning responds in this case as follows: Cancellation proposal for the firmed receipt element and creation of a new order proposal which has a start date in the past.
    4. There is a balanced stock/requirements situation, that is, for every requirement there is an appropriate receipt element. The receipt elements at the start of the time axis are firmed receipts, thus for example, production orders, purchase orders, firm planned orders, PReqs, or schedule lines. Now, a new larger requirement is added at the start of the time axis. As a result, new order proposals are created at the end of the time axis. The entire lot size determination becomes chaotic. Suddenly, there are more receipt elements than requirements for a lot-for-lot order quantity.
    5. At the start of the time axis, there is a requirement which is not covered by an order proposal of materials planning. Although the material was replanned with MD01 or MD02, you cannot find a receipt element near the requirement which would be suitable to cover this requirement. Negative quantities are also displayed in MD05/MD06 for the available quantity.
    6. The MRP controllers search for materials with exceptions using Transaction MD05/MD06 via exception groups (Customizing exception groups) in order to intervene manually if necessary. In this case, they are flooded by materials with rescheduling proposals. In most cases, the requirements date and receipt date are only one or two days apart.

These rescheduling proposals are often viewed as unnecessary. How can you avoid these rescheduling proposals in order to reduce the order/operation pool of the MRP controllers ?

    7. A requirement could be covered by a receipt reservation which is further in the future. Instead, a new order proposal is created. Thus, the receipt reservation does not participate in the rescheduling check.
    8. A rescheduling proposal 15 (move) is created for a firmed receipt element at the start of the time axis. On the other hand, a rescheduling proposal 10 (forward shift) is created for a later firmed receipt element.

How can you reach such a situation where the effect of both rescheduling proposals might be balanced?

    9. You get a material with an assembly order and create an assembly order directly from a sales order. However, material requirements planning does not create a planned order for the sales order. The problem can occur if the material is scheduled deterministically. This may also be useful for materials which are obtained with assembly orders, for example to consider different requirements (no sales orders).
    10. A distribution key is used for receipts (for example, planned orders). A planned order of 100 pieces is distributed as a result, for example Monday to Friday (in each case, 20 pieces). If you now firm the planned order, a subsequent planning run creates additional receipts.
Additional key words

MD01, MD02, MD03, MD04, MD05, MD06

Cause and prerequisites
    1. The firmed receipt elements are later than the requirements and the rescheduling horizon is set too soon. If the firmed elements are outside of the rescheduling horizon, you can not use these as resources.
    2. The rescheduling check is carried out before the lot-size calculation and has no information on the lot-sizing procedure selected. In Customizing for the period lot-sizing procedure, you can use the scheduling indicator to determine when the availability date of an order proposal is to be - at the requirements date, the start of the period, or the end of the period. If the availability date is at the end of the period, then all new requirements within the period are covered by one order proposal that is not available until the end of the period. If this receipt element is firmed (for example, by conversion to a production order or a purchase order), and if the requirements do not also lie at the end of the period and if the requirements lie outside the rescheduling horizon, then the system recognizes a shortage within the period and creates a new order proposal. The firmed receipt element is used to cover following requirements. If no further requirements exist, then the system flags the firmed receipt element with a reversal proposal 20. The availability date of the new order proposal is again set to the end of the period so that now two receipt elements exist for this date - one that has newly been created and one firmed with a reversal proposal.
    3. The firmed receipt element was not included in the rescheduling check. This receipt element could not, therefore, cover the requirements before it. You can set which firmed receipt elements are taken into account in the rescheduling check in Customizing of the requirements planning plant parameters (table T399D).
    4. The new requirements are near in the future. In-house production times are no longer sufficient to cover them. The firmed receipts (production orders which it is hoped are already in production) therefore have to be accessed. The rescheduling check therefore creates rescheduling proposals for the firmed receipts - provided that it was set in the Customizing of a plant data that these firmed receipt elements participate in the rescheduling check.

If these rescheduling proposals are followed, then the new requirements can be covered by the firmed receipts with the rescheduling proposal. As a result, the requirements originally covered by the receipt elements with the rescheduling proposal must be covered elsewhere. Materials planning creates new order proposals for this. If the new requirements are larger than the first firmed receipt, then rescheduling proposals are created on the same date for several firmed receipts. Now several firmed receipts cover a requirement. Materials planning now creates a new order proposal for each of the remaining requirements for each requirements date for the lot-for-lot order quantity. There are then more receipt elements than requirements elements.

Important: There is no fixed relationship between requirement elements and receipt elements. For firmed receipts, only the date determines which requirements are covered by which receipt element. The lot-sizing procedure is insignificant here.

    5. Further in the future, there is a firmed receipt (in Transaction MD04/MD05/MD06, you might have to scroll many pages forwards). This is first used for covering requirements. Only if the quantity from the firmed receipt is no longer sufficient, does materials planning create new order proposals. Thus, the first requirement is covered by the first firmed receipt. In this case, it is not relevant whether the availability date of the firmed receipt lies before or after the requirements date. It is also unimportant whether further requirements lie between the first requirement and the firmed receipt. In Transaction MD05/MD06, the firmed receipt is assigned a corresponding rescheduling proposal.
    6. In the Customizing of MRP groups, you can set tolerance values for the rescheduling check. Default values can be set using plant parameters. An exception message is created only if the firmed receipt lies more days after the requirement than the number of "comparison value for rescheduling shift" or more days before the requirements date than the number of "comparison value rescheduling move forward".
    7. If the availability date of the firmed receipt is within the comparison values, then an exception message is not created and the material is not displayed in Transaction MD06 when accessing via MRP controller and exception group (provided that no other exceptions were calculated).
    8. A dependent reservation representing a receipt (manufacture of co-products) normally cannot be rescheduled independently. This can only be done by rescheduling the superceding production order. Therefore, the dependent receipt reservation does not participate in the rescheduling check.

Since Release 3. 0A, stock transfer reservations always participate in the rescheduling check.

Manually created receipt reservations participate in the rescheduling check since Release 3.0A. The prerequisite for this is that either the production orders or purchase orders also participate in the rescheduling check (Customizing of plant parameters for requirements planning).

    9. A safety stock is set in the material master for a material and there are outstanding requirements for the material in the past. A firmed receipt element in the past could now cover the requirements in the past, but it is assigned a rescheduling proposal to cover the FIRST requirement on the list, namely the unavailable safety stock. This requirement has the respective current date as the date. The firmed receipt element in the past is now given rescheduling proposal 10 (move) because the material shortage due to the missing safety stock is not as far in the past.

A firmed receipt which is expected later (for example, on the current date) now covers the NEXT requirement on the list, that is, the open requirements in the past. This receipt element is given rescheduling proposal 10 (move forward).

The problem is due to the fact that the missing safety stock represents a requirement for the current date, but this requirement is sorted at the beginning of the time axis.

The problem only occurs if there are requirements in the past. The respective firmed receipt elements always need special processing.

    10. Requirements planning does not know the link between receipt and and outward movement elements. This also applies to the assembly order of a sales order. The sales order and assembly order are sorted according to date and inserted in a separate planning section. If the requirement date of the sales order is prior to the basic date of the assembly order, a rescheduling proposal is created if the assembly order participates in the rescheduling check. If this is not the case, that is, the assembly order does not participate in the rescheduling check, a new planned order is created to cover the sales order.
    11. The rescheduling horizon is set too short or the firmed receipt element is set in such a way in Customizing that it does not participate in the rescheduling check. The rescheduling logic does not recognize that it is a distributed planned order in which the receipt date is decisive in ensuring that the relevant requirements are covered by the distribution period.
Solution
    1. Enter a longer rescheduling horizon for the MRP group of the material. A default value can be entered in the plant parameters for requirements planning.
    2. Use a longer rescheduling horizon. For period lot-sizing procedures, with the availability date at the end of the period, this horizon should be at least so long so that all requirements lie within it.
    3. In the Customizing of plant data, it is best to activate the rescheduling check for all firmed receipt elements.
    4. This behavior is intended. There is no solution.
    Pay attention to the rescheduling proposals. These can provide valuable information on when a manual intervention is necessary.
    5. Try to firm the receipt element as late as possible or to generate firmed receipts. This ensures that materials planning adjusts the receipt elements to the current requirements each over a long period of time. It also prevents materials planning from trying to cover requirements with firmed receipts that are too far in the past or future.

You firm an order proposal by making manual changes. For planned orders, a simple "posting" is enough without having to change any data.

For firm order proposals, "/*" is displayed at the end of the planned order number or purchase requisition number in MD05/MD06 as well as in MD04.

If special company-internal reasons make it necessary to firm a receipt element early, or to create a firm receipt element, then try to do this in a separate planning section (individual customer requirements).

In the Customizing of the planning group table, you can set the rescheduling horizon. Default values can be set in the Customizing of plant data. Firm receipts outside the rescheduling horizon do not participate in the rescheduling check. This also prevents rescheduling proposals over a long period. If, however, the firmed receipt moves into the rescheduling horizon, then materials planning immediately covers the first requirement that is not covered by earlier firmed receipts.

    6. Set suitable comparison values in the Customizing of the planning group table or plant data.
    7. No solution. If stock transfer reservations or manually created reservations also participate in the rescheduling check in a 2.2 release, then the modification XXXXXX given below can be installed.
    8. No solution.
    9. If you process assembly orders and you plan the material requirements, make sure that the rescheduling horizon is long enough.
10. Use a rescheduling horizon and set in Customizing that the firmed receipts participate in scheduling.

SAP Note 25385 - Inc.total consumpt.val.in Inventory Controlling

Symptom:

The total consumption value is displayed incorrectly in the reporting of Inventory Controlling although the value is updated correctly in the database.

Cause and prerequisites

This is caused by a program error.

Solution
Carry out the program correction

Additional key words

RMCB01F0, RMCB02F0, RMCB0900, MCBR

SAP Note 25384 - Drawn bank drawn in check deposit trans.

Symptom:

The customer wants to enter the name and city of the bank drawn upon when entering a check deposit (for checks for foreign payment). This field should be able to be printed on the check deposit list.

Cause and prerequisites

Name and city of the bank drawn upon is not provided in the standard system.

Solution

A modification is possible. Please consider the differences between Releases 2.1/2.2 and Release 3.0.


1.) Create data element (SE11):
===============================

Create data element "ZZBNKNO".
Short text : Bank account number
Domain name : TEXT30
Field descript. short : 10 Bank name
medium : 15 Bank name/city
long : 30 Bank name/city
heading : 30 Bank name/city
Activate the data element.


2.) Extend the structures (SE11):
=================================

Insert field "BNKNO_PRNO" in structure "FEBSCK" with data element "ZZBNKNO". Activate the structure.

Insert field "BNKNO_PR" in structure "RF40SI1" with data element "ZZBNKNO". Activate the structure.


3.) Extend the screen (SE51):
=============================

Place the field on screen "SAPVF40S/1001" (Release 2.1/2.2) or "SAPVF40S/1003" (Release 3.0). Consider the following in this case:

  • a) Field "FEBSCK-BNKNO_PRNO" must be chosen as a long key word.
  • b) Field "FEBSCK-BNKNO_PRNO" must be chosen as a template.
  • c) Field "*FEBSCK-BNKNO_PRNO" must be chosen as a heading.
  • d) Insert an instruction "FIELD FEBSCK-BNKNO_PRNO." into the flow
    logic.
  • e) If you have a lack of space on the screen, you can delete the
    fields that you do not need. Be very careful when doing this; you
    can no longer use deleted fields.

Generate the screen.


4.) Extend the form (SE71):
===========================

Include the field "FEBEP-PARTN+25(30)" in the form that you use for the check deposit list.


5.) Change the program (SE38):
==============================

Insert the following lines indicated by (<- insert). Check the programs afterwards for syntax errors.

Additional key words

FF68, OT45, SAPMF40S

SAP Note 25383 - Database links, synonyms, remote DB

Symptom:

When using an Oracle based R/3 system, how can you access a table using ABAP in other Oracle databases that are not necessarily R/3 databases?

Other terms

Database link, synonym, ORA-2068, ORA-2080, ORA-2081, abap/no_dsql95, dbs/ora/_retry_on_sql_error, ALTER SESSION

Reason and Prerequisites

Oracle offers the possibility to link one database to another database with a "Database link" and to access tables from the remote database with this database link. By doing this, reading and also writing access can be established to the remote tables, in which Oracle transfers the synchronization of the distributed transaction via a 2 phase commit log.

Below, possibilities for using database links from the R/3 system are described.

Solution

A Database link can be created on the R/3 database by using the following Oracle command:

CREATE PUBLIC DATABASE LINK
CONNECT TO IDENTIFIED BY
USING '';

For the refer to the Oracle documentation.

There are two possible alternatives for accessing a remote table from the R/3 System:

    1. With ABAP Open SQL
    For this, the description of the remote table and its fields in the R/3 data dictionary is required. In the releases smaller than 3.x, you can create and activate a table description in the data dictionary without the table also having to be created on the R/3 database at the same time. However, as of Release 3.x, the table is implicitly created on the R/3 database during activation. In this case, the created table must be explicitly deleted again by using the database utility.
    Instead of the table, you now create a synonym under the table name used in the R/3 data dictionary for the remote table, thus:

    CREATE SYNONYM
    FOR [.]@;

    This synonym enables you to make full use of the ABAP Open SQL language range when accessing the remote table.
    2. With ABAP native SQL
    When using native SQL, no table description is necessary in the data dictionary. The data types of the ABAP variable entered in the SQL statement are set up here. That is, type C fields should be used as host variables in the SQL statement for CHAR or VARCHAR data types and type I or type P fields for NUMBER data types.

    In the native SQL statement, the database link can be directly called:

    EXEC SQL.
    SELECT ... FROM @ ...
    ENDEXEC.

    For simplifying the syntax, you can also use synonyms, although it is not necessary.

Refer to the Oracle manuals in order to obtain the commands for creating a view or a synonym.

Possible problems:

    1. ORA-2068 after restarting the remote DB.

From the performance view, SQL statements are buffered in the R/3 System in a local work process statement cache. When repeatedly calling up the same statement, reparsing does not need to be carried out. However, this means that the connection to the Oracle database process for an SQL statement contained in the statement cache is seperately held through the execution end of the statement (technically, the respective database cursor is held until the statement is replaced in the cache).

If an SQL statement which accesses via a database link on a remote table (such as is described above) is executed, then the R/3 statement cache will also receive this statement (as it does all the other SQL statements). This occurs because the database cursor in question becomes invalid when shutting down the remote database. However, the R/3 statement cache does not notice this occurence and therefore repeatedly attempts to execute the statement with the invalid database cursor.

This problem can only be corrected by a restart of the affected application server for R/3 Releases 3.0C and smaller.

As of Release 3.0D you can avoid this problem during access with ABAP OPEN SQL by setting the R/3 parameter

dbs/ora/_retry_on_sql_error = 2068

in all instance profiles. This parameter causes the affected database cursor to be closed when the error ORA2068 occurs and a new database cursor to be opened when executing the statements again. This occurs implicitly and therefore transparently for the requested ABAP program. However, the parameter is noteffective native SQL accesses.

When using the ABAP native SQL for the remote access with Releases 3.0D - 3.1I it is possible, by setting the R/3 parameter

ABAP/no_dsql95 = NO

to force the used database cursor to close again directly after the execution of a native SQL statement. As of R/3 Release 4.x, this parameter is no longer necessary since the database cursors for Native SQL statements are always immediately released there again. Unfortunately, there is no such option in Release 3.0C and smaller.
It is mandatory that you use the newest 3.1I R/3 kernel if you set parameter ABAP/no_dsql95 since some errors affecting the Native SQL were corrected there. Refer to Note 102445 on how to import the 3.1I kernel.

However even if all DB cursors were closed, the first access via the database link after the remote DB was started terminates in every work process with the error ORA-2068 because of an Oracle error. This is probably due to the fact that the Oracle shadow process assigned to the R/3 work process, does not register the "dying" of the corresponding shadow process on the remote DB, and therefore confirms the first access with ORA-2068. Subsequently it establishes a new link to the remote DB, and further accesses are executed correctly. As workaround for this Oracle problem an SQL statement which terminated ORA-2068 is now repeated implicitly in the R/3 kernel also for ABAP Native SQL. This kernel change is valid as of Support Package level

4.0B: 650
4.5B: 404 (it is sufficient to replace the Shared Library 'dboraslib.)

    2. Use of utilization on the remote DB.
A further problem when accessing with database links is that an Oracle (shadow) process is started when first accessing the remote database with the database link. That means, if the SQL statement in question is carried out in several R/3 work processes, just as many Oracle processes are started on the remote database. Of course, these Oracle processes allocate resources to the remote machine (even if they are no longer doing anything) and therefore are preferably not seen for a long period of time by the database administrator of the remote database.

For this reason, Oracle offers the possibility to explicitly close database links and, as a result, to release the resources allocated to the remote database again. The affected SQL command is:

ALTER SESSION CLOSE DATABASE LINK

If a remote access is only occasionally carried out, it is useful, under the circumstances, to close the database link (which is opened in the execution of the SQL statements) immediately after the carrying out of the SQL statements. However, Oracle only allows the execution of the command above if the database transaction in which the remote access is carried out commits and the respective database cursor has been closed. Otherwise, the attempt to close the database link leads to the Oracle errors ORA-2080 or ORA-2081.

If you use the remote access via ABAP Open SQL with a kernel release older than 4.6D, it is unfortunately not possible to fix this error because there is no option of closing a DB cursor after carrying out an open SQL statement in the R/3 statement cache. This means that, in this case, the database link can no longer be excluded from the ABAP program. The resources allocated to the remote database remain until the affected R/3 work process ends or the remote database is shut down. As of kernel release 4.6D, however, it is possible to close an open SQL statement immediately after executing it by using the open SQL hint SAP_FORCE_CLOSE_CURSOR. For more information about specifying hints in open SQL statements, see Note 772497. The hint SAP_FORCE_CLOSE_CURSOR is available in kernel Release 4.6D as of patch level 1391 and 6.20 as of patch level 549 (and with any higher release).

If the remote accesses are exclusively performed via ABAP Native SQL, thus the DB cursors are closed immediately after executing the SQL statement, database links can be closed explicitly again in the ABAP program also:

....
EXEC SQL.
SELECT . ... FROM @ ...
ENDEXEC.
....
EXEC SQL.
COMMIT
ENDEXEC.
* The commit is necessary, otherwise the database link
* cannot be closed (ORA-2080)

EXEC SQL.
ALTER SESSION CLOSE DATABASE LINK
ENDEXEC.
* The resources are now released again on the Remote-DB

Unlike Open SQL, Native(=EXEC) SQL statements up to and including kernel Release 4.6D are closed again immediately after they have been executed . However, as of kernel release 6.20, open and native SQL statements are processed in the same way, that is, native SQL statements are also written to the statement cache and are kept open for Oracle until they have been removed from the Cache. This means that the above code fragment no longer works as of Release 6.20 and you receive an SQL error "ORA-2080: database link is in use" when you close the database link. The old response can be re-established, however, by setting the profile parameter "dbs/ora/close_stmt_after_exec = 1". This causes all native SQL statements to be closed immediately after they are carried out, as is the case with releases earlier than 6.20

SAP Note 25381 - RAISE_EXEPTION in ABAP for NAMETAB_GET

Symptom:

    1. When you execute a transaction (in particular KEU5), you receive runtime error RAISE_EXCEPTION. The termination occurred in the function NAMETAB_GET.
    2. Syntax error when checking a report which uses the field of an internal structure. However, this field is defined correctly in the Dictionary.
    3. The SHOW command in the ABAP editor either causes a termination or not enough fields are displayed.
Cause and prerequisites

During individual access to a field description by position or field name (C_DD_GET_FIELD, NAMETAB_GET), the system calculates an offset to end of the field description which is only of the C-type "short." An overflow occurs when there are more than 1540 fields in an internal structure. The ABAP/C call C_DD_GET_FIELD returns a SY-SUBRC=1. This causes the error during the syntax check of a report.
Strutures with more than three digit field amounts cannot be correctly displayed in transaction SE11 for maintaining DDIC objects.
Alternatively, you can also find out the number of fields using database statements:
In ORACLE with "sqlplus"
select max(position) from dd03l where tabname = '

';
This request gives you the number of fields.

Solution

The correction in the C coding was carried out in Release 2.2G, 2.1M and 3.0B. The number of fields of an internal structure cannot be more than 1540 in earlier upgrades.
To make it possible to assess cost center costs to Profitability Analysis (KEU5), you need to correct the syntax error in module ALxxyyyX as follows:

    1. After generating the operating concern, remove the value field groups which are not used in the assessment cycles (either as a fixed/variable value field or a field group in the tracing factor) from structure CE8nnnn (nnnn = operating concern) using SE11. Then activate the structure in SE11 so that it can be included in the nametab.
    2. The modification specified below should be entered in the ABAP Include LKEG1F20.
The modifications are lost when you regenerate the operating concern. The structure is then recreated.

Additional key words

Nametab , C_DD_GET_FIELD , NAMETAB_GET , INTERNAL_ERROR,
Syntax error in ALxxyyyX, CE8xxxx



SAP Note 25377 - Checking leave and quota deductions

Symptom:

Inconsistencies sometimes arise between leave entitlement and absence or attendance quotas on the one hand, and absence and attendances.

Cause and prerequisites

There are a range of possible causes, and corrections are described in notes (collective note 21216).

Solution
Please implement the corrections which are referred to in note 21216.
A correction is described in note 27555 for quotas 2006 and 2007.
You can use report RPTKOK00 which is contained in this note to check whether your leave and quota deductions are consistent. As of release 2.2G, the report is part of the standard delivery.
The report carries out a "totals check". For leave, the number (payroll days or payroll hours) of an absence record is compared to the total of all deductions in the period. For performance reasons, the leave is not sorted by leave type, leave year and leave ID.
For absence or attendance quotas, the consumption of all corresponding quotas 2006/2007 is totaled for each quota type, and the value is compared to the total of the numbers (payroll days or payroll hours) of the corresponding absence or attendace records 2001/2002.
You run report RPTKOK00 before accounting. Please note that certain quotas are not reduced by infotypes but by time evaluation, i.e. overtime approval. You can use the selection options AN_KTART and AB_KTART to exclude these quota types from the check.
Please create the report with the following attributes:
Type 1
Use P
Logical database PNP
Fixed point arithmetic aktiv
Maintain the following selection texts:
ABW_KONT Check absence quotas
AB_KTART Absence quota type
ANW_KONT Check attendance quotas
AN_KTART Attendance quota type
URL_ABTR Check leave deduction
Define the following text symbols:
001 Checked personnel numbers:
002 Incorrect personnel numbers:
003 Incorrect leave deduction
004 Leave deduction without absence
005 Absence quota type
006 Quota consumption
007 Absence total
008 Attendance quota type
009 Attendance total
Please carry out a syntax check once you have transferred the source text.
The easiest way to correct inconsistencies in leave deduction is to delete an existing absence record and create a new one, or if you are deducting from an absence without an absence record, to create an absence for the period and then delete it again.
You can also load report RPTKOK00 as a preliminary transport from the FTP server sapserv3. The procedure is explained in note 13719. You require the following data:
Transport request P22K008977,
R3trans file R008977.P22,
Transport info file K008977.P22,
Directory on sapserv3 /dist/permanent/Note.25377.
This directory also contains an improved version ZPTBPC10 of report RPTBPC10 (a preliminary delivery for 2.1 and 2.2) which you can use to correct the deduction of quotas 2006/2007.

Additional key words

Leave, leave entitlement, leave deduction, leave account, remaining leave, P0005, I0005, P2001, I2001, absence quota, attendance quota, attendance approval I2006, P2006, I2007, P2007, I2002, P2002, attendances.

SAP Note 25375 - SAPLV45V, GETWA_NOT_ASSIGNED, runtime error, VL01

Symptom:

When creating a delivery, the runtime error GETWA_NOT_ASSIGNED occurs with a reference to SAPLV45V, FYVBFA_LESEN_KOPF and LV45VFFA.

Cause and prerequisites
Solution
The following correction can be carried out:

SAP Note 25373 - Field SY-DATAR has incorrect value

Symptom:

The value of the system field SY-DATAR is not correct.

Cause and prerequisites

This note is only relevant for application developers !
Before determining that the value of the field SY-DATAR is incorrect, you should note the following:

- the possible values of SY-DATAR and their description:

SPACE : no entries were made in the current screen

'X' : entries were made in the current screen

- The term "current screen" is the main screen as well as any
subscreens that may also exist. The field SY-DATAR is always
valid for all of this.

- As an entry for a screen, all the following processes are valid.
These lead to the field SY-DATAR being set:

manual entry via the keyboard

transferring a value via background input

transferring a value via GPA (get parameter)

distributing a held or set value (hold/set data)

supplying a value via transaction parameter

distributing a value into a global field (HD project)

setting a selection field by default (radio button)

transfer of a value via the possible entries pushbutton (F4).

Solution
Please note the above rules.

SAP Note 25370 - Invalid access authorization is not logged.

Symptom:

Invalid access authorization is not stored in table USR07.
Specific case: GR12 (Changing Report Writer libraries)

Cause and prerequisites

If an invalid access authorization is determined during an authorization check, it is logged in table USR07. If, however, a rollback occurs within the transaction, this table is also reset. A rollback occurs in case of a termination message, for example. Upon "Process Before Input", all messages are changed into termination messages.
In this specific case, the attempt to use transaction GR12 (program SAPMGRWL) is denied in the function module G_LIBRARY_AUTHORITY_CHECK through a type E system message. This is issued as type A, however, and results in the rollback. The entry in table USR07 is thereby deleted.

Solution
The issuing of the MESSAGE can be prevented by implementing an EXCEPTION when calling up the function module.

Additional key words

AUTHORITY CHECK, Report Writer
Prorams:
SAPMGSGM, SAPMGRWC, SAPMGRWJ, SAPMGRWL, SAPMGRWD, SAPLGRWF

Transactions:
GR11 Create standard Layout
GR12 Change Standard Layout
GR13 Display Standard Layout
GR14 Delete Standard Layout
GR21 Create Library
GR22 Change Library
GR23 Display Library
GR24 Delete Library
GR31 Create Report
GR32 Change Report
GR33 Display Report
GR34 Delete Report
GR41 Create Parallel Report
GR42 Change Parallel Report
GR43 Display Parallel Report
GR44 Delete Parallel Report
GR51 Create Report Group
GR52 Change Report Group
GR53 Display Report Group
GR54 Delete Report Group
GR55 Execute Report Group
GS11 Create Variable
GS12 Change Variable
GS13 Display Variable
GS14 Delete Variable
OPDM Create Variable
OPDN Change Variable
OPDO Display Variable
OPDP Delete Variable

SAP Note 25365 - Allocation: error message GA733 or GA749

Symptom:

When you try to execute an FI-SL distribution or FI-SL assessment with variable portions as tracing factor, the following error messages are issued:
GA733 'The segment contains no receivers'
or
GA749 'Cycle &1, with starting date &2, does not contain any senders'

Cause and prerequisites

This frequently involves an inheritance problem of the allocation for summary tables, which have been installed prior to Release 4.6A.

Example:
The costs of cost element 400,000 have to be distributed from cost center 1000 to cost centers 2000 and 3000 according to the number of employees in these cost centers.

Sketch:

Sender Receiver Tracing factor
Account 400,000
Cost center 1000 2000, 3000
Stat. ratio MITARB


Due to the inheritance logic, cost element 400,000 is passed on to the receiver, and in the end also to the receiver tracing factor.
Cost centers 2000 and 3000 are passed on to the receiver tracing factor in exactly the same way.
The system now tries to find records with cost element 400,000, cost center 2000 and 3000, statistical ratio MITARB.
However, this is not possible since the statistical ratio is always only posted to one cost center (and never with cost element). Consequently, the system does not find a receiver tracing factor.

Solution
    1. For summary tables which have been installed as of Release 4.6A the problem should no longer occur.
    For tables which have been installed prior to Release 4.6A you can as of Release 4.6A deactivate the indicator "Inheritance from sender to receiver allocation basis" (T811U-INHERSRC) using Transaction GCA8.
    Then no sender values except for the company code or the company and the version are inherited to the receiver allocation bases.
    2. For Releases < 4.6A
    You maintain the cycle described as follows:

Sketch

Sender Receiver Tracing factor
Account 400,000 INITIAL-SET
Cost center 1000 2000, 3000
Stat. ratio MITARB

You can correct the error by entering a set containing only one set line for the cost element in the receiver tracing factor. You must enter 10 blank characters in this set line (press the space bar exactly 10 times).
As a result, the system is forced to search for valid receiver tracing factors without cost elements, which you will find is eventually successful.

Caution:
The dimension Statistical Ratio is only an example of the problems with inheritance. The problem can occur for ANY dimension with similar constellations of senders, receivers and tracing factors.

Refer to Note 75800 up to and including Release 3.1I.
Note for development of error search:
Under certain circumstances error message GA749 is also generated in function module G_RECORD_CHECK_AGAINST_COMB.

Additional key words

Assessment, distribution, allocation
GA733, GA749

SAP Note 25362 - "SAPLCXTK" "PARAMETERS_NOT_VALID"

Symptom:

Exception "PARAMETERS_NOT_VALID" is triggered.
The termination occurred in the ABAP/4 program "SAPLCXTK" in "CX_OPR_SCHEDULE".

Cause and prerequisites

The error occurs for
transaction "CO07" "Create order without material master"

transaction "CO01" "Create order with material master", if no routing was selected

operations with the control key "do not schedule" Solution

Correction in LCXTKU01

Additional key words

Scheduling

SAP Note 25358 - Incorrect indicator in table RGDIR in cluster CD

Symptom:

The net change planning indicator (SRTZA) is set to 'A' in table RGDIR for older results. However, 'P' would be correct. This causes incorrect values for evaluations. For example, this result is not cancelled in the interface between Financial Accounting/Controlling but is posted again.

Cause and prerequisites

This is caused by a program error in the CD manager.
This error only occurs if you carry out a change of legal person in the middle of a period, if you carry out retroactive accounting on this period and it is just a repetition of payroll accounting.
Example:
You made a change of legal person for a personnel number on 4/11/1995. Two results are written in April. Both have the indicator 'A'. In May, you carry out a retroactive accounting for April. During this first accounting run, both of the April results receive an 'A' (in-period May). Both of the old results of April are given 'P'. If you now repeat the May payroll accounting again, the result from 04/01 - 04/10/1995 (in-period April) is given an 'A' by mistake.

Solution
Correct the routine SET_RGDIR_TYPE in INCLUDE RPCMGR00. If you use RPCALCU0 (U.S.A.), RPCALCK0 (Canada) or RPCALCJ0 (Japan) for payroll accounting, maintain INCLUDE RPCMGR09. For all other country versions, you only need to edit the RPCMGR00 version.
What must you do to eliminate the effects of the error?
Start report RPUDIRx0 (x=country letter) for the affected personnel numbers and repeat the evaluations for this period.

SAP Note 25357 - MM-SRV: Error in the case of service conditions

Symptom:

Possible symptoms:

    1. Price is not found and the entered price is not retained. Message SE377 is always generated.
    2. In the contract, the error message "Condition table not found or condition type wrong" is generated.
    3. Master conditions for services cannot be maintained.
    4. Condition tables for the services cannot be displayed.
Additional key words

SE316

Cause and prerequisites

The price calculation schema is not set up for External Services Management or calculation schema not adopted from client 0 when system configured.

Solution

External Services Management uses its own price calculation schema with separate condition types.
These must be set up in the system or adopted from client 0.

In Customizing, you can do this via the menu path
-> Materials Management -> Purchasing
-> Functions -> Cond. for services
-> Conditions: schema for services

As of Release 4.0 via:
-> Materials Management -> Service
-> Maintain Conditions for Services
-> Conditions: Schema for Services

You can adopt the SAP default data by calling the function "Comparison with client 0" under the menu option "Utilities".
In the process, you must both adopt the schema and assign the associated condition types to the schema.
The necessary schemas are: MS0000 and MS0001.

To check whether the condition types have been assigned to the schema, select the relevant schema and then press the function button next to the word "--> Control".
On this second overview screen, you can then again perform the function "Comparison with client 0" (under menu option "Utilities").

Note:
Even if you set up your own calculation schema, it is advisable to first adopt the SAP standard setting from client 0 and then change this schema in accordance with your requirements.


If price determination problems still occur with regard to services even after you have adopted the schema, check whether the exclusion indicator has been set for condition type PRS.

In Customizing, you do this via the following menu path:
-> Materials Management -> Purchasing
-> Functions -> Cond. for services
-> Condition types
-> Double-click on condition type PRS

As of Release 4.0 via:
-> Materials Management -> Service
-> Maintain Conditions for Services
-> Conditions: Condition types

If this exclusion indicator has not been set, fill this field with an "X".
If the system does not allow this value, you must first maintain it using Transaction SM30.
After starting transaction SM30, enter the value "V_T686A" in the field "table/view" and press the function "Maintain".
Enter the value "MS" in the field "Application" in the dialog box "Work area".
On the overview screen which is displayed, you can again perform the function "Comparison with client 0" in the menu "Utilities".

When you have done this, the system should allow the value "X" in the field "Exclusion indicator" of condition type PRS.

SAP Note 25351 - Database transaction is full

Symptom:

SQL0964C The transaction log for the database is full

Cause and prerequisites

The problem is caused by many transactions without COMMIT, for example, client copy of client 000.

Solution
Increase the number of configured log files in DB CFG.

Additional key words

SQL0964C, logs logging, Primary logs, Secondary logs, DB CFG

SAP Note 25346 - NAST: F4 help for partner in condition records

Symptom:

There is no F4 help for partners on the list screen for condition records

Cause and prerequisites

The generated screens must be regenerated

Solution
The functionality for generating screens for condition tables can be found in the Implementation Guide.
For example, in the Implementation Guide, choose Materials Management -> Purchasing -> Functions -> Messages -> Output control -> Condition table messages -> Determine condition table for purchase order.
There choose Utilities -> Generate.
Alternatively, you can start report RV12A001 with usage 'B'.
Enter the corresponding table number on the following screen and select 'Reports & Screens'. Then execute the function.
This generates the maintenance screen again.

Additional key words

Message Control, condition records, SAPMV13B, possible entries pushbutton

SAP Note 25344 - Interface SAPSprint (SAPFprint) Barcode DLL (details)

Symptom:

An external barcode DLL is to be added to the SAPSprint or SAPFprint.


Solution
The SAPSprint or SAPFprint delegates the task of printing barcodes to an external DLL. SAP does not provide a barcode DLL.
The DLL must meet certain requirements so that it can be used.

Interface specifications:

Introduction:
-----------
SAPSprint should be able to output barcodes under windows on any Windows printer. This function should be allowed by an external DLL which is called by SAPSprint, if required.

The external barcode DLL is responsible for the appropriate display of the code including the calculation of check digits and the text itself.

Name:
-----
The SAPSprint expects a DLL with the name BARCODE.DLL in the Windows directory, the Windows System directory, or the SAPSprint work directory. For front-end printing with control technology (SAPSprint), the BARCODE.DLL must be in the SAPGUI directory.

Interface:
----------
The interface for the barcode DLL consists of two functions.

bool BarcodeInit (far char *buff, int bufflen)
----------------------------------------------

The function is called when a print job is started.
The parameter "buff" points to a buffer of length
bufflen. In this buffer, the barcode DLL sets a
string which SAPSprint issues in job log file.
This string should basically supply information using the
manufacturer of the DLL and the version number.

The function returns 0 if initialization
succeeded.

int BarcodePrint (HDC hPr, struct barcode *bc_ptr)
---------------------------------------------------

The function is called when printing a barcode. The
parameter hPr contains the GDI device context for the output device.
The parameter bc_ptr points to a control block that
contains information on the barcode.

Return codes:
0: OK
<> 0: An error occurred. In this case, the user
must set the pointer errmsg in the control block accordingly.
The control block is defined as follows:
struct barcode
{
short protovers;
long xpos;
long ypos;
long hsize;
long vsize;
char far* str;
int strlength;
int check;
int label;
int fontsize;
int hspacing;
int codeid;
long code;
int scale_s1;
int scale_s2;
int scale_s3;
int scale_s4;
int scale_l1;
int scale_l2;
int scale_l3;
int scale_l4;
char far * errmsg;
}

The parameters in detail:
protovers:
describes the log version used.
is set to 3 by SAPSprint

xpos:
ypos:
When you call the function BarcodePrint, these fields are
supplied with the current SAPSprint cursor. The barcode output
starts at this point (lower left corner of the barcode).
The DLL puts the final coordinates of the barcode into these
fields as a return value.
The specifications refer to the current Windows MapMode.

hsize:
vsize:
The required size of the barcode is set here.
If -1 is transferred, the barcode is set to its standard size.
(For log version 3, always set to 1)

str:
str points to interchange data. The length is determined by strlen.
In log version 3 all attributes of the barcode are determined
. Parameters are separated by commas.
Until now the following conventions exist:
(Improvements should be reported to SAP, so that they can be
published here):

C= Choice of barcode (for values see codeid)
B= Width of the barcode in millimeters
(for B=0 the width is determined by the Sx and Lx parameters)
H= Height of the barcode in millimeters
(H > 0: lower left corner = (xpos,ypos)
H < 0: upper left corner = (xpos,ypos))
P= Check sum (like parameter check)
A= Label (0/1 as parameter is labelled)
X= X position for barcode in millimeters from the left margin
Y= Y position for barcode in millimeters from the upper margin
(X and Y determine an absolute position that does
not depend on xpos and ypos)
S1..S4 Setting of the stripe width
Defaults: S1=6, S2=12, S3=18, S4=24
L1..L4 Setting of the gap widths
Defaults: L1=6, L2=12, L3=18, L4=24
(If B=0 was specified, these values should be taken as a pixel
for the print resolution. Otherwise just define ratios for
defining the stripes and gaps in the total width of
the barcode that you request.)
R= (0, 90, 180, 270) barcode to rotate the specified degree
clockwise (default 0)
%= Separator

strlength:
contains the length of the interchange data transferred.

check:
determines, whether a check-sum is calculated and returned.

0: no check-sum
1: with check-sum (for MSI with 1 Mod 10)
2: for MSI with 2 Mod 10
3: for MSI with 1 Mod 11, 1 Mod 10
4: for MSI with 1 Mod 11, 1 Mod 10
-1: Use the default for the respective barcode. (log version 3)

label:
checks the text of the barcode.
0: Without text
1: With text
-1: Use the default for the respective barcode.

fontsize:
Fontsize checks the size of the text font.
This is specified according to the current MapMode.
(always 0 for log version 3)

hspacing:
Hspacing checks the character spacing in the text.
This is specified according to the current MapMode.
(here, the increment of the font is copied)

codeid: (Description equals those for device type SWIN in Release 4.6A)
Selection of the required barcode.
The following constants are defined:
(character string SAPscript- Print-
for log 3) Name control
1 2 of 5 Industrial 25I
2 2 of 5 Interleaved 25L BC_I25C SBP14
BC_I25 SBP15
3 2 of 5 Matrix 25M
4 Codabar CODA
5 Code 39 39 BARCLVS SBP03
BC_CD39 SBP11
BC_CD39C SBP16
6 Code 39 Extended 39E
7 Code 93 93
8 Code 93 Extended 93E
9 Code 128 Subset B 128B ARTNR SBP01
AUFNR SBP02
KUNAUNR SBP04
KUNAUPS SBP05
MBBARC SBP06
RSNUM SBP08
RSPOS SBP09
RUECKNR SBP10
BC_C128B SBP21
10 EAN 8 E8 MBBARC1 SBP07
BC_EAN8 SBP12
11 EAN 8 with 2 places extra E8+2
12 EAN 8 with 5 places extra E8+5
13 EAN 13 E13 BC_EAN13 SBP13
14 EAN 13 with 2 places extra E13+2
15 EAN 13 with 5 places extra E13+5
16 UPC A UA
17 UPC A with 2 places extra UA+2
18 UPC A with 5 places extra UA+5
19 UPC D-1 UC1
20 UPC D-2 UC2
21 UPC D-3 UC3
22 UPC D-4 UC4
23 UPC D-5 UC5
23 UPC E UCE
24 UPC E with 2 places extra UCE+2
25 UPC E with 5 places extra UCE+5
26 UCC/EAN-128 E128 BC_EANH SBP22
27 SSCC18 SSCC18
28 MSI MSI BC_MSI SBP17
BC_MSIC SBP18
BC_MSIC1 SBP19
BC_MSIC2 SBP20
29 USPS Postnet 5 PSN5 BC_PSN5 SBP23
30 USPS Postnet 9 PSN9 BC_PSN9 SBP24
0 DEFAULT The default barcode is used. This can, if necessary,
be copied from information in the interchange data
(log version 3)
The above list represents the list of barcodes which are supported
by most normal laser printers.
The DLL should support all of the named barcodes.

code: reserved.

scale_s1:
scale_s2:
scale_s3:
scale_s4:
scale_l1:
scale_l2:
scale_l3:
scale_l4:

Scaling information on individual stripe widths and
vertical line spacing. The individual correction factors for the printer
can be set with these values.
The measurement specification is carried out according to the current MapMode settings.
The value 0 represents the default barcode width.
(not initialized for log version 3)

errmsg:
If an error occurs, the barcode DLL can store a pointer to an error
text in this variable. This text is
logged by SAPSprint as an error message.

This interface should be available from commercial suppliers.
The following list is of suppliers known to us that
manufacturer compatible barcode DLL:

1) e-bizco.com GmbH, Up'n Hoff 1, D-22927 Großhansdorf, Germany

Tel. +49/4102/6919049
Fax. +49/4102/6919047
E-Mail: info@e-bizco.com
URL: www.e-bizco.com
Note : e-bizco offers a free demo version.


2) TEC-IT Datenverarbeitung GmbH, Wagnerstr. 6, A-4400 Steyr, Austria

Tel. +43/7252/72720
Fax +43/7252/72720-77
E-Mail: sap@tec-it.com
URL: www.tec-it.co.at


3) MW6 Technologies, Inc.
Suite 700, One Executive Place
1816 Crowchild Trail NW Calgary, AB T2M 3Y7 Canada

Tel::+1(403) 451-4930
Fax: +1(403) 220-1389
Emails: info@mw6tech.com (general inquiries)
support@mw6tech
sales@mw6tech.com (orders & pre-sales)
URL: www.mw6tech.com
Note : MW6 also offers a free demo version.

SAP Note 25341 - Reason for rejection or billing block disappears

Symptom:

You entered a reason for rejection in a sub-item.
Then, data which was copied into the sub-item was changed in the main item, for example the delivery group.
The reason for rejection is then also copied from the main item into the sub-item. If the main item has no reason for rejection, the reason for rejection in the sub-item is removed.
The same applies to the billing block and other fields that are copied from the main item into the sub-item.
See also Note 0025391.

Cause and prerequisites
Solution
The following correction takes into account whether the reason for rejection or the billing block was changed in the higher-level item. Only then the data is transferred into the sub-item.

Additional key words

Bill of material

SAP Note 25340 - Sometimes no termination for REJECT (incorrect) table

Symptom:

'REJECT field.' does not cause an abnormal termination although the field does not contain the name of a table which is contained in the path from the current table XYZ to the root of the logical database (event 'GET XYZ.'). This particularly occurs if
REJECT XYZ.

is written instead of

REJECT 'XYZ'.

But, a
REJECT SPACE.
also behaves in the same way. Instead of the expected termination, you simply exit the current GET event; the superordinate table work areas then contain hexadecimal zeros afterwards.

() ABAPNOTE ABAPRESERR REJECT

Cause and prerequisites

Program error.

Solution
Correction.

SAP Note 25339 - W501 Creating orders with reference to a contract

Symptom:

Message V1501 is issued incorrectly when creating an order with reference to a contract. The target quantity in the warning does not correspond to the target quantity in the contract.

Cause and prerequisites

Variance in units of measure from the sales unit of measure on order creation.

Solution
Program correction as of 2.1d

Additional key words

Release order