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

сделать как просит клеент, взять деньги

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

2300 час стоимость консультанта

(0) В меню Ещё ТЧ Товары есть команда Отвязать от заказа. Т.е. док на основании заказа, но товары можно отвязать. Не устраивает? Написать расширение,которое будет сверять Поступление с заказом и нужные строки отвязывать от заказа

(3) это я предлагал, не устраивает. Типа цены можно сравнивать в заказе и поступлении, неудобно если отвязать.

(2) все верно, но т.к. это мой постоянный клиент, то 2000

(4) Я в (3) говорил не о полной отвязке Поступления от заказа, а отдельных товаров, которых НЕТ в заказе. Еще раз, ТЧ Товары-меню Еще-Отвязать от заказа. По этой команде от заказа отвязывается выделенная строка заказа

выделенная строка заказа = выделенная строка ТЧ товары

(6) речь же про частичную отвязку

(8) ТОлько что перечитал. Сорри, не въехал сразу )))

кстати, а внятно эта методология где-то описана? на ИТС описания куцые, в курсах - рассматриваются "идеальные варианты", про отклонения, как правило, говорится вскользь ("при отклонениях можно оформить...",и все)

(10) Проблема 1с в том что она живет в мире розовых менеджеров и голубых кладовщиков.

Короче сделал затычку. Работает как часы.

В модуль ПроведениеСерверУТ

&Вместо("СообщитьОбОшибкахПроведенияПоРегиструЗаказыКлиентовПоставщикам")
Процедура дор_СообщитьОбОшибкахПроведенияПоРегиструЗаказыКлиентовПоставщикам(Объект, Отказ, РезультатЗапроса)
    ПредОтказ = Отказ; //Сохраняем отказ
    ПродолжитьВызов(Объект, Отказ, РезультатЗапроса);
    Отказ = ПредОтказ; //Восстанавливаем отказ
КонецПроцедуры

(11) проблема в том, что кто-то что-то планирует, а кто-то живет одним днем
как ты думаешь зачем сделано так, чтобы нельзя было больше заказа по нему приобрести?
И да, у тебя остаточный регистр не будет закрываться

(12) разные уровни формализации процессов бывают.
КМК это недоработка, что нельзя закрыть заказ тем что есть

позвонил поставщик -  этого нет, меняйте на вот это. А вот это по акции + 1 бесплатно берите еще.
По хорошему нужно заказ корректировать, но см (13)

(13) это можно, но нельзя сделать лишний перезаказ

(12) да можно там все приобрести и больше заказа и того чего нет изначально в заказе, просто это ж надо работать, мозгами шевелить, а это лень

Потому что заказ может выполняться несколькими поставкам и надо знать остаток недопоставленный еще

(15) и плохо что нельзя. Просто программа не позволяет, но бизнесс процесс такой вполне нормальный

(17) нужна возможность закрыть заказ тем что есть

(16) сам механизм еще в (0) описан, но там слишком много ручной работы

(20) много работы нажать 2 кнопки? ну тады ой... пусть ждут когда в 1С появится одна большая кнопка "сделать хорошо" -)

(21) Работа программиста 1с во многом состоит в том, что бы эти кнопки создавать. Удивляет то, что люди вроде ТС в упор не видят, что видение этого "хорошо" у каждой конторы своё.

(21) 2 кнопки по каждой строке

(23) это с какого перепугу? только на той где превышение количества

(24) ну никто не говорит что такая строка всего 1

(25) ну 2, 3?... если их больше то тут уж надо решать вопрос с отелом закупа почему заказывают одно, а приходит другое -) Да и вообще тогда зачем заказы поставщику как таковые при таком бардаке -)

+(26) я вот тоже склоняюсь, что им заказы поставщику не нужны, если они отражают "примерную картину"

(22) Это должны видеть методолги 1С, а не я, чтобы мне не затыкать их дыры.

(26) (25) проблема в том, что эти строки надо выискивать.

(27) там бывает пересорт. Вместо одного другое или чутка побольше (неточно намерили)

(27) а какой смысл вообще в документе заказ поставщику, если он тупо дублирует приход?

ИМХО заказ на то и заказ, это то что мы заказали, а поставщик привез другое количество, потому что у него норма упаковки и он не готов рвать упаковку, плюс арфы нет, но есть аналог - бубен. Т.е. мы что то заказали, они что то привезли.
А в том виде что есть в 1С, это просто тупо для разделения функционала т.е. чтобы не дать менеджеру по закупки возможность проводить и править документ поступления, только заказ поставщику, на основания которого обезьянка в должности операционист, проведет приход и сформирует ордера на склад

(31) заказ нужен чтоб было за что платить, а не просто так

(30) если не то привезли, то значит и в документах поставщика неправильно оформлено. Значит это корректировка приобретения или замена документов.
Но это не про заказы. Если вам не надо отслеживать их, что привезли не то, то может и заказы не нужны?

(33) ты это методистам разработчиков объясни.

Методически накрутили именно так. Есть Заказ - своего рода план. А есть Поступление - реальный факт. Причем, еще и докрученный Ордерной схемой приемки поступлений на склад.

И есть отчетность о наличии несоответствий между Покупками по планам и по фактам. И далее по взаиморасчетам.

При этом всем очевидно, что реализовано это все в учетной системе не идеально. Но мало того, что не идеально, так и провоцирует на неадекватное использование всей этой разработанной функциональности, не в том виде, как задумывалось, а в том виде как оно на практике работает.

впрочем, зачем я это все объясняю... похоже, что это так думаю как бы вслух :-)

(33) это когда ты 1 шт раз в месяц заказываешь то нужно что точно.
А когда по 100 - 200 позиций, то можно и с отклонениями

Например какой нибудь продуктовый магазин. Придет молоко грусный молочник а не веселый не существенно

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

(34) (37) так никто и не заставляет - просто оформляйте вне заказа, потом заказ закрываете.
Потом смотрим отчеты - что здесь постоянно заказывают одно, а приходит другое.

(34) все просто, 1С разрабатывает программу для себя, т.е. для франча торгующий коробками с 1С. Поэтому тут и не бывает отклонений и пересортов, ведь если клиент заказал коробку с БП, ты же не будешь ему отгружать коробку с ЕРП, типа пересортили.

(40) причем 2 шт

(40) 1с разрабатывает для тех, кто дружит с математикой. Если этого всего не надо - так и не стоит мучаться может?

А кстати в 10 как было?

(31) чтобы сравнивать план-факт в том числе и по ценам. А то поставщик может другие цены поставить

(42) ага, опять клиенты плохие. Не те, понимаешь. С математикой не дружат. Хотят как удобно им, а не "прохфессору"

(45) ну если это по факту, бизнес ларька у них
а остальное тоже хотят, но затраты нести не хотят

(46) вот, вот, комфортно должно быть только ларечникам. Остальные должны колоться, плакать, но жрать 1с:Кактус

(47) остальные должны думать
по теме - тебе как минимум надо будет сносить РН ЗаказыПоставщикам, т.к. он не будет закрывать в ноль и база будет "пухнуть"

(48)
а) и сильно пухнуть? ггг
б) если сильно пухнуть, можно закрывать раз в год автоматом корректировкой регистров.

Еще вопросы, юноша с глазами горящими теорией?

(49) > можно закрывать раз в год автоматом
У меня как-то раз стиралка сдохла. 10 лет прослужила, подшипники переклинило и все. Пришел мастер, говорит - "ой какая машинка хорошая, давая я тебе тут подшаманю, будешь раз в год вот эту хрень менять, и сносу ей еще 10 леь не будет". Я подумал, послал его нахер и купил себе новую. На те же 10 лет.

Ну вас в хер, таких "практиков".

(49) сильно беременна? Можно аборт делать каждый год - такого уровня ответы

(51) Рекомендую поработать на фрилансе, сразу "ближе к земле" станешь

(13) "КМК это недоработка, что нельзя закрыть заказ тем что есть"
это как у кого БП построены.
у себя на клюшках делал так - потому что БП ТАК построен. Если по заказу что-то недогружено - реализация закрывает заказ полностью. В типовую процедуру добавлено 1-3 строки (точно не помню). работает тыщщу лет уже...

(52) ты так пишешь, как-будто это что-то замечательное. Нет, я не хочу ларьками заниматься

(54) тогда просто прими как данность, что УТ - универсальная программа и для ларьков в том числе.

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

(55) > и для ларьков в том числе.
Ну вот они и брызги той самой субстанции от тебя.

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