Здравствуйте.
Подскажите, кто работает с УНФ, как корректно вести учет Заказов? Проблема следующая:

1) Есть заказ поставщику. Мы его полностью оплатили, получили товар, затем сделали возврат части товара.
И теперь в различных местах у нас всплывает, что заказ не полностью оплачен. Как я понимаю, чтобы этого не было нужно вручную залезать в Заказ и править его чтобы он соответствовал реально купленому товару с учетом возврата?

2) Заказ поставщику на 100р. Оплачен нами авансом 100р. Товара пришло на половину заказа 50р. Что нужно сделать, чтобы оплата по этому заказу закрыла когда-нибудь следующий заказ этому контрагенту? Какие-то корректировки нужно сделать, чтобы отцепить наш аванс от Заказа?

3) Ну и с заказами покупателя аналогичная ерунда. Если вернул клиент часть товара то в списке заказов покупателей вечно будет висеть не полностью закрашенный кружок. и будет показано что клиент нам должен по заказу.

очень просто
надо либо работать только с УНФ и быть чуть ли не "своим" в их техподдержке по частоте контактов, знать все баги и глюки этой конфы

либо не работать с УНФ.

(1) как требуемый функционал, частичный отказ от заказов, реализован в УТ11 и ЕРП ?

1. Смотреть в сторону расчетов. Если расчеты ведутся в разрезе заказов то очевидно что после возврата на заказе поставщику лежит переплата. Корректировкой задолженности перевилите переплату в зачёт оплаты по другому заказу. По заказам покупателя аналогично.
.
Если выбрали расчеты по документам - то ссзб и нехер удивляться что прога не вангует ваши замыслы насчет переплаты. Ручками, ручками.
.
Опять же можно не вести учет оплаты по документам - потому что долбодятлы не умеют этого - а вести учет по договору.

2. Аналогично

3.аналогично

Спасибо за ответы :) будем разбираться.

(2) там вроде "строка отменена по причине" в заказе указываешь, разбив исходную строку на две по количеству единиц

(0) методисты в 1с не умеют в исключения. У них только стандартная схема прописана. Шаг влево-вправо - расстрел

Заказы нужно ручками обрабатывать.
Нельзя так. Заказал на 100, а купил на 50.
Будь добр отмени строк на 50

(9) Заказ поставщику оплачен и получен полность; по каким то причинам вернули часть товара
Это может быть и через месяц и через полгода.
И тут система начинает сигнализировать о незакрытом заказе в прошлых периодах ...

Это бред болезненный, и конкретный косяк учетной системы.

(10) По заказу 100 рублей. Оплачено 100 рублей. Отгружено на 50 рублей.
Он реально незакрыт. Нормальная картина.

(11) Это да. Я не про то

(10) немодифицировать заказ при возврате - это несложно. Но тут как определить - при возврате заказ считать исполненым полностью или нет? Ситуации ведь разные бывают. И вполне нормальная ситуация когда при возврате заказ становится неисполненым (обнаружен спустя какое-то время производственный брак, идет возврат и будь добр вместо возвращенного допоставить товар нормального качества).

Пусть даже заказ при возврате остаётся полностью исполненым. А что делать с взаимооасчетами если они ведутся по заказам? По товарному наполнению считаем исполненым, а по взаиморасчетам будет висеть хвостик? Хрен потом учетчики разберутся откуда хвостик... Да, можно при возврате по взаиморасчетам кидать хвостик на "пустой" заказ - будет ли это лучше?
Напридумывать схем по возвратам можно разных - вопрос будут ли они лучше/понятнее текущей схемы?

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

В Унф дохрена - с моей точки зрения - косяков. И не программных, а концептуальных.
Например, в заказе покупателя есть ссылка Анализ заказа - показывает состояние заказа сводное. Так вот вам хрен - показывает только то, что указано именно в заказе, не учитывая движения по заказу, которые могут быть выполнены другими документами. И все. Увидеть истинное состояние заказа только отчетом соответствующим можно...

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

Про отчеты я уже писал. По умолчанию в отчетах нет ни кода товара, ни артикула. Нет даже опции такой в настройках (это даже в тис есть). Сиди и в каждом отчете через скд настраивай...

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

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

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

(21) да, такой вариант - я упоминал его выше - реализовать вообще в коде совсем малость подправить. И в большинстве случаев так будет норм. Но не во всех сделках, часть сделок будут по типу допоставки недогруза из-за возвратов. Городить новую сделку с перекидыванием на неё переплаты может быть некомильфо.
Но предложенная схема в большинстве случаев мне кажется более удобной.