Добрый день!
Ситуация такая - есть магазин, продажи есть как организациям, так и розничным покупателям. Пожелания покупателя формируются документом "неподтвержденная заявка", на основе которой в дальнейшем заводится "реализация". Проблема в том, что в справочнике контрагентов есть позиция "розничный покупатель", и все заявки делаются на этого контрагента. В дальнейшем при создании реализации вылазит следущее - допустим есть заказ №1, в котором товары А, Б и В, и заказ №2 с товарами А, Г и Д. Сначала делаем реализацию на заказ №1, все нормально, затем делаем реализацию на заказ №2 и в реализации не видим товара А, который якобы уже был отдан розничному покупателю. Если менеджер заводит заявку покупателя как документ "Заявка от покупателя", такого не происходит, но это неудобно, т.к. этот документ ставит товары в резерв. Вопрос к знатокам - можно ли это как-нибудь обойти? Заранее спасибо!
Ситуация такая - есть магазин, продажи есть как организациям, так и розничным покупателям. Пожелания покупателя формируются документом "неподтвержденная заявка", на основе которой в дальнейшем заводится "реализация". Проблема в том, что в справочнике контрагентов есть позиция "розничный покупатель", и все заявки делаются на этого контрагента. В дальнейшем при создании реализации вылазит следущее - допустим есть заказ №1, в котором товары А, Б и В, и заказ №2 с товарами А, Г и Д. Сначала делаем реализацию на заказ №1, все нормально, затем делаем реализацию на заказ №2 и в реализации не видим товара А, который якобы уже был отдан розничному покупателю. Если менеджер заводит заявку покупателя как документ "Заявка от покупателя", такого не происходит, но это неудобно, т.к. этот документ ставит товары в резерв. Вопрос к знатокам - можно ли это как-нибудь обойти? Заранее спасибо!
По теме из базы знаний
- Акт передачи прав и лицензионный договор для ТиС 7.7
- Правила обмена и обработка выгрузки из ТиС, в БП 3.0
- Правила выгрузки из Торговля и Склад 9.2 в Управление Торговлей 11.2
- Обработка обслуживания ККТ АТОЛ, платформа 5.0 с драйверами v10 для 1С:Торговля и Склад 9.2 (МАРКИРОВКА, ФФД 1.2, эквайринг Сбер)
- Обработка печати чеков для кассы Штрих Онлайн (1С 7.7 Торговля и Склад)
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) zakhar111, если не трудно, на цифрах поясните. Допустим есть заказ №1, в котором товары А, Б и В, и заказ №2 с товарами А, Г и Д. В заказе №1 товара А 3шт., в заказе №2 товара А 2шт.
Сначала делаем реализацию на заказ №1.
Сколько в этой реализации штук товара А ?
Как формируется Реализация, вводом на основании заявки или непосредственным вводом документа, выбором покупателя и заполнением по кнопке Заполнить ?
Сначала делаем реализацию на заказ №1.
Сколько в этой реализации штук товара А ?
Как формируется Реализация, вводом на основании заявки или непосредственным вводом документа, выбором покупателя и заполнением по кнопке Заполнить ?
Добрый день. Я бы не мучился, а делал вместо счета непроведенную реализацию. А дальше либо проводил ее на розничного, либо выбирал конкретного покупателя. Если нужна печатная форма счета, то добавить ее как внешнюю к реализации.
реализацию делают на основании неподтвержденной заявки. если попробовать заполнить по новой, то все равно товара А нет. в неподтвержденных заявках кол-во не отслеживается, оно отслеживается только в документе "заявка от покупателя"
Вот блин интересный вопрос: как не резервировать товар, но при этом сделать так, чтобы тоара хватило. Решение - есть! Закупайте товара всегда с запасом.
.
Неподтвержденка служит для фиксации "неоформившихся" хотелок клиентов. Типа я там може к вам завтра забегу и куплю то что мне нужно. а если товар ане будет тои фиг с ним - забегу потом через недельку. если же хотелка клиента ОФОРМИЛАСЬ ЧЕТКО и вы болеете за то, чтобы УДОВЛЕТВОРИТЬ ДЕЙСТВИТЕЛЬНОЕ пожелание клиента - то товар придется РЕЗЕРВИРОВАТЬ.
.
следующее - если вы хотите избежать ситуации когда товар зарезервирован, а покупатель не пришел - и получилось так что ни ему не продали, ни другому который вот сегодня был но товар-то зарезервирован... - то СЛЕДУЕТ ПРИНЯТЬ ДЛОЯ СЕБЯ СТРАТЕГИЮ ТОРГОВЛИ. Если вариант: конкуретные продажи покупателям - про принципу "кто первый встал того и тапки" - то все оформляем заявками на склад, у всех проджавцов ставим ШТАТНУЮ галочку "разрешить продавать чужой резерв" - далее на конкурентной основе. - если реализация списывает чужой резерв (а это будет делаться только в том случае если нет свободного товара) - то "генерим событие" типа "отправить клиенту отлуп, что его товар продан, так как клиент ормоз, товар высокодифицитный, манагеры хотят кушать". если появляются ЛЮБИМЫЕ клиенты - то начинаем их "идентифицировать" - вместо безликого "Розничный покупатель" ВВОДИМ (БЫСТРЫМ И УДОБНЫМ ОБРАЗОМ ДЛЯ МЕНЕДЖЕРА) персонифицированного покупателя, через "основное свойство "покупателя указываем что этот клиент относится к разряду "любимых" и зарезервированный на него товар продавать нельзя. Такой запрет продажи можно реализовать несколькими способами как штатно (но с небольшими неудобствами для манагеров), так и с мелкими дописками (но прозрачно и удобно для манагеров).
.
Могу написать еще много чего, а лучше всего - закажите себе консультацию ПО СУЩЕСТВУ как вам сделать в типовой ТИСЕ чтобы получить то что вам надо. а то чувствуется никто ничего вам толком не показывал/не объхяснял и вы изобретаете мозголомныесхемы вне конткеста построения ТИС. в итоге придете к тем же возможностям что есть втис, только с полностью насмерть перекуроченной конфигой.
.
привлекайте квалифицированных специалистов по ТИС.
.
Неподтвержденка служит для фиксации "неоформившихся" хотелок клиентов. Типа я там може к вам завтра забегу и куплю то что мне нужно. а если товар ане будет тои фиг с ним - забегу потом через недельку. если же хотелка клиента ОФОРМИЛАСЬ ЧЕТКО и вы болеете за то, чтобы УДОВЛЕТВОРИТЬ ДЕЙСТВИТЕЛЬНОЕ пожелание клиента - то товар придется РЕЗЕРВИРОВАТЬ.
.
следующее - если вы хотите избежать ситуации когда товар зарезервирован, а покупатель не пришел - и получилось так что ни ему не продали, ни другому который вот сегодня был но товар-то зарезервирован... - то СЛЕДУЕТ ПРИНЯТЬ ДЛОЯ СЕБЯ СТРАТЕГИЮ ТОРГОВЛИ. Если вариант: конкуретные продажи покупателям - про принципу "кто первый встал того и тапки" - то все оформляем заявками на склад, у всех проджавцов ставим ШТАТНУЮ галочку "разрешить продавать чужой резерв" - далее на конкурентной основе. - если реализация списывает чужой резерв (а это будет делаться только в том случае если нет свободного товара) - то "генерим событие" типа "отправить клиенту отлуп, что его товар продан, так как клиент ормоз, товар высокодифицитный, манагеры хотят кушать". если появляются ЛЮБИМЫЕ клиенты - то начинаем их "идентифицировать" - вместо безликого "Розничный покупатель" ВВОДИМ (БЫСТРЫМ И УДОБНЫМ ОБРАЗОМ ДЛЯ МЕНЕДЖЕРА) персонифицированного покупателя, через "основное свойство "покупателя указываем что этот клиент относится к разряду "любимых" и зарезервированный на него товар продавать нельзя. Такой запрет продажи можно реализовать несколькими способами как штатно (но с небольшими неудобствами для манагеров), так и с мелкими дописками (но прозрачно и удобно для манагеров).
.
Могу написать еще много чего, а лучше всего - закажите себе консультацию ПО СУЩЕСТВУ как вам сделать в типовой ТИСЕ чтобы получить то что вам надо. а то чувствуется никто ничего вам толком не показывал/не объхяснял и вы изобретаете мозголомныесхемы вне конткеста построения ТИС. в итоге придете к тем же возможностям что есть втис, только с полностью насмерть перекуроченной конфигой.
.
привлекайте квалифицированных специалистов по ТИС.
Все спасибо за ответы, особенно чебуратору за его опус) все, что написано в опусе вроде и было понятно, но вопрос был немного не в этом. как сделать, чтобы реализация одному и тому же контрагенту на основе неподтвержденных заявок не выпиливала позиции из всех заявок? может, я неправлильно объяснил, могу пояснить... скрины позже немного. еще раз всем спасибо!
могу соврать, бо у себя немного переточил. но в штатной сделано так: реализация на основании НЗ - списывает эту НЗ. с "баланса" учета неподтвержденных заявок. Причем - абсолютно пофиг, что реализация введена на основании какой-то конкретной НЗ. В первую очередь будут закрыты позиции из самых первых незакрытых по ФИФО заявок. Сказанное верно в рамках заявок одного договора одного клиента. Ничто не мешает на оснвоании заявки выписать реализацию и сменить вней договор/клиента - реализация успешно проведется. НЗ останется висет в учете как и была.
.
важно? неподтвержденные заявки как и прочие заявки должны закрываться "в ноль." т.е. если выписали НЗ, а по ней никакой сделки не прошло - эту НЗ следует закрыть шатными документами, предназначенными для этих целей.
.
конкретней ответить на вопросы - это только голосом. бо авто изъясняется сильно уж телепатически.
.
совет: не надо строить систему удовлетворения "заявок" клиентов базируясь на НЗ. В результате будете изобретать велосипед и писать контур учета паралельный удже существующим возможностям. а так как возможностей штатных представляете слабо тио и свой участок учета будет написан кранйе слабо и криво. Для ПРЕДМЕТНЫХ разговоров я открыт в скайпе zlopun
.
важно? неподтвержденные заявки как и прочие заявки должны закрываться "в ноль." т.е. если выписали НЗ, а по ней никакой сделки не прошло - эту НЗ следует закрыть шатными документами, предназначенными для этих целей.
.
конкретней ответить на вопросы - это только голосом. бо авто изъясняется сильно уж телепатически.
.
совет: не надо строить систему удовлетворения "заявок" клиентов базируясь на НЗ. В результате будете изобретать велосипед и писать контур учета паралельный удже существующим возможностям. а так как возможностей штатных представляете слабо тио и свой участок учета будет написан кранйе слабо и криво. Для ПРЕДМЕТНЫХ разговоров я открыт в скайпе zlopun
(13) CheBurator, не совсем так. Специально вживую (не лазя в код) проверил на ТиСе.
Если реализация делается на основании НЗ, то в реализацию первоначально попадает нереализованный остаток именно по этой конкретной заявке. Но если в реализации вручную увеличить количество, тогда при проведении закрываются другие заявки того же покупателя на имеющееся в этих заявках количество в пределах добавленного.
Поясню на тех же цифрах из (12)
На основании заявки №1 вводится реализация 1. Первоначально в реализации 3шт. Меняем на 2шт. Проводим реализацию 1. По регистру Заявки закрываются 2 штуки по заявке №1
На основании заявки №2 вводится реализация 2. Первоначально в реализации 2шт.
Варианты:
1) Проводим реализацию 1. По регистру Заявки закрываются 2 штуки по заявке №2
2) Меняем на 3шт. По регистру Заявки закрываются 2 штуки по заявке №2 и 1 штука по заявке №1
3) Меняем на 5шт. По регистру Заявки закрываются 2 штуки по заявке №2 и 1 штука по заявке №1
В вариантах 1) и 2) по регистру остатков ТМЦ расход будет составлять 2 и 3 шт. соответственно, т.е. ровно столько, сколько в реализации и в закрытии заявок. Если повезет.
В варианте 3) по регистру остатков ТМЦ расход будет составлять 5 шт. Если повезет.
"Если повезет" в том смысле, что указанное в реализации количество будет в наличии, т.е. в остатках ТМЦ. Поскольку НЗ товар не резервирует, то не факт, что указанное в заявках количество товара фактически имеется на складе.
На 100% согласен. Во-первых, непонятно, как ТС находит для конкретного клиента именно его заявку, выписанную на обезличенного покупателя. Ну, допустим, как-то находит. Если выписывать реализацию на основании заявки и строго придерживаться количеств из заявки, тогда работает штатный механизм. А если менять количество, тогда без изобретения велосипеда, со всеми вытекающими, не обойтись.
Во-вторых, НЗ - это только намерение, клиент никаких обязательств на себя не принимает. Тогда почему продавец должен на себя брать какие-то обязательства, да ещё под это дело что-то менять в своей системе учета ?
Если реализация делается на основании НЗ, то в реализацию первоначально попадает нереализованный остаток именно по этой конкретной заявке. Но если в реализации вручную увеличить количество, тогда при проведении закрываются другие заявки того же покупателя на имеющееся в этих заявках количество в пределах добавленного.
Поясню на тех же цифрах из (12)
На основании заявки №1 вводится реализация 1. Первоначально в реализации 3шт. Меняем на 2шт. Проводим реализацию 1. По регистру Заявки закрываются 2 штуки по заявке №1
На основании заявки №2 вводится реализация 2. Первоначально в реализации 2шт.
Варианты:
1) Проводим реализацию 1. По регистру Заявки закрываются 2 штуки по заявке №2
2) Меняем на 3шт. По регистру Заявки закрываются 2 штуки по заявке №2 и 1 штука по заявке №1
3) Меняем на 5шт. По регистру Заявки закрываются 2 штуки по заявке №2 и 1 штука по заявке №1
В вариантах 1) и 2) по регистру остатков ТМЦ расход будет составлять 2 и 3 шт. соответственно, т.е. ровно столько, сколько в реализации и в закрытии заявок. Если повезет.
В варианте 3) по регистру остатков ТМЦ расход будет составлять 5 шт. Если повезет.
"Если повезет" в том смысле, что указанное в реализации количество будет в наличии, т.е. в остатках ТМЦ. Поскольку НЗ товар не резервирует, то не факт, что указанное в заявках количество товара фактически имеется на складе.
совет: не надо строить систему удовлетворения "заявок" клиентов базируясь на НЗ. В результате будете изобретать велосипед и писать контур учета паралельный уже существующим возможностям
На 100% согласен. Во-первых, непонятно, как ТС находит для конкретного клиента именно его заявку, выписанную на обезличенного покупателя. Ну, допустим, как-то находит. Если выписывать реализацию на основании заявки и строго придерживаться количеств из заявки, тогда работает штатный механизм. А если менять количество, тогда без изобретения велосипеда, со всеми вытекающими, не обойтись.
Во-вторых, НЗ - это только намерение, клиент никаких обязательств на себя не принимает. Тогда почему продавец должен на себя брать какие-то обязательства, да ещё под это дело что-то менять в своей системе учета ?
(15) согласен. Правильно гашение происходит так как ты описал.
Глянул на имеющемся на руках 964 релизе
там
.
ТИЗаявки.Сортировать ("ЗаявкаПокупателя",1); //сортируем заявки по дате
стр=0;
Если ТИЗаявки.НайтиЗначение(ДокОснование,стр,"ЗаявкаПокупателя")<>0 Тогда
ТИЗаявки.СдвинутьСтроку(-(стр-1),стр);
КонецЕсли;
.
это отрабатывает когда нет резервов. Если есть резервы - то гасятся в порядке заявок-резервов аналогичным образом. а потом отрабатываются оставшиеся. У меня 932 релиз и по коду понять что там было в самом начале (возможно мое соображение касалось резевров только - найду 932 гляну) - в районе 2006 года - уже трудновато, а нулевого 932 мдшника нет.
.
у себя систему заявок переписывал под более прозрачные реалии. Реализация, выписанная на основании заявки - гасит заявку, потом гасит СВОБОДНЫЙ остаток (при превышении в реализации колва по заявке). При этом не трогает заявки по этому же клиенту по этому же договору, например:
Остаток на складе = 10
-Заявка1, Товар1 = 7
-Заявка2, Товар1 = 2
Реализация по заявка1 на 9шт - не проведется, так как по заявке 7шт, +1шт в свободном остатке, не хватает 1 шт.
.
такая система оказалась ближе менеджерам, потому что работаю, по сути, хоть и по договору в целом, но посделочно. Так легче контролируется/управляется.
.
штатная система ТиСа больше ориентирована на "длинные" заявки - заявки идут потоком, потоком идут отгрузки, главное - отгрузить столько, сколько запросил клиент всего. а по каким заявкам - пофиг.
.
Вдобавок у меня реализация всегда полностью гасит заявку, даже если реализация меньше заявки (например недогруз или отказ клиенту в части товара и т.д.) - Клиенту проще считать что с этой заявкой финиш! что надо - вцыставляет новую заявку, а не ждет когда догрузхят по старой не поолностью отгруженной - такая система тоже прозрачнее/управляемее с точки зрения менеджеров.
Глянул на имеющемся на руках 964 релизе
там
.
ТИЗаявки.Сортировать ("ЗаявкаПокупателя",1); //сортируем заявки по дате
стр=0;
Если ТИЗаявки.НайтиЗначение(ДокОснование,стр,"ЗаявкаПокупателя")<>0 Тогда
ТИЗаявки.СдвинутьСтроку(-(стр-1),стр);
КонецЕсли;
.
это отрабатывает когда нет резервов. Если есть резервы - то гасятся в порядке заявок-резервов аналогичным образом. а потом отрабатываются оставшиеся. У меня 932 релиз и по коду понять что там было в самом начале (возможно мое соображение касалось резевров только - найду 932 гляну) - в районе 2006 года - уже трудновато, а нулевого 932 мдшника нет.
.
у себя систему заявок переписывал под более прозрачные реалии. Реализация, выписанная на основании заявки - гасит заявку, потом гасит СВОБОДНЫЙ остаток (при превышении в реализации колва по заявке). При этом не трогает заявки по этому же клиенту по этому же договору, например:
Остаток на складе = 10
-Заявка1, Товар1 = 7
-Заявка2, Товар1 = 2
Реализация по заявка1 на 9шт - не проведется, так как по заявке 7шт, +1шт в свободном остатке, не хватает 1 шт.
.
такая система оказалась ближе менеджерам, потому что работаю, по сути, хоть и по договору в целом, но посделочно. Так легче контролируется/управляется.
.
штатная система ТиСа больше ориентирована на "длинные" заявки - заявки идут потоком, потоком идут отгрузки, главное - отгрузить столько, сколько запросил клиент всего. а по каким заявкам - пофиг.
.
Вдобавок у меня реализация всегда полностью гасит заявку, даже если реализация меньше заявки (например недогруз или отказ клиенту в части товара и т.д.) - Клиенту проще считать что с этой заявкой финиш! что надо - вцыставляет новую заявку, а не ждет когда догрузхят по старой не поолностью отгруженной - такая система тоже прозрачнее/управляемее с точки зрения менеджеров.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот