Unicode conversion causing OCRA, OCRB, and MICR lines to output as symbols

Hi,
I am tesing the printing of SAPScript invoices in a Unicode converted sandbox copy of our production system. When viewing the OTF output of an invoice I noticed that the line for postal barcode using OCR-B font is producing # symbols instead of numbers reprsenting the postal zip code. This works in the Non-Unicode environment on our production server.
The printer is an HPLJ8150. The device type for the printer that is used for the invoice, is ZHP8150, which uses the base device type of HPLJ8000. The character set is 1116, which is ISO 8859-1.
Can anyone tell me how to go about correcting this problem?
Any help will be greatly appreciated.
Thanks,
Mark

Hi Nils,
Thank you for the information. I have created a new message in the Form Printing forum. Since this is something that was changed after the unicode conversion, I think I will leave this message open a little while longer incase someone who experienced this type of issue is looking in this forum.
Two things I should add. One, the font used for the device type is working in a Non-Unicode production system at this time. Two, the OTF output of the spool is not printed on our printer but is instead converted to XML and the resulting file is FTP'd to a third party for printing. So the zip code that is represented by the bar code font is just the numerical text that is in the OTF output which is sent in the XML file.
Regards,
Mark

Similar Messages

After unicode conversion Variant missing

Dear All,
After unicode conversion in transaction S_ALR_87013611 and
S_ALR_87013613 variant is missing.
We checked in table VARIT - "Variant Texts" data is missing.
Kindly suggest.
Thanks and regards,
Joseph

Hello
Did you discover the reason for this? We are now facing the same issue and we cannot find the reason.
I don't think that note 987914 can be the answer.
Can it be something connected to the procedure for conversion or caused by a wrong-executed step?
Every suggestion can help,
Thanks
Luca

BAPI Receives unreadable parameters after unicode conversion

Dear All,
I have a strange issue, which i am stuck with and need your help to solve this.
I have a BSP Application which resides in my BW Production system and it calls a custom BAPI in R/3 to fetch list of materials based on material-text search as one of the parameters. This used to work properly before our R/3 got upgraded to ECC 6.0 with unicode conversion.
Both BW and R/3 are unicode systems now. But, doing external debugging i found that the parameters that i am sending through BSP to this BAPI are ok on BW side but, when it reaches R/3 it is getting converted to some unreadable characters due to which the BAPI doesnot return correct results.
Please advice where does conversion is happening and how can this be solved. I need immediate help as I am helpless and its a production issue...
Thanks,
Chandan

Hi Chandan,
please make sure that in transaction SM59 on both sides (BW and ERP) the rfc connections are defined as Unicode.
Best regards,
Nils Buerckel
SAP AG

Combined upgrade & Unicode conversion.

Hi
I need some suggestions for my concerns: I would appreciate, if you reply ASAP for below situations and actions.
Current system: HP unix DB: Oracle10.2.0.2
SAP 6.20 with SP 61, single code page
strategy: resource minimized.
Upgrading from 4.7 was 6.20 to ECC6.0 with CU & unicode conversion.
we ran UCCHECK and provide the list to ABAP, but they are not modifying now.
Mean while we started the preconversion steps for unicode conversion and completed. SPUMG.
Upgrade prepare is completed and currently in begining of down-time.
so far ABAP programs are not unicode complaint!!!
we don't know, when would they modify??
If we complete the upgrade and post upg steps for ecc 6.0 and
pre coversion steps for unicode.
is it a problem, if the ABAP programs are not modified yet, can it be done after conversion and before export???
or after import??
Your time is highly appreciated.
Thanks
creddy

Per CU&UC guide, you can do some conversions in parellel
and after upgrade, you have to perform preparation steps and then export, that is what i am following.
What you said is right for single code page conversion method.
upgrade first
unicode conversion second.
I am following CU&UC method.
Thanks
reddy

Unicode Conversion in Downtime Minimized Strategy

Hi,
Whether a Unicode Conversion can be done in a Downtime Minimized Strategy as what we have in Application Upgrade?
Regards,
Sam

No. Unicode conversion can be a easy project or a big project it depends on many factors lke developments, languages installed, product version, etc...
One of the steps of unicode conversion, is the EXPORT and IMPORT. During this time your system is unavailable.
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/unicode/unicode%2bfaq
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/sdn_oss_bc_i18/~form/handler%7b5f4150503d3030323030363832353030303030303031393732265f4556454e543d444953504c4159265f4e4e554d3d393238373239%7d
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5001004f-ce99-2910-8fa9-c5e564a5f318
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/sdn_oss_bc_i18/~form/handler%7b5f4150503d3030323030363832353030303030303031393732265f4556454e543d444953504c4159265f4e4e554d3d363535333331%7d
cheers

Uninstall Database manually for Unicode Conversion

Hi Guys,
While performing a Unicode Conversion, during Export, Unistall and Import of Database, I would like to improve times for Database Creation since its 5TB
My goal is to delete SAP/DB Instance Non-Unicode but keeping Tablespaces and Datafiles Layout, in order to not recreate them when re-installing SAP/DB Instance Unicode
According to SAP Note 1260050 - UNIX:Deleting Oracle DB Instance Based on NW7.1 and Higher, the steps are the following.
drop user SAP<SCHEMA_ID> cascade;
drop tablespace <TABLESPACE_NAME> including contents;
Are this steps valid to delete a ABAP Database, and keeping Datafiles structures for when Installing Unicode SAP Instance?
Thanks!

The drop command "including contents" will delete the datafiles... thus SAPinst will have to create them again... and it can take while for a 5 Tb DB.
SAPinst is supposed to recreate the whole DB thus you should entirely delete it
startup mount exclusive restrict
drop database;
One solution would be to keep the datafiles
=> just run the first SQL command : drop user SAP<SCHEMA_ID> cascade;
and play with sapinst option SAPINST_SET_STEPSTATE to skip the DB creation step

Twin upgrade and Unicode conversion: UMG_TWIN_PROCESS_LOGS Could not adjust

Hello,
We have done Upgrade of 4.5B MDMP system to ECC6 EHP4 MDMP and currently Unicode conversion in progress.
We adopted TU&UC. Now we are importing twin spumg results of last run to our procution copy system.
During running UMG_TWIN_PROCESS_LOGs. we are facing some errors
INDX lines to be corrected:               4.417
INDX lines corrected      :               4.144
IN that Could not adjust:        SMODISRC, we are referring Note 991654 - UMG_TWIN_PROCESS_LOGS shows errors on SMODISRC.
please suggest for other error tables below
Could not adjust:        VARI 1160
Could not adjust:        MONI
Could not adjust:        BDLDATCOL 1160 DLR000000492TSK0020305440PV1     0000000000DIFF    BDL   000614a01822pr                        000000Field List          S1100
Please suggest what action can be taken
Regards
Vinay

Hi Vinay,
did you already check attachment of SAP note 765475 - "Unicode conversion Troubleshooting guide" ?
Excerpt:
...check if the entries in
<table name> still exist. In some cases those entries only exist in the
Twin System but no longer in the Production System. In such cases the
message is not an error message but only information.
Best regards,
Nils Buerckel
SAP AG

What's the best solution Unicode Conversion and Upgrade on AS 400

Hi Guys,
We have a R/3 4.6C system on AS400 server. Within this year, we' like to change hardware and DB vendor (Oracle), in the meantime we also need to perform the UC and upgrade to ECC6.0.
What 's the best scenario? we have below suggestions.
1
Step1 - Heterogeneous migration and perform UC to new server and DB in one migration (export / import)
Step2 - Upgrade ECC6.0 Unicode
(not sure about this solution, is Unicode conversion to 4.6C without upgrade possible?????)
2
Step1 - Heterogeneous migration to new server and DB
Step2 - UC&UP
3
Step 1 - Heterogeneous migration to new server and DB
Step 2 - Upgrade to ECC non-unicode
Step3 - Unicode conversion to ECC unicode
????? which is better? 2 big question
- is Unicode conversion to 4.6C without upgrade possible?????)
- what's the difference between UC&UP and upgrade first and perform UC later, which is better?
Thanks very much
Lin
Edited by: ye zhulin on Mar 8, 2010 9:53 AM

Hi Lin,
I assume you have an EBCDIC database at the moment.
Point 1 is not possible, since 4.6C is not supported with Unicode.
The difference between CU&UC and a separate Upgrade and a later Unicode conversion is that CU&UC is done in one downtime. However you need to evaluate whether this is possible with your downtime requirements.
My recommendation would be to do the Migration and after that the CU&UC approach (if this is possible in a feasible downtime window - this is highly dependent on your system size / downtime requs / hardware capabilities).
Best regards,
Nils Buerckel
SAP AG
Edited by: Nils Buerckel on Mar 8, 2010 10:34 AM

Combined Upgrade and Unicode conversion of Sap 4.6C to ECC6.0

Hello all,
my project team intends to carry out a combined upgrade and unicode conversion of an SAP ERP 4.6C system with MDMP to ECC6.0 (no enhancement package). The system is running on Oracle 10.2.
In preparation for this upgrade, I have gone through the SAP notes 928729, 54801.
We need to get a rough estimate of the entire downtime so as to alert our end users. From the CU&UC documentation in 928729, I read up note 857081. However the program in this note cannot be used to estimate the downtime as my system is < SAP netweaver 6.20.
Is there any other SAP note or tool or program that I can use to estimate the downtime for the entire CU&UC? Thanks a lot!

Hi,
Combined upgrade depend upon number of factors like database size, resources on the server and optimization. In order to get idea of how much downtime, it will take, I would suggest you to do combined upgrade and unicode conversion on sandbox system which should be the replica of your production system. And try to optimize it. From there you can get approx. downtime required.
Also, please read combined upgrade and unicode conversion guides on http://service.sap.com/unicode@sap
Thanks
Sunny

Preparing for upgrade and Unicode conversion while on 4.6c

We're currently on 4.6c and preparing to upgrade to ERP 2005 and do a Unicode conversion. I'm trying to compile a list of coding techniques that can used in 4.6c that will minimize changes needed for Unicode. Does anyone have such a list?
Some things I've discovered reading about Unicode include:
1) Use GUI_UPLOAD and GUI_DOWNLOAD rather than WS_UPLOAD and WS_DOWNLOAD.
2) Structures or table headers that contain non-character data need to be identical when moving, comparing, selecting into, updating from, etc. This includes not moving structures/tables with non-character data to a character field or vice-versa.
3) Offsets can't cross non-character data.
4) Assign statement with offset must specify a length.
5) Open dataset must specify "FOR INPUT", "FOR OUTPUT", "FOR APPENDING", or "FOR UPDATE". It no longer defaults to FOR INPUT when omitted.
6) Many implicit conversions from char to numeric are no longer allowed. Use explicit conversion instead; such as the move statement.
I know there are others. Any help would be appreciated.
Regards,
Mark Perrey

Hai Mark
Check the following F.M Replacents
Upgrade Error Details     Suggestions
Function Module "DOCUMENT_REGISTRY_PROGRAM"not found in the target system     Suggest to replace this FM with the function module CV120_GET_APPL_FROM_REGISTRY.
Function Module "RP_HIRE+FIRE"not found in the target system     Suggest to replace this FM with the function module RP_HIRE_FIRE .
Function Module "ME_READ_HEADER_SINGLE" not found in the target system     Suggest to replace this FM with the function module ME_EKKO_SINGLE_READ.
Function Module "ME_READ_ITEM_SINGLE" not found in the target system     Suggest to replace this FM with the function module ME_EKPO_SINGLE_READ.
Function Module "RZL_ALERT_CONTROL" not found in the target system     Function Module "RZL_ALERT_CONTROL" is not available in the Enterprise Version. Suggest to use the function module "TH_SEND_ADM_MESS" to acheive the same functionality of "RZL_ALERT_CONTROL".
Function Module "MM_SELECT_ADDRESS" not found in the target system     Suggest to replace this FM with the function module MM_SELECT_PARTNER.
Function Module "MM_READ_ADDRESS" not found in the target system     Suggest to replace this FM with the function module MM_PARTNERS_FOR_MESSAGING
Function Module "ME_VALUES_T161" not found in the target system     Suggest to replace this FM with the function module HELP_VALUES_BSART.
Function Module "ME_VALUES_T024W" not found in the target system     . Suggest to replace this FM with the function module HELP_VALUES_WERKS.
Function Module "SD_PACKING_REFRESH" not found in the target system     Suggest to replace this FM with the function module HU_PACKING_REFRESH.
Function Module "SD_PACKING_RENAME" not found in the target system      Suggest to replace this FM with the function module V51P_PACKING_RENAME.
Function Module "RV_EXPORT_CONTROL_UPDATE" not found in the target system     Suggest to replace this FM with the function module RV_EXPORT_CONTROL_UPD_PREPARE.
Function Module "RV_INVOICE_COPY" not found in the target system     Suggest to replace this FM with the function module RV_SALES_DOCUMENT_COPY.
Function Module "SD_SCHEDULE_AGREEMENT_PACKING" not found in the target system     Suggest to replace this FM with the function module HU_PACKING_SALES_PROPOSAL.
Function Module "SERIAL_RENUM_WV" not found in the target system     Suggest to replace this FM with the function module IWOL_WV_SWITCH_NUMBER.
Function Module "CUD0_DISPLAY_CONFIGURATION" not found in the target system     Suggest to replace this FM with the function module VC_I_DISPLAY_CONFIGURATION.
Function Module "SD_PACKING_CREATE" not found in the target system     Suggest to replace this FM with the function module V51F_PACKING_CREATE.
Function Module "FI_ARCHIVE_CHECK_DOC" not found in the target system     Function Module FI_ARCHIVE_CHECK_DOC is not available in the Enterprise Version. Suggest to replace this FM with the function module FI_DOCUMENT_ARCH_CHECK_DOCS.
Function Module "OPEN_FI_CHECK" not found in the target system     Function Module OPEN_FI_CHECK is not available in the Enterprise Version. Suggest to replace this FM with the function module OPEN_FI_PERFORM_******_E.
Function Module "SD_PACKING_UPDATE"not found in the target system     Function Module SD_PACKING_UPDATE is not available in the Enterprise Version. Suggest to replace this FM with the function module HU_PACKING_UPDATE.
Function Module "F4_MACO" is being used in the program     Function Module "F4_MACO" is not available in the Enterprise Version. Since the Matchcode objects are not used in the Enterprise Version, Suggest to replace this FM with Search help's Value Request function module F4_SEARCH_HELP.
Function Module "SWZ_AI_RELEASE_S" is used in the program     Suggest to use the function module "SWZ_AI_RELEASE" instead of "SWZ_AI_RELEASE_S".
Function Module "SWW_WI_ORGTASK_READ" is used in the program      Suggest to replace this FM with the function module RH_WI_ORGTASK_READ.
Function Module "RH_READ_EXCEL_PATH" is being used in the program     Suggest to replace this FM with "RH_CHECK_EXCEL_SUPPORT".
Function Module "RZL_ALERT_CONTROL" is used in the program     Function Module "RZL_ALERT_CONTROL" is not available in the Enterprise Version. Suggest to use the function module "TH_SEND_ADM_MESS" to acheive the same functionality of "RZL_ALERT_CONTROL".
Function Module "CONVERT_TO_OTHER_CURRENCY" is used in the program     Suggest to ruse the function module "CONVERT_TO_LOCAL_CURRENCY" for currency conversion.
Function Module "LOAN_TABLECONTROL_SCROLLING" is not available in the Enterprise Version.      Suggest to replace this FM with the function module SCROLLING_IN_TABLE.
CALL FUNCTION 'DOWNLOAD' used in program is obsolete in target system.     "DOWNLOAD function module is obsolete and result in errors on Unicode systems or on systems that may potentially be Unicode enabled.
Suggest to use the unicode enabled methods
FILE_SAVE_DIALOG and GUI_DOWNLOAD
from class CL_GUI_FRONTEND_SERVICES.
Note:
However, to support existing applications, a compatibility mode was added to the function module(enhanced with Support Package) that will forward calls to DOWNLOAD to the new GUI_DOWNLOAD functions."
CALL FUNCTION 'HELP_VALUES_GET_NO_DD_NAME' used in program is obsolete in target system.     "HELP_VALUES_GET_NO_DD_NAME function module is obsolete and result in errors on Unicode systems or on systems that may potentially be Unicode enabled.
Suggest to use the function module F4IF_INT_TABLE_VALUE_REQUEST in the target system."
CALL FUNCTION 'POPUP_TO_CONFIRM_LOSS_OF_DATA' used in program is obsolete in target system.     "POPUP_TO_CONFIRM_LOSS_OF_DATA is obsolete in the target system.
Suggest to use function module POPUP_TO_CONFIRM."
CALL FUNCTION 'POPUP_TO_CONFIRM_STEP' used in program is obsolete in target system.     "POPUP_TO_CONFIRM_STEP is obsolete in the target system.
Suggest to use function module POPUP_TO_CONFIRM."
CALL FUNCTION 'WS_DOWNLOAD' used in program is obsolete in target system.     "WS_DOWNLOAD function module is obsolete and result in errors on Unicode systems or on systems that may potentially be Unicode enabled.
Suggest to use the unicode enabled GUI_DOWNLOAD function module.
Note:
However, to support existing applications, a compatibility mode was added to the function module(enhanced with Support Package) that will forward calls to WS_DOWNLOAD to the new GUI_DOWNLOAD function."
CALL FUNCTION 'WS_FILENAME_GET' used in program is obsolete in target system.     "WS_FILENAME_GET function module is obsolete, and results in errors on Unicode systems.
Suggest to use FILE_OPEN_DIALOG und FILE_SAVE_DIALOG Unicode-enabled methods of the cl_gui_frontend_services class.
Note:
New applications should restart on these methods instead of the function module. The function module is extended by a Support Package so that it diverts calls to the methods without the application having to be changed."
CALL FUNCTION 'WS_UPLOAD' used in program is obsolete in target system.     "WS_UPLOAD function module is obsolete and result in errors on Unicode systems or on systems that may potentially be Unicode enabled.
Suggest to use the unicode enabled GUI_UPLOAD function module.
Note:
However, to support existing applications, a compatibility mode was added to the function module(enhanced with Support Package) that will forward calls to WS_UPLOAD to the new GUI_UPLOAD function."
Function parameters EBENE, GRUPP, DATE_LOW, DATE_HIGH, BANKK. BUKRS, S_BUKRS, S_DISPW in function module CASH_FORECAST_TR_SELECT_ITEM is missing in the target system.     "Function Module CASH_FORECAST_TR_SELECT_ITEM is no longer used, instead it has been split based on the functionalities.
Suggest to use function module
1) CASH_FORECAST_PR_SELECT_ITEM for Payment Arrangements.
2) For TR, WP, DA use function module CASH_FORECAST_TR_ITEM_2.
The IMPORT and TABLES parameters of the above 2 function modules are almost same as CASH_FORECAST_TR_SELECT_ITEM.
The IMPORT parameter BUKRS is not available in the above 2 function modules. Hence suggest to change the coding accordingly."
Import parameter BUKRS in function CASH_FORECAST_LO_SELECT_ITEM is missing in the target system.     "Import parameter BUKRS in function CASH_FORECAST_LO_SELECT_ITEM is not available in the target system.
Also the coding in Function Module based on the parameter BUKRS has been removed, instead the TABLES parameter S_BUKRS and S_GSBER has been used.
Suggest to check the coding in the program accordingly.
Import parameter BUKRS in function CASH_FORECAST_RE_SELECT_ITEM is missing in the target system.     "Import parameter BUKRS in function CASH_FORECAST_RE_SELECT_ITEM is not available in the target system.
Also the coding in Function Module based on the parameter BUKRS has been removed, instead the TABLES parameter S_BUKRS and S_GSBER(new parameter) has been used.
Suggest to check the coding in the program accordingly.
Function Module HELP_VALUES_GET_WITH_MACO is obsolete in target system     Suggest to use F4IF_FIELD_VALUE_REQUEST
Function Module G_OBJECT_GET is obsolete in target system.     Suggest to Use G_INTERVAL_GET_NEXT
Function Module READ_COSTCENTER is obsolete in target system     Suggest to Use K_COSTCENTER_SELECT_SINGLE
Function Module K_BUSINESS_PROCESS_READ_MULTI is obsolete or not available in target system     Suggest to Use K_PROCESSES_SELECT_TAB
G_SET_AVAILABLE     Suggest to Use G_SET_GET_INFO
Function Module G_SET_DOUBLE_CHECK is obsolete or not available in target system     "DO NOT CALL THIS FUNCTION MODULE
FROM 4.0A VERSION ,THIS PROBLEM WILL NOT OCCUR"
Function Module HELP_VALUES_GET is obsolete or not available in target system     Suggest to Use F4IF_FIELD_VALUE_REQUEST
G_SELECT_SET     Suggest to Use G_SET_SELECT
Function Module G_SET_AVAILABLE is obsolete or not available in target system     Suggest to Use G_SET_GET_INFO
Function Module NAMETAB_GET is obsolete or not available in target system     Suggest to Use DDIF_FIELDINFO_GET
Function Module DD_GET_DD03P is obsolete or not available in target system     Suggest to Use DDIF_FIELDINFO_GET / DDIF_TABL_GET
CALL FUNCTION 'POPUP_TO_CONFIRM_WITH_MESSAGE' used in program is obsolete in target system.     Suggest to use function module POPUP_TO_CONFIRM.
CALL FUNCTION 'POPUP_TO_DECIDE' used in program is obsolete in target system.     Suggest to use function module POPUP_TO_CONFIRM.
Function Module HELP_VALUES_GET_WITH_TABLE is obsolete or not available in target system     Suggest to Use F4TOOL_F4FUNCTION_BRIDGE
Function Module CLPB_EXPORT is obsolete or not available in target system     "Suggest to Use Suggest to use the unicode enabled methods
CLIPBOARD_EXPORT from class CL_GUI_FRONTEND_SERVICES."
Function Module SAP_TO_ISO_MEASURE_UNIT_CODE is obsolete or not available in target system     Suggest to Use UNIT_OF_MEASURE_SAP_TO_ISO
Regards
Sreeni

4.7EEx1.10 to ECC6.0 upgrade and Unicode conversion

Hi Experts,
We are going to initiate the upgrade from next month onwards. Subsequently i have started preparing the plan and strategy for the same.
As our current setup is 4.7EEx110/Win 2003 R2-64 bit/Oracle 10.2.0.4.0 (Non unicode). And we have recently migrated on to this setup from WIn2k 32 bit. Also the current hardware is Unicode compatible.
With respect to strategy for achieving this Upgrade and Unicode conversion, i am planning as follows.
Step 1) Perform Unicode conversion on the current landscape (Both Export/import on the same servers)
Step 2) Setup Temporary landscape as part of Dual maintenance strategy and migrate data from the current systems to temporary systems using backup/restore method.
Step 3) Perform the SAP version upgrade on the current landscape and setup transport routes from temporary to current landscape in order to keep it in sync
Step 4) after successful upgrade, decommission the temporary landscape
Please provide your suggestions and valuable advices if there is anything wrong with my strategy and execution plan.
Regards,
Dheeraj

Hi,
Thanks. As i have already referred these notes as i am seeking advise with respect to my upgrade approach.
However i have planned to perform in the following manner.
1) Refresh Sandbox with Prod data and perform Upgrade to ECC6.0 EHP5 & subsequently Unicode conversion on the same server (Since both export & Import has to perform on the same hardware as we have recently migrated on this hardware which is Unicode compatible)
2) Setup temporary landscape for DEv & QAs and establish transport connection to Production system in order to move urgent changes
3) Keep a track of the changes which have transported during upgrade phase so that the same can be implemented in the upgraded systems i.e. Dev & QAS
4) After Sandbox Migration and signoff, we will perform Dev & QAS upgrade & unicode conversion on the same hardware (Note: Since these are running on VMware can we export the data from the upgraded system and import on to a new VM?)
5) Plan for production cutover and Upgrade the Prod system to ECC6.0 Ehp5 and then Unicode conversion. As i am planning to perform upgrade over the weekend and then Unicode conversion activity in the next weekend (Is it a right way?)
My Production setup: DB on one Physical host and CI on separate Virtual host
6) After the stabilization phase, we are planning for OS & DB upgrade as follows:
a) Windows upgrade from 2003 R2 to Windows 2008 R2
b) Oracle Upgrade from 10.2 to 11.2
If anyone thinks that there is anything wrong with my above approach and need changes then please revert.
I have one more doubt as I am going to upgrade 4.7EEx110 (WAS 620, Basis SP64) to ECC6.0 EHp5.As I presume that I can straight away upgrade from the current version to ECC6.0 Ehp5 without installing EHP. Kindly confirm
Thanks

Wrong text in ADRC and LFA1 table after Unicode conversion

Hello,
We are doing MDMP to Unicode on SAP 4.7 system.
In post unicode activities,we had corrected the garbage characters in
table ADRC
by converting to target langauage ZH using SUMG t-code.
Condition used for addind table ADRC in SUMG is LANGU ='1' and
LANGU_CREA = 'EN'
But after converting and saving the data,most of the records have
incorrect character in word.
and text field of search term/company name/city in table LFA1 are also
wrong in correspond field in table ADRC.
Thanks
Harshavardhan

Hi Harshavardhan,
Assumption: You have Chinese entries in table ADRC with ADRC-LANGU_CREA = EN
Now you have to distinguish two problems:
1) Chinese texts are stored in ADRC fields, which are NOT used for search help texts (most of the fields - e.g. ADRC-NAME1):
These texts can be handled in two ways:
a) Change LANGU_CREA = EN to LANGU_CREA = ZH for these entries (e.g. where ADRC-COUNTRY = CN) before the Unicode conversion (by the way, I would not use ADRC-LANGU, since this is the communication language, which does not necessarily comply with the code page of the entry).
This needs to be done in a similar way as shown in z-reports described in SAP Note 634839 ( although this specific fool-the-system case is not covered there - you have to adapt those examples)
b) Use SUMG to repair the entries using language ZH (as you already did)
My favourite would be a), as this can be done before the conversion (Note that SUMG ineeds to be executed during downtime !)
2) Chinese texts are stored in ADRC fields, which are used for search help texts (e.g. ADRC-MC_NAME1):
a) If these entries were inserted / changed with logon language ZH, then point 1) applies
b) If users logged on with logon language EN and created the entries, then most of these texts are destroyed already in Non-Unicode system. Then there is no automatic repair possible (at least point 1 does not work). Here my statement from before is valid:
Those entries need to be generated again - e.g. if you do a dummy change on the name.
According to my knowledge, this is a manual effort (either before or after the conversion) - but maybe it can be automized ...
Best regards,
Nils Buerckel
SAP AG

Combined Upgrade and Unicode conversion question

Hello Everyone,
I will be performing combined Upgrade and Unicode conversion soon. Currently i have run Prepare and do not have any errors.
I have already run SPUMG consistency check and i do not have any errors there. Since this is Combined Upgrade and unicode conversion according to guide i do not need to do the Nametab conversion right now. But now if i go this place:
SPUMG -> Status -> Additional Information , i see a status with red for Unicode nametabs are not consistent or not up-to-date.
Please let me know if i can ignore this step and do the nametab conversion after upgrade is complete and before unicode conversion.
Thanks,
FBK

Please follow the instructions from the guides.
The Unicode nametabs will be generated automatically during the upgrade.
An additional check is integrated into the final preparation steps in the target releases.
Regards,
Ronald

Single Code Page Unicode conversion when source and target are the same

Hi everyone. We have recently upgraded our non-unicode 4.7 to ECC6 non-unicode. Now we have begun researching the next step to convert to Unicode. I know we could have done the Combined Upgrade and Unicode Conversion but I wanted to do thorough testing after the upgrade to eliminate too many variables if problems arose.
So, my question is...has anyone done the Unicode conversion when source and target servers are the same? Most documentation I've seen recommends a system copy to another box first. I did find one forum thread that gave a high level approach to doing the conversion with just one server and listed this:
Step 1:- Run Tcode SPUMG to scan
Step 2:- Export Database
Step 3:- Drop Database
Step 4:- Create New Database
Step 5:- Import database
Step 6:- Chnage unicode Kernel
What are your thoughts? Is it supported? Am I wasting my time and should I just bite the bullet and buy yet another system? Thanks in advance.
-Anthony

Theoretically that's possible, yes. However...
> Step 5:- Import database
> Step 6:- Chnage unicode Kernel
the import must be done using the Unicode kernel.
So basically you can
- export the old systm
- uninstall system + database
- start as if you were installing "from scratch" on a new box
Markus

Combined upgrade and Unicode conversion for ECC5 MDMP system

Hello,
We are planning to do Upgrade and Unicode conversion of ECC5 MDMP system to ECC6 EHP4 Unicode. We are adopting Combined upgrade and Unicode conversion strategy to minimise the downtime.
In source version ECC5 we are in support pack level 6. Should we need to update the support pack to any target version to start with CU&UC or we can start with ECC5 with SP 6 itself.
Since we cant afford more downtime for support pack update also, is it ok to start with upgrade and unicode conversion with current version.
please advice.
Regards
Vinay

Hello Vinay,
please note that as a prerequisite the Basis SP should be accurate for an MDMP conversion.
There is no MUST to have the latest Basis SP, but without you could have severe issues in SPUMG.
On the application side, there are in most cases no hard requirements on the SP level.
Best regards,
Nils Buerckel
SAP AG

Unicode conversion causing OCRA, OCRB, and MICR lines to output as symbols

Similar Messages

Maybe you are looking for