#0
by bug16
Здравствуйте! Имеется конфигурация Торговля и склад. Возник следующий вопрос. Допустим есть несколько документов реализации от одного контрагента 1ый документ на сумма 300р 2ой документ на сумму 400р 3ий документ на сумму 500р. Покупатель допустим хочет закрыть/оплатить 2ой документ, тот который на 400р. Заводим документ приходный кассовый ордер, на основании 2ого документа реализации. Делает отчет ведомость по контрагентам, и получается что документом ПКО, мы перекрываем 1ый документ который на 300р. А правильнее то надо, чтобы он показал, что мы перекрыли/оплатили 2ой документ.... Или все таки я не правильно понимаю логику?
#1
by Ёпрст
в типовых всегда списывается по фифо, в не зависимости от документа-основания. Хочешь по-другому , переписывай.
#6
by bug16
ну даже если так, что от этого меняется? )) пусть буду для Вас, начинающий программист-бухгалтер...
#7
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
если у них идет оплата тютелька в тютельку (т.е. полная оплата, без частичной оплаты/переплаты, и без всяких возвратов), то в этом случаи и Ваш метод должен работать нормально...
Тэги: 1С 7.7 и ранее
Ответить:
Комментарии доступны только авторизированным пользователям
Похожие вопросы 1С
- v7: v7 : НДС при возврате
- v7: Что нужно чтоб подключить ККМ Меркурий 112F к 1с V7 Торговля + склад
- v7: v7.7 премещение элемента справочника
- v7: v8: v7: Кто-нибудь сумел скачать комплект отчетности за I квартал 2007 года
- v7: 1С V7.7 в сети
- v7: Комплексная. Ведомость по контрагентам. Показывает не правильную сумму.
- v7: 1C:V7 starter program (for SQL) - обнаружена ошибка
- v7: Перенос данных Бухгалтерия из v7 в v8
- v7: ведомость по контрагентам не правильно формируется, почему?
- Ведомость по остаткам ТМЦ 1С V7.7
- v7: v7 Перехват глобального события ПриЗаписи() или ОбработкаПроведения()
- v7: Ведомость по контрагентам - фильтр по проектам.
В этой группе 1С
- Слишком много фактических параметров
- СКД вывод группировок по условию
- Запуск веб-клиента с параметрами запуска
- Управляемая форма заказа покупателя в УПП 1.3
- Зочет аванса в РТиУ, Комплексная автоматизация 1.1
- Не устанавливается пароль в конфигураторе на конфигурацию
- УТ 10.3 себестоимость
- v7: свернуть таблицу значений
- УФ: не появляется кнопка "перейти" для просмотра движений
- Перевод сканеров в режим эмуляции клавиатуры
- 1С УПП Как из общего модуля вызвать функцию другого модуля?
- Что такое КоличествоРазвернутыйОстатокДт?
- УТ11 - Ошибка в таблице AccumRg4641
- условие в запросе на вхождение в ТЗ
- Дата запрета изменения данных в УТ 11
- Передать отборы и настройки из одного Построителя Отчета в другой
- Передать таблицу значений в СКД
- ЗУП 2.5.51.1 - 2НДФЛ в ИФНС - Перечислено не равно Удержано
- Какой фискальный регистратор лучше?
- Конвертация данных