Содержание
1.1 Понятие узла взаиморасчетов
1.3 Учет по документам расчетов
2. Контуры учета и совмещение их ведения в одной информационной базе
3. Используемые структуры данных для ведения учета взаиморасчетов в КА 1 / УПП
4.1 Неправильная настройка детализации взаиморасчетов
4.3 Методически неправильное ведение взаиморасчетов в регламентированном учете
4.5 Ошибки учетной системы, не позволяющие вести учет каким-либо конкретным образом
Предисловие
На самом деле, данная статья запоздала, по меньшей мере, лет на 6. У меня давно были мысли выразить накопленный опыт в виде такой публикации, но все никак не случалось. Разгребал взаиморасчеты, поверите или нет? Шутка, конечно. Но даже до сих пор, несмотря на то, что конфигурации КА 1 и УПП вроде бы выводятся из эксплуатации, регулярно обращаются клиенты, у которых во взаиморасчетах бардак и хаос.
За это время собрались некоторые наработки, которыми бы хотелось поделиться с сообществом. Я полагаю, что будет полезно больше тем специалистам, которые сопровождают существующую автоматизацию в штате, поскольку, как я полагаю, франчайзи уже практически не внедряют данные конфигурации. Тем не менее, даже в новых конфигурациях используется близкая логика, и я хотел бы надеяться, что смогу понятно довести ключевые моменты, которые помогут читателям в будущем.
Объем знаний, который требуется передать, достаточно велик. Как ни хотелось ужаться, к сожалению, в рамках одной публикации сделать это не получится. Я постараюсь разделить текст по смыслу в несколько статей, и дополнительно выложить ряд внешних отчетов, для УПП/КА которые помогают в анализе и контроле. Некоторые из них можно заменить универсальным отчетом, некоторые «незаменимы».
Кроме того, не получилось сделать статью, ориентированную только на бухгалтера или только на специалиста. К сожалению, УПП/КА — не те конфигурации, которые можно внедрять, вести и контролировать, не влезая в смежные знания. Либо специалист должен разбираться совместно с бухгалтером, либо кто-то из них должен достаточно глубоко проникнуть мыслью в работу другого.
Данная часть больше теоретическая, в рамках которой я постараюсь зафиксировать и описать используемые понятия и термины, и показать их в сравнении с другими конфигурациями.
Введение
В конфигурациях «Комплексная автоматизация 1.1» и «Управление производственным предприятием 1.3» часто встречается ситуация, когда, по, кажется, непонятным причинам, на счетах 60.01, 60.02, 62.01, 62.02 образуются отрицательные остатки, встречное сальдо (одновременно присутствует и аванс и долг на разных субсчетах), внезапно возникают авансы и/или долги, которых не должно было случиться. И это только видимая «вершина айсберга».
Основными «пострадавшими» становятся: баланс (в котором неправильно разворачивается дебиторская и кредиторская задолженность), участок налогового учета НДС с авансов выданных и полученных (счета 76.АВ, 76.ВА). В случае валютных расчетов, либо расчетов в условных единицах, ситуация дополнительно осложняется тем, что у документов неправильно определяется рублевое покрытие, переоценка остатков происходит некорректно.
Многие пользователи начинают рефлексировать, исправляя ситуацию операциями, введенными вручную. Хотя формально «баланс сходится», однако это никак не помогает автоматизированно заполнить книги по НДС, распечатать отгрузочные документы с нужным рублевым покрытием.
Однако, проблему желательно решать системно, от начала. Для этого придется немного погрузиться в теорию. В первую очередь необходимо рассмотреть детализацию учета, которая применяется в 1С вообще, и в частности, в рассматриваемых конфигурациях. Затем — контуры учета (регламентированный и управленческий) — опять таки, вообще, и в рассматриваемых конфигурациях. И наконец, структуры данных, которые используются для ведения учета в рассматриваемых конфигурациях.
1. Детализация учета
1.1 Понятие узла взаиморасчетов
Традиционно, в конфигурациях системы 1С: Предприятие учет взаиморасчетов ведется в разрезе договоров (привязанных к контрагентам и организациям). Назовем, для удобства, это сочетание «координат» (измерений) «узлами взаиморасчетов».
В бухгалтерских конфигурациях мы ведем учет еще и на разных счетах плана счетов, поэтому, для целей бухгалтерского учета, будем полагать, что определение узла взаиморасчетов дополнено счетом бухгалтерского учета. При этом, если к счету открыты отдельные субсчета для аванса и долга (например, 60.01 и 60.02), то один договор по ним мы все равно будем рассматривать как один узел по паре счетов. Так, на счете 60 у нас есть пара счетов для рублевых расчетов (60.01, 60.02), пара счетов для валютных (60.21, 60.22), пара счетов для расчетов в условных единицах (60.31, 60.32)
Остатки и обороты взаиморасчетов в разрезе узлов проводятся в какой-либо регистр. В чисто бухгалтерских конфигурациях это в 90% случаев — регистр бухгалтерии, в конфигурациях управленческого учета — регистр накопления.
Для удобства далее, будем говорить, что если для расчетов мы используем регистр бухгалтерии, то мы «ведем учет на плане счетов», а если регистры накопления, то «ведем учет на регистрах». Это не совсем правильно технически, зато понятнее интуитивно.
1.2 Учет по сделкам
В конфигурации «Управление торговлей 10.3» представлена возможность дополнить узлы взаиморасчетов полем «Сделка», которое может принимать значение либо выставленных (поставщиками или покупателями) счетов, либо заказов. Какой именно тип документа выступает в качестве разделителя — указывается в элементе справочника «Договоры».
На рисунке представлен фрагмент формы элемента справочника «Договоры контрагентов» из КА 1.1, где зеленым обведено поле, отвечающее за эту аналитику.
Конфигурации КА и УПП унаследовали этот механизм.
При указании данного признака все документы взаиморасчетов по договору начинают императивно требовать указание сделки (счета или заказа), в регистрах учета начинает использоваться соответствующее поле, и, соответственно, отчеты по этим регистрам получают возможность разделить взаиморасчеты договора по сделкам.
Таким образом, мы получаем возможность вести в рамках одного договора раздельный учет в разрезе каждой сделки, контролировать полноту оплаты каждой сделки, расставить ответственных менеджеров к каждой сделке, и рассматривать задолженность в разрезе менеджеров.
Применение такой схемы бывает удобно, но рождает ряд побочных эффектов, о которых позже.
1.3 Учет по документам расчетов
С какого-то момента во всех новых конфигурациях 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», к КА и УПП прямого отношения не имеющий):
Вообще, надо сказать, такая (гибридная) концепция рождает нехорошие глюки и требует железной дисциплины пользователей, которые в некоторых узлах взаиморасчетов сами должны поддерживать ручной учет (и не допускать автоматического), а в некоторых — тщательно избегать ручного указания документов. И в то же время, этот подход самый гибкий.
В любом случае, каким бы образом не велся учет в разрезе документов расчетов, если он проведен корректно, на выходе мы получаем таблицу долгов / авансов в разрезе образующих их документов. Это позволяет нам, например:
- легко вести налоговый учет по НДС, в части сумм, исчисленных с авансов выданных и полученных (мы точно знаем, по какому выставленному счету-фактуре на аванс погашен, собственно, аванс, и ее пора ставить в зачет);
- определять просроченную задолженность, определив для каждого документа образования долга дату истечения срока оплаты (допустим, через свойство, или через дополнительный регистр сведений), и написав несложный специальный отчет, который, если срок оплаты больше текущей даты, выбирал бы задолженность в колонку «Сумма», а если меньше или равен — в колонку «В том числе, просрочено», и сворачивал по узлам взаиморасчетов;
- вести контроль полноты оплаты в разрезе аналитики документов образования долга (ответственных, грузополучателей и др).
1.4 Модель взаиморасчетов
Учитывая вышеизложенное, мы получаем современную детализацию учета взаиморасчетов:
Узел взаиморасчетов:
- Организация
- Счет учета
- Контрагент
- Договор
- Сделка (счет или заказ)
Детальнее узла:
- Документ расчетов
Эта детализация, в виде измерений, «втыкается» в регистр накопления или бухгалтерии, после чего по ней документами начинают проводиться остатки и обороты взаиморасчетов.
Например, на этом рисунке представлен фрагмент плана счетов конфигурации «Бухгалтерия предприятия 3.0» в части субсчетов 60 счета, где для описания узла взаиморасчетов взведены субконто «Контрагенты», «Договоры» (Организация определена на уровне регистра бухгалтерии), а для учета по документам расчетов — свое одноименное субконто.
А здесь на рисунке представлено описание регистра «Взаиморасчеты с контрагентами» из конфигураций «Управление торговлей 10.3», «Комплексная автоматизация 1.1» и «Управление производственным предприятием 1.3». Конкретно в этом регистре не ведется учет по документам расчетов, остальные же измерения соответствуют вышеописанной детализации.
Прошу также обратить внимание, что в регистре используется два ресурса — СуммаВзаиморасчетов учитывает сумму расчетов в валюте взаиморасчетов (обычно рубль, но для договорах в валюте и условных единицах — в валюте, заданной в договоре), а СуммаУпр — в валюте управленческого учета (которую большая часть здравомыслящих пользователей выбирает «Рубль», а крики мучений совершивших ошибку мне до сих пор слышатся в самых страшных кошмарах).
К регистру, на котором ведется учет, должен прилагаться отчет в виде простой ведомости, который предоставит пользователю аналитические данные и позволит проводить контрольные мероприятия.
Так, в КА/УПП, для регистра бухгалтерии «Хозрасчетный» используется комплект бухгалтерских отчетов (оборотно-сальдовая ведомость, анализ счета и др.), а для регистра накопления «Взаиморасчеты с контрагентами» — отчет «Ведомость по взаиморасчетам с контрагентами».
Такая модель должна быть в идеале, но на практике, опять таки, все немного сложнее, о чем, в частности, пойдет речь в разделах 3 и 4.1.
2. Контуры учета и совмещение их ведения в одной информационной базе.
Теперь необходимо рассмотреть контуры учета. Нас интересуют два основных — управленческий и регламентированный.
С этой точки зрения конфигурации 1С можно условно поделить на те, которые способны вести учет только в одном контуре (все «Бухгалтерии» — регламентированный, или «Торговля и Склад 9.2», «Управление небольшой фирмой» — управленческий), те, которые способны вести независимый или связанный учет в двух контурах (УПП 1, КА 1), и те, которые тщательно делают вид, что могут вести два контура, но без доработок — все-таки только один (например, «Управление торговлей 10.3»).
Управленческий учет предназначен для отражения того, что случилось в жизни предприятия (холдинга) на самом де с точки зрения руководителя или собственника предприятия. Регламентированный учет — с точки зрения того, как это отображается государству.
В двухконтурных конфигурациях документ может быть отражен либо в каком-то одном контуре, либо сразу в двух. Некоторые документы имеют ограничения, например, банковские документы всегда отражаются в управленческом учете. На рисунке представлен фрагмент формы документа «Реализация товаров и услуг» из конфигурации КА 1.1, где зеленым обведены флажки, регулирующие включение в учет. Хотя здесь регламентированный учет представлен двумя флажками (бухгалтерского и налогового учета), их крайне желательно использовать вместе, в то время, как управленческий учет можно использовать отдельно:
Бурное воображение может подсказывать нам про черную кассу, которая отражается в управленческом учете, но не отражается в регламентированном. Да, на этот вопрос можно посмотреть и с этой стороны, но лично я туда не пойду. Даже не вступая в противоречие с УК и НК РФ, можно встретить достаточно много легальных ситуаций, в которых операция может отражаться только в одном контуре учета, и не отражаться (отражаться иначе) в другом.
Так, например, в холдинге может находиться две организации, которые, в силу хозяйственной необходимости продают друг другу товары. В регламентированном учете операция продажи однозначно отражается (реализация — поступление), в то время, как собственник холдинга вправе считать, что в управленческом учете это его же товар, который просто сменил склад (перемещение), или вообще остался на месте, и не отражать это в данном контуре.
В похожем базисе существуют также внутренние займы, аренда у своих же ИП, находящихся на 6%-ной упрощенке, услуги управления одной организацией другой, и др., ситуации — эти взаиморасчеты есть в регламентированном учете, а в управленческом — нет.
Есть также случаи, когда мы разрываем дату оформления документов и фактического производства хозяйственной операции. Причины разные. Либо потому что гражданское право плохо стыкуется с налоговым (например, потому, что в договоре может быть очень странно прописана дата перехода права собственности на товар, и, с учетом длительной дороги, эта дата значительно отличается от даты поступления на склад), либо потому, что правовое обоснование сделки оговаривается позднее совершения операции (принятый на склад возврат товаров, который потом оформляют либо как отказ от договора купли-продажи, либо как гарантийную замену, либо как корректировку / исправление реализации).
Кроме того, очень часто целесообразно не засорять регламентированный учет чрезмерной аналитикой, которую все равно не будут способны понять и оценить проверяющие, а выбрать разумный и объяснимый уровень огрубления, не противоречащий ПБУ и НК РФ, и никого не раздражающий. В то же время, в управленческом учете иметь детализацию, необходимую для работы. Речь, например, идет о том, что для целей производства важно знать вид покрытия какой-либо детали (поместив этот признак в характеристики), и отслеживать затраты позаказнт, а для целей бухучета можно просто отражать результат работы смены, без заказов, и использовать учет не глубже номенклатуры.
В конечном итоге, все эти нюансы можно отразить в одной двухконтурной системе учета посредством разработки правильной схемы, в рамках которой мы будем отражать хозяйственные операции определенными типовыми документами конфигурации, и взводить флажки нужных контуров учета. Да, иногда одна и та же операция будет повторена в двух контурах учета с разной детализацией и в разное время.
Либо изначально следует рассмотреть вопрос ведения двух контуров учета в двух различных информационных базах.
Кстати, часто заказчики обращаются с ситуацией, когда они уже долгие годы внедряют одноконтурную конфигурацию (обычно изначально бухгалтерскую), но в процессе внедрения ее переросли. Они крайне недовольны ее функциональностью, и прилепили уже на нее столько костылей, что она стала визуально похожа на ежика, а фактически не может даже хромать. А на самом деле им просто нужна двухконтурная конфигурация и правильная схема.
3. Используемые структуры данных для ведения учета взаиморасчетов в КА1 / УПП
Мы рассмотрели модель взаиморасчетов и два контура учета. Рассмотрим, какие структуры данных для учета взаиморасчетов используются в конфигурациях КА 1 и УПП 1 (см. рисунок).
В управленческом контуре за взаиморасчеты отвечают два регистра накопления. Основной — «Взаиморасчеты с контрагентами», и вспомогательный — «Взаиморасчеты с контрагентами по документам расчетов». Первый используется для отражения взаиморасчетов всегда, и накапливает общие данные — с детализацией «Организация — Контрагент — Договор — Сделка (счет, или заказ, если такой способ ведения указан в договоре)). Второй используется для учета по узлам в разрезе документов расчетов (если в договоре взведен признак «Вести учет по документам расчетов».
По данным этих регистров работает большое количество «управленческих» отчетов по взаиморасчетам, которыми, чаще всего, пользуются менеджеры. Эти же отчеты (а также регистры, принцип и порядок учета взаиморасчетов) используются в конфигурации «Управление торговлей 10». Видите в конфигурации «серенький» отчет по взаиморасчетам? Скорее всего он выбирает данные из регистра «Взаиморасчеты с контрагентами».
В регламентированном контуре единственным источником отчетной информации является комплект бухгалтерских аналитических отчетов (оборотно-сальдовая ведомость, анализ счета и др), которые выбирают данные их регистра бухгалтерии «Хозрасчетный» (и плана счетов бухгалтерского учета). При этом, узел взаиморасчетов включает в себя всего лишь организацию, счет учета и два субконто — контрагент и договор (см. рисунок).
Мало? Не стыкуется с 1.2-1.4? Верно. Истинный учет взаиморасчетов в регламентированном учете ведется совсем не там. Существуют два регистра накопления, которые на самом деле используются для ведения большей части взаиморасчетов, а в бухгалтерский учет попадают лишь проводки по их данным. Это «Расчеты по приобретению (бухгалтерский учет)» и «Расчеты по реализации (бухгалтерский учет)». Первый регистр обеспечивает учет расчетов по договорам вида «С поставщиком», «С комитентом», второй — «С покупателем», «С комиссионером». При этом, договоры с видом «Прочее» ведутся только на бухгалтерском регистре (плане счетов), и в упомянутых регистрах накопления никак не фигурируют, и не должны.
Следует заметить, что существует небольшая путаница с названиями. В конфигураторе эти регистры носят, соответственно, названия «РасчетыПоПриобретениюВУсловныхЕдиницахОрганизации», «РасчетыПоРеализацииВУсловныхЕдиницахОрганизации», хотя их синонимы — «Расчеты по приобретению (бухгалтерский учет)» и «Расчеты по реализации (бухгалтерский учет)» почти повторяют и имена и синонимы смежных по назначению регистров сведений c именами «РасчетыПоПриобретениюОрганизации», «РасчетыПоРеализацииОрганизации». Они тоже нужны и важны, но мы их в настоящей статье не рассматриваем.
Детализация учета в вышеупомянутых регистрах накопления более глубокая, чем на плане счетов (см. рисунок): узел взаиморасчетов, кроме привычного трио «Организация-Контрагент-Договор» имеет счет учета, сделку (выделено зеленым). Детализация также ведется в разрезе документов расчетов (выделено желтым). Почти вся автоматика проведения документов ориентирована на выборку остатков не со счетов учета взаиморасчетов бухгалтерского регистра, а из регистров накопления.
Опять обращу внимание на наличие двух ресурсов, один из которых хранит сумму в валюте взаиморасчетов по договору, а второй — в валюте регламентированного учета.
При этом, например, в бухгалтерских конфигурациях (Бухгалтерия предприятия 2.0, 3.0) учет по сделкам отсутствует в принципе (плодите мнимые договоры, если нужно разделить взаиморасчеты в рамках одного реального договора), а учет по документам расчетов осуществляется на бухгалтерском регистре, путем использования третего субконто — «Документ расчетов» (см. рисунок из 1.4 с планом счетов).
Почему в КА/УПП учет по сделкам и по документам расчетов не сделан через субконто бухгалтерского регистра — вопрос сложный. Может быть дело в том, что вышеупомянутые конфигурации имеют в себе бухгалтерский модуль конфигурации «Бухгалтерия предприятия» версий 1.5 и 1.6, где еще не было такой парадигмы. Может быть в том, что конфигурации рассчитаны на большой объем данных, а выбирать запросами из регистра накопления куда производительней, чем из регистра бухгалтерии. А может в том, что для добавления еще двух субконто (сделку и документ расчетов) пришлось бы увеличивать количество возможных субконто, отказываясь от традиционного числа 3. Возможно, где-то это все описано разработчиком технологии, а я просто не знаю, тогда прошу прощения за невежество.
Такая разветвленная система с множеством смежных и дублирующих друг друга участков крайне неустойчива, и способна приводить к целому ряду возможных ошибок ведения учета, о которых будет рассказано в следующем разделе.
Продолжение: //infostart.ru/public/637461/
Время для темы не принципиально. Нужно просто собрать и качественно изложить информацию.
Вообще противоречивое мнение. Слишком много воды, нет последовательности в изложении, много непонятных упоминаний на другие конфигурации.
(1) Опубликовал вторую часть, в которой как раз следует конкретика по КА1/УПП.
В разделе 1.2 не отображается картинка
(3) Спасибо за замечание, исправил.
Хочу отметить одну особенность (подводный камень): в регистрах накопления Расчеты по приобретению, Расчет по реализации сумма регл. учета хранится без учета переоценки, а сумма балансовая с учетом переоценки только в регистре бухгалтерии, но там уже с меньшей детализацией.
То есть по валютным договорам не получить корректную сумму регл. учета в разрезе всей аналитики отчетом по регистру, то есть уже нельзя сказать что учет ведется именно на регистре накопления, а не на проводках, все на самом деле намешано.
(5)
Да, я сам в полной мере вкусил это уже после написания статьи. Переоценка только на проводках.
Однако в валюте взаиморасчетов суммы сходятся, и их можно проверять на предмет совпадения.
1. Как всегда ошибка парадигмы от 1c в области организации взаиморасчетов состоит в попытке решить серийную (протяженную по времени) информационную задачу с помощью атомарного (через 1 документ) подхода. Это детская болезнь тянется во многих решениях 1с со времен царя гороха.
2. Вторая методологическая ошибка в 1с в том, что понятие аванса считают оперативным (сиюминутным в течение дня от порядка документов в течение дня) а оно является периодическим! аванс — то что осталось на конец периода — а это в бухучете месяц, а не день, не час и не минута!
3. Третья методологическая ошибка — это считать серию взаиморасчетов бесконечной. Тогда проблема изменения предыдущих данных становится тотальной.
3. Поэтому большинство продвинутых разработчиков альтернативных конфигураций учета (умерли в РФ, но живы, например, в РБ) решали проблему серийным подходом — то есть выделением взаиморасчетов в отдельную подсистему со своим серийным механизмом. Когда вопрос взаиморасчетов не решается в текущем документе (может быть виден но не решается).
4. В результате 1с (в типовых решениях) как Иван Сусанин завела в полный тупик свою систему где она пребывает уже лет 20. Последний костыль сделан а прошлом году в бух 3.0 (из «ерп» перекочевало) — это перенос зачета авансов в обработку конец месяца. Хотя бы сняло месячную проблему но принципиально проблему не решило.
5. Не мешало бы 1с-цам не зазнаваться а смотреть как люди делают вне «суперспецотдела 1с» — например в Аксапте.
Продолжение следует (как сделать правильно и как это реально работает)