док оплаты введен на основании Заявки покупателя.

Отказался покуп-ль, деньги надо вернуть
и тоже через Банк (строкой выписка Банка (расход)).

Штатно, на основании ЗаявкиПокупателя нельзя оформить возврат денег, док СтрокаВыпискиБанка(расход) в списке отсутствует..

Нет проблем сделать в конфе ввод на основании, но вот что меня волнует: Может быть возврат д/с на основании Заявки - нарушение какого-нибудь ПБУ?
отсутствует также и РКО на основании ЗаявкиПок-ля..
ведь разработчики 1с вроде ничего просто так не делают?...
или я не прав?
или уж пойти навстречу директору-моему заказчику хотелок?
он выражал такое желание, пополам с недоумением.. Логично, смотреть в журнале на Заявку и оформить возврат д/с простым жмаканьем..

даже если сделаешь ввод на оснвоании - придется глДвижениеДолгов переписывать. если это раз в полгода происходит - лучше сделай сторно на основании оплаты нужной датой (датой возврата денег) дешево и сердито!

(1) спасибо! это, кажется, то, что и надо..

ЗЫ. всё, отбой проблеме :)

Заявка покупателя с точки зрения БУ пипифакс. Пофиг что ты введешь на ее основании. Или не введешь.

(3) это понятно.. :)
БУ и торговля в этом смысле кой-где и не пересекаются

(0) Читай Джинна. правильно говорит. Просто не привязываясь ни к чему оформи движение денег по банку с нужным видом платежа. главное - пусти ее по тому же договору, по которому пришла(заявка)

(5) в типовой ТиС не взлетит.

(6) что именно не взлетит? Строка вписки расход с видом оплаты =  "возврат покупателю"?

(7) в общем случае - не взлетит. дело в том что в глДвиженииДолгов не заложены (специально или нет?) два момента:
1. при проведении доков по взаиморасчетам не учитываются основания доков
2. при проведении операций "возврат покупателю/поставщику" учитываются только остатки долгов по регистру на момент проведения дока.

т.о. указанная операция проведется типовой ТиС корректно только, если в рамках нашего покупателя/договора не было неоплаченных долгов по другим отгрузкам, и не было других предоплат в рамках других заявок.

(5) - да, я прочел  Джинн"а..
идея его вполне имеет право жить.
только в моем случае одно немного не катит: диру нужно видеть картину СРАЗУ по конкретным Счетам, отчеты ему 100 лет не нужны.. не любит он большинство из них.

на журналах состояние документов отражается цветными пиктограммами:
http://s016.radikal.ru/i334/1010/ba/c915aaac123c.jpg

потому желательна цепочка документов, начало которой - Счет, и именно она определяет состояние - пиктограмму в журнале

дир энергично проинструктирован, и вполне одобряет решение.

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

Спасибо, ребята за советы!

(8)
по п.1 - читай мою статью на ИС почему не ведется учет по основаниям доков.
по п.2 - не понял, но думаю что все нормально проведется. сформулируй ситуевину проблемную - готов тренирнуть...

(9) если а)дисциплина ведения учетаплатежей высокая. б) люди очень вменяемые - то можно сделать все с минимальной "кровью". Но я не видел чтобы а и б было...

а вся эта "оплата" счетво в итоге банально сводится к оплат по последнему выставленному счету.

(10) выписали контру заявку1, контр сделал оплату1, затем (без отгрузки по заявке1) выписали еще заявку2, контр сделал оплату2. потом контр отказывается от заявки2 и требует вернуть оплату2. при вводе возврата оплаты2 в первую очередь будет закрываться аванс по оплате1, а не по оплате2.
или вот еще:
контру выписали заявку1 на 500 руб. и накл1(со сроком оплаты ч/з 30 лней например) на 500 руб., затем, через три дня например, без оплаты накл1 - заявку2(читай - счет) на 50000 руб., на основании которой контр сделал оплату2 на 50000 руб.
потом контр отказывается от своей заявки2 и требует вернуть ему 50000 руб., т.к. срок оплаты по накл1 еще не скоро, он ее потом оплатит, когда время подойдет. При оформлении возврата покупателю на 50000 руб. в итоге получим совсем не то распределение долгов по кред. документам, как подразумевает ситуация.

(11) согласен.. но дир - единственный пользователь, и вполне вменяемый.

ориентируется во всех аспектах предприятия свободно, и не ждет, что ему предложит типовая ТиС, а требует того, что ему надо.

думаю, обратили внимание, что заголовки журналов и наименования доков - не штатные..

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

с физиками покончено, теперь процентов 10 доработки под юриков..

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

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

(13) в РАМКАХ ОДНОГО ДОГОВОРА (т.е. совершенно одинаковых условий обслуживания сделок) закрывается первая незакрытая проблем. так что если идет возвра оплаты - то можно считать логичным что идет погашение первого "незакрытого" документа. - первой оплаты. никаких противоречий не вижу.

(15) спасибо, хороший вариант..

(15) данная технология описана у меня упомянутой статье. а с учетом возратов товаров, взаимозачетов и т.д. - такая ситуация разваливается точно-так же как и прочие - и не соответвует "ожиданиям" бухгалтеров...

http://www.infostart.ru/public/16225/

(15) сторно - это сторно... ;-)

(19) не-а, не разваливается, если все продумать, и если доки разнесены с чувством, толком, расстановкой ;)

(17) не согласен. у нас, например, бывают ситуации, когда контра уговорили взять какой-нить неликвид, так у него срок оплаты по накл например 14 дн, а неликвид ему могут и со сроком 60 дать. при оплате он сошлется на накл., а типовка ТиС закроет по хронологии. удобно для бухов, но неудобно для продвинутых диров, таких как у автора.

(21) а вот с этим согласен полностью, я это еще в (1) сказал.

(22) да не вопрос, я тоже такого мнения.
(23) в данной ситуевине в штатной ТиСе надо разносить по разным "договорам" - не надо никаких правок кодов и все делается штатно. но это же надо как в(22) аккуратно, с чувством и расстановкой сажать платеж на нужный договор...
.
частные случаи, когда тебе удалось "построить" и обеспечить дисциплину ведения учета - не обсуждаем. у теюя докручено в штатной - и все сходится, юзеры делают., у мен яничего не докручено - юзерам выносится мозг - тоже все сходится...
.
а в условиях когда ни ты, ни я не будем стоять над "душой" и регулярно отслеживать проблемные моменты - что чтовя что моя система очень быстро ДЕГРАДИРУЮТ к самой простой не требующей никаких затрат системе , которая называется "КУЧА"

(25) согласен, без присмотра все быстро падает, но это уже не вина алгоритмов/конфы/учета, а вина управленцев. Потому как в солидной, уважающей себя конторе присмотр быть должен.

(26) стопудово! просто у нас все упирается в типовую ситуацию? интересно только "сейчас" (короткие деньги). подавляющее большинство не готов работать на длинном плече.. соответсвенно какое-то сильное планирование, пордяок и прочее - не особо и востребовано...