17.04.2012 09:43
Tiger
 
Цитата:
Mtirt Покажи trm_out_shift_open, я не совсем поняла, что не совпадает...
Вот trm_out_shift_open
Миниатюры
Нажмите на изображение для увеличения
Название: trm_out_shift_open.jpg
Просмотров: 654
Размер:	192.8 Кб
ID:	1194  
17.04.2012 09:52
Mtirt
 
1050 - это тот номер, который будет отдан Супермагу, и, который, по идее, совпадает с тем, что есть в фискальнике.
Никакого влияния на сам УКМ4 он не оказывает.
В УКМ4 надо ориентироваться на 1049, который должен быть
в trm_out_shift_close (если смена точно закрыта) и в trm_out_receipt_header.
Ну и если смена в trm_out_shift_close точно закрыта то в sequences должно быть 1050.
А если записи нет, то может быть попробовать закрыть смену?
17.04.2012 09:55
Kosh Naranek
 
Цитата:
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 зет-отчета.
Далее сиквенсы теже самые в новых версиях выставлять на правильные всегда проще с помощью веба кассы имхо. Он и смену нужну. выставит и сиквенсы поправит.
И это ненормально, что у вас такое происходит. Покажите лог кассы за тот день, когда были такие ситуации, а лучше за два дня. Явно там были какие-то ошибки
17.04.2012 10:13
Tiger
 
Цитата:
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!
17.04.2012 10:17
Tiger
 
Цитата:
Kosh Naranek Имхо слишком много ненужных действий и слишком большой риск потерять целостность данных. Не надо ид менять, плохо это. Сиквенсы можно, но не ид.
Проще, как ранее сообщалось, удалить последние trm_out_shift_payments и trm_out_shift_close и закрыть смену штатно.
Единственный минус который тут возникнет, что продажи за два ждня попадут в супермаг как одна смена, но будет 2 зет-отчета.
Далее сиквенсы теже самые в новых версиях выставлять на правильные всегда проще с помощью веба кассы имхо. Он и смену нужну. выставит и сиквенсы поправит.
И это ненормально, что у вас такое происходит. Покажите лог кассы за тот день, когда были такие ситуации, а лучше за два дня. Явно там были какие-то ошибки
Я сделал по-твоему алгоритму, но возникла ошибка при загрузки в супермаг, якобы такая смена уже закрыта! Логи с кассы:
Вложения
Тип файла: rar Log.rar (19.7 Кб, 87 просмотров)
17.04.2012 10:27
Mtirt
 
А покажи результат запроса:
Код:
select * from trm_out_receipt_header where shift_open=1049 and local_number=1
17.04.2012 10:37
Tiger
 
Цитата:
Mtirt А покажи результат запроса:
Код:
select * from trm_out_receipt_header where shift_open=1049 and local_number=1
Надеюсь, что правильно выполнил:
Миниатюры
Нажмите на изображение для увеличения
Название: Запрос.jpg
Просмотров: 599
Размер:	107.7 Кб
ID:	1196  
17.04.2012 10:53
Mtirt
 
В принципе, видно, что две строки отобрались.
Kosh Naranek, ты результат своих предложений видишь?
Смену Tiger то закрыл в УКМ4.
Только эти данные НИКОГДА не будут приняты Супермагом из-за банального дублирования номеров чеков.
17.04.2012 11:02
Kosh Naranek
 
Цитата:
Mtirt В принципе, видно, что две строки отобрались.
Kosh Naranek, ты результат своих предложений видишь?
Смену Tiger то закрыл в УКМ4.
Только эти данные НИКОГДА не будут приняты Супермагом из-за банального дублирования номеров чеков.
Если Tiger знает какие чеки в какую дату были(ну если одна смена помещается в одно число),то всего лишь надо на кассе остается выполнить запрос:

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

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