Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

MATERIAL_MAINTAIN_DARK

Former Member
0 Kudos

Hi all,

iam using MATERIAL_MAINTAIN_DARK inmy program,

iwant to add tax (from MLAN table )classification data

how can i do this.

and how to do this.

thanks in advance.

1 ACCEPTED SOLUTION

nishanthbhandar
Contributor
0 Kudos

Sai,

Check in the FM documentation if any info is available.Anyways M attaching the same.

FU MATERIAL_MAINTAIN_DARK

____________________________________________________

Material Master Maintenance Without Screens

You can call up this function module from any application you like. Special initiators, such as material group maintenance or CAD, must identify themselves using the parameter CALL_MODE or CALL_MODE2. Special processing exists for these cases, for example, material number assignment.

The material data to be maintained is transferred using tables AMARA_UEB, AMARC_UEB, and so on, in internal format.

The data is processed in logical transactions; that is, only data that can be created or changed jointly in an online transaction is created or changed jointly.

An AMARA_UEB record must exist for each of these logical transactions.

For this reason, a transaction code (Create Material or Change Material) must also be transferred for each MARA record.

In addition, a unique transaction counter must also be transferred - also to dependent tables AMARC_UEB, and so on. This transaction counter groups together the related records in the tables. (The material number cannot do this with internal number assignment.)

All related MAKT and MARM records can be transferred for a record in AMARA_UEB as well as a

MARC record

MBEW record (must be consonant with MARC in accordance with the assignment of plant to valuation key)

MARD record for the MARC record

MVKE record and all MLAN records for the MVKE record

MLGN record

MLGT record for the MLGN record

With regard to MLAN, please note that MLAN records are logically linked to the combination of sales organization and distribution channel via the country. You can therefore maintain only those records that are consonant with the MVKE record (can be determined with function module Steuertab_Identify). To transfer MLAN data, MVKE must always be transferred.

For an AMARA_UEB record, you can also transfer all related

MVEG records (total consumption)

MVEU records (unplanned consumption)

LTX1 records (long texts)

MPRW records (forecast values)

Notes

The extension of a material previously created with an internal number is recognized as before by the special material number '0 '. In this case, the special material number is replaced with the previously determined internal number. The initiator must ensure that materials with an internal number are created and extended within a call package.

The commit work must be carried out by the initiator.

KZ_MATNR_RES is used to determine whether the material number has already been reserved. In this case, the material number is treated like an internal number; in particular, no check is made to see whether the material already exists.

Fields that are to be reset to their initial value are transferred using exception table AMFIELDRES.

The successfully updated records are removed from the transfer tables.

If you want to transfer the maintenance statuses to be maintained, you must fill field VPSTA in table MARA accordingly.

The maintenance statuses possible are as follows:

Maintenance status Description

A Work scheduling

B Accounting

C Classification

D MRP

E Purchasing

F Production resources/tools

G Costing

K Basic data

L Storage

P Forecasting

Q Quality management

S Warehouse management

V Sales

If you do not specify a maintenance status, the system determines it automatically from the maintenance status determination type.

The following data is not supported:

Document data

Execution of forecasts

Average plant stock

Scheduling of changes

Production versions

Classification

Joint production

Units of measure group

QM inspection data

Revision level

Sales price

Reference material

Customs tariff preferences and export licenses

Assignment of configurable material and respective variant configuration

Appendix

The material master "thinks" in the combinations of material master table and maintenance status. The combinations to be maintained are determined for each maintenance transaction from the data transferred. There are several maintenance status determination types (which can currently be specified for each transaction type in Customizing). For more information, see the documentation on the maintenance status determination type.

In the standard SAP R/3 System, the third determination type is currently used.

This has the following consequences:

A maintenance status is not created if a single status field has not been transferred for it and if all other fields for the status are already covered by the creation of other maintenance statuses. This can also result in a complete table entry not being created (for example, MLGN/MLGT - only a single maintenance status).

Normally, this has no effect since the maintained views of productively used materials contain sufficient entries.

If accounting data is transferred, the maintenance statuses Accounting and Costing are both created since all accounting fields have both maintenance statuses. (You must have sufficient authorization for this, otherwise only the status for which you are authorized will be created.)

This is of practical value since there are two separate maintenance statuses essentially for authorization reasons. The data maintained in the Costing view is only proposed in the Accounting view.

If warehouse management data is transferred in another transaction separately from the relevant plant, the corresponding MARC is not given the maintenance status Warehouse Management.

If document management is active and if document data fields are transferred, they are included in table MARA. This contrasts with the old batch input method, where this was not possible due to either the documents subscreen or the MARA drawing fields subscreen being active.

Reference data is used for all relevant tables/maintenance statuses (only for fields on the processed screen in the old material master). This concerns the following in particular:

Defaults from the MRP profile or forecast profile

Variance key from T001W for costing

Product hierarchy in MVKE from product hierarchy in MARA (general departure from the old material master)

Parameters

FLAG_MUSS_PRUEFEN

SPERRMODUS

MAX_ERRORS

P_KZ_NO_WARN

KZ_PRF

KZ_VERW

KZ_AEND

KZ_DISPO

KZ_TEST

NO_DATABASE_UPDATE

CALL_MODE

CALL_MODE2

USER

SUPPRESS_ARRAY_READ

FLG_MASS

DONT_PROCESS_HEADERS

MATNR_LAST

NUMBER_ERRORS_TRANSACTION

AMARA_UEB

AMAKT_UEB

AMARC_UEB

AMARD_UEB

AMFHM_UEB

AMARM_UEB

AMEA1_UEB

AMBEW_UEB

ASTEU_UEB

ASTMM_UEB

AMLGN_UEB

AMLGT_UEB

AMPGD_UEB

AMPOP_UEB

AMVEG_UEB

AMVEU_UEB

AMVKE_UEB

ALTX1_UEB

AMPRW_UEB

AE1CUCFG_UEB

AE1CUINS_UEB

AE1CUVAL_UEB

AE1CUCOM_UEB

AMFIELDRES

AMERRDAT

Exceptions

KSTATUS_EMPTY

TKSTATUS_EMPTY

T130M_ERROR

INTERNAL_ERROR

TOO_MANY_ERRORS

UPDATE_ERROR

ERROR_PROPAGATE_HEADER

Function Group

MGMD

Cheers

Nishanth

4 REPLIES 4

nishanthbhandar
Contributor
0 Kudos

Sai,

Check in the FM documentation if any info is available.Anyways M attaching the same.

FU MATERIAL_MAINTAIN_DARK

____________________________________________________

Material Master Maintenance Without Screens

You can call up this function module from any application you like. Special initiators, such as material group maintenance or CAD, must identify themselves using the parameter CALL_MODE or CALL_MODE2. Special processing exists for these cases, for example, material number assignment.

The material data to be maintained is transferred using tables AMARA_UEB, AMARC_UEB, and so on, in internal format.

The data is processed in logical transactions; that is, only data that can be created or changed jointly in an online transaction is created or changed jointly.

An AMARA_UEB record must exist for each of these logical transactions.

For this reason, a transaction code (Create Material or Change Material) must also be transferred for each MARA record.

In addition, a unique transaction counter must also be transferred - also to dependent tables AMARC_UEB, and so on. This transaction counter groups together the related records in the tables. (The material number cannot do this with internal number assignment.)

All related MAKT and MARM records can be transferred for a record in AMARA_UEB as well as a

MARC record

MBEW record (must be consonant with MARC in accordance with the assignment of plant to valuation key)

MARD record for the MARC record

MVKE record and all MLAN records for the MVKE record

MLGN record

MLGT record for the MLGN record

With regard to MLAN, please note that MLAN records are logically linked to the combination of sales organization and distribution channel via the country. You can therefore maintain only those records that are consonant with the MVKE record (can be determined with function module Steuertab_Identify). To transfer MLAN data, MVKE must always be transferred.

For an AMARA_UEB record, you can also transfer all related

MVEG records (total consumption)

MVEU records (unplanned consumption)

LTX1 records (long texts)

MPRW records (forecast values)

Notes

The extension of a material previously created with an internal number is recognized as before by the special material number '0 '. In this case, the special material number is replaced with the previously determined internal number. The initiator must ensure that materials with an internal number are created and extended within a call package.

The commit work must be carried out by the initiator.

KZ_MATNR_RES is used to determine whether the material number has already been reserved. In this case, the material number is treated like an internal number; in particular, no check is made to see whether the material already exists.

Fields that are to be reset to their initial value are transferred using exception table AMFIELDRES.

The successfully updated records are removed from the transfer tables.

If you want to transfer the maintenance statuses to be maintained, you must fill field VPSTA in table MARA accordingly.

The maintenance statuses possible are as follows:

Maintenance status Description

A Work scheduling

B Accounting

C Classification

D MRP

E Purchasing

F Production resources/tools

G Costing

K Basic data

L Storage

P Forecasting

Q Quality management

S Warehouse management

V Sales

If you do not specify a maintenance status, the system determines it automatically from the maintenance status determination type.

The following data is not supported:

Document data

Execution of forecasts

Average plant stock

Scheduling of changes

Production versions

Classification

Joint production

Units of measure group

QM inspection data

Revision level

Sales price

Reference material

Customs tariff preferences and export licenses

Assignment of configurable material and respective variant configuration

Appendix

The material master "thinks" in the combinations of material master table and maintenance status. The combinations to be maintained are determined for each maintenance transaction from the data transferred. There are several maintenance status determination types (which can currently be specified for each transaction type in Customizing). For more information, see the documentation on the maintenance status determination type.

In the standard SAP R/3 System, the third determination type is currently used.

This has the following consequences:

A maintenance status is not created if a single status field has not been transferred for it and if all other fields for the status are already covered by the creation of other maintenance statuses. This can also result in a complete table entry not being created (for example, MLGN/MLGT - only a single maintenance status).

Normally, this has no effect since the maintained views of productively used materials contain sufficient entries.

If accounting data is transferred, the maintenance statuses Accounting and Costing are both created since all accounting fields have both maintenance statuses. (You must have sufficient authorization for this, otherwise only the status for which you are authorized will be created.)

This is of practical value since there are two separate maintenance statuses essentially for authorization reasons. The data maintained in the Costing view is only proposed in the Accounting view.

If warehouse management data is transferred in another transaction separately from the relevant plant, the corresponding MARC is not given the maintenance status Warehouse Management.

If document management is active and if document data fields are transferred, they are included in table MARA. This contrasts with the old batch input method, where this was not possible due to either the documents subscreen or the MARA drawing fields subscreen being active.

Reference data is used for all relevant tables/maintenance statuses (only for fields on the processed screen in the old material master). This concerns the following in particular:

Defaults from the MRP profile or forecast profile

Variance key from T001W for costing

Product hierarchy in MVKE from product hierarchy in MARA (general departure from the old material master)

Parameters

FLAG_MUSS_PRUEFEN

SPERRMODUS

MAX_ERRORS

P_KZ_NO_WARN

KZ_PRF

KZ_VERW

KZ_AEND

KZ_DISPO

KZ_TEST

NO_DATABASE_UPDATE

CALL_MODE

CALL_MODE2

USER

SUPPRESS_ARRAY_READ

FLG_MASS

DONT_PROCESS_HEADERS

MATNR_LAST

NUMBER_ERRORS_TRANSACTION

AMARA_UEB

AMAKT_UEB

AMARC_UEB

AMARD_UEB

AMFHM_UEB

AMARM_UEB

AMEA1_UEB

AMBEW_UEB

ASTEU_UEB

ASTMM_UEB

AMLGN_UEB

AMLGT_UEB

AMPGD_UEB

AMPOP_UEB

AMVEG_UEB

AMVEU_UEB

AMVKE_UEB

ALTX1_UEB

AMPRW_UEB

AE1CUCFG_UEB

AE1CUINS_UEB

AE1CUVAL_UEB

AE1CUCOM_UEB

AMFIELDRES

AMERRDAT

Exceptions

KSTATUS_EMPTY

TKSTATUS_EMPTY

T130M_ERROR

INTERNAL_ERROR

TOO_MANY_ERRORS

UPDATE_ERROR

ERROR_PROPAGATE_HEADER

Function Group

MGMD

Cheers

Nishanth

former_member188685
Active Contributor
0 Kudos

Hi,

Check this Direct Input method Program<b> RMDATIND</b> to upload meterial master data , here you can see how they used . and more over it is well documented , just read the documentation for better understanding.

Regards

vijay

former_member186078
Active Participant
0 Kudos

Hi Sai,

I presume that if you want to maintain Tax classification data for the material, you cannot acheive it by using MATERIAL_MAINTAIN_DARK. It would be better if you use a BAPI for this i.e., BAPI_MATERIAL_SAVEREPLICA rather than using MATERIAL_MAINTAIN_DARK.

  • If the solution is helpful, dont forget to reward points

Former Member
0 Kudos

check with the program 'RMMM0001' inside this F.M using like the following way

CALL FUNCTION 'MATERIAL_MAINTAIN_DARK'

EXPORTING

flag_muss_pruefen = 'X'

p_kz_no_warn = 'N'

kz_prf = space

kz_verw = 'X'

kz_aend = 'X'

kz_dispo = 'X'

  • kz_mdip = flag_mdip " //br300697 zu 4.0

  • kz_mprp = flag_mprp "

call_mode = call_mode "

kz_test = ' '

TABLES

amara_ueb = tmara_ueb

amarc_ueb = tmarc_ueb

ampop_ueb = tmpop_ueb

amfieldres = amfieldres

amerrdat = amerrdat

EXCEPTIONS

kstatus_empty = 1

tkstatus_empty = 2

t130m_error = 3

internal_error = 4

too_many_errors = 5

update_error = 6

OTHERS = 7.

regards

Sreenu