ТиС - заявка на склад - резервирование имеющегося при превышении остатка
 

Доброго времени суток!
В ТиС есть режим документа "Заявка покупателя" - "Заявка на склад" - в этом режиме производится резервирование товара из складского остатка. Но, если какого-либо товара недостаточно на остатке, то вся заявка не проводится с сообщением об ошибке о недостаточном количестве товара. Как считаете - если переделать алгоритм документа на резервирование из имеющегося остатка, то начнётся путаница, или-же это распространенная практика?
Пример, требуется 10 шт товар1, 10 шт товар2 и 10 шт товар3. На остатке имеется 10 шт товар1, 5шт товар2, 0шт товар3. Заявка проводится и ставит на резерв 10 шт товар1 и 5шт товар2.
Где в таком решении вопроса подводный камень?

А что мешает удалить строку из заявки с 0 остатком?

а подумать?

(2)так её не нужно удалять, тогда придётся вводить два документа "Заявка от покупателя" - один "Заявка на склад", второй "Заявка на поставку",в одном отражать количество товара которое есть на складе, во втором количество требующееся покупателю за минусом имеющегося на складе.

(3) это мне адресовано или-же (2)?

тебе

нужно переделать "Заявка на поставку"

(7) да, верно, спасибо - в варианте "Заявка на поставку" резервирует из остатка и проводится.

1. Изучить типовой функционал ТИС.
в заявке покупателя есть НЕСКОЛЬКО режимов резервирования - а именно 4 стратегии. Одна из них - РЕЗЕРВИРОВАТЬ ТОЛЬКО ПО ОСТАТКАМ.
.
НО! имея "заявку покупателя" на 40 строк - и иметь по ней резерв всего по 20 строкам - да и то не в полном количестве по строке - весьма непрозрачно для 99% тупых офисных обезъян.
.
неоднократно реализуя управление заявками - самый жизненный вариант следующий:
- овормляется НЕПОДТВЕРЖДЕННАЯ ЗАЯВКА.
- из нее ЗАЯВКА НА СКЛАД +
- заявка покупателя (с нужной стратегийей) по тому, что сейчас нет на складе.
.
в принципе, будет работать и штатная ситуевина всего с одной заявокй покупателя - но требуется жОсткое управление процессом оформления, поступлеяни, остлеживания состояняни за явки и отгрузок по ней.
.
еще раз? для 99% тупых офисных обезъян это а) либо неподьемно б) либо исклюбчительно и только работа программера.
.
как пример - смотри на Исе у меня "расширенный монитор заявок"

(9) спасибо за информативный пост! отличная пища для ума!

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

в типовой тис очень плохо то, что штатаная система корректировочных заявок не позволяет ЛЕГКО и УДОБНО идентифицировать заявку/сделку
.
у меня вообще мысль документ ЗАЯВКА разделить нахер - заявка клиента - докуимент с голой ШАПКОЙ, без ТЧ - там указываем ИДданные ЗАЯВКИ КЛИЕНТА, а состав заявки - отдельные документы (цепочка корректировок), состоящие из ТЧ + ссылка на докоснование = ИДзаявки.

вброс прошел удачно, заявки покупателей в тисе в типовом функционале ето нечто
(0) предлагаю тему еще исходя из отчета график платежей

(13) работет ок, нго только очень строго надо все. вдобавок есть РАЗРЫВ - когда система заявки-заказы и правится какте-то одно плечо - второе - в молчании.. если заявок-заказов много - полный тупняк..

14-Чучундер >корректировочки долга повводи - поговорим

15-Одинэсник >ето я к продолджению ( а по поводу заявок оке оке втоятеория нормально катит когда менегеры оклад получают и не имеют процентов

корректировочки долга по вопросу о заявках - к чему..7 а вот то. что корректировочка долга корректирует только долги по товарам - это да..

все ответы - чушь. чучундерная...

(11), (12) спасибо за идею! если вдруг что-то подобное реализую - обязательно отчитаюсь

(18) застрелись, сабака бешеная