По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Как это оформить в программе?
Есть ли какие-нибудь печатные формы договора рассрочки с покупателем?
Может ли программа расчитать платежи покупателя, например, на 3 месяца, на 6 месяцев?
Может ли программа напоминать о просрочке платежа?
==============
Ну хватит, наверное, пока вопросов.
Есть ли какие-нибудь печатные формы договора рассрочки с покупателем?
Может ли программа расчитать платежи покупателя, например, на 3 месяца, на 6 месяцев?
Может ли программа напоминать о просрочке платежа?
==============
Ну хватит, наверное, пока вопросов.
(3) NE_ZNAIY,
Заводим контрагента "Физлицо" (обычно рознице не требуется прямая персонификация покупателей отдельными контрагентами). У него - договор с покупателем "Предзаказ/рассрочка". Способ ведения взаиморасчетов - "По заказам". Далее делаем на этот договор документ "Заказ покупателя", указываем состав приобретения. Далее, в момент продажи делаем на основании "Реализацию", в момент оплаты - "Приходный кассовый ордер", "Оплата платежной картой".
Если человеку вернули деньги, то "Расходный кассовый ордер".
В комментарий заказа пишем контактный телефон и ФИО покупателя.
Отчеты "Ведомость по заказам покупателей", "Анализ заказов покупателей", "Ведомость по расчетам с контрагентами" позволяют отконтролировать полноту отгрузки, оплаты по каждому заказу.
Можно брать предоплату под заказ, можно отгружать с рассрочкой, можно использовать любую смешанную схему.
Заводим контрагента "Физлицо" (обычно рознице не требуется прямая персонификация покупателей отдельными контрагентами). У него - договор с покупателем "Предзаказ/рассрочка". Способ ведения взаиморасчетов - "По заказам". Далее делаем на этот договор документ "Заказ покупателя", указываем состав приобретения. Далее, в момент продажи делаем на основании "Реализацию", в момент оплаты - "Приходный кассовый ордер", "Оплата платежной картой".
Если человеку вернули деньги, то "Расходный кассовый ордер".
В комментарий заказа пишем контактный телефон и ФИО покупателя.
Отчеты "Ведомость по заказам покупателей", "Анализ заказов покупателей", "Ведомость по расчетам с контрагентами" позволяют отконтролировать полноту отгрузки, оплаты по каждому заказу.
Можно брать предоплату под заказ, можно отгружать с рассрочкой, можно использовать любую смешанную схему.
Заводите покупателя как контрагента, создавайте ему договор рассрочки, взаиморасчеты - по договору. Оформляйте обычную реализацию, вносите оплату приходным ордером. Потом отслеживайте долги с помощью отчета Взаиморасчеты с контрагентами, вносите остающиеся оплаты приходными ордерами. Это вручную все делать. Если хочется автоматизации - нанимайте программиста.
И еще. Вы понимаете, что рассрочку вы можете сделать только от суммы товара? Никакие проценты начислять не можете.
И еще. Вы понимаете, что рассрочку вы можете сделать только от суммы товара? Никакие проценты начислять не можете.
Заводим контрагента "Физлицо" (обычно рознице не требуется прямая персонификация покупателей отдельными контрагентами)
Розница не требует, а вот в случае если покупатель решил забыть про свои долги в суд будете подавать на "физическое лицо"? А других документов у Вас нету.
В комментарий заказа пишем контактный телефон и ФИО покупателя.
Отчеты "Ведомость по заказам покупателей", "Анализ заказов покупателей", "Ведомость по расчетам с контрагентами" позволяют отконтролировать полноту отгрузки, оплаты по каждому заказу.
Можно брать предоплату под заказ, можно отгружать с рассрочкой, можно использовать любую смешанную схему.
Отчеты "Ведомость по заказам покупателей", "Анализ заказов покупателей", "Ведомость по расчетам с контрагентами" позволяют отконтролировать полноту отгрузки, оплаты по каждому заказу.
Можно брать предоплату под заказ, можно отгружать с рассрочкой, можно использовать любую смешанную схему.
Угу, а если таких покупателей более 1, делающих покупку на 10т.р, и оплачивающих по графику платежей по 1 т.р. в месяц то поможет всемогущая тетрадка в клеточку?
Это для удобства контроля (отчетов) ?
По заказам, это типа чтобы разбить платежи нескольких покупателей под конкретную продажу, не заводя много контрагетов, в принципе можно и по документам расчета, позаказный учет удобней когда покупатель действительно что-то заказывает, а если пришел-увидел и купил заказ может даже и мешать, т.к. может невзначай завысить ваш заказ поставщику.
Четкого алгоритма нет, в любой торговле есть свои особенности, нужна полная схема со всеми "хотелками" и вариантами исполнения и неисполнения договорных условий.
(9) genna,
Полагаю, запись в УТ, что Петров - именно Петров, как контрагент, а не заказ №..... с комментарием "Петров 8920...", вряд ли как-то поможет отбить долги в суде.
Нужно заключать бумажный договор, что не лежит прямо в области автоматизации.
Но можно прикрутить к контрагенту (заказу) свойства типа "кто подписал", "где подписал", "реквизиты" и т.п., и сделать внешнюю печатную форму.
Непосредственно про график платежей именно в таком виде ТС ничего не спросил. Хотя можно автоматизировать тоже, все зависит от процесса взымания денег.
Так, как Вы сказали, я обычно делаю учет возвратов.
Для продаж, в принципе, Вы правы: если ТОЛЬКО рассрочка - то удобней по документам расчетов. Но обычно рассрочка идет бок о бок с заказом/предоплатой, а они - с резервами, и учить менеджера ЧЕТЫРЕМ схемам (заказ с пред/постоплатой, просто постоплата, просто розничная продажа через чек ККМ, возврат) сложнее, чем трем.
Плюс типовой отчет "Анализ заказов" работает только для схемы с заказами.
Розница не требует, а вот в случае если покупатель решил забыть про свои долги в суд будете подавать на "физическое лицо"? А других документов у Вас нету.
Полагаю, запись в УТ, что Петров - именно Петров, как контрагент, а не заказ №..... с комментарием "Петров 8920...", вряд ли как-то поможет отбить долги в суде.
Нужно заключать бумажный договор, что не лежит прямо в области автоматизации.
Но можно прикрутить к контрагенту (заказу) свойства типа "кто подписал", "где подписал", "реквизиты" и т.п., и сделать внешнюю печатную форму.
Угу, а если таких покупателей более 1, делающих покупку на 10т.р, и оплачивающих по графику платежей по 1 т.р. в месяц то поможет всемогущая тетрадка в клеточку?
Непосредственно про график платежей именно в таком виде ТС ничего не спросил. Хотя можно автоматизировать тоже, все зависит от процесса взымания денег.
По заказам, это типа чтобы разбить платежи нескольких покупателей под конкретную продажу, не заводя много контрагетов, в принципе можно и по документам расчета, позаказный учет удобней когда покупатель действительно что-то заказывает, а если пришел-увидел и купил заказ может даже и мешать, т.к. может невзначай завысить ваш заказ поставщику.
Так, как Вы сказали, я обычно делаю учет возвратов.
Для продаж, в принципе, Вы правы: если ТОЛЬКО рассрочка - то удобней по документам расчетов. Но обычно рассрочка идет бок о бок с заказом/предоплатой, а они - с резервами, и учить менеджера ЧЕТЫРЕМ схемам (заказ с пред/постоплатой, просто постоплата, просто розничная продажа через чек ККМ, возврат) сложнее, чем трем.
Плюс типовой отчет "Анализ заказов" работает только для схемы с заказами.
Полагаю, запись в УТ, что Петров - именно Петров, как контрагент, а не заказ №..... с комментарием "Петров 8920...", вряд ли как-то поможет отбить долги в суде.
Запись в УТ нет, не поможет, а вот накладная с верными реквизитами (ФИО, паспортными данными, адресом регистрации) и подписью клиента, а так же надлежащим образом оформленные платежные документы ПКО с кассовыми чеками, выписки банка (оплата по безналу) вполне будут надлежащими доказательствами, даже при отсутствии договора как такового, ведь розничная продажа подразумевает под собой договор в устной форме. В идеале конечно нужен и договор, чтобы уже наверняка не отвертелся.
(14) genna,
Согласен, но если речь идет о рознице, то у нас может быть несколько тысяч таких покупателей за год, и каждый придет не более 1 раза.
Смысл плодить сущности сверх необходимости? Эти же реквизиты можно держать в заказе и адаптировать печатную форму.
А можно вообще не держать: заполнение покупателем в бланке договора / накладной своих реквизитов от руки лишает нас обязанности получать согласие на обработку персональных данных по 152-ФЗ, обрабатывать надлежащим образом, и нести связанную с этим ответственность.
Запись в УТ нет, не поможет, а вот накладная с верными реквизитами (ФИО, паспортными данными, адресом регистрации) и подписью клиента,
Согласен, но если речь идет о рознице, то у нас может быть несколько тысяч таких покупателей за год, и каждый придет не более 1 раза.
Смысл плодить сущности сверх необходимости? Эти же реквизиты можно держать в заказе и адаптировать печатную форму.
А можно вообще не держать: заполнение покупателем в бланке договора / накладной своих реквизитов от руки лишает нас обязанности получать согласие на обработку персональных данных по 152-ФЗ, обрабатывать надлежащим образом, и нести связанную с этим ответственность.
(16) stvorl,
Конечно все зависит от специфики товара, но чаще всего это явное упущение.
Примеры:
Детский супермаркет, продали коляску в рассрочку, при оформлении договора покупатель поставил галочки о каких товарах, какой ценовой категории, информировать по смс, поступили новые кроватки - покупатель пусть не купил, но зашел посмотреть, купил что-то из сопутствующего товара.
Салон автомобилей, аналогично, поступили новые уникальные шины (либо акция - скидки на автошины), чехлы, и пр.пр.
Если бизнес направлен на продать и забыть, то этот бизнес уже отмирающий, т.к. не справится с конкурентами "заботящимися" о своих покупателях. Сейчас нужно продать так, чтобы человек либо сам вернулся, либо привел друзей.
Всего 1 абзац в договоре + место под дату и роспись.
и каждый придет не более 1 раза.
Конечно все зависит от специфики товара, но чаще всего это явное упущение.
Примеры:
Детский супермаркет, продали коляску в рассрочку, при оформлении договора покупатель поставил галочки о каких товарах, какой ценовой категории, информировать по смс, поступили новые кроватки - покупатель пусть не купил, но зашел посмотреть, купил что-то из сопутствующего товара.
Салон автомобилей, аналогично, поступили новые уникальные шины (либо акция - скидки на автошины), чехлы, и пр.пр.
Если бизнес направлен на продать и забыть, то этот бизнес уже отмирающий, т.к. не справится с конкурентами "заботящимися" о своих покупателях. Сейчас нужно продать так, чтобы человек либо сам вернулся, либо привел друзей.
лишает нас обязанности получать согласие на обработку персональных данных по 152-ФЗ, обрабатывать надлежащим образом, и нести связанную с этим ответственность.
Всего 1 абзац в договоре + место под дату и роспись.
(17) genna,
Касательно персонификации покупателей - в моем варианте их можно идентифицировать дисконтными картами, при этом выдавая покупателям реальный пластик (персональный, или обезличенный), или нет.
На этом пути надо быть аккуратным. Всего один абзац в договоре, а еще и исполнение обязанностей по защите персональных данных, конкретно относительно торговой точки, согласно ФЗ и куче подзаконных актов.
Я, честно, дилетант в этом вопросе. Клиентов отправляю к специально обученным людям. Но если вы начнете вместе с именем клиента собирать данные, например, о размерах ноги / росте / весе, то договоритесь до "медицинских данных, сведениях о здоровье и т.п.", что уже может потянуть на 1 группу защищенности. К которой особые требования. А если будете собирать их обезличено (без имен), то всего лишь к 4-й, к которой требования невелики.
Опять таки, насколько я помню, есть граничные критерии, по количеству хранимых субъектов, в 1, 1000 и 100000 человек, определяющие класс системы, что тоже влияет на группу защищенности.
И доколе под защиту ПДН у вас попадает только кадровая служба, в отношении ПДН ваших собственных сотрудников, к вам требования одни, а когда вы публично втаскиваете в это правовое поле ваших покупателей, то совсем другие; кроме того вы начинаете быть более заметнымии привлекать внимание санитаров.
Касательно персонификации покупателей - в моем варианте их можно идентифицировать дисконтными картами, при этом выдавая покупателям реальный пластик (персональный, или обезличенный), или нет.
Всего 1 абзац в договоре + место под дату и роспись.
На этом пути надо быть аккуратным. Всего один абзац в договоре, а еще и исполнение обязанностей по защите персональных данных, конкретно относительно торговой точки, согласно ФЗ и куче подзаконных актов.
Я, честно, дилетант в этом вопросе. Клиентов отправляю к специально обученным людям. Но если вы начнете вместе с именем клиента собирать данные, например, о размерах ноги / росте / весе, то договоритесь до "медицинских данных, сведениях о здоровье и т.п.", что уже может потянуть на 1 группу защищенности. К которой особые требования. А если будете собирать их обезличено (без имен), то всего лишь к 4-й, к которой требования невелики.
Опять таки, насколько я помню, есть граничные критерии, по количеству хранимых субъектов, в 1, 1000 и 100000 человек, определяющие класс системы, что тоже влияет на группу защищенности.
И доколе под защиту ПДН у вас попадает только кадровая служба, в отношении ПДН ваших собственных сотрудников, к вам требования одни, а когда вы публично втаскиваете в это правовое поле ваших покупателей, то совсем другие; кроме того вы начинаете быть более заметными
Ну я так понимаю, на каждого "кредитного" покупателя заводится свой контрагент. Там можно и контактные данные заполнить и даже паспортные.
На мой взгляд да, так будет правильнее, в этом случае можно будет и оплату по эквайрингу (карточкой банковской) оформить, да даже банковский товарный кредит на него посадить в случае необходимости. На диске ИТС статья должна быть как это проделывать, сам давно делал, всех тонкостей не помню. А вот с "заказами" не знаю можно ли такое устроить. Опять же все зависит от потребностей и условий именно Ваших продаж, не смотря на схожесть все торговые организации по своему уникальны.
Продаю товар рассрочку.
Завел контрагента.
В договоре проставил дату окончания договора.
Сделал через заказ покупателя. Затем реализация. Затем приходный кассовый ордер.
Есть ли отчет, которым можно посмотреть КОГДА нам должны отдать долг по договору?
Найти сам не могу.
Хотелось бы увидеть. Потому что таких покупателей много. И каждый день листать тетрадку не охота.
Завел контрагента.
В договоре проставил дату окончания договора.
Сделал через заказ покупателя. Затем реализация. Затем приходный кассовый ордер.
Есть ли отчет, которым можно посмотреть КОГДА нам должны отдать долг по договору?
Найти сам не могу.
Хотелось бы увидеть. Потому что таких покупателей много. И каждый день листать тетрадку не охота.
(18) NE_ZNAIY,
Отчет "Анализ заказов покупателей".
В "Настройках" группируете дополнительно по реквизиту "Заказ покупателя.Дата оплаты" - выше группировки заказа, или к заказу добавляете этот же дополнительный реквизит (через Расширенные настройки).
В самой форме отчета флажками отбираете "частично оплаченные" и "не оплаченные".
Даты оплаты, разумеется, кто-то должен расставить в заказах при оформлении.
Отчет "Анализ заказов покупателей".
В "Настройках" группируете дополнительно по реквизиту "Заказ покупателя.Дата оплаты" - выше группировки заказа, или к заказу добавляете этот же дополнительный реквизит (через Расширенные настройки).
В самой форме отчета флажками отбираете "частично оплаченные" и "не оплаченные".
Даты оплаты, разумеется, кто-то должен расставить в заказах при оформлении.
(18) NE_ZNAIY,
Свойства договора - вести по документам..
Контролировать число дней задолженности..
Отчеты-Продажи-Взаиморасчеты-Отчет по кредитной линии
+ Куча внешних отчетов по контролю просрочки (ПДЗ) на этом сайте
У себя используем доработанный отчет по кредитной линии, с автоматическим начислением процентов..
Так же разработан Отчет платежный календарь, показывает кто и сколько должен сегодня/завтра, в любой день "принести" денежек, небольшое планирование поступления без лишних телодвижений.
Так, на вскидку, не меняя конфигурации, можно попробовать соорудить вот такой отчетик:
Реализация на 100т.р.
Св-ва договора
Контролировать сумму задолженности 10 т.р. (используем в отчете как сумма ежемесячного платежа)
Контролировать число дней задолженности 15. (испоьзуем в отчете как оплата не позднее 15 числа каждого месяца)
В итоге видим:
Покупатель________Документ_________Сумма док.____Текущий долг___Дата след.платежа__Сумма платежа
Иванов И.И.__Реализация 01.07.16_____100т.р.________80т.р.____________15.09.16__________10т.р.
Свойства договора - вести по документам..
Контролировать число дней задолженности..
Отчеты-Продажи-Взаиморасчеты-Отчет по кредитной линии
+ Куча внешних отчетов по контролю просрочки (ПДЗ) на этом сайте
У себя используем доработанный отчет по кредитной линии, с автоматическим начислением процентов..
Так же разработан Отчет платежный календарь, показывает кто и сколько должен сегодня/завтра, в любой день "принести" денежек, небольшое планирование поступления без лишних телодвижений.
Так, на вскидку, не меняя конфигурации, можно попробовать соорудить вот такой отчетик:
Реализация на 100т.р.
Св-ва договора
Контролировать сумму задолженности 10 т.р. (используем в отчете как сумма ежемесячного платежа)
Контролировать число дней задолженности 15. (испоьзуем в отчете как оплата не позднее 15 числа каждого месяца)
В итоге видим:
Покупатель________Документ_________Сумма док.____Текущий долг___Дата след.платежа__Сумма платежа
Иванов И.И.__Реализация 01.07.16_____100т.р.________80т.р.____________15.09.16__________10т.р.
В изложенных мной методах это реквизит "Дата оплаты" в самом заказе.
Вообще, идеологий и способов контроля задолженности - дофига. Все зависят от схемы. Попробуйте этот, потом попробуйте вариант "вести учет по документам расчетов", как предлагает genna.
Основная идея - определить, какая именно сделка насколько оплачена.
В варианте ведения учета "по заказам" - мы в реализациях и платежах вынуждены указывать заказ, и относительно заказа становится возможным определить его отгруженность (в сумме или количестве), оплаченность (в сумме) и баланс (осталось оплатить - как разницу предыдущих сумм). Сделкой в вышеупомянутом смысле будет являться заказ. Типовой отчет для этого - Анализ заказов покупателей. Крив, как сосна в поле, но зато типовой.
В варианте ведения учета "по документам расчетов" мы будем вынуждены в каждом документе отгрузки указывать документы оплат, пришедших ранее (или отгрузка образует долг), а в каждом документе оплаты - документы отгрузки, долг по которым надо закрыть (или оплата станет авансом). Сделкой будет являться документ (отгрузки, в вашем случае). Оплаченность отгрузок и возникшие авансы можно определить по отчету "Ведомость по взаиморасчетам" с группировкой "Документ расчетов".
Далее вы просто находите способ к каждой сделке присобачить дату предполагаемой оплаты (в заказе она уже есть как типовой реквизит, для второго варианта можете ввести свойство документов "Дата оплаты", или грубо нарушитьдевст конфигурацию и прилепить свой реквизит).
Дополнительно находите персонал, который бы эти даты расставлял, или пишете регламентный автомат, который это будет делать с какой-то логикой.
Группируете один из вышеизложенных отчетов по датам оплаты, затем по сделкам: таким образом, видите, когда вам должны были бы оплатить, и сколько еще не оплатили.
Если не нравится форма типовых отчетов - рукожопите свой отчет. И любые обработки по напоминаниям, смс-рассылкам и т.п. Хороших типовых средств - нет.
Вообще, идеологий и способов контроля задолженности - дофига. Все зависят от схемы. Попробуйте этот, потом попробуйте вариант "вести учет по документам расчетов", как предлагает genna.
Основная идея - определить, какая именно сделка насколько оплачена.
В варианте ведения учета "по заказам" - мы в реализациях и платежах вынуждены указывать заказ, и относительно заказа становится возможным определить его отгруженность (в сумме или количестве), оплаченность (в сумме) и баланс (осталось оплатить - как разницу предыдущих сумм). Сделкой в вышеупомянутом смысле будет являться заказ. Типовой отчет для этого - Анализ заказов покупателей. Крив, как сосна в поле, но зато типовой.
В варианте ведения учета "по документам расчетов" мы будем вынуждены в каждом документе отгрузки указывать документы оплат, пришедших ранее (или отгрузка образует долг), а в каждом документе оплаты - документы отгрузки, долг по которым надо закрыть (или оплата станет авансом). Сделкой будет являться документ (отгрузки, в вашем случае). Оплаченность отгрузок и возникшие авансы можно определить по отчету "Ведомость по взаиморасчетам" с группировкой "Документ расчетов".
Далее вы просто находите способ к каждой сделке присобачить дату предполагаемой оплаты (в заказе она уже есть как типовой реквизит, для второго варианта можете ввести свойство документов "Дата оплаты", или грубо нарушить
Дополнительно находите персонал, который бы эти даты расставлял, или пишете регламентный автомат, который это будет делать с какой-то логикой.
Группируете один из вышеизложенных отчетов по датам оплаты, затем по сделкам: таким образом, видите, когда вам должны были бы оплатить, и сколько еще не оплатили.
Если не нравится форма типовых отчетов - рукожопите свой отчет. И любые обработки по напоминаниям, смс-рассылкам и т.п. Хороших типовых средств - нет.
Продажа в рассрочку - тоже самое, что обычно происходит в оптовой торговле. Накапливается та же дебиторка, которая потом со временем закрывается. В программе уже есть готовые механизмы контроля размеров и сроков этой дебиторки. Осталось только приспособить это к рознице, Но по факту, продажа в рассрочку действительно подразумевает персонализацию покупателей, ведение договоров с ними и т.д. и т.п. Так что думаю, особых сложностей не возникнет.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот