[ОТВЕТИТЬ]
16.04.2012 04:03
Tiger
 
Снимаю z-отчет появляется ошибка следующего вида:

Цитата:
Query failed: Error(1062)
Duplicate entry '2001013-264-0-1' for key 1
SQL INSERT IMTO trm_out_shift_payments (cash_id, id, payment, user, amount, version deleted)
SELECT 2001013, 264, payment
P.S Думал, что поможет закрытие смены через драйвер фискального регистратора, не помогло! Z-отчет достал в бумажном виде, а на кассе даже при открытии новой смены не получается снять z-отчет! На кассе использую УКМ4 версия 49 sp5 (обновился с версии 47 sp5)! C такой ошибкой на прошлой версии сталкиваться не приходилось! Ошибка появляется на кассах в разных магазинах!

Подскажите, что сделать?
16.04.2012 07:16
Mtirt
 
Поправить счетчик в таблице sequences ?
Правда мне непонятно, почему они могли у тебя слететь.
16.04.2012 08:52
Tiger
 
Цитата:
Mtirt Поправить счетчик в таблице sequences ?
Правда мне непонятно, почему они могли у тебя слететь.
Подскажите как? Чем подключиться к этой таблице и как поправить?
16.04.2012 08:58
Mtirt
 
А чем вы обычно подключаетесь к базам данных mysql?
16.04.2012 10:12
Kosh Naranek
 
Цитата:
Tiger Снимаю z-отчет появляется ошибка следующего вида:



P.S Думал, что поможет закрытие смены через драйвер фискального регистратора, не помогло! Z-отчет достал в бумажном виде, а на кассе даже при открытии новой смены не получается снять z-отчет! На кассе использую УКМ4 версия 49 sp5 (обновился с версии 47 sp5)! C такой ошибкой на прошлой версии сталкиваться не приходилось! Ошибка появляется на кассах в разных магазинах!

Подскажите, что сделать?
Подключитесь на кассу по SSH
Подключитесь к БД кассы:
mysql -uroot -Dukmclient -pCtHDbCGK.C

Выполните запросы:

delete from trm_out_shift_payments where id=264;
delete from trm_out_shift_close where id=264;

Лучше делать при остановленном укмклиенте.
Этими запросами вы добьетесь того, что дупликатов не возникнет, но две смены объединятся в одну. Закрывайте после этого смену и пусть работают дальше. Так будет корректнее. А вот почему это происходит - надо разибраться отдельно. Явно был какой-то сбой на кассе.
16.04.2012 10:47
Tiger
 
Цитата:
Kosh Naranek Подключитесь на кассу по SSH
Подключитесь к БД кассы:
mysql -uroot -Dukmclient -pCtHDbCGK.C

Выполните запросы:

delete from trm_out_shift_payments where id=264;
delete from trm_out_shift_close where id=264;

Лучше делать при остановленном укмклиенте.
Этими запросами вы добьетесь того, что дупликатов не возникнет, но две смены объединятся в одну. Закрывайте после этого смену и пусть работают дальше. Так будет корректнее. А вот почему это происходит - надо разибраться отдельно. Явно был какой-то сбой на кассе.
Данная ошибка возникла уже не на одной кассе, уже где-то порядка 5 касс по всей сети!

Сделал по предложенному алгоритму, z-отчет на кассе снялся, но теперь не могу загрузить в супермаг! В кассовом модуле ошибка:
Цитата:
В работе кассового модуля произошел сбой. Сообщения об ошибках см. ниже.
Запись 1. Код=80004005h (141) [SMUKMC~1]:
Таблицы Z-отчета в каталоге кассы не удалены, так как во время загрузки Z-отчета были обнаружены ошибки.
%2 %3 %4 %5 %6 %7 %8
16.04.2012 12:12
Mtirt
 
Так после чего это происходит?
Может была перезаливка информации с сервера?
Или какие-то другие действия?
Что с этими 5-ю кассами происходило?
16.04.2012 12:22
Tiger
 
Цитата:
Mtirt Так после чего это происходит?
Может была перезаливка информации с сервера?
Или какие-то другие действия?
Что с этими 5-ю кассами происходило?
Вот конкретно по кассе, с которой в данный момент разбираюсь! Эта касса в магазине используется крайне редко (пробивается товар под з/п, аренда и т.д.). Обновилась до версии 49 sp5 и не работала! Смена на кассе была закрыта, пробили аренду, начали снимать z-отчет - всё ошибка!
16.04.2012 12:25
Mtirt
 
Обрезка данных на кассах включена?
16.04.2012 12:30
Tiger
 
Цитата:
Mtirt Обрезка данных на кассах включена?
Не знаю, что это такое! Где посмотреть?
16.04.2012 12:44
Mtirt
 
Администрирование - Сервер - Удаление чеков.

У меня, просто есть предположение, что таблички пообрезались криво еще на 47 версии.
А сейчас в 49 версии ты просто "встал на эти грабли".
16.04.2012 13:15
Tiger
 
Удаление чеков с кассы и с сервера выключено! А как быть с этой-то ошибкой https://olegon.ru/showpost.php?p=113808&postcount=6

Добавлено через 23 минуты 25 секунд
Заметил еще, что оперативных чеков по кассам, на которых возникает данная ошибка, НЕТ!
16.04.2012 13:19
vdm
 
Ошибку Супермага - в супермаговскую ветку.
И выкладывай больше информации из журнала, там явно не только "во время загрузки Z-отчета были обнаружены ошибки", еще сообщения должны быть.
16.04.2012 14:28
Tiger
 
Ошибки относительно супермага здесь - https://olegon.ru/showthread.php?p=113855#post113855
16.04.2012 15:05
Mtirt
 
Кстати, я тоже заметила, что если на кассе долго не работают, то с неё перестают приходить опер.чеки.
И Z-отчеты приходится выгружать вручную.
16.04.2012 17:26
Tiger
 
Цитата:
Kosh Naranek Подключитесь на кассу по SSH
Подключитесь к БД кассы:
mysql -uroot -Dukmclient -pCtHDbCGK.C

Выполните запросы:

delete from trm_out_shift_payments where id=264;
delete from trm_out_shift_close where id=264;

Лучше делать при остановленном укмклиенте.
Этими запросами вы добьетесь того, что дупликатов не возникнет, но две смены объединятся в одну. Закрывайте после этого смену и пусть работают дальше. Так будет корректнее. А вот почему это происходит - надо разибраться отдельно. Явно был какой-то сбой на кассе.
А как сделать запрос, что обновить (изменить) id с 264 (например на 266) - это необходимо, чтобы не пересекаться уже с закрытыми сменами в супермаге. И скажется ли это как-то на работе кассе!
16.04.2012 22:07
Kosh Naranek
 
Цитата:
Tiger А как сделать запрос, что обновить (изменить) id с 264 (например на 266) - это необходимо, чтобы не пересекаться уже с закрытыми сменами в супермаге. И скажется ли это как-то на работе кассе!
В СМ+ смены не по ид выгружаются, а по number. Чтобы выставить нужный номер смены лучше воспользуйтесь штатным функционалом. Он доступен на вебе кассы в пункте меню "Синхронизация ККМ" . Выставляете там нужный номер смены - 1 и следующая смена будет с нужным вам номером.

А вообще если хотите обновлять в будущем запросом, то в данном случае он будет написан так:
update trm_out_shift_close set id=266 where id=264; (установить номер смены в 266 для записи с ид 264)
Но я вам категорично не рекомендую этого делать. Т.к. последствия могут быть плачевными. Данный ид смены во многих таблицах на кассе и на сервер используется, не хотите же вы всю БД перелопачивать.
17.04.2012 05:53
Tiger
 
Цитата:
Mtirt Поправить счетчик в таблице sequences ?
Правда мне непонятно, почему они могли у тебя слететь.
Подключился к mysql! Зашел в табличку sequences нашел id с номером (477) на который ругается кассы поправил на 478! Также поправил id 477 на 478 в таблице trm_out_shift_open, так как заметил что в таблице trm_out_shift_close запись с id 477 уже была! Z-отчет снялся на кассе, но в кассовике появилась ошибка https://olegon.ru/showpost.php?p=113916&postcount=7!

P.S. Хочу заметить, что эти ошибки происходят на фискальных регистраторах Штрих-ФР-К
17.04.2012 09:34
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
17.04.2012 09:37
Mtirt
 
Покажи trm_out_shift_open, я не совсем поняла, что не совпадает...
17.04.2012 09:43
Tiger
 
Цитата:
Mtirt Покажи trm_out_shift_open, я не совсем поняла, что не совпадает...
Вот trm_out_shift_open
Миниатюры
Нажмите на изображение для увеличения
Название: trm_out_shift_open.jpg
Просмотров: 375
Размер:	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 Кб, 71 просмотров)
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
Просмотров: 328
Размер:	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, время: 02:12.

 

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