[lhc]

Проблема в следующем: в торговом зале установлено несколько рабочих мест в стандартном комплекте сканер ШКИ и ФП Мария 301. Иногда случается, что надо напечатать довольно длинный чек, и в это время на других рабочих местах невозможно создать новый документ и соответственно работать. Возможно возникали похожие ситуации и есть решения проблемы.

[zetovich]

тут телепатов нет. Вы сами прочитав свой вопрос, поймете что вы хотели?
что за софт? длинный это скок?....и ваще скорее помут писатели рабочего места кассира....обычно это не 1с.

[logist]

Встречалась такая проблема, без долгих раздумий решалась одним методом - закрытие чеков с количеством позиций не более 10.
В чем проблема на самом деле не разбирались. Используем ФР Датекс.

[zetovich]

Встречалась такая проблема, без долгих раздумий решалась одним методом - закрытие чеков с количеством позиций не более 10.
В чем проблема на самом деле не разбирались. Используем ФР Датекс.

тип я пришел в маркет...натарил тележку...а мне на кассе 10 чеков дали?
как то не так...
хотя я не сталкивался

[logist]

тип я пришел в маркет...натарил тележку...а мне на кассе 10 чеков дали?
как то не так...
хотя я не сталкивался

Ситуация была не в маркете, а на торговой точке, где 70% чеков имеют одну позицию, а 25% имеют в среднем 3 позиции.
В идеале, стоит поиграться со скоростью СОМ-порта. Т.е. чем меньше тем лучше. После общения с инжереами обслуживающими ФР, есть подозрение, что ФР не успевает работать на скорости СОМ-порта 9,6 и более (по крайней мере Датекс)

[lhc]

Длинный чек - это в смысле 15 и более позиций. Драйвер ФП от ТзОВ “Резонанс”. Этот драйвер создает промежуточный текстовый файл, который потом и печатает ФП. Этот промежуточный файли создан для устранения задержки ожидания по COM-порту. Хотя проведение документа возможно только после того, когда чек напечатан. Тут логика непонятна как можно ускорить печать, ведь надо дожтаться флага успешой печати чека. Все-равно нужно контролировать печать чека - возможно окончание или заминание бумаги в ФП.
Интересно Ваше мнение.

[logist]

Получается проблема в работе самой 1С, что-то грузит ее в момент проведения чека.

[lhc]

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

[Batchir]

Всё, правильно сначала закрывай и проводи чек, а потом печатай.