Вернуться
Работа CashTAN с остатками
Павленко Сергей
0 - 24.01.2012-17:37
Добрый день,

возникла специфическая проблема. Большое количество кэштанов настроены в режим контроля остатков, учетная система периодически, не очень часто, осуществляет выгрузку остатков. Приблизительно пару раз в день.
При этом периодески возникает одна и та же проблема: иногда почему-то кэштан все-таки позволяет пробивать товар, которого нет на остатке. Это хорошо видно в учетной системе.
Проблема возникает не часто, но регулярно. При этом повторное пробитие позиции без остатка не удается.
Каштанов около полусотни и изредка проблема вылазит у всех.
Каштаны работают в паре с кассой Datecs MP-50, хотя, думаю, это не играет роли.

Остатки выгружаются на утро текущего дня, так что этот момент тоже учтен.

Вопрос: как исправить эту ситуацию, и в каком направлении хотя бы разбираться? Есть ли возможность пробить товар с нулевым остатком на кэштане с установленым признаком контроля остатков?
Jekky
1 - 24.01.2012-19:18
Здраствуйте.

Эта тема периодически всплывает вот уже более десяти лет на тысячах устройтв, однако пока никому не удалось увидеть нулевой остаток на кассовой ленте а потом пробить товар.

Я всётаки полагаю, что это всё изза того, что то данные, которые хорошо видно в УЧЁТНОЙ системе СЕЙЧАС, слегка не соответствуют тому, что БЫЛО выведено в CashTAN РАНЕЕ.

Причины:
а) был закрыт протокол, но обмен произошёл ДО вывода справочника (такое обязательно случится при регулярном обмене);
б) в учётной системе было проведено какое-либо списание товара ПОСЛЕ выгрузки справочника;
в) редактировался приходный документ (об этом никто не признается).

В конце концов товар на момент продажи БЫЛ В РУКАХ У ПОКУПАТЕЛЯ, а значит учётная система немного не права.

Таково моё мнение. Создайте ситуацию, которую можно повторить и мы обязательно исправим ошибку. Если она есть.
Павленко Сергей
2 - 25.01.2012-10:31
"Причины:
а) был закрыт протокол, но обмен произошёл ДО вывода справочника (такое обязательно случится при регулярном обмене);"

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

"в) редактировался приходный документ (об этом никто не признается)."
Да, возможно так и происходит. Попробую поразбираться в этом направлении, спасибо.
Jekky
3 - 25.01.2012-10:45
Могу.
Вы пропустили один момент: система ЗАКРЫВАЕТ протокол. Это действие увеличивает остатки в драйвере (пока не в самом устройстве). Ожидается, что непосредственно после закрытия протокола будут выгружены остатки с учётом данных по протоколу, после чего пойдёт обмен - для этого и предусмотрена опция загрузки данных по выводу справочника.

Впрочем, если нет регулярного обмена - оно так само собой выходит, так что скорее всётаки дело в пунктах б,в.

Есть и ещё один момент - если на один и тот же код выведено несколько товаров, например, с разными штрихкодами, - в таком случае контроль не работает.
Павленко Сергей
4 - 25.01.2012-12:58
"Вы пропустили один момент: система ЗАКРЫВАЕТ протокол. Это действие увеличивает остатки в драйвере (пока не в самом устройстве). Ожидается, что непосредственно после закрытия протокола будут выгружены остатки с учётом данных по протоколу, после чего пойдёт обмен - для этого и предусмотрена опция загрузки данных по выводу справочника."

Действительно, я пропустил этот момент. В моей учетной системе сначала осуществляется загрузка продаж из открытого протокола и, если протокол не текущий осуществляется его закрытие методом
ОткрытыйПротокол.Close();
т.е. без всяких флагов блокировки вывода справочника.
Гм. А ведь это может, теоретически, вызвать порчу остатков, если сразу после закрытия делали обычные обмены, без выгрузки остатков?

Я настроил для операторов 2 способа обмена с кэштаном - получение протоколов с последующей выгрузкой остатков и без выгрузки остатков, только получение протокола.
Jekky
5 - 25.01.2012-13:17
Обязательно вызовет. За закрытием протокола должна следовать выгрузка новых остатков.
Павленко Сергей
6 - 30.01.2012-16:16
Добрый день,
"Есть и ещё один момент - если на один и тот же код выведено несколько товаров, например, с разными штрихкодами, - в таком случае контроль не работает."

Есть вопрос: появилась необходимость учитывать товар с несколькими ценами. Поясню: в нашей учетной системе учет ведется в разрезе розничных цен, а именно МРЦ. Часто возникает ситуация, что остаток на киоске имеется по двум ценам.
Сегодня эта проблема решается так: каждому товару установливается текущая цена и выгружается именно эта цена и остаток по ней.

Но вот все чаще возникает ситуация, когда необходимо продавать по все-таки по двум ценам. Появилась идея: зарезервировать один лок. код и выгружать на него все позиции с двойными ценами. А идентификацию проводить по штрихкоду.
Ну а при обратной загрузке определять - если лок. код такой-то - значит поиск производить по штрихкоду. И наоборот.

1. Вот только насколько я понимаю по позициям с одним лок. кодом, но разными ШК не контролирутся остатки?
2. Позволит ли кэштан иметь в памяти позиции с одинаковым лок. кодом , но разными наименованиями?
3. В моих кэштанах, насколько я понял ограничение по лок. коду 5840, хотя в сервере до 999999. Можно ли обойти это ограничение? Может какая-то другая модель кэштана?
Т.к. в этом случае я мог бы выгружать просто на разные лок. коды. А кассир бил бы по ШК. А так у меня практически все коды заняты.
Jekky
7 - 31.01.2012-09:52
С несколькими ценами должны обязательно быть разные коды. В протоколе нет данных по штоихкоду, да и цена туда попадёт (не на ПРО) от первого встретившегося, а какой попадётся - неизвестно.

1. Не контроллируются.
2. Позволит. Что получится дальше - неизвестно. На сейчас 90% (а может и 100) касс такой финт не пропустят.
3. Это у вас кассы такие, либо у них такая настройка.

Добавить сообщение
Ваше имя 
Пароль (для зарегистрированных) 
email 
Сообщение 
Введите код, изображенный на картинке
Для зарегистрированных пользователей можно не вводить 
Внимание - введите символы кода в обратном порядке!

© ТФПК Лтд. Все права защищены.
0.02749 seconds