ИП на УСН доходы с НДС 5%, красное сальдо по счету 57.03 при эквайринге из разных подразделений в 1С

Индивидуальную консультацию запросил Татьяна М. (Волгоград, Волгоградская область)

Ответственный за ответ: Корнилова Оксана (★9.84/10)

Здравствуйте!
1С релиз 3.0.197.22. ИП на УСН с Доходы с НДС 5% с 01.12.25.
Уже несколько раз обращаюсь к вам за консультацией по вопросу автоматизации процесса закрытия сч. 57.03 в расчетах : наступление на рс по платежным картам.
Проблема только с одним из 2-х расчетных счетов — банк УБРИР. Данные с разных терминалом ( подразделений) поступают с задержкой 1-2 дня в общей сумме, разбивка указана в Наименовании поступления.
Счет 57.03. при каждом перезагрузке меняет остатки. Сначала я меняла время проведения ОРП на более ранне, чем Поступление на рс. Ваш эксперт обратила внимание, что в Поступлении на рс и в КУДИР должно быть одинаковое наименование Подразделения ( терминала) и предложила исправлять вручную. Но в поступлении бывает по 3 разных прихода : вместо одной автоматической операции у меня получается 3 и в каждой надо вручную высчитывать сумму Выручка минус комиссия банка, в КУДР исправлять наименование подразделения ( только через галочку «ручная корректировка», обязательная проверка остатка по сч.51. Я сделала весь январь, он потянул декабрь ( с 01.01.25 — перешли на НДС 5%). Несколько дней занималась только этим. В результате — все равно в некоторых подразделениях «красное сальдо» по сч.57.03. Ввела Операции Выравнивание остатков по регистру Прочие расходы, выровняла. — а «красное» сальдо по сч.57.03. за декабрь 2025 осталось. Потратила огромное количество времени — результата нет. Ваш эксперт посоветовала обратиться к разработчику. Неужели никто больше не сталкивался с подобным случаем?.

Метки консультации: —
Все комментарии (45)
  1. В Регистраторе подразделение не видно.

    По времени давайте смотреть настройки: Администрирование – Настройка программы Проведение документов.

    Когда сняли флаг, документы записываются по системному времени компьютера. А если отредактировали дату документа, то при его записи автоматически установится время 12:00:00.

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

    Внутри одного дня сначала записываются Поступление и Реализация, а позже по времени Оплата поставщику и Поступление оплаты от покупателя.
    Документ Поступление автоматически всегда записывается раньше Реализации.
    И таким образом не будет проблем с тем, что внутри дня образовался «аванс», который в этот же день и закрылся.
    Или что прихода еще нет, а реализацию провели и как минимум получили отрицательные остатки.
    Время документов для автоподстановки установлено разработчиками, оно логически продумано. Вручную его не изменить.
    Но если нужно, то в конкретном документе можно поправить время в ручном режиме.

    У меня настройка отключена.
    Но я не рекомендую это делать.
    Просто хочу продемонстрировать вам на скрине, что последовательность проведения документов корректная. Не возникает минусом по регистру, как у вас.

    Сейчас когда вы корректировали минусы/плюсы в УО, могли что то лишнее откорректировать. Поэтому это дает кривой НДС в КУДиР.

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

  2. Здравствуйте!
    В Настройке программы проведения документов у меня галочка не стоит.
    Можно ли в УО ( Регистраторе) добавить наименование подразделения для наглядности поиска даты расхождения?
    Так что же мне теперь делать для правильного начисления УСН? Вы могли бы в моей программе протестировать и написать мне логистику действий?

  3. По вашей базе понять как должно быть правильно сможете только вы.

    Та копия, что у меня, там большое кол-во минусов по регистру.
    Как я понимаю,
    чтобы это все исправить, надо открывать каждый ОРП ( из УО) с момент как ИП стал с НДС и проверять аналитику и документы Поступления, чтобы нигде не было лишних сумм, и так по каждому документу.
    Это по сути восстановление учета.
    И конечно должно быть минимум корректировок, потому если корректировка где то неверная, это опять потом приведет к ошибке.

    Поэтому я не могу вам это обещать.
    Что смогу, сегодня посмотрю.

  4. Вот сформировала УО за декабрь.
    Первая сумма в УО корректно внутри сформирована. а по второй сумме 27400,00 вижу некорректную картину( см. скрин).

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

  5. Татьяна, я вернулась))

    Скажите, а у вас ведь по каждому виду оплаты свой договор заведен?

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

    Но мне кажется, что у вас именно так и есть?

  6. Здравствуйте! Разделения по разным видам договоров по разным подразделениям нет. Возможно, тогда и нет необходимости использовать УО? Будет достаточно, если нет «красного» сальдо по сч.57.03?

  7. Я понимаю так, что пока будет сальдо по УО, так и будут суммы НДС вычитаться некорректно в КУДиР.

    Потому что сальдо в УО говорит о «кривой» аналитике и нарушении хронологии.

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

    Ситуация у вас нетипичная, пока не сталкивались с подобным. Поэтому нужно пробовать все способы.

  8. Раскладка УО с подразделениями. Опять появилась сумма 8200=. Она соответствует конкретному ОРП и Поступлению на рс. Вопрос: почему в Поступлении на рс в КУДИр учитывается сумма, уменьшенная не на НДС 1 173,81 (ОРП), а 416,67? Почему 8200= не идет в зачет с УО образуется с сальдо?

  9. Опять смотрим Регистратор.
    Видим, что есть Операция на 16400,00.
    Далее идут ОРП от 02.12. — 16400,00 и 24650,00.
    Поступление на р/счет — 16450,00.

    Полагаю, что должно быть еще одно Поступление на разницу.

    А Операция вовсе должна отсутствовать.
    Потому что не все операции верные.

    Сальдо по УО может быть, если Поступление на р/счет еще не было.
    А тут у вас именно такой случай — Операция сделана ошибочно.

    Остается вопрос, где остаток оплаты по ОРП.

  10. Здравствуйте!
    1. С УО пробовала по разному: убирала Операции введенные вручную, УО менялся, потом опять на другие даты вводила. Результаты менялись.
    2. Обратила внимание, что в ОРП — часто формируется КУДИР на уменьшение НДС. При этом в Поступлении на рс в КУДИР иногда попадает полная сумма платежа ( тогда за вычетом НДС из КУДИР в ОРП) суммы сходятся. Но часто, особенно, когда в Поступлении на рс включены приходы от разных терминалов-подразделений. А есть случаи, когда сумма одного ОРП разбивается на несколько приходов по рс. Полная мешанина. (пример в файле приложения)
    3. Возможно, есть отчет, где бы по итогу за какой-то период по общему Доходу проверять КУДИР , уменьшенный на НДС? Программа своей жизнью живет.
    4. Уже пришлось сдавать уточненную Декларацию по УСН за 2025, новое Уведомление на УСН за 1 квартал. Хочется уже быть уверенной быть, что результаты не изменятся.

  11. 1. Конечно, если убираете Операцию, результата в УО будет меняться по регистру.
    Но он все равно должен закрыться, не может быть по нему сальдо.
    Сальдо может быть только от момента создания ОРП до момента Поступления средств. Далее сальдо должно уйти.

    2. Подобное встречалось ранее в обсуждениях. Но помню, что выглядело это как ошибка. Так программа самостоятельно корректировала регистры, потому что ранее что то было проведено не как надо.

    3. Нет, специального отчета нет.

    4. Не могу вам дать гарантию, что ничего не изменится.
    Как вариант, предлагаю как и разработчики, создать к каждому виду оплаты свой договор. И учитывать не только по подразделениям, но и по договорам.
    Попробовать это можно в копии базы, чтобы увидеть как корректно работает программа.
    Создать новые договора, несколько технических примеров и проверить.

  12. Здравствуйте!
    После присвоения каждому терминалу своего Договора, наконец-то учет по КУДИР формируется правильно. Конечно, значительно добавилось ручной корректировки на этапах ОРП и банковских выписок, но появилась логика и наглядность , а, главное, понимание, процесса. Вымучила себя и умучила вас. Предстоит еще перепроведение всех ОРП и банковских выписок с декабря 2025. Зато — появилась уверенность в правильности результата.
    Спасибо за терпение и уделенное время.

    1
  13. Татьяна, очень здорово, что все получилось!!!

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

    Пусть дальше никогда лишнего сальдо не будет и НДС в КУДиР попадает верный ☕☕☕

Комментарии закрыты.