ут11, ЗаказКлиента обеспечивать обособленно. Зачем еще "Отгружать обособленно"? #767100

Вот есть заказ клиента. В нем поставили "Обеспечить обособленно". Зачем сделано, что после поступления под этот заказ от поставщика товара, нужно снова его открыть и нажать "Отгрузить обособленно"? Иначе нельзя завести Реализацию. Но зачем так сделано - есть заказ клиента, есть пришедший товар на складе под этот заказ. Почему нельзя без этих танцев создать отгрузку? Или я чего то не понимаю?

может надо целиком заказ отгрузить? Зачем машину гонять несколько раз?

Мои мысли по этому поводу. В УТ 11 и проч.(КА 2.0, ERP 2, ...) реализуют идею заказов на "общий котел". То есть, чтобы уменьшить количество зарезервированного товара на складе, и черпать оттуда по мере общего поступления товаров. Но оставили возможность резервировать товар под конкретную хотелку(обособленно), как в предыдущей версии. Так вот, "Обеспечение обособлено" требует все последующие действия тоже делать "обособлено"

мой мелкий опыт показывает что клиенты/менеджеры предпочитают работать строго позаказно, а не из "общего котла" 9хотя и такое было в моей практике). То есть клиент прислал заках. его отгрузили частично. Проще/прозрачнее - далее работать с новым заказом от клиента - который выставляет в этом новом заказе нужный ему товар. Если делать большой один заказ и грузить его по мере поступления товара/оплат - рано или поздно клиентура и манагеры начинают путаться. - здесь ваен удобный инструмент, позволяющий быстро и красиво получать нужные данные. у 1С с этим обычно пролблемы. имхо

Я когда писал мыслю, подумал, что ты должен на это, наверняка, среагировать. Разовью свою мыслю. Дело в том, что некоторые менеджеры, в угоду только своим интересам, резервируют для себя товары, пока не накопится полный пакет, например, из 10 позиций. А эти 10 позиций могут копиться довольно приличное время. А товар за это время мог бы продаться и поступить не один раз. Получается, "замораживание" оборотных средств. Вот отсюда идея общего котла, которая позволяет уменьшить количество существующего, но "недоступного" товара. А инструмент для резервирования подделали. И возможность резервирования осталась, но это уже "обособленность"

боюсь не понял (понял неправильно) идею общего котла "Вот отсюда идея общего котла, которая позволяет уменьшить количество существующего, но "недоступного" товара." - можешь дать ликбез/пояснения более подробно? спсб.

вариант длительного резервирования - да есть такое. имхается да с этим надо бороться. как - надо думать, варианты есть

Извените, что встреваю, а есть ли опыт, как наименьшими изменениями исправить эту вещь, что бы не нужно было лишний раз нажимать "Отгрузить обособлено", и было достаточно статуса "Обеспечить обособлено", при условии, что весь товар под обеспечение уже пришел на склад?

Кто бы мне ликбез устроил? Я думаю, что проблема излишней "зарезервированности" товаров на складах существует. Причины этого явления, мне кажется, понятны. Это желание менеджера заработать, не взирая на то, чего это будет стоить фирме. Так вот, сейчас, например, можно сделать так, чтобы обособленно резервировать можно было только с определенного разрешения, например, какого-либо руководителя. То есть, надо будет обосновывать причину такого долгого резервирования определенного количества товара. Все остальным придется ждать поступления. И за время резерва этот товар вполне может поступить. Тогда зачем ждать, пока он придет? Нужно продавать, что есть на складе. Или, например, регулировать это дело минимально необходимыми запасами. Это мы тут встряли. Мне сдается, что если ты зарезервировал, то будь добр, именно этот зарезервированный товар довести до потребителя. Или отвяжи обособленность, чтобы товар оказался в общем котле. Это, по моему, механизм "обособления" и преследует.

Механизм "длительного резервирования" можно побарывать(как говорит мой сын), например, периодической обработкой/запросом по резервам и снятием с резерва, например, руководителем или еще кем. А то зарезервируют и забывают, что там что-то лежит недоступно.

ну так это типовая задача, я давно уже написал (да и не я один стопудово... недавно, кстати, купили экземпляр ;-)

а как "резервировать необособленно"...? и что это такое?

У меня не длительное резервирование. И заказы по паре строк в документе, и по большей части сразу заказываются у поставщика. Без наличия остатка, поставить статус "Отгрузить обособлено" нельзя - приходится "Обеспечивать обособлено". Товары под заказ пришли, но отгрузка на основании не создается, пока не поставишь "Отгрузить обособлено". Клиенту не нравится это лишнее нажатие.

Ты, я вижу, всерьез решился сбегать с 7.7))) УТ 11.1(или КА 2.0, ERP 2.0) под рукой имеется? Там, вроде, механизм по умолчанию "необособленно".

сколько же кактусов мы в январе сожрали с этим "обособленно"... ад, треш и угар. А у нас еще и торговля с колёс имеет место быть...

Клиент - это кто? Покупатель товара или контора, где внедряется УТ 11(должно быть не ниже УТ 11.1)?

контора, где внедряется УТ11 (мой клиент).

Так оно и есть. 1С клепает коробки, остальные тестят

вроде как мелкомягкие за тестирование тестовых релизов выдают бесплатные лицензии. В 1С бы такое...

не, ну там в теории то красиво все расписано. Когда торговля идет "сегодня пришло, после-после-завтра отгрузим", а продаж не очень много - оно даже работает. Но вот "Корректировка назначения", которая хрен пойми как снимает резервы, или замкнутые круги, когда уже поступило под этот заказ клиента, потом резерв сняли, потом попробовали отдать под другой заказ... нафиг

+ Вернее, если на складе есть товар, то свободный остаток предлагается просто зарезервировать, а недостающий "обособленно" можно резервировать. То есть, захватит первый же заказ на поставку.

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

хм.. ну так такая же схема в ТиС... - что нового-то?

В таком случае, вам, наверное, уже пора браться за написание четкого регламента. Это многие проблемы должно снять.

Я не думаю, что ДАЖЕ в УТ11 схема резервирования что-то сильно заумное...

Ну, не знаю я ТиС, хотя переводил с него на УТ 11. И тогда в УТ 11 еще не было таких наворотов(но ечень и очень сырая была). Может быть, решили от хорошего наработанного не отходить.

нет, захватит заказ на поставку ПОД НЕГО

Ну да.

Вопрос то не в том что обособленно или нет, а том что сначала нужно установить статус строки "Обеспечивать обособленно", а потом статус "Отгрузить обособленно". Можно и не обособленно: сначала "Обеспечивать", потом "Отгрузить" Непонятно зачем менять статус строк ДВА раза? Сейчас разбираюсь с похожей ситуацией в ЕРП

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

пока (как ламер тупой не читавший книжек) так и не понял что такое "обособленно"

в ут тоже самое + обособленное поступление

в УТ/КА/ERP в поступлении тоже есть "Назначение" (справочник, внезапно). Можно, если отвязать строку от заказа поставщику, удалить привязку к заказу покупателя

читай "под заказ"

нет, если обеспечение необособленное, то "Назначение" в заказе поставщику просто пустое, т.к. сам заказ не создает элемента справочника "Назначения"

ТОЛЬКО под ЭТОТ заказ клиента и никак по другому.

Наверное, не всегда правильно. А вдруг нужно, чтобы пришедший товар никто не мог забрать под другой заказ?

а как может быть по-другому?

Я так понимаю "обособленно", это под конкретный заказ.

Приход (на отдельный склад) - резервирование (если успели). или Заказ под клиента - под него заказПоставщику-По ему Приход - ляжет строго под заказ клиента

"только" означает, что его вообще потом никуда не пристроишь. Без корректировки назначения (в элементе справочника заменяется ссылка на заказ) этот товар нельзя реализовать вообще под другие заказы.

вот второй вариант у тебя - это и есть обособленное обеспечение

+ 1 к 1

а как можно резервировать еще, если не под заказ клиента? или речь о том, что если какой2-то приход в котором не указано что он конкретно под данный заказ клиента - то не ляжет на этот заказ клиента?

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

Резервирование - это и есть обособленное обеспечение. Зачем придумали новое слово, это вопрос

тьфу. совсем запутался. может кто-то нарисовать неспеша как идет работа с заказами клиентов, резервированием (по свободному остатку и под поставку от поставщика и как еще)...?

Не путай человека.

"и на остатках общего котла" - свободный остаток, который доступен к продаже и ни под кого не зарезервирован?

на ИС была оооочень неплохая и полная статья. "просто взять и нарисовать" не выйдет, к сожалению. Там даже разные ресурсы регистра "Свободные остатки" используются

Да, именно, так. в демке поработай. Там будет понятно.

не а. если обеспечение обособленное, то под этот заказ нельзя взять из общего котла, если есть заказ поставщику

+вернее, зарезервирован, но не под конкретный заказ(не обособленно)

Именно так: В терминах УТ 11: резервировать - это резервировать на складе. А обособленно обеспечивать - это резервировать в заказах поставщику и тд

ага, так конечно понятнее. все согласны с таким определением?

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

Именно так

Но после того как товар придет в заказе нужно поменять с обеспечивать на отгрузить, что дает нам вопрос из

Можно ли заявку покупателя (в один клик) обработать по одному из любых вариантов: 1. взять только из свободного остатка, все что не хватило нафиг (отказ) 2. все поставить в "требование" обеспечить поставкой 3. что есть - взять из свободного остатка, остальное - поставить в "требование" обеспечить поставкой 4. если есть ожидаемые поставки - все что из них еще не расписано на какие-то заявки - поставить под эту заявку клиента, остальное - взять со свободного остатка на складе . ?

херня полная.

в чем смысл такого действия...?

почти все можно из описанного тобой ОбособленноеОбеспечениеЗаказовКлиентовВЗаказахПоставщикамИмениБорисаНуралиева

в целом, в правильно. Только там можно еще и обеспечивать необособленно - типа кто первый хапнет из поступления, тот и молодец

"обеспечивать необособленно" - ну это тупо кинуть на склад в свободный остаток..?

да. просто дает понять закупке, что этот товар вроде как надо купить под этот заказ клиента... Но *не только* под него :)

херня какая-то.. нагородили сущностей, шо пипец

"дает понять закупке, что этот товар вроде как надо купить под этот заказ клиента... Но *не только* под него" - то есть часть закупа пойдет в резерв под заявку клиента, остальное - в свободный остаток..?

там понятие "обособленно" еще нужно для расчета себестоимости - под этот заказ взять из этой поставки, потому что в этой поставке будет цена ниже, значит и заказ будет рентабелен.

напишу-ка я как в клюшках работает система резервирования. . Пришла заявка клиента. Возможные варианты: - можно оформить заявку с видом "ЗаявкаНеподтвержденная". По сути это просто фиксация хотелки клиента. Никаких обязательств мы на себя не берем, ничего клиенту не обещаем. - можно оформить заявку с видом "ЗаявкаНаСклад". Это чистое резервирование из текущего свободного остатка, имеющегося на данный момент. Все что отсутсвует на свободном остатке - из заявки д.б. убрано - иначе заявка тупо не проведется. - можно оформить заявку с видом "ЗаявкаНаПоставку". Это самый сложный вариант и в моей практике использовался редко - бо требует высокой дисциплины учета. При оформлении такой заявки можно выставить типа один из вариантов . Далее все от текущей ситуации зависит. Рассмотрим вариант "со склада, остальное - под поставку" Все что есть на свободном остатке - ставится в резерв. оставшаяся част заявки - смотрим есть ли ожидаемые заказы поставщикам (проверяется даты ожидаемых поставок с датами ожидаемой отгрузки в заявке покупателя), которые (заказы поставщикам) еще не распределены под заявки покупателей - если есть - пишем часть заявки покупателя под конкретные заказы поставщикам. Часть заявки покупателя остается по прежнему необеспеченной. Формируем заказ поставщику, где указываем ожидаемую дату поставки - смотрим все заявки со статусом "ЗаявкаНаПоставку", вычитаем резервы (которые уже на складе). вычитаем позиции которые уже закреплены под ожидаемыми ранее заказами поставщикам. оставшуюся часть - кладем в заказ поставщику. В итоге все описывается одной таблицей/регистром "ЗаказыЗаявки", где ЗаказПоставщику,ЗаявкаПокупателя,Номенклатура,Количество. Если приходит поставка и она введена на основании заказа поставщику - на склад падает РЕЗЕРВ под упомянутые в данном заказе поставщику заявки покупателей. Все остальное падает в свободный остаток (даже если есть заявки покупателей ждущие этот товар по другим заказам поставщика даже этому же самому поставщику). Если приходит поставка и она введена без упоминания заказа поставщику - все падает в свободный остаток (который расхватывают манагеры по принципу кто первый встал того и тапки). Здесь зачастую допиливалось(с вариациями) многими (практически штатный вопрос) - такие поставки (без упоминания заказа поставщику) - тупо сразу ставили резерв (погашая имевшиеся непогашенными заказы поставщикам по заявкам клиентов). При оформлении заказа поставщику его можно было заполнить "сводно" (тупо считаем необеспеченные заявки) - без упоминания заявок клиентов (тогда раскладка под конкретные заявки клиентов вычислялась и фиксировалась при проведении). а можно не сводно, а "конкретно по заявкам клиентов" - тогда каждая строка заказа поставщика указывалась с конкретной заявкой покупателя - это давало возможность рулить ПРИОРИТЕТАМИ в обеспечении заявок. какая строка с упоминанием заявки покупателя выше - та будет обеспечиваться первее. Вот примерно так (некоторые тонкости опущены/забыты) сделано в ТиС. надеюсь, кому-то пригодится.

Вариант исполнения заявки клиента "со склада, остальное - под поставку" - приводит к минимизации складского запаса, другие варианты из упомянутых - сами дотумкаете...

И что переходить на клюшки? )))

а документ изменение резервиновая не помагает ?

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

Полдня работы лет 10 назад мне сберёг. Бы. На ИС не хочешь положить, а то на 77 ещё немало народа работает?

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

не, можно сказать что клюшки умерли. Они мало кому интересны. А там где они есть - там и без меня специалистов хватает. Хотя вот надысь для казахстана программил Прикольно

статусы.. менеджер принимает решение об отгрузке.. и собственно, так ставится задание на отгрузку..

Тогда выставленное задание на отгрузку должно включать в себя "предыдущие" статусы. если я поставил "отгружать", это автоматом значит "обеспечивать"...

если поможет, то можно будет запускать обработку, которая и будет менять статусы