Технологический сервер ККТ Меркурий
-
diacsupport
- Сообщения: 201
- Зарегистрирован: 27 апр 2017, 16:40
Re: СЕРВЕР ККТ
IP адрес мы не программировали, хост, порт, период опроса- по умолчаниюdiacsupport писал(а):Сделайте тест WiFi, IP-адрес есть?
-
diacsupport
- Сообщения: 201
- Зарегистрирован: 27 апр 2017, 16:40
Re: СЕРВЕР ККТ
Это ясно, в тесте WiFi над списком точек доступа адрес есть?
Re: СЕРВЕР ККТ
Естьdiacsupport писал(а):Это ясно, в тесте WiFi над списком точек доступа адрес есть?
Re: СЕРВЕР ККТ
У Вас также должен быть запрограммирован ID ККТ и выбран канал.
Не забывайте, только, после настройки необходимо ККТ перезагрузить.
В общем, в статусе сервера ККТ должен быть статус ПАУЗА или ОБМЕН.
А далее 2-3 минуты ждать короткого сигнала писка, говорящего о начале загрузки на ККТ данных.
Если проходит «ТЕСТ.СЕРВ.ККТ», то с настройками WiFi всё в порядке.
Не забывайте, только, после настройки необходимо ККТ перезагрузить.
В общем, в статусе сервера ККТ должен быть статус ПАУЗА или ОБМЕН.
А далее 2-3 минуты ждать короткого сигнала писка, говорящего о начале загрузки на ККТ данных.
Если проходит «ТЕСТ.СЕРВ.ККТ», то с настройками WiFi всё в порядке.
-
diacsupport
- Сообщения: 201
- Зарегистрирован: 27 апр 2017, 16:40
Re: СЕРВЕР ККТ
На сервере ККТ касса есть? Необходимо добавить там.
Re: СЕРВЕР ККТ
Добавилиdiacsupport писал(а):На сервере ККТ касса есть? Необходимо добавить там.
Во вкладке "общие"
Ожидаются настройки от кассы
Re: СЕРВЕР ККТ
Оказывается перезагрузить ККТ надо было :D Спасибо за помощь всем!Юля писал(а):Добавилиdiacsupport писал(а):На сервере ККТ касса есть? Необходимо добавить там.
Во вкладке "общие"
Ожидаются настройки от кассы
Re: СЕРВЕР ККТ
Ребят, чето перемудрили с сервером ККТ по поводу рег. номера кассы. Он теперь не стирается в окне сервера, а раньше можно было удалить. Поймите, мы кассу готовим заранее со всеми вбитыми данными (в том числе- и копируя чужие настройки), а регномер (не знаю, кто как) вводим только вручную с клавы в последний момент- когда он уже получен. Прошу исправить.
зы. Стереть регномер получилось с какой-то попытки, но после этого при попытке начать регистрацию (просто чтобы распечатать все данные для проверки)- "не введены параметры регистрации", то есть во всех полях ФН пусто. Выкл/вкл- всё опять нормально, но регномер опять прописался старый (неверный). Вобщем, просто оставьте это поле в покое в техсервере.. Пусть он контролирует, но не лезет в настройки поля.
зы. Стереть регномер получилось с какой-то попытки, но после этого при попытке начать регистрацию (просто чтобы распечатать все данные для проверки)- "не введены параметры регистрации", то есть во всех полях ФН пусто. Выкл/вкл- всё опять нормально, но регномер опять прописался старый (неверный). Вобщем, просто оставьте это поле в покое в техсервере.. Пусть он контролирует, но не лезет в настройки поля.
-
RomanStrel
- Сообщения: 235
- Зарегистрирован: 22 май 2017, 21:52
Re: Технологический сервер
Здравствуйте.
Вот некоторые пожелания для Сервера ККТ. Буду благодарен, если вы их рассмотрите и прокомментируете. Если надо что-то пояснить, рассказать подробнее, показать – я готов.
1) Самое главное. Это позволит решить большинство проблем «взросления» Сервера ККТ.
Сделайте возможность отправки обновления в кассы из заранее сформированных файлов. То есть, заранее формируется файл обновления – руками или своим софтом – например, в формате XML, или в другом – лишь бы его можно было править без спец.программы типа нового Конфигуратора. В таком файле записывается весь набор необходимых данных для обновления – по заранее описанным полям – товары, коды, цены, флаги, настройки, опции. И так для каждой кассы – отдельный файл. А в идеале – еще и с перечнем касс внутри этого одного файла. Таким образом, вся подготовительная работа будет лежать на пользователе – например, для одной пачки касс код1=Булочка=10руб, для второй пачки касс код1=Булочка=15руб, а для третьей пачки касс код1=Журнал=45руб. Да, конечно, такая схема работы усложнит централизованную отчетность средствами Сервера ККТ, но, во-первых, это вполне решаемо, а во-вторых, ведь можно сделать два режима – один для тех, кто готовит обновления внутри Сервера ККТ, и пользуется отчетностью Сервера ККТ, а другой – для тех, кто готовит обновления своими силами, а Сервер ККТ использует для самого процесса обновления и для нецентрализованной отчетности. Я могу дать пример, как это работает сейчас в 180К.
2) Отложенное обновление.
Сделайте возможность выполнять отложенное обновление. Чтобы можно было заранее сделать все нужные настройки и указать время, начиная с которого обновление будет активным для передачи в кассы. То есть, например, я указал начало действия обновления 23.05.2017 03:00, и тогда кассы, которые стучатся на сервер в 02:55, не получают обновления. И в 02:59 тоже не получают обновление. А если в 03:00 или позже – тогда уже получают обновление. Это позволит готовить обновления заранее, чтобы не нажимать кнопку «Отправить» в три часа ночи или в выходной день. Я могу дать пример, как это сейчас работает в 180К.
3) Версия пакета обновления.
Сделайте возможность собирать нужные для обновления данные в пакеты и нумеровать их версиями. И в кассе отображать номер обновления вместо даты (ну или вместе с датой). Потому что, во-первых, людям на местах легче ориентироваться на двух-трехзначный номер обновления, чем на дату (особенно, когда эта дата – не сегодняшняя), чтобы убедиться «касса обновлена последним обновлением». А во-вторых, за один день возможно несколько обновлений в разное время. Особенно, если вдруг вспомнили, что что-то нужно срочно добавить-изменить, – такое бывает постоянно при больших обновлениях. К тому же, это позволит готовить заранее несколько обновлений вперед. Номер версии может быть автоматическим или ручным, достаточно трехзначного числа максимум, или текстового значения (например, «12» и «12а»). Этот номер версии нужно печатать также и на чеках-статусах. И было бы хорошо, чтобы этот номер автоматически подставлялся (как переменная) в текстовое клише. Сейчас мы еще и руками каждый раз при обновлении прописываем номер версии в текстовое клише, чтобы всегда было сразу понятно, с каким обновлением работает касса. Я могу дать пример, как это работает сейчас в 180К.
4) Группировка касс для обновления.
Сделайте возможность группового обновления касс. То есть, чтобы можно было выбрать группу касс и по ним выполнить обновление. А то, например, обновлять 70 касс единовременно – будет несколько утомительно.
5) Группировка касс для настроек.
Сделайте возможность группировать настройки для касс. Например, как я упоминал ранее, текстовое клише сразу поменять для всех касс нужной группы. Или какую-то опцию включить/отключить сразу для всех касс группы. В идеальном варианте настройки указывать для именованной группы касс, а для каждой кассы отдельно можно тоже указать значения настроек, и настройки конкретной кассы будут перекрывать настройки группы.
6) Товары по концепциям.
Сделайте возможность создания концепций, для которых будет доступно назначать кодам разные товары с ценами. То есть, для одной концепции для кода 1 указывается товар Булочка с ценой 15 руб, а для второй концепции для кода 1 указывается товар Журнал с ценой 45 руб. Кассы привязываются к той или иной концепции (как к группам). Это связано в первую очередь с тем, что персоналу приходится запоминать коды товаров, и двух-трехзначные коды запоминать гораздо прощу и удобнее, чем четырех-пятизначные. Особенно, если периодически происходят изменения. К тому же, самые часто используемые позиции удобно ставить на самые короткие коды – так сокращается количество нажатий. А еще, раньше, на 180К, от объема базы товаров зависел объем электронного журнала – не знаю, насколько это теперь актуально.
Дальнейшее развитие концепций – это факультативно, в общем-то. Для сквозных концепций у товаров сквозные код и наименование с параметрами, различная только цена по концепциям.
7) Сообщения на кассу.
Сделайте возможность отправки информационного сообщения на кассу, с обязательной его распечаткой по получению. Что-то вроде «Внимание! У булочки сменился код – теперь код=26.» (это для группы касс). Или «Передайте эту кассу в обслуживание!» (это для конкретной кассы). Также, кроме обычных сообщений, должно быть возможно отправить сообщение в составе обновления. То есть, при успешном завершении обновления печатается некое сообщение «Обновление завершено. Версия справочника = 18. Новые позиции: код26=Булочка=15руб, код74=Журнал=45руб. Журналы начинаем продавать, когда распродадим все булочки.». Если для обновления не определено пользовательское сообщение, то касса должна просто распечатать системное сообщение, о том, что обновление произведено, версия такая-то. Сообщение должно быть визуально оформлено так, чтобы блок текста выделялся среди чеков и отчетов. Также в настройках сообщения нужно разрешить использовать разные размеры шрифтов. Я могу дать пример, как это работает сейчас в 180К.
8) Отложенное применение изменений на кассе.
Это не то же самое, что отложенное обновление, это другое. Это когда мы для одного пакета обновления указываем, например, две строки одного кода с разным периодом действия. Например, код26=Булочка=15руб с началом действия «изначально» и код26=Булочка=20руб с началом действия 25.05.2017. Касса забрала себе обновление и ушла в работу. И с момента обновления булочка стоит 25 руб., а с 25.05.2017 булочка пробивается уже по 20 руб. Если технически возможно сделать, чтобы отложенное изменение вступало в силу в тот момент, который указан – было бы отлично. Если нет – тогда можно сделать применение отложенных изменений только при закрытии смены. Это необходимо для тех случаев, когда изменение должно произойти в период недоступности связи с сервером. Я могу дать пример, как это работает сейчас в 180К.
9) Отчет Журнал операций.
Сделайте загрузку из кассы журнала операций. Чтобы можно было фиксировать и анализировать все действия на кассе – включение кассы, выключение кассы, изменение даты-времени, открытие смены, аннулирование чека ручное, аннулирование при щелчке выключателем, дата-время каждой позиции в чеке, печать нефискального отчета, закрытие смены, поступление пакета обновления, выполнение обновления и так далее. Если сам чековый потом еще можно загрузить из ОФД, то с журналом операций сложнее – он же в ОФД не передается, а очень нужен. Конечно, лучше бы и чеки, и операции грузить из одного места. Для чего – это для тех, кому в аббревиатуре ККТ слово «контрольная» не менее важно, чем слово «кассовая». Так мы отлавливаем воровство и махинации. Я могу дать пример, как это работает сейчас в 180К.
10) Доступ через API.
Сделайте возможность загрузки на сервер фалов обновления и выгрузки отчетов в автоматическом режиме через какое-нибудь API. В этом случае те, кому достаточно существующих возможностей, будут пользоваться клиентской частью Сервера ККТ. А кому нужны расширенные возможности по управлению и аналитике – будут загружать себе массив данных и уже в своих системах крутить как хочется.
Конец первого акта.
Вот некоторые пожелания для Сервера ККТ. Буду благодарен, если вы их рассмотрите и прокомментируете. Если надо что-то пояснить, рассказать подробнее, показать – я готов.
1) Самое главное. Это позволит решить большинство проблем «взросления» Сервера ККТ.
Сделайте возможность отправки обновления в кассы из заранее сформированных файлов. То есть, заранее формируется файл обновления – руками или своим софтом – например, в формате XML, или в другом – лишь бы его можно было править без спец.программы типа нового Конфигуратора. В таком файле записывается весь набор необходимых данных для обновления – по заранее описанным полям – товары, коды, цены, флаги, настройки, опции. И так для каждой кассы – отдельный файл. А в идеале – еще и с перечнем касс внутри этого одного файла. Таким образом, вся подготовительная работа будет лежать на пользователе – например, для одной пачки касс код1=Булочка=10руб, для второй пачки касс код1=Булочка=15руб, а для третьей пачки касс код1=Журнал=45руб. Да, конечно, такая схема работы усложнит централизованную отчетность средствами Сервера ККТ, но, во-первых, это вполне решаемо, а во-вторых, ведь можно сделать два режима – один для тех, кто готовит обновления внутри Сервера ККТ, и пользуется отчетностью Сервера ККТ, а другой – для тех, кто готовит обновления своими силами, а Сервер ККТ использует для самого процесса обновления и для нецентрализованной отчетности. Я могу дать пример, как это работает сейчас в 180К.
2) Отложенное обновление.
Сделайте возможность выполнять отложенное обновление. Чтобы можно было заранее сделать все нужные настройки и указать время, начиная с которого обновление будет активным для передачи в кассы. То есть, например, я указал начало действия обновления 23.05.2017 03:00, и тогда кассы, которые стучатся на сервер в 02:55, не получают обновления. И в 02:59 тоже не получают обновление. А если в 03:00 или позже – тогда уже получают обновление. Это позволит готовить обновления заранее, чтобы не нажимать кнопку «Отправить» в три часа ночи или в выходной день. Я могу дать пример, как это сейчас работает в 180К.
3) Версия пакета обновления.
Сделайте возможность собирать нужные для обновления данные в пакеты и нумеровать их версиями. И в кассе отображать номер обновления вместо даты (ну или вместе с датой). Потому что, во-первых, людям на местах легче ориентироваться на двух-трехзначный номер обновления, чем на дату (особенно, когда эта дата – не сегодняшняя), чтобы убедиться «касса обновлена последним обновлением». А во-вторых, за один день возможно несколько обновлений в разное время. Особенно, если вдруг вспомнили, что что-то нужно срочно добавить-изменить, – такое бывает постоянно при больших обновлениях. К тому же, это позволит готовить заранее несколько обновлений вперед. Номер версии может быть автоматическим или ручным, достаточно трехзначного числа максимум, или текстового значения (например, «12» и «12а»). Этот номер версии нужно печатать также и на чеках-статусах. И было бы хорошо, чтобы этот номер автоматически подставлялся (как переменная) в текстовое клише. Сейчас мы еще и руками каждый раз при обновлении прописываем номер версии в текстовое клише, чтобы всегда было сразу понятно, с каким обновлением работает касса. Я могу дать пример, как это работает сейчас в 180К.
4) Группировка касс для обновления.
Сделайте возможность группового обновления касс. То есть, чтобы можно было выбрать группу касс и по ним выполнить обновление. А то, например, обновлять 70 касс единовременно – будет несколько утомительно.
5) Группировка касс для настроек.
Сделайте возможность группировать настройки для касс. Например, как я упоминал ранее, текстовое клише сразу поменять для всех касс нужной группы. Или какую-то опцию включить/отключить сразу для всех касс группы. В идеальном варианте настройки указывать для именованной группы касс, а для каждой кассы отдельно можно тоже указать значения настроек, и настройки конкретной кассы будут перекрывать настройки группы.
6) Товары по концепциям.
Сделайте возможность создания концепций, для которых будет доступно назначать кодам разные товары с ценами. То есть, для одной концепции для кода 1 указывается товар Булочка с ценой 15 руб, а для второй концепции для кода 1 указывается товар Журнал с ценой 45 руб. Кассы привязываются к той или иной концепции (как к группам). Это связано в первую очередь с тем, что персоналу приходится запоминать коды товаров, и двух-трехзначные коды запоминать гораздо прощу и удобнее, чем четырех-пятизначные. Особенно, если периодически происходят изменения. К тому же, самые часто используемые позиции удобно ставить на самые короткие коды – так сокращается количество нажатий. А еще, раньше, на 180К, от объема базы товаров зависел объем электронного журнала – не знаю, насколько это теперь актуально.
Дальнейшее развитие концепций – это факультативно, в общем-то. Для сквозных концепций у товаров сквозные код и наименование с параметрами, различная только цена по концепциям.
7) Сообщения на кассу.
Сделайте возможность отправки информационного сообщения на кассу, с обязательной его распечаткой по получению. Что-то вроде «Внимание! У булочки сменился код – теперь код=26.» (это для группы касс). Или «Передайте эту кассу в обслуживание!» (это для конкретной кассы). Также, кроме обычных сообщений, должно быть возможно отправить сообщение в составе обновления. То есть, при успешном завершении обновления печатается некое сообщение «Обновление завершено. Версия справочника = 18. Новые позиции: код26=Булочка=15руб, код74=Журнал=45руб. Журналы начинаем продавать, когда распродадим все булочки.». Если для обновления не определено пользовательское сообщение, то касса должна просто распечатать системное сообщение, о том, что обновление произведено, версия такая-то. Сообщение должно быть визуально оформлено так, чтобы блок текста выделялся среди чеков и отчетов. Также в настройках сообщения нужно разрешить использовать разные размеры шрифтов. Я могу дать пример, как это работает сейчас в 180К.
8) Отложенное применение изменений на кассе.
Это не то же самое, что отложенное обновление, это другое. Это когда мы для одного пакета обновления указываем, например, две строки одного кода с разным периодом действия. Например, код26=Булочка=15руб с началом действия «изначально» и код26=Булочка=20руб с началом действия 25.05.2017. Касса забрала себе обновление и ушла в работу. И с момента обновления булочка стоит 25 руб., а с 25.05.2017 булочка пробивается уже по 20 руб. Если технически возможно сделать, чтобы отложенное изменение вступало в силу в тот момент, который указан – было бы отлично. Если нет – тогда можно сделать применение отложенных изменений только при закрытии смены. Это необходимо для тех случаев, когда изменение должно произойти в период недоступности связи с сервером. Я могу дать пример, как это работает сейчас в 180К.
9) Отчет Журнал операций.
Сделайте загрузку из кассы журнала операций. Чтобы можно было фиксировать и анализировать все действия на кассе – включение кассы, выключение кассы, изменение даты-времени, открытие смены, аннулирование чека ручное, аннулирование при щелчке выключателем, дата-время каждой позиции в чеке, печать нефискального отчета, закрытие смены, поступление пакета обновления, выполнение обновления и так далее. Если сам чековый потом еще можно загрузить из ОФД, то с журналом операций сложнее – он же в ОФД не передается, а очень нужен. Конечно, лучше бы и чеки, и операции грузить из одного места. Для чего – это для тех, кому в аббревиатуре ККТ слово «контрольная» не менее важно, чем слово «кассовая». Так мы отлавливаем воровство и махинации. Я могу дать пример, как это работает сейчас в 180К.
10) Доступ через API.
Сделайте возможность загрузки на сервер фалов обновления и выгрузки отчетов в автоматическом режиме через какое-нибудь API. В этом случае те, кому достаточно существующих возможностей, будут пользоваться клиентской частью Сервера ККТ. А кому нужны расширенные возможности по управлению и аналитике – будут загружать себе массив данных и уже в своих системах крутить как хочется.
Конец первого акта.
Re: СЕРВЕР ККТ
ewgen
Совсем проверку убирать не стал, но теперь можно нормально удалить номер. Попробуйте посмотрите, если не устроит, будем совместно думать, что бы и удобно было и что бы как то защитить от ошибочного ввода номера.
Совсем проверку убирать не стал, но теперь можно нормально удалить номер. Попробуйте посмотрите, если не устроит, будем совместно думать, что бы и удобно было и что бы как то защитить от ошибочного ввода номера.
Re: Технологический сервер
вопрос по теме привязки настроек ккт к ID ккт?
Если все данные , которые находятся на сервере ккт (настройки, товары,конфигурация и т.д.) привязывать при выгрузке к ID ккт в виде префикса.(например ID 123455, то товар с кодом 12 будет выгружаться в ккт как 123455_12) или пакет данных для передачи на ккт с ID 123455 будет содержать такой префикс. А ккт в свою очередь должна понимать, для нее этот пакет или для другой ккт . Это актуально если на разные ккт выгружаются разные данные.
Еще , было бы не плохо видеть, ккт находиться в сети или нет, т.е. видит сервер ккт или кидает в пустоту данные.
Я не знаю , как это реализовано на серверах ОФД, но у них есть функция мониторинга(в сети , не в сети и т.д.).
Еще, желательно при нажатии кнопок выгрузить изменения в ккт задавать вопрос (от дурака) "ВЫ действительно хотите
выгрузить данные? Да, нет.
Из топика выше про возможность выбирать пакеты для загрузки по дате и времени для выбранной ккт было бы не плохо
сначала видеть в списке эти пакеты, но нужно еще понимать что находиться в этих пакетах.
Да и на самой ккт желательно дать возможность выбирать данные для загрузки и возможность отклонять загрузку с сообщением на сервер , что загрузка отклонена.
Конечно довольно муторное дело эти загрузки, особенно если на кассе нажать принять обновление должны кассиры, которые бояться подходить к ккт, а не то чтобы принимать решения загружать или нет.
особенно это касается обновления конфигурации через сервер ккт. Пока админ не проверит как работают все функции на самой ккт после обновления. После обновления могут поменяться функциональные клавиши , порядок нажатия, да и все настройки надо перепроверять.
Если все данные , которые находятся на сервере ккт (настройки, товары,конфигурация и т.д.) привязывать при выгрузке к ID ккт в виде префикса.(например ID 123455, то товар с кодом 12 будет выгружаться в ккт как 123455_12) или пакет данных для передачи на ккт с ID 123455 будет содержать такой префикс. А ккт в свою очередь должна понимать, для нее этот пакет или для другой ккт . Это актуально если на разные ккт выгружаются разные данные.
Еще , было бы не плохо видеть, ккт находиться в сети или нет, т.е. видит сервер ккт или кидает в пустоту данные.
Я не знаю , как это реализовано на серверах ОФД, но у них есть функция мониторинга(в сети , не в сети и т.д.).
Еще, желательно при нажатии кнопок выгрузить изменения в ккт задавать вопрос (от дурака) "ВЫ действительно хотите
выгрузить данные? Да, нет.
Из топика выше про возможность выбирать пакеты для загрузки по дате и времени для выбранной ккт было бы не плохо
сначала видеть в списке эти пакеты, но нужно еще понимать что находиться в этих пакетах.
Да и на самой ккт желательно дать возможность выбирать данные для загрузки и возможность отклонять загрузку с сообщением на сервер , что загрузка отклонена.
Конечно довольно муторное дело эти загрузки, особенно если на кассе нажать принять обновление должны кассиры, которые бояться подходить к ккт, а не то чтобы принимать решения загружать или нет.
особенно это касается обновления конфигурации через сервер ккт. Пока админ не проверит как работают все функции на самой ккт после обновления. После обновления могут поменяться функциональные клавиши , порядок нажатия, да и все настройки надо перепроверять.
-
x-th-unicorn
- Сообщения: 25
- Зарегистрирован: 03 май 2017, 09:49
Re: Технологический сервер
Ничёси у людей пожелания... 
было бы конечно шикарно еcли бы разработчики запилили хотя бы половину... особо плюсую за API.
У меня хотелка скромнее, всего навсего сделать настройку сетевых параметров через сервер, а то SSID и пароль указать можно, а статический IP или шлюз например, ручками на месте менять надо...
было бы конечно шикарно еcли бы разработчики запилили хотя бы половину... особо плюсую за API.У меня хотелка скромнее, всего навсего сделать настройку сетевых параметров через сервер, а то SSID и пароль указать можно, а статический IP или шлюз например, ручками на месте менять надо...
Re: Технологический сервер
RomanStrel
1. Сервер был написан для автоматизации торговли, в качестве входных данных номенклатуру из сторонних программ, таких как 1С. Вы же предлагаете половину функционала выкинуть и при этом, что бы все работало. Это система совсем другого типа у которой основной задачей будет передача данных от каких то других систем автоматизации. Возможно если будет поставлена задача сделать новую версию, то попробуем учесть это пункт, но скорей всего система будет эволюционировать, соответственно глобальных переделок не будет. Переделывать существующую систему под этот пункт будет довольно затратно.
2. По конфигурациям обновления возможны только по закрытии кассы, как бы частично отложено, но конечно у Вас идея интереснее. По остальным данным идея конечно интересная, записал себе в планы.
3. По версии пакета довольно спорный вопрос, если уж по хорошему делать версию числом, то там должны major.minor[.build[.revision]] . Да и для Вашей версии записи версии не вижу преимуществ, да что бы под это еще все переделывать.
4. Да это в планах.
5. Это тоже в планах и все под одним пунктом.
6. Если у Вас разные предприятия торговли с пересечением по кодам, по просто можно завести другую точку доступа. Если такой бардак(кроме отдельных случаев) на одном торговом предприятии, то как по такому чуду делать отчеты о продажах по всему предприятию, как делать списание по складам(при передаче в складской учет). Мне все эти коллизии не нравятся, но подобные запросы уже были и мы думаем как это лучше решить. Возможно для групп касс которые участвуют в ограничении пользователей сделать свои номенклатуры и тогда и уникальность будет(PLU+IDGroup) и для касс можно будет выгружать короткие PLU.
7. Думаю это лучше в начале поднять в ветке по кассе, реализуют поддержим.
8. Думаю это лучше в начале поднять в ветке по кассе(еще актуальнее), реализуют поддержим.
9. Опять же ну совсем не к серверу вопрос, касса сможет мы поддержим.
10. Да конечно по загрузке товаров и выдаче продаж будет интерфейс взаимодействия. Планируем доработать этот драйвер https://forum.incotexkkm.ru/viewtopic.php?f=19&t=6 , пока там только выгрузка товаров в файл, который потом можно загрузить на сервер.
Спасибо за столь серьезный труд, на самом деле много взяли на заметку.
1. Сервер был написан для автоматизации торговли, в качестве входных данных номенклатуру из сторонних программ, таких как 1С. Вы же предлагаете половину функционала выкинуть и при этом, что бы все работало. Это система совсем другого типа у которой основной задачей будет передача данных от каких то других систем автоматизации. Возможно если будет поставлена задача сделать новую версию, то попробуем учесть это пункт, но скорей всего система будет эволюционировать, соответственно глобальных переделок не будет. Переделывать существующую систему под этот пункт будет довольно затратно.
2. По конфигурациям обновления возможны только по закрытии кассы, как бы частично отложено, но конечно у Вас идея интереснее. По остальным данным идея конечно интересная, записал себе в планы.
3. По версии пакета довольно спорный вопрос, если уж по хорошему делать версию числом, то там должны major.minor[.build[.revision]] . Да и для Вашей версии записи версии не вижу преимуществ, да что бы под это еще все переделывать.
4. Да это в планах.
5. Это тоже в планах и все под одним пунктом.
6. Если у Вас разные предприятия торговли с пересечением по кодам, по просто можно завести другую точку доступа. Если такой бардак(кроме отдельных случаев) на одном торговом предприятии, то как по такому чуду делать отчеты о продажах по всему предприятию, как делать списание по складам(при передаче в складской учет). Мне все эти коллизии не нравятся, но подобные запросы уже были и мы думаем как это лучше решить. Возможно для групп касс которые участвуют в ограничении пользователей сделать свои номенклатуры и тогда и уникальность будет(PLU+IDGroup) и для касс можно будет выгружать короткие PLU.
7. Думаю это лучше в начале поднять в ветке по кассе, реализуют поддержим.
8. Думаю это лучше в начале поднять в ветке по кассе(еще актуальнее), реализуют поддержим.
9. Опять же ну совсем не к серверу вопрос, касса сможет мы поддержим.
10. Да конечно по загрузке товаров и выдаче продаж будет интерфейс взаимодействия. Планируем доработать этот драйвер https://forum.incotexkkm.ru/viewtopic.php?f=19&t=6 , пока там только выгрузка товаров в файл, который потом можно загрузить на сервер.
Спасибо за столь серьезный труд, на самом деле много взяли на заметку.
Re: Технологический сервер
forint
1. Конфигурации и настройки и так под каждую кассу свои. Вы предлагаете и товары для каждой кассы делать свои. А кто потом с каждой такой базой будет работать: набивать, изменять, синхронизировать с системой автоматизации(1С). Другой вопрос, хотя бы по группам уже совсем другой порядок работ, об этом думаем, пока только в отдельной точке доступа.
2.По состоянию подключения кассы, сейчас показывается последнее подключение кассы к серверу(касса>Общие>Касса связывалась).
3. "ВЫ действительно хотите выгрузить данные?" согласен сделаем
4. По загрузкам, да там не все просто, для кого то наоборот может показаться что то излишеством. Изменения там должны быть обдуманы.
1. Конфигурации и настройки и так под каждую кассу свои. Вы предлагаете и товары для каждой кассы делать свои. А кто потом с каждой такой базой будет работать: набивать, изменять, синхронизировать с системой автоматизации(1С). Другой вопрос, хотя бы по группам уже совсем другой порядок работ, об этом думаем, пока только в отдельной точке доступа.
2.По состоянию подключения кассы, сейчас показывается последнее подключение кассы к серверу(касса>Общие>Касса связывалась).
3. "ВЫ действительно хотите выгрузить данные?" согласен сделаем
4. По загрузкам, да там не все просто, для кого то наоборот может показаться что то излишеством. Изменения там должны быть обдуманы.
Re: Технологический сервер
x-th-unicorn
Эти поля появились в кассе недавно, конечно они появятся и на сервере.
Эти поля появились в кассе недавно, конечно они появятся и на сервере.
-
RomanStrel
- Сообщения: 235
- Зарегистрирован: 22 май 2017, 21:52
Re: Технологический сервер
Shtirlic
спасибо за ответ.
Да, по кассовой прошивке я тоже отправлю отдельный пост в соответствующую ветку.
1) Жаль. На самом деле, по многим случаям в условиях большого количества касс и наличия выстроенной системы учета, от Сервера нужна только транспортная функция – передача по GPRS/WIFI обновлений на кассу и прием от кассы отчетов. Всё остальное выполняется уже своими силами. Ваша позиция тоже понятна, поскольку большинство пользователей маленьких автономных касс подразумевают небольшое их количество и вполне удовлетворятся любым более-менее простым доступным решением. Наверное, придется отказаться от GPRS¬-канала (вот этого жаль больше всего) и ждать возможности работы Конфигуратора по WIFI-каналу.
2) Здесь я имел в виду не обновление конфигурации аппарата, а обновление справочников кассы – цены, наименования, кода.
6) При проработанной структуре всё это работает и в одной организации, с подразделениями, распределенными по стране. Когда есть несколько (12-17) разных направлений-концепций, у каждой из которых свои кассы, свои пересекающиеся коды, товары, цены, настройки и т.д. – и централизованное управление и учет.
спасибо за ответ.
Да, по кассовой прошивке я тоже отправлю отдельный пост в соответствующую ветку.
1) Жаль. На самом деле, по многим случаям в условиях большого количества касс и наличия выстроенной системы учета, от Сервера нужна только транспортная функция – передача по GPRS/WIFI обновлений на кассу и прием от кассы отчетов. Всё остальное выполняется уже своими силами. Ваша позиция тоже понятна, поскольку большинство пользователей маленьких автономных касс подразумевают небольшое их количество и вполне удовлетворятся любым более-менее простым доступным решением. Наверное, придется отказаться от GPRS¬-канала (вот этого жаль больше всего) и ждать возможности работы Конфигуратора по WIFI-каналу.
2) Здесь я имел в виду не обновление конфигурации аппарата, а обновление справочников кассы – цены, наименования, кода.
6) При проработанной структуре всё это работает и в одной организации, с подразделениями, распределенными по стране. Когда есть несколько (12-17) разных направлений-концепций, у каждой из которых свои кассы, свои пересекающиеся коды, товары, цены, настройки и т.д. – и централизованное управление и учет.
Re: Технологический сервер
Статус сервера ККТ. На чеке ошибка 511 Серв. ККТ. ВЕРНУЛ ОШИБКУ. (Все параметры запрограммированы, ККТ не зарегистрирован)
Re: Технологический сервер
Юля писал(а):Статус сервера ККТ. На чеке ошибка 511 Серв. ККТ. ВЕРНУЛ ОШИБКУ. (Все параметры запрограммированы, ККТ не зарегистрирован)
Там по-английски должно ещё быть и сообщение от сервера ККТ.
-
x-th-unicorn
- Сообщения: 25
- Зарегистрирован: 03 май 2017, 09:49
Re: Технологический сервер
Эх... вот если бы хоть примерные сроки...хотя бы вида займемся в июне, или раньше сентября не появится... чтобы было на что ориентироваться...Shtirlic писал(а):x-th-unicorn
Эти поля появились в кассе недавно, конечно они появятся и на сервере.