Закупка, снятие резервов

[Sancho]

в одной компании такая простенькая бизнес задача:
если товар долго не продается дать в бубен тому, кто захотел его купить.

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

что делать и как найти кто виноват?

варианты решения, которые вижу я:
1. запретить снимать резервы, разве только модным перцам.
2. создать альтернативную резервейшн ентри, чтобы находить хвосты источников закупок

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

поможите, люди умные

[Lrundom]

на предыдущем месте работы с этим у нас было все очень просто. все можно было отследить по 337 таблице, т.е запись о том, что был сделан резерв не удалялась, а при отмене резерва в той же 337 табл. создавалась запись с типом(дай бог мне памяти) "Отмена/изменение резерва"(ну или что-то в этом роде). Так же в этой таблице были соответствующие поля типа "Дата отмены резерва", "Кем отменен резерв".. ну мож еще какие то, не помню уже.. НО суть в том, что можно было с легкостью отследить кто и когда, какой товар, из и для какого документа зарезервировал, отменил резерв..и на основании этих данных можно было с чистой совестью погрозить ему пальчиком

[apanko]

Цитата:

Сообщение от Sancho

у нас же есть резервы, которые переползают с заявки прямо в заказ!
а в них как раз сохраняется фамилия злодея.
но.
резервы ж можно снять, а по табличке 405 найти удаленный резерв очень даже непросто...

Любопытства ради: откуда резерв берется?

[Sancho]

Цитата:

Сообщение от Lrundom

на предыдущем месте работы с этим у нас было все очень просто. все можно было отследить по 337 таблице, т.е запись о том, что был сделан резерв не удалялась, а при отмене резерва в той же 337 табл. создавалась запись с типом(дай бог мне памяти) "Отмена/изменение резерва"(ну или что-то в этом роде). Так же в этой таблице были соответствующие поля типа "Дата отмены резерва", "Кем отменен резерв".. ну мож еще какие то, не помню уже.. НО суть в том, что можно было с легкостью отследить кто и когда, какой товар, из и для какого документа зарезервировал, отменил резерв..и на основании этих данных можно было с чистой совестью погрозить ему пальчиком

хм, круто, а это стандартный функционал или доработанный напильником? если доработанный, то доработка интересна... данный проект на 3.70

Цитата:

Сообщение от apanko

Любопытства ради: откуда резерв берется?

это просто. создали кнопу, на которую пользователь нажимает, когда товара нет: "Создать заявки на Закупку на недостающий товар". Она и казявки создает и резервирует автоматически под Заказ Продажи, например.

[Lrundom]

Цитата:

Сообщение от Sancho

хм, круто, а это стандартный функционал или доработанный напильником? если доработанный, то доработка интересна... данный проект на 3.70

скорее всего доработка. потому как система была ну очень круто доработана... много было того, что стало стандартом в более поздних версиях. А Навик был 2.6.

[apanko]

Вот такая мысль пришла (в порядке обсуждения).

Подключить к товару трассировку по лоту (только покупки).
Создавать заявки с номерами лотов.
В заказы покупки они переносятся и в книге операций тоже останутся. На применение это все не повлияет.
Если кто-то резирвирование и снял, то учтенная операция все равно им помечена.

Единственная проблема - массовое снятие резервов и последующая продажа - тогда применение пойдет по ФИФО и тогда, кому-то повезет (его косячная закупка уйдет), а кому-то нет.

[Sancho]

спасибо, Андрей, подумаю...
т.е. в строке "трассировки по лотам" будет код пользователя, он и есть злодей.
если вести лоты и резервирование, они друг друга не убьют?

[apanko]

Цитата:

Сообщение от Sancho

спасибо, Андрей, подумаю...
т.е. в строке "трассировки по лотам" будет код пользователя, он и есть злодей.
если вести лоты и резервирование, они друг друга не убьют?

И трассировка и резервирование сидят в одной таблице. Разница там в поле тип (или как оно). У резервирования статус выше, у трассировки ниже.
Т.е. создается строка типа Резервирование, а в поле Лот Но указывается фамилия. Если же резервирование снимается, то запись остается, у нее просто понижается тип на Трассировка.

[RedFox]

Цитата:

Сообщение от apanko

И трассировка и резервирование сидят в одной таблице. Разница там в поле тип (или как оно). У резервирования статус выше, у трассировки ниже.

Или я не понял глубины высказывания или немного не так.
В 337 мы можем иметь запись c типом Reservation для операций резервирования (в том числе если у нас есть ЛОТ) и Prospect для Item Tracking только без резервирования.
Например, если мы создаем резервирование с товаром ЛОТ1 (Item Tracking по лотам), то мы должны создать (и система создает) 2 записи c типом Reservation и заполненным полем "Lot No.".
Однако, если мы просто работаем с Item Tracking по лотам, то система создаст записи с c типом Prospect и заполненным полем "Lot No."
Так что по моему статус выше-ниже тут не причем.

Цитата:

Т.е. создается строка типа Резервирование, а в поле Лот Но указывается фамилия. Если же резервирование снимается, то запись остается, у нее просто понижается тип на Трассировка.

Таким образом если в поле "Lot No." указывается фамилия, то это значение должно присутствовать в таблице 6505 "Lot No. Information" (или развязать поле) = ЛОТ Фамилия. И при этом нужно понимать, что про Item Tracking по лотам можно забыть.
Не проще ли добавить таблицчку или поле и заполнять его? Или вообще модернизировать Измерения?