Ковыряю УНФ (1.6.16.153). Столкнулся с такой фичей.
Клиент заказывает две позиции:
Тов1 - 1 шт.
Тов2 - 3 шт.
Менеджер оформляет ЗаказПокупателя.
Покупатель забирая товар, говорит - "Положите мне Тов1 еще одну штучку, а Тов2 замените на Тов3".
Если менеджер НЕ правя заказ покупателя выписывает Реализацию:
Тов1 - 2 шт.
Тов3 - 3 шт.
то в отчете по заказам покупателя будет:
Тов1 - (-1) шт.
Тов2 - 3 шт.
Тов3 - (-3) шт.
Т.е. при проведении реализации регистр ЗаказыПокупателей минусуется не Мин(Заказано,Отгружено), а именно на Отгружено. Даже если товара в заказе нет, но есть в реализации, то Регистр всё равно сминусуется.
Это так и должно быть?
Конечно, можно менеджеру надавать по рукам и запретить выписывать реализацию отличную от ЗаказаПокупателя.
Но может я чего не знаю/не понимаю? Может есть где-то какая-то настройка, как списывать ЗаказыПокупателя при проведении Реализации?

Вопрос, и нахрена вам заказы, если покупатели берут товары не по заказу?

(0) "есть где-то какая-то настройка, как списывать ЗаказыПокупателя при проведении Реализации?"
Есть. И она работает. Ровно так, как и показано в примере.

(0) остаток по Заказу: нет в заказе - остаток в минус
все верно

"Вопрос, и нахрена вам заказы, если покупатели берут товары не по заказу?" - чтобы планировать сколько и чего закупать.
И тут видятся такие грабли:
На складе лежит Товар1 - 1 шт.
Покупатель1 заказал Товар1 - 1 шт. Но пока не покупает, думает...
Покупатель2 заказал Товар2 - 1 шт. Приехал в магазин, увидел Товар1 и решил Товар1 тоже купить. Позвонили Покупателю1, тот говорит "Мне пока не горит, продавайте, я на следующей неделе буду брать".
Если Товар1 добавить в реализацию, не исправляя Заказ, то в регистре будет:
Покупатель1,Товар1 - 1 шт.
Покупатель2,Товар1 - (-1)шт.
Т.е. в сводном отчете "Итого заказано Товар1" - 0 шт.
и Покупатель1 курит бамбук. Мне кажется это не правильно.

(0) это норма! (с) Малышева

(0) Это не только фича унф, а вообще всех поделок 1с на бсп
Поведение заказов - нелогичное и не овечающее запросам бизнеса, на планирование закупок в т.ч.

Ясно, спасибо за разъяснения. Буду ставить заглушку, если в реализации товар/количество вываливается за рамки заказа - фигвам, выписывайте отдельной накладной вне заказа.

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

(8) не забывай, что менеджерам часто закрывают период, оставляя максимум 5 дней и это тоже правильно

(8) Заказ это не обязательно резерв. Понятно, что на каждый чих не наздравствуешься. И специфика у всех своя. Но почему если на основании заказа менеджер имеет право выписать ТОЛЬКО то, что в заказе система ему позволяет выписать всё что угодно? Впрочем этот вопрос риторический. Решение есть. Еще раз, спасибо.

(6) вообщето и без бсп такое было на оф. и очень, кстати логичное поведение заказа

У меня как-то другое мнение, ближе к (6).
Не знаю какую настройку в (2) имеют в виду? может, есть настройка для разных режимов заказов покупателей?
.
все зависит от того что надо регистрировать?
имеет ли ценность сведения о том, что клиент взял то, чего не было в заказе? хз...  мне кажется не очень - если товар есть на свободном остатке - да пусть клиент хоть все сразу скупит и то что в заказе было и то что не было... Реализацией с заказа списываем то что есть в заказе. Все остальное что сверх заказа - по заказу не проводим.
.
опять-таки, с другой стороны:
"Покупатель забирая товар, говорит - "Положите мне Тов1 еще одну штучку, а Тов2 замените на Тов3". Если менеджер НЕ правя заказ покупателя выписывает Реализацию" -ЭЭЭ! подождите! у вас тут разрыв (до этого не было ни единого разрыва!). Менеджер выписал реализацию, клиент забрал - а, извините, товар-то откуда он забрал. Товар где-то лежит (склад, кладовка). До этого товар собирался по заказу, а тут товар собирается - КАК? из ниоткуда появляется перед покупателем? как-то задание на "отбор" товара для покупателя должно же быть дано. И если ранее оно было дано по заказу, а теперь в качестве задания выступает реализация - то это трэш и угар, бяка. Все новые хотелки клиента надо как-то зафиксировать и передать на "отбор" - ну и делаем новую заявку с новыми хотелками....
.
кака-то так... надо подробнее смотреть как в действительности все происходит, чтобы не натягивать на глобус. мне вот кажется что описано совсем не так как происходит в действительности. или я чего-то недопонял кардинально...
.



мне кажется не очень - если товар есть на свободном остатке - нам не пофиг

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

(13): "Отменять ту заявку и делать новую - лишние документы/движения" - ошибаетесь, они НЕ лишние.

(13) Именно так. Отменять заявку. И делать новую. И бить по рукам всех, кто пытается оспорить этот факт. Или работать вообще без заявок.

(15) Исскуственный подгон реальности под систему.
В таком случае 1с никогда не отчетит на вопрос что хотел и что взял клиент.

(13) "Править заявку недельной давности? Редактирование может быть уже закрыто. Отменять ту заявку и делать новую - лишние документы/движения."
- корректировочная заявка делается, например. вообще никаких проблем.

(13) "Все остальное что сверх заказа - по заказу не проводим" как раз то, что мне нужно."
- переходи на ТиС 7.7, там как раз так и сделано.
только свои засады есть - несмотря на то что ты реализацию делаешь по заявке - она спишет более ранние заявки если они есть - потому что покашение идет в рамках договора

... поэтому тоже подшаманивать приходится, но по коду все намного проще...

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

Опять же - как не спецу в 8-ке - там что, ахеренно сложно подкрутить чтобы делало как ТС надо?

(21) F rfr tve yflj&

В смысле - как ему надо?

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

(16) Система прекрасно скажет что взял клиент, расходная же существует. А вот что он хотел уже не важно абсолютно. Потому что заказ не для того чтобы знать что ХОТЕЛ, а планировать резервирование, допоставку, производство, перемещение и т.п. под то что ХОЧЕТ клиент. И отчеты по заказам именно это и выводят. Поэтому либо аннулировать заказ и выписывать без заказа либо править заказ под реальность. Если программа будет спокойно проглатывать несоответствие заказа и расходной, никакой правдивой аналитики по заказам получить будет невозможно. Мне даже слегка странно почему это непонятно, это же основа практически всех торговых типовых

(25) а какая аналитка по заказам нужна? хз...
обычно (?) - что заказд клиент и что мы смогли удовлетворить.
если клиент берет без заказа - нам это "не интересно" - он взял - мы смогли удовлетворить его хотелку.
.
Поэтому тут хорошо бы понять в УНФ какова концепция использования заказов - для чего они? какую бизнес-сущность отражают? для чего? я УНФ не знаю, поэтому тут не скажу...
А надо послушать тех, кто знает.

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

(27): загляни-ка сюда (сильно подозреваю, что кое-что прояснишь для себя): http://catalog.mista.ru/public/298945/

(25) Вот именно, мне ГОРАЗДО ВАЖНЕЕ знать что ХОЧЕТ клиент, сколько ЕЩЕ нужно докупить, а не разницу между тем что хотел клиент и что ему отгрузили. Интернет-магазин (ИМ), он с одной стороны как розница - частные клиенты, небольшие заказы, с другой как опт - отгрузка с временным лагом между заказом и реализацией. Плюс постоянно нужно держать руку на пульсе сколько и какого товара держать на складе. Ассортимент широкий, но каждая позиция в малом количестве. При этом если оптовик часто готов ждать неделю-другую до отгрузки, то клиент ИМ, если не привезти завтра-послезавтра уйдет в другой магазин. И удобная связка между остатками и заявками основа планирования в ИМ.
В УНФ списание заявок нацелено на анализ разницы ХОТЕЛИ/ВЗЯЛИ, а инструментарий планирования закупок для интернет-магазинов совсем не удобный. По крайней мере обработка написанная лет семь назад для ТИС в легкую позволяет одному человеку за день спланировать заказы двум десяткам поставщиков для закрытия около сотни ЗаказовПокупателей. В УНФ смоделировать рабочий день закупщика пока не удается.
По (27) - о том и речь, что даже такой простой инструмент как отмена заявки и то нужно допиливать.

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

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

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

(32) Согласен, не правильно выразился, конечно не "убирать". А получилось действительно "шире" )))

(31) Работаем с УНФ 8 лет. Не существует проблемы с заказами, у тебя просто привычка делать что-то определенным образом. Обычно составляется заказ, там фиксируются именно хотелки клиента, резервируется товар в наличии, планируется перемещение с др складов на нужный склад, делается заказ поставщику или на производство на отсутствующий товар. Единственная доработка у меня была на подписке, теперь в расширении, это составление заказа поставщику на основе заказа. Каждый раз создается документ тому поставщику и на отсутствующий его товар и больше никакой не попадает в Заказ поставщику. И так до тех пор пока не выйдет пусто заказ (т.е. все заказано) Закупщику не надо думать что заказывать только жать кнопку Создать на основании. Но это мои хотелки, вам возможно не обязательно. Остальное все работает как часы В том числе и отчеты. Что заказано клиентом, что отгружено, что в наличии, что заказано и кому. Просто разберись как это работает.
Приезжает клиент и открывается НЕ расходная, а его заказ! И правится при необходимости по количеству, составу и т.д. И когда все утряслось - на основании делается расходная. Все получается легко и просто и как надо

(34) У меня типичный заказ клиента 5-10 строк, в котором 90% товаров из наличия, остальное нужно дозаказывать у поставщиков. В день сотни полторы заказов покупателей. На их основе делаются заказы поставщикам. Обычно это 15-20 поставщиков в день. У одного поставщика это три позиции, каждая по одной в разные заказы покупателей. У другого 30 позиций на 20 заказов покупателей, плюс 30 позиций на пополнение своих остатков. Сейчас всё это в ТИСе одной обработкой собирается по регистрам, правится/добивается руками на усмотрение закупщика и генерятся заказы поставщикам. Каждому в свое время. Кто-то, чтобы привезти мой заказ завтра, принимает заказ до 14, кому-то можно заказ скинуть и в 20 часов.
Ваша схема работы на такой вариант рассчитана?
По поводу "Приезжает клиент и открывается НЕ расходная, а его заказ" - именно так и делается. Но гладко лишь в теории. И опять пример из практики. Возил водитель клиенту два вольера на выбор - побольше и поменьше. Клиент взял маленький. У этого же водителя был другой клиент заказавший такой же маленький вольер. При доставке клиент понял, что не угадал с размером. Водитель ему - погоди, у меня в машине как раз большой остался. Вроде и водитель благое дело сделал, клиент доволен, водителю опять же второй раз к клиенту с новым вольером не ехать. Вечером, водитель отчитываясь ситуацию обрисовал. Оператор реализации поправил. А вот поправить заказ даже не подумал. В ТИСе с этим проблем не было. Я сейчас переношу данные из ТИСа в УНФ и вот как раз на этот случай из 2017 года попал. Данные перенес. Разными отчетами сравниваю что в ТИСе, что в УНФ и нашел этот минус. Стал копать, за период с 2012 по 2019 всего около 20 случаев, когда в реализации товара больше чем в заявке. И хорошо, что решил полностью все данные перенести, а не только итоги. Много нюансов вскрылось и разная логика по списанию заявок лишь один из них.

(27) "Я не на столько хорошо знаю как работает УНФ и если я в регистр буду писать не то, что ожидает система, с какого бока это выползет..."
ну, если понимать для чего используется регистр и как он построен - то совершенно пофиг что ожидает система и писать можно все что считаешь нужным. имхо

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

кстати, как в УНФ штатано закрыть неотгруженный заказ?

и как в УНФ быстро понимать - какая заявка полностью обеспечена остаткми, а какая нет? каким-то отчетом типа "состояние заявки"...? Можно штатно автоматом заявку клиента разделить на две - полностью обеспеченное и необеспеченное?

(37) Всей истории я уже не помню. Но наверняка водитель звонил в офис и согласовывал продажу иного товара. Наверняка править лишь по звонку не стали. По какой причине не поправили заказ, сейчас тоже не установить. Впрочем это и не важно. Важнее было понять почему заявки списываются так, а не как в ТИС и если штатные средства переключить на старый вариант списания. Штатных средств не обнаружено.
(38) - костылем, см. (28)
(39) в заявке есть отчет типа "состояние заявки". Есть ли средство автоматом поделить заявку по наличию не смотрел. Мне это и не важно. Всё равно свой костыль прилаживаю, так как мне важнее поделить заявку - это везем послезавтра (с учетом завтрашнего прихода), остальное клиент готов ждать, пока не появится у поставщиков. Но и то это частный случай. Чаще, если товара нет ни у меня, ни у поставщиков, заказ просто обрезается, либо по моему остатку, либо мой остаток + завтрашние поступления.

(39) Мысль - нужно смоделировать ситуацию. У клиента две заявки, одна переотгружена (заказал 1шт, отгрузили 2 шт), вторую текущую смотрим на обеспеченность товаром. Скорее всего количество по текущей заявке будет браться из самой заявки и всё покажет верно. А если у клиента три заявки и мы смотрим не обеспеченность конкретной заявки, а обеспеченность клиента товаром.
Думаю будет что-то вроде:
Заявка1, Тов1 - надо (-1) шт.
Заявка2, Тов1 - надо 3 шт.
Заявка3, Тов1 - надо 2 шт.
Итого Тов1 - надо 4 шт.
На складе 4 шт. - клиент обеспечен.
Что и требовалось доказать. Неисправленная, ранее отгруженная заявка, если не знать этой особенности и не отслеживать сей момент, заставит иметь бледный вид перед клиентом.

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

(41) как исследуешь - отпишись, интересно, бо планируем переход на EYA? а в ТИСе все заавтоматизировано практически до "одна большая кнопка" и хочется понимать что потом придется допиливать если надо будет и бюджет выделен. Хотя у меня отгрузка выше заявки даже при переходе на УНФ с такой "кривой" идеей учета заявок некритично будет. потому как перед отгрузкой ВСЕГДА сборка по складу, а она - сборка - только по заявкам "на отбор" (те же самые "заявка на склад").

и вообще - есть ли какие-то обучаловки-описания по УНФ? не там где менюшки рассказаны - а общие принципы ведения учета что и как работает...?

(43) EYA = УНФ?
По подобным БП работают почти все мои поставщики. Я им каждый день по заявке, они мне на следующий день товар. Всё что не смогли привезти или я не принял (брак/пересорт и т.п.) вычеркивается. Сегодня будет новый заказ с нуля. Когда водитель поставщика опаздывает и заказ поставщику нужно делать до прихода, конечно возникают нестыковки, т.е. вечером я узнал, что такой-то товар на склад не поступил, а дозаказать я его смогу только завтра, планируемые сроки для моих клиентов приходится сдвигать.
У меня в ТИСе также многое сделано для удобства манагеров. Через ExtForms заявки расцвечены. Зеленые - всё с моего склада, рыжим - к завтрашнему дню всё будет на складе (если поставщики не подведут). Красные - нужно разбирать ручками, либо у поставщика нет, либо поставщик данные не дает, либо еще что. В самой заявке каждая строка также подсвечена. Сами заявки через закладки рассортированы на: "это везем завтра/послезавтра/дата", "в ожидании", "необработанные" и т.д.
(44) Книжек много, но большая часть рассчитана на сферическую компанию в вакууме. В любом случае нужно на себя примерять, тестировать и разумеется допиливать.

(43) Потестил, всё как и предполагалось - в заказе по ссылке "Отчеты" есть отчет "Анализ заказа". Если к заказу есть реализация и он переотгружен в отчете лезут минуса. У следующего (без реализации) заказа данные фильтруются по текущему заказу и минусов не видно. Если смотреть сводный отчет "Заказы покупателей" (не из заказа), то по умолчанию идет группировка документ/номенклатура и по первому заказу минус, по второму плюс. Если оставить группировку только по номенклатуре, идет сложение по правилам математики. Если было переотгружено 2 шт. и в новом заказе также две шт, то эта позиция в отчет вообще не попадает, что в общем-то соответствует логике заложенной в УНФ .
Инструмента для деления ЗаявкиПокупателя на обеспеченную/не обеспеченную не нашел. Но как писал, мне это не актуально. Я уже прикрутил программное создание реквизита с типом "таблица значений", в него при создании формы гружу необходимые данные. И оперативно, в самой форме показываю, что есть в наличии, что можно заказать с поставкой на завтра, сколько штук на складе, у поставщиков, есть ли другие ЗаявкиПокупателя по той или иной позиции. У меня достаточно часто бывает ситуация, когда на имеющуюся 1 шт. на складе есть три заявки. При этом по первой заявке клиент ждет поступления какой-то другой позиции, по второй заявке, отправляемой в регион, я сам жду оплату по покупателя, который в свою очередь ждет ЗП. И эта одна шт. едет в третий заказ. А для двух первых заявок есть резерв у поставщика, который будет выкуплен при наступлении соответствующего события.

(36) и эта.. Злопчинский, ты поаккуратней с регистрами. Всё-таки писать в него всё, что считаешь нужным, даже прекрасно понимая как он работает, чревато. Завтра БН с сотоварищи решит этот регистр использовать скажем так, несколько иначе, а у тебя там, что-то непредусмотренное. Лучше уж свой регистр прикрутить, коли очень нужно.

(46) @что в общем-то соответствует логике заложенной в УНФ .@

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

(48) Да, понятие Минимум изучают в классах постарше )))
Помнится однажды знакомый на анекдот про программиста, который застрял в ванной с шампунем, на котором была инструкция "Нанести шампунь на голову, вспенить, смыть, повторить" заметил - "Сразу видно 1С-ник, системщик бы по прерыванию вывалился".
Это я к тому, что логика, заложенная в УНФ не является незыблемой как сама арифметике.

(48) я бы не писал в регистр если переотгружено...

(49) а есть в унф ведомость по типу ТиСовской "Ведомость по партиям", по которо можно проследить при необходимости расчет себестоимости списания?

(51) С себестоимостью в УНФ вообще всё сложно. В течении месяца она списывается только по среднему. При проведении документа "Закрытие месяца" стоимость каждой партии корректируется.
https://1eska.ru/projects/publications/upravlenie-nashey-firmoy-unf/kak-1s-unf-schitaet-sebestoimost-po-fifo/ - почтай, кошмары на ночь обеспечены.

(38) Просто перевести в состояние Закрыт , НЕ успешно и указать причину, или ... не указывать

(39) Так это и есть ненайденная или непонятая вами аналитика по закзам в УНФ. Запускаете отчет по заказам и видишь, что зсаказано, что от гружено, что в процессе обеспечения. Об этом и была речь, что нельзя дуроковать с заказами, иначе хрен разберешься через месяц - два

Курю "Расчет потребностей в запасах".... Минус по переотгруженной заявке обрабатывает корректно. Но мин.запас не учитывает, заказывает только то, что нужно по заявкам покупателей. Сама форма крайне неудобная, может оно конечно с непривычки, но найти/посмотреть нужные данные крайне не удобно. Формирует заказы на всех поставщиков скопом, т.е. выбрать конкретного поставщика и поработать только с ним не получилось.
Обработка "Закупка товаров" вообще чумовая вещь. Некая позиция закупалась под конкретного клиента в количестве 12 шт. единственный раз в году. Сегодня пришла, завтра ушла. Обработка считает 12 шт. продали за 1 день. Значит, для того, чтобы обеспечить потребность на ближайшие две недели нам нужно 12*14 = 168 штук. Покупай хозяин!

(55) Еще раз. 8.3 это не 7.7 Я понимаю, привык, что должно быть ТАК! Но прими как данность в 8.3 не ТАК и это далеко не всегда хуже, всегда ПО ДРУГОМУ и НЕПРИВЫЧНО. Работа с Заказами Покупателя в УНФ реализовано очень даже неплохо. А, на мой взгляд, придраться в принципе не к чему

(54) уродская идея формировать отчеты постоянно при оперативной деятельности. состояние заказа дб достаточно ясно из контекста самого заказа или арма по заказам. формировать отчеты для этого - уродство еще то.

(52) валовая прибыль по номенклатуре - можно развернуть до документа продажи? аналогично как в тис "Анализ продаж"?

(52) Это жопа (

(58) Можно

(59) Партии и УНФ - это почти несовместимые понятия. УНФ - это по среднему практически прекрасно, по партиям - пытался, но лет 6 назад бросил. Сегодня может то-то и поправили, но как-то уже пох.. )))

(61) я по фифо смотрел, вроде норм, но вот с партиями в разных месяцах - как по ссылке - не дотумкал посмотреть. если партии консолидируются на начало месяца - то смысл в таком партионом учете для целей исчисления себестоимости?

(62) Себестоимость она посчитает. Предводители любят спрашивать наценку по поставщикам ...

(56) Сами ЗаказыПокупателя сделаны неплохо, есть удобные поля для контактов, адресов и интервалов доставки, резервирование, планирование отгрузки. Но, как пишет в (57) Злопчинский, "идея формировать отчеты постоянно при оперативной деятельности... уродство еще то". Я писал выше, что пришлось допиливать, создавать программно реквизит формы, в него грузить необходимую информацию и отображать данные на форме, чтобы всё для обработки заказа было под рукой. Вот планирование закупок меня совсем не устраивает.
AlvlSpb, с высоты 8-летнего опыта, скажите: имеется около пятисот неотгруженных, но уже обработанных, т.е. товар либо в наличии, либо заказан поставщику, либо есть понимание к какому числу нужно товар заказать. Плюс около ста пятидесяти новых заявок, которые нужно разобрать, проставить желаемую дату отгрузки и т.д. Если все эти заявки отфильтровать, добавить к ним данные по остаткам и мин.запасам и свернуть по номенклатуре, будет около 500 строк товаров, какое-то количество которых нужно заказывать обязательно, плюс было бы неплохо пополнить остатки.
Есть удобный инструмент чтобы оперативно смотреть остаток, оптимальный запас, общий резерв и в какую заявку сколько товара нужно? Сколько, какого товара, у какого поставщика нужно заказать, принимая во внимание, что этот поставщик  возит минимум от 30 тысяч, этот товар можно заказать как минимум у трех поставщиков, этот ЗаказПокупателя лучше подождёт, т.к. минзаказ поставщику уже сделали и если добить сейчас - завтра не хватит на доставку, а в этот если не закажем сейчас, то в следующий раз поставка только через неделю. При этом учитывая, что склад и бюджет не резиновые и тупо заказывать всё до оптималки не вариант.
(59), (63) Я не Кощей, над златом чахнуть, считая каждую копейку, мне достаточно средней себестоимости.