Всем доброго времени суток!
Ситуация такая: после долгого трудового дня кассир закрывает смену (1С:Розница ред.2.2 платформа 1С 8.3.12 ККТ-Атол 55Ф) программа зависает примерно 20-30 мин. Количество чеков в среднем около 100, продается алкоголь, т.е.работает ЕГАИС. Тестирование и исправление не помогает.
Почему так долго закрывается смена???
Обновляйте программу. Удаляйте все драйвера на кассу ккм. Чистите реестр. Устанавливайте драйвер ккм 10 версии. Проблема взаимодействия 1с с драйвером. Если конечно у вас не терминальный доступ.
(12)посмотрите не осталось ли неиспользованных и необновленых правил обмена/синхронизации.
Может совпадение, но на одной базе в разы быстрее стало закрывать смену после удаления старых давно неиспользуемых правил обмена. Но все равно закрывает по 2-7 минут
(68)никакие регистры не нужно очищать. Установите расширение, если розница у вас проф.
Если не проф, тогда войдите в продажи-чеки и поставьте на удаление чеки без статуса (поле статус пустое).
Затем в Администрирование - обслуживание - удаление помеченных - выборочное удаление : тут удалите чеки.
Та же проблема на рознице 2.2.11.24, платформа 8.3.13.1644.
Обновились с 2.2.27.39 и старой платформы. Файловая база выросла в 2 раза. Сразу в тестирование и исправление - сжатие таблиц, база уменьшилась в 1,5 раза.
база файловая.
2 кассы, 1 касса на компе с базой, 2я по веб подключена, они в одной сети. По веб ещё 2 компа подключены. Настроен обмен с БП через синхронизацию.
2 чека, алкогольный и сигареты - закрывается 3-5 минут, хотя раньше закрывалось за секунды.
100-150 чеков, со-второй кассы, которая подключена через веб-сервис доступ 25 (!!!) минут.
На компе с базой 200-250 чеков 7-10 минут. Не важно, через веб или прямое подключение. 75% чеков - алкогольные
Комп очень мощный, i5, быстрый SSD, без бэдов и глюков.
В итоге: было закрытие за минуту-две максимум, чеков было и по 500. После обновления закрывается до получаса.
Ещё момент: раньше, когда закрывалась смена на 2й кассе, то тормозила 1-я, можно было нарваться на блокировку. Сейчас пока пол часа закрывается 2я можно без проблем торговать на 1й.
(14) Подтверждаю. Точно такая же проблема. Кассы Атол, драйвера 10 й версии последние. Началось после последнего обновления конфигурации, плюс стала падать 1с в режиме кассира при закрытии крестиком окна ввода цены. Качество 1С конфигураций упало просто катастрофически.
Аналогично долгое закрытие смены по кассе Атол. Драйвер 9.х
Перед этим смена по Вики принту 15 чеков закрывается секунд 20.
2.2.11.24
8.3.13.1644
База на этом компьютере. SSD. проц двухъядерный e8400.
300-400 чеков. смена закрывается около 5-7 минут.
Думал проблема в апаче, но его отключение ничего не дало. сам кассир и до этого работал в файловом режиме.
на 2.2.9.20 такого не было
Чеки в базе с 2017 года. Выемки делаются в конце смены и остается около 7к на следующий день.
Приходники по выемкам не делаются.
Подозрение только на чеки или выемки
Пробовал на копии базы в кассах и в терминалах отключить оборудование - закрывается также долго.
База 1,8гб. процессор при этом загружен на 60%, диск почти не используется.
На другом компе с процессором e7300, ssd и отключенным оборудованием на копии базы - тоже самое
Обмены и синхронизации никакие не используются
Всем доброго времени суток.
Платформа 8.3.13.1644, Конфигурация 8.3.13.1690
Предлагаю 2-а решения проблемы:
1. Урезать чеки в базе (беру из собственного опыта):
- Есть 20 баз РМК (где-то база на апаче + клиент, где-то одиночная (соединение файловое) - не суть) на всех этих БД чеков скопилось, примерно, за 2-3 года - смена закрывается за 30-40 минут, если алко, тогда чутка побыстрее
- Есть 2-е базы РМК, которые готовил для нового магазина, чеков скопилось за 2-3 месяца - смена закрывается за 3-4 минуты
2. Но я пошел другим путем:
Написал расширение, где вместо стандартного выполнения процедуры "ОбработатьДокументыККМСервер" Формы Обработки "Закрытие кассовой смены" идет выполнение моего кода
Суть кода: в КАЖДЫЙ запрос и в КАЖДЫЙ подзапрос добавил ограничение по дате для ЧековККМ - Чеки выбираются только за сегодняшний день, а не за все время
Ловите, только сначала протестируйте, сравните с оригиналом т.к. многие моменты отключил
вы у себя в расширении используете НачалоДня и КонецДня... не совсем думаю логично, потому как закрытие смены может быть и на следующий день, те кто работает круглосуточно..
(28)Отлично, сегодня попробую потестить, спасибо ещё раз.
А в чём, собственно, проблема, не подскажите? Что делается с чеками в конце смены, что их приходится ограничивать по дате? Думал, что обработываются только чеки закрывающейся смены.
(28)попробовал на тестовой базе, сократило время закрытия раз в 10. Файловая база, добавлена папкой
Но на торговой точке все кассы работают в веб-режиме и там не повлияло, как было, так и осталось.
Причём без расширения если смена закрывалась, то можно было работать на 2й кассе, а с расширением вторая касса перестаёт реагировать пока смена не закроется на 1й.
Аналогичная проблема. Решил расширением. Ограничил анализ чеки с начала года.
вы ограничиваете с начала года.. но к концу года, у кого пробитых чеков прилично, будет ровно такая же проблема что закрываться будет долго.. поэтому предлагаю использовать не НачалоГода а НачалоМесяца или у кого уж совсем много чеков то использовать НачалоНедели..
у себя переделал на НачалоНедели, закрытие смены проходит быстро
Я просто удалил 100к+ чеков за год обработкой которая может удалять непосредственно, тестированием прогнал чтобы потерянные ссылки на чеки почистились и проблема ушла.
(33)в общем смысле, на работу с ЕГАИС не влияет, я это понимаю.
Но нужна история продаж с марками и реквизитами чеков, т.к. уже были претензии по разборкам с проверяющими и им так тыкнуть в лицо проще. А разборы по вопросам от полугода до полутора лет, т.к. марки спустя время вновь продали в каком-то кафе.
Но думаю, что оставить старую базу и сделать свёртку нужно. База за 3 года выросла до > 7 гб, + сильный скачок в объёме после последнего обновления.
1. логи в папке с базой чистили ?
2. может все-таки базу на SQL сервер перекинуть ?
пс. у меня под постоянным наблюдением 7 магазинов где стоит розница.
чеков везде много. и нигде нет проблем которые вы описываете, потому что я избавился от файловых баз.
если база прям раздувается, то чеки можно смело удалять. у них статус "архивный", и работе базы они какого участия не принимают.
но повторюсь, я удивлен что подобная тебя существует, но понимаю что эта проблема только на файловых базах
(37) ну ка расскажите в двух словах как и зачем переводить на sql базу, которая физически находится на компьютере кассира на ssd? Товаровед подключается по сети но в этот момент выключен.
Как по мне так это сговор 1С, Microsoft, продавцов ssd и прочего железа. Ведь всякие dns, ситилинки и прочие железячники явно почувствовали волну хороших продаж с приходом сначала егаиса а потом и нового 54фз. И вот сейчас когда десятка худо-бедно работает на компьютерах с обычными hdd, 1C как будто подливает масла в огонь и вносит искусственные тормоза в простую операцию свертывания чеков за один день.
Потому что надо базу выносить на отдельный сервер, а если такой возможности нет, то sql сервер можно и на кассе развернуть. Хуже от этого не будет.
У меня есть опыт, когда в магазине 4 рабочих места (из них 2 кассы).
Работаем весной, всё хорошо, приходит лето (живу на курорте), оборот сильно увеличивается, с 50 до 200 чеков в день. И всё... все висит, смены как у вас долго закрываются, документы долго проводятся, полнотекстовый поиск медленно работает. И все потому что база файловая.
Все проблемы разом решились SQL сервером.
Много раз наблюдал что SSD это не панацея от тормозов. SSD реально увеличивает скорость работы самой ОС, и файловая система работает реально шустро, комп включается в разы быстрее и выключается и перезагружается, но что касается 1С, то производительность вырастает на 10%, не больше.
Производительность файловой базы вырастает при наличии процессора с большим кэшем.
Я раньше старался не браться за обновление старых баз, пока не поставил i7-8700 и количество ядер тут не причем.
Еще раз повторюсь. Для баз данных важен кэш ядра процессора. Поэтому для серверов и советуют xeon. Сравните кэш у i5-7400 и Xeon E3 в одной ценовой категории. 2М кэша разницы дают существенное преимущество.
При работе базы (в т.ч. при обновлении или резервном копировании) процессор совсем не загружен. Так откуда берется скорость работы базы данных ?
Скорость Шины тоже важна, но она у них одинаковая.
Частота процессора и количество ядер важно для игр, и рендеринге видео, но никак не для базы
(40) т.е. вы предлагаете в каждый маленький чипок ставить по мима 1С еще и сервер sql(есть бесплатные), сервер 1С(минимум 14400 руб на магазин) лишь бы смены закрывались быстро, при этом отработав пару лет без всяких проблем. Вы не думаете что заказчики на вас после этого нормально посмотрят?
(41) Не только нормально смотрят, но и платят бывает больше рыночной цены за эти работы.
Я вам дал просто наводку, так сказать. Я же не могу вам тут все свои секреты выложить.... )))) а дальше думайте.
есть решение вашей проблемы, а как это грамотно реализовать, чтобы и овцы и волки.... думайте дальше сами, либо в личку стучите
(43) тогда удаляем логи, чистим чеки.
или переносим все номенклатуру, штрихкоды, поставщиков, закупочные, розничные цены, остатки в новую базу, а старую оставляем для архива.
за ночь можно управиться...
...хотя какая ночь, за три часа. дешево и сердито.
оборот сильно увеличивается, с 50 до 200 чеков в день
В среднем было от 150 до 300 чеков в день, база на SSD, две кассы работают одновременно, с третьего компьютера заводят поступления и прочее. В конце прошлого года, когда чеков больше всего, смена закрывается нормально, но после обновления в январе закрытие смены заметно увеличивается до 7-10 минут с одной максимум (сколько же оно будет проходить в декабре?). Мне кажется или тут вполне очевидно, что проблема не аппаратная? К тому же, после ограничения выборки чеков по дате, проблема сразу исчезает.
Одного или двух заказчиков может и удастся уговорить увеличить расходы на обслуживание в 2-3 раза, но когда их больше 10, то скорее всего вы останетесь без работы, а ваши клиенты перейдут к тому, кто освоил работу с расширениями.
Раз уж обсуждение про этот последний пролемный релиз спрошу тут.
Выявил глюк, может кто сталкивался?
Есть две егаисных алко бутылки в справочнике Номенклатура с абсолютно одинаковыми названиями, но, естестенно, разными кодами товара. Если по названию искать этот товар в НСИ - Номенклатура, то видно два этих товара, а если искать из любого документа, связанного с егаис ,через Подбор, то видно только один из этих товаров.
63.
user629138_rnienol
14.03.19 12:28 Сейчас в теме
Смена закрывалась минут 10.По данным этой ветки в рознице при закрытой смене открыл Чеки, поставил отбор на чеки, у которых статус НЕ Аннулированный, НЕ Отложенный, НЕ Архивный (Можно просто статус не заполненный). Было ~ 300 чеков. Удалил все эти чеки. Теперь закрытие смены ~ 3 мин.
а закрывалась минут 10.По данным этой ветки в рознице при закрытой смене открыл Чеки, поставил отбор на чеки, у которых статус НЕ Аннулированный, НЕ Отложенный, НЕ Архивны
Все еще мучаюсь с долгим закрытием смены. Причем проблема плавающая. Один день может закрыться за 5 минут, в другой день 20 минут.
Пробовал все, что предлагали в этой теме (расширение тоже не помогло).
Также пробовал и стандартные процедуры, такие как очистка кеша, chdbfl.exe и ТиИ.
Сейчас релиз Розницы стоит последний, кассы Атол с самыми последними драйверами 10 версии (10.4.6.0) и прошивка на кассе последняя 7942.
Обработчик взял Атоловский от последних драйверов, именно под 10.4.6.0, но также пробовал и встроенный от 1С (разницы в итоге никакой).
Причем есть другой магазин с абсолютно идентичной конфигурацией 1С и оборудования, там закрывается смена почти мгновенно.
Кто-нибудь посоветуйте, как выяснить причину проблемы?
75.
user629138_rnienol
15.05.19 16:59 Сейчас в теме
(74) Чтобы узнать причину, то это, наверное, надо замеры производительности смотреть(регистры).
На партнёрском форуме ещё был совет:почистить кэш и установить параметр /ClearCache
76.
user644675_mfilipenko
16.05.19 10:57 Сейчас в теме
Добрый день!
У нас такая же проблема с зависание 1С при закрытии смены.
Работаем на ПП 1С:Розница 2.2 на облачном ресурсе 1С:ГРМ https://service.1capp.com.
Платформа: 1С:Предприятие 8.3 (8.3.13.1644)
Конфигурация: Розница, редакция 2.2 (2.2.11.30)
Режим: Веб-сервер (сжатие: усиленное)
Приложение: Тонкий клиент
Касса подключена АТОЛ 55Ф.
При закрытии смены происходит зависание программы, при этом ошибку не выдает, ждем минут 15 и 2 часа. В итоге приходится сбрасывать процесс, запускать 1С заново и псоле чего смена закрывается.
Техподдержка v8 отчета не дает.
Пробовали и параметр /ClearCache , и менять драйвера кассы 9 и 10, и удалять помеченные чеки, и выгрузку в dt и загрузку, и разные платформы 1С, и ТИИ. Ничего не помогает.
Подскажите, пожалуйста, получилось ли все-таки у кого-нибудь решить проблему????
Будем очень благодарны.
Замер производительности показывает, что больше всего времени тратится на выполнение обработки ЗакрытиеКассовойСмены, а именно МассивРезультатСуммаОплатыНаличных = ЗапросСуммаОплатыНаличных.ВыполнитьПакет();
А какие старые чеки? За все время? Так придется все связанные документы Отчеты о розничных продажах удалять, в которых эти чеки присутствуют. Это нереально, разъедутся все остатки.
(84) Проблема не решилась. Поменяйте запрос на этот
ЗапросСуммаОплатыНаличных.Текст =
"ВЫБРАТЬ РАЗЛИЧНЫЕ
| ЧекККМОплата.Ссылка КАК Ссылка,
| ЧекККМОплата.ДоговорПлатежногоАгента КАК ДоговорПлатежногоАгента
|ПОМЕСТИТЬ ТаблицаЧековСОплатойНаличными
|ИЗ
| Документ.ЧекККМ.Оплата КАК ЧекККМОплата
|ГДЕ
| ЧекККМОплата.Ссылка.КассаККМ = &КассаККМ
| И ЧекККМОплата.Ссылка.Проведен
| И НЕ ЧекККМОплата.Ссылка.СтатусЧекаККМ = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Архивный)
| И НЕ ЧекККМОплата.Ссылка.СтатусЧекаККМ = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Аннулированный)
| И НЕ ЧекККМОплата.Ссылка.СтатусЧекаККМ = ЗНАЧЕНИЕ(Перечисление.СтатусыЧековККМ.Отложенный)
| И ЧекККМОплата.ВидОплаты = &Наличные
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| СУММА(ЕСТЬNULL(ЧекККМТовары.Сумма, 0)) КАК СуммаТоваров,
| СУММА(ЕСТЬNULL(ЧекККМОплата.Сумма, 0)) КАК СуммаОплат,
| СУММА(ЕСТЬNULL(ВЫБОР
| КОГДА ЧекККМОплата.ВидОплаты = &Наличные
| ТОГДА ЧекККМОплата.Сумма
| ИНАЧЕ 0
| КОНЕЦ, 0)) КАК СуммаНаличных,
| ТаблицаЧековСОплатойНаличными.Ссылка КАК Ссылка,
| ТаблицаЧековСОплатойНаличными.ДоговорПлатежногоАгента КАК ДоговорПлатежногоАгента,
| СУММА(ЕСТЬNULL(ЧекККМТовары.Количество, 0)) КАК Количество
|ПОМЕСТИТЬ ТаблицаПоЧекам
|ИЗ
| ТаблицаЧековСОплатойНаличными КАК ТаблицаЧековСОплатойНаличными
| ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЧекККМ.Товары КАК ЧекККМТовары
| ПО ТаблицаЧековСОплатойНаличными.Ссылка = ЧекККМТовары.Ссылка
| ЛЕВОЕ СОЕДИНЕНИЕ Документ.ЧекККМ.Оплата КАК ЧекККМОплата
| ПО ТаблицаЧековСОплатойНаличными.Ссылка = ЧекККМОплата.Ссылка
|
|СГРУППИРОВАТЬ ПО
| ТаблицаЧековСОплатойНаличными.ДоговорПлатежногоАгента,
| ТаблицаЧековСОплатойНаличными.Ссылка
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ТаблицаПоЧекам.Ссылка КАК Ссылка,
| ВЫБОР
| КОГДА ТаблицаПоЧекам.СуммаТоваров = 0
| И ТаблицаПоЧекам.Количество <> 0
| И ТаблицаПоЧекам.Ссылка.ОперацияСДенежнымиСредствами
| ТОГДА 0
| КОГДА ТаблицаПоЧекам.СуммаТоваров = 0
| И ТаблицаПоЧекам.Ссылка.ОперацияСДенежнымиСредствами
| ТОГДА ТаблицаПоЧекам.СуммаНаличных
| ИНАЧЕ ТаблицаПоЧекам.СуммаТоваров - ТаблицаПоЧекам.СуммаОплат + ТаблицаПоЧекам.СуммаНаличных
| КОНЕЦ КАК НаличныеБезСдачи,
| ТаблицаПоЧекам.ДоговорПлатежногоАгента КАК ДоговорПлатежногоАгента
|ПОМЕСТИТЬ ТаблицаНаличныеБезСдачи
|ИЗ
| ТаблицаПоЧекам КАК ТаблицаПоЧекам
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| ТаблицаНаличныеБезСдачи.Ссылка КАК Ссылка,
| ТаблицаНаличныеБезСдачи.НаличныеБезСдачи КАК НаличныеБезСдачи,
| ТаблицаНаличныеБезСдачи.ДоговорПлатежногоАгента КАК ДоговорПлатежногоАгента
|ИЗ
| ТаблицаНаличныеБезСдачи КАК ТаблицаНаличныеБезСдачи
|;
|
|////////////////////////////////////////////////////////////////////////////////
|ВЫБРАТЬ
| СУММА(ВЫБОР
| КОГДА ТаблицаНаличныеБезСдачи.Ссылка.ВидОперации = ЗНАЧЕНИЕ(Перечисление.ВидыОперацийЧекККМ.Возврат)
| ТОГДА -ТаблицаНаличныеБезСдачи.НаличныеБезСдачи
| ИНАЧЕ ТаблицаНаличныеБезСдачи.НаличныеБезСдачи
| КОНЕЦ) КАК НаличныеБезСдачи
|ИЗ
| ТаблицаНаличныеБезСдачи КАК ТаблицаНаличныеБезСдачи
|ГДЕ
| ТаблицаНаличныеБезСдачи.ДоговорПлатежногоАгента = &ПустойАгентскийДоговор";
Добрый день. Такая же проблема. Правда Розница базовая. Но не суть. Обновился до 2.2.12.30. И в одном из магазинов закрытие просто висит. процесс 1С жрет 50-100 % процессора и что-то делает. На версии 2.2.5.27 все работало нормально. Какие могут быть вариаты? Висит сама 1С. т.к. пробовал закрывать смену без галочки "Закрыть без Z-отчета". В один день закрыло быстро. в другой висит.
База РИБ на 50 точек. На некоторых точках долго закрывается смена. Убрал все не пробитые старые чеки.
Если не поможет хочу попробовать расширение.
Вопрос: его подключать в центральной базе и при синхронизации оно уйдёт по точкам. Он прийдёт на магазин и всё или придётся обновлять каждую точку?
С расширениями не работал.
(94) О как. В этой теме проблема закрытия смены в рознице 2.2.11 обсуждается. Потому как в 2.2.9.20 например со сменами проблем не было. В 2.2.6 я тоже не припоминаю таких проблем. Боюсь в вашем случае расширение не поможет.
Розница 2.2.11.30. РИБ на 3 удаленных базы. Оборудование абсолютно одинаковое. На всех базах по 2 ККМ ИП+ООО. На одной базе периодически смена ИП закрывается по 10-15 минут. На второй базе смена ИП постоянно закрывается по 30-120 минут. На третей базе все закрывается за пару минут всегда.
(96) В 2.2.13.8 пофиксили. У меня статистика пока небольшая 10 магазинов. Но во всех полет нормальный. Если бы еще кассы vikiprint не терялись переодически.
(98) Такая же проблема. Затраты времени после обновления с 2.2.11.30 до 2.3.4.33 возросли с 15 минут до... мы ждали несколько часов. Не дождались.
Правили код, ставили во всех запросах условие на ограничение выборки чеков до 3 последних дней (как (87) ). Добились приемлемых 15 минут.
У нас базе несколько лет, чеков много. Видимо это и является основным тормозом. Буду пробовать свертку базы.