Взаиморасчеты по договору в целом или по заказам, отслеживание задолженности.
Здравствуйте!
Есть база на УТ 10.3, ведется с 01.01.12 (ввод остатков), оптовые покупатели, в основном работа от заказа. Сейчас способ ведения взаиморасчетов в договорах покупателей "По договору в целом", нужно отслеживать сроки задолженности. Существующие в УТ 10.3 отчеты не удовлетворяют.
Например, отчет по деб. задолженности по срокам не учитывает оплату, видимо, из-за отсутствия в регистре Взаиморасчеты по документам расчета правильно заполненного реквизита Документ расчетов - в Платежном Поручении Входящем указан оплачиваемый заказ, но в регистре поле Сделка не заполняется, а поле Документ расчета содержит ссылку на саму платежку.
Сейчас пытаюсь понять, как лучше сделать, вижу два варианта:
1. Изменить ведение взаиморасчетов по договорам с покупателями на "По заказам", перепровести документы с 01.01.12
2. Сделать автоматическое распределение поступающих денег на конкретные документы реализации или заказа по ФИФО
Склоняюсь к первому варианту, немного прибавит работы при разноске банка.
Поделитесь, пожалуйста, опытом по этому вопросу.
Есть база на УТ 10.3, ведется с 01.01.12 (ввод остатков), оптовые покупатели, в основном работа от заказа. Сейчас способ ведения взаиморасчетов в договорах покупателей "По договору в целом", нужно отслеживать сроки задолженности. Существующие в УТ 10.3 отчеты не удовлетворяют.
Например, отчет по деб. задолженности по срокам не учитывает оплату, видимо, из-за отсутствия в регистре Взаиморасчеты по документам расчета правильно заполненного реквизита Документ расчетов - в Платежном Поручении Входящем указан оплачиваемый заказ, но в регистре поле Сделка не заполняется, а поле Документ расчета содержит ссылку на саму платежку.
Сейчас пытаюсь понять, как лучше сделать, вижу два варианта:
1. Изменить ведение взаиморасчетов по договорам с покупателями на "По заказам", перепровести документы с 01.01.12
2. Сделать автоматическое распределение поступающих денег на конкретные документы реализации или заказа по ФИФО
Склоняюсь к первому варианту, немного прибавит работы при разноске банка.
Поделитесь, пожалуйста, опытом по этому вопросу.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) изучаю тот же вопрос, промежуточный вывод пока такой - надо в платежках делать заполнение сделок (заказов) максимально автоматическим и выбрать один отчет, которым будут пользоваться все. Продавцы ведь отслеживают дебиторку и сверяют ее с клиентами, каким отчетом они пользуются? Клиент на своей стороне тоже как-то это ведет, все расхождения быстро станут известны, так что этот отчет можно будет привести к канонически правильному результату и им пользоваться дальше. А остальные отчеты похерить, они все разные.\
У нас тут пока используется отчет "по кредитной линии", вроде он ничего так, работает.
У нас тут пока используется отчет "по кредитной линии", вроде он ничего так, работает.
(7) starjevschik, есть еще вариант.
В случае оптовой торговли разноску платежей частично можно отдать менеджерам по продаже. Бухгалтер загружает данные из клиент-банка, создает и проводит входящие платежки, где может - привязывает заказ и док. расчетов. Дальше менеджеры открывают обработку, которая позволяет им не изменяя общую сумму каждой платежки, выбрать заказы контрагента (того же, что в платежке) и распределить по ним сумму платежа. Обработка меняет таблицу расшифровки платежа в ППВ, при этом контролируя общую сумму и не давая менять контрагента и договор.
У меня есть такая обработка под УТ 10.2, могу выложить.
В случае оптовой торговли разноску платежей частично можно отдать менеджерам по продаже. Бухгалтер загружает данные из клиент-банка, создает и проводит входящие платежки, где может - привязывает заказ и док. расчетов. Дальше менеджеры открывают обработку, которая позволяет им не изменяя общую сумму каждой платежки, выбрать заказы контрагента (того же, что в платежке) и распределить по ним сумму платежа. Обработка меняет таблицу расшифровки платежа в ППВ, при этом контролируя общую сумму и не давая менять контрагента и договор.
У меня есть такая обработка под УТ 10.2, могу выложить.
(8) у нас примерно так и происходит. С отчетами беда в том, что они все показывают разные результаты. Я думаю, раз уж манагеры сверяются с клиентами по этому отчету, то будем считать его верным и все.
Попробую сейчас еще посмотреть этот тоже, вдруг с чем-нибудь да сойдется.
ЗЫ посмотрел - этот отчет сходится с отчетом "ведомость по взаиморасчетам" и не сходится с отчетом по кредитной линии. Причем по документам вроде выглядит правильно. Хз что делать :)
Попробую сейчас еще посмотреть этот тоже, вдруг с чем-нибудь да сойдется.
ЗЫ посмотрел - этот отчет сходится с отчетом "ведомость по взаиморасчетам" и не сходится с отчетом по кредитной линии. Причем по документам вроде выглядит правильно. Хз что делать :)
(7) starjevschik, все стандартные отчеты в УТ 10.3 по дебиторской задолженности - полная фигня, к сожалению. Когда я увидел, что отчет по срокам долга не учитывает отсрочку из договора, слегка обалдел. Отчет по кредитной линии тоже куций. Более-менее нормальный отчет есть здесь,
(11) Diego_Iv, мне вариант (9) jack_kkm больше понравился, хотя он тоже не без недостатков.
По итогам они не сходятся, хотя несколько клиентов я проверил - вроде в обоих правильно и в ведомости по взаиморасчетам тоже так же по этим клиентам, по общим итогам они все разные.
По итогам они не сходятся, хотя несколько клиентов я проверил - вроде в обоих правильно и в ведомости по взаиморасчетам тоже так же по этим клиентам, по общим итогам они все разные.
(13) starjevschik,
Может быть и лучше.
Я с конфигурацией УПП работаю, в ней эти отчеты открылись с ошибкой
(какая-то мелочь с "Текущий пользователь"...)
А исправить ее не могу, так на модуле пароль стоит.
Поэтому пришлось удалить их и поверить Вам на слово :-)
Может быть и лучше.
Я с конфигурацией УПП работаю, в ней эти отчеты открылись с ошибкой
(какая-то мелочь с "Текущий пользователь"...)
А исправить ее не могу, так на модуле пароль стоит.
Поэтому пришлось удалить их и поверить Вам на слово :-)
Поищите на Инфостате , есть класный отчет по отслеживанию задолженности , который формируется по документам , а не по регистру взаиморасчеты , с отчетами по регистрам взаиморасчетов , есть проблемы , обусловленные архитектурой этого регистра , например - корректировка долга в этот отчет не попадает.
корректировка долга в этот отчет не попадает.
Имеется в виду, в регистр Взаиморасчеты по документам? Спасибо, буду иметь в виду.
Интересно, как в большинстве случаев ведутся расчеты, по договорам в целом, по заказам или по счетам?
Имеется в виду, в регистр Взаиморасчеты по документам? Спасибо, буду иметь в виду.
Интересно, как в большинстве случаев ведутся расчеты, по договорам в целом, по заказам или по счетам?
Чтобы взаиморасчеты велись по документам расчетов - надо не способ ведения договора менять, а ставить галочку
ведение документов по документам расчетов.
ну и соответственно в документах нужно заполнять документа расчетов по контрагентам.
Механизм подбора там сделал, но мне пришлось дорабатывать его, чтоб заполнялось все автоматически, потому что следить за этим бухгалтерия отказалась, это слишком муторно.
Вообще перелопатил весь механизм под подбор документов расчетов по фифо при проведении, с обязательным восстановлением последовательности.
ведение документов по документам расчетов.
ну и соответственно в документах нужно заполнять документа расчетов по контрагентам.
Механизм подбора там сделал, но мне пришлось дорабатывать его, чтоб заполнялось все автоматически, потому что следить за этим бухгалтерия отказалась, это слишком муторно.
Вообще перелопатил весь механизм под подбор документов расчетов по фифо при проведении, с обязательным восстановлением последовательности.
(4) Lokiy, разницу между "вести расчеты по документам" и "ведение взаиморасчетов по договору в целом/по заказам" я понимаю. Сейчас для всех договоров включено ведение расчетов по документам. Но при анализе регистра Расчеты по документам даже вручную не могу связать концы с концами. Скачанные с инфостарта отчеты показывают среди документов с задолженностью такие документы, как ПКО и ППВ, их там быть не должно. Смотрю, откуда они, вижу их в поле Документ расчета.
Плюс отчета, что при вводе документов оплаты вообще не надо разносить оплату по документам.
Просрочка будет зависеть только от срока документа реализации, а не от того как бухгалтер разнес оплату
по этим документам.
У всех договоров стоит ведение взаиморасчетов по договору в целом.
В конфигураторе только немного подправить надо форму элемента для справочника "Договор".
Там сделано так, что галка "Контролировать число дней задолженности" привязана к галке "По документам расчетов с контрагентами". Т.к. контроль сроков в типовой 1С привязан к регистру "по документам расчетов".
Но просрочку можно считать и по обычному регистру взаиморасчтетов, поэтому можно закомментировать пару строк в
коде модуля формы, чтобы эта первая галка была видна всегда.
ЕМНИП это делается там в процедуре "Установить видимость".
Просрочка будет зависеть только от срока документа реализации, а не от того как бухгалтер разнес оплату
по этим документам.
У всех договоров стоит ведение взаиморасчетов по договору в целом.
В конфигураторе только немного подправить надо форму элемента для справочника "Договор".
Там сделано так, что галка "Контролировать число дней задолженности" привязана к галке "По документам расчетов с контрагентами". Т.к. контроль сроков в типовой 1С привязан к регистру "по документам расчетов".
Но просрочку можно считать и по обычному регистру взаиморасчтетов, поэтому можно закомментировать пару строк в
коде модуля формы, чтобы эта первая галка была видна всегда.
ЕМНИП это делается там в процедуре "Установить видимость".
(22) jack_kkm, если у тебя стоит галка по документам расчета - то аванс ввести невозможно т.к. при авансе не существует еще расчетного документа.
Это реально косяк , который 1с-ки на партнерском форуме не хотят признавать. у них логика такая - если по докам расчетов то должны быть расчеты , иначе - галку снять. -)
так что тут нужно дорабатывать.
Это реально косяк , который 1с-ки на партнерском форуме не хотят признавать. у них логика такая - если по докам расчетов то должны быть расчеты , иначе - галку снять. -)
так что тут нужно дорабатывать.
Самый простой и надежный путь борьбы с просроченной и рисковой дебиторской задолженностью - не допускать ее. Эта истина стара и банальна, однако о ней часто забывают, что приводит к самым значительным потерям.
Неоплаченные отгрузки возникают, как правило, по двум причинам. Первая - это стремление руководства выполнить план продаж любой ценой, не думая о последствиях. Сэйлз-менеджеры получают от собственников или первых лиц компании команду "отгружать", и в пылу желания продать больше многие из продавцов забывают о том, что долги их клиентов нужно возвращать. В результате такого поведения образуется просроченная дебиторская задолженность. Вторая причина - неэффективная система мотивации, не связанная с возвратом "дебиторки" и не стимулирующая продавцов к работе с должниками. Типичным примером может послужить система премирования, при которой менеджерам выплачивают бонус от суммы заключенной сделки вне зависимости от того, когда ее реально оплатит покупатель.
Неоплаченные отгрузки возникают, как правило, по двум причинам. Первая - это стремление руководства выполнить план продаж любой ценой, не думая о последствиях. Сэйлз-менеджеры получают от собственников или первых лиц компании команду "отгружать", и в пылу желания продать больше многие из продавцов забывают о том, что долги их клиентов нужно возвращать. В результате такого поведения образуется просроченная дебиторская задолженность. Вторая причина - неэффективная система мотивации, не связанная с возвратом "дебиторки" и не стимулирующая продавцов к работе с должниками. Типичным примером может послужить система премирования, при которой менеджерам выплачивают бонус от суммы заключенной сделки вне зависимости от того, когда ее реально оплатит покупатель.
(18) oleglg,
//Самый простой и надежный путь борьбы с просроченной и рисковой дебиторской задолженностью - не допускать ее. Эта истина стара и банальна, однако о ней часто забывают, что приводит к самым значительным потерям. //
Тут в основном общаются те, кто непосредственно занимается учетом (бухглатера, экономисты) и те, кто его старается им облегчить (программисты).
И это не они принимают решения такого уровня: с завтрашнего дня работаем только по предоплате, т.к. мне лень отслеживать всякую просроченную задолженность :-)
//Самый простой и надежный путь борьбы с просроченной и рисковой дебиторской задолженностью - не допускать ее. Эта истина стара и банальна, однако о ней часто забывают, что приводит к самым значительным потерям. //
Тут в основном общаются те, кто непосредственно занимается учетом (бухглатера, экономисты) и те, кто его старается им облегчить (программисты).
И это не они принимают решения такого уровня: с завтрашнего дня работаем только по предоплате, т.к. мне лень отслеживать всякую просроченную задолженность :-)
Дебиторка была есть и будет есть -) это реалии экономики.
никуда от нее никто не уйдет (исключений - единицы - и это очень специфические организации).
Причина - конкуренция -) ты не дашь отсрочку даст другой -) от это реалии экономики.
Окромя того всем выгодно прокрутить бабосы у себя подольше, это опять же рыночная экономика -)
практически согласен с Diego_Iv.
никуда от нее никто не уйдет (исключений - единицы - и это очень специфические организации).
Причина - конкуренция -) ты не дашь отсрочку даст другой -) от это реалии экономики.
Окромя того всем выгодно прокрутить бабосы у себя подольше, это опять же рыночная экономика -)
практически согласен с Diego_Iv.
он нужен для указания начального долга при вводе остатков , а не при оформлении аванса.
так что не катит, у тебя регистр не закроется.
т.е. если у тебя есть отгрузки - и тебе нужно закрыть оплату он подойдет , а не в обратную сторону.
так что не катит, у тебя регистр не закроется.
т.е. если у тебя есть отгрузки - и тебе нужно закрыть оплату он подойдет , а не в обратную сторону.
Аванс запишет в реквизит ДокументРасчета ссылку на себя. При реализации можно заполнить вкладку Предоплата, тогда реализация сделает запись по документам расчета, ссылаясь в поле ДокументРасчета на документ, сформировавший аванс. Т.е. ППВ (или ПКО) пишет в рег. Расчеты по документам ссылку на себя, реализация пишет ссылку на то же самое ППВ.
Регистр закроется.
Документ расчетов теоретически подойдет для аванса, но на практике это не удобно и не логично.
Регистр закроется.
Документ расчетов теоретически подойдет для аванса, но на практике это не удобно и не логично.
Действительно если ставить по договору в целом, и галочку вести расчеты по документам расчетов, все нормально показывает долг и сроки долга, другое дело что это очень муторно ставить это да. Но у меня бухи ставят и в принципе нормально. Ничего переписывать не пришлось. единственная проблема была что использовал поле ответсвенный в документах реализации для указания торговых агентов, а в документах ввода остатков, долг по каждому агенту не ввели поэтому по агентам первые 2 месяца не смогли смотреть долги, но сейчас все удобно смотрится и все типовые отчеты работают
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот