- сенсорного монитора,
- программируемой клавиатуры продавца,
- обычной клавиатуры и мыши.
Так уж получилось, что я стал автором и разработчиком «1С: Розница», что это и почему я публикую технические проекты описал в предыдущем материале.
Название проекта
Разработка интерфейса рабочего места кассира (РМК) для обеспечения возможности подключения программируемой клавиатуры кассира и работы с сенсорным монитором.
Цель проекта
Реализовать возможность использовать РМК в POS-терминалах с программируемыми клавиатурами продавца и/или сенсорными дисплеями.
Требования по проекту
- Поддержать работу с клавиатурой, запрограммированной в сторонних программных продуктах, для работы с РМК (примерная раскладка клавиатуры в приведена в предварительном анализе).
- Обеспечить возможность ввода действий, аналогичных клавиатуре, с touch-screen.
- Оптимизировать установку основных параметров строки чека в момент продажи кассиром: назначение количества, скидки (суммой, процентом), цены на активную строку товара.
- Сохранить возможность работы в РМК с помощью обычной клавиатуры и мыши.
Описание концепции
- Добавляется возможность настроить РМК таким образом, чтобы можно было работать в режимах:
- Обычная клавиатура + мышь.
- Программируемая клавиатура продавца.
- Сенсорный экран.
- Все три режима работы используют одни и те-же визуальные формы, это обеспечит конгруэнтность для пользователя и гибкость для разработчиков.
- Режим работы с сенсорным экраном и программируемой клавиатурой, в основе, имеют общую настройку интерфейса, т.к.:
- Могут использоваться совместно.
- Предполагают одно и то-же назначение — продовольственная розница, оптимизация действий кассира.
- Технически похожи, т.к. для подключения клавиатуры продавца на форму должны быть вынесены акселераторы, а их можно назначить кнопкам (которые будут явно отрисованы на форме для сенсорного ввода).
- Для более «тонкой» настройки интерфейса существует возможность скрыть/показать панели рабочего места кассира.
Предварительный анализ по проекту
Текущее состояние
Перед началом проекта интерфейс РМК позволяет выполнять действия с использованием стандартной клавиатуры + мыши, выглядит следующим образом:
Работу текущего режима рассмотрим на небольшом примере общего случая «ввода товара» в Чек ККМ:
- Сканируется товар (или выбирается из списка).
- Активизируется ячейка количества (только если текущая строка – новая).
- Ввод количества.
- Если позволено редактировать цену в колонке ТЧ, то активизируется ячейка ввода цены (что далеко не всегда необходимо, и продавцу приходится лишний раз пропускать ее клавишей Enter или Tab).
- Если позволено редактировать процент скидки в колонке ТЧ, то активизируется ячейка ввода скидки (что далеко не всегда необходимо, и продавцу приходится лишний раз пропускать ее клавишей Enter или Tab).
Очевидно, что процесс «ввода товара» имеет ряд необязательных действий, которые требуют лишних движений кассира.
Имеющиеся примеры решения
Схема оптимизации продаж с учетом практик борьбы с очередями:
- Обычно используется программируемая клавиатура продавца (64 клавиши).
- Ввод информации осуществляется:
- Сканирование / ввод по штрихкоду / подбор (редко) товара.
- Набор цифр (отображаются на мониторе).
- Нажатие клавиши действия (клавиша «Количество», «Цена», «Скидка») – устанавливает числовое значение в нужную ячейку, в зависимости от нажатой клавиши.
- З.Ы. Штрихкод вводится по вышеописанному способу – набор цифр, подтверждение клавишей «ШК».
Описанный вариант ввода значительно ускоряет процедуру обслуживания покупателя, т.к. движения кассира минимизированы.
Имеющиеся в некоторых POS-терминалах (обычно старые версии) варианты ввода «Нажатие клавиши – вывод диалогового окна – ввод значения – подтверждение (отмена) введенного значения» признаны медленными способами обслуживания, т.к. продавец вынужден контролировать вывод диалогового окна. После ввода значения кассир выбирает между вариантами принятия или отклонения решения, и еще раз нажимает клавишу (опять же затраты времени). Даже если на все вышеописанные «лишние» действия в совокупности у продавца уходит 3 секунды (у очень хорошего кассира) при пробитии 1 чека на 5 позиций, то, при проходимости кассы 1000 чеков/день (я говорю о продовольственной рознице), за день будет потрачено на лишние операции 1000 (шт) * 3 (сек) / 60 (сек) = 50 минут, т.е. 50 минут простоя кассы (задержки очереди). наша задача максимально оптимизировать работу, поэтому способ «Нажатие – диалог – ввод – подтверждение(отмена)» не будет реализован в этом проекте.
Очевидно, что в режиме touch-screen и в режиме подключаемой клавиатуры рабочее место кассира должно предоставлять стандартные действия клавиатуры продавца, используемые нынешними POS-терминалами, т.к. необходимость этих действий подтверждена многолетней практикой.
Примерное расположение клавиш на стандартной программируемой клавиатуре продавца:
| Выход | Блок. | Просм печать чека | Повтор прод | Ред. Цену | Сервис | #k8SjZc9Dxk | Откр. Ящик |
| 1 | 2 | Ноль | Тара | Ред. Кол-во | < | Назад | > |
| 3 | 4 | Секция | Возврат | Сторно | Отмена чека | / | Диск. Карта |
| 5 | 6 | -% | +% | Виз. Подбор | КОД | ШК | С |
| 7 | 8 | -Сумм | +Сумм | 7 | 8 | 9 | Х |
| 9 | 10 | Фикс. Скидка | Отмена скидки | 4 | 5 | 6 | ПРОМ ИТОГ |
| 11 | 12 | ВН | ВЫП | 1 | 2 | 3 | ОПЛАТА |
| 13 | 14 | Опл. Кредит | Опл. Тарой | 0 | . | 00 | |
- Клавиши от 1–14 — назначаемые клавиши
- Блок. – блокировка рабочего места кассира
- Повтор прод – дублирование последней проданной позиции
- Ред цену – установка цены
- Откр. Ящик – открытие денежного ящика (функция ФР)
- Сторно – удаление продажи активной позиции товара
- Отмена чека – аннулирование пробиваемого чека
- Виз. Подбор – открытие формы подбора
- КОД – ввод товара по коду в базе товаров (на практике редко используется, для не штрихкодированных товаров (хлеб, булки) используют короткие штрихкода)
- ШК – ввод штрихкода
- С – стереть текущие введенные цифры
- +% — установить процент скидки
- -% — удалить скидку
- +Сумм – установить скидку суммой
- -Сумм – удалить скидку суммой
- Фикс. Скидка – скидка на весь чек
- Отмена скидки – отмена скидки на чек
- ВН – внесение денег в кассу
- ВЫП – выплата денег из кассы
- Опл. Кредит – оплата кредитом
- Опл. Тарой – оплата тарой
- Сервис – доступ к функциям, не вынесенным на клавиатуру.
- X – вывод X-отчета
- Стрелки – перемещение по позициям и по пунктам диалоговых меню (Точно выйти? Да – Нет)
Роли и сценарии работы пользователей
Роль пользователя «Кассир»
Прецедент: покупатель подходит к кассе с товаром, чтобы его купить.
Общий сценарий работы кассира:
- Берет товар в руки, считывает штрихкод
- Кассир может ввести штрихкод с помощью сканера штрихкода. Если штрихкод не найден – система выдает сообщение в «читаемом» виде с указанием возможных действий.
- Кассир может ввести последовательность цифр штрихкода, нажимает клавишу «Поиск по штрихкоду» либо на мониторе либо на клавиатуре. Если штрихкод не найден – система выдает сообщение в «читаемом» виде с указанием возможных действий.
- Кассир нажимает клавишу подбор (либо на touch screen либо на клавиатуре), поиском по товарам находит нужный товар, подтверждает выбор (нажимет Enter).
- Если необходимо установить количество товара – набирает на цифровой панели клавиатуры количество (либо нажатием кнопок на touch-screen), нажимает клавишу установки количества. В строке товара изменяется количество.
- Если необходимо установить цену товара (и есть разрешения на изменения цены) – набирает на цифровой панели клавиатуры цену (либо нажатием кнопок на touch-screen), нажимает клавишу установки количества. В строке товара изменяется цена.
- Если необходимо установить скидку на отдельную позицию товара – вводит процент (сумму) скидки, нажимает на клавишу установки процента (суммы) скидки. Скидка в строке товара устанавливается.
- Если покупатель отказался от покупки какого-либо товара – поиском по таблице товаров находит нужную строку товара, нажимает на клавишу удаления строки товара («сторно»).
- Когда формирование ТЧ чека ККМ завершено – нажимает на клавишу «Оплата». Попадает в интерфейс оплаты товара:
- Если покупатель дает всю сумму наличными – можно, до нажатия клавиши оплата, ввести сумму оплаты. В открывшимся окне лишь подтвердить оплату. Сдача отобразится в окне, где в момент формирования чека отображается сумма документа.
- Если магазин работает с эквайрингом, то в списке выбора оплат появляется пункт «Карта».
- Если обслуживается только один вид карт (visa/mastercard…), то при нажатии на пункт «Карта» произведется оплата по обслуживаемому типу карт. Если обслуживается несколько типов карт, то откроется список выбора обслуживаемых карт, из которых следует выбрать нужный тип карт.
- Если магазин работает с кредитами, то в списке выбора оплат появляется пункт «Кредит».
- Если обслуживается только один кредит, то при нажатии на пункт «Кредит» произведется оплата кредитом. Если используется несколько кредитов, то откроется список выбора кредитов, из которых следует выбрать нужный.
- Если оплата производится по частям (нал и безнал):
- Необходимо стрелками выбрать пункт «Карта» (если оплата производится плат. картой), нажать Enter, система перейдет в таблицу типов оплат, выбрать стрелками нужный тип оплаты.
- Ввести с цифровой панели сумму оплаты по карте. Подтвердить Enter. Если к компьютеру подключена эквайринговая система – система задает вопрос об оплате картой.
- В случае с оплатой по кредиту – в таблице оплат необходимо стрелками выбрать пункт «Кредит», система перейдет в таблицу кредитов, выбрать стрелками нужный.
- Ввести с цифровой панели сумму оплаты кредитом. Подтвердить Enter.
- Если оплата производится налом – ввести сумму оплаты, в таблице оплат выбрать пункт наличные.
- Когда сумма оплат будет превышать сумму документа (только по наличным оплатам) – чек запишется и пробъется на ФР.
- Если сумма вводится на вид оплаты, по которому сумма уже была введена, то пользователю задается вопрос: «Произвести доплату?», при ответе «Да» суммы по виду оплат суммируется.
Реализуемая функциональность
- Возможность работы в РМК без использования мыши.
- Возможность работы в РМК без использования клавиатуры, с учетом того, что работа будет производиться через touch-screen.
- Возможность использования программируемой клавиатуры в интерфейсе РМК, запрограммированной в сторонней программе. Обеспечивается акселераторами.
- Возможность настройки РМК, как на работу с обычной (101 клавиша) клавиатурой, когда возможен ввод текста в подборе товаров, так и с программируемой (~64 и меньше) клавиатурой, когда на клавиатуру (или монитор для тач — скрин) выносятся необходимые функции.
Структура данных, алгоритмы обработки данных
Описание объектов метаданных конфигурации
В справочник Настройка ККМдобавляются реквизиты:
- ОтображатьПодборВПравойЧастиЭкрана
- Имя: «ОтображатьПодборВПравойЧастиЭкрана»
- Синоним: «Отображать подбор в правой части экрана»
- Тип: «Булево»
- Если Истина, то в правой части экрана отображается панель подбора номенклатуры. Подбор возможен по тексту, введенному со стандартной клавиатуры.
- Если Ложь , то в правой части экрана отображаются кнопки — акселераторы для управления РМК с touch – screen. Также появляется возможность использовать клавиатуру для более удобного (быстрого) заполнения табличной части документа (рекомендуется подключать программируемую клавиатуру продавца).
- Позже эта настройка была переименована в «Использовать режим для непродовольственной розницы», т.к. режим отображения стандартного подбора позволяет взаимодействовать продавцу с покупателем, отвечая на вопросы о товарах, что требует обычного клавиатурного ввода. Продовольственная розница, наоборот, нацелена на сокращение очередей (в силу специфики товара), поэтому логично использовать отображение кнопок для сенсорного экрана (или назначение акселераторов для программируемой клавиатуры).
- ОткрыватьПравуюПанельПриЗапуске
- Имя: «ОткрыватьПравуюПанельПриЗапуске»
- Синоним: «Открывать правую панель при запуске „
- Тип: “Булево»
- Если Истина, то при запуске интерфейса кассира в правой части экрана отображается панель подбора или кнопок (в зависимости от вышеописанной настройки).
- Логично установить данную настройку в Ложь, если будет использоваться программируемая клавиатура продавца, чтобы освободить треть экрана.
- РассчитыватьСуммовуюСкидкуОтЦены
- Имя: «РассчитыватьСуммовуюСкидкуОтЦены»
- Синоним: «Рассчитывать суммовую скидку от цены»
- Тип: «Булево»
- При установке суммовой скидки на позицию товара процент скидки рассчитывается от цены товара, если Истина, от суммы в строке товара, если Ложь.
- ОкруглятьПроцентСкидкиВБольшуюСторону
- Имя: «ОкруглятьПроцентСкидкиВБольшуюСторону»
- Синоним: «Округлять процент скидки в большую сторону»
- Тип: «Булево»
- Необходимо для установки суммовой скидки на товар. Если Истина, то вычисленный процент скидки округляется в большую сторону, если Ложь – в меньшую.
- ЗакрыватьПодборПриВыбореТовара
- Имя: «ЗакрыватьПодборПриВыбореТовара»
- Синоним: «Закрывать подбор при выборе товара»
- Тип: «Булево»
- Настройка актуальна, если ОтображатьПодборВПравойЧастиЭкрана = Ложь., т.к. эта настройка отвечает за подбор с помощью сенсорного экрана (или клавиш-акселераторов).
- Если Истина, то окно подбора закрывается при выборе товара, если Ложь – окно подбора остается активным и можно продолжать подбор.
- ОсуществлятьОтборТоваровПриПереходеВРежимПодбора
- Имя: «ОсуществлятьОтборТоваровПриПереходеВРежимПодбора»
- Синоним: «Осуществлять отбор товаров при переходе в режим подбора»
- Тип: «Булево»
- Настройка актуальна, если ОтображатьПодборВПравойЧастиЭкрана = Ложь., т.к. эта настройка отвечает за подбор с помощью сенсорного экрана (или клавиш-акселераторов).
- Если Истина, то при открытии «сенсорного» подбора, номенклатура будет фильтроваться по введенным ранее символам с цифровой клавиатуры (с экрана/клавиш-акселераторов). Параметры фильтрации – следующие 3 реквизита.
- Смысл: бывает так, что штрихкод не может быть прочитан сканером и визуально видны не все цифры штрихкода, тогда продавец может ввести видимые цифры и перейти в подбор — подбор отфильтрует все товары по вхождению указанных цифр, это позволит быстро идентифицировать товар по названию.
- ОтборПоКоду
- Имя: «ОтборПоКоду»
- Синоним: «Отбор по коду»
- Тип: «Булево»
- Настройка актуальна, если ОтображатьПодборВПравойЧастиЭкрана = Ложь., т.к. эта настройка отвечает за подбор с помощью сенсорного экрана (или клавиш-акселераторов).
- Если Истина, то при переходе в режим подбора фильтрация номенклатуры осуществляется по коду.
- ОтборПоАртикулу
- Имя: «ОтборПоАртикулу»
- Синоним: «Отбор по артикулу»
- Тип:«Булево»
- Настройка актуальна, если ОтображатьПодборВПравойЧастиЭкрана = Ложь., т.к. эта настройка отвечает за подбор с помощью сенсорного экрана (или клавиш-акселераторов).
- Если Истина, то при переходе в режим подбора фильтрация номенклатуры осуществляется по артикулу.
- ОтборПоШтрихкоду
- Имя: «ОтборПоШтрихкоду»
- Синоним: «Отбор по штрихкоду»
- Тип: «Булево»
- Настройка актуальна, если ОтображатьПодборВПравойЧастиЭкрана = Ложь., т.к. эта настройка отвечает за подбор с помощью сенсорного экрана (или клавиш-акселераторов).
- Если Истина, то при переходе в режим подбора фильтрация номенклатуры осуществляется по штрихкоду.
Интерфейс формирования чека
Если ОтображатьПодборВПравойЧастиЭкрана = Истина и ОткрыватьПравуюПанельПриЗапуске = Истина, то пользователю предоставляется следующий интерфейс:
В подборе, в строке ввода можно указать любой текст, также возможно указать область поиска (везде, наименование, код, артикул, штрихкод), нажать кнопку «Поиск» или Enter – будет осуществлен отбор номенклатуры по заданным критериям поиска. Работа с табличной частью товаров осуществляется стандартным образом – активация ячейки строки товара, внесение данных с клавиатуры.
Подбор можно отключить нажатием кнопки «Подбор (/)» или клавишей «/» с клавиатуры, такой же интерфейс будет при открытии, если ОткрыватьПравуюПанельПриЗапуске = Ложь:
Если настройки РМК ОтображатьПодборВПравойЧастиЭкрана = Ложь и ОткрыватьПравуюПанельПриЗапуске = Истина, то, при открытии, форма выглядит следующим образом (эти настройки, обычно, используются с сенсорным экраном):
В правой части экрана отображаются кнопки для удобного нажатия с touch–screen. Каждой кнопке назначен акселератор (для возможности настройки программируемой клавиатуры).
Действия для заполнения табличной части «Товары» осуществляются следующим образом:
- Вводится последовательность цифр (например 3,567)
- Нажимается кнопка, соответствующая необходимому действию с активной строкой в ТЧ товары: например «Кол-во (К)»
- Результатом является то, что в активной строке ТЧ товаров в ячейке «Количество» устанавливается количество = 3,567.
Назначение кнопок:
- Цифры и запятая – ввод цифр. Цифры, при нажатии на кнопки с touch–screen или цифровой панели клавиатуры, отображаются в правом верхнем углу под кнопками «Клавиши», «Возврат», «Тов. Чек», «Оплата».
- Кол – во (К) – установить количество активной строчке ТЧ «Товары».
- Цена (Р) — установить цену активной строчке ТЧ «Товары».
- Сторно (D) – удалить активную строчку ТЧ «Товары».
- Подбор (F) – открыть подбор. Если в настройке РМК установлено ОсуществлятьОтборТоваровПриПереходеВРежимПодбора, тогда в случае, если в панель цифр введено некоторое значение, то фильтрация отображаемых данных в подборе осуществляется по области указанной в настройках РМК (код, штрихкод, артикул).
- C (Backsp.) – очистить введенные цифры с клавиатуры.
- + Процент (Alt +) – установить процентную наценку на товар в активной строчке ТЧ «Товары».
- — Процент (Alt -) – установить процентную скидку на товар в активной строчке ТЧ «Товары».
- + Сумма (Ctrl +) – установить суммовую наценку на товар в активной строчке ТЧ «Товары» (пересчитывается в проценты в зависимости от настроек РМК).
- — Сумма (Ctrl -) – установить суммовую скидку на товар в активной строчке ТЧ «Товары(пересчитывается в проценты в зависимости от настроек РМК).
Эти акселераторы следует назначить программируемой клавиатуре продавца, если она подключена к компьютеру.
- Юзабилити-тестирование, проводимое в реальных магазинах, показало, что расположение цифр в правой части удобно для большинства людей (правшей).
- Расположение цифрового ряда и функциональных клавиш повторяют привычное расположение кнопок на большинстве клавиатур продавца.
- Расположение цифрового ряда повторяет расположение клавиш правого ряда (ряда NumLock) на стандартной клавиатуре (акселераторы «верхних» кнопок-действий с чеком тоже взяты со стандартной клавиатуры).
- Действию «Оплата» назначен акселератор «+» потому, что при оплате наличными достаточно удобно на стандартной клавиатуре(в секции NumLock) последовательно нажимать «+» и Enter (подтверждение оплаты). Собственнно, поэтому кнопка «Оплата» на форме расположена вверху, т.к. визуальные ощущения совпадают с тактильными. Кнопка «Оплата» расположена вверху еще и потому, что она визуальна связана с полем, где выводится сумма чека (сумма возврата), что какбэ намекает.
- Кнопки разнесены в соответствии с направлением взгляда. «Редкие» кнопки – внизу экрана, «Рабочие» — под правую руку. Отображение наименования в текущей строке – выше середины экрана (основное место прямоугольной картинки, куда падает взгляд человека).
Отображение кнопок отключается кнопкой «Клавиши (/)», такой же интерфейс будет при открытии, если ОткрыватьПравуюПанельПриЗапуске = Ложь(актуально, обычно, при подключенной программируемой клавиатуре продавца):
Если в настройках РМК ЗакрыватьПодборПриВыбореТовара = Ложь, тогда при нажатии на кнопку «Подбора (F)» (или акселератор) подбор открывается в нижней части экрана, размером в половину ТЧ «Товары» (подбор не будет закрыт после выбора товара для возможности продолжения выбора из подбора):
Если ЗакрыватьПодборПриВыбореТовара = Истина, тогда видимость подбора заслоняет ТЧ «Товары». После выбора товара подбор закрывается:
В подборе дополнительно отображаются остатки и цены товаров текущего магазина.
Интерфейс оплаты чека
Форма оплаты чека вызывается нажатием кнопки «Оплата (+)»:
Форма оплаты чека поделена на четыре части, оптимизированных, как для ввода данных с/без мышки, так и с touch–screen:
- Верхняя часть – информационная, где отображается сумма чека и внесенная сумма.
- Средняя – «Поле ввода», в которое можно внести данные с цифровой панели клавиатуры или с сенсорногно монитора.
- Левый нижний угол – «Кнопки» видов оплат и «Кнопка» отмены оплаты (удаляется, если оплата была произведена при помощи торгового оборудования эквайринговой системы). По «Кнопкам» возможна навигация стрелками клавиатуры.
- Правый нижний угол – цифровая панель. Обеспечивает ввод с тачскрина или клавиатуры продавца.
Если покупатель желает оплатить товар платежной картой (кредитом), то, при выборе пункта «Карта» («Кредит»), панель видов оплат замещается на панель оплат картами (кредитом).
Только при оплате платежной картой: при вводе «вносимой суммы» и выборе соответствующего вида оплат, если к компьютеру подключена эквайринговая система, пользователю задается вопрос о внесении суммы по карте (для исключения случайных нажатий). Если сумма вносится повторно по одному и тому-же виду оплат (кредиту) – пользователю задается вопрос о доплате или замене текущей суммы.
Форма оплаты закрывается и пробивается чек, когда сумма внесенных денежных средств больше (в части нала) или соответствует сумме чека.
Интерфейс установки скидки/наценки на чек
При нажатии кнопки «Уст % на чек (F5)», или акселератора F5 открывается меню установки скидки / наценки на чек.
В меню скидки / наценки на чек возможно ввести процент (сумму) скидки, с клавиатуры, с touch-screen или мышкой (клавиши ввода цифр отображены на экране).
- После ввода цифр необходимо указать (нажатием кнопки, акселератора или перемещением курсора стрелками клавиатуры), что эти цифры означают: скидку или наценку, процентную или суммовую.
- Если это «суммовая скидка» будет произведен перерасчет данной скидки в проценты и скидка распределена по всем товарам в чеке.
- Если это «суммовая наценка» будет произведен перерасчет данной наценки в проценты и наценка распределена по всем товарам в чеке.
Процентная скидка и наценка, думаю, не нуждаются в пояснениях.
Интерфейс информации об ошибках
Требования к форме информации об ошибке:
- Должна отображаться пользователю.
- Не должна изменять размеры рабочей области.
- Должна максимально точно описывать сложившуюся проблему.
- Должна быть узнаваема пользователем с «полувзгляда».
- Должна по возможности комментировать дальнейшие действия пользователя.
На основании вышеописанных требований была разработана форма информации об ошибках.
Преимущества перед стандартным комментарием «1С: Предприятие» (то, что вылезает внизу экрана):
- Не изменяет размеры формы.
- Легко закрыть. Тем более с подключенной клавиатурой продавца, т.к не нужно отдельный акселератор прописывать на закрытие «всплывающих» ошибок.
- Возможность отобрзить ошибку в различном варианте оформления.
- Первая строка – класс ошибки.
- Вторая строка — категория ошибки.
- Третья строка – полное описание ошибки или варианты дальнейшей работы.
Преимущества перед предупреждением (всплывающим модальным окном):
- Возможность читабельного вывода многих строк текста. Оформление текста.
- В режиме touch–screen размер кнопки адекватен удару кулаком 😉 шутка.
Взаимодействие с другими подсистемами, механизмами
Взаимодействует с подсистемой торгового оборудования.
Ограничения, следующие из проектных решений
Ограничений нет. Интерфейс будет развиваться.
Переход с предыдущих релизов и обновление информационной базы
Не требуется.
Порядок тестирования
- Проверить возможности настройки рабочего места РМК.
- Оформить несколько документов «Чек ККМ» для продажи товаров.
- Проверить подбор товаров с помощью набора штрихкода.
- Проверить корректность работы механизма подбора и возможности поиска по подбору.
- Проверить корректность работы функциональных клавиш при продаже товаров (скидка на сумму чека, скидка по отдельным позициям и т.д).
- Проверить корректность установки скидок по дисконтным картам.
- Оформить оплату чеков по различным видам оплаты: по каждому отдельно и смешанная оплата. Со смешанной оплатой оформить два чека.
- Оформить возврат товаров от покупателя по чеку со смешанной оплатой в той же кассовой смене.
- Проверить корректность оформления и печати списка документов при возврате товара.
- Проверить формирование пакета документов при возврате товаров от покупателя.
- Проверить установку запрета на доступ к данным в соответствии с настройками РМК во всех возможных вариантах.
- Проверить работоспособность программируемой клавиатуры.
Что из проекта осталось не реализовано
Проект реализован полностью, удовлетворяет поставленным требованиям.
Послесловие
Это был самый первый проект по разработке РМК для «1С: Розница», скриншоты актуальны для бета-версии. С тех пор интерфейс и механизмы все улучшались и расширялись, но это — тема отдельных проектов.
Александр Волков, 2008
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Я может быть не увидел. Но как дела обстоят с акциями(к примеру покупаешь две получаешь одну в подарок) или это придется все самому программисту доделывать?
Ниче не надо доделывать — юзай скидки.
Спасибо разработчику Розницы!
Хотел узнать у автора, почему такая продуманная интерфейсная модель Розницы 1.0 уступила место простенькому и неудобному интерфейсу в версии 2.0? Смена команды?
Этот вопрос мне задавали не раз…
Основная причина в том, что весь интерфейс первой редакции «1С: Розница» и все, что с ним связано, с огромным скрипом, мне удалось продвинуть в типовое решение «1.0» (это было очень-очень-очень непросто), мотивируя это юзер-экспиренсом и кучей юзабилити-тестирований. Сейчас решением занимается другая команда…
(4) Действительно РМК в Розница 1.0 разительно отличается в плане подходов к построению интерфейсов в сравнении с тем что обычно делают в 1С. Многое в интерфейсе РМК пришлось «допиливать» для того чтобы можно было полностью отказаться от клавиатуры и полностью перейти на Touch Screen, но как для стандартной конфигурации очень много уже готово.
Спасибо.
Я был бы Вам очень признателен, если бы Вы сказали, что именно пришлось «допиливать»?
Из того, что я могу вспомнить — на некоторых внедрениях приходилось:
1. Убирать курсор мышки. Не сделано в типовой, т.к. это противоречит стандартам разработки.
2. В подбор добавлять вывод изображения. Это уже отраслевая специфика.
3. Добавлять отдельные функции с подключаемыми обработчиками (на «внешних» механизмах), которых нет в типовой. Это тоже отраслевая специфика.
Удобство РМК для пользователя в рознице 1.0 на высоте, чего не хватает большинству конфигураций 1С. При внедрении розницы, сложности возникли только когда решили реализовывать продукцию сотрудникам в счет зарплаты (не удалось совместить печать на разные ККМ в одном интерфейсе).
(6) Пришлось добавить полноценную (не только цифры) экранную клавиатуру в форму РМК. Все сообщения переделать для формы с большими кнопками. Больше всего изменений было по разного рода сообщениям кассиру. Добавить кнопку удаления выбранной накопительной дисконтной карты. Еще по мелочи что то. Подробнее можно почитать тут
(6) Из глобальных изменений в «1С:Розница» был полностью переписан механизм по скидкам, дисконтным картам и подарочным сертификатам. Написан механизм обмена с управленческой базой (УПП) по технологии XDTO. Практически полностью переписано взаимодействие с фискальным регистратором. Устранены «узкие» места по производительности и масштабируемости.
(9) ZLENKO.PRO,
Скажите, пожалуйста, Вы переписывали первую версию (УТ-шную) механизма скидок или второю (Розничную)? Первая версия была заимствована в УТ/УПП и, конечно, не отвечала многим потребностям розничных предприятий. Вторая версия — это полное переосмысление понятия скидки, как таковой (в контексте «1С»-овских систем). Декомпозиция скидки на отдельные сущности и предоставление механизмов их произвольной компоновки. Если Вы работали над вторым вариантом, то очень интересно узнать, что в нем не устраивало.
По поводу обмена — это, конечно, всегда дело субъективное, т.к. зависит от процессов интегрируемой системы, поэтому обмены переписываются достаточно часто.
По поводу взаимодействия с ТО, а точнее с ФР: есть стандартный «1С»-овский интерфейс для торгового оборудования, которому должны соответствовать драйверы торгового оборудования. Удовлетворение этому стандарту позволяет вендорам ТО получить сертификат «1С: Совместимо». Из этого следует, что малейшее изменение интерфейса влечет огромный перечень проблем, конечно, не технических. Для «Розницы» удалось несколько расширить этот стандарт, но, как обычно, с ограничениями.
Вернусь к скидкам. Признаюсь, что часто скидку проще описать кодом (был и такой вариант реализации), т.к. здесь можно учесть все тонкости. Механизмы настройки создаются для тех пользователей, которые не имеют возможности качественно изменить код. Слово «качественно» здесь ключевое, т.к. в России совсем немного разработчиков, которые в состоянии написать рабочий код без того, чтобы что-то не сломать, да.
(9) ZLENKO.PRO,
Еще добавлю, что подарочные сертификаты и бонусные карты реализовывать в рамках ИС, базирующейся на платформе «1С: Предприятие 8» — дело неблагодарное в силу несовместимости ограничений платформы и потребности процессинга работать в режиме он-лайн. Я рекомендую интегрировать учетную систему (ту-же «1С: розница») с качественным процессингом и не стараться в сотый раз изобретать велосипед, который как ни крути — не будет ехать, так как задумано.
(10) Переписывал версию Розница 1.0, т.к. версия 2.0 вышла намного позже. На самом деле глубоко не анализировал возможности 2.0 в плане конструктора скидок. Просто пока не было такой необходимости. Согласен что абсолютно все возможные условия предоставления скидок конструктором описать невозможно, но мне в моей подсистеме удавалось реализовать все что придумывали маркетологи заказчика (поверьте они знают толк в извращениях:-)), правда иногда таки приходилось дорабатывать код подсистемы скидок. Кстати Розница 2.0 до сих пор не локализована для Украины…
По поводу ФР я понимаю что стандарты достаточно ограничены, но невозможность передавать сумму скидки по строке, а не % скидки уже порождает множество проблем. Кроме того я выжал все что только можно из конкретно взятого фискального регистратора — минимум трехкратное уменьшение длины чека и понятность чека для покупателя.
(11) Завязываться на сторонний сервис процессинга ПС и накопительных карт означает ограниченность возможностей возможностями конкретного сервиса. Мой заказчик например захотел подарочные сертификаты с «гибкой» суммой, т.е. сумма сертификата определяется стоимостью сертификата при продаже — используется для предоплаты товара «под заказ». Сомневаюсь что сторонние сервисы имеют такую возможность…
Если честно, то я не понимаю в чем принципиальная проблема процессинга карт и ПС на 1С в единой базе данных. Сейчас активно развивается сегмент облачной розницы. Я уже давно понял что ставить базу на каждое рабочее место (как некоторые делают типа для повышения надежности) — в корне неправильный подход.
Мне было бы интересно сделать облачное решение на основе Розница 2.0, но пока что нет конкретного заказчика, а заниматься этим из чисто спортивного интереса я не могу себе позволить 🙁
В целом по поводу розницы могу сказать что потребителя интересует на 100% готовое рабочее решение. Так уж сложилось что конфигурации от 1С являются скорее качественными универсальными заготовками, чем готовым решением.
(10) Если интересно пообщаться на тему 1С Розница — напишите мне в Skype: ZLENKO.PRO
(12) ZLENKO.PRO,
Новая версия подсистемы скидок вышла в редакции 1.7 или 1.8, это был финальный проект, который я писал для РТ.
Процент скидки замечательно передается строкой, если Вы используете функционал WYSIWIG настройки внешнего вида чека для фискального регистратора. Этот функционал позволяет что-угодно и как угодно передать для печати на чеке. Я, на своем опыте, столкнулся с сеткой, в которой уже долго стояла РТ, а печать на ФР была сильно переписана под драйвер… любое изменение чека требовало массы усилий, да. Почему они не использовали гибкий WYSIWIG конструктор внешнего вида чека? Потому, что не знали, что он есть! Этот случай, кстати, стал одним из мотиваторов того, что я начал публиковать тексты своих техпроектов на специализированном ресурсе.
Про «Розницу 2.0» ничего сказать не могу, но слышал много весьма негативных отзывов о том, как качество программы ухудшилось по всем параметрам.
(13) ZLENKO.PRO,
Гибкая сумма и прочие бонусы — это как раз тема для реализации сторонней организацией (именно организацией), т.к. очень хорошо ложится на правовые рельсы (в России). Остальные способы, так или иначе, будут «не совсем» попадать под различные законодательные акты. Это является одним из козырей сторонних процессингов.
Попытка влезть 1С в облако, может стать удачной только, если 1С включит «на полную» свою маркетинговую машину, которая устранит всех совковых конкурентов (что сейчас происходит) и нивелирует стоны пользователей по поводу грузности, отсутствия масштабируемости, тормознутости, сложности, громоздкости и всех многочисленных врожденных пороков платформы.
По поводу «зачем ставить отдельную версию на каждую кассу?»:
Как можно опираться на «облако» в условиях отсутствия стабильного коннекта даже в крупнейших торговых центрах Москвы? Если бы все было так просто, то ДАВНО бы все кассы с РТ работали в терминальном режиме и не тренировали голову обменами данных. ДАВНО — т.е. задолго до того, как маркетологи придумали, пудрящее головы людям, слово «облако» 🙂
По поводу 100% готового решения:
Я могу с полной ответственностью заявить, что в нескольких крупных сетках изначально использовалась типовая РТ (а уж количество одиночных магазинов с типовой РТ не счесть) и во многих организациях типовая БП. По остальным решениям — все неоднозначно.
В чем причина того, что одни могут внедрить типовую, а другие нет? Одни снимают с поддержки конфу, перепиливают её и НЕ обновляют (далее — конфа потихоньку дохнет), а другие реализуют требуемый функционал и оставляют родную поддержку ненавязчивой и приятной?
В посте выше я описал одну крупную контору с раздутым штатом разработчиков, которые не знали возможности продукта, который используют. Так часто бывает. Тем более с 1С-овскими продуктами (документацию мало кто читает, да) и многими «сертифицированными» специалистами (я многих собеседовал — люди кичатся сертификатами, но, к примеру, не могут назвать количество реальных таблиц для регистра накопления или проводки по операции продажи купленного и оплаченного товара или… огромное количество примеров, не буду распылятся).
(16) Чтобы успешно использовать 1С в облаках надо делать функционально законченные решения с отработанными на практике бизнес-процессами. А пока что разработчики конфигураций в 1С больше теоретики… Часто смотриш — функционал вобщем интересный, а вот на практике как его применить не особо понятно.
Посмотрел видео на ютубе про Розница 2.0 — интерфейс РМК «убил»… Дальше смотреть желания не возникло.
(15) По поводу % скидки: на ФР передается цена товара и количество товара, сумму по строке ФР считает сам, а потом на эту сумму надо передать скидку (% или сумму). Не нужно быть семи пядей во лбу чтобы понять что если передавать % скидки, то сумма которую посчитает 1С в чеке и которую посчитает ФР иногда будет отличаться. Разработчики розницы объяснили что % передается потому что не все ФР поддерживают скидку суммой.
Кроме того в чеке даже суммовая скидка пересчитывалась в % что уже само по себе давало погрешность.
По поводу подарочных сертификатов — понравилась идея использовать их как оплату, а не как скидку, но они шли по тому же виду оплаты что и оплата банковскими картами. В итоге потом непонятно сколько было каких оплат.
В подсистеме скидок очень не хватало сегментов покупателей и сегментов дисконтных карт. Не было возможности последовательного применения скидок (скидка на сумму после предыдущей скидки — важно для скидок процентом).
Если поднапрячь память я могу много всего такого вспомнить что вроде как бы и было но работало не так как хотелось бы. Это конечно с одной стороны субъективный мой взгляд и моего достаточно требовательного клиента, но с другой стороны может часть клиентов и так устраивает.
(16) Я выжал использовал по максимуму то что было в типовой Рознице. Даже печать чека сделали через конструктор хоть и помучились с его «допилом» изрядно, но жалко было не использовать такой интересный функционал. Там было что то напутано с заголовком и подвалом, но конструктор приятный. Жаль не осталось образца чека который в итоге получился показать. Буду что нибудь покупать — отсканю и выложу этот шедевр 🙂
ZLENKO.PRO,
Я понял, что Вы не видели реального розничного механизма скидок, т.к. там как раз все желанные бинарные конкатенации, последовательные применения и прочие сегментирования по настраиваемым отборам реализованы, да. Еще раз повторюсь, что этот функционал покрывает 80% требований к маркетинговым акциям и он реально используется в сетках, как есть — без допилов.
По чеку и шаблонизатору. Каких-от проблем с заголовком и подвалом припомнить не могу и не уверен в их присутствии, т.к. этот механизм и в хвост и в гриву проверялся группой тестирования (РТ одна из первых конфигураций, которая проходила столь тщательные тески группы тестирования). После, на практике, я его применял многократно — и всегда результат был отличный. Про передачу суммы или процента скидки на ФР — я помню эту заморочку. Идея передавать скидку, как таковую в ФР, мне кажется порочной, так-же, как и вносить скидку процентом в товароучетную систему (привет УТ). Вообще ИМХО — все, что написано на чеке должно быть текстом (картинки тоже можно) с одной лишь итоговой фискальной строкой. Для этого и служит шаблонизатор чеков WYSIWIG. (по поводу практики — первой просьбой в магазинах раньше было: «хочу, чтобы ценники были такие-то, а чек такой-то» :)) — кстати, ноги wysiwig’а в РТ).
«А пока что разработчики конфигураций в 1С больше теоретики…».
Вот мне интересно — на основании чего вы это утверждаете? Я являюсь разработчиком и автором «1С: Розница 8». С 2003 года занимался автоматизацией розничных предприятий и различных сеток…долго мучал УТ, всевозможное ТО и POSы, управлял крупными проектами внедрения. Со школьной скамьи учился грамотно проектировать софт — в итоге стал признанным архитектором информационных систем. Было дело, пришел в «1С» с одной лишь целью — сделать тот продукт, который бы удовлетворил, в первую очередь, потребности розничных предприятий, во вторую, потребности интеграторов. Сотни благодарных отзывов и многотысячные продажи ПО в подтверждение тому, что это получилось.
Кстати, «1С: Розница 8», в процессе создания, внедрялась в собственной розничной сети «1С», были и другие пилотные проекты.
Идея использовать подарочные сертификаты, как оплату — не прошла мой тест на удовлетворение правилам учета в торговых предприятиях. Это было сделано после меня, да. Этот механизм я ни за что бы в релиз не пропустил. Как было сказано выше — сменилась команда и изменились требования к процессу разработки. В итоге — Вы видели «видео на ютубе про Розница 2.0″…
(20) В Розница 1.0 был только справочник «Сегменты Номенклатуры», сегментации по контрагентам и информационным картам не было. Если бы они там были я бы их не создавал 🙂 Т.к. обрабатывать 300 тыс. информационных карт без механизма сегментации было просто нереально.
И последовательного применения скидок там не было, т.к. последовательное применение входит в противоречие со способами объединения скидок минимум и максимум — получаем нетривиальную рекурсивную логику работы. Были способы объединения: «Сложение», «Вытеснение», «Минимум», «Максимум», а вот «Умножения» не было. Последовательное применение эквивалентно умножению процентов скидок (не сложение).
Так что не надо говорить что я не видел этого механизма в Розница 1.0 — я его разобрал «до последнего винтика»…
А вот Розница 2.0 я действительно не видел — по этому поводу я и не спорю.
(20) Поэтому я и сказал по поводу теоретиков и практиков… При использовании в чеке суммы скидки по строке (а не процента) и передаче ее в ФР все проблемы решаются с округлениями. При чем чтобы не было конфликтов надо разделять ручные скидки (отдельно процент и сумма), автоматические скидки (сумма) и округление (сумма) по строке и ручные скидки (отдельно процент и сумма) по чеку в целом. Сначала рассчитываем сумму автоматических скидок по строке, потом рассчитываем сумму ручной скидки (если указан процент, а если сумма то она уже есть) и потом считаем округление по строке для чека без копеек. Тогда все получается очень прозрачно и не возникает никаких конфликтов при использовании ручных скидок.
Вот здесь мое мнение по этому поводу:
Я понимаю что критика как автору решения Вам не очень приятна. Да и потом если бы в конфигурации было все идеально я не получил бы проект на пол-года по ее доработке и запуску 🙂 Так что воспринимайте сказанное мной не как претензию, а как обмен опытом использования.
(20) На самом деле хочу поблагодарить за Розницу 1.0, особенно после того как увидел видео по Розница 2.0 !
Я откровенно говоря не ожидал такого продвинутого интерфейса РМК от 1С. К сожалению счастье было не долгим (2.0).
Ну и вот после Розницы 2.0 (epic fail) Вы продолжаете утверждать что разработчики в 1С не теоретики ? 🙂
(20) Кстати по поводу подсистемы скидок — если пороетесь в форуме разработчиков 1С , то увидите что именно я предложил разработчикам 1С (непосредственно Вам 🙂 ) использовать «дисконтное дерево» и подсказал «прототип» ATOL CARD.
(20) Я вот здесь начал описывать то что сделано в моей версии по «1С: Розница 1.0»:
Пока что не очень подробно, т.к. не могу правильно позиционировать это решение…
Для массового рынка дорого, а крупных игроков в украинском ритейле не так уж много. Вот думаю может попробовать на российский рынок позиционироваться.
Если есть интерес в этой области — можем объединить наши усилия 🙂
Skype: ZLENKO.PRO
(24) ZLENKO.PRO,
Не поверите, но атоловский механизм и механизмы остальных розничных решений я начал применять задолго до того, как занялся разработкой механизма скидок для РТ в середине 2008-го года. Перед началом работы над скидками разобрал все мало мальские вменяемые системы.
Вы говорили про последовательное применение (иными словами «умножение» и то, что его нет), что скажете по поводу данного скриншота(?):
Далее. Сегметы инфокарт и контрагентов. Вот скриншот, где они присутствуют:
Виды дисконтных карт — агрегатор карточек, Группы получателей скидки — агрегатор контрагентов.
Еще раз про передачу скидки в ФР. Зачем это делать вообще? Зачем пробивать каждый товар по ФР, если все, что требуется — распечатать текст и вывести одну фискальную строку с итогом?
(26) Вероятно умножение появилось позже. Я брал за основу версию Розницы 1.0 по состоянию на май 2009 года (в октябре 2009 года уже началась промышленная эксплуатация). Но кстати большой вопрос насколько корректно этот вид взаимодействует со способами применения минимум/максимум.
Ну а по поводу сегментов контрагентов и карт — не надо вводить в заблуждение. Одно дело сегментация по произвольным критериям как сделано для номенклатуры, а другое то что вы показали — отборы по видам и группам. Как говорится — это две большие разницы…
(26) Не поверите 🙂 но осенью 2004 года у меня было готово ТЗ на разработку дисконтной подсистемы на основе анализа ATOL CARD и других систем (все что удалось найти в инете). Собственно остальные системы (ATOL CARD) были мало интересны. Более менее интересным был СуперМаг УКМ (кажется так называется), но там организация скидок была весьма запутанной, а меня интересовала «красивая» реализация. Я долго не мог придумать как обеспечить высокое быстродействие системы на больших объемах данных. Когда увидел в 1С Розница сегменты номенклатуры — это было как просветление 🙂 Просто и гениально.
Но я сильно удивился что этот механизм был сделан только для номенклатуры.
Второе удивление было по поводу механизме сегментации что интерфейс отбора сделан на СКД, а потом условия отбора из СКД передаются в построитель. Очень странное инженерное решение. Правда когда я попытался переделать все на СКД — меня ждал в конце пути большой облом — СКД упорно не хотела возвращать таблицу значений с результатом. Вероятно были какие то баги в платформе на тот момент и поэтому в типовой задействовали построитель. Плюнул и учитывая что тогда СКД не могла работать с планами видов характеристик в отборе — переписал все (в том числе интерфейс отбора) на построителе.
(27) ZLENKO.PRO,
Умножение скидок появилось в релизе РТ 1.0.6. Т.е. в первом-же релизе с новой подсистемой скидок. Почему Вы его не заметили — я не имею представления.
Я понимаю, что можно придраться к любому агрегату и спросить, а почему он не настраивается произвольными отборами 🙂 По секрету — эти самые произвольные отборы очень тяжело проталкивались в конфигурацию, в принципе. Для номенклатуры это получилось сделать с большим трудом и то — только в контексте скидок. Не все стандарты разработки преодолеваются в крупной компании, но зачастую они помогают избавить конечные продукты от всевозможных хотелок разработчиков, которые могут зарубить принципы универсальности, что, в конечном счете, отразится на всей системе продаж. Углублятся не буду. Возвращаясь к настройке сегментов для различных справочников — это было отнесено к отраслевой специфике, т.е. к разработке в отраслевых конфигурациях.
По поводу расчета сумм реально «убила» вот эта фишка
Если из-за разницы в округлениях сумма по строке отличается от ФР, то на ФР передаем продажу 1 штуки на всю сумму по строке. Ну вот скажите — можно в здравом уме такое придумать ?
Вот тут по поводу % скидки:
(28) ZLENKO.PRO,
Сегментацию справочников я пытался протащить в РТ с момента её основания, т.к. сам часто разрабатывал подобные механизмы на внедрениях (не только для скидок, конечно).
А по поводу граблей с новыми механизмами при разработке конфигураций на ежедневно обновляющейся платформе — их было несчислимое множество! Поэтому некоторые решения могут устаревать и казаться странными в процессе обновления платформы. Собственно, чтобы разработчики не изобретали велосипеды и поняли откуда растут ноги того или иного функционала — я начал публиковать тексты проектов.
(26) Прояснилось по поводу умножения. Оно было, но работало несколько мягко говоря странно.
Если правила скидки процентом непосредственно находятся в одной группе с последовательным применением программа работает правильно — учитывается скидка данная по по предыдущему правилу.
А вот если эти правила находятся внутри различных вложенных групп (например, тоже с вытеснением) а потом должны последовательно примениться — получается сложение а не последовательное применение, т.к. накопленная скидка по вложенным группам не учитывается.
Подробнее здесь:
(30) ZLENKO.PRO,
У меня сейчас закрыт доступ на форум, лень искать пароли.
«Если из-за разницы в округлениях сумма по строке отличается от ФР, то на ФР передаем продажу 1 штуки на всю сумму по строке. Ну вот скажите — можно в здравом уме такое придумать ?» Можно, я помню этот ход. Проблема в том, что фискальников много (не только штрихи и фпринты есть на свете), и каждый работает со скидками по своим правилам. В тот момент в РТ, как помню, еще использовался унылый УТшный процент для назначения скидки и интерфейс работы с ФР был сделан для процента. Собственно — складываем эти факторы того момента и получаем одно унылое решение для тех индивидов кто упорно бьет каждую строку по ФР-у. Но я не перестану повторять, что взаимодействовать с фискальником так, чтобы «пробивать» каждую строку — рудимент.
(33) ZLENKO.PRO,
Не буду проверять, то что Вы описали. Вы уже утверждали, что умножения не было…
Если этот баг имел место быть, то он должен быть исправлен. Если его не было, а пользователь неправильно вводил данные, то пользователю должны быть даны разъяснения.
(32) Я понимаю что при разработке типовых используется принцип что должно устроить всех, а в результате устраивает мало кого… По поводу печати информации на ФР есть достаточно жесткие законодательные требования и есть покупатели с «дурацкими» вопросами типа «Объясните мне что я тут купил и за сколько и какая скидка и почему она такая». При чем законодательные требования касаются именно печати фискальной информации. Нефискальную можно печатать какую угодно но сильно не попечатаеш много т.к. длина чека сильно увеличивается. Нехорошо когда клиенту распечатывается несколько метров чека 🙂
По поводу устраивают мало кого — про РТ и БП я уже опровергал ваши догадки.
«При чем законодательные требования касаются именно печати фискальной информации.»
Приведите, пожалуйста, пример российского законодательства, где сказано, что в чек должно быть выведено еще что-то, кроме фискальной итоговой строки. Меня НЕ интересует украинское право и права тех стран для которых РТ локализована, т.к. — это задача локализаторов, если они взялись за это дело.
(34) В моем понимании если умножение не работало как должно было работать, то это все равно что его не было.
По крайней мере моего клиента не устраивало что умножение иногда умножало а иногда складывало.
В ветке на партнерском форуме есть ответ что это сознательное ограничение.
Кстати та же проблема в УТ 11
Просто я хорошо помню что именно этот момент заставил меня полностью и окончательно переписать все ядро Розница 1.0 дисконтной подсистемы фактически «с нуля». Правда мне пришлось из-за этого отказаться от «максимум» и «минимум». Насколько нужны эти виды взаимодействия мне сложно судить. Заказчику важно было чтобы скидки умножались а не складывались (разница в деньгах существенная), а минимум и максимум сложно объяснить потом клиенту почему у него такая скидка а не другая — вариант с вытеснением проще объяснить — если участвуеш в этой скидке, то не участвуеш в той и все.
Это ж было три года назад — я могу не помнить некоторые детали. Сорри за неточность.
(36) Не могу ответить на Ваш вопрос т.к. российской розницей занимался последний раз в 2004 году. Не в курсе актуального российского законодательства.
(29) Мне с позиции конечного пользователя проблемы бюрократии внутри 1С мало интересны сами по себе 🙂
Просто казалось бы могло получится отличное готовое решение, а получилась хорошая «заготовка» (о чем я и писал в самом начале). А еще мне очень не нравится решение 1С из чисто маркетинговых соображений вырезать розницу из конфигурации «Управление торговлей». За последние несколько месяцев было несколько небольших заказчиков, которым нужно и опт и розницу — две разные базы и обмены между ними создают множество дополнительных проблем за решение которых заказчик не хочет платить. Пусть розница отдельная конфигурация — она востребована как отдельное решение, но тогда Управление торговлей надо переименовать в «Управление оптовой торговлей» 🙂
Зря вы так говорите. Сейчас проданы десятки тысяч лицензий — и многие используют типовой функционал. Более продвинутые — читают документацию и поражаются, что «оказывается можно контролировать рабочее время продавцов» или что-то еще 🙂 Большие сетки заказывают комплексные внедрения на сотни и тысячи магазинов.
На вкус и цвет фломастеры разные. Если ваши три магазинчика предъявили повышенные требования к функционалу, то это повод Вам заняться работой, что 1С и предлагает. Хотите — сделайте отраслевую конфигурацию и продавайте её. Вы, как и множество обывателей, до сих пор не можете понять, что есть база, а есть специфика — упорно гнете линию по «хочу все и сразу» (помните перламутровые пуговицы?). Это применимо не только к конфигурациям на всяких платформах, но и к жизни.
Из УТ ничего не вырезалось. Если заимствовались механизмы, то они проходили тщательную верификацию, во многих, кстати, правились ошибки, что-то переделывалось на корню — ибо не подходило под требования ритейла. Т.к. РТ активно использует обмены с УТ/УПП/БП, то приходится некоторый функционал делать идентичным для корректного отражения в «связанных» базах. УТ всегда позиционировалась для опта и никогда для розницы, Вы не знали?
(40) Согласен — десятки тысяч подопытных кроликов не могут ошибаться 🙂
Согласен — мир не идеален и идеальным не будет никогда, но это не повод к этому не стремиться 🙂
Согласен — розницы в конфигурациях 1С до выхода «1С:Розница» не было вообще, но за последние два месяца два моих клиента отказались вообще что либо внедрять когда узнали что им придется отдельно опт и отдельно розницу и заморачиваться с обменами.
Прекращаем флуд.
(42) Поддерживаю. Вобщем то все уже и обсудили по теме и даже больше.
Спасибо очень полезная статья и я ее во время увидел)))
При конвертирования из 8.0 в 8.1 сохраненных в 8.0 только справочников
(Справочник номенклатуры, справ. ед. из, классиф. ед изм, валюты и т.п )
получилась ситуация
Элемент номенклатуры
— базовая единица заполнена.
— Табличная часть (единиц измерения) заполнена.
НО ЕдиницаДляОтчетов -не выбрана
ЕдиницаХраненияОстатков — не выбрана
т.е. поъхоже ссылки на ед. из. утерены при конфертировании.
Задача проставить каждом элементе номенклатуры в соответствие
ЕдиницаДляОтчетов и ЕдиницаХраненияОстатков Базовую еденицу Измерения
Делаю так
Ссылка = Справочники.Номенклатура.НайтиПоКоду(» Код элемента»);
Элемент = Ссылка.ПолучитьОбъект();
Запрос2 = Новый Запрос;
Запрос2.Текст = «ВЫБРАТЬ
| ЕдиницыИзмерения.Ссылка,
| ЕдиницыИзмерения.Владелец,
| ЕдиницыИзмерения.Код,
| ЕдиницыИзмерения.Наименование,
| КлассификаторЕдиницИзмерения.Ссылка КАК Ссылка1,
| КлассификаторЕдиницИзмерения.Код КАК Код1
|ИЗ
| Справочник.ЕдиницыИзмерения КАК ЕдиницыИзмерения
| ЛЕВОЕ СОЕДИНЕНИЕ Справочник.КлассификаторЕдиницИзмерения КАК КлассификаторЕдиницИзмерения
| ПО ЕдиницыИзмерения.ЕдиницаПоКлассификатору = КлассификаторЕдиницИзмерения.Ссылка
|ГДЕ
| ЕдиницыИзмерения.Владелец = &Владелец
| И ЕдиницыИзмерения.ЕдиницаПоКлассификатору.Код = &ЕдиницаИзмПоКл»;
Запрос2.УстановитьПараметр(«Владелец»,Справочники.Номенклатура.НайтиПоКоду(Ссылка.Код).Ссылка);
Запрос2.УстановитьПараметр(«ЕдиницаИзмПоКл»,Справочники.КлассификаторЕдиницИзмерения.НайтиПоКоду(Элемент.БазоваяЕдиницаИзмерения.Код).Ссылка );
Результат2 = Запрос2.Выполнить();
ВыборкаЭЛ = Результат2.Выбрать();
Если ВыборкаЭЛ.Количество()=1 Тогда
Сообщить («Правим этот элемент»,СтатусСообщения.БезСтатуса);
Элемент.ЕдиницаДляОтчетов = ВыборкаЭЛ.ЕдиницыИзмерения.Ссылка;
Элемент.ЕдиницаХраненияОстатков = ВыборкаЭЛ.ЕдиницыИзмерения.Ссылка;
КонецЕсли;
Элемент.Записать();
Где я не прав?
Подскажите пожалуйста!!
(40) «УТ всегда позиционировалась для опта и никогда для розницы, Вы не знали?»
Время — лучший судья 🙂 В нашем споре тоже. В «Управление торговлей 11.1» вернули функционал розницы 🙂 Это досадное недоразумение в виде «Управление торговлей 11» стало историей.
Так и не понял, а где тут под сенсорное управление? в такие кнопки вроде и не попасть? или инфа устарела?
(46) ZLENKO.PRO,
Да уж. В 2007 году его не было и не планировалось.
В УТ11 хотели сделать функционал розничной торговли (я даже принимал в этом участие на первых этапах), но в силу огромного числа факторов эта идея была замята. А я особо и не настаивал, т.к. ***, да и у меня была своя конфа, которую надо было развивать, в которой должно было появиться ещё очень много-много всего нужного и полезного, но большая часть так и осталась в моей голове или в каких-то описаниях.
(47) pafftis,
На мониторе 15″ в кнопки можно попасть даже левой пяткой, так-то.