Имя: Пароль:
1C
 
УНФ Заказы покупателя, Заказы поставщику
0 Nikkitka
 
16.09.21
12:28
Здравствуйте.
Подскажите, кто работает с УНФ, как корректно вести учет Заказов? Проблема следующая:

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

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

3) Ну и с заказами покупателя аналогичная ерунда. Если вернул клиент часть товара то в списке заказов покупателей вечно будет висеть не полностью закрашенный кружок. и будет показано что клиент нам должен по заказу.
1 Dmitry1c
 
16.09.21
12:37
очень просто
надо либо работать только с УНФ и быть чуть ли не "своим" в их техподдержке по частоте контактов, знать все баги и глюки этой конфы

либо не работать с УНФ.
2 Холст
 
16.09.21
13:00
(1) как требуемый функционал, частичный отказ от заказов, реализован в УТ11 и ЕРП ?
3 Злопчинский
 
16.09.21
13:17
1. Смотреть в сторону расчетов. Если расчеты ведутся в разрезе заказов то очевидно что после возврата на заказе поставщику лежит переплата. Корректировкой задолженности перевилите переплату в зачёт оплаты по другому заказу. По заказам покупателя аналогично.
.
Если выбрали расчеты по документам - то ссзб и нехер удивляться что прога не вангует ваши замыслы насчет переплаты. Ручками, ручками.
.
Опять же можно не вести учет оплаты по документам - потому что долбодятлы не умеют этого - а вести учет по договору.
4 Злопчинский
 
16.09.21
13:18
2. Аналогично
5 Злопчинский
 
16.09.21
13:19
3.аналогично
6 Nikkitka
 
17.09.21
07:12
Спасибо за ответы :) будем разбираться.
7 Dmitry1c
 
17.09.21
07:21
(2) там вроде "строка отменена по причине" в заказе указываешь, разбив исходную строку на две по количеству единиц
8 Гений 1С
 
гуру
17.09.21
07:57
(0) методисты в 1с не умеют в исключения. У них только стандартная схема прописана. Шаг влево-вправо - расстрел
9 Вафель
 
17.09.21
08:01
Заказы нужно ручками обрабатывать.
Нельзя так. Заказал на 100, а купил на 50.
Будь добр отмени строк на 50
10 Смотрящий
 
17.09.21
08:47
(9) Заказ поставщику оплачен и получен полность; по каким то причинам вернули часть товара
Это может быть и через месяц и через полгода.
И тут система начинает сигнализировать о незакрытом заказе в прошлых периодах ...

Это бред болезненный, и конкретный косяк учетной системы.
11 ДенисЧ
 
17.09.21
08:53
(10) По заказу 100 рублей. Оплачено 100 рублей. Отгружено на 50 рублей.
Он реально незакрыт. Нормальная картина.
12 Смотрящий
 
17.09.21
08:58
(11) Это да. Я не про то
13 Злопчинский
 
17.09.21
10:23
(10) немодифицировать заказ при возврате - это несложно. Но тут как определить - при возврате заказ считать исполненым полностью или нет? Ситуации ведь разные бывают. И вполне нормальная ситуация когда при возврате заказ становится неисполненым (обнаружен спустя какое-то время производственный брак, идет возврат и будь добр вместо возвращенного допоставить товар нормального качества).
14 Злопчинский
 
17.09.21
10:29
Пусть даже заказ при возврате остаётся полностью исполненым. А что делать с взаимооасчетами если они ведутся по заказам? По товарному наполнению считаем исполненым, а по взаиморасчетам будет висеть хвостик? Хрен потом учетчики разберутся откуда хвостик... Да, можно при возврате по взаиморасчетам кидать хвостик на "пустой" заказ - будет ли это лучше?
Напридумывать схем по возвратам можно разных - вопрос будут ли они лучше/понятнее текущей схемы?
15 Злопчинский
 
17.09.21
10:32
(10) ..
Это бред болезненный, и конкретный косяк учетной системы.
.
- а какое твое видение схемы работы по возвратам? Действительно интересно
16 Злопчинский
 
17.09.21
10:37
В Унф дохрена - с моей точки зрения - косяков. И не программных, а концептуальных.
Например, в заказе покупателя есть ссылка Анализ заказа - показывает состояние заказа сводное. Так вот вам хрен - показывает только то, что указано именно в заказе, не учитывая движения по заказу, которые могут быть выполнены другими документами. И все. Увидеть истинное состояние заказа только отчетом соответствующим можно...
17 Злопчинский
 
17.09.21
10:42
В Унф реализована мудачно идея из документа сделать АРМ. Например, в заказе покупателя ты можешь включить глаз и увидеть обеспечение - появляются допколонки. И все бы хорошо, но по этим колонкаи ты нихрена не можешь отсортировать - и вот идет у тебя заказ на пару сотен строк, а обеспечение по строкам вразнобой - где-то полностью обеспечено, где-то частично, где-то необеспечено - и все, кабздец, упорядочить по обеспечению никак...
18 Злопчинский
 
17.09.21
10:45
Про отчеты я уже писал. По умолчанию в отчетах нет ни кода товара, ни артикула. Нет даже опции такой в настройках (это даже в тис есть). Сиди и в каждом отчете через скд настраивай...
19 Злопчинский
 
17.09.21
10:50
Если говорить коротко - программа изначально для ларьков делалась. Обросла возможностями, но "село так и прет"
20 Злопчинский
 
17.09.21
10:58
Про два разных ТНВЭДа в карточке я уже писал.
По ошибкам и несуразностям видно, что коммуникации в команде разработки - на очень низком уровне, правая нога не знает что делает левая. Даже разброд и шатание в терминологии. Например, в разных местах то группа, то родитель, то папка... Взаимосвязи и структуру данных разрабы представляют кусочно-отрывочно, из свежего: в структуре подчинённости вы нихрена не увидите относящиеся к заказу документы корректировки тех же самых взаиморасчетов. И такой всякой хрени много, пишу на форум разрабов, ошибок с десяток зарегали. И это при том, что я только по верхам лазаю, как пользователь...
21 Смотрящий
 
17.09.21
11:55
(13) Заказ уже исполнили полностью, бп закрылся; и тут возникает отклонение в виде возврата.
Причина, возврата не важна, брак там или просто договорились; по уму надо приходовать
возвращаемый товар не трогая цепочки заказов, а взаиморасчеты вещать на заказ по которому возврат чтоб было видно сразу где "переплата" возникает.
22 Злопчинский
 
17.09.21
17:09
(21) да, такой вариант - я упоминал его выше - реализовать вообще в коде совсем малость подправить. И в большинстве случаев так будет норм. Но не во всех сделках, часть сделок будут по типу допоставки недогруза из-за возвратов. Городить новую сделку с перекидыванием на неё переплаты может быть некомильфо.
Но предложенная схема в большинстве случаев мне кажется более удобной.
Есть два вида языков, одни постоянно ругают, а вторыми никто не пользуется.