Controlling posting sequence during GL Import(GL_INTERFACE table)

I am putting multiple journal records in GL_INTERFACE table having same accounting date. I have enabled Auto Post.
My requirement is, during Journal import and subsequent Auto posting. Some particular journals to be posted before posting other journals. Is there any column in GL_INTERFACE other than accounting date, which can be used to sequence the posting of journals in GL.
This requirement comes due to the fact, that some of the journals add funds to a account and other journals use that funds from that account. My requirement is when I do a journal import, GL should first post the journals which add funds and then post the other journals which use those funds, else I may have funds check failed issue.
Please let me know of solutions...

Hi,
Thanks for the solution. My company has assigned me similar kind of automation process. So if you could give me more input on this that would be great. You can send me further mails on the following id : [email protected] or a reply in the same forum is much appriciated. Waiting for your reply.
Thanks,
Nagaraj

Similar Messages

Retrofitted during the import of tables

hi
I have a source module (oracle database 8.1.7) and a target module (oracle database 10.2) and owb 10g rel 2.
I cannot directly import from the source schema, instead I have to access through a read only schema where the grants given for the table.
when I import the tables, I get the description as retrofitted in the owb screen
I am able to create the locations, validate and generate the mappings successfully, but when I deploy the mappings I get an error as
ORA-06550: line 59, column 12:
PL/SQL: ORA-00942: table or view does not exist
I checked the db links, connectors and also registered the modules successfully.
as it is a remote database, I have to access through db links and there is no question of giving the grants.
pls suggest what exactly the problem might be
regards
kishan

Kishan,
you may want to create synonyms for the tables and views you use in your mappings.
Regards,
Jörg

Need to convince manager on posting downtime during build of setup tables

Can any one suggest some pointers in writing a business case for downtime during build up of setup tables
this is for Sales Application component.

Delta loads especially for LO extraction is governed by the V3 jobs scheduled in the source system.
These V3 jobs will post into the delta queue even if there is some activity in the R/3 system.
To ensure that no transactions get missed - a downtime is taken in the source system so that no documents are changed.
If you want to avoid downtime :
1. You should know which documents changed during the period the extractors were refreshed. this is in order to fo a full repair request.
Typical procedure involves :
1. Take downtime.
2. Clear delta queues into SAP BI
3. Deschedule V3 jobs
4. Move enhancements into the production R/3 system.
5. Do an init without data transfer into SAP BI to create the delta queues
6. Schedule the V3 collection jobs
7. open the system for users to post / change documents etc
8. Continue deltas into SAP BI
If you want to avoid downtime then
1. Clear delta queues into SAP BI
2. Deschedule V3 jobs
3. Move enhancements into R/3 production
4. Init without data transfer
5. Schedule V3 jobs
6. Continue deltas
7. Perform full repair request for documents that have changed between steps 1 and 5 into SAP BI.
I have gioven the steps for an enhancement - but then any activity involving changes to V3 extractions or Upgrade activity in SAP BI would fall into the same category.

Maintain Sequence During Bulk Import

I'm doing 'Mass Import' in transaction SOLMAN_WORKCENTER->START_IMPORT for a CTS project. But, I noticed that it triggers all the transports at once and import depends on the size of objects in the transport and not sequence.
For example, if I've the following TRs in sequence and each TR is dependent on the previous one.....
1 TR1
2 TR2
3 TR3
If I trigger Bulk import for these TRs and TR1 has bulky objects, TR2 and TR3 will be imported before the dependent TR1, which will cause failure in import.
Is there any way to trigger a mass import sychronously? So that TR2 will be moved only if TR1 is successful and TR3 will be moved only after if TR2 is successful.
I'm facing the same issue in imports. The only solution to this problem was to move the TRs manually in STMS, one by one as per the sequence. It worked. But, it's not feasible for scenarios where the no of TRs in queue for imports are quite high.I checked the SAP help as well, but got no information on the same.
Kindly suggest.

Hello.
Would you answer the following question:
Have you already developed the program for transport requests import into a target (especially Productive) system ?
With the possibility to maintain the requests sequence ?
If so, then inform me, pls., how.
Best regards,
Vlad Beloglazov

Importing internal table from one program to another program

Hi everybody,
i have one small doubt.
i am using submit statement and passing the values from this program to another program selection screen. in that program logic is written.In that program one internal table values are being exported to the memory id of that program. now i have to import that internal table values into my program by using import statement. i am using the following syntax
import itab from menory id 'program name'.
but i am getting an error saying program name is unknown.
what is the exat syntax for this .
thanking you,
giri.

hi,
check these statements.
IMPORT - Get data
Variants:
1. IMPORT obj1 ... objn FROM DATA BUFFER f.
2. IMPORT obj1 ... objn FROM INTERNAL TABLE itab.
2. IMPORT obj1 ... objn FROM MEMORY.
3. IMPORT obj1 ... objn FROM SHARED MEMORY itab(ar) ID key.
4. IMPORT obj1 ... objn FROM SHARED BUFFER itab(ar) ID key.
5. IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.
6. IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.
7. IMPORT obj1 ... objn FROM LOGFILE ID key.
8. IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
9. IMPORT (itab) FROM ... .
In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs. For more details, see Storing Cluster Tables.
Variant 1
IMPORT obj1 ... objn FROM DATA BUFFER f.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... ACCEPTING PADDING
4. ... ACCEPTING TRUNCATION
5. ... IGNORING STRUCTURE BOUNDARIES
6. ... IGNORING CONVERSION ERRORS
7. ... REPLACEMENT CHARACTER c
8. ... IN CHAR-TO-HEX MODE
9. ... CODE PAGE INTO f1
10. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in Clusters.
Effect
Imports the data objects obj1 ... objn from the data buffer declared. The data buffer must be of type XSTRING . The data objects obj1 ... objn can be fields, structures, complex structures, or tables. The system imports all the data that has been stored in the data buffer f using the EXPORT ... TO DATA BUFFER statement and is listed here. It also checks that the structure used in the IMPORT statement matches the one in the EXPORT statement.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged. (In some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. The contents of all the objects remain unchanged.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is stored in the field f.
Addition 3
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end
of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 4
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR
fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 5
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is
relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 3 (enlarge structure) or addition 4 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Addition 6
...IGNORING CONVERSION ERRORS
Effect
This addition prevents the system from triggering a
runtime error, if an error occurs when the character set is converted. '#' is used as a replacement character.
Addition 7
... REPLACEMENT CHARACTER c
Effect
The replacement character is used if a particular
character cannot be converted when the character set is converted.
This addition can only be used in conjunction with addition 6.
Addition 8
... IN CHAR-TO-HEX MODE
Effect
Not all character-type fields are converted. To convert
a field, you must create a field (or structure) that is identical to the exported field or structure, except that all its character-type components must be replaced with hexadecimal fields.
You can only use this addition in Unicode programs, to allow you to import camouflaged binary data as single-byte characters.
Moreover, you cannot use this addition in conjunction with the additions 3, 4, 5, 6, or 7.
Addition 9
... CODE PAGE INTO f1
Effect
The code page of the exported data is stored in the
character-type field f1 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition.
Addition 10
... ENDIAN INTO f2
Effect
The byte order (LITTLE or BIG) of the
exported data is stored in the field f2 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition. The field f2 must have the type ABAP_ENDIAN, which is defined in the type group ABAP. For this reason, the type group ABAP must be included in the ABAP program using a TYPE-POOLS statement.
Variant 2
IMPORT obj1 ... objn FROM INTERNAL TABLE itab.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... ACCEPTING PADDING
4. ... ACCEPTING TRUNCATION
5. ... IGNORING STRUCTURE BOUNDARIES
6. ... IGNORING CONVERSION ERRORS
7. ... REPLACEMENT CHARACTER c
8. ... IN CHAR-TO-HEX MODE
9. ... CODE PAGE INTO f1
10. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See No implicit field names in cluster.
Effect
Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from the specified internal table itab. The first column in the internal table must be of the predefined type INT2 and the second must be type X. To define the first column you must refer to a data element in the ABAP Dictionary that has the predefined type INT2.
All data that was stored in the internal table itab using EXPORT ... TO INTERNAL TABLE and listed, is imported. The system checks that the EXPORT and IMPORT structures match.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the specified data cluster were imported, the rest remain unchanged (it is possible that no data object was imported).
SY-SUBRC = 4:
The data objects could not be imported.
The contents of all listed objects remain unchanged
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
Places the object in the field f.
Addition 3
... ACCEPTING PADDING
Effect
This addition allows you to add new fields to the ends
of structures, even to substructures and internal tables (the additional fields are filled with initial value during the IMPORT). It also allows you to increase the size of existing fields (C, N, X, P, I1, and I2) and to map Char fields to STRING type fields or byte fields to XSTRING type fields.
Addition 4
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR
field or omit the last component on the highest level (till Release 4.6 this was possible without specifying an addition).
Addition 5
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the page order is
relevant, that is any substructures match. With this addition, the system also ignores alignment changes arising from the Unicode conversion (for example, due to subsequent insertion of named includes).
This addition rules out any subsequent structural enhancements (addition 3) or structural shortening (addition 4) because with this addition it is the structural limits and include limits that are to be ignored.
As from Release 6.10, the include information will also be stored in the dataset, so that it is possible to also check whether the includes match, that is substructures and includes (named or unnamed) are treated the same. When importing data that was exported in a Release lower than 6.10, the includes are not checked.
Addition 6
...IGNORING CONVERSION ERRORS
Effect
This addition has the effect that an error in the
character set conversion does not cause a runtime error. The system uses "#" as a replacement character.
Addition 7
... REPLACEMENT CHARACTER c
Effect
The system uses the specified replacement character if a
character cannot be converted during a character set conversion. If this addition is not specified, the system uses "#" as a replacement character.
This addition can only be used in conjunction with addition 6.
Addition 8
... IN CHAR-TO-HEX MODE
Effect
No character type fields are converted. For this you
must create a field or structure that is identical to the exported field or exported structure, except that all character type fields must be replaced with hexadecimal fields.
This addition, which is only allowed in programs with a set Unicode flag, allows you to import binary data disguised as single byte characters. This addition cannot be used in conjunction with additions 3, 4, 5, 6, and 7.
Addition 9
... CODE PAGE INTO f1
Effect
The codepage of the exported data is stored in the
character-type field f1 (for example, to be able to analyze the data imported with the addition IN CHAR-TO-HEX MODE).
Addition 10
... ENDIAN INTO f2
Effect
The byte order (LITTLE or BIG) of the
exported data is stored in the field f2 (for example, to be able analyze the data imported using the addition IN CHAR-TO-HEX MODE). The field f2 must be of type ABAP_ENDIAN, defined in type group ABAP. You must therefore include the type group ABAP in the ABAP program with a TYPE-POOLS statement.
Variant 3
IMPORT obj1 ... objn FROM MEMORY.
Extras:
1. ... = f (for each object to be imported) 2. ... TO f (for each object to be imported)
3. ... ID key
4. ... ACCEPTING PADDING
5. ... ACCEPTING TRUNCATION
6. ... IGNORING STRUCTURE BOUNDARIES
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See You Must Enter Identification and Cannot Use Implicit Field Names inClusters
Effect
Imports data objects obj1 ... objn (fields, structures, complex structures or tables) from a data cluster in the ABAP memory (see EXPORT). Reads in all data without an ID that was exported to memory with "EXPORT ... TO MEMORY.". In contrast to the variant IMPORT FROM DATABASE, it does not check that the structure matches in EXPORT and IMPORT.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because the ABAP memory was empty.
The contents of all objects remain unchanged.
Note
You should always use the addition 3 (... ID key) with the statement. Otherwise, the effect of the variant is not certain (EXPORT statements in different parts of a program overwrite each other in the ABAP memory), since it exists only for reasons of compatibility with R/2.
Additional methods for selecting and deleting data clusters in the ABAP memory are provided by the system class CL_ABAP_EXPIMP_MEM.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Addition 3
... ID key
Effect
Imports only data stored in ABAP memory under the ID key.
Notes
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Addition 4
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 5
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR field, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 6
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 3 (enlarge structure) or addition 4 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Related
EXPORT TO MEMORY, DELETE FROM MEMORY, FREE MEMORY
Variant 4
IMPORT obj1 ... objn FROM SHARED MEMORY itab(ar) ID key.
Extras:
1. ... = f (for each object to be exported) 2. ... TO f (for each object to be exported)
3. ... CLIENT g (before ID key)
4. ... TO wa (after itab(ar) or ID key )
5. ... ACCEPTING PADDING
6. ... ACCEPTING TRUNCATION
7. ... IGNORING STRUCTURE BOUNDARIES
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See You Cannot Use Implicit Field Names in Clusters and You Cannot Use Table Work Areas.
Effect
Imports the data objects obj1 ... objn (fields, structures, complex structures, or tables) from shared memory. The data objects are read using the ID key from the area ar in the table itab - c.f. EXPORT TO SHARED MEMORY). You must use itab to specify a database table although the system reads from a memory table with the appropriate structure.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged. (In some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. You may have used the wrong ID. The contents of all the objects remain unchanged.
Notes
The table dbtab named according to SHARED MEMORY must be declared using TABLES (except in addition 2).
The structure of fields (field symbols and internal tables) to be imported must match the structure of the objects exported in the dataset. The objects must be imported under the same names as those under which they were exported. Otherwise, they will not be imported.
The key length consists of: the client (3 digits, but only if tab is client-specific); area (2 characters); ID; and line number (4 bytes). It must not exceed 64 bytes - that is, the ID must not be longer than 55 characters, if the table is client- specific.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the shared memory are provided by the system class CL_ABAP_EXPIMP_SHMEM.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is stored in the field f.
Addition 3
... CLIENT g (before ID key)
Effect
The data is imported from client g (provided the import/export table is tab client-specific). The client, g must be a character-type data object (but not a string).
Addition 4
... TO wa (after itab(ar) or ID key)
Effect
You need to use this addition if user data fields have been stored in the application buffer and are to be read from there. The work area wa is used instead of the table work area. The target area must correspond to the structure of the called table tab.
Addition 5
... ACCEPTING PADDING
Effect
This addition allows you to: append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 6
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 7
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 4 (enlarge structure) or addition 5 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Related
EXPORT TO SHARED MEMORY, DELETE FROM SHARED MEMORY
Variant 5
IMPORT obj1 ... objn FROM SHARED BUFFER itab(ar) ID key.
Extras:
1. ... = f (for each object to be exported) 2. ... TO f (for each object to be exported)
3. ... CLIENT g (before ID key)
4. ... TO wa (last addition or after itab(ar))
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas.
See Cannot Use Implicit Fieldnames in Clusters und Cannot Use Table Work Areas.
Effect
Imports data objects obj1 ... objn (fields or
tables) from the cross-transaction application buffer. The data objects are read in the application buffer using the ID key of the area ar of the buffer area for the table itab (see EXPORT TO SHARED BUFFER). You must use dbtab to specify a database table although the system reads from a memory table with an appropriate structure.
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this means that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Example
Import two fields and an internal table from the application buffer with the structure INDX:
TYPES: BEGIN OF ITAB3_LINE,
         CONT(4),
       END OF ITAB3_LINE.
DATA: INDXKEY LIKE INDX-SRTFD VALUE 'KEYVALUE',
      F1(4),
      F2(8) TYPE P DECIMALS 0,
      ITAB3 TYPE STANDARD TABLE OF ITAB3_LINE,
      INDX_WA TYPE INDX.
Import data.
IMPORT F1 = F1 F2 = F2 ITAB3 = ITAB3
       FROM SHARED BUFFER INDX(ST) ID INDXKEY TO INDX_WA.
After import, the data fields INDX-AEDAT and
INDX-USERA in front of CLUSTR are filled with
the values in the fields before the EXPORT
statement.
Notes
You must declare the table dbtab, named after DATABASE using a TABLES statement.
The structure of the fields, structures, and internal tables to be imported must match the structure of the objects exported to the dataset. Moreover, the objects must be imported with the same name used to export them. Otherwise, the import is not performed.
The maximum total key length is 64 bytes. It must include: a client if the table is client-specific (3 characters); an area (2 characters); identification; and line counter (4 bytes). This means that the number of characters available for the identification of a client-specific table is 55 characters.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the cross-transaction application buffer are provided by the system class CL_ABAP_EXPIMP_SHBUF.
Please consult Data Area and Modularization Unit Organization documentation as well.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in the field f
Addition 3
... CLIENT g (after dbtab(ar))
Effect
Takes the data from the client g (if the import/export table dbtab is client-specific). The client g must be a character-type data object (but not a string).
Addition 4
... TO wa (as the last addition or after itab(ar))
Effect
You need to use this addition if you want to save user data fields in the application buffer and then read them from there later. The system uses a work area wa instead of a table work area. The target area must have the same structure as the table tab.
Example
DATA: INDX_WA TYPE INDX,
      F1.
IMPORT F1 = F1 FROM SHARED BUFFER INDX(AR)
               CLIENT '001' ID 'TEST'
               TO INDX_WA.
WRITE: / 'AEDAT:', INDX_WA-AEDAT,
       / 'USERA:', INDX_WA-USERA,
       / 'PGMID:', INDX_WA-PGMID.
Variant 6
IMPORT obj1 ... objn FROM DATABASE dbtab(ar) ID key.
Extras:
1. ... = f (for each object to be imported)
2. ... TO f (for each object to be imported)
3. ... CLIENT g (before ID key )
4. ... USING form
5. ... TO wa (last addition or after dbtab(ar))
6. ... MAJOR-ID id1 (instead of ID key)
7. ... MINOR-ID id2 (with MAJOR-ID id1 )
8. ... ACCEPTING PADDING
9. ... ACCEPTING TRUNCATION
10. ... IGNORING STRUCTURE BOUNDARIES
11. ... IGNORING CONVERSION ERRORS
12. ... REPLACEMENT CHARACTER c
13. ... IN CHAR-TO-HEX MODE
14. ... CODE PAGE INTO f1
15. ... ENDIAN INTO f2
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Fieldnames in Clusters and Cannot Use Table Work Areas.
Effect
Imports data objects obj1 ... objn (fields, structures, complex structures, or tables) from the data cluster with ID key in area ar of the database table dbtab (see EXPORT TO DATABASE).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that not data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported, probably because an incorrect ID was used.
The contents of all objects remain unchanged.
Example
Import two fields and an internal table:
TYPES: BEGIN OF TAB3_TYPE,
          CONT(4),
       END OF TAB3_TYPE.
DATA: INDXKEY LIKE INDX-SRTFD,
      F1(4), F2 TYPE P,
      TAB3 TYPE STANDARD TABLE OF TAB3_TYPE WITH
                NON-UNIQUE DEFAULT KEY,
      WA_INDX TYPE INDX.
INDXKEY = 'INDXKEY'.
IMPORT F1   = F1
       F2   = F2
       TAB3 = TAB3 FROM DATABASE INDX(ST) ID INDXKEY
       TO WA_INDX.
Notes
You must declare the table dbtab, named after DATABASE, using the TABLES statement (except in addition 5).
The structure of fields, field strings and internal tables to be imported must match the structure of the objects exported to the dataset. In addition, the objects must be imported under the same name used to export them. If this is not the case, either a runtime error occurs or no import takes place.
Exception: You can lengthen or shorten the last field if it is of type CHAR, or add/omit CHAR fields at the end of the structure.
The key, key, must be a character-type data object (but not a string).
Additional methods for selecting and deleting data clusters in the database table specified are provided by the system class CL_ABAP_EXPIMP_DB.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Addition 3
... CLIENT g (before the ID key)
Effect
Data is taken from the client g (in client-specific import/export databases only). Client g must be a character-type data object (but not a string).
Example
DATA: F1,
      WA_INDX TYPE INDX.
IMPORT F1 = F1 FROM DATABASE INDX(AR) CLIENT '002' ID 'TEST'
               TO WA_INDX.
Addition 4
... USING form
Note
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
Effect
Does not read the data from the database. Instead, calls the FORM routine form for each record read from the database without this addition. This routine can take the data key of the data to be retrieved from the database table work area and write the retrieved data to this work area. The name of the routine has the format <name of database table>_<name of form>; it has one parameter which describes the operation (READ, UPDATE or INSERT). The routine must set the field SY-SUBRC in order to show whether the function was successfully performed.
Addition 5
... TO wa (after key or after dbtab(ar))
Effect
You need to use this addition if you want to save user data fields in the cluster database and then read from there. The system uses the work area wa instead of a table work area. The target area entered must have the same structure as the table dbtab.
Example
DATA WA LIKE INDX.
DATA F1.
IMPORT F1 = F1 FROM DATABASE INDX(AR)
               CLIENT '002' ID 'TEST'
               TO WA.
WRITE: / 'AEDAT:', WA-AEDAT,
       / 'USERA:', WA-USERA,
       / 'PGMID:', WA-PGMID.
Addition 6
... MAJOR-ID id1 (instead of the ID key).
Addition 7
... MINOR-ID id2 (with MAJOR-ID id1)
This addition is not allowed in an ABAP Objects context. See Cannot Use Generic Identification.
Effect
Searches for a record the first part of whose ID (length of id1) matches id1 and whose second part - if MINOR-ID id2 is also declared - is greater than or equal to id2.
Addition 8
... ACCEPTING PADDING
Effect
This addition allows you to append new fields to the end of structures, sub-structures, and internal tables. The IMPORT statement fills the additional fields with initial values; make existing fields (C, N, X, P, I1, and I2) longer; map character-type fields to STRING-type fields; or to map byte-type fields to XSTRING-type fields.
Addition 9
... ACCEPTING TRUNCATION
Effect
This addition allows you to shorten the last CHAR fields, or to omit the last component at the top level. (Until Release 4.6, you could do this without using an addition).
Addition 10
... IGNORING STRUCTURE BOUNDARIES
Effect
This addition means that only the fragment sequence is relevant - that is, that any sub-structures match. If you use this addition, the system ignores any alignment changes necessitated by Unicode - such as inserting named includes.
You cannot use this addition with either addition 8 (enlarge structure) or addition 9 (shorten structure), since it specifies that structure and include boundaries are to be ignored.
From Release 6.10 onwards, the include information is stored in datasets, so that the system can also check that includes match - that is, that sub-structures and includes (named or unnamed) are treated equally. When data is imported in a Release prior to 6.10, includes are not checked.
Addition 11
...IGNORING CONVERSION ERRORS
Effect
This addition prevents the system from triggering a runtime error, if an error occurs when the character set is converted. '#' is used as a replacement character.
Addition 12
... REPLACEMENT CHARACTER c
Effect
The replacement character is used if a particular character cannot be converted when the character set is converted. If you do not use this addition, '#' is used as a replacement character.
This addition can only be used in conjunction with addition 11.
Addition 13
... IN CHAR-TO-HEX MODE
Effect
All character-type fields are not converted. To convert a field, you must create a field (or structure) that is identical to the exported field or structure, except that all its character-type components must be replaced with hexadecimal fields.
You can only use this addition in Unicode programs, to allow you to import camouflaged binary data as single-byte characters. Moreover, you cannot use this addition in conjunction with the additions 8, 9, 10, 11, and 12.
Addition 14
... CODE PAGE INTO f1
Effect
The code page of the exported data is stored in the character-type field f1 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition.
Addition 15
... ENDIAN INTO f2
Effect
The byte order(LITTLE or BIG) of the exported data is stored in the field f2 - for example, to analyze data that has been imported with the IN CHAR-TO-HEX MODE addition. The field f2 must have the type ABAP_ENDIAN, which is defined in the type group ABAP. For this reason, the type group ABAP must be included in the ABAP program using a TYPE-POOLS statement.
Variant 7
IMPORT obj1 ... objn FROM DATASET dsn(ar) ID key.
This variant is not allowed in an ABAP Objects context. See Cannot Use Clusters in Files
Note
This variant is no longer supported and cannot be used.
Variant 8
IMPORT obj1 ... objn FROM LOGFILE ID key.
Note
This statement is for internal use only.
Incompatible changes or further developments may occur at any time without warning or notice.
Extras:
1. ... = f (for each field f to be imported) 2. ... TO f (for each field f to be imported)
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Implicit Field Names in Clusters
Effect
Imports data objects (fields, field strings or internal tables) from the update data. You must specify the update key assigned by the system (with current request number) as the key.
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The existing data objects in the data cluster specified were imported. The rest remain unchanged (in some circumstances, this may mean that no data objects were imported).
SY-SUBRC = 4:
The data objects could not be imported. An incorrect ID may have been used.
The contents of all objects remain unchanged.
Addition 1
... = f (for each object to be imported)
Addition 2
... TO f (for each object to be imported)
Effect
The object is placed in field f.
Variant 9
IMPORT DIRECTORY INTO itab FROM DATABASE dbtab(ar) ID key.
Extras:
1. ... CLIENT g (after dbtab(ar)) 2. ... TO wa (last addition or after dbtab(ar))
The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Table Work Areas.
Effect
Imports an object directory stored under the specified ID with EXPORT TO DATABASE into the table itab. The internal table itab may not have the type HASHED TABLE or ANY TABLE.
The key, key, must be a character-type data object (but not a string).
The Return Code is set as follows:
SY-SUBRC = 0:
The directory was successfully imported.
SY-SUBRC = 4:
The directory could not be imported, probably because an incorrect ID was used.
The internal table itab must have the same structure as the Dictionary structure CDIR (INCLUDE STRUCTURE).
Addition 1
... CLIENT g (before ID key)
Effect
Takes data from the client g (only with client-specific import/export databases). Client g must be a character-type data object (but not a string).
Addition 2
... TO wa (last addition or after dbtab(ar))
Effect
Uses the work area wa instead of the table work area. When you use this addition, you do not need to declare the table dbtab, named after DATABASE using a TABLES statement. The work area entered must have the same structure as the table dbtab.
Example
Directory of a cluster consisting of two fields and an internal table:
TYPES: BEGIN OF TAB3_LINE,
         CONT(4),
       END OF TAB3_LINE,
       BEGIN OF DIRTAB_LINE.
         INCLUDE STRUCTURE CDIR.
TYPES END OF DIRTAB_LINE.
DATA: INDXKEY LIKE INDX-SRTFD,
      F1(4),
      F2(8)   TYPE P decimals 0,
      TAB3    TYPE STANDARD TABLE OF TAB3_LINE,
      DIRTAB TYPE STANDARD TABLE OF DIRTAB_LINE,
      INDX_WA TYPE INDX.
INDXKEY = 'INDXKEY'.
EXPORT F1 = F1
       F2 = F2
       TAB3 = TAB3
       TO DATABASE INDX(ST) ID INDXKEY " TAB3 has 17 entries
       FROM INDX_WA.
IMPORT DIRECTORY INTO DIRTAB FROM DATABASE INDX(ST) ID INDXKEY
       TO INDX_WA.
Then, the table DIRTAB contains the following:
NAME     OTYPE FTYPE TFILL FLENG
F1         F      C      0      4
F2         F      P      0      8
TAB3       T      C      17     4
The meaning of the individual fields is as follows:
NAME:
Name of stored object
OTYPE:
Object type (F: Field, R: Field string / Dictionary struc

Error in import of tables splitted with SQL splitter of note 1043380

I'm doing an import on AIX for a Sap system, while the source system was on Windows and during the export I splitted some table using the splitter of note 1043380.
THe export went fine, and I see from the .TOC files into the export directory a huge number of rows has been exported for these splitted tables.
Neverthless during the import I discovered the Sapinst mark these tables as completed but the edata is not imoported.
Into the .log file for one of them I see this :
RFF) ERROR: no entry for table "VBFA" in "/export/ABAP/DATA/VBFA-1.TOC"
(IMP) INFO: import of VBFA completed (0 rows)
On SDN I found the post:
Problem with import of split tables.
But it's not clear how to apply it. I try to modify the ..TSK files for the VBFA pieces but I'm not able to find out the two space characters responsible for this behaviour.
Below some row of one of the .TSK for the VBFA table:
VBFA-1__TPI.TSK
D VBFA I ok
WHERE (ROWID >= CHARTOROWID('AAAaZsAAEAAAqYJAAA') and ROWID <= CHARTOROWID('AAAaZsAAEAAArYIEI/'))
/*+ ROWID ("VBFA") */
D VBFA I ok
WHERE (ROWID >= CHARTOROWID('AAAaZsAAEAACGUJAAA') and ROWID <= CHARTOROWID('AAAaZsAAEAACIUIEI/'))
/*+ ROWID ("VBFA") */
Beside the post stated this is a well know bug of the splitter of note 1043380 but I'm not able to find any Oss note for that.
I used the splitter already several times and never encountered this error.
Any help is really appreciated.
Best regards

Sorry I have posted the wrong link, it should be:
Re: Import error 1647, CLOB fields problem, need help!
Regards
Rob

Oracle GL error during journal import- ICM DOWN

Hi all,
I hit an error regarding the Concurrent Manager - Oracle GL during the journal import from GL_INTERFACE table. I've already populate the table with a set of dummy values. i've run the journal import to import the value from the table. i've clicked on correct and search for the Journal Import Data, but Oracle Application prompted me an error - FRM-40350: Query caused no record to retrieve, So i view the request, each and every of the request ID's phase is "Pending" with its status as "Stand by". I checked on the diagnostics and the error code was as following
CONC-DG-INACTIVE ICM DOWN
This request may have to wait on one or more of the following requests to complete before it can begin execution:
i have 2 doubts.firstly i was thinking could it be that i couldnt search for the Journal Import data at Journal: import - Correct was due to the Concurrent manager was down, thus prompting error FRM-40350? please advise. Secondly is that does CONC-DG-INACTIVE ICM DOWN suggest me to startup the concurrent management script? please advise
thanks in advance
Larry
user572825

that i couldnt search for the Journal Import data at Journal: import - Correct was >due to the Concurrent manager was down, thus prompting error FRM-40350?no i dont think so
>please advise. Secondly is that does CONC-DG-INACTIVE ICM DOWN suggest >me to startup the concurrent management script?
check fisrt if there is any runing request and wait till finish if there no runing requeste try to restart the CM if that didnot solve you issue run the CMclean.sql script then restart the CM
fadi hasweh
http://oracle-magic.blogspot.com/
Oracle is not Magic, it just takes years of experience

Automatic TAX in GL During Journal Import

Need a solution for the following.
Need to integrate Payroll data from a legacy system to General Ledger. GL Interface and Journal Import feature is being used. The Journal Lines will carry the TAX code and will have to automatically create the TAX lines in the Journal after import.
There is an option to automate TAX line generation during Manual Journal Entry by setting the TAX Required field in the Journal Header to 'Required' and supplying a Tax Code in the Line. However, on inspecting the GL INTERFACE tables for journal import there is no provision to set the Tax Required field to Required in the GL_INTERFACE table ( no column exists ).
Does anybody if Oracle GL supports the Automatic Tax calculation option for imported journals. Is the feature only available for Manual Journal Entry ?
Any workarounds possible to use the standard GL functionality for imported journals as well.

As I know, Calculate tax feature works only if you are entering manual journal entries from screen (not tried using ADI) (this is for customers who do not have any other modules others than GL and you are using manual entries).
I am aware of this functionality.If you are coming from the gl_interface, I guess, oracle assumes that you are already calculating the tax in the source system and importing the tax entries.
Journal Import on GL_INTERFACE does not support this feature.
But if you want to calculate the tax using the gl_interface, there are ways to do that. You can make use of the gl_import_hook_pkg.post_module_hook. This is called at the end of the Jounal Import program. This takes batch_ids in that are being created in the journal import. You can create a package that takes these batch_ids in and calculates tax using gl_calculate_tax_pkg.calculate_tax. This creates additional journal lines for you at the tax rate with the tax account that is setup. This involves some updates to gl_je_batches, gl_je_headers, gl_je_lines, but works. Let me know if you need more details.
Thanks
Nagamohan

GL_Interface Table

Hi All,
I have a question about GL_Interface Table.
Our company has been spitted and at the time of split one of users run a journal import, and that request has been killed.
After all in GL_Interface I have 4 records (a journal), which already has been posted to GL but still reside in a table.
What should I do? Just Delete them? Oracle is not recommend it :(

if you are absolutely sure they have been imported into the GL for the right company, etc, etc, you don't need them in the interface table anymore.
You can delete them.

How can you post comments during signal aquisition?

How can you post comments during signal aquisition? For example, while acquiring your signal, you want to post a comment which the temperature reads at "30 seconds" from your relative start time (t=34 sec into recording)
I have the LE package where events, alarms, etc cannot be used. Are there other ways that the user can mark an "event" during recording?

Hey hkim,
If you know how long it will be before you want a message to pop up you can simply include a sequence structure and in the first sequence have a wait time of your desired length and have the message pop up and display in the second sequence frame.
Hope This Helps,
Doug B
Applications Engineer
National Instruments

Error during export & import of rules in RAR 5.2

Hi all,
We followed the steps mentioned in exporting & importing the rules as per the Config guide. But we
are receiving the below error during the import of rules. Can anybody please throw a limelight on why this error message is appearing?
"Error in Table Data ==> VIRSA_CC_CRPROF
SQL==>Insert into VIRSA_CC_CRPROF(VSYSKEY,PROFILE,RULESETID,RISKLEVEL,STATUS)Values(??????)
Record==>D VIRSA_CC_CRPROF null"
We also ensured that the downloaded file is not truncated and saved it in a separate folder. Does the file needs to saved in ANSI or Unicode text? We saved in ANSI
Also the background ground job is not getting scheduled automatically during the import of ruels. Is that due to the above error?
Thanks and Best Regards,
Srihari.K

Hello Sri,
background job for generating the rules won`t be scheduled before you upload the file successfully.
The most obvious reason for this error message is that you have line in your file - in table VIRSA_CC_CRPROF that is corrupted. Make sure all lines from table VIRSA_CC_CRPROF have all predefined fields - (VSYSKEY,PROFILE,RULESETID,RISKLEVEL,STATUS).
If you keep hiting this problem just delete this table, after the upload you`ll add the critical profiles manually - I bet you don`t have many of them.
Also from my experience I always choose to save the downloaded file in UNICODE UTF-8 format.
Once the file is saved in other format, there`s no use of it, download it again and save directly in Unicode.
Make sure you don`t have empty fields, even in the fields where you don`t have values, you must leave space, otherwise you`ll keep hitting the same issue.
Regards,
Iliya

Doubt in export, import and table para when creating Function Module

Dear fellow ABAPers,
I have a doubt in defining export, import and table parameter while creating a function module.
I am calling a function module inside a user exit. Now in the user exit the SAP fills an internal table called i_lfa1 with all the data user has eneterd.
Now I want to pass this whole internal table to function module and the perform some checks on the values of internal table.
After that function module fills an error structure with values depending on some check.
1)
How do I pass this internal table to function module ?
When I am creating function module in se37 where do I define this iternal table type ? Is it in Import or Table parameter during function module creation?
2)
Where do I define error structure type (which is returned by function module to main program)? Is it in Export or table parameter during function module creation?
Please clear my doubt..
Relevant points will be awarded.
Regards,
Tushar.

Hi Tushar,
1. How do I pass this internal table to function module ?
   I assume u are creating your own Y/Z FM.
   Pass it thru TABLES parameter.
2. When I am creating function module in se37 where do I define this iternal table type
   Define this in TABLES interface.
   What Type ?
   THE SAME TYPE WHICH HAS BEEN DEFINED
    WHILE PASSING IN THE USER-EXIT FUNCTION MODULE.
   IF U SEE THE FM OF THE USER-EXIT,
   U WILL COME TO KNOW.
3.
Where do I define error structure type (which is returned by function module to main program)? Is it in Export or table parameter during function module creation?
Define it in TABLES interace. (not in export, import)
(Since what u are going to return is an internal table)
U can take for eg. BDCMSGCOLL.
OR u can create your own Y/Z structure
for the same purpose.
(or u can use the structure type T100)
I hope it helps.
Regards,
Amit M.

Import of Tables with CLOB problem.

Hi,
I am having problems with the import of tables with CLOB columns.
Tables with CLOB columns will force the use of the tablespace in which it (table) was created originally. It will not be created on the new schema's default tablespace. Is there a way to get around this problem?
More on this problem can be found here :
Re: Import error 1647, CLOB fields problem, need help!
I am using Oracle 9.2.0.6 standard edition, that is why the transportable tablespace option will not work.
Thanx
Rob

Sorry I have posted the wrong link, it should be:
Re: Import error 1647, CLOB fields problem, need help!
Regards
Rob

Import a table from FULLDB dump

Oracle 8i / Windows2000 server.
When i tried to import a table from a fulldb dump in a cloned databse.
i tried to drop the same name table from user.
NO authority to drop the table error
when i tried to rename the table
NO authority to rename the table error.
How to import a table from fulldb dump in the cloned databse.?
[email protected]

Hi..
Can you post the ORA error that you are getting....
Anand

Export and import only table structure

Hi ,
I have two schema scott and scott2. scott schema is having table index and procedure and scott2 schema is fully empty.
Now i want the table structure, indexes and procedure from scott schema to scott2 schema. No DATA needed.
What is the query to export table structure, indexes and procedure from scott schema and import in scott2 schema.
Once this done, i want scott schema should have full access to scott2 schema.
Oracle Database 10g Release 10.2.0.1.0 - 64bit Production
Please help...

Pravin wrote:
I used rows=n
it giving me below error while importing dump file:-
IMP-00003: ORACLE error 604 encountered
ORA-00604: error occurred at recursive SQL level 1
ORA-01013: user requested cancel of current operation^CYou are getting this error because you hit "Ctrl C" during the import, which essentially cancels the import.
IMP-00017: following statement failed with ORACLE error 604:
"CREATE TABLE "INVESTMENT_DETAILS_BK210509" ("EMP_NO" VARCHAR2(15), "INFOTYP"
"E" VARCHAR2(10), "SBSEC" NUMBER(*,0), "SBDIV" NUMBER(*,0), "AMOUNT" NUMBER("
"*,0), "CREATE_DATE" DATE, "MODIFY_DATE" DATE, "FROM_DATE" DATE, "TO_DATE" D"
"ATE) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 STORAGE(INITIAL 6684672"
" FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DMSTG" LOGG"
"ING NOCOMPRESS"Srini

Controlling posting sequence during GL Import(GL_INTERFACE table)

Similar Messages

Maybe you are looking for