COMMIT

FeBO-Sh

Добрый день, коллеги.

Создаю документ ММ (Заявка к примеру), в EXIT-е меняю одно поле. Это поле храниться в Z таблице, счетчик. Т.е. на каждую позицию документа ММ надо это поле сохранять в БД(обновлять) - отрабатывает коммит ворк, чтоб на второй строке или при параллельном создании документа значение этого поля не повторялось.
Так вот, собственно вопрос заключается в том, правильно ли делать коммит ворк при еще не созданном документе? Или есть более правильные решения? В общем-то хотелось бы чтоб при создании документа значение этого поля генерировалось для каждой позиции, но при этом в случае если документ не сохранять откатить сохранение в Z таблицу.
Заранее всем спасибо за участие.

Besa

По-моему, так Вам нужно пересмотреть свою логику, так как Вы написали - не делается.

Почему просто не используете счетчик(SNRO)? Вам ведь нужно чтобы значение поля не повторялось или есть какие другие условия? Судя по тому что Вы написали, нужно просто использовать счетчик(SNRO) и коммитить данные в Z таблицу при сохранении заявки через модуль обновления(или, если не ошибаюсь, там даже уже есть экзит, который в обновлении выполняется), если заявка не сохраниться, в Z таблицу ничего не попадет.

FeBO-Sh

Besa написал:

По-моему, так Вам нужно пересмотреть свою логику, так как Вы написали - не делается.

Почему просто не используете счетчик(SNRO)? Вам ведь нужно чтобы значение поля не повторялось или есть какие другие условия? Судя по тому что Вы написали, нужно просто использовать счетчик(SNRO) и коммитить данные в Z таблицу при сохранении заявки через модуль обновления(или, если не ошибаюсь, там даже уже есть экзит, который в обновлении выполняется), если заявка не сохраниться, в Z таблицу ничего не попадет.

Я все-таки немного не дописал условия выполнения. Присвоение не совсем счетчик, шаблон такой <счетчик без нолей> <буква при определенных условиях разная, в зависимости от выбранного материала>. Нужно сделать чтоб пользователь видел этот номер до сохранения документа а не после. Т.е. сгенерированный номер должен коммититься до сохранения при этом не задеть документ. Как такое правильно сделать понятия не имею. Может попробовать сделать коммит в параллельном процессе

Code:

STARTING NEW TASK '****'

?

bossjohn

FeBO-Sh написал:

Может попробовать сделать коммит в параллельном процессе

Code:

STARTING NEW TASK '****'

?

плохая идея - может запись и не создастся к тому моменту, когда вам надо

P.S. если не удается пересмотреть логику, можно написать свое ведение объекта нумерации - хоть буквы, хоть цифры.

Besa

FeBO-Sh написал:

Я все-таки немного не дописал условия выполнения. Присвоение не совсем счетчик, шаблон такой <счетчик без нолей> <буква при определенных условиях разная, в зависимости от выбранного материала>. Нужно сделать чтоб пользователь видел этот номер до сохранения документа а не после. Т.е. сгенерированный номер должен коммититься до сохранения при этом не задеть документ. Как такое правильно сделать понятия не имею. Может попробовать сделать коммит в параллельном процессе

Code:

STARTING NEW TASK '****'

?

х
Ваше доп условие никак не мешает сделать как я написал. Все это можно решить через счетчик + экзит. Пользователь будет видеть номер до сохранения, другое дело что если произойдет отмена создания заявки, то конечно точно такого номера Вы больше не увидите... Почему номер должен коммитися?? зачем его в базу сажать до сохранения дока? Про STARTING NEW TASK не понял вообще.

Может задачу расскажете? Может найдутся другие решения...

FeBO-Sh

Besa написал:

FeBO-Sh написал:

Я все-таки немного не дописал условия выполнения. Присвоение не совсем счетчик, шаблон такой <счетчик без нолей> <буква при определенных условиях разная, в зависимости от выбранного материала>. Нужно сделать чтоб пользователь видел этот номер до сохранения документа а не после. Т.е. сгенерированный номер должен коммититься до сохранения при этом не задеть документ. Как такое правильно сделать понятия не имею. Может попробовать сделать коммит в параллельном процессе

Code:

STARTING NEW TASK '****'

?

х
Ваше доп условие никак не мешает сделать как я написал. Все это можно решить через счетчик + экзит. Пользователь будет видеть номер до сохранения, другое дело что если произойдет отмена создания заявки, то конечно точно такого номера Вы больше не увидите... Почему номер должен коммитися?? зачем его в базу сажать до сохранения дока? Про STARTING NEW TASK не понял вообще.

Про STARTING NEW TASK я имел ввиду программно создать новый процесс и там в подпрограмме к примеру генерировать номер и коммитить. Я так полагаю коммит другого процесса не повлияет на операции другого процесса? Наверно я ошибаюсь.

Про SNRO, примерно вот это вы имеете ввиду?
1. В екзите EXIT_SAPLMEREQ_005 написать такой код:

Code:

CASE ...
WHEN '1'.
nr_range = '01'.
bukva = 'A'.
WHEN others.
nr_range = '02'.
bukva = 'B'.
ENDCASE.

CALL FUNCTION 'NUMBER_GET_NEXT'
  EXPORTING
    nr_range_nr             = nr_range
    object                  = 'ZTEST'
*   QUANTITY                = '1'
*   SUBOBJECT               = ' '
*   TOYEAR                  = '0000'
*   IGNORE_BUFFER           = ' '
  IMPORTING
    number                  = number
*   QUANTITY                =
    returncode              = returncode
  EXCEPTIONS
    interval_not_found      = 1
    number_range_not_intern = 2
    object_not_found        = 3
    quantity_is_0           = 4
    quantity_is_not_1       = 5
    interval_overflow       = 6
    buffer_overflow         = 7
    OTHERS                  = 8.
IF sy-subrc NE 0.
" MESSAGE TYPE 'E'.
RETURN.
ENDIF.
" Какие-то условия
CONCATENATE number bukrs INTO l_bednr SEPARATED space.
...

Цитата:

Может задачу расскажете? Может найдутся другие решения...

Ну задача в принципе не трудная, до создания документа генерировать номера (счетчик) + буковка по условию, главное чтоб эти присвоенные номера не повторялись в разных заявках. Вот и все ).

Besa

Задача понятная, решается просто, выше написано как.
STARTING NEW TASK отпадает.

Точного названия экзита не помню. Но в общих чертах, да, я имел в ввиду это + можно поднастроить сам объект номеров(подобъект).

FeBO-Sh

Besa написал:

Задача понятная, решается просто, выше написано как.
STARTING NEW TASK отпадает.

Точного названия экзита не помню. Но в общих чертах, да, я имел в ввиду это + можно поднастроить сам объект номеров(подобъект).

Спасибо большое, Besa.
Возникает другая засада, что делать если на один объект диапазона нельзя создать два диапазона (01, 02) начинающие с номера 1 к примеру? Они будут пересекаться...

Неужели создавать еще один объект со своим диапазоном?

bossjohn

FeBO-Sh написал:

Спасибо большое, Besa.
Возникает другая засада, что делать если на один объект диапазона нельзя создать два диапазона (01, 02) начинающие с номера 1 к примеру? Они будут пересекаться...

Неужели создавать еще один объект со своим диапазоном?

подобъект не поможет?

Besa

bossjohn написал(а):

FeBO-Sh написал:

Спасибо большое, Besa.
Возникает другая засада, что делать если на один объект диапазона нельзя создать два диапазона (01, 02) начинающие с номера 1 к примеру? Они будут пересекаться...

Неужели создавать еще один объект со своим диапазоном?

подобъект не поможет?

+1 Конечно поможет.

to FeBO-Sh, я ведь написал, смотрите подобъект, к Вашей задаче он там в самый раз

Это как раз то, что Вы называете "bukva" у себя в коде, это доп ключ к вашему диапазону. Не нужно плодить объекты номеров.

Правила форума

COMMIT

Кто сейчас на конференции