17.03.2009 17:16
Цитата:
Shlong Проблема в том, что люди привыкшие к суммарному учету, переучиваться к количественному ну никак не хотят, им побоку что один сырок с апельсиновой начинкой, а другой - с лимонной, ЦЕНА ЖЕ ОДИНАКОВАЯ и все тут... И если своим с горем попалам вдалбливаешь в чем разница, то поставщикам это и не нужно, НЕ РАЗ видел как в коробках лежат продукты отличающиеся тока добавками (те же сырки, чипсы и т.п.) по одинаковой цене, для них это нормально для нас это уже ПЕРВАЯ СТАТЬЯ ПЕРЕСОРТА, если кладовщики проспят, что кстати не редкость...
Вот для этого и нужен ПОЛНЫЙ инструментальный контроль. Это когда сканируется каждый сырок при каждом его движении. Но это очень сложно.
17.03.2009 17:19
Цитата:
Назым Кто-нибудь решал эту задачу с положительным результатом?
Что ты понимаешь под положительным результатом?
Абсолютного нуля всё равно не достичь.
Второй закон термодинамики тоже не нарушить.
17.03.2009 17:20
Цитата:
Назым Кто-нибудь решал эту задачу с положительным результатом?
Конечно... всяческая мелочь ... которая заказывается представителями торговых компаний самостоятельно... такие как
Орбит
Дирол..
Конфетки.. а также
Сухарики...
Чипсы и другая не очень принцыпиальная мелочь сводиться на одну карточку типа в АСС...
Остаток общий... заказывать по видам не удобно...но помогает первое время... потом можно опять разнести когда психология магазинов\поставщиков нормализуется...
помогает избавится от 15-20% пересорта (в общем списке)
Затем...
Весь весовой товар перед отправкой на склад и фасовкой маркируется в обязательном порядке этикетками с весов... после ввода накладной оператором и выдачи ценников...
это еще ~10% от тупости фасовщиц и операторов дающих каждый день разные ценники...
Самый большой выявленный пересорт в ревизию (показательно не важно в + или в -) вешается на ......... (фамилию виновного вписать)
избавляет при должной строгости еще 10%
Далее...
избавляемся от одинаковых левых заказов ради откатов...
типа... печенье бантики 1КГ белый бизон
и печенье бантики 1КГ Зеленый бизон... :) это работа с манагерами...
ну это я не смогу оценить процентно.. но помагает точно...
короче на половину административно точно можно... а остальное... ну это торговля... иногда разумный пересорт полезен...ИМХО хотя сам его не перевариваю...
18.03.2009 00:17
Цитата:
Mtirt Что ты понимаешь под положительным результатом?
Абсолютного нуля всё равно не достичь.
Второй закон термодинамики тоже не нарушить.
Положиетельный - это результат, который Вас удовлетворил.
23.03.2009 11:00
Цитата:
Mtirt Единственный действенный метод борьбы с пересортом: полный инструментальный контроль движения товара. Т.е. терминал сбора данных или сканер штрих-кодов...
И бейсбольная бита, для тех кто долбит руками, не используя сканера и ТСД,
23.03.2009 11:20
Да конечно есть положительный результат но только через определенный геморой для магазинов..
Чтобы автозаказ в офисе создавался на основе относительно правильных остатков магазинов, у нас было принято решение воздействовать на магазины не организационно(мотивация, демотивация) а технически...

Ввели новую дополнительную характеристику для места хранения:
VL_PERESORT Контроль отрицательного остатка

Код:
SELECT * from SUPERMAG.SASTOREPROPDEF
Код:
ID	NAME	DATATYPE	LIMITCHOICE	PRESET	STATUS
VL_TYPE_PROGRAMM	Вид учетной системы	0	1	0	1
VL_LOCKIL	Блокировать Инвентаризационные Описи	0	1	0	1
VL_PERESORT	Контроль отрицательного остатка	1	0	0	1
После этого проставили для всех месх хранения разное число в эту характеристику по принципу
-1 : контроль отрицательного остатка отсутствует
0....9999999: столько артикулов могут быть в отрицательном остатке
(то есть не количество остатка по одному артикулу, а именно количество артикулов, то есть товаров)

Потом написал триггер такой и создал его в каждой базе данных(в магазинах)
Код:
create or replace trigger SUPERMAG.SMDOCUMENTS_PERESORT
before insert or update	of DocState
ON SUPERMAG.SMDOCUMENTS
for each row 
when (new.DocType = 'WI')
declare
	CountGoods NUMBER(10);  -- количество отрицательных артикулов(остатков)
  ExceptEnabled NUMBER(10); --разрешен контроль отрицательного остатка
  FirstChangeStatus NUMBER(10); -- первая смена статуса - разрешен контроль
  DayofNow NUMBER(10);  -- текущий день недели
begin

 SELECT MOD(TO_NUMBER(TO_CHAR(SYSDATE,'J')),7)+1 INTO DayofNow FROM DUAL;

--если это не суббота и воскресенье тогда работаем дальше иначе НАХ
 if NVL(DayofNow,1) in (6,7)
 then return;
 end if;

--если текущая дата праздник тогда тоже НАХ
 if to_char(SYSDATE,'DDMM') in ('0101','0201','0301','0401','0501','0701','2302','0803','0105','0905','1206','0411')
 then return;
 end if;

  
--если это не поднятие статуса до принят на складе тогда нафик
 if NVL(:new.DocState,0) <> 2 and NVL(:old.DocState,0) <> 1
 then return;
 end if;

--если документ не сегодняшним числом  тогда нафик
 if TRUNC(:old.CreateDat) <> TRUNC(SYSDATE)
 then return;
 end if;

 SELECT nvl(count(*),0) INTO FirstChangeStatus
 FROM SUPERMAG.SMDOCLOG L
 WHERE L.OLDSTATE=1 AND L.NEWSTATE=2
 AND L.DOCTYPE='WI' AND L.ID=:old.ID;
 
--если это не первая смена статуса документа то есть он пришел на корректировку то выход
 if FirstChangeStatus>0
 then return;
 end if;
 
--если это не операция прихода тогда невыполняю триггер
 if NVL(:new.OpCode,-1)<>0 or NVL(:old.OpCode,-1)<>0
 then return;
 end if;
 
--если  VL_PERESORT не существует тогда нафик
 BEGIN
         SELECT PROPVAL into ExceptEnabled 
         FROM SUPERMAG.SMSTOREPROPERTIES 
         WHERE PROPID='VL_PERESORT' AND STORELOC= :new.LocationTo;
 EXCEPTION
     WHEN NO_DATA_FOUND THEN Return;
 END;
 
--если  VL_PERESORT=-1 тогда нафик
 If ExceptEnabled = -1 
 then return;
 end if;
         
 If ExceptEnabled>-1 then
    SELECT COUNT(G.ARTICLE) into CountGoods
    FROM SUPERMAG.SMGOODS G,
         SUPERMAG.SACARDCLASS T,
         SUPERMAG.SMCARD C
    WHERE G.ARTICLE=C.ARTICLE 
          AND T.ID=C.IDCLASS 
          AND NOT T.TREE LIKE ('11.%') 
          AND NOT T.TREE LIKE ('27.%')
          AND G.QUANTITY<0 AND G.STORELOC= :new.LocationTo;
 End If;
 
 If (ExceptEnabled>-1) and (CountGoods>ExceptEnabled)  then
    RAISE_APPLICATION_ERROR(-20100, 'В Вашем магазине количество артикулов в отрицательных остатках '||CountGoods||'. Центральным Офисом разрешено не более '||ExceptEnabled||'. Принятие Приходной Накладной на склад запрещено. Срочно проводите инвентаризацию!!!'); 
 End If;
end;
Этот триггер просто не дает в магазине принять на склад приходную накладную, сегодняшнего числа, если сегодня не праздничный день и если Контроль Отрицательного остатка утановлен для данного магазина >-1, а отрицательный остаток по таблице SMGOODS превышает число артикулов установленное для данного магазина в дополнительной характеристике VL_PERESORT(Контроль отрицательного остатка).

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

Ну для примера сначала магазины сильно возмущались, но сейчас привыкли(1-2 месяца адаптации) и цифра VL_PERESORT у них в базах сползла для маленьких магазинов с 400 до 30, а в супермаркетах с 1400 до 100 артикулов..это 24 магазина...
Зато автозаказ в офисе стал более менее реальный..

ЗЫ: Отчет просто ложите в папку отчетов максимизатора и он появляется в списке ответов "Пересортица",
там 3 отчета в одном. Один показывает общее количество отрицательного остатка в магазине, второй по старшим группам, твретий по артикулам, что позволяет магазину быстро ориентироваться как оптимальнее сделать миниинвентаризацию..(по какой группе).

НО ЕСТЬ НЬЮАНС: Если убирать только отрицательные остатки. то содазтся одна ПН инвентаризация недостачи, и ежедневная такая миниинвентаризация через месяц когда начнется глобальная инвентаризация по всем группам товаров - выдаст такие бешенные минуса, то никакая естественка не поможет. Магазины это просекли и теперь если добавляют в опись тот товар который в минусе, добавляют и те товары которые в плюсе(не секрет что они знают что с чем сортится) и все вообщем то встает на свои места.
Вложения
Тип файла: rar !Пересортица_Отрицательныеостатки.rar (25.4 Кб, 134 просмотров)
23.03.2009 12:40
Угу, а в Пятерочке день нельзя закрыть, пока не избавишься от всех отрицательных остатков.
Только это порядка не прибавляет.
На второй месяц такой беготни народ перестает считать и начинает минуса закрывать от балды тем товаром, который пока есть на остатках.
Картинка получается в итоге "чистая", но так же далекая от действительности, как и та, которая с минусами.
23.03.2009 14:44
лет 6 назад, когда все только начиналось, первые магазины работали на программе Тендо: Товародвижение...
Там был реализован достаточно удобный механизм работы с пересортом...
что-то типа сличительной ведомости в СМе -
т.е. создавался документ - заполнялся отрицательными и соответствующими (по мнению оператора) положительными остатками
условно говоря "проводился" - и все остатки выравнивались...
всегда можно было посмотреть что и с чем пересортили...
Но позже, когда операторы освоились с этим... начались чудеса...
т.е. излишками перекрывался любой товар...
но тогда никому не нужна была такая развернутая аналитика как сейчас... корректные остатки по поставщику, и соответсвенно точная себестоимость...
И любая инвентаризация с большими отклонениями как в - так и в +
просто уводит нас от правильных цифр...
23.03.2009 15:17
Цитата:
Назым Положиетельный - это результат, который Вас удовлетворил.
в одной сети сработал такой ход: начали отслеживать процент продаж по неустановленной себестоимости. если процент был ниже установленного порога - МОЛ-бригада получала премию. вменяемым людям объяснили, откуда он берется. они начали дрессировать всех, от кого зависят пересорты (от приемщиков до кассиров). за два месяца процент упал на порядок. просто люди за свою денежку начали более внимательно отслеживать моменты, порождающие пересорты (в частности) и минуса (в целом).
Часовой пояс GMT +3, время: 07:13.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.