[ОТВЕТИТЬ]
Опции темы
10.07.2017 14:36
 
Добрый день, уважаемые. Сразу скажу, человек я в настройке УКМ случайный, область деятельности у меня смежная. В процессе работы возникла необходимость менять состояние бонусного счета клиента в УКМ4. Техподдержка сообщила, что сделать это можно через конвертер Импорт4, таблицу clients_operations. Результат соотв. как я себе это представляю должен появиться в базе ukmserver таблице trm_out_aoo.

Мучаюсь с ней уже 2 дня, и честно говоря пока с нулевым эффектом. Заполняю поля следующим образом:
id - числовой номер операции, делаю случайное число (пробовал разной длины)
account_id - номер типа счета, беру в т.ч. по аналогии из trm_out_aoo
client - client_id из trm_in_clients
number равен id
date
operation_date - обе ставлю сегодняшним числом
amount - размер изменения счета
type - 0
version - 0

Подскажите пожалуйста, может у вас будут соображения что я делаю не так? Возможно надо что-то записывать в какую то еще таблицу? Куда эти данные в итоге идут на УКМ?

Заранее большое спасибо.
"Спасибо" luciphur от:
10.07.2017 14:42
 
Надо. Таблицу signal.



Цитата:
Значения сигнала о состоянии процесса
Внимание!
Начиная с версии MySQL 5.5, при написании запроса название таблицы "Signal" необходимо заключать в апострофы, т.к. слово "signal" является ключевым.

Пример запроса:

select count(*) from `signal` where `signal`='busy'

Значение сигнала о состоянии процесса импорта хранится в поле signal таблицы signal. Поле может принимать одно из следующих значений:

cumm – сигнал помещается торговой системой и означает, что торговая система подготовила данные, которыми необходимо полностью заменить данные в СуперМаг-УКМ V.4.0 (полная загрузка данных);
incr – сигнал помещается торговой системой и означает, что торговая система подготовила данные, которые содержат в себе только изменения (частичная загрузка данных);
busy – сигнал помещается СуперМаг-УКМ V.4.0 и означает, что конвертер выполняет импортирование данных (конвертер занят).

Первые два сигнала выставляются торговой системой по окончании операции экспортирования, поскольку являются сигналами начала процесса импортирования в СуперМаг-УКМ V.4.0.
Схема взаимодействия систем

Взаимодействие систем состоит из следующих шагов: 1. торговая система проверяет готовность СуперМаг-УКМ V4.0 принять данные. Если СуперМаг-УКМ V4.0 готов принять данные, то торговая система выполняет экспорт данных. Если СуперМаг-УКМ V4.0 не готов принять данные, то торговая система приостанавливает экспорт данных.

Для того чтобы убедиться в том, что СуперМаг-УКМ V4.0 готов принять данные, следует выполнить запрос:

select count(*) from signal where signal='busy'

Нулевое значение означает, что СуперМаг-УКМ V4.0 готов к приему данных.

2. Если СуперМаг-УКМ V4.0 готов принять данные, торговая система проверяет закончился ли предыдущий экспорт данных в СуперМаг-УКМ V4.0 (т.е. сигналов cumm или incr нет).

Если эти сигналы есть, то торговая система удаляет их.

3. Торговая система заполняет таблицы данных и формирует соответствующую запись в таблице signal. Запись в таблице signal информирует сервер СуперМаг-УКМ V4.0 о произведённых изменениях и одновременно является сигналом для начала операции импортирования.

4. Стандартный конвертер СуперМаг-УКМ V4.0 проверяет запись таблицы signal. Если запись хранит информацию о том, что торговая система подготовила данные, конвертер СуперМаг-УКМ V4.0 помещает значение busy в поле signal и начинает импорт данных. После чтения информации СуперМаг-УКМ V4.0 удаляет ее из таблиц.

5. По окончании процесса импорта конвертер СуперМаг-УКМ V4.0 удаляет сигнал о занятости из таблицы signal.
Очередь сигналов и данных

Приведенная схема взаимодействия систем работает для случая, когда экспортированные из торговой системы данные сразу импортируются в СуперМаг-УКМ V4.0. Если есть вероятность того, что СуперМаг-УКМ V4.0 не успеет обработать предыдущий экспорт данных из торговой системы до готовности нового, следует организовать очередь сигналов и данных. Для этого используется поле version, хранящее номер версии данных (номер экспорта данных из торговой системы).

Поле version хранится в каждой таблице данных и таблице сигналов. При подготовке данных поле version заполняется значением счётчика. При формировании сигнала поле signal.version имеет тоже самое значение, что и в данных. То есть, если к моменту готовности новой порции данных конвертер СуперМаг-УКМ V4.0 сообщает, что находится в процессе импортирования данных, либо не приступал к импортированию предыдущих данных, то необходимость в приостановке экспорта данных из торговой системы отпадает. В этом случае торговая система увеличивает номер версии на 1 и формирует новый пакет.
Полная и частичная загрузка данных

Стандартный конвертер поддерживает полную и частичную загрузку данных в СуперМаг-УКМ V4.0. В случае полной загрузки данные импортируются в СуперМаг-УКМ V4.0 без сохранения предыдущего состояния.

В случае частичной загрузки следует выделять две операции: добавление новой (или корректировка старой) и удаление записи. В последнем случае в поля delete в таблице данных установить значение «1». Значения всех полей, кроме ключевых, при удалении роли не играют. Эти поля могут оставаться пустыми или иметь значение по умолчанию.
10.07.2017 14:43
 
Таблицу signal я естественно заполняю, соотв. incr и version 0. Данные исчезают из таблиц конвертера, в таблице trm_out_aoo не появляются.
10.07.2017 14:51
 
А они точно в эту таблицу должны реплицироваться? А не в какую-нибудь trm_auth_local_storage?
10.07.2017 14:57
 
Сложный вопрос, баллы, приходящие с кассовых терминалов, пишутся именно в эту таблицу.
10.07.2017 15:02
 
Судя по цифрам, в trm_auth_local_storage хранится некий подытог по кассовым терминалам, а не баланс счета клиента. Могу ошибаться конечно.
10.07.2017 15:57
 
Данные должны появится вот тут

local_auth_account_journal Журнал операций по счёту

Название поля Тип данных Размер Значение Описание
id INTEGER 11 Not Null Идентификатор
account_id INTEGER 11 Not Null ссылка на таблицу local_auth_account
amount DECIMAL 20 Not Null сумма операции ("+" - приход, "-" - расход
date DATETIME Not Null учётная дата операции
source_type SMALLINT 6 Not Null источник операции (происхождение операции по счёту)
source_id VARCHAR 40 Not Null идентификатор источника (чека, документа, сумматора и др.)
cash_id BIGINT 20 Not Null идентификатор кассы (например, для выяснения происхождения чека) (если не по кассе то значение 0)
comment TEXT свободный комментарий
balance DECIMAL 20 Not Null остаток по счёту после проведения данной операции по счёту
action_date DATETIME Not Null реальная дата операции
"Спасибо" AlgolB от:
10.07.2017 16:03
 
проверьте правильно ли вы задаете значение
import.clients_operations.account_id,
import.clients_operations.CLIENT,
"Спасибо" AlgolB от:
10.07.2017 16:05
 
Цитата:
AlgolB Данные должны появится вот тут

local_auth_account_journal Журнал операций по счёту
Там тоже не появляется (

Сразу вопрос - а client в import4.clients_operations должен соответствовать id в local_auth_account или params в нем же?
10.07.2017 16:06
 
Цитата:
AlgolB проверьте правильно ли вы задаете значение
import.clients_operations.account_id,
import.clients_operations.CLIENT,
Подскажите откуда правильно брать эти величины.
Я выше писал, откуда беру я.


Опции темы



Часовой пояс GMT +3, время: 01:26.

Все в прочитанное - Донат - RSS - - Карта - Вверх

Форум сделан на основе vBulletin®
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.