Логическая дата отличаентся от даты SYSTEM.DB [Архив] - Карбис -R-Keeper, StoreHouse - Комплексная автоматизация ресторанного бизнеса

Просмотр полной версии : Логическая дата отличаентся от даты SYSTEM.DB

banch

02.01.2016, 11:50

Добрый день,
столкнулся с такой проблемой.
Логическая дата на сервере (если смотреть на кассовой станции или через монитор) отличается от даты вбитой через setcodat.exe.
В system.db стоит дата 02.01.2016, сервер показывает 03.01.2016, если изменить дату в SYSTEM.DB, то сервер все равно показывает на один день больше.
Кто нибудь сталкивался?

02.01.2016, 13:33

system.db смотрите не там.

walikos

09.01.2016, 00:27

system.db смотрите не там.

Всегда смотрю в DATABASE. У меня та же проблема, логическая дата с нового года отличается от даты в SYSTEM.DB на 1 день!!! Причем на нескольких объектах!!!:elka:

sibgaba

09.01.2016, 10:55

Причем на нескольких объектах!!!
И очевидно что все эти объекты 1-го числа не работали...

Проблема то в чем?

walikos

09.01.2016, 22:38

Раньше переводил дату с пом setkodat, все было нормально, какую дату установил в п.1, такая и появляется на кассе. А с нового года нужно почему то устанавливать дату в setkodat на один день меньше, чем должна быть!!! Нужно 8-е число, приходится ставить 7-е!!!!

Admin

09.01.2016, 23:34

Я знаю в чем дело!!! Рамблер виноват....

ZiG1982

11.01.2016, 10:34

Точно такая же ерунда на нескольких объектах, в system.db одна дата, на кассах в логик дате на число больше...

walikos

11.01.2016, 10:41

Я знаю в чем дело!!! Рамблер виноват.... Это, скорее проделки госдепа:p

Rus75lan

12.01.2016, 08:49

Точно такая же ерунда на нескольких объектах, в system.db одна дата, на кассах в логик дате на число больше...
Подтверждаю.
Когда закидываешь system.db, сервер при запуске переводит дату на день вперед.

mcmaster

18.01.2016, 20:10

И я подтверждаю. Что случилось то?
Объект работает 3 дня в неделю. Сегодня смотрел на сервере 18 и на станции 18. Перевожу на 22. В system.db 22 на станции 23.

---------- Добавлено в 19:10 ---------- Предыдущее сообщение было размещено в 17:23 ----------

Ха.. Закусился на трекере по этому вопросу....
Как всегда, не ищут в чём проблема а навязывают Контроль логической даты - LOGDATE.DLL
Вот как то так...

Вопрос
Т.е. объект работал без этой dll несколько лет, а теперь без неё работать правильно не будет?
Ответ
Вы можете проверить у себя на стенде ситуацию и разобраться в причине возникновения данной ситуации, я же предлагаю вам, на мой взгляд, более быстрый способ решения проблемы.
:facepalm::facepalm::facepalm:

19.01.2016, 00:26

Как всегда, не ищут в чём проблема
Тут не совсем так... На саппорте же ясно выразились - такими некритичными багами в rk6 больше не будут заниматься. Всю жизнь setcodat нормально работал, что-то случилось, но увы.

lEEFT

20.01.2016, 12:33

А с нового года нужно почему то устанавливать дату
Может год високосный? :)

20.01.2016, 16:22

Я тоже подумал про високосный, но раньше в високосные года не было такой проблемы. Надо посмотреть, какая дата в system.db пишется.

walikos

22.01.2016, 23:32

Даже самый самый в UCS подтвердил на http://tracker.ucs.ru:8080/redmine/issues/70368:

Подтверждаю - если использовать SETCODAT.EXE под Windows, дата на кассе "убегает" на один день вперед, хотя в самой программе SETCODAT.EXE дата отображается корректно.

Если использовать SETCODAT.EXE под DOS, проблема не проявляется.

Во вложении два варианта SYSTEM.DB, обработанные одинаковыми сборками SETCODAT.EXE, но под разными ОС - при бинарном сравнении есть различия.

okis

23.01.2016, 09:43

Мелкомягкие начали кибервойну против нас.:)

sibgaba

23.01.2016, 15:17

Подтверждаю - если использовать SETCODAT.EXE под Windows, дата на кассе "убегает" на один день вперед, хотя в самой программе SETCODAT.EXE дата отображается корректно.
О! Хорошая инфа. А то я себя уже ущербным начал чувствовать. У всех убегает на 1 день, а у меня нет...
А оказывается OS у меня не та...

Wilde

29.01.2016, 16:24

я столкнулся с этой же шнягой, перевел легко через мониторинг

Hendehog

02.02.2016, 08:29

02.02.2016, 12:48

А если сервер под виндой, что великий you see ass советует?
Переходить на RK7.
Переводить через мониторинг.

RafStudio

12.02.2016, 14:49

Переходить на RK7.
Не АЙС. В двух словах: Имеем сеть фуд-кортов (ну или фаст-фудов). Допустим, что на данный момент около 30 торговых точек, грубо говоря: 30 серверов. Для перехода на семёрку клиенту придется выложить что-то около 45000 рублей на три промежуточных сервера отчетов, свыкнуться с бесконечным пересчетом кубов, пересесть на другой тарифный план по интернету (меня это конечно тоже забавит, но вот бывают "рачительные" хозяева, умеющие экономить на мелочах и проё по крупному, но это так, оффтоп). В общем и целом примерно на пару месяцев геммороя, поскольку тут придется как в той песне - СНАЧАЛА ДО ОСНОВАНИЯ ВСЕ НА ХРЕН РАЗРУШИМ, А ПОТОМ ПОСТРОИМ НОВОЕ...
И, извиняюсь, всё лишь из-за того (это видимо мне придется объяснять владельцам), что вот SETCODAT.EXE c 2016 года, подчиняясь Российскому тренду, перешёл на новый план по импортозамещению... Тьфу ты! Новое байторазмещение!
В общем НЕ АЙС!!!

Переводить через мониторинг.
Дело путное. Но вот беда: У клиентов кассовая версия RK6.107WIN, а уважаемый UCS, начиная с версии менеджера выше 6.92, сделал обязательным наличие ключа защиты для такой милой штуки как Monit32.exe и никаким другим монитором, кроме как от менеджера 6.93 и выше к кассе 6.107 не подключиться. А так было бы просто прелесть - закинул необходимую для монитора мелочь на кассу и твори себе в радость нужную дату...

более быстрый способ решения проблемы
Это, как Вы сами понимаете для RK6WIN на данный момент не существует и вряд-ли будет.

sibgaba

12.02.2016, 15:09

Раф, а у тебя то в чем проблема?

Я никогда не поверю что в этой сети у тебя клиенты сами через setcodat переводили дату в случае косяка... По любому инженер делал, и скорее всего удаленно. Ну так и в чем проблема для инженера поставить не сегодняшнюю дату, а вчерашнюю?

Офф топ: По поводу привязки монитора к ключу. Я так только "за", давно пора было... А то привыкли все к халяве (и дилеры, и клиенты)... Если кто забыл, то так то Монитор это отдельный модуль, который денег стоит...

---------- Добавлено в 17:09 ---------- Предыдущее сообщение было размещено в 17:07 ----------

PS Под такого крупного клиента можно и свою прогу написать, которая будет переводить дату в system.db так как тебе нужно...

RafStudio

12.02.2016, 15:34

Раф, а у тебя то в чем проблема?
Привет!
Да как бы проблем лично у меня то нет! Проблемы обычно у клиентов возникают. Особенно после праздников - бывает, что вместо отставания, завтрашним числом аж начинают молотить, пока не очухаются.
(одна девочка заранее пару раз закрыла, а другая на автомате придя еще пару раз захлопнула). Но это действительно - не проблема... Поправить и это можно.
Неприятностью выглядит следующее (последняя запись с трекера):
"кстати обратил внимание, что если править таким же образом код-ресторана, то он так же прописывается некорректно, т.е. если в последующем генерировать сос-код относительно вписанного кода ресторана, сайт лицензирования выдает ошибку типа: "ID в коде запроса не соответствует ID выбранного объекта", хотя объект выбран тот что нужно..."
Сам не проверял...

Вру!!!
Вспомнил!!!
Как раз клиента запускал в двадцатых числах января и с изумлением увидел эту надпись!
Пару раз тыкнулся с Chrome - одно и то-же. Хотел уже звонить в Москву, но время было раннее. Думаю дай попробую зайти через IE и о чудо! Всё заработало!
Это конечно не совсем то, о чём Дмитрий Родиков говорит, но сообщение l.ucs было именно такое.