Заказы и Резервы в УТ11 (привязка и расшифровка заказов клиентов в заказах поставщикам и резервах на складах) + списание конкретных партий!
Ответы
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Занимательная статья! Прослеживается наличие свойств эмерджентности в УТ 11!! Вот в чем вопрос, а если характеристик много для конкретного товара и мало того его будут заказывать и, соответственно, он будет поступать от разных поставщиков, тогда характеристики разбухнут! Связка "Номенклатура-Характеристика.ИдентификаторКонкретныйЗаказКлиента" не рухнет ли? Есть мысль, что менеджер просто может потеряться во всем многообразии характеристик когда будет работать с клиентом! Или как?
(4) Stas-ch,
Автор пишет
Включив учет по характеристикам мы получаем эту самую уникальность.
Если компания работает по заказной системе, нам нужно в заказе клиента завести на товары уникальные характеристики (связанные с заказом и строкой товара в заказе). Это решает всю задачу от начала до конца.
Получив в заказе на товар уникальную характеристику, мы получаем уникальную запись в учетной системе, которая будет отслеживаться по всей цепочке!
1) Делая заказы поставщикам, заполнением по заказам покупателей с характеристиками, мы получаем в заказе привязку заказов клиентов с заказами поставщикам.
2) После поступления заказа поставщика с заполненными характеристиками (уникальной записью заказа клиента) мы получаем остатки резервов в разрезе этих записей. А вот это и есть наша связка. Отчет по остаткам нам будет показывать информацию по товарам и характеристикам - это и есть расшифровка наших резервов. Получив характеристику мы легко можем получить документ заказа клиента.
Это значит что мы конкретно видим чьи резерваы лежат на складе и готовы к отгрузке. И т.д.
//////////////
Если мы будет работать с одной номенклатурой, то каждый раз, для конкретного элемента справочника Номенклатуры, придется записывать новую характеристику, то есть заявленную уникальность "заказ клиента - заказ поставщику". Опять же, если я правильно понял идею. Если заказов на один и тот же товар много, то этих уникальностей должно быть соответствующее количество. Вот тут и вопрос - это не усложнит работу менеджеру по продажам, когда он при заполнении заказа должен будет еще и характеристику товара правильно указать?
Автор пишет
Включив учет по характеристикам мы получаем эту самую уникальность.
Если компания работает по заказной системе, нам нужно в заказе клиента завести на товары уникальные характеристики (связанные с заказом и строкой товара в заказе). Это решает всю задачу от начала до конца.
Получив в заказе на товар уникальную характеристику, мы получаем уникальную запись в учетной системе, которая будет отслеживаться по всей цепочке!
1) Делая заказы поставщикам, заполнением по заказам покупателей с характеристиками, мы получаем в заказе привязку заказов клиентов с заказами поставщикам.
2) После поступления заказа поставщика с заполненными характеристиками (уникальной записью заказа клиента) мы получаем остатки резервов в разрезе этих записей. А вот это и есть наша связка. Отчет по остаткам нам будет показывать информацию по товарам и характеристикам - это и есть расшифровка наших резервов. Получив характеристику мы легко можем получить документ заказа клиента.
Это значит что мы конкретно видим чьи резерваы лежат на складе и готовы к отгрузке. И т.д.
//////////////
Если мы будет работать с одной номенклатурой, то каждый раз, для конкретного элемента справочника Номенклатуры, придется записывать новую характеристику, то есть заявленную уникальность "заказ клиента - заказ поставщику". Опять же, если я правильно понял идею. Если заказов на один и тот же товар много, то этих уникальностей должно быть соответствующее количество. Вот тут и вопрос - это не усложнит работу менеджеру по продажам, когда он при заполнении заказа должен будет еще и характеристику товара правильно указать?
(5) DoctorRoza,
Насколько я понял задумку автора - менеджеру по продажам не придется вбивать характеристики - они будут создаваться автоматически при проведении документа Заказ клиента (через подписки на события). Да, характеристик будет много, справочник будет пухнуть как на дрожжах, но при грамотном их наименовании их вбивать будет легко. А вбивать их не придется - опять же, в идеале. В Заказе клиента они генерятся автоматически. Заказ поставщику можно создавать на основе Заказа клиента или через обработку. Поступление и реализация - на основе соответствующих Заказов.
А вот что есть в реалии - вот это интересно было бы узнать.
Например, в случае отказа клиента от заказа - как он будет продаваться? (В случае запрета в Заказе клиента товаров с чужим номером заказа).
Насколько я понял задумку автора - менеджеру по продажам не придется вбивать характеристики - они будут создаваться автоматически при проведении документа Заказ клиента (через подписки на события). Да, характеристик будет много, справочник будет пухнуть как на дрожжах, но при грамотном их наименовании их вбивать будет легко. А вбивать их не придется - опять же, в идеале. В Заказе клиента они генерятся автоматически. Заказ поставщику можно создавать на основе Заказа клиента или через обработку. Поступление и реализация - на основе соответствующих Заказов.
А вот что есть в реалии - вот это интересно было бы узнать.
Например, в случае отказа клиента от заказа - как он будет продаваться? (В случае запрета в Заказе клиента товаров с чужим номером заказа).
А еще не рассмотрен вопрос - что делать с товаром, который закуплен не под конкретный заказ клиента, а в общем, под все заказы, т.е. для поддержания минимального остатка.
Получается надо придумывать механизм, который позволит "переименовывать товар" - присваивать ему характеристики заказа, по которому он будет продан. Иначе система не позволит отгрузить товар с иными характеристиками, как в заказе клиента. или переименовывать товары в заказе, что тоже не есть выход.
интересно, как этот нюанс автор темы реализовал? Или в его случае все товары покупаются только под заказ? Мне кажется эта схема маловероятно, но могу и ошибаться.
Получается надо придумывать механизм, который позволит "переименовывать товар" - присваивать ему характеристики заказа, по которому он будет продан. Иначе система не позволит отгрузить товар с иными характеристиками, как в заказе клиента. или переименовывать товары в заказе, что тоже не есть выход.
интересно, как этот нюанс автор темы реализовал? Или в его случае все товары покупаются только под заказ? Мне кажется эта схема маловероятно, но могу и ошибаться.
Статья отличная!
Только вот для каждого предприятия необходима конкретная подстройка учета характеристик и конкретная доработка конфиги.
Примерно год уже пользуюсь примерно такой же схемой.
У меня учет характеристик для каждой номенклатуры по отдельности.
При создании номенклатуры, подпиской создаются две характеристики: "!без характеристики" и "!создать характеристику"
Во всех доках автоматом проставляется "!без характеристики"
При создании заказа (при определенных статусах) ставиться "!создать хар-ку" и при записи заказа создается новая характеристика, привязанная к заказу.
В других случаях выбрать "!создать хар-ку" невозможно.
У нас продажи и поступления только по заказам. Но если без заказа, то можно использовать "!без характеристики"
В особо редких случаях приходится изменять характеристику в приходах.
Контроля за продажей "чужой" характеристик нету.
Конфига с минимальными изменениями, всё на подписках, в отдельных модулях, документы изменены незначительно.
Только вот для каждого предприятия необходима конкретная подстройка учета характеристик и конкретная доработка конфиги.
Примерно год уже пользуюсь примерно такой же схемой.
У меня учет характеристик для каждой номенклатуры по отдельности.
При создании номенклатуры, подпиской создаются две характеристики: "!без характеристики" и "!создать характеристику"
Во всех доках автоматом проставляется "!без характеристики"
При создании заказа (при определенных статусах) ставиться "!создать хар-ку" и при записи заказа создается новая характеристика, привязанная к заказу.
В других случаях выбрать "!создать хар-ку" невозможно.
У нас продажи и поступления только по заказам. Но если без заказа, то можно использовать "!без характеристики"
В особо редких случаях приходится изменять характеристику в приходах.
Контроля за продажей "чужой" характеристик нету.
Конфига с минимальными изменениями, всё на подписках, в отдельных модулях, документы изменены незначительно.
Всё замечательно конечно, но вопрос к снятию резерва при необходимости остается - ведь получается, если некий резерв менеджер решит "перебросить" под другой заказ он удивится, когда увидит, что цен нет...
Ну например склад метизов с номенклатурной матрицой в 150000 эл. немного офигеет от счастья... ну и кочно непонятно, что делать там, где ведутся еще и РЕАЛЬНЫЕ хар-ки, размеры/цвета например...
это увеличивает объем хар-к в арифметической прогрессии...
Ну например склад метизов с номенклатурной матрицой в 150000 эл. немного офигеет от счастья... ну и кочно непонятно, что делать там, где ведутся еще и РЕАЛЬНЫЕ хар-ки, размеры/цвета например...
это увеличивает объем хар-к в арифметической прогрессии...
Вакансии
1С-Программист (интегратор Битрикс24)
Санкт-Петербург
зарплата от 150 000 руб. до 250 000 руб.
Полный день
Санкт-Петербург
зарплата от 150 000 руб. до 250 000 руб.
Полный день