Как правильней отразить подтверждение "заказа поставщику" в УТ 10.3? #562682

Добрый день, есть следующая задача: Делается "Заказ поставщику", и отправляется поставщику, поставщику корректирует Excel файл заказа - наличие номенклатуры на складе и присылает обратно откорректированный файл. Как этот файл лучше отразить в ИБ? как корректировку заказа поставщику или ввести доп. регистр? В итоге нужно получить информацию о "Заказе поставщику"

вверх

По-моему, как корректировку.

Конечно же корректировкой заказа поставщику, вводится на основании исходного заказа поставщику. Что бы получить результирующий заказ используй печатную форму "Заказ поставщику (с учетом корректировок)". Только с размещением не ошибись, в случае работы системы заявка - заказ, нужно очень осмотрительно относиться к содержимому "Размещение" этих документов.

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

Я в свое время делал динамическое определение статуса на основе содержимого РН - заказы покупателей и расчеты с контрагентами (соответственно отгрузка и оплата). На 25+ юзверях работала нормально, в плане скорости. Можно сделать наверное реквизитом заказа, или регистром сведений. Которые обновляются после проведения документа, влияющего на статус заказа (когда его делает пользователь), либо регламентной обработкой. Но нужно думать над производительностью.

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

По производительности всё равно нужно нагрузочное тестирование. Но у РС есть очень большой плюс - он пишется независимо от документа в БД. Особенно это актуально, если есть механизм запрета редактирования задним числом заказов (до определенного конечно уровня), и не хочется ломать этот механизм. А статусы всегда можно перечитывать с необходимым интервалом.

все очень просто. рабочее место могу показать статусов там нет правда. Добавил статусы в заказы. Неподтвержденный заказ отмечают статусом и док не проводят. Как только прошел этап согласования и закахз принят. ставят статус и прроводят документ чтобы он попадат в отчет с акутальными (в пути заказами). Все очень просто. Статусы нужны просто для удобства отборов в журнале. Чтобы видеть непроведенные заказы и они отличались в случае если что то есть непроведенное или отмененное.

Плюс убрал нафиг с заказов запрет редактирования. безсмысленная штука по заказам поставщикам 9контролировать нечего). если заказ принят и проведен (т.е. подтверждне) то его итак никто править не будет. А с неподтвержденными работают любым числом. Работаем без корректировок (ибо это убожество).

Либо можно проводить все документы, и по статусам фильтровать отчеты. выполненные заказы ставить запрет редактирования. все остальные могут менятся на любом этапе. Отчевате за все ограниченный состав людей, которым главное это удобство работы. Это не бухи и не операторы. У них справшивают почему с торговлей пипец. а не почему в базе они что то не могут сделать ибо там фигово работать.

Ну да, Маня порадовал.

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

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

+ большая часть работы будет делаться через загрузки выгрузки Excel

в реальном времени. т.е. если несогласованный заказ отличается от поставщика. то его просто делают отметку. А загружают заказ поставщика и проводят именно его. а старый остается в программе. но непроведет.

этой херни я написался в свое время, где-то с 2004 года - монитор заявок на фармации крутится... да и сейчас работает в разных конторах разные виды "мониторов" - по резервам, по заявкам, в основном относительно ненавороченные мониоры - для любого юзверя... Навороченные мониторы - для отдельно выделенных пользователей нуджны. например сейчас у меня менеджеры в основном работают с монитором заявок (замена журналу штатному) и склад тот вообще 99% времени - складской монитор...

мы так и работаем. ща покажу это из загрузки счета.

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

У нас порядка пяти поставщиков. как правило наши заказы на треть могут несовпадать. А номенклатуры 30000. Закуп идет на пополнения склада месячным объеом. Как думаешь сколько закуп будет сидеть дрочить корректировку? а потом сидеть и сравнивать чо изменилось или нет, будет по дереву документы склеивать??? Им проще видеть актуальный документ.

- 22 поставщика, номенклатура - около 35 тысяч позиций... - задача уменьшить время обработки заказов и исключить ошибки людей, например, по выбору некорректной цены

это ты берешь упрощенную систему. В реаль ности путь многоступенчатый: клиент присылает заявку, заявка распиливается на несколько поставщиков - поставщикам скидываются ПРЕДВАРИТЕЛЬНЫЕ ЗАКАЗЫ. - поставщики их ставят в ВРЕМЕННЫЙ РЕЗЕРВ. Если временные резерв не подтвержден нами к исходу 3 суток - он может быть снят поставщиком. Также в общем случае ВРЕМЕННЫЙ РЕЗЕРВ у поставщика может по желанию поставщика - "корректироваться"... мне - надо видеть реальное сосотояни е  сколько товара у меня стоит во временном резерве у поставшщика, сколько в заказе поставщику (временные резервы переводятся потом в постоянный заказ поставщику). . непонятна идея у тебя - непроведенного документа..?

как я понял проведения только последнего документа, остальные потом убиваются

нахрена им что-то склеивать по дереву документов? актуальное состояние - это или последний документ, или отчет по регистру.. ..?

добро пожаловать!! оптовым покупателям скидки!

Очень странно ломать копья, сравнивая бизнес-процессы РАЗНЫХ контор :)

+ ясен пень у меня это все на 7.7

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

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

ну да вижу, но не совсем понимаю как обработка у него работает + требование основных пользователи - формирование заказов в автоматическом режиме в определенное время с этим тоже проблем не возникает)

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

Когда у "преимущественных" поставщиков нет достаточно товара?

Либо условия поставки по срокам(другим параметрам) не подходят?

написать ГРАМОТНЫЙ УДОБНЫЙ "монитор" для отслеживания состояния заявок/заказов - на 2-3 дня усидчивой работы. вся инфа тащится из регистров/статусов... / просто надо сидеть и пилить такой "монитор", чтобы им было удобно юзаться в конкретной конторе - скольо это займет - хз. Может маньяковские разработки подойдут, а может свое писать придется или дотачивать... / я вон на терминальную обработку для сканера - 20 часов потратил, 2000 строк кода. Зато заработала сразу и без глюков практически. Правда перед этим я лично на всех участках долго вертелся и работы делал, чтобы понять что и как и где..

по иерархии цен выбираетс яследующий поставщик. Опыт по крайней мере в фармации у меня - те количества которые декларируют в прайсах поставщики - к жизни имеют отдаленное отношение.

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

спасибо большой за подсказки

Ну да, я о том же. Универсальных схем нет. Любой механизм придется допиливать, особенно если контора большая и экономия времени операторов дорого стоит :)

> 20 часов потратил, 2000 строк кода не все могут =)

Спасибо за информацию, сорри но наверно не явлюсь покупателем Ваших разработок)

тут вдобавок как раз и получается: во временный резерв поставили 100 штук, через 2 часа пришел ответ от поставщика - даем 80, скорректировали на 80, 20 - отправили следующему поставщику... и так по кругу... . когда закупы делаются на пополнение склада - это фигня. А когда на заявку покупателя рамером в 300 строк надо дать ответ через пару часов - за это время надо распихать по куче поставщиков, получить от нихз ответы, скорректировать - распихать по другим поставщикам и это все крутится ПОСТОЯННО - тут начинаются тонкости вплоть до тривиального УДОБСТВА интерфейса...

так вроде в УТ есть какое-то рабочее место менеджера штатно?

а вы хотели что нить зашиьительское даром то есть безвозмездно...? ждите когда появится в типовых конфигах...

Оно плохонькое совсем :(

нет, я хотел идею примерную. у меня есть какой какие свои прикидки, но посоветоваться с больше опытными людьми важно для итогового решения

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

ни о чем ваще))

это будет, как в БП 3.0 хочешь - заплати за апгрейд =)

УТ 10.3, там уже ничего не появится))

сидишь в конторе, тщательно собираеншь "производственный процесс", МНОГО ДУМАЕШЬ. МНОГО ДУМАЕШЬ. потом за пару дней делаешь СВОЙ ЧАСТНЫЙ ПРОДУКТ. . совет могу дать тебе только один: эффективно рулят только ускоспециализированные решения.

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

> тщательно собираеншь "производственный процесс" мне рассказывали про такие конторы : они вообще документооборот не озвучивали, ибо тайна человек работал по "наитию" в итоге : автоматизировал =)

давно пора. . вот нахрена мне в УТ например система заказов поставщикам если ОНА МНЕ НЕ НУЖНА. вот и беру "решение" УТ без него.. понадобятся заказы поставщикам - докупаю БЛОК "заказы поставщикам" - который должен становится в типовую конфигу. . идея простая: продавать изделие из минимального набора кубиков. нужные кубики потом ддокупать. . почему это не сделано в 1Ске - хз. видимо не могут сделать автономные встраиваемы кубики, видимо будут высоки накладные расходы на связь кубиков.. ни один коредуба не потянет.. . Подсистемы в 8.2 - для этого...?

несогласен с тобой : система должна быть в принципе одна "универсальной" =)

просто с большой настройкой - надо ключил ,не надо отключил..

ну не  все так гладко, конечно же есть проблемы всякие. но они в основном лежат в области адекватной оценки разрабатываемого решения. зачастую просто невыгодно скажем упрощенно платить мне лимон за частное решение - проще нанять 2-3 обезъяны менеджера которые занимаются всем этим вручну. со всеми косяками и прочей хренью.. . я тебе nmfr скажу. по фармацим моя ТРИВИАЛЬНАЯ Ссистема расчета конкурентноспособных цена (там где-то 2-3 критерия) - в 95% случаев считала правильнее чем манагеры. . задача как раз в том, чтобы высвободить эти самые 95% тупой работы, а оставшиеся 5% - отдать н аоткуп РУЧНОГО анализа/работы.

ключил = включил

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

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

при этом пользователь такого кастомизированного до простоы продукта вправе ожидать что добавка маленького простого функционала к ЕГО простой системе  не должна стоить бешеных бабок.. ;-)

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

какие проблемы соединить ут/бп/зуп ?

в 8.2 есть понятие, как "Функциональны опции"

соединили - получилась КА..и как ее успехи?

хруйня

ставить то, что еле-еле развивается - тупиковое решение

она стоит копейки. а ты хоч по кубикам разибть?))) лол. представляю себе прайс з подсистема заказов - 2999 рублей 99 копееек. Оно чтобы её спец встроил еще 30 000 заплати.

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

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