Ошибка при снятии Z-отчета на кассе : УКМ-4

Tiger · █ 17.04.2012 09:43

Цитата:

Mtirt ➤ Покажи trm_out_shift_open, я не совсем поняла, что не совпадает...

Вот trm_out_shift_open

Mtirt · █ 17.04.2012 09:52

1050 - это тот номер, который будет отдан Супермагу, и, который, по идее, совпадает с тем, что есть в фискальнике.
Никакого влияния на сам УКМ4 он не оказывает.
В УКМ4 надо ориентироваться на 1049, который должен быть
в trm_out_shift_close (если смена точно закрыта) и в trm_out_receipt_header.
Ну и если смена в trm_out_shift_close точно закрыта то в sequences должно быть 1050.
А если записи нет, то может быть попробовать закрыть смену?

Kosh Naranek · █ 17.04.2012 09:55

Цитата:

Tiger ➤ Опишу последовательность своих действии:

1. Беру магазин с кассой, на которой не могу снять z-отчет;
2. Захожу в УКМ на сервер, смотрю номера отчетов (через конвертер) по этой кассе. Вижу последовательность отчетов 1045, 1046, 1047, 1048, ..., 1050
3. Еду на кассу проверять на какой там отчет ругается, оказывается отчет, который будто бы дублируется, тот же что и отсутствующий в приведенной линейке выше;
4. Подключаюсь к БД ukmclient, первым делом смотрю таблицу (sequences), в неё Mtirt предложила заглянуть, смотрю значение trm_out_shift_open оно равно 1049
5. Проверяю еще таблицы trm_out_shift_open в ней значение id и number не совпадают в отличии от предыдущих смен, а в таблице trm_out_shift_close уже присутствует запись id 1049.

Теперь вопрос: На какое значение и где необходимо поменять, чтобы и на кассе всё закрылось и в супермаг выгрузилось!

P.S. Пробовал править на другом магазине id 477 на 478 в таблице sequences и trm_out_shift_open. Получил снятие z-отчета на кассе и ошибку в супермаге https://olegon.ru/showpost.php?p=113916&postcount=7

Имхо слишком много ненужных действий и слишком большой риск потерять целостность данных. Не надо ид менять, плохо это. Сиквенсы можно, но не ид.
Проще, как ранее сообщалось, удалить последние trm_out_shift_payments и trm_out_shift_close и закрыть смену штатно.
Единственный минус который тут возникнет, что продажи за два ждня попадут в супермаг как одна смена, но будет 2 зет-отчета.
Далее сиквенсы теже самые в новых версиях выставлять на правильные всегда проще с помощью веба кассы имхо. Он и смену нужну. выставит и сиквенсы поправит.
И это ненормально, что у вас такое происходит. Покажите лог кассы за тот день, когда были такие ситуации, а лучше за два дня. Явно там были какие-то ошибки

Tiger · █ 17.04.2012 10:13

Цитата:

Mtirt ➤ 1050 - это тот номер, который будет отдан Супермагу, и, который, по идее, совпадает с тем, что есть в фискальнике.
Никакого влияния на сам УКМ4 он не оказывает.
В УКМ4 надо ориентироваться на 1049, который должен быть
в trm_out_shift_close (если смена точно закрыта) и в trm_out_receipt_header.
Ну и если смена в trm_out_shift_close точно закрыта то в sequences должно быть 1050.
А если записи нет, то может быть попробовать закрыть смену?

В супермаге нет z-отчет за №1049 и в УКМ сервере тоже в списке нет, в trm_out_shift_close id 1049 и trm_out_receipt_header есть. А sequences = 1049!

Tiger · █ 17.04.2012 10:17

Цитата:

Kosh Naranek ➤ Имхо слишком много ненужных действий и слишком большой риск потерять целостность данных. Не надо ид менять, плохо это. Сиквенсы можно, но не ид.
Проще, как ранее сообщалось, удалить последние trm_out_shift_payments и trm_out_shift_close и закрыть смену штатно.
Единственный минус который тут возникнет, что продажи за два ждня попадут в супермаг как одна смена, но будет 2 зет-отчета.
Далее сиквенсы теже самые в новых версиях выставлять на правильные всегда проще с помощью веба кассы имхо. Он и смену нужну. выставит и сиквенсы поправит.
И это ненормально, что у вас такое происходит. Покажите лог кассы за тот день, когда были такие ситуации, а лучше за два дня. Явно там были какие-то ошибки

Я сделал по-твоему алгоритму, но возникла ошибка при загрузки в супермаг, якобы такая смена уже закрыта! Логи с кассы:

Mtirt · █ 17.04.2012 10:27

А покажи результат запроса:

Код:

select * from trm_out_receipt_header where shift_open=1049 and local_number=1

Tiger · █ 17.04.2012 10:37

Цитата:

Mtirt ➤ А покажи результат запроса:

Код:

select * from trm_out_receipt_header where shift_open=1049 and local_number=1

Надеюсь, что правильно выполнил:

Mtirt · █ 17.04.2012 10:53

В принципе, видно, что две строки отобрались.
Kosh Naranek, ты результат своих предложений видишь?
Смену Tiger то закрыл в УКМ4.
Только эти данные НИКОГДА не будут приняты Супермагом из-за банального дублирования номеров чеков.

Kosh Naranek · █ 17.04.2012 11:02

Цитата:

Mtirt ➤ В принципе, видно, что две строки отобрались.
Kosh Naranek, ты результат своих предложений видишь?
Смену Tiger то закрыл в УКМ4.
Только эти данные НИКОГДА не будут приняты Супермагом из-за банального дублирования номеров чеков.

Если Tiger знает какие чеки в какую дату были(ну если одна смена помещается в одно число),то всего лишь надо на кассе остается выполнить запрос:

update trm_out_receipt_header set number=(поставить нужный),version=0 where date like '2012-04-16%';
дату тоже изменить на нужную.
После перезапустить или кассу или службу сервера.
После этого ОБЯЗАТЕЛЬНО на вебе кассы сделать синхронизацию ккм и выставить тот номер смены, который указали в запросе выше. Чтобы следующие чеки и смена шли следующим номером.
Т.к. в см+ выгрущка идет именно по намберу, а не по ид. Думаю должно помочь.
Но может лучше не химичить а куда-нибудь в ТП обратится. Вдруг все хуже.

Mtirt · █ 17.04.2012 11:22

Для каждого чека?
Наверное всё же лучше так:

Код:

update trm_out_receipt_header set local_number=local_number+(Номер последнего чека за предыдущую дату),version=0 where date like '2012-04-16%';