Анастасия
Что это такое взаиморасчеты?
Самой важной составляющей учетной системы является ведение взаиморасчетов. Это даже можно назвать самой главной, так как деньги на любом предприятии намного важнее, чем внутреннее передвижение товара и его остатки на складах.
В условиях жесткой конкуренции очень сложно производить взаиморасчеты на крупных предприятиях, когда товар может отпускаться в кредит, так как нет полной уверенности в платежеспособности клиента.
Требования к взаиморасчетам
При работе с постоянным клиентом, как правило, взаиморасчеты - это прохождение по схеме, которая выработана путем переговоров и устраивает всех участников.
Существуют в этой области некоторые требования, которые нужно строго соблюдать.
Требования, которые предъявляются к системе взаиморасчетов:
Достоверность.
Вывод данных должен происходить быстро и без сложностей.
Возможность контролировать задолженность.
Быстрая детализация отчетов любой сложности.
В эту систему входит две подсистемы: первая следит за движением товара (склад), вторая следит за движением денег (касса). Обе этих подсистемы нераздельны друг от друга и принимают участие во взаиморасчетах.
Рассмотрим простой пример. Мы пришли в магазин за покупкой. Нам подают выбранный товар (товарная операция), мы оплачиваем покупку (кассовая операция). Как только мы взяли в руки поданный нам товар, мы становимся должниками магазина на сумму покупки.
Как только мы отдали продавцу деньги, мы погасили задолженность. Какие бы крупные операции не происходили на предприятиях, принцип всегда один.
Виды взаиморасчетов
Взаиморасчеты - это в принципе понятный процесс, который делится еще и на некоторые виды, которых три:
Взаиморасчеты по заказам - в том случае, когда взаиморасчет происходит по конкретному заказу клиента.
Взаиморасчет по договору - все покупки и продажи осуществляются согласно подписанному между сторонами договору. Это может быть продажа товара в кредит, либо покупка по предоплате.
Взаиморасчет по накладным - в этом случае покупка или продажа оплачивается отдельно по конкретной накладной.
Этих видов достаточно для того, чтобы можно было охватить все сферы деятельности, в которых присутствуют взаиморасчеты.
Итак, взаиморасчеты - это прямое перераспределение доходов, от продажи товаров или услуг, между той или иной организацией, которые учувствуют в предоставлении услуг или в продаже товара.
Говоря простым языком, это операции купли-продажи. Ведет все операции по расчетам в большинстве случаев бухгалтер-экономист, он же и отвечает за всю отчетную документацию по взаиморасчетам.
Для осуществления качественного контроля в современных условиях просто необходимо применение качественного программного обеспечения.
Как правило, грамотное отражение текущих операций позволяет быстро и своевременно получить любую информацию по взаиморасчетам.
к Депозитарному договору
№ _____ от “____“ _________2012 года.
1. Общие положения
1.1. Настоящий Порядок взаиморасчетов определяет отношения Депозитария и Депонента в части, касающейся их денежных расчетов по Депозитарному договору (далее – Договор), в течение всего срока действия Договора.
1.2. Порядок взаиморасчетов действует и после расторжения Договора вплоть до полной передачи, в соответствии с Условиями, ценных бумаг Депонента, хранившихся в Депозитарии (учитываемых на счете депо Депонента в Депозитарии), от Депозитария к Депоненту и оплаты услуг Депозитария.
1.3. Порядок взаиморасчетов может быть изменен:
· в любой момент после подписания сторонами соглашения, изменяющего или дополняющего настоящий Порядок взаиморасчетов;
· Депозитарием в одностороннем порядке через один месяц после уведомления в письменном виде Депонента о внесении соответствующего изменения.
1.4. Платежи Депонента Депозитарию по Договору осуществляются на основании выставляемых счетов. Счета выставляются Депозитарием и оплачиваются Депонентом в рублях. Счета могут высылаться Депозитарием Депоненту с использованием средств факсимильной связи.
1.5. Платежи Депонента Депозитарию по Договору включают в себя:
· оплату услуг по хранению ценных бумаг и (или) учету прав Депонента на ценные бумаги;
· оплату услуг Депозитария по проведению текущих операций для Депонента;
· оплату дополнительных услуг Депозитария.
1.6. Услуги Депозитария по хранению ценных бумаг и (или) учету прав Депонента на ценные бумаги, переданные Депозитарию как номинальному держателю, оплачиваются Депонентом на основании счетов, выставляемых Депозитарием Депоненту ежемесячно. Счета выставляются на основании раздела 2 настоящего Порядка взаиморасчетов (Прейскуранта услуг Депозитария) в течение первых пяти рабочих дней месяца, следующего за оплачиваемым.
1.7. Стоимость услуг Депозитария по хранению ценных бумаг и (или) учету прав собственности Депонента на ценные бумаги рассчитывается следующим образом: неполный месяц пользования услугами Депозитария округляется до полного и счет выставляется как за полный месяц учета и хранения ценных бумаг Депонента.
1.8. Счета, указанные в п.1.6., оплачиваются Депонентом в течение десяти банковских дней со дня выставления их Депозитарием.
1.9. Услуги Депозитария по текущим операциям, проводимым Депозитарием по распоряжениям Депонента или по дополнительным соглашениям Сторон, оплачиваются Депонентом на основании счетов, выставляемых Депозитарием не чаще, чем один раз в неделю на основании раздела 2 настоящего Порядка взаиморасчетов.
1.10. В счета, выставляемые Депозитарием Депоненту за проведение текущих операций, включаются издержки Депозитария на проведение соответствующих операций, а именно:
· расходы на оплату услуг сторонних организаций:
Регистраторов и депозитариев;
Расчетных организаций;
Трансфер-агентов;
Агентов по перерегистрации;
Курьеров;
Почты (в том числе, при необходимости, экспресс-почты);
Нотариусов и переводчиков;
· транспортные расходы;
· расходы на командировки сотрудников;
· другие разумные расходы, произведенные Депозитарием для выполнения распоряжений Депонента.
1.11. В том случае, если сумма издержек, оговоренных в п. 1.10., по предварительным расчетам превышаетДвадцать тысяч) рублей, Депозитарий имеет право выставить счет, указанный в п. 1.10, до проведения операций. В этом случае операции проводятся после получения денежных средств от Депонента.
1.12. Счета, указанные в п. 1.10, оплачиваются Депонентом в течение десяти (девяноста – для нерезидентов) банковских дней с момента выставления их Депозитарием. Вместе со счетами Депозитарий выписывает счета-фактуры. По согласованию Сторон, они подписывают акт о выполненных работах за отчетный период.
1.13. Датой оплаты считается дата списания требуемой суммы с расчетного счета Депонента при наличии платежного поручения с отметкой расчетного банка Депонента или мемориального ордера , полученных через банк, либо непосредственно от Депонента. Если в течение тридцати (30) (для нерезидентов – 95) календарных дней с даты выставления счета на оплату услуг денежные суммы в размере выставленного счета не будут зачислены на расчетный счет Депозитария, то Депозитарий вправе приостановить осуществление всех операций по счету депо Депонента, а также прием депозитарных поручений от Депонента до полного возмещения всех причитающихся по Договору сумм.
1.14. При оплате счета в долларах США или Евро сумма платежа пересчитывается по курсу Центрального банка РФ на дату выставления счета. При значительном уменьшении курса доллара США и (или) Евро по отношению к рублю (больше, чем на 15% от курса на дату заключения договора) Депозитарий вправе в одностороннем порядке изменить Прейскурант, предварительно уведомив об этом Депонента.
2. Прейскурант услуг Депозитария .
№ п/п | Наименование услуг | Стоимость/доплата за срочное исполнение | Единица измерения |
||
Открытие счета депо | руб. за счет |
||||
Закрытие счета | руб. за счет |
||||
Ведение счета депо | |||||
Ведение счета депо | руб. в месяц за хранение и/или учет | руб. за поездку |
|||
Расходы на командировку, связанную с исполнением поручения Депонента | руб. за день/1 сотрудник, не считая накладных расходов |
||||
Почтовые расходы (включая подготовку документов для отправки) | |||||
Почта России | руб. за одно заказное письмо |
||||
Иные почтовые службы | руб. за одно письмо |
||||
Услуги нотариусов по заверению копий учредительных документов Депозитария для открытия счета НД в реестрах владельцев ценных бумаг или в депозитариях | руб. за заверение копий комплекта документов |
||||
Отправление корреспонденции по междугородней факсимильной связи в интересах Депонента | 60 за страницу, но не менее 180 | ||||
Изготовление ксерокопий документов, предоставленных Депонентом | руб. за страницу |
||||
Иные услуги, связанные с исполнением Депозитарием поручения Депонента, не названные в настоящем Прейскуранте | по соглашению сторон |
3. ПОДПИСИ СТОРОН
На указанный тариф производится начисление НДС по действующей ставке.
Включая прием учредительных документов, доверенностей и проверку правильности оформления;
В случае резервирования ЦБ на корреспондентском счете Депозитария, открытом в ином депозитарии, обслуживающем организатора торгов. Открывается на основании дополнительного соглашения к Договору.
Без учета прямых издержек Депозитария.
Без учета прямых издержек Депозитария.
Без учета прямых издержек Депозитария, если такие возникнут.
Без учета услуг нотариуса, переводчика и сторонних организаций.
Без учета прямых издержек. В случае наличия нескольких Депонентов прямые издержки и комиссия делятся между ними в равных долях.
Если соответствующим договором с регистратором не предусмотрены иные расценки.
Без учета комиссии за выезд курьера.
На самом деле, данная статья запоздала, по меньшей мере, лет на 6. У меня давно были мысли выразить накопленный опыт в виде такой публикации, но все никак не случалось. Разгребал взаиморасчеты, поверите или нет? Шутка, конечно. Но даже до сих пор, несмотря на то, что конфигурации КА 1 и УПП вроде бы выводятся из эксплуатации, регулярно обращаются клиенты, у которых во взаиморасчетах бардак и хаос.
Объем знаний, который требуется передать, достаточно велик. Как ни хотелось ужаться, к сожалению, в рамках одной публикации сделать это не получится. Я постараюсь разделить текст по смыслу в несколько статей, и дополнительно выложить ряд внешних отчетов, для УПП/КА которые помогают в анализе и контроле. Некоторые из них можно заменить универсальным отчетом, некоторые «незаменимы».
Кроме того, не получилось сделать статью, ориентированную только на бухгалтера или только на специалиста. К сожалению, УПП/КА - не те конфигурации, которые можно внедрять, вести и контролировать, не влезая в смежные знания. Либо специалист должен разбираться совместно с бухгалтером, либо кто-то из них должен достаточно глубоко проникнуть мыслью в работу другого.
Данная часть больше теоретическая, в рамках которой я постараюсь зафиксировать и описать используемые понятия и термины, и показать их в сравнении с другими конфигурациями.
В конфигурациях "Комплексная автоматизация 1.1" и "Управление производственным предприятием 1.3" часто встречается ситуация, когда, по, кажется, непонятным причинам, на счетах 60.01, 60.02, 62.01, 62.02 образуются отрицательные остатки, встречное сальдо (одновременно присутствует и аванс и долг на разных субсчетах), внезапно возникают авансы и/или долги, которых не должно было случиться. И это только видимая "вершина айсберга".
Основными "пострадавшими" становятся: баланс (в котором неправильно разворачивается дебиторская и кредиторская задолженность), участок налогового учета НДС с авансов выданных и полученных (счета 76.АВ, 76.ВА). В случае валютных расчетов, либо расчетов в условных единицах, ситуация дополнительно осложняется тем, что у документов неправильно определяется рублевое покрытие, переоценка остатков происходит некорректно.
Многие пользователи начинают рефлексировать, исправляя ситуацию операциями, введенными вручную. Хотя формально «баланс сходится», однако это никак не помогает автоматизированно заполнить книги по НДС, распечатать отгрузочные документы с нужным рублевым покрытием.
Однако, проблему желательно решать системно, от начала. Для этого придется немного погрузиться в теорию. В первую очередь необходимо рассмотреть детализацию учета, которая применяется в 1С вообще, и в частности, в рассматриваемых конфигурациях. Затем - контуры учета (регламентированный и управленческий) - опять таки, вообще, и в рассматриваемых конфигурациях. И наконец, структуры данных, которые используются для ведения учета в рассматриваемых конфигурациях.
Традиционно, в конфигурациях системы 1С: Предприятие учет взаиморасчетов ведется в разрезе договоров (привязанных к контрагентам и организациям). Назовем, для удобства, это сочетание «координат» (измерений) «узлами взаиморасчетов ».
В бухгалтерских конфигурациях мы ведем учет еще и на разных счетах плана счетов, поэтому, для целей бухгалтерского учета, будем полагать, что определение узла взаиморасчетов дополнено счетом бухгалтерского учета . При этом, если к счету открыты отдельные субсчета для аванса и долга (например, 60.01 и 60.02), то один договор по ним мы все равно будем рассматривать как один узел по паре счетов. Так, на счете 60 у нас есть пара счетов для рублевых расчетов (60.01, 60.02), пара счетов для валютных (60.21, 60.22), пара счетов для расчетов в условных единицах (60.31, 60.32)
Остатки и обороты взаиморасчетов в разрезе узлов проводятся в какой-либо регистр. В чисто бухгалтерских конфигурациях это в 90% случаев - регистр бухгалтерии, в конфигурациях управленческого учета - регистр накопления.
Для удобства далее, будем говорить, что если для расчетов мы используем регистр бухгалтерии, то мы «ведем учет на плане счетов », а если регистры накопления, то «ведем учет на регистрах ». Это не совсем правильно технически, зато понятнее интуитивно.
В конфигурации «Управление торговлей 10.3» представлена возможность дополнить узлы взаиморасчетов полем «Сделка» , которое может принимать значение либо выставленных (поставщиками или покупателями) счетов, либо заказов. Какой именно тип документа выступает в качестве разделителя - указывается в элементе справочника «Договоры».
На рисунке представлен фрагмент формы элемента справочника "Договоры контрагентов" из КА 1.1, где зеленым обведено поле, отвечающее за эту аналитику.
Конфигурации КА и УПП унаследовали этот механизм.
При указании данного признака все документы взаиморасчетов по договору начинают императивно требовать указание сделки (счета или заказа), в регистрах учета начинает использоваться соответствующее поле, и, соответственно, отчеты по этим регистрам получают возможность разделить взаиморасчеты договора по сделкам.
Таким образом, мы получаем возможность вести в рамках одного договора раздельный учет в разрезе каждой сделки, контролировать полноту оплаты каждой сделки, расставить ответственных менеджеров к каждой сделке, и рассматривать задолженность в разрезе менеджеров.
Применение такой схемы бывает удобно, но рождает ряд побочных эффектов, о которых позже.
С какого-то момента во всех новых конфигурациях 1С появляется концепция «Учет в разрезе документов расчетов», который предполагает, что остаток долга (аванса) по узлу взаиморасчетов дополнительно разделяется по документам образования этого долга (аванса).
Если я не ошибаюсь, впервые эта концепция появилась в конфигурации «Торговля и склад 9.2», а затем и в бухгалтерских конфигурациях, частично начиная с «Бухгалтерии предприятия 1.6». В полном объеме - с редакции 2.0.
Для удобства, мы будем полагать, что разные документы расчетов не образуют разные узлы взаиморасчетов, а считаются дополнительной детализацией внутри узла.
Учет по документам расчетов подразделяется на три вида, назовем их ручной , автоматический и гибридный .
В рамках автоматического учета по документам расчетов , долги (авансы) образуются и зачитываются в разрезе этих документов по принципу FIFO.
Пример: При нулевом (изначально) состоянии расчетов с покупателем, остатки по узлу нулевые. Пусть у нас появляется платежное поручение на 10 000 рублей. Поскольку задолженности по узлу не было, платежное поручение признает аванс суммой в 10 000 рублей, и приходует его в узел «в разрезе себя». Пусть, затем, у нас появляется реализация на сумму 12 000 рублей. Эта реализация сначала выбирает с узла остатки авансов в разрезе документов их образования (платежное поручение №1 на сумму 10 000 рублей), и гасит их. Затем, если от суммы реализации, после зачета авансов что-то осталось, реализация признает задолженность в размере остатка уже «по себе» (реализация №1 на сумму 2 000 рублей). Следующая платежка на 5 000 рублей сначала будет пытаться погасить долги в разрезе документов их образования (реализация №1 на сумму 2 000 рублей), и только затем, если что-то осталось, признает аванс в разрезе себя (3 000 рублей). И так далее.
Есть небольшие различия, как это сделано в разных конфигурациях на регистрах бухгалтерии и на регистрах накопления, но общий принцип остается таким.
Если все документы проводятся последовательно, то эта схема прекрасно работает. В результате, по узлу взаиморасчетов складываются остатки авансов и долгов в разрезе наиболее последних документов их образования. В идеале, по одному узлу у нас должен быть либо аванс, либо долг : одновременное их присутствие обычно указывает на ошибку.
Как только кто-либо задним числом изменяет суммы документов, проводит новые документы, эта стройная логика разрушается: авансы и долги, которые давно должны были быть погашены, «вскрываются» задним числом. Чтобы устранить эту проблему требуется перепровести документы в хронологической последовательности (иначе говоря, «восстановить последовательность»), для чего разработчиком технологии придуманы различные костыли:
Этот (автоматический) способ подходит для большинства хозяйственных случаев.
В рамках ручного учета по документам расчетов, каждый раз, принимая платеж или оформляя реализацию мы должны указывать, соответственно, погашаемые долги или зачитываемые авансы. Если этого не сделать, то реализация всегда будет формировать новый долг, а платежка - новый аванс.
Для этого в документах предусмотрены особые поля и закладки, в которых есть различные формы подбора долгов/авансов по остаткам, чтобы не делать это совсем вручную и медитативно.
Особенно сложно вести учет в таком режиме, если имеют место быть какие-то взаимозачеты или расчеты через третьих лиц. Но иногда это нужно ввиду особенностей законодательства, договоров и т. п. Например, из отраслевого законодательства по ЖКХ вытекает необходимость принимать платежи с учетом назначений платежа (за какой расчетный месяц оплачиваются услуги), для их отражения как раз удобен ручной учет. Для расчетов по факторингу тоже крайне важно закрывать отдельные узлы взаиморасчетов в несколько этапов (первичное финансирование, остаток финансирования и удержание комиссии), и контролировать полноту их закрытия.
Эта концепция заложена в конфигурациях КА 1 и УПП 1, ее можно включить на уровне договора, посредством установки признака «Учет по документам расчетов». См. рисунок:
После этого во всех платежных документах появляется возможность выбора документа (одного или списком), по которому будет погашаться долг (см. рисунок), а если этот документ не указать, то будет образован новый аванс, а во всех отгрузочных документах - закладка "Предоплата", в которую можно подбирать документы, аванс с которых нужно зачесть, либо будет образован новый долг.
(Но на самом деле все будет немного сложнее, что будет описано в 4.1.
В рамках гибридного учета образование долгов и авансов осуществляется по-умолчанию автоматически, но в каждом документе мы имеем возможность перехватить автоматику и явно указать зачитываемый аванс или погашаемый долг. Эта концепция, например, по умолчанию заложена в "Бухгалтерию предприятия 3.0". На рисунке представлена форма документа "Реализация", в которой имеется возможность выбора (еще раз обращу внимание, что это просто пример из конфигурации "Бухгалтерия предприятия 3.0", к КА и УПП прямого отношения не имеющий) :
Вообще, надо сказать, такая (гибридная) концепция рождает нехорошие глюки и требует железной дисциплины пользователей, которые в некоторых узлах взаиморасчетов сами должны поддерживать ручной учет (и не допускать автоматического), а в некоторых - тщательно избегать ручного указания документов. И в то же время, этот подход самый гибкий.
В любом случае, каким бы образом не велся учет в разрезе документов расчетов, если он проведен корректно, на выходе мы получаем таблицу долгов / авансов в разрезе образующих их документов. Это позволяет нам, например:
Учитывая вышеизложенное, мы получаем современную детализацию учета взаиморасчетов:
Узел взаиморасчетов:
Детальнее узла:
Эта детализация, в виде измерений, «втыкается» в регистр накопления или бухгалтерии, после чего по ней документами начинают проводиться остатки и обороты взаиморасчетов.
Например, на этом рисунке представлен фрагмент плана счетов конфигурации "Бухгалтерия предприятия 3.0 " в части субсчетов 60 счета, где для описания узла взаиморасчетов взведены субконто "Контрагенты", "Договоры" (Организация определена на уровне регистра бухгалтерии), а для учета по документам расчетов - свое одноименное субконто.
А здесь на рисунке представлено описание регистра "Взаиморасчеты с контрагентами" из конфигураций "Управление торговлей 10.3", "Комплексная автоматизация 1.1" и "Управление производственным предприятием 1.3". Конкретно в этом регистре не ведется учет по документам расчетов, остальные же измерения соответствуют вышеописанной детализации.
Прошу также обратить внимание, что в регистре используется два ресурса - СуммаВзаиморасчетов учитывает сумму расчетов в валюте взаиморасчетов (обычно рубль, но для договорах в валюте и условных единицах - в валюте, заданной в договоре), а СуммаУпр - в валюте управленческого учета (которую большая часть здравомыслящих пользователей выбирает "Рубль", а крики мучений совершивших ошибку мне до сих пор слышатся в самых страшных кошмарах).
К регистру, на котором ведется учет, должен прилагаться отчет в виде простой ведомости, который предоставит пользователю аналитические данные и позволит проводить контрольные мероприятия.
Так, в КА/УПП, для регистра бухгалтерии "Хозрасчетный" используется комплект бухгалтерских отчетов (оборотно-сальдовая ведомость, анализ счета и др.), а для регистра накопления "Взаиморасчеты с контрагентами" - отчет "Ведомость по взаиморасчетам с контрагентами".
Такая модель должна быть в идеале, но на практике, опять таки, все немного сложнее, о чем, в частности, пойдет речь в разделах 3 и 4.1.
Теперь необходимо рассмотреть контуры учета. Нас интересуют два основных - управленческий и регламентированный .
С этой точки зрения конфигурации 1С можно условно поделить на те, которые способны вести учет только в одном контуре (все «Бухгалтерии» - регламентированный, или «Торговля и Склад 9.2», «Управление небольшой фирмой» - управленческий), те, которые способны вести независимый или связанный учет в двух контурах (УПП 1, КА 1), и те, которые тщательно делают вид, что могут вести два контура, но без доработок - все-таки только один (например, «Управление торговлей 10.3»).
Управленческий учет предназначен для отражения того, что случилось в жизни предприятия (холдинга) на самом де с точки зрения руководителя или собственника предприятия. Регламентированный учет - с точки зрения того, как это отображается государству.
В двухконтурных конфигурациях документ может быть отражен либо в каком-то одном контуре, либо сразу в двух. Некоторые документы имеют ограничения, например, банковские документы всегда отражаются в управленческом учете. На рисунке представлен фрагмент формы документа "Реализация товаров и услуг" из конфигурации КА 1.1, где зеленым обведены флажки, регулирующие включение в учет. Хотя здесь регламентированный учет представлен двумя флажками (бухгалтерского и налогового учета), их крайне желательно использовать вместе, в то время, как управленческий учет можно использовать отдельно:
Бурное воображение может подсказывать нам про черную кассу, которая отражается в управленческом учете, но не отражается в регламентированном. Да, на этот вопрос можно посмотреть и с этой стороны, но лично я туда не пойду. Даже не вступая в противоречие с УК и НК РФ, можно встретить достаточно много легальных ситуаций, в которых операция может отражаться только в одном контуре учета, и не отражаться (отражаться иначе) в другом.
Так, например, в холдинге может находиться две организации, которые, в силу хозяйственной необходимости продают друг другу товары. В регламентированном учете операция продажи однозначно отражается (реализация - поступление), в то время, как собственник холдинга вправе считать, что в управленческом учете это его же товар, который просто сменил склад (перемещение), или вообще остался на месте, и не отражать это в данном контуре.
В похожем базисе существуют также внутренние займы, аренда у своих же ИП, находящихся на 6%-ной упрощенке, услуги управления одной организацией другой, и др., ситуации - эти взаиморасчеты есть в регламентированном учете, а в управленческом - нет.
Есть также случаи, когда мы разрываем дату оформления документов и фактического производства хозяйственной операции. Причины разные. Либо потому что гражданское право плохо стыкуется с налоговым (например, потому, что в договоре может быть очень странно прописана дата перехода права собственности на товар, и, с учетом длительной дороги, эта дата значительно отличается от даты поступления на склад), либо потому, что правовое обоснование сделки оговаривается позднее совершения операции (принятый на склад возврат товаров, который потом оформляют либо как отказ от договора купли-продажи, либо как гарантийную замену, либо как корректировку / исправление реализации).
Кроме того, очень часто целесообразно не засорять регламентированный учет чрезмерной аналитикой, которую все равно не будут способны понять и оценить проверяющие, а выбрать разумный и объяснимый уровень огрубления, не противоречащий ПБУ и НК РФ, и никого не раздражающий. В то же время, в управленческом учете иметь детализацию, необходимую для работы. Речь, например, идет о том, что для целей производства важно знать вид покрытия какой-либо детали (поместив этот признак в характеристики), и отслеживать затраты позаказнт, а для целей бухучета можно просто отражать результат работы смены, без заказов, и использовать учет не глубже номенклатуры.
В конечном итоге, все эти нюансы можно отразить в одной двухконтурной системе учета посредством разработки правильной схемы, в рамках которой мы будем отражать хозяйственные операции определенными типовыми документами конфигурации, и взводить флажки нужных контуров учета. Да, иногда одна и та же операция будет повторена в двух контурах учета с разной детализацией и в разное время.
Либо изначально следует рассмотреть вопрос ведения двух контуров учета в двух различных информационных базах.
Кстати, часто заказчики обращаются с ситуацией, когда они уже долгие годы внедряют одноконтурную конфигурацию (обычно изначально бухгалтерскую), но в процессе внедрения ее переросли. Они крайне недовольны ее функциональностью, и прилепили уже на нее столько костылей, что она стала визуально похожа на ежика, а фактически не может даже хромать. А на самом деле им просто нужна двухконтурная конфигурация и правильная схема.
Мы рассмотрели модель взаиморасчетов и два контура учета. Рассмотрим, какие структуры данных для учета взаиморасчетов используются в конфигурациях КА 1 и УПП 1 (см. рисунок).
В управленческом контуре за взаиморасчеты отвечают два регистра накопления. Основной - «Взаиморасчеты с контрагентами», и вспомогательный - «Взаиморасчеты с контрагентами по документам расчетов». Первый используется для отражения взаиморасчетов всегда, и накапливает общие данные - с детализацией «Организация - Контрагент - Договор - Сделка (счет, или заказ, если такой способ ведения указан в договоре)). Второй используется для учета по узлам в разрезе документов расчетов (если в договоре взведен признак «Вести учет по документам расчетов».
По данным этих регистров работает большое количество «управленческих» отчетов по взаиморасчетам, которыми, чаще всего, пользуются менеджеры. Эти же отчеты (а также регистры, принцип и порядок учета взаиморасчетов) используются в конфигурации «Управление торговлей 10». Видите в конфигурации «серенький» отчет по взаиморасчетам? Скорее всего он выбирает данные из регистра «Взаиморасчеты с контрагентами».
В регламентированном контуре единственным источником отчетной информации является комплект бухгалтерских аналитических отчетов (оборотно-сальдовая ведомость, анализ счета и др), которые выбирают данные их регистра бухгалтерии «Хозрасчетный» (и плана счетов бухгалтерского учета). При этом, узел взаиморасчетов включает в себя всего лишь организацию, счет учета и два субконто - контрагент и договор (см. рисунок).
Мало? Не стыкуется с 1.2-1.4? Верно. Истинный учет взаиморасчетов в регламентированном учете ведется совсем не там. Существуют два регистра накопления, которые на самом деле используются для ведения большей части взаиморасчетов, а в бухгалтерский учет попадают лишь проводки по их данным. Это «» и «». Первый регистр обеспечивает учет расчетов по договорам вида «С поставщиком», «С комитентом», второй - «С покупателем», «С комиссионером». При этом, договоры с видом «Прочее» ведутся только на бухгалтерском регистре (плане счетов), и в упомянутых регистрах накопления никак не фигурируют, и не должны.
Следует заметить, что существует небольшая путаница с названиями. В конфигураторе эти регистры носят, соответственно, названия «РасчетыПоПриобретениюВУсловныхЕдиницахОрганизации », «РасчетыПоРеализацииВУсловныхЕдиницахОрганизации », хотя их синонимы - «Расчеты по приобретению (бухгалтерский учет) » и «Расчеты по реализации (бухгалтерский учет) » почти повторяют и имена и синонимы смежных по назначению регистров сведений c именами «РасчетыПоПриобретениюОрганизации », «РасчетыПоРеализацииОрганизации ». Они тоже нужны и важны, но мы их в настоящей статье не рассматриваем.
Детализация учета в вышеупомянутых регистрах накопления более глубокая, чем на плане счетов (см. рисунок): узел взаиморасчетов, кроме привычного трио "Организация-Контрагент-Договор" имеет счет учета, сделку (выделено зеленым). Детализация также ведется в разрезе документов расчетов (выделено желтым). Почти вся автоматика проведения документов ориентирована на выборку остатков не со счетов учета взаиморасчетов бухгалтерского регистра, а из регистров накопления.
Опять обращу внимание на наличие двух ресурсов, один из которых хранит сумму в валюте взаиморасчетов по договору, а второй - в валюте регламентированного учета.
При этом, например, в бухгалтерских конфигурациях (Бухгалтерия предприятия 2.0, 3.0) учет по сделкам отсутствует в принципе (плодите мнимые договоры, если нужно разделить взаиморасчеты в рамках одного реального договора), а учет по документам расчетов осуществляется на бухгалтерском регистре, путем использования третего субконто - «Документ расчетов» (см. рисунок из 1.4 с планом счетов).
Почему в КА/УПП учет по сделкам и по документам расчетов не сделан через субконто бухгалтерского регистра - вопрос сложный. Может быть дело в том, что вышеупомянутые конфигурации имеют в себе бухгалтерский модуль конфигурации «Бухгалтерия предприятия» версий 1.5 и 1.6, где еще не было такой парадигмы. Может быть в том, что конфигурации рассчитаны на большой объем данных, а выбирать запросами из регистра накопления куда производительней, чем из регистра бухгалтерии. А может в том, что для добавления еще двух субконто (сделку и документ расчетов) пришлось бы увеличивать количество возможных субконто, отказываясь от традиционного числа 3. Возможно, где-то это все описано разработчиком технологии, а я просто не знаю, тогда прошу прощения за невежество.
Такая разветвленная система с множеством смежных и дублирующих друг друга участков крайне неустойчива, и способна приводить к целому ряду возможных ошибок ведения учета, о которых будет рассказано в следующем разделе.
В предыдущей части мы рассмотрели модель учета взаиморасчетов, определение узла взаиморасчетов, вопросы ведения учета в управленческом и бухгалтерском контуре, и структуры данных, используемые для учета взаиморасчетов в конфигуациях «Комплексная автоматизация 1.1» и «Управление производственным предприятием 1.3».
Там было много теории и абстракций, без которых, однако, крайне тяжело пояснять информацию этого раздела.
В этой части речь пойдет о типичных ошибках ведения учета взаиморасчетов, способах их выявления и устранения.
При внедрении конфигураций есть вероятность настроить детализацию взаиморасчетов для целей управленческого учета таким образом, что это вызовет неудобства в регламентированном учете, или вообще выведет его за правовое поле.
В разделе 1.4 мы оговорили модель взаиморасчетов, в рамках которой узел с нужной детализацией помещается в регистр, по которому проводятся обороты. Какой-либо отчет выводит необходимые данные. С учетом изложенного в разделе 2 (то есть двух контуров учета - управленческого и регламентированного) у нас, казалось бы, есть все степени свободы настройки детализации - по сделкам, по документам расчетов... Но нет. У нас имеется конкретная конфигурация, и с учетом изложенного в разделе 3, следует рассмотреть, какие есть в ней технические ограничения (я не полагаю их ошибками, это, скорее, by design). Перечислим их:
1. Включение детализации учета взаиморасчетов в разрезе сделок (счетов или заказов), к сожалению, применяется к обоим контурам учета (и к регламентированному, и к управленческому) одновременно.
Здесь следует отметить следующее. В действующей нормативной базе в области учета взаиморасчетов (НК РФ, ПБУ, 402-ФЗ) не прописана аналитика раздельного ведения взаиморасчетов, это является элементом учетной политики. Однако, имеются требования к формированию показателей «Дебиторская задолженность», «Кредиторская задолженность» в бухгалтерской отчетности (не допускается их искусственное взаимное завышение, как и зачет между ними), а также есть ограничения в смежных участках учета, связанные с понятием сделки на стыке ГК РФ и НК РФ, например — в НДС с авансов, в валютных расчетах и расчетах в условных единицах.
Для всевозможных проверяющих (налоговики, аудиторы и др.) наиболее привычным является вариант ведения учета по договору в целом, с привязкой к бумажным договорам. Это легко обосновывается, хорошо стыкуется с имеющимися бухгалтерскими отчетами и регистрами налогового учета, не требует дополнительных пояснений.
Любые дополнительные углубления детализации взаиморасчетов, приводящие к наличию «встречного» сальдо по одному договору, т.е. когда на какую-то отчетную дату по одному контрагенту и одному договору имеется и долг и аванс, требуют дополнительной расшифровки стандартных бухгалтерских регистров для обоснования:
что, в свою очередь нуждается в проработке на уровне учетной политики (в части закрепления используемой детализации и расшифровывающих ее бухгалтерских регистров) и/или договоров с контрагентом (в части закрепления порядка погашения однородных требований).
Поэтому, если в вашей информационной базе ведется два контура учета, и вы не можете (или не хотите) по вышеизложенным причинам включить разделитель учета по сделкам, чтобы он не влиял на авансы и долги в реальном бухучете, но вам при этом крайне важно понимание оплаченности каждого заказа, то есть два варианта:
а) вы можете совместно использовать регистры накопления «Заказы покупателей» и «Расчеты с контрагентами» (!!! НЕ взаиморасчеты, а имено "расчеты") в разрезе заказов чтобы определить отгруженность, оплаченность заказа, а разница между ними как раз будет виртуальной задолженностью (авансом) по заказу.
б) можно пойти другим путем, и доработать конфигурацию так, чтобы детализация по сделкам не выносилась в регламентированный учет, сохранившись чисто в управленческом (например, для менеджеров).
3. В регламентированном контуре учет по документам расчетов ведется по умолчанию автоматически, по принципу FIFO (см. 1.3), а в управленческом учете не ведется вообще. Если включить в договоре признак ручного учета «Учет по документам расчетов», то для данного договора ручной учет по документам расчетов будет включен одновременно и в управленческом учете, и в регламентированном.
Это крайне неудобно! Если вы вдруг решили организовать ручной учет по документам расчетов в управленческом учете, то это автоматически полезет в регламентированный учет, что вызовет те же проблемы, что были тремя абзацами выше. Здесь тоже два варианта:
а) вы подводите «научную базу» в регламентированном учете под схему управленческого, то есть, обосновываете на уровне учетной политики, не противоречащей законодательству, то, что платеж может закрывать не наиболее старую по времени задолженность (как "по умолчанию" указано в ст. 319 ГК РФ), а некую произвольную, естественно, согласно какому-то принципу (см. пример с ЖКХ в разделе 1.3).
б) конфигурация дорабатывается таким образом, чтобы в регламентированном учете всегда оставался автоматический учет по документам расчетов (по опыту — громоздкая и неудобно обновляемая доработка).
4. В управленческом контуре учет по документам расчетов бывает либо ручной, либо его нет вообще (определяется признаком «Учет по документам расчетов» в договоре). Автоматического режима нет.
Поэтому, если мы, чисто ради управленческого контура, не хотим вести массовый ручной учет по документам расчетов по всем контрагентам (в основном, тщательно изображая FIFO), это резко ограничивает нас в выборе данных о просроченной задолженности именно из регистров управленческого учета (см. раздел 2 первой части статьи на предмет причин отклонений управленческого учета от бухгалтерского). Кроме того, часть, связанных со сроками, типовых отчетов о задолженности, а также механизм контроля глубины задолженности, также отказываются работать.
Все это приводит нас к тому, что несмотря на видимое богатство способов ведения учета взаиморасчетов, при наличии в одной базе двухконтурного учета, куда бы мы не двигались — везде будут вилы: либо в том, что не работает программа, либо в том, что мы нагребаем много ручной работы, либо в том, что не получается удержать регламентированный учет в правовом поле.
К сожалению, каких-то «серебрянных пуль» здесь нет. Конфигурации КА и УПП достаточно грубо слеплены из «Управления торговлей 10.3» и «Бухгалтерии 1.5/1.6», и несмотря на многообразие детализации учета в первой, вторую конфигурацию об этом, похоже, никто не предупредил.
Приходится либо тщательно классифицировать виды отношений с контрагентами, разрабатывать для каждого согласованную, между управленческим и регламентированным контурами, схему ведения взаиморасчетов, подбирать точечные доработки, либо изначально отказываться от ведения двух контуров учета в одной информационной базе, используя две различные базы, что тоже требует значимого объема человеческих ресурсов и организации всевозможных загрузок-выгрузок (с проблемами сопоставлений и задвоений).
Положения этого раздела справедливы, даже если КА/УПП используется только для ведения регламентированного учета (без управленческого), только для расчетов по приобретению и реализации .
Как было описано в разделе 3, конфигурации КА и УПП имеют крайне разветвленную структуру данных для хранения взаиморасчетов, и даже в регламентированном контуре истинный учет большинства взаиморасчетов ведется не плане счетов (регистрах бухгалтерии), а на регистрах накопления «Расчеты по приобретению», «Расчеты по реализации» (далее — просто «на регистрах»).
Помним, что почти вся автоматика проведения документов ориентирована на выборку остатков не с плана счетов, а из регистров накопления.
Это вызывает, мягко говоря, некоторые неудобства.
Собственно, проблема не в специфической организации учета, а в том, что нет ни одного типового отчета, который бы отображал данные регистры накопления в виде простой ведомости. Можно использовать универсальные отчеты, но простому пользователю это не очевидно, а как показывает практика, иногда даже сертифицированные внедренцы из команд крупных интеграторов, снизошедших внезапно до нашей провинции попилить большие бюджеты, при совместной работе, с удивлением открывают для себя всю опубликованную в данной статье информацию.
Несмотря на то, что ни одного отчета нет, контрольные мероприятия и поиск ошибок необходимо организовывать именно по данным этих регистров, куда в первую очередь поступают данные. А оборотно-сальдовая ведомость, составляемая по бухгалтерскому регистру, носит уже вторичный характер .
Несоблюдение правильного места приложения контрольных мероприятий приводит нас к классическому сценарию развития событий, описываемом следующими шагами:
Рассмотрим основные ошибки, приводящие к несоответствию учета на плане счетов и на регистрах:
1. Использование операций, введенных вручную . Проводки по регистру бухгалтерии сделаны операциями, введенными вручную, без параллельной корректировки регистров накопления (назовем это свободными проводками ).
Движения по регистрам накопления сделаны корректировками записей регистров , при этом бухгалтерские проводки не сделаны (обратная ситуация, редкая и подразумевающая, что кто-то вообще в курсе регистров накопления, но все таки).
2. Неправильный выбор вида операции в платежных документах. Движения сделаны только по регистру бухгалтерии,платежными документами с видом операции "Прочее поступление/списание денежных средств" (при этом указан правильный корсчет и контрагент/договор), вместо вида операции, относящегося к соответствующему виду договора ("Оплата от покупателя", "Возврат покупателю", "Оплата поставщику", "Возврат от поставщика"), что фактически означает свободную проводку в корреспондирующую аналитику (движений по регистрам накопления нет).
3. Неправильное заполнение сумм в платежных документах : указаны разные рублевые суммы в левой и правой половине формы и т.п.), что легко допустить при вводе документов копированием. См. рисунок:
4. Неправильно выполненные корректировки долга (несхождение сумм в трех колонках табличной части, использование вида операции "Перенос задолженности" или "Списание задолженности" там, где необходимо использовать "Взаимозачет", особенно часто распространено использование вида операции "Списание задолженности" для переноса сумм между счетами учета взаиморасчетов (что опять-таки означает свободную проводку в аналитику, указанную на закладке "Счета учета", поэтому там не должны использоваться счета 60, 62, 76.05, 76.06). Вопрос ввода корректировок долга подробнее оговорен в разделе 4.3.
5. Неконсистентные данные в документах в результате неправильных автоматизированных манипуляций при различных выгрузках/загрузках и групповых обработках (незаполненные скрытые реквизиты, договор несоответствующего вида (например «с поставщиком» — в реализации)), причем некоторые ошибки не обнаруживаются при проведении, т.к. во многих типовых документах логика проверки заполнения реализована в форме документа (а при выгрузке/загрузке и групповых обработках форма не открывается, и эта логика, соответственно, не выполняется). Отдельно следует оговорить состояние, когда данные документа не соответствуют его проведению (сначала провели с одними данными, а потом записали в документ другие данные, не выполнив перепроведение).
6. Нарушение порядка учета ручного учета по документам расчетов (погашение платежным документом будущих долгов, зачет документом поступления/реализации будущих авансов и др., в результате чего по разным ресурсам разных регистрам проводятся несоответствующие друг другу суммы, что будет более подробно изложено в п. 4 раздела 4.3).
7. Технические проблемы . Мистика, ошибки в информационной базе, нетиповые доработки и др. ситуации, с которыми нужно звать специалиста.
Для выявления таких ситуаций необходимо регулярно выполнять следующее контрольное мероприятие : на какой-то выбранный момент времени сверить остатки взаиморасчетов по плану счетов (бухгалтерскому регистру) и по регистрам накопления .
А именно, можно воспользоваться оборотно-сальдовой ведомостью (анализом счета), вместе с ней составить универсальный отчет по одному из рассматриваемых регистров накопления, сгруппировав данные примерно так же как в бухгалтерском отчете, после чего сравнить их визуально, или в Excel/Calc, на предмет равенства.
Для автоматизации данного контрольного мероприятия (сверки остатков) в условиях большого количества узлов взаиморасчетов можно воспользоваться , пример использования с картинками описан в этой же публикации.
К сожалению, этот отчет сверяет только остатки в регистре бухгалтерии и регистрах накопления. Удобный оборотно-остаточный сверочный отчет я сделать не смог из за несколько разных принципов формирования движений при зачете авансов: не удается сопоставить обороты в одном запросе. Поэтому поиск точного момента ошибки придется выполнять «нащупывая» шагами, или половинным делением, дату, вперед от периода, когда еще не было расхождений, к текущему, или наоборот.
В случае выявления ошибок в остатках следует локализовать период ошибки, выполнить перебор документов по узлу и их проверку согласно вышеописанному перечню. После того, как нарушения будут устранены, восстановить последовательность, выполнить проведение по регистрам НДС, повторить контрольное мероприятие.
В результате будет устранен наиболее грубый уровень ошибок, после чего можно приступить к дальнейшему этапу.
Условия применения информации из данного раздела такие же, как и у 4.2 (в базе ведется регламентированный учет, неважно, есть ли управленческий). Предполагается, что рекомендации 4.2 исполнены, и остатки регистров на конец анализируемого периода совпадают с планом счетов.
В этом случае, даже при совпадении остатков, пользователи могут вести учет так, что это нарушает методику, которую разработчик технологии заложил в систему, на уровне применения счетов и субсчетов, и порядка погашения долгов / зачета авансов.
В регламентированном учете, при этом, могут наблюдаться следующие очевидные проблемы:
а) на субсчетах долга и аванса счетов 60 и 62 присутствует «красное» сальдо. То есть, у нас имеются отрицательные долги или авансы;
б) на субсчетах *1 и *2 счетов 60 и 62 присутствует одновременно и долг и аванс по одному договору;
в) в случае, когда мы ожидаем погашение долга, у нас образуется аванс (т.е., приходим к ситуации 2), а долг: не погашается вообще; погашается не полностью; долг погашается, но вместо образования аванса, становится красным (приходим к ситуации 1);
г) зеркальная пункту в) ситуация с зачетом авансов (аванс не погашается; аванс погашается частично, и при этом образуется долг; аванс становится красным).
Чуть выше я назвал эти проблемы очевидными, т. к. ошибка сразу визуально наблюдается в бухгалтерских отчетах по счетам 60 и 62. Но истинная ошибка возникла изначально не в регистре бухгалтерии, а в регистрах накопления. В регистре бухгалтерии мы увидели ее только потому, что счета 60 и 62 разделены субсчетами на долг и аванс, и каждый из этих субсчетов либо активный, либо пассивный.
Однако, расчеты с поставщиками и покупателями могут вестись на и счетах 76.05, 76.06, 76.09, а также аналогичных субсчетах для учета в у.е. (76.3x) и в валюте (76.2x). Эти субсчета не делятся на аванс и долг, являются активно-пассивными, поэтому ситуации а)-г) там визуально заметны не будут, но тем не менее, ошибки в регистрах накопления все равно могут быть.
Это может вызвать те же последствия — неправильный НДС с авансов, валютные или у.е.-шные расчеты, переоценки, курсовые разницы, но вы даже не будете об этом знать до проявления каких-то очевидных признаков ошибок в смежных участках.
Важно также отметить, что ошибочные ситуации а)-г) мы видим в оборотно-сальдовой ведомости по счетам взаиморасчетов, которая ограничена детализацией не глубже договора. Наши же узлы взаиморасчетов могут быть разделены сделками. В этом случае, одновременный аванс и долг по одному договору могут быть вполне нормальным явлением: аванс по одной сделке, долг по другой сделке, а в оборотно-сальдовой ведомости эта детализация недоступна, поэтому если речь идет о счетах 60, 62 — мы увидим развернутое встречное сальдо в разных субсчетах, а в счете 76.05, 76.06, 76.09 — свернутое сальдо.
Для выявления проблемных ситуаций описанных в данном разделе, следует использовать отчет и контрольные мероприятия №4-5, . Вы можете также воспользоваться универсальным отчетом, хотя это и менее удобно.
Рассмотрим основные причины ошибок и способы их устранения.
1. Невосстановленная последовательность взаиморасчетов.
Устранение.
Восстановить последовательность, повторить контрольное мероприятие. Если не помогло — переходить к следующим пунктам.
2. Подстановка неправильных пар счетов учета долга/аванса в документы.
Неправильно:
60.01/60.01, 60.02/60.02 и все в этом роде. Обычно возникает, когда мы пытаемся «принудить к миру» алгоритм зачетов аванса. Не делайте так. В подавляющем большинстве случаев программа сама способна разобраться с авансами и долгами, хотя ее логика и сложная/странная. Ошибка, ваша уже далеко позади, ищите ее в прошлом, текущий документ работает неправильно лишь потому, что видит неправильные остатки по регистрам накопления. Правильно:
указывать разный субсчет аванса и субсчет долга (т. е. 60.01 / 60.02), если для данного счета заведены отдельные субсчета для авансов и долгов.
Неправильно: 60.01/60.22. Вероятно, операторская ошибка, в результате которой долг находится на рублевом субсчете, а аванс — на валютном. Правильно: указывать соответствующие друг другу пары счетов долга и аванса (60.21/60.22, 60.31/60.32 и т.п.).
Неправильно: 76.05/76.06. Это в бухгалтерии 4.5 платформы 7.7 для расчетов с прочими дебиторами и кредиторами имелись раздельные субсчета аванса и долга, а здесь 76.05 — расчеты с прочими поставщиками, а 76.06 — с покупателями. Правильно: Для субсчетов 76 счета не открыты отдельные подсубсчета для авансов и долгов, поэтому в оба поля указываем одно значение — либо 76.06/76.06, либо 76.05/76.05.
Счета подставляются почти в любой документ - в платежные, отгрузочные документы, корректировка долга - явно, или через механизм умолчаний, задаваемых через регистр сведений "Контрагенты организаций".
Устранение. Расшифровать соответствующую строку ОСВ или отчета по регистрам накопления по регистратору, открыть и осмотреть каждый регистратор, проверить правильность указания счетов (явно или по умолчанию). Исправить при необходимости, провести. Убедиться, что этот конкретный документ сформировал правильные движения и проводки по зачету авансов / погашению долгов.
Поскольку у вас только что откатилась последовательность, перейти к пункту 1 выше, либо вручную перепровести документы по данному узлу взаиморасчетов хронологически от точки правки до текущего момента.
3. Неправильное использование документов «Корректировка долга».
Про использование корректировок долга в КА/УПП, вероятно, следует написать целую книгу. В этих документах крайне легко допустить ошибку, и описать все возможные проблемы в этой статье не представляется возможным.
Если вкратце, то во-первых, следует обращать внимание на вид операции.
Во-вторых, следует обратить внимание на то, что корректировка долга, при отражении во всех контурах учета, спрашивает с вас для каждого узла до 3 (трех) сумм, которые в подавляющем большинстве случаев должны быть равны. Одна сумма — в валюте взаиморасчетов, вторая — в валюте учета, и третья — для принятия к налоговому учету (см. рисунок):
Впрочем, если эти суммы отклоняются, то вы это должны были заметить еще при проверках по разделу 4.2, либо в налоговом учете вне рамок данной статьи.
В-третьих, для двухконтурного учета, следует понимать, как должны быть включены флажки отражения в управленческом и регламентированном учете в случае этого узла взаиморасчетов (см. раздел 2 на предмет примеров плановых отклонений учетов друг от друга).
Напомню также, что все, что было сказано в пункте 2 данного раздела про пары счетов, в полной мере относится и к корректировкам долга.
Локализация - как в следующем пункте, поскольку в регистрах образуются такие же проблемы. Устранение - расшифровать узел взаиморасчетов по регистратору, осмотреть все корректировки, найти расхождения в суммах, устранить, провести. Перейти к пункту 1 про последовательность.
4. Нарушение порядка учета по документам расчетов при включенном ручном учете.
Допустим, мы пытаемся принять оплату, указав вручную документ долга (см. рисунок):
Предположим, что происходит опытка зачесть аванс (погасить долг) в большем объеме, чем он есть на остатках. В этом случае выводится сообщение:
Проведение документа: Платежное поручение входящее ТТ-00003245 от 10.02.2017 0:00:00 (Оплата от покупателя)
Указана сумма взаиморасчетов, превышающая непогашенный остаток по документу расчетов с контрагентом!
Договор: <Здесь название вашего договора> от 31.01.2017, сделка не указана, документ расчетов: Реализация товаров и услуг ТТ-00000620 от 31.01.2017 23:00:00;
Остаток 0 руб.; указана сумма 10 000 руб.; превышение 10 000 руб.
Пусть вас не смущает словосочетание «сделка не указана» - речь идет лишь о том, что учет по сделкам отключен, и заказ (счет) не указан в данном узле взаиморасчетов. Основная мысль здесь выделена жирным. Остаток задолженности по документу реализации товаров и услуг ТТ-00000620 отсутствует, а вы пытаетесь его погасить в сумме 10 000 рублей. В принципе, проводки будут сделаны, и подвоха в них не будет: Дт 51 — Кт 62.01. А вот в движениях по регистру накопления будет "небольшая" проблема (см. рисунок):
В ресурс «Сумма взаиморасчетов» помещена сумма, а в «Сумма бух. учета» нет.
В нашем примере остаток погашаемого долга был 0, но он вполне бы мог быть в сумме меньшей, чем предполагается погасить. И последствия будут примерно такие же: суммы в двух ресурсах не будут совпадать - в «Сумма бух. учета» будет записан лишь доступный остаток долга.
Такие же проблемы возникают, когда в документе мы пытаемся погасить долг (зачесть аванс) в правильной сумме, но по документу расчетов, который находится в будущем. Действительно: ведь на момент проведения текущего документа долга (аванса) по целевому документу еще нет в природе — он появится позже.
Поскольку при отражении следующей, по этому узлу взаиморасчетов, хозяйственной операции, автоматика проведения будет анализировать остатки регистров накопления, отсутствие в ней суммы приведет к неправильному зачету (образованию) аванса или долга, и начнется тот же порочный круг, который был описан в начале раздела (неправильные проводки, исправляемые неправильными проводками). Описанное расхождение ресурсов является большой проблемой, его нельзя допускать.
Иногда такая же проблема случается и при автоматическом ведении учета по документам расчетов. Устраняется обычно последовательным перепроведением документов (а вот восстановление последовательности помогает не всегда). Иногда такая проблема - лишь следствие более ранней ситуации расхождения по данному узлу взаиморасчетов.
Локализовать этот вид ошибки можно воспользовавшись , контрольное мероприятие №3.
Устранение: исключить техническую проблему проведения (попробовать перепровести документ, обновить контрольный отчет), затем проверить соответствие сумм для разных видов учета (если это корректировка долга или платежный документ). Убедиться, что по этому узлу взаиморасчетов не было ошибки раньше.
Разбираясь с нюансами соответствия регламентированного учета "самому себе", мы немного отвлеклись от управленческого. Положения данного раздела применяются, если в одной информационной базе ведется оба контура учета.
Как было указано в разделе 3, у управленческого учета свои регистры, по ним составляется свой комплект отчетов (часть из которых отражена на схеме в разделе 3 части 1 данной публикации), причем именно этими отчетами обычно пользуется «небухгалтерская» часть пользователей.
В этом случае предприятие фактически автоматизировано по двухконтурной схеме, хотя может и не догадываться об этом: есть управленческий и регламентированный учет, и обоими контурами пользуются разные люди.
По разным причинам, как было упомянуто в разделе 2, в управленческий и бухгалтерский учет могут планово попадать разные данные. Это образует отклонения, которые следует держать под контролем, и регулярно проверять, потому как могут образоваться и другие отклонения, вызванные ошибками .
Ошибки эти крайне распространены, потому что за чисто регламентированным учетом следят "процессуально близкие" к актам сверки бухгалтеры, вовремя поднимают тревогу, если что-то не так. А вот управленческий учет оказывается выбит из контрольных мероприятий, и живет сам по себе, постепенно отклоняясь из за забытых галочек и несхоящихся сумм в разных полях документов.
Поэтому часто работа предприятия, автоматизированное на УПП/КА, выглядит примерно так:
1. Бухгалтеры "в домике", смотрят взаиморасчеты в привычные еще с версии 7.7 «беленькие» оборотно-сальдовые ведомости. и других отчетов не признают. Контрольные мероприятия делаются чисто в регламентированном контуре, правки нередко накладываются операциями (о вреде которых написано в 4.2, но хотя бы бухгалтерские отчеты показывают что-то, близкое к правде).
2. Менеджеры смотрят в свои «серенькие» отчеты по управленческому учету, и про другие источники информации тоже не знают. Также они не знают, что их контур учета де-факто не работает, а успешно не знать об этом дальше им помогают экзотические отборы, которые "прячут" ошибки и нестыковки.
3. Супервизора (сводящего), мыслящего в двух контурах нет вообще.
4. За месяцы и годы работы между разными регистрами набежали существенные отклонения, и все отчеты показывают совершенно разные данные, которые, если поотключать имеющиеся отборы, не сходятся друг с другом на 10-40%.
5. По этой причине никто толком не знает, кто и сколько должен нам и кому мы. Все решают свои локальные задачи, а вышеизложенное противоречие никого не волнует до тех пор, пока очередное расхождение между контурами учета не пробьет отборы, и контора не прокосячит отправить (получить) пару фур товара или взыскать несколько миллионов просрочки.
Про взаимодействие пользователей в разных контурах учета вообще вспоминается анекдот: По реке, вниз по течению, плывет лодка. На корме сидит чукча, курит трубку. Жена гребет против течения, силенок мало, лодка все равно сплавляется вниз. Чукча думает: «Хорошо ей, греби себе да греби. А мне о жизни думать надо».
Основные причины возникновения отклонений:
Дополнительная причина:
Вышеописанное применяется теперь не только к расчетам по приобретению и реализации, но и ко всем остальным расчетам. Например, к займам и процентам по ним, финансовым вложениям, расчетам через третих лиц (включая судебных приставов) и др. Они же должны быть представлены не только в регламентированном, но и управленческом учете (и отображаться в упр. отчетах). А именно эти операции обычно делаются нетиповыми проводками, к которым сложно подобрать типовые документы так, чтобы одновременно двигался и регистр бухгалтерии, и регистр накопления упр. учета "Взаиморасчеты с контрагентами", и корреспондирующая аналитика тоже правильно двигалась и по плану счетов и по соответствующим регистрам (например, РАУЗ). Характернейший пример отражен в пункте 4 раздела 4.5.
Конкретно в участке взаиморасчетов для выявления отклонений следует сравнить остатки по анализу субконто «Контрагенты-Договоры» (который покажет нам данные регламентированного учета) и по отчету «Ведомость по взаиморасчетам с контрагентами» (который отразит данные управленческого). Затем локализовать день, когда возникли отклонения, составляя аналогичные сверки на прошлые периоды до тех пор, пока не найдется точка сходимости. Пересмотреть документы по проблемному узлу взаиморасчетов за этот день и устранить ошибку.
Для автоматизации данной процедуры могу порекомендовать и приложенное к нему контрольное мероприятие.
Кроме операторских ошибок, а также by-design ограничений учетной системы, затронутых в разделе 4.1, существует еще пласт проблем, которые, по характеру, ближе к ошибкам разработчика, и которые мешают нам, в некоторых случаях, комфортно жить.
1. При включенном учете по документам расчетов, документы «Корректировка поступления», «Корректировка реализации», в случае, если они на уменьшение, и должны образовывать авансы, относят суммы на неправильный субсчет (60.01, 62.01, вместо субсчетов 02), что лечится, к сожалению, только доработкой, или отказом от ручного учета по документам расчетов.
2. Если вы ведете взаиморасчеты в реальной валюте, или в условных единицах, то в бухгалтерском и управленческом учете переоценка задолженности будет происходить разными способами.
В бухгалтерском учете авансы в валюте и условных единицах не переоцениваются (примерно с 2010 года). Переоценке подлежат только долги. Но дело в том, что разработка модуля управленческого учета «замерзла» раньше, и в нем остался старый механизм переоценки, предполагающий переоценку и долгов и авансов.
Небольшие правки разработчик технологии, как я понимаю, все-таки предпринял. Для нового механизма нужен учет по документам расчетов, который в управленческом контуре УПП/КА автоматически не ведется (см. 4.1). Если вы включите ручной режим, то переоценка в управленческом учете будет осуществляться правильно, а если нет — то остатки рублевого покрытия в бухгалтерском и управленческом учете будут всегда отличаться. Здесь мы переходим к разделу 4.4 и наблюдаем расхождения в работе отчетов, работающих по разным контурам.
Как это "точечно" доработать, я лично пока не понял.
3. При использовании расчетов по возвратной таре, суммы проводятся по плану счетов, однако в регистрах накопления регламентированного и управленческого учета не отражаются.
Во-первых, это вызывает отклонения по контрольным мероприятиям пункта 4.4 в любом случае, а по 4.2 — если вы ведете обычные расчеты и расчеты по таре на одном субсчете (например, на 76.05 или 76.06), причем в последнем случае будет крайне тяжело выкинуть эти узлы взаиморасчетов из контрольных мероприятий каким-либо отбором по счету (ведь на этом счете живут другие, "нормальные" контрагенты, поэтому придется отбирать по списку договоров).
Во-вторых, это приводит к тому, что закрывающие корректировки долга и платежи по расчетам, связанным с возвратной тарой, нужно делать со своей особой логикой (добиваясь обратного тому, о чем я говорил в 4.1 — чтобы на этот раз проводки формировались, а движения по регистрам нет (поскольку их не было изначально)), чтобы не углублять ошибку.
Поэтому здесь рекомендации могут быть следущие:
1) Развести счета учета расчетов по возвратной таре и основных расчетов. Вообще, завести отдельные счета учета расчетов по возвратной таре (типа 76.10 / 76.11) — проще добавлять их каждый раз вручную в балансе, чем тратить время на обход этих «плановых» отклонений в контрольных мероприятиях.
2) Желательно добиться того, чтобы возвратная тара всегда сопровождалась отдельными накладными, не смешиваясь с основными товарами или услугами. Тогда и в информационную базу мы занесем их отдельными документами.
4. Списание дебиторской задолженности на затраты, либо прочие расходы. Начисление процентов по займам и кредитам (оприходование кредиторской задолженности за счет прочих расходов).
К сожалению, здесь мы вообще не можем правильно подобрать один документ, который сделал бы нам и проводки, и движения по регистрам накопления.
Если мы воспользуемся корректировкой долга, вид операции "Списание задолженности", то обнаружим, что у нас правильно сформировались все движения по участку взаиморасчетов, проводки в 91 счет (указанные на закладке "Счета учета" вместе с аналитикой) выполнены верно, но в регистр накопления управленческого учета затрат (Затраты или УчетЗатрат, в зависимости от того, используется ли партионный учет или РАУЗ) соответствующая сумма, как прочие затраты, не попала вообще. Если мы воспользуемся документом "Прочие затраты", который без проблем закредитует счет взаиморасчетов, задебетует 91 счет, и сделает движения в регистры учет затрат, то обнаружим, что с регистров накопления по учету взаиморасчетов сумма не списалась.
а) использовать вариант одновременной корректировки долга в обоих контурах учета, плюс документ "Прочие затраты" только в управленческом учете, а можно даже проконтролировать их соответствие друг другу и полноту ввода каким-нибудь костыльным отчетом;
б) доработать документ "Прочие затраты", чтобы он делал движения по регистрам накопления в участке взаиморасчетов;
в) доработать документ "Корректировка долга", чтобы он делал движения в регистры накопления учета затрат;
г) отказаться от управленческого учета затрат.
д) вести проценты по кредитам и займам только на плане счетов и исключить их из всех вышеописанных контрольных мероприятий.
Как только я припомню что-то еще, обязательно допишу, хотя я полагаю, что у каждого внедренца имеется маленькое кладбище, где он похоронил исправленные или обойденные ошибки разработчика технологии.
На этом пока все. Если вы дочитали до этого момента, хотел бы поблагодарить за внимание, и выразить надежду, что изложенная информация чем-либо помогла.
Чуть позднее, если позволит время, я постараюсь опубликовать подборку «хороших практик». Просто это настолько неисчерпаемая тема, что мне бы хотелось сначала понаблюдаю за вопросами, если таковые появятся, сопоставить с опытом и, возможно, дать в форме ответов. Кроме того, я не знаю, насколько еще актуально обсуждать, с точки зрения правильного ведения регламентированного учета, выводящиеся из эксплуатации конфигурации, которые с каждым годом будут все меньше соответствовать законодательству.
И здесь есть очень важный момент, поступивший платеж необходимо привязать к договору иначе платеж ляжет отдельно и взаиморасчеты не закроются. Продемонстрируем это: Клиент заплатил даже больше чем нужно 50 тыс. рублей. Но бухгалтер не указал Объект расчетов. Хотя можно было просто нажать кнопку Подобрать по остаткам и были бы подобраны суммы не оплаченных продаж. Теперь же возникла ситуация, что клиент фактически оплатил товар, но менеджер видит долг за клиентом в отчете Задолженность клиента, который он открывает из заказа. А вот что покажет отчет Ведомость расчетов с клиентами, который можно открыть из раздела Продажи. В отчете видно, что задолженность клиента образовалась по договору, а платеж прошел без договора. Хотя конечная сумма и положительная, это ситуация считается ошибкой и взаиморасчеты в УТ11 в регистре Расчеты с клиентами не закроются.
Посмотрим движения, которые сделает реализация: Мы закрыли строчку К отгрузки, теперь у нас, как у продавца нет долга перед клиентом, мы отгрузили товар. И появилась сумма в ресурсе Сумма — это основной ресурс регистра, клиент нам должен.
При оплате сумма будет закрыта движением по расходу. Объект расчетов в регистре все тот же заказ сколько бы не было реализаций.
Важно
Проведем оплату по безналичному расчету. Создадим документ Поступление безналичных ДС на основании документа Реализация товаров. Обратите внимание на реквизит Объект расчетов. Объектов расчетов может быть несколько, но поменять его нельзя.
Расчеты с поставщиками и подрядчиками Для того чтобы не путаться и понимать что к чему, существуют виды взаиморасчетов, которые сразу же подразделяют взаиморасчеты на:
Стоит обратить внимание на то, что эти два вида взаиморасчетов кардинально отличаются друг от друга, потому разработана специальная специфика ведения взаиморасчетов. Так, в том случае, если речь идет о взаиморасчете с поставщиком, то с ним может быть договоренность по выплате товара в кредит, или же на каких — либо других условиях.
Внимание
В свою очередь, если речь идет о подрядчиках, то документы ведутся только в бухгалтерии, и подрядчик лишь получает оговоренную с ним сумму. Это говорит о том, что бухгалтерия сразу же закрывает ведомости, и задолженности в данном случае бывают крайне редко.
Если этот флажок не устанавливать это будет означать, что реализация оплачена (со слов клиента), но пока платеж ещё не подтвержден банком. Ну и Объект расчетов тот же заказ. Все взаиморасчеты закрылись.
Долгов нет. Если вернутся и пробежаться по движениям регистра Расчеты с клиентами, то видно, как в разрезе одного объекта расчетов формируются приходы и расходы по суммам взаиморасчетов, отражая этапы расчетов с клиентом, а также общую фактическую задолженность в ресурсе Сумма. Настройка вариантов ведения взаиморасчетов На примере взаиморасчетов по заказам мы рассмотрели всю цепочку документооборота и движений по регистрам.
А как же настроить взаиморасчеты по договорам в торговле 11, например, спросите вы? Варианты взаиморасчетов настраиваются непосредственно в договоре.
При разнесении платежей, необходимо указывать именно тот заказ, по которому осуществлялась отгрузка, в противном случае получиться результат, который демонстрирует следующий пример: В документах «Реализация товаров и услуг 001» и «Платежное поручение 001» в качестве связующей сделки выбран «Заказ покупателя 001», поэтому в отчете эти документы сгруппированы в рамках одной сделки: «Заказ покупателя 001». А в документе «Платежное поручение 002» вместо «Заказа покупателя 002» ошибочно был выбран «Заказ покупателя 003».
Контрагент Сумма взаиморасчетов Договор контрагента Нач. остаток Приход Расход Кон. остаток Сделка Документ движения (регистратор) Покупатель-1 16 000,00 16 000,00 ОД-2 , руб.
Также можно оформить протест, который составляется даже до того как истечет окончательный срок предъявления чека. Если документ будет представлен в последний день данного срока, то в таком случае протест в конечном итоге можно составить уже на следующий рабочий день.
Стоит отметить, что чекодержатель в обязательном порядке должен известить своего чекодателя и индоссанта об отсутствии платежа на протяжении двух рабочих дней, которые следуют за днем оформления протеста. Таким образом, основные виды расчетов позволяют значительно упростить процедуру оплаты и сделать ее общедоступной.
Читайте также
Подробнее … Статьи по 1С УТ11:
Сайт посвящен конфигурации 1C:Управление торговлей 11.
По контрагенту «Покупатель-2» из таблицы видно, что сделав авансовый платеж на сумму 15000 рублей и получив товар на сумму 11000 рублей, наша организация осталась должна отгрузить товар еще на сумму 4000 рублей. А теперь выясним, как определить размер текущего долга.
ПРИМЕЧАНИЕ Обратите внимание на то, что столбцы в заголовке таблицы выделены разными цветами. Столбцы, выделенные оранжевым цветом это измерения, зеленым – ресурсы Контрагент Договор Сумма Покупатель-1 ОД-1 (руб.) 10000 Покупатель-1 ОД-1 (руб.) -7500 Покупатель-2 ОД-2 (руб.) -15000 Покупатель-2 ОД-2 (руб.) 11000 ВАЖНО Чтобы получить состояние взаиморасчетов необходимо просто свернуть существующие записи таблицы (регистра) по одинаковым значениям измерений, суммируя значения ресурсов.
В этом случае в число арендаторов входит третье лицо, не являющееся получателем или вносителем денежных средств, но выполняющим контролирующую функцию. Это может быть риэлтор, комиссионные которого тоже хранятся в этой же ячейке, как гарантия его заинтересованности в сделке.
Третий способ – «эксперт-сейфинг». При этой схеме сотрудник банка участвует в Соглашении выдачи ценных пакетов и контролирует сам процесс выдачи, согласно условиям Соглашения о взаиморасчетах по сделке. То есть, если в Соглашении написано, что ценный пакет может быть выдан продавцу после предоставления нотариальной копии Свидетельства о регистрации права собственности на имя Покупателя, сотрудник банка выдает ценный пакет с денежными средствами после получения требуемого документа.
Естественно, фиксируются все реквизиты предоставляемого документа, а также имена и фамилии сторон по сделке.
Мы увидим все три варианта взаиморасчетов: по заказам, по договорам и по накладным. Видно, что при расчете по заказам колонка Договор пустая.
При расчете по договорам надпись «По договору» — название договора. И при расчете по накладным выходит надпись «По накладным». Но если нужна более детальная информация, можно в настройках отчета на вкладке Структура включить группировку по объектам расчетов. Тогда отчет будет иметь следующий вид: Все взаиморасчеты будут сгруппированы по объектам расчетов.
Не путайте с регистратором. Регистраторов может быть несколько, а объект расчетов будет один. На этом я завершаю эту статью. В следующих статьях я отражу разные моменты возникающие при расчётах с партнерами, такие как контроль лимитов задолженности, использования графиков платежей и другие. В начало… Комментарии В начало…
Это справочник в котором хранится ключ вида (Партнер, Организация, Контрагент).
Сумма к оплате говорит о том, что собственно есть долг клиента и он должен заплатить «сумма к оплате» — так и звучит. Есть ещё вспомогательный регистр Расчеты с клиентами по документам, он всегда показывает расчеты в разрезе документов и служит для определения программой 1С оплачен Заказ клиента или Реализация или нет. Собственно мы видим в регистре, что есть сумма К отгрузки и сумма К оплате, пока и у нас есть долг перед клиентом и у него перед нами.
Сделка» и «Документ расчетов с контрагентами», в результате чего наша таблица приобретет следующий вид: Регистратор Контрагент Договор Сделка Документ расчетов Сумма + Реализация товаров от 30.09.2009 Покупатель-1 ОД-2 (руб.) Заказ покупателя от 21.09.2009 10000 — Платежное поручение входящее от 04.11.2009 Покупатель-1 ОД-2 (руб.) Заказ покупателя от 21.09.2009 10000 — Платежное поручение входящее от 01.11.2009 Покупатель-2 ОД-1 (руб.) Платежное поручение входящее от 01.11.2009 5000 + Реализация товаров от 03.11.2009 Покупатель-2 ОД-1 (руб.) Реализация товаров от 03.11.2009 15000 ПРИМЕЧАНИЕ Добавление очередного измерения говорит о том, что появляется дополнительный аналитический признак, благодаря чему мы имеем отчет с большей детализацией, т.е. можем проводить анализ в разрезе дополнительной аналитики.
