v7: Ведомость по контрагентам #614464


#0 by bug16
Здравствуйте! Имеется конфигурация Торговля и склад. Возник следующий вопрос. Допустим есть несколько документов реализации от одного контрагента 1ый документ на сумма 300р 2ой документ на сумму 400р 3ий документ на сумму 500р. Покупатель допустим хочет закрыть/оплатить 2ой документ, тот который на 400р. Заводим документ приходный кассовый ордер, на основании 2ого документа реализации. Делает отчет ведомость по контрагентам, и получается что документом ПКО, мы перекрываем 1ый документ который на 300р. А правильнее то надо, чтобы он показал, что мы перекрыли/оплатили 2ой документ.... Или все таки я не правильно понимаю логику?
#1 by Ёпрст
в типовых всегда списывается по фифо, в не зависимости от документа-основания. Хочешь по-другому , переписывай.
#2 by ДенисЧ
А разве в тисе ведётся учет расчетов в разрезе документов?
#3 by Ёпрст
в разрезе КредДокумента - да.
#4 by bug16
а что такое фифо? может есть у кого отчет такой переписанный/переделанный ?
#5 by povar
судя по вопросу, вы бухгалтер...
#6 by bug16
ну даже если так, что от этого меняется? )) пусть буду для Вас, начинающий программист-бухгалтер...
#7 by Ёпрст
там делов то - одну табличку значений сортировать в "немножко" другом порядке и привет. Чебур вроде тоже занимался изысканиями на инфостарте по этому поводу - есть его статейка тама.
#8 by Злопчинский
читаем здесь:
#9 by Злопчинский
вот она.
#10 by Злопчинский
но! не поможет по большому счету. . если атор не понимает что при абсолютно равных условиях отгрузок нет никакого резона гасить их платежами на конкретные сделки - потому что при равных услвоиях отгрузок единственный логичный способ погашения по фифо. . если условия отгрузок НЕРАВНЫЕ (например часть отгрузок на отсрочку 10 дней, часть на 45 дней) - то следует завести ДВА ДОВГОВОРА - каждый из которых и будет отражать что отношения с клиентом идут в разрезе разных условий. и соответсвенно платежи разносить именно ТУДА КУДА ОНИ ПРЕДНАЗАНЧЕНЫ. . крайним вырожденным вариантом двух договоров является когда каждая ОТГРУЗКА = ОТДЕЛЬНЫЙ ДОГОВОР/СДЕЛКА (в случае предоплатников все стартует с акцептовки счета). . если автору надо - то делать можно тупо без всякого программирования. и вес будет работать как надо. если конечно автор СПОСОБЕН ВЕСТИ АККУРАТНЫЙ УЧЕТ ПЛАТЕЖЕЙ. . открываем карточку клиента. открываем для него список договоров. заводим !!!ГРУППУ!!1 называем типа "Договор купли-продажи №007 от 01.04.12" на каждую отгрузку/предоплату заводим "договор" типа "Реализацяи 0001" или "Счет 00050" - и вся СДЕЛКА оформляется по этому договору, в т.ч. и ПЛАТЕЖИ относятся на каждую сделку. . в результате - имеем то что хочет автор. куда он будет девать недоплаты/переплаты по таким договорам - это его личное горе/геморроой. . в описанной схеме для пользователя единственное неудобство - вводить каждый раз новые "договора" - это автоматизировать гораздо легче чем переписывать отчеты и извращаться - одной кнопки для генерации нового "договора" будет достаточно. . кардинально предупреждаю автора - неоднократно имел опыт и автоматизацию по типу хотелки в . в результате у клиента в процессе работы вырождается в две варианта: - все идет "в кучу" - ибо - СМ,СТАТЬЮ. - клиент начинает допиывать/программить отчеты, которые отражают взаиморасчеты по хотелкам клиентов. в итоге имеем параллельно штатной системе взаиморасчетов по фифо кривую и глючную систему взаиморасчетов по хотелкам клиента - ибо а) клиент не может сформулировать что ему надо б) см.статью в) пишут такую парарлельную систему криворукие отморозки спустя рукава. . в то время как хотелка клиент ареализуется типовой схемой "каждая отгрузка = отдельный договор" + пару мелких дописок для удобства ввода и разноски платежей на каждую сделку. . все. . включите уже кто в книгу знаний, ибо затрахался писать каждый раз.
#11 by Злопчинский
причина также может быть в непроходимой тупости и мудосранстве. зачастую клиенту отгружается на равных условиях, но гасить он хочет по конкретным сделкам. При этом ни у криворуких пляавтоматизаторов и прочих чмододятлов не хватает ума поговорить с клиентом внятно - ибо и клиент невнятны - это прощаемо - но и программисты хреновы такие же невнятные. продолжаю? а клиент хочет гасить выборочно только потому что таким образом он ведет "свой" учет. наши отгрузки у него уходят на разные точки - и гасит совй долг он деньгами конкретных точек, имея таким образом у себя вполне понятный ему учет в разрезе "отгрузки от поставщика - продажи по точкам". И в этом случае вполне достаточно сделать "субдоговора", эквтивалентыне точкам клиента и отгрузки пускать в разрезе точек. . описан всего лишь один из вариантов, когда казалось бы одинаковые услвоия отгрузок должны интепретироваться по разному. других таких вариантов - еще может быьть.. надо всего лишь РАБОТАТЬ ВКАЛЫВАТЬ И ПАХАТЬ, мударасы хреновы. . злой я. . потому что все что ОНИ делают руками - все криво. а запрограммить всю возможную кривизну - невозможно. акромя как дт слева кт справ - вводите как хотите.. но при этом еще хотят шоколадку. . уроды.
#12 by yam
Решение на инфостарте методологически неверное, т.к. допускает разнообразные ошибки по закрытию накладных. Тут конечно полностью согласен.
#13 by bug16
ухххх как накипело у Вас :) не будем наверное делать такого тогда! спасибо за разъяснения!
#14 by Любопытная
Если вам тупо крыжить неудобно, вытащите док основание для документа расчетов в отчет и все станет видно
#15 by Злопчинский
в этом случае типовое решение по фифо - точно такое же неверное, т.к. совершенно так же допускает разнообразные ошибки по закрытию накладных. . с интересом послушаю, каким образом упомянутое решение допускает разнообразные ошибки и какие именно? (ясен пень, что если обвесить всякими защитами и статусами возврата при нарушении нарисованнйо схемы - то будет гораздо устойчивее..). исходим из того, что юзверь - вменяемый, в платежках указаны конкретные доки оплаты, взаимозачеты относятся на конкретные док, ввод документов строго по хронологии.
#16 by Злопчинский
не делать надо не из-за того, что уменя накипело, а потому что вы сочли приведенные доводы вескими.. или наоборот...
#17 by Злопчинский
и чем это поможет? - поможет только в том случае если платеж и док основание = 1 в 1, в остальных случаях скатываемся см.выше... в построение своего отчетра по взаиморасчетам дубля основногог...
#18 by bug16
если у них идет оплата тютелька в тютельку (т.е. полная оплата, без частичной оплаты/переплаты, и без всяких возвратов), то в этом случаи и Ваш метод должен работать нормально...
#19 by Злопчинский
если я такое увижу - я умоюсь счастливыми слезами.
Тэги: 1С 7.7 и ранее
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С