В СРМ OneBox была добавлена процедура, которая при каждом сохранении заказа записывает значение '1' в дополнительное поле. На основе этого поля реализована интеграция между системой OneBox - 1С исчезла.
В СРМ OneBox была добавлена процедура, которая при каждом сохранении заказа записывает значение '1' в дополнительное поле. На основе этого поля реализована интеграция между системой OneBox - 1С исчезла.
Описание проблемы:
В СРМ OneBox добавлена процедура, которая при каждом сохранении заказа записывает значение '1' в дополнительное поле. На основе этого поля реализована интеграция между системой OneBox – 1С (данное дополнительное поле служит признаком необходимости обновления
объекта заказа). После обновления (допускаем последнего) изменилось поведение реагирования данной процедуры на обновление заказа через API.
Ранее, до обновления, редактирования заказа через API 'не триггерила' данную процедуру, и после чтения/интеграции изменений для каждого прочитанного заказа ставился соответствующий признак ('0'), на основе чего такой заказ в дальнейшем
не возделывалось.
На данный момент, при редактировании заказа через API (запись '0' в дополнительное поле признака) триггерит описанную выше процедуру, и система трактует такой заказ как обновленный и соответственно повторно 'переписывает' значение признака в '1'.
Таким образом, нет возможности поставить признак завершения чтения и приходится читать абсолютно все заказы (которых тысячи)
Описание возможного наследия:
Вариант 1. Не трактовать заказ (или другой процесс) измененным, когда идет обновление конкретного дополнительного поля (название поля - 'update_o', идентификатор поля в системе - 'update')
Вариант 2. Не трактовать заказ (или другой процесс) измененным, когда идет обновление его дополнительных полей через API
Вариант 3. Не трактовать заказ (или другой процесс) измененным, когда идет его обновление через API
Приоритетность в порядке убывания. Мы хотим заказать за средства решения этой проблемы!!!!!!!
Описание проблемы: В СРМ OneBox добавлена процедура, которая при каждом сохранении заказа записывает значение '1' в дополнительное поле. На основе этого поля реализована интеграция между системой OneBox – 1С (данное дополнительное поле служит признаком необходимости обновления объекта заказа). После обновления (допускаем последнего) изменилось поведение реагирования данной процедуры на обновление заказа через API. Ранее, до обновления, редактирования заказа через API 'не триггерила' данную процедуру, и после чтения/интеграции изменений для каждого прочитанного заказа ставился соответствующий признак ('0'), на основе чего такой заказ в дальнейшем не возделывалось. На данный момент, при редактировании заказа через API (запись '0' в дополнительное поле признака) триггерит описанную выше процедуру, и система трактует такой заказ как обновленный и соответственно повторно 'переписывает' значение признака в '1'. Таким образом, нет возможности поставить признак завершения чтения и приходится читать абсолютно все заказы (которых тысячи) Описание возможного наследия: Вариант 1. Не трактовать заказ (или другой процесс) измененным, когда идет обновление конкретного дополнительного поля (название поля - 'update_o', идентификатор поля в системе - 'update') Вариант 2. Не трактовать заказ (или другой процесс) измененным, когда идет обновление его дополнительных полей через API Вариант 3. Не трактовать заказ (или другой процесс) измененным, когда идет его обновление через API Приоритетность в порядке убывания. Мы хотим заказать за средства решения этой проблемы!!!!!!!
Пожалуйста, присоединяйтесь к диалогу. Если вам есть что сказать - пожалуйста, напишите комментарий. Для входа потребуется мобильный телефон и смс-код для идентификации.
Войти и написать комментарий