ТиС продажи в розницу

Лучше ТиС на фронт энд рабочих местах не ставить оч небольшая производительность труда получается у продавцов

Атол Frontol гораздо работоспособнее,
чтобы попробовать у них есть триал версия редакции Оприм, 900р на 6 мес
http://www.atol.ru/products/programs/front-office/frontol-32/

Попросили помочь одному магазину с 1С, обнаружилась такая фигня. Продажа в розницу регистрируется с помощью документа "Инвентаризация", на основании которого вводится документ "ОтчетККМ". По некоторым позициям номенклатуры возникает разница в 1 копейку (в сумме продажи и в цене), т.е. в Инвентаризации одно, а в ОтчётеККМ другое. Похоже проблема в округлении. С ТиС работал мало, поэтому прошу помочь советом, как решить проблему.
Пример:
в документе "Инвентаризация" - Рыба - кол.учет 0,638; кол.факт. 0,326
сумма(учет) 317,72; цена 498,00; сумма(факт) 162,35
в документе "ОтчетККМ" - Рыба - кол-во 0,312; цена 498,01; сумма 155,38

Как видим появилась разница в 1 коп. в цене и в сумме продажи.

Просто цену вручную исправить и все. Скажи им, пусть не грузятся. Только не соглашайся добавлять знаки после запятой в цену! А отчет ККМ по инвентаризации - это, конечно, круто. Они не хотят комп в торговый зал поставить, чтобы отчеты ККМ автоматически формировались ежедневно?

Нет, комп в торговый зал нереально. А если поправить модуль ОтчетаККМ (закомментировать глПересчетТаблЧасти(Контекст,"Сумма")) чтобы цену не пересчитывал - это прокатит?

> Нет, комп в торговый зал нереально
См. картинку

Продажа осуществляется в розницу с 3-х касс, тремя продовцами. Магазин продуктовый. Какой комп в торговый зал???

А ты как думаешь, в "Пятерочке" что стоит у продавцов на кассах? Обычные celeron 1000, только в металлических корпусах, с маленьким дисплейчиком и сканером штрихкода. И стоит эта бодяга от 50000 руб. Я теперь понял, почему так сложно найти мне кого-то, кто бы помог с внедрением моей "Кассирочки" в другом городе. Просто народ конкретно не вьезжает в процесс торговли с использованием сканеров. Я представляю, сколько хлопот по учету продаж в твоем магазине. А делов-то! Поставил три компа, потратил час на обучение работе со сканером кассиров - и все! Все продажи начинают фиксироваться автоматически, продавцы гарантированно не ошибутся и не общитают по ценам. Реализация за день в Торговле и складе формируется автоматически. Всегда виден остаток реальный, можно динамику продаж сформировать, всегда увидеть, какой продавец что и восколько продал и т.д. У меня один клиент вообще оборзел. Шесть магазинов у него сопровождает один оператор всего лишь, потому что все делается автоматически. Кстати, сеть не нужна. для обмена данными достаточно флешки.

Serg76 Написал:
-------------------------------------------------------
> Продажа осуществляется в розницу с 3-х касс, тремя
> продовцами. Магазин продуктовый. Какой комп в
> торговый зал???

У нас при аптечной базе открыли две аптеки для продаж в розницу (и не только). Так вот, в каждой аптеке по несколько компов, но не это главное, а то, что по одному компу выделено по кассовые сервера: сервер в бытовке, а кассовые аппараты естественно в зеле. В каждой аптеке к кассовому серверу подключено по 4 кассовых аппарата. Все реально работает и никаих компов в торговом зале. Имеется в виду без необходимости. Все-таки по одному компу в зале имеется: но сугубо для справки - покупатель при виде большой очереди (хотя с этим мы активно боремся), или по телефону всегда сможет получить информацию о наличии товара и его цене.

ЗЫ
О-Планет написал: Просто народ конкретно не вьезжает в процесс торговли с использованием сканеров

Продажа только и только по сканерам (и один хрын - все равно очереди. Иногда создается впечатление, что весь город к нам сбегается). Так что подумываем увеличивать количество точек отпуска.

Мужики! Это - частный магазин, там всего 1 компьютер, там даже бухгалтера в штате нет, есть приходящая девушка пару раз в неделю. Доказать владельцу, что он должен потратить десятки тысяч на сканеры штрих-кодов, новые компы и т.д. нереально. Кроме того, от способа ввода информации в систему проблема не исчезнет. В описанном мной примере (см. первое сообщение)имеем:
поступило 0,638 кг рыбы, её розничная цена 498 руб. за кг
Т.о. если её сразу всю продать то выручка составит 0,638*498=317,72 руб.
Если продавать частями то получим
0,312*498=155,38
0,326*498=162,35
Итого 155,38+162,35=317,73 руб.
ПОЯВИЛАСЬ РАЗНИЦА В 1 КОП. И какая разница как фиксировать факт продаж - копейка всё равно появляется?

дружище Битнер!
попробую посчитать КАК НАДО
0.312/0.638*317.72 = 155.37404388714733542319749216301 = 155.37
0.326/0.638*317.72 = 162.34595611285266457680250783699 = 162.35

(155.37+162.35)-317.72 = 0 коп. невязки

ГДЕ Я НЕПРАВИЛЬНО?

На самолм деле - это не решение проблемы, а так.. тренировка.. чтобы ты подумал...

Изыски с математикой - это конечно хорошо. Понятно, что проблема в округлении. Непонятно зачем в ОтчётеККМ после заполнения табл. части из документа-основания идёт пересчёт цены (вызовом глобальной функции). Цену-то зачем пересчитывать???

хз.. не знаююю надо смотреть.. по рознице не работал...

Объясню проблему более подробно.
Выдержка из модуля док-та ОтчетККМ

//**************************************
// ЗаполнитьПоИнвентаризации(ОписаниеОш)

//// Возвращаемое значение:
// 1 - функция отработала успешно, 0 - возникла ошибка
//
// Описание:
// Заполняет документ на основании документа Инвентаризация по рознице
//
Функция ЗаполнитьПоИнвентаризации(ОписаниеОш)

Если (ТаблицаДокумента.КоличествоУчет - УжеСписано > ТаблицаДокумента.Количество) Тогда

// т.е. по учету больше чем факт, т.е. куда - то пропало
НоваяСтрока();
Номенклатура= ТаблицаДокумента.Номенклатура;
Количество = ТаблицаДокумента.КоличествоУчет - ТаблицаДокумента.Количество - УжеСписано;
Единица = ТаблицаДокумента.Единица;
Цена = ТаблицаДокумента.Цена;
ВремСумма = (Цена * Количество);
Сумма = ВремСумма - ВремСумма * Скидка.Процент / 100;

глПересчетТаблЧасти(Контекст,"Сумма");
КонецЕсли;
КонецЦикла; // по строкам основания

Возврат Рез;
КонецФункции // ЗаполнитьПоИнвентаризации()
/////////////////////////////////////////////////////////
Как видно из документа-основания передаётся цена (в нашем примере 498 р) и количество ( у нас 0,312 кг) и ещё кое-что, что нам сейчас не важно. Далее рассчитывается сумма как цена*кол-во (498*0,312=155,38 руб), а затем идёт вызов той самой глобальной функции глПересчетТаблЧасти(Контекст,"Сумма").

Выдержка из функции глПересчетТаблЧасти(Конт,ИмяРеквизита)

ИначеЕсли ИмяРеквизита = "Сумма" Тогда
................
Иначе
Конт.Цена=?(Конт.Количество=0,0,Конт.Сумма/Конт.Количество);
КонецЕсли;
/////////////////////////////////////
Как видно здесь идёт пересчёт цены как сумма/кол-во (в нашем примере 155,38/0,312=498,01). Появилась РАЗНИЦА В 1 КОП. В ЦЕНЕ. Эта цена и заносится в табл. часть док-та и при проведении конечно идёт ругань что товара с такой ценой на складе нет.
Вот и вопрос - как с этим бороться и зачем идёт пересчёт цены?

есть следующее мнение
тут еще фигурирует скидка, которая дается в рамках типовой проги от суммы поэтому написано так...
оперативно полечить можно типа так:
Если ПустоеЗначение(Скидка.Процент)=1 Тогда
глПересчетТаблЧасти(Контекст,"Цена");
Иначе
Сумма = ВремСумма - ВремСумма * Скидка.Процент / 100;
//здесь надо подумать...
глПересчетТаблЧасти(Контекст,"Сумма");
КонецЕсли;

Действительно, на скидку я не обратил внимания. В этом магазине её нет и никогда не будет, поэтому, думаю, всё-таки можно ограничиться закомментированием строки глПересчетТаблЧасти(Контекст,"Сумма").
Всем большое спасибо за обсуждение проблемы!

P.S. для Che Burashka
Помнишь ты писал, что сложные вещи туго идут, а сам в последней версии SendMSG используешь ВК. Считаю, что v.1.1 самая лучшая. Что касается моего мода, то он писался для моей работы и не претендует на универсальность. Проверить его в рабочей группе не могу по причине отсутствия таковых сетей на работе. Кстати, комплекс утилит администратора откуда взята Admin1С.dll действительно хорош. Мне как сисадмину он очень нравится. А ты как считаешь?
С уважением, Serg76.

> Доказать владельцу, что он должен потратить десятки тысяч на сканеры штрих-кодов, новые компы и т.д. нереально.

3000 руб. + прога 6000. И вопрос с вороством, общетом и т.д. снимается. Кстати, и твой вопрос снимется, ведь отчеты ККМ формируются автоматически, и никакой пересчет, сответственно, не включается.

Что касается твоего вопроса - без изменения конфы не решить. Поставь для начала после запятой в табл части в цене и сумме 4 знака. Мож поможет. Попробуй на демке. Я еще так решал (но на плане счетов): делал доп проводку по суммовой разнице, связанной с округлением.

Re to O-Planet: > 3000 руб. + прога 6000. И вопрос с вороством, общетом и т.д. снимается. Кстати, и твой вопрос снимется, ведь отчеты ККМ формируются автоматически, и никакой пересчет, сответственно, не включается.

Всего 9000??? Маловато! А компы, а обслуживание. Да и продавцы неохотно идут на такие кассы, ну и наконец не хочет просто человек.
А вот проблема не фига не снимется. Как я уже писал раньше какая разница как вводить информацию в систему? Проблема в том что масса считается с точностью до 3-х знаков, а сумма до 2-х. В моём примере с многострадальной рыбой имеем:
если продать всё сразу, то выручка 0,638*498=317,72 руб.
Если партиями, то имеем
1) 0,312*498=155,38
2) 0,326*498=162,35 162,35+155,38=317,73 - выручка
Как видим цена продажи везде одинаковая и сумма масс по партиям равна общей массе, а выручка расходится на ту самую злосчастную 1 КОПЕЙКУ. Вот такой парадокс математики! (желающие могут сэмулировать эту ситуацию в деме и сформировать Товарный отчёт - копейка сразу вылезет). И какая разница как вводить ОтчётККМ - вручную, по инвентаризации или автоматически ЗакрытиемКассовойСмены? Никакой! Ну а про снятие вопроса с воровством и говорить нечего. Ну что мешает продавцу в вечернюю смену продать несколько бутылок пива и пачек сигарет в обход сканера? Да ничего!!!

Попробуем еще раз почитать мой пост (конечно, могу быть не прав)
> дружище Битнер!
1. проблема в том, что вы отталкиваетесь не от той базы расчета
2. опять же всегда можно модифицировать так, чтобы ошибку округления корректировать в "последней" операции

Сумму надо списывать не по весу ДАННОЙ КОНКРЕТНОЙ продажи, а по доле этого веса данной продажи в общем весе...
.. а вообще - м.б. стоит все-таки прислушаться к Опланету?

> И какая разница как вводить ОтчётККМ - вручную, по инвентаризации или автоматически ЗакрытиемКассовойСмены?

Не вьехал ты. У меня отчет ККМ формируется не средствами ТиС вообще, а внешней обработкой. И суммы соответственно в нем не расчитываются, а ВСТАВЛЯЮТСЯ те, что реально прошли по чекам (если только какой придурок потом не захочет пересчитать всю табл. часть)

То же самое и с ревизией: она делается на точке, с пом. сканера с точностью до 1 шт и формируется во внешней программе (на точке), а потом просто загружается (а не расчитывается опять же) Просто товаровед со сканером пройдет по прилавкам и все. Прикинь, ревизия в отделе за 30 минут! Ты енто видел когда-нить?

> Ну а про снятие вопроса с воровством и говорить нечего. Что мешает ...
Все мешает.
1. Сумма по кассе не сойдется с суммой по программе
2. Ревизия покажет недостачу, если продавец продает вообще без кассы.
3. Продавец не может изменить цену товара вручную никак.
4. Программа помнит все чеки в точности до того, кто, что и когда продал

На самом деле, все очень серьезно. Там, где работает "Кассирочка", проблема воровства и общета стояла всегда на 1 месте. И она полностью исчезла (к неудовольствию, разумеется, продавцов и товароведов)

Поддерживаю Опланета. ибо - правильно глаголет.

Чебурашка до-о-обрый!

По поводу "прислушиться" - можно вот что сделать: пиши свою собственную обработку, которая расчитывает и заполняет строки ревизии так, как надо и не использует внутренние механизмы. Помести эту хрень в доп. возможности и не майся. Я бы такую штуку часа за пол написал.

Однозначно надо ставить, тем более если по недорогой цене. Я тебя уверяю - если это частник и у него есть сво ймагазин (точка) 25000 руб на автоматизацию дл янего отстегнуть не проблема.
у себя на старой работе магазин - куча мелочи (семена и прочее) - реальное положение дел можно было узнать только раз в месяц после интентаризации, которая целый день занимала, а ежедневные результаты продаж - по записям в тетрадочке. в результате поставили АРМ кассира (спецсистемник, фиск.аппарат, программируемую клаву, многолучевой сканер, + софт на арм кассира, +бэкофис на ТиСе откуда раз в сутки берутся и сливаются данные), бабла ушло конечно нормально, зато после 2-х месяцев работы шеф сказал - ставить второй аналогичный кассовый аппарат! И БЫЛ ОЧЕНЬ ДОВОЛЕН! в т.ч. и продавцы - сначала кривились, а потом - только на ура...