[ОТВЕТИТЬ]
09.11.2015 10:26
CriticalDays
 
Здравствуйте.

Открыли магазин, до этого он работал в прошлом году несколько месяцев.
Работает, чеки с кассы в УКМ загружает "нормально", но автоматически не выгружает в папку обмена с супермагом. Попытка выгрузить вручную даёт результат вот такой:

При попытке выгрузить одну смену получаем эту смену и кучу смен предыдущих, т.е. которые были в прошлом году.
При попытке выгрузить две смены этого года - выгружается самая последняя и куча прошлогодних, а самая первая смена в этом году нет.
Прошлогодние смены выгружаются правильно и загружаются в супермаг.

Смены этого года при попытке загрузить в супермаг через кассовый модуль "загружаются успешно", но из папки не исчезают и в супермаге не появляются.

В логах СМ2000\Дата не нашел ничего, в логах приложений винды тоже.

Сегодня еще сказали, что чеки неправильные выгружаются(вроде как позиции не такие), буду проверять.

Может кто чего подскажет, куда рыть?)
09.11.2015 11:14
vdm
 
А что менялось в этом УКМ между "закончил работать в прошлом году" и "начал работать в этом году". Перерегистрировали кассы, поменяли конвертер экспорта?
09.11.2015 11:30
CriticalDays
 
Оборудование прошлогоднее, конвертер старый, номер тот же

Магазин открывается на пару месяцев раз в год, его настройку вроде как никто не трогает, единственное - кассу заново заливал.

Меня смущает то, что когда выбираю нужную смену в конвертере там нумерация смен началась с единицы, а старые смены доступны не все и счет идёт с двадцати, но я не знаю должно быть так или нет.


С кассы выгрузился один чек, в котором три лишние позиции на возврат и одна нужная, хотя в чеке на продажу всего одна позиция. Но сумма продажи и возврата совпадает, на кассе в БД возврат был в 1 позицию, т.е. правильно.
Можно ли как-то аккуратно удалить только один чек на укм сервере и если да то как?
09.11.2015 11:41
CriticalDays
 
Есть вот такая строка в логах кассы

10:34:22: 0x00004000: WARNING: hw: Неизвестная подверсия (11) протокола ФР ШТРИХ. Возможны ошибки в работе
09.11.2015 11:59
vdm
 
Цитата:
CriticalDays в конвертере там нумерация смен началась с единицы
Похоже на кривую/незавершенную перезаливку кассы. В чеках номер смены тоже с начала пошел?

"Неправильные" чеки можно аннулировать через веб кассы. Но такая каша как тут началась аннулированиями не лечится.

Протокол ФР думаю ни при чем.
09.11.2015 12:03
Mtirt
 
Или обрезка чеков отработала неверно.
Версия УКМ4 какая?
09.11.2015 12:10
CriticalDays
 
Да, в чеках смены начались с единицы

версия 59 сп5
09.11.2015 12:15
CriticalDays
 
Еще почему-то в администрировании/отчеты он не может получить информацию по ЭКЛЗ
09.11.2015 12:46
CriticalDays
 
Цитата:
vdm Похоже на кривую/незавершенную перезаливку кассы.
можно ли решить эту проблему перезалив заново кассу?
Цитата:
vdm
"Неправильные" чеки можно аннулировать через веб кассы. Но такая каша как тут началась аннулированиями не лечится.
беда в том, что на кассе чек правильный, а вот на сервере нет
09.11.2015 12:59
CriticalDays
 
В УКМ зашел в операционный день, список закрытых смен

и там Дата закрытия смены 07.11.2015, а операционного дня 15.11.2014

может в этом беда?
09.11.2015 13:23
CriticalDays
 
он, кажется, перезаписывает смены оставляя старый операционный день и, видимо, сумму сданную

т.к. сумма очень отличается от суммы продаж.
09.11.2015 13:37
CriticalDays
 
отчет по кассовым сменам говорит, что номера смен ККМ идут почти по порядку, прошлый год смена ККМ 838, а сейчас 841
09.11.2015 15:33
vdm
 
Цитата:
CriticalDays можно ли решить эту проблему перезалив заново кассу?

беда в том, что на кассе чек правильный, а вот на сервере нет
Если на сервере все id попутались, то какой смысл заливать их на кассу.
Нужно сохранить на касе все что в этом году пробили и в том-же виде выгрузить чеки из УКМ?
Пока что видится вариант "грохнуть на сервере ВСЕ чеки этой кассы и поднять с кассы то что есть". Но номера смен останутся с единицы, а это косяк. Можно их предварительно в БД кассы поправить, но что и где - не скажу, не приходилось.
09.11.2015 15:49
CriticalDays
 
Нужно что бы чеки, которые пробьют завтра и т.д. выгружались нормально в супермаг.

Сейчас поменяю номер смены в веб кассы, может новая смена выгрузится нормально, хотя всё равно не знаю как поменять дату операционного дня.

В теории, если он перестанет тянуть старые операционные дни, то выгружать будет только нужное.
09.11.2015 17:14
Павел Сосновских
 
чтобы дальше было нормально, я бы предложил после закрытия смены сделать на вебе кассы синхронизацию с ккм
тогда следующие смены пойдут с указанным номером

остальные(старые) данные я бы предложил в укме оставить как есть
чтобы в супермаг это все затянуть - выгружаем в отдельную папку все, что есть
потом правим файлики(нужно знать их структуру, в хранилище и фтп с+ есть, правда в хранилище в укм2 надо смотреть)
потом скармливаем их кассовику
09.11.2015 17:21
CriticalDays
 
У нас особый штрих, которы
09.11.2015 17:28
CriticalDays
 
лан, без описания штриха )

в общем, сделал синхронизацию, перезагрузилась касса, аннулировали чек и выползло с новой сменой, но появилась смена с этим номером в конвертере экспорта, соответствующая дате операционного дня в прошлом году (т.к. чеки начало переписывать).

Получается, что эта смена только открыта на кассе, но уже можно выгрузить её, но только данные прошлогодние.

Вероятнее всего после закрытия смены он опять выгрузит фигню, но вопрос - дальше операционный день сменится на текущую дату или нет

Можно ли его как-то вручную поменять или он строго автоматически?
09.11.2015 23:20
Павел Сосновских
 
так почему нумерация повторяется? сколько смен было в прошлом году?
возможно синхронизацию уже делали на номер смены меньший чем последняя смена в прошлом году...
могло так случиться?
если у вас было, скажем, 62 смены в прошлом году и в этом, допустим 5, тогда надо выставить номер больше 67
если на фискальнике смены с первой снова в этом году пошли, то в укме они никуда не делись
тогда я бы при смене/обнулении/замене "мозгов" у ФР вообще создал новую кассу под новым номером

в общем, надо нумерацию смен продолжить, учитывая наличие прошлогодних смен.
механизм "синхронизация с ккм" в этом может помочь
10.11.2015 10:37
CriticalDays
 
Было всего 50 смен, я выставил 53 в надежде на то, что может две предыдущие отредактирую в 51 и 52, но видимо не буду

Фискальник на Z-отчете "продолжает номера смен", т.е. последний 838, а начались новые с 841 и продолжаются

Синхронизацию сделал, но он прибил новую смену к прошлогоднему операционному дню, т.е. не помогло, возможно новая смена будет нормальной, а может нет)

Беда еще в том, что касса присылает чеки с кучей лишних позиций, хотя на кассе, в БД, всё нормально. Восстановил из бэкапа, перезагрузил чеки, но фигня осталась.

Я думаю перезалить кассу, дать ей новый номер, а с текущими чеками что-то придумать.

Возможно и правда перенос с заблокированного терминала прошел неудачно, ибо данных многих нет на кассе.
10.11.2015 10:56
CriticalDays
 
Могут ли быть такие глюки, если в конфигурации магазина указана материнская плата Чек Вей ПОС 55, а я залил ПОС 55 на старую кассу, которая стояла в магазине с конфигурацией "материнская плата совместимая с РС" ?
10.11.2015 11:37
akonev
 
маловероятно. торгует же касса.
10.11.2015 11:38
akonev
 
судя по описанию, касса начала с нуля не номера смен и чеков, а их id.

прилетает с кассы смена и частично перетирает уже существующую на сервере прошлогоднюю.
пришел с кассы чек на одну позицию = затер первую позицию старого чека. но если в прошлом году чек с такими id был на три товара, то первую затер, а еще две "в наследство" получил от прошлогоднего.
10.11.2015 11:39
Mtirt
 
И, это скорее всего, результат некоректной обрезки чеков на кассе.
10.11.2015 11:42
akonev
 
присоединяюсь к:

Цитата:
vdm Если на сервере все id попутались, то какой смысл заливать их на кассу.
Нужно сохранить на касе все что в этом году пробили и в том-же виде выгрузить чеки из УКМ?
Пока что видится вариант "грохнуть на сервере ВСЕ чеки этой кассы и поднять с кассы то что есть". Но номера смен останутся с единицы, а это косяк. Можно их предварительно в БД кассы поправить, но что и где - не скажу, не приходилось.
править, я так понимаю, trm_out_shift_open.number
для проверки посмотреть последнюю смену, в которой синхронизацию делали.
10.11.2015 11:43
CriticalDays
 
может и обрезка, я не знаю, что с кассой делали после закрытия магазина в течении трех месяцев
10.11.2015 11:45
CriticalDays
 
смены в базе совпадают, а вот операционные дни новые не создаются
10.11.2015 11:49
akonev
 
Цитата:
CriticalDays смены в базе совпадают
расшифруй: что с чем сравниваешь?
10.11.2015 11:54
akonev
 
кстати, с чего бы новому опердню открываться?
с точки зрения сервера смена - старая. у него смена с таким ID с прошлого года лежит.

ну прилетела она в новой версии с кассы. она же не стала новая.
"всё очень хорошо, обновляем записи, в которых id совпадают" говорит сервер и сливает новую смену со старой.
10.11.2015 13:17
CriticalDays
 
trm_out_shift_open.number со сменой, которая должна быть

а вот айдишники да, с единицы, но в trm_line_oper_day я не вижу поля, по которому айдишник можно связать

значит там связь не прямая, может через пользователя

в trm_line_oper_day даты закрытия нет, может и не должно быть


это всё я в базе на кассе смотрю

еще, trm_out_shift_open.number - кроме смен этого года нет ничего, как и в таблицах по продажам (trm_out_receipt_header и т.п.), а вот в trm_line_oper_day все старые операционные дни есть, новых нет
10.11.2015 13:23
CriticalDays
 
а, он видимо по версии сравнивает

может попробовать версию поменять на кассе и он пойдет с нормальным отсчетом?


Опции темы


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

 

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