[ОТВЕТИТЬ]
18.11.2014 13:29
winmasta
 
Всем доброго, суть проблемы в заголовке - не сжимаются одинаковые позиции в чеке (в том числе и в товарном) и получается иногда очень большая портянка, что неудобно продавцам, кладрвщикам, а главное покупателям. Все это происходит на 2х кассах, на обоих галочки "Не сжимать одинаковые позиции в чеках" изначально не стояли, на одной из касс (для эсксперимента) поставил эту галку - ничего не изменилось. Подскажите, может быть где-то этот параметр жестко задан или еще что-то не так ?
18.11.2014 13:45
OlegON
 
А печать чека онлайновая или по подитогу? Я не помню, как этот параметр называется...
18.11.2014 13:49
Dim
 
если печать после расчета, то все сжимается. если печатается сразу после сканирования, то, естественно, ничего сжиматься не будет
18.11.2014 14:40
winmasta
 
... если честно не посмотрел, завтра гляну - отпишу
26.11.2014 14:42
winmasta
 
галка "Конфигурация->Общие настройки->[ ] Печать чека после расчета" стоит, при сканировании одинаковых позиций они не сжимаются на мониторе и в чеке
26.11.2014 14:59
konst
 
можно попробовать взять CF_INI с двух касс - где сжимается и где не сжимается - и сравнить все параметры.
а также проверить версии УКМ на этих кассах. в CF_INI - очень много недокументированных и нигде не описанных параметров, при этом некоторые параметры взаимосвязаны.
04.12.2014 08:09
winmasta
 
Цитата:
konst можно попробовать взять CF_INI с двух касс - где сжимается и где не сжимается - и сравнить все параметры.
а также проверить версии УКМ на этих кассах. в CF_INI - очень много недокументированных и нигде не описанных параметров, при этом некоторые параметры взаимосвязаны.
видимо придется так и сделать
04.12.2014 10:50
winmasta
 
накатил новый дистрибутив (2.466 вместо 2.464) - ничего не изменилось: набиваем одинаковые позиции (через сканер, например 5 раз) на экране появляется 5 строчек, нажимаем ПОДИТОГ - они объединяются в одну, а печатает все равно столько строчек сколько раз чиркнули сканером, если забивать через ВВОД КОЛИЧЕСТВА, то конечно все в порядке ....
04.12.2014 11:30
konst
 
а сравнение CF_INI ?
04.12.2014 14:55
winmasta
 
Цитата:
konst а сравнение CF_INI ?
в процессе
05.12.2014 17:47
winmasta
 
ТП сервисплюса выслушав проблему попросили описание на мыло ... будут разбираться
05.12.2014 18:40
OlegON
 
убедительная просьба потом причину тут озвучить
06.12.2014 15:25
winmasta
 
Цитата:
OlegON убедительная просьба потом причину тут озвучить
если докопаюсь (или ТП сообщит) - обязательно
09.12.2014 09:21
winmasta
 
единственный параметр из отличающихся, который меня смутил - USE_CLISUM, про него нигде ничего нету
09.12.2014 12:11
konst
 
Этот параметр похож на соседние
USE_CLIENTS 1 6 1-Использование таблицы CLIENTS.DB
USE_CLISUM 1 0 "Использование таблицы CLISUM.DB" - по крайней мере такая таблица есть
09.12.2014 17:13
winmasta
 
ну тогда я в тупике, жду теперь ответ от ТП - последняя надежда
09.12.2014 17:35
konst
 
я бы попробовал поменять эти три параметра:

"NOT_MIN_QUANT";"1";3;"1-Не уменьшать количество"
"NOT_MIN_QUANT";"0";3;"1-Не уменьшать количество"

"_CLR_IPC_MCR";"0";0;""
"_CLR_IPC_MCR";"2";0;""

"_MERGEDISCCLI";"0";0;""
"_MERGEDISCCLI";"1";0;""

хотя по описанию они и не очень подходят, но в УКМ-2 много необъяснимых взаимосвязей...
09.12.2014 17:51
winmasta
 
NOT_MIN_QUANT - пробовал (т.к. вроде бы проблемы начались как раз с момента когда разрешили уменьшать кол-во) - НО не помогло

_CLR_IPC_MCR - всегда стоит в 0 (если нет то дисконтные карты не работают), а там 2 опять неожиданно "влезла" (это кстати еще одна проблема, тут есть отдельная тема), так что этот параметр тоже мимо

_MERGEDISCCLI - осознанно стоит 1 для поглощения скидок, менять не пробовал, но это параметр для нас критичен и без него мы не сможем, можно только в кач-ве теста попробовать
09.12.2014 18:12
konst
 
Почему на кассах эти параметры разные? - поменяй их на той, где позиции сжимаются, если перестанут, то что то на них завязано.
09.12.2014 18:32
winmasta
 
кассы стоят в разных магазинах (строительный - с проблемой, продуктовый - без проблем)

по _CLR_IPC_MCR вот _CLR_IPC_MCR выставляется в 2 файл взят в тот момент когда произошел очередной сбой

NOT_MIN_QUANT - нужен для работы (пробовал его менять - не помогло)

_MERGEDISCCLI - нужен для работы, попробую конечно его убрать в кач-ве эксперимента на той кассе где проблема

на тех кассах где нет проблем менять ничего не хочется - не дай бог, как говорится, "сломается" ))
17.12.2014 12:06
winmasta
 
ответ техподдержки:

Добрый День!
В результате анализа присланных архивов было выяснено следующее: Несжимаемые позиции есть в обеих версиях программы. Причина этого в следующем - в таблице Plucash.db есть параметр MesPresision, который отвечает за точность измерения товара. Если этот параметр целочисленный (0, 1 и т.д., используется для ШТУЧНОГО товара), то одинаковые позиции в чеке сжимаются, если же точность имеет дробное значение (0.1 0.01, используется для весового товара), то одинаковые позиции в чеке не сжимаются. В вашем случае в магазине где позиции схлопываются этот параметр практически на всех товарах целочисленный, за исключением некоторых позиций. А вот там, где позиции не сжимаются практически НА ВСЕМ товаре это значение 0.1, нам не совсем понятно для чего? Ладно вы можете гвозди продавать на вес, но инструмент же имеет явно штучную форму продажи. Для решения проблемы Вам необходимо сделать точность штучного товара 1, а для весового оставить 0,1.

сделал точность шт. "1" и все стало замечательно

ps до этого точность шт. ставил в "0,1" когда пытался разобраться с продажей дробного количества (а надо было снять галку "Не давать уменьшать количество" в CF_INI.DB), а в "1" вернуть забыл
Опции темы


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

 

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