[ОТВЕТИТЬ]
17.04.2012 11:24
Tiger
 
Цитата:
Mtirt Для каждого чека?
Наверное всё же лучше так:
Код:
update trm_out_receipt_header set local_number=local_number+(Номер последнего чека за предыдущую дату),version=0 where date like '2012-04-16%';
Может я недопонимаю, но я уже z-отчет на кассе снял когда удалил задублированный z-отчет, как я повторно сниму z-отчет!
17.04.2012 11:27
akonev
 
тогда уж...

where shift_open=1049 and global_number>=368945

...отсюда и дальше пошли дубли.
17.04.2012 11:28
Mtirt
 
Этим запросом ты не снимаешь Z-отчет, ты корректируешь номера чеков для того, чтобы данные можно было выгрузить в Супермаг.
Потому как сейчас у тебя в одной смене есть чеки с одинаковыми номерами. И Супермаг на это и ругается ( в соседней ветке было сообщение).

Если сейчас на кассе смена закрыта, то лучше, как советует Kosh Naranek из web-а проставить правильный номер смены для Супермага.
17.04.2012 11:29
Mtirt
 
Цитата:
Andrew_Konev тогда уж...

where shift_open=1049 and global_number>=368945

...отсюда и дальше пошли дубли.
Так лучше :)
17.04.2012 11:35
Kosh Naranek
 
Цитата:
Kosh Naranek Если Tiger знает какие чеки в какую дату были(ну если одна смена помещается в одно число),то всего лишь надо на кассе остается выполнить запрос:

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

тогда в таких ситуациях наверна надо следующего алгоритма придерживаться: (поправьте, елси вру где-то опять)
1. остановить укмклиент
2. добавить trm_out_shift_open (ид ставить +1 от той. на которую ругается) - номер тоже корректный выставлять
3. исправить trm_out_receipt_header - запросом
update trm_out_receipt_header set shift_open=(поставить нужный),version=0 where date like '2012-04-16%';
4. исправитьtrm_out_moneyoperation
5. исправить sequences:
update sequences set id=номер_смены_который_добавляем where name='trm_out_shift_open';
6. проверяем local_state - значение shift_number

запустить укмклиент.
но не знаю нормалньо будет в результате выгружаться или нет.
17.04.2012 11:49
Tiger
 
Цитата:
Mtirt Этим запросом ты не снимаешь Z-отчет, ты корректируешь номера чеков для того, чтобы данные можно было выгрузить в Супермаг.
Потому как сейчас у тебя в одной смене есть чеки с одинаковыми номерами. И Супермаг на это и ругается ( в соседней ветке было сообщение).

Если сейчас на кассе смена закрыта, то лучше, как советует Kosh Naranek из web-а проставить правильный номер смены для Супермага.
А в какой БД mysql я должен корректировать номера чеков. Я так понимаю, что уже на сервер УКМ! И можно подробнее описать необходимый запрос!
17.04.2012 11:52
Mtirt
 
Вообще, Kosh Naranek изначально предлагал делать это на кассе.
Судя по тому, что корректируется и version, предполагается, что данные должны реплицироваться на сервер.
18.04.2012 08:38
Mtirt
 
Tiger, ты бы сказал, что сделал и какое сейчас состояние этой проблемы.
18.04.2012 11:36
Tiger
 
Цитата:
Mtirt Tiger, ты бы сказал, что сделал и какое сейчас состояние этой проблемы.
Сейчас все кассы работают (на все кассах снят z-отчет). Сняли z-отчет путем удаления задвоенных z-тов https://olegon.ru/showpost.php?p=113803&postcount=5! Но в супермаг выгрузить не могу причина описанной здесь https://olegon.ru/showthread.php?t=12286! Что и где поправить, чтобы не было задвоенных чеков или z-отчетов увы не знаю!

P.S. В Сервис плюс дали ответ на происходящее на кассах, причина обрыв бумаге вовремя выполнения операции на кассе с чеками (снятие z-отчета). Это относится точно к фискальным регистраторам Штрих-ФР-К!
18.04.2012 11:50
Mtirt
 
Цитата:
Tiger Что и где поправить, чтобы не было задвоенных чеков или z-отчетов увы не знаю!
Тот скрипт, который мы с Коневым предлагали выполнить ты не делал?
Он как раз для "убирания задвоенных" предлагался.

Код:
update trm_out_receipt_header set local_number=local_number+(Номер последнего чека за предыдущую дату),version=0 
where shift_open=1049 and global_number>=368945
18.04.2012 12:15
Tiger
 
Цитата:
Mtirt Тот скрипт, который мы с Коневым предлагали выполнить ты не делал?
Он как раз для "убирания задвоенных" предлагался.

Код:
update trm_out_receipt_header set local_number=local_number+(Номер последнего чека за предыдущую дату),version=0 
where shift_open=1049 and global_number>=368945
Этот запрос необходимо выполнить в mysql на кассе? А как эти поправленные чеки затем записать в mysql на сервере, я так понимаю, что при формировании файлов для выгрузки используются данные из mysql сервера?
18.04.2012 12:18
Mtirt
 
Отвечала же я вчера на этот вопрос.
На кассе.
Так как в запросе меняется и поле version, то данные записи будут помечены как измененные и касса попытается отдать их серверу.
18.04.2012 12:30
Tiger
 
Цитата:
Mtirt Тот скрипт, который мы с Коневым предлагали выполнить ты не делал?
Он как раз для "убирания задвоенных" предлагался.

Код:
update trm_out_receipt_header set local_number=local_number+(Номер последнего чека за предыдущую дату),version=0 
where shift_open=1049 and global_number>=368945
Номер последнего чека за предыдущую дату, а текущая дата - это какая? И откуда взято число 368945?
18.04.2012 12:32
Mtirt
 
368945 - из результатов запроса, который ты вчера выполнил по моей просьбе (вторая строчка).
В принципе, можешь отобрать на сервере чеки за смену № 1049 и найти чек, после которого локальные номера начинаются опять с 1.
18.04.2012 12:43
Tiger
 
Цитата:
Mtirt 368945 - из результатов запроса, который ты вчера выполнил по моей просьбе (вторая строчка).
В принципе, можешь отобрать на сервере чеки за смену № 1049 и найти чек, после которого локальные номера начинаются опять с 1.
Если можно помогите с запросом?
18.04.2012 12:45
Mtirt
 
Не поняла, с каким?
18.04.2012 12:58
Tiger
 
Цитата:
Mtirt Не поняла, с каким?
Извини не понял! Но на сервере нет смены с №1049! После удаления id=1049 запросом, смена закрылась 1050! Нужно смотреть номер чека для 1050 смены?
18.04.2012 13:26
Tiger
 
Я правильно понимаю предыдущая дата = 15.04.2012, а номер чека 1?
Вложения
Тип файла: rar Чеки на сервере.rar (160.1 Кб, 74 просмотров)
18.04.2012 13:30
Mtirt
 
Не, не 1. Отсортируй по дате.
18.04.2012 13:33
Tiger
 
Цитата:
Mtirt Не, не 1. Отсортируй по дате.
Отсортировал по дате
Вложения
Тип файла: rar Sort.rar (174.6 Кб, 66 просмотров)
18.04.2012 13:39
Mtirt
 
Издеваешься?
Во-первых, картинки можно загружать как картинки. Не обязательно заставлять меня скачивать архив и его открывать.
Во-вторых, зачем мне скрин первой страницы, если ты сам не можешь найти момент, когда заканчиваются чеки за 15 число и начинаются за 16.
18.04.2012 13:47
Tiger
 
Цитата:
Mtirt Издеваешься?
Во-первых, картинки можно загружать как картинки. Не обязательно заставлять меня скачивать архив и его открывать.
Во-вторых, зачем мне скрин первой страницы, если ты сам не можешь найти момент, когда заканчиваются чеки за 15 число и начинаются за 16.
Извиняюсь! Я не до конца понял, а отдельно картинку загрузить не получилось, так как велика! Т.е правильный номер чека это последний чек за 15.04.2012! Надеюсь, сейчас всё верно я понял!

P.S. Если все верно, завтра попробую и отпишусь о результате!
18.04.2012 15:25
Павел Сосновских
 
А чего это все так дружно предлагают менять id в trm_out_receipt_header?
там же куча ссылок на них trm_out_receipt_items...(_discounts, _payment, _footer, _subtotal...)
и еще оч. много. Развалите все чеки.
18.04.2012 15:37
Mtirt
 
Так я предлагаю менять local_number, на него нет ссылок.
18.04.2012 17:19
Павел Сосновских
 
Вообще все по порядку.
Почему возникла ошибка? Про бумагу - вариант, но не единственный. Может быть так:
1. укм послал команду в фр на закрытие смены
2. фр закрыл у себя, но что-то пошло не так(например, бумага кончилась) вернул ошибку и в укм'е смена не закрылась ИЛИ, наоборот, в фр ошибка и смена не закрыта, а укм'у об этом не сообщил и в укм'е смена закрылась.
3. есть расхождение в закрытиях смен в фр и укм.

Что делать?
если в укм закрыто, в фр - нет. подключаем фр куда-то еще с драйвером и закрываем руками.
если наоборот:
1.на кассе дописываем строку в trm_out_shift_close, соответствующую последней строке в trm_out_shift_open: "insert into trm_out_shift_close..."(уж погуглите mysql insert)
id из trm_out_shift_open
version на единицу больше последней записи в trm_out_shift_close
date - нужный
остальные поля должны быть понятны(соответствуют последней записи в trm_out_shift_close), значения полей некоторые в кавычках в соответствии с типом(можно все в кавычках - не ошибетесь)

На кассе смена закрылась

2. на сервере "update cnv_table_client_versions set latest_version=<немного поменьше выше вставленного> where table_name='trm_out_shift_close' and mysterious_id=<cash_id нашей кассы>"

Серверу сказали затянуть эти данные

3. рестарт службы укм сервера или кассы

Данные поднялись на сервер
19.04.2012 07:15
Mtirt
 
Ты не совсем прав в данной ситуации.
Дело не в том, что смена не закрылась.
Там было интереснее.
У автора смена 1049 закрылась и выгрузилась в Супермаг.
А потом касса начала снова пробивать чеки с ЭТИМ же номером смены.
Причем опять, начиная с первого номера чека.
И при снятии Z-отчета автор получил сообщение об ошибке.
19.04.2012 09:47
Tiger
 
Решился на эксперимент, но возник вопрос: в запросе указана 1049 смена, а на сервере мы отбирали чеки за 1050! Какую смену указывать в запросе? Какой вариант выбрать? global_number>=368945 или какой-то другой?

1) update trm_out_receipt_header set local_number=local_number+(Номер последнего чека за предыдущую дату),version=0
where shift_open=1049 and global_number>=368945

2) update trm_out_receipt_header set local_number=local_number+(Номер последнего чека за предыдущую дату),version=0
where shift_open=1050 and global_number>=368945
19.04.2012 10:13
Mtirt
 
Выбрать 1049. Это id смены
1050 - это номер, отдаваемый внешней программе.
19.04.2012 10:46
Tiger
 
Выполнил запрос успешно, было поправлено порядка 525 записей! Но при выгрузке в супермаг ошибка сменилась с https://olegon.ru/showpost.php?p=113916&postcount=7 на https://olegon.ru/showpost.php?p=113855&postcount=1. На смены прошу не обращать внимание, так как с разных магазинов сообщения об ошибках!


Опции темы


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

 

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