Failed to update Batch characteristics using a program

[Former Member]

Hi everybody,

I've build a program that confirms certain operations of Prd. Ords. During the confirmation, goodmovement is done and a batch is created according to this goodsmovement. The number of the batch is determined in the program itself, nog standard sap logic.

I use the bapi BAPI_PRODORDCONF_CREATE_TT. When succesfull, I perform the bapi commit. When this final step is performed (after the bapi commit), I update some of the batch characteristic using the determined batch. This is where the problem starts!

After the bapi commit I perform a form for each characteristic I'd like to update. This form calls my own created function. This created function determines certain objectnumbers and other characteristics/class data and calls function CACL_OBJECT_VALIDATION_MAINT to update the characteristic and when succesfull, calls CACL_CLASSIFICATION_SAVE. All exceptions are taking care of.

The problem is the following: when I execute the program, NO batch characteristics are updated at all! Sometimes it gives a message that certain objects are locked but when I look at sm12, nothing unusual.

When I

debug

the program and the function itself, the batch characteristics ARE updated. When I test the created function myself with se37

with or without

debugging. the chars ARE updated.

I've tried the following things and all failed to update the characteristics.

- Commit work before I call my own created function
- Calling my function in new tasks or update tasks.
- Wait up till x seconds
- Commit and wait.
- Commit work after every call of my function
- Submitting the variables to a completely different program that calls the function.
- Calling a form in my own program that has the same functionality as the function that I wrote (bypassing the function call in case that was the problem).
- Leaving to transaction and using shared buffer with an internal table and thén calling a newly created program.

All failed to update the characteristics unless I

debug

the program.

Any ideas? I think it is something simple but I just can't get a 'lock' on it.

Cheers and thanks

Laurens

[christian_wohlfahrt]

Hi Laurens,

your two working ways are online - all the rest of your tries were background.

I don't know, why these 'CACL...' functions might need a GUI, but it's at least a hint for further researches.

Regards,

Christian

[sergey_korolev]

Place <b>SET UPDATE TASK LOCAL</b> statement before BAPI_PRODORDCONF_CREATE_TT call.

[Former Member]

I'm still having problems updating the characteristics despite using the local update, so no luck here. It is still only working when I place a breakpoint in the form that updates the characteristics.

Any other ideas? Here is a short flow in pseudo code of the calls:

Bapi PO confirmation

Bapi trans. commit.

when subrc 0.

_______perform update_batch.

__________call function validation maint.

__________call function class. save.

exit.

Thanks

Laurens

[sergey_korolev]

Try the following (putting it your way):

SET UPDATE TASK LOCAL.

Bapi PO confirmation

Bapi trans. commit.

when subrc 0.

SET UPDATE TASK LOCAL.

_______perform update_batch.

Bapi trans. commit.

__________call function validation maint.

__________call function class. save.

exit.

Update mode is reset to non local mode after each commit or rollback. So, you should do SET UPDATE TASK LOCAL before any piece of code which finishes with COMMIT.

[Former Member]

Still no result.

I've narrowed the problem down to the following. In my own routine to update the batch characteristics (BC) I also call function CUOB_GET_NUMBER to obtain the object number. This objectnumber should be read from the inob table. When I get to the point that is has to obtain this number, it isn't present in the inob (or mch1) table at that precise moment. I'm to early I think (or sap is to slow ). One possibility is to keep looping at the mch1 or inob table until there is a hit for the specific matnr batch combination, but that's not a nice solution in my opinion. Any more ideas?

Cheers and thanks

Laurens

[sergey_korolev]

If you experience different behavior of the program in debug mode and in online processing (some locks still locked, or some just created objects not found) then it's most likely the problem is in asynchronous updates. Maybe you should post some code fragments?

[Former Member]

Hi Laurens,

Instead of using the function module CUOB_GET_NUMBER, can you directly read INOB? I think the function module does a simle select, but in this case you may need to do a SELECT FROM INOB BYPASSING BUFFER, because your buffer is not yet updated with the latest values. So if you do the select bypassing the buffer, then you may get that value.

Regards,

Srinivas

[Former Member]

Hello Srinivas,

thank you for your reply. Unfortunatly still no positive result with bypassing buffer. The function of get_number does also use a parameter that makes sure it looks at the database first.

I know it is a problem with the updates. I can use a loop that keeps reading from the db until the record is found or a certain amount of seconds has passed. But not the best solution I think

Here are a few code snippets, maybe it 'll help (some parts are left out):

CALL FUNCTION 'BAPI_PRODORDCONF_CREATE_TT'

EXPORTING

testrun = ' '

IMPORTING

return = it_returnconf

TABLES

timetickets = it_timetickets

goodsmovements = it_goodsmovement

link_conf_goodsmov = it_link_conf_goodsmov

detail_return = it_detail_return.

IF NOT it_detail_return[] IS INITIAL.

READ TABLE it_detail_return WITH KEY type = 'E'.

...

ENDIF.

ENDIF.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

EXPORTING

WAIT = 'X'

IMPORTING

RETURN = return2.

.

• When finished, call form to update batch that was created by the goodsmovement of the ...CREATE_TT.

PERFORM adjust_batch.

(code of adjust batch).

• Objectnumber is combination of matnr and charg.

shift lo_objectnumber right deleting trailing space.

translate lo_objectnumber using ' 0'.

CALL FUNCTION 'CUOB_GET_NUMBER'

EXPORTING

class_type = '023'

object_id = lo_object

table = 'MCH1'

I_read_db_first = 'X'

IMPORTING

object_number = lo_objectnumber

EXCEPTIONS

lock_problem = 1

object_not_found = 2

OTHERS = 3.

IF sy-subrc <> 0.

...

ENDIF.

SELECT SINGLE * FROM kssk

WHERE objek = lo_objectnumber

AND klart = '023'

AND mafid = 'O'.

IF sy-subrc = 0.

SELECT SINGLE * FROM klah

WHERE clint = kssk-clint.

IF sy-subrc = 0.

etc....

*********

So I've tried all the hints and tips and things I could come up with but the fact remains that the inob / mch1 table is not updated during the commit after the create_tt bapi.

Any more ideas?

Cheers and happy Eastern!

Laurens

[sergey_korolev]

Hi Laurens,

Happy Easter to you too

I know it's a side problem, but to be honest, I don't like at all the way you calculate object number. I think you should better do this:

data:
  begin of objnum,
    matnr type mara-matnr,
    charg type mch1-charg,
  end of objnum.
  objnum-matnr = <your material num in internal format>.
  objnum-charg = <your batch num in internal format>.

  lo_object = objnum.

instead of

shift lo_objectnumber right deleting trailing space.
translate lo_objectnumber using ' 0'.

Is it a typo that you mentioned here <b>lo_objectnumber</b> instead of <b>lo_object</b>? (lo_objectnumber must be a result of 'CUOB_GET_NUMBER' call).

Besides this I insist that doing updates in local mode guarantees that after firing COMMIT WORK all the data affected by the update must be in place in the database. And to do this SET UPDATE TASK LOCAL should be placed before CALL FUNCTION 'BAPI_PRODORDCONF_CREATE_TT. Also the same should be done in the FORM adjust_batch.

[Former Member]

Hello Sergei,

thanks for the reply. Never thought about the objnum statement that you used. I just copied code that was already used in another program. But those are small details , uhm, btw: isn't there a conflict type when calling the function using the objnum definition like you used? It needs a character type. But again, small details.

About the update task local: I tried this statement in different locations (before the bapi and the call in the update_batch itself), but the result was none.

I'll try the method of calling the bapi for the create_tt in a separate function module and see what happens.

I really appreciate your time and effort!!

Cheers (from 2th eastern day in the Netherlands )

Laurens

[sergey_korolev]

Weird enough..

Concerning type conflict, certainly you cannot pass objnum structure as a parameter into the function module, you have to use intermediate variable lo_object. Or else you may do something like this:

lo_object(18) = matnr.

lo_object+18(10) = charg.

[Former Member]

LOL! To be honest, the lo_objnum+18 stuff is one of the parts that I left out

• Concatenate doesn't work all the time because of the char

• that can be in a material.

lo_object = p_p_gl_matnr.

lo_object+18(10) = p_p_gl_batch.

The part that I did post (about the translating) was only used when I did a direct selection on the mch1 table and shouldn't be there in combination with the cuob_getnumber function. That's the disadvantage of trying different methods and only commenting them out instead of deleting them. To much code

Good that you mentioned it btw

Cheers!

Laurens

[Former Member]

Hi Laurens.

Try to do the following. Make sure that the program buffer is deleted by changing the roll area.You can accomplish this by logging off and then logging in again for the BAPI process.

Here you have to adhere to the following procedure:

1. The call of the BAPI_PRODORDCONF_CREATE_TT and the subsequent call of BAPI BAPI_TRANSACTION_COMMIT or in case of an error of BAPI BAPI_TRANSACTION_ROLLBACK has to be included in a function module.

2. This function module must be called with command CALL FUNCTION func DESTINATION 'NONE'. As a result, the system opens a new roll area.

3. Then you must call function module RFC_CONNECTION_CLOSE.This function module closes the roll area of the function module.As a result, a new roll area is opened when you call a function module with DESTINATIN 'NONE' for the next time, and thus, for example, no more internal buffer data is available.

In your situation:

CALL FUNCTION Z_BAPI_PRODORDCONF_CREATE_TT DESTINATION 'NONE'

<the same import/export/exceptions sections of BAPI_PRODORDCONF_CREATE_TT>

CALL FUNCTION RFC_CONNECTION_CLOSE

EXPORTING destination = 'NONE'.

...

FUNCTION Z_BAPI_PRODORDCONF_CREATE_TT .

CALL FUNCTION 'BAPI_PRODORDCONF_CREATE_TT '.

...

IF 'no errors'.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.

ELSE.

CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.

ENDIF.

...

ENDFUNCTION.

Regards,

Maxim.