Нет возможности зафиксировать расчеты с покупателями 1с унф

Обновлено: 06.07.2024

У любой организации рано или поздно возникает потребность в автоматизации учета своей деятельности. Таблички в Excel стали громоздкими и неудобными, объем информации увеличился и требует анализа. Руководство компании принимает решение — нужно внедрение 1С.

Приобрести лицензии на программы 1С не сложно, гораздо сложнее и ценнее получить нужный результат от программного продукта.

Среди прочих конфигураций, малый бизнес, как правило, внедряет 1С:Управление нашей фирмой (1С:УНФ). В этой конфигурации можно фиксировать все типовые операции коммерческой деятельности компании. Бывает, что типовых возможностей программы для ведения деятельности недостаточно. В этом случае требуется доработка конфигурации.

В статье расскажем об успешном внедрении 1С:УНФ нашему клиенту и доработке конфигурации для ведения валютного учета.

Постановка задачи

В конце 2019 г. к нам обратилась логистическая компания, которой требовалось купить и внедрить 1С. Компания предоставляет услуги перевозки в России и за рубежом. Мы выяснили, как компания ведет учет, и какие процессы нужно автоматизировать.

Требования к валютным операциям в проекте

Одно из основных требований заказчика — организация многовалютного учета с выполнением требований:

  • Отражать операции в разной валюте в рамках одной сделки.
    Например:
  • заказ и отгрузка в евро;
  • оплата в рублях;
  • расходные операции, связанные с выполнением сделки в долларах.

Индивидуальный курс валюты должен указываться в следующих документах:

  • Заказ покупателя;
  • Поступление на счет;
  • Расход со счета;
  • Приход в кассу;
  • Расход из кассы;
  • Расходная накладная.

За один день может быть создано несколько наборов документов с различными сценариями поступления и списания денег и разным курсом одной валюты.

  • Расчеты с контрагентами в валюте необходимо осуществлять не по курсу ЦБ, а по курсу, согласованному сторонами (у.е.). В связи с тем, что в один день могут быть операции с разными контрагентами и с различными сценариями поступления и списания денег – во всех документах требуется указывать индивидуальный курс пересчета валюты на рубли.
  • Необходимо формировать отчеты одновременно в двух валютах: национальной валюте и иностранной валюте, в которой проведена операция.

Ни в одной подходящей конфигурации 1С полностью не реализованы перечисленные требования к валютному учету.

После анализа остальных бизнес-процессов компании мы остановили выбор на конфигурации 1С:Управление нашей фирмой.

1С:УНФ не перегружена лишними функциями и при этом закрывает потребности учёта основных бизнес-процессов небольшой фирмы.

Внедрение 1С:УНФ

На старте внедрения мы проводим предпроектное исследование. Это необходимо для фиксирования бизнес-процессов компании, подлежащих оцифровке и учету. Также, исследование помогает подобрать правильную конфигурацию и методологию ведения учета. В результате предпроектного исследования мы фиксируем техническое задание на внедрение и передаем в работу.

В результате внедрения мы выполнили работы:

  • Провели анализ бизнес-процессов в компании;
  • Выбрали наиболее подходящую конфигурацию и купили лицензии 1С;
  • Смоделировали процессы в 1С и написали техническое задание на внедрение 1С;
  • Установили и настроили типовую конфигурацию;
  • Провели доработку и тестирование системы в соответствии с требованиями;
  • Выполнили интеграцию 1С и Битрикс24;
  • Передали систему в эксплуатацию.

Учет валютных операций в УНФ

Существующий в УНФ валютный учет решает две из трех задач обозначенных заказчиком.

  • В документах есть возможность отражать операции в разной валюте;
  • В документах можно указать индивидуальный курс валюты, но используется он только для пересчета табличной части документа. При проведении документа сумма операции все равно пересчитывается по единому курсу, зафиксированному в регистре сведений. Этот курс используется при формировании отчетов. Курсы валют обычно равны курсу ЦБ. Для решения этой задачи мы сделали ряд доработок, о которых расскажем далее..
  • В конфигурации можно формировать отчеты в разных валютах.

Как работает учет валютных операций в 1С:УНФ

В начале работы с программой в списке валют есть только российский рубль. Чтобы вести в программе учет в нескольких валютах нужно выполнить несколько действий:

  • Активировать соответствующую настройку. В блоке настроек “Деньги” раздела “Компания” - установить флаг “Несколько валют”.
  • В справочник “Валюта” необходимо добавить те валюты, в которых будут происходить расчеты с покупателями и поставщиками. Из классификатора валют необходимо выбрать Доллар США, ЕВРО и загрузить их курсы. Можно настроить расписание загрузки для ежедневного обновления курса валют.
  • Для того, чтобы в документах появилась возможность работы с валютами, надо создать договора с поставщиками и покупателями в валюте. Именно по этим договорам и будут осуществляться валютные операции.

Чтобы операции можно было создавать одновременно в рублях и в иностранной валюте, в договоре должен быть установлен признак “в у.е.”. При установленном признаке, даже если документ оформляется в рублях, при проведении суммы операций оперативно пересчитываются и отражаются в валюте договора. Т.е. это решает задачу с формированием отчетов в двух валютах и задачу оформления отгрузки в валюте, а оплаты этой отгрузки в рублях.

Валютный учет в программе 1С:УНФ не представляет особых сложностей. Курс валюты задается в справочнике валют. Документы продажи и отчеты формируются в соответствующей валюте. Для одной валюты можно задать один курс на день. Этот курс фиксируется в регистрах, используется в расчетах и отчетах.

В большинстве случаев этих возможностей достаточно для учета. Для выполнения требований к валютным операциям потребовались доработки конфигурации.

Доработка валютного учета в УНФ

Для достижения поставленных целей в конфигурацию внесли ряд доработок:

  • В документах "Поступление на счет", “Поступление в кассу”, “Расход со счета” и “Расход из кассы” изменили механизм проведения: суммы по всем регистрам пересчитываются из иностранной валюты в национальную валюту не по курсу указанному в регистре, а по курсу указанному в документе
  • Запретили менеджерам проводить “денежные” документы. Оставили возможность только создавать и записывать документы.
  • В отчетах реализовали отражение прибыли по индивидуальному курсу поступления денежных средств, а не по курсу расходной накладной.

Полезные доработки УНФ для упрощения учета

Кроме настроек и доработок валютного учета решили еще ряд задач, которые упростили работу пользователям и минимизировали ошибки:

Взаиморасчеты в УНФ (Часть 1) или Почему врет начальная страница (Пульс бизнеса)

Один из самых частых вопросов у внимательных пользователей УНФ, которые рассматривают цифры, которые выдает им программа — «Почему врет стартовая страница УНФ? Откуда у нас такие долги?!».

Это первая статья из цикла.

Один из самых частых вопросов у внимательных пользователей УНФ (Управление нашей фирмой), которые рассматривают цифры, которые выдает им программа — «Почему врет стартовая страница УНФ? Откуда у нас такие долги?!».

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

Лучше всего ситуацию иллюстрирует скриншот =)

Долги наши и нам в УНФ.jpg

И теперь очевидный вопрос: «Откуда такие долги?! Причем есть наши и нам, а на самом деле долгов никаких нет».

И в подтверждение этого показывают справочник покупателей / поставщиков и подкладывают Акты сверки.

Примечание: Для упрощения рассказа у нас один контрагент — покупатель.

Долга нет у покупателя.jpg

Нет долгов в акте сверки.jpg

Такое ощущение, что действительно никаких долгов нет, а программа об этом не в курсе.

Давайте попробуем посмотреть мощные аналитические отчеты программы Управление нашей фирмой.

Начнем с Отчета «Взаиморасчеты» (кратко).
Этот отчет по нашим оценкам наиболее часто используется для контроля за долгами.

И в отчете Взаиморасчеты долга нет.jpg

Опять двадцать пять.

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

Так вот, самое правильное место для анализа долгов покупателей — это Отчет «Расчеты с покупателями».

Расчеты с покупателями.jpg

В-о-о-о-т, уже . Мы видим, что в группе «Конечный остаток» у нас две одинаковых цифры. Есть и задолженность и предоплата.

А может ли так быть вообще?!
Может. В одном из двух случаев:

  • Если с контрагентом ведутся расчеты по нескольким договорам (по одному договору висит долг, а по другому — предоплата)
  • Если с контрагентом ведутся расчеты по нескольким заказам (соответственно, по одному заказу висит долг, а по другому — предоплата)

А если договор один и по заказам расчеты не ведутся, то одновременный долг и аванс на покупателе (бухгалтера еще называют это «одновременным сальдо») — это чисто техническая ошибка, которая ничего не означает экономически.

Построим Отчет «Расчеты с покупателями» специальным образом, чтобы сделать проблему очевидной.

Настройки отчета Расчеты.jpg

Мы добавили очень важную аналитику «Документ расчетов».

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

С авансами та же история — они учитываются обособленно, а потом зачитывают долг.

Расчеты с покупателями по документам расчетов.jpg

В этом отчете мы как раз и видим, что ни один из долгов (Акты выполненных работ 1,2,3) не оплачены, а все оплаты стали авансами. Вот и получается, что долгов на 8 млн. и авансов на столько же.

Почему так произошло?

— был выписан акт выполненных работ
— была совершена оплата за этот акт

Для программы очень важно, что бы в документе оплаты было прямо указано, что оплачивается именно этот акт, а у нас стоит что эта оплата — предоплата.

предоплата стоит.jpg

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

а вот теперь выбрали правильный акт.jpg

Вот теперь нет долгов.jpg

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

Повторим подобное с Актом № 2 и Оплатой № 2.

Теперь и второй акт частично оплатили.jpg

Видим, что Поступление на расчетный счет № 2 пропало из отчета (точнее показывается как оплата в 500 000 Акта № 2) и остался долг.

Посмотрим внимательно на оплату № 3. Это сложный платеж. это оплата долга по второму акту и предоплата за . Именно так мы и должны заполнить Поступление на расчетный счет № 3.

разнесение оплаты с учетом аванса.jpg

долг и аванс по 3му акату.jpg

Нам остался последний штрих — сказать что в Акте № 3 мы зачитываем аванс в 7 000 000 рублей.

Зачет аванса по акту.jpg

зачет аванса и нет долгов.jpg

Во-первых, мы видим тут что заработала колонка «Зачтено» и наконец наступила красота — нет никаких долгов и авансов (сравните с первым построением отчета).

Вот именно такой работы с долгами и оплатами ожидает программа и теперь посмотрим на итог нашей работы — начальную страницу «Пульс бизнеса».

Монитор теперь не врет.jpg

Ну наконец пульс бизнеса стучит верно и не врет.

Под конец остается как минимум два вопроса:

А вообще для чего так сложно (аккуратно и внимательно) вести расчеты?

Основная идея в том, что очень много пользователей (собственников, руководителей отделов продаж, менеджеров) хочет использовать замечательный механизм отсрочек и «давности» долгов. То есть отчет который скажет —есть ли просроченная задолженность, или на сколько дней задолженность просрочена и можно ли делать новую отгрузку / давать скидку или еще в этом духе.

Так вот, для этого отчета критически важно знать когда именно был оплачен какой долг. Причем, в идеале это решение должен принимать человек (именно этим мы с вами сейчас и занимались).
Соответственно, без уверенности в том, что у вас «красивые» взаиморасчеты ожидать адекватных цифр в Отчете «Задолженность покупателей по срокам долга» не стоит.

Неужели нет других вариантов и надо так сильно заморачиваться?

  1. В прошлых версиях программы Управление Нашей Фирмой можно было выполнять эту работу только вручную
  2. Практически никто с этим не справлялся и во взаиморасчетах всегда была каша

В новой версии УНФ (начиная с ) можно организовать работу так, что бы авансы и долги закрывались автоматически (по методу ФИФО), но:



Друзья, дабы тема с УНФ не затерялась в постах общего топика по продуктам 1С, создаю отдельную тему для обсуждения.

Релиз с конфигурацией "Управление небольшой фирмой" выпущен недавно, программа отличается в лучшую сторону по интерфейсу от других продуктов 1С, судя по всему компания видит в УНФ будущего флагмана своих продуктов для бизнеса, версия преподносится как необходимая для небольших производств и сфер услуг.

Давайте обсудим ее.


У меня вопрос по поводу загрузки из банка в УНФ. При загрузке ВСЕ документы делаются проведенными, база самостоятельно распределяет заказы/приходные накладные/расходные накладные.
В самом документе, Зачет долгов " в ручную". В программе Автозачет авансов "да".
Меняла автозачет авансов, но это не исправило ситуацию.

Кто-нибудь сталкивался с подобным? Началось это после перехода на 1.6

"преобразование значения к типу Булево не может быть выполнено"

Есть какой-нибудь квик-фикс? Занимаюсь тестовой разверткой для проекта и нужна эта функция. Не хочется ждать появления новой версии.

Добавлено:
Возвращаюсь к обсуждению глюка шрифтов в бланке договора! Дошел плотно и до них! Вот что у меня происходит по пунктам.
1) Про создании бланка на основании другого, слетают автозаполняемые параметры (почему то не все).
2) При выделении всего бланка договора через CTRL-A шрифт на другой не меняется.
3) При выделении мышкой, шрифт поменялся. При печати из документа (счета) шрифт тот который я выбрал при создании бланка.
4) Так как слетели параметры, вставляю вновь. И Опа, при печати договора (из документа счет), шрифт который я выбрал п3, опять слетает, хотя при вызове редактирования бланка договора шрифт стоит тот который мне нужен.
. чудеса

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

1. Выберем настройки отчета:


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


2. Сформируем отчет и начнем искать ошибки:


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


Ошибка № 1 . поступление платежа после отгрузки, с выбранным типом платежа "аванс"

мы видим, что поступление на счет произошло позже чем отгрузка, это видно по дате и времени документов.


открываем последний в цепочке документ.


и видим, что в документе поступления денег выбран признак "является авансом - Да", что не верно,

решение: выбираем признак "является авансом - нет" , указываем расходную накладную и проводим поступление на счет.


и в отчете видим что всё зачлось.


и в окончательной сверке видим, что всё стало правильно


Ошибка № 2. Не зачтен аванс при отгрузке

Снова видим что одна и та же сумма по заказу и в нашем долге и в долге контрагента, а общая задолженность 0.


в расшифровке отчета видим, что в этом случае отгрузка произошла позже оплаты, но аванс по какой-то причине всё равно не зачелся (возможно документ оплаты записали датой раньше отгрузки, но провели позже проведения документа отгрузки)


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


мы видим в документе. что сумма расчетов = 0, то есть аванс не зачелся при отгрузке чаще всего достаточно нажать кнопку "провести" и аванс зачтется. но можно и зачесть для надежности его вручную, для этого нажимаем кнопку (на которую указывает розовая стрелка)


мы видим, что в таблице зачета предоплаты, как раз висит аванс ровно на требуемую сумму по этому же заказу. эту сумму мы и зачитываем.



после проведения получаем следующую картину, что всё прекрасно зачлось и долгов по дебету и кредиту нет.



Ошибка № 3. Зачет аванса с ввода остатков.

Аванс введенный через ввод остатков зачитывается немного по особому. его сразу видно, в отчете, ввиду отсутствия параметров документа заказ


в расшифровке видим, что на 01.01.2013 у поставщика был долг перед нами, и он совершил нам оплату


При вводе остатков автоматически создаются не проведенные документы, , которые и можно использовать для зачтения остатков откроем документ поступления платежа.


видимо что необходимо признак аванса установить в "нет" и выбрать псевдо документ отгрузки (обращаю внимание, что этот документ без суммы и не проведенный. так как создан автоматически документом ввода остатков)


видим что долг зачелся



Важное замечание, бывает так , что в обще сумме долга, введенного при вводе остатков содержится несколько сделок. закрываемы затем несколькими платежами, в этом случае - необходимо зайти в документ ввода остатков и разбить общую сумму долга на суммы соответствующие этим сделкам введя их разными строчками, соответсвенно в документах поступления денег затем выбирать разные псевдо накладные.

Ошибка № 4. Выбор не правильных договоров

Необходимо также обращать внимание на ситуации изображенные на скриншоте - здесь явно видно, что у одного из документов по сделке на сумму 12 912 рублей выбран не тот договор, выбрав правильный договор и проведя документы, нужно будет переформировать отчет и в случае не зачтения аванса, провести действия по одному из вышеописанных сценариев.

Читайте также: