Учебный курс: Подготовка на 1С:Специалист по платформе 1С:Предприятие 8.3

Задачи оперативного учета – тема № 9:
Нюансы и подводные камни задач по взаиморасчетам в разрезе проектов

Ранее в главе «8. Как организовать учет взаиморасчетов с контрагентами с точностью до конкретного счета на оплату» мы уже разбирали задачу на взаиморасчеты с контрагентами. Рассмотрим еще одну возможную аналитику взаиморасчетов – проекты.

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

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

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

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

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

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

• «7. Старая и новая методики контроля остатков – их преимущества, недостатки и рекомендации, какую методику выбрать в решении»
• «11. Какие навыки в использовании управляемых блокировок потребуются на экзамене»
• «14. Что нужно знать о партионном учете и методах учета себестоимости для успешной сдачи экзамена»
• «17. Использование обработки проведения для документа Расходная накладная».

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

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

Для отгрузки товаров клиенту используется документ «Расходная накладная», для поступления денежных средств от клиента – документ «Приход денег». В каждом из этих документов указывается проект, к которому относится данная операция, причем в документе может быть указан только один проект (в реквизите шапки).

Документ «Расходная накладная» при проведении формирует задолженность клиента по проекту. Если при проведении документа есть аванс, необходимо его погасить. Оставшаяся сумма должна быть учтена как задолженность по отгрузке по проекту.

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

Авансы числятся за клиентами без учета проектов. Дата оплаты указывается в проекте.

Учет остатков номенклатуры не ведется.

Рассматриваемое условие можно встретить в задаче 1.9 сборника для подготовки к экзамену «1С:Специалист по платформе». Взаиморасчеты в разрезе проектов встречаются также в задачах 1.34 и 1.35.

Построение учетной схемы

Основные объекты

Для хранения информации о клиентах и проектах понадобятся справочники «Контрагенты» и «Проекты». Для справочника «Контрагенты» будет достаточно стандартного реквизита Наименование. В справочнике «Проекты», согласно условию задачи, будет еще и реквизит Дата оплаты.

Для организации описанного в задании документооборота понадобятся два документа:

• «Расходная накладная» – для оформления отгрузки клиентам
• «Приход денег» – для оформления поступления денег от клиентов.

В этих документах будут реквизиты шапки: Контрагент и Проект.

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

У регистра «Взаиморасчеты» будет два измерения: Контрагент и Проект и один ресурс Сумма. Регистраторами для него будут документы «Расходная накладная» (движение приход – увеличивает долг клиента) и «Приход денег» (движение расход – уменьшает долг клиента).

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

В документе «Расходная накладная» потребуется проверка на заполненность реквизита Проект. Эту проверку реализуем установкой свойства «Проверка заполнения» реквизита документа. В документе «Приход денег» значение реквизита Проект может быть пустым.

Правильно ли спроектирован учет по регистрам?

Так как в нашей учетной схеме используется регистр остатков («Взаиморасчеты»), нужно убедиться, что для него обеспечивается выполнение двух важных требований:

• Учетная схема позволяет одновременно вывести в ноль все ресурсы регистра. Иными словами, после совершения всех операций остаток регистра обнулится.
• Соблюдается правило «Один показатель – один регистр»

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

Долги клиентов погасятся при поступлении оплаты, а авансы зачтутся при оформлении отгрузки клиентам – все это предусматривается реализуемой в решении учетной схемой. (Заметим, что это утверждение справедливо, только если в систему вводятся полностью корректные данные. В противном случае ситуация не столь однозначна. Этот случай подробно рассматривается в следующем подразделе «Неоднозначная ситуация с зачетом аванса».)

В нашей задаче один показатель – состояние взаиморасчетов с одним ресурсом Сумма и двумя разрезами: Контрагент и Проект. Помимо величины, сумма взаимных расчетов характеризуется еще и знаком: положительная – клиент должен компании, отрицательная – компания должны клиенту. Поэтому для решения задачи достаточно одного регистра – «Взаиморасчеты». Разделять этот учет на два регистра (один для задолженности клиента перед компанией, другой для задолженности компании перед клиентом) смысла не имеет.

Таким образом, оба требования для регистра «Взаиморасчеты» будут выполнены, и можно считать, что учет по регистрам построен без ошибок.

Неоднозначная ситуация с зачетом аванса

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

Рассмотрим пример.

Предположим, что расчеты с клиентом ведутся по 3 проектам. Для клиента оформлены следующие документы:

Дата	Документ	Клиент	Проект	Сумма
01.08.2018	Расходная накладная 1	Клиент 1	Проект 1	10 000,00
02.08.2018	Расходная накладная 2	Клиент 1	Проект 2	5 000,00
03.08.2018	Приход денег 1	Клиент 1	Проект 2	16 000,00
04.08.2018	Расходная накладная 3	Клиент 1	Проект 3	1 000,00

Клиент заплатил ровно ту сумму, на которую ему была произведена отгрузка, и считает, что расчеты с компанией у него завершены. Но в регистре «Взаиморасчеты» после проведения всех этих документов будет содержаться и задолженность по проекту, и аванс, причем на одинаковые суммы:

Контрагент	Проект	Сумма Остаток
Клиент 1	Проект 1	10 000,00
Клиент 1	Пустое значение (Аванс)	– 10 000,00

Сумма взаиморасчетов по клиенту в целом обнулилась, а в разрезе проектов и авансов – нет. И если расчеты с клиентом полностью завершены, то задолженность по проекту «Проект 1» так и останется в регистре при наличии аванса.

Такая ситуация получилась потому, что в документе «Приход денег 1» указан проект «Проект 2», хотя сумма оплаты в этом документе включает в себя и сумму оплаты задолженности по проекту «Проект 1», и сумму оплаты задолженности по проекту «Проект 2», и сумму аванса в счет будущих отгрузок.

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

Согласно условию задачи, если в документе «Приход денег» указан проект, то документ погашает задолженность по этому проекту, а остаток суммы оплаты относит на аванс. Что и произошло в данном случае.

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

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

Казалось бы, в этом случае надо вернуться в документ «Приход денег 1» и очистить поле Проект. Но при этом, во первых, потеряется информация о том, что оплата должна пройти именно по проекту «Проект 2». А во-вторых, если у клиента имеются задолженности по более ранним проектам, вся сумма оплаты может пойти на погашение задолженностей по этим проектам, и проект «Проект 2» останется неоплаченным. То есть произойдет нарушение описанной в задании логики проведения документа.

Либо же можно разбить исходный документ «Приход денег 1» на два, и указать в одном «Проект 1», а в другом – «Проект 2». Но это тоже не совсем удобно и может в некотором смысле быть расценено как искажение первичных данных.

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

Поэтому предпочтительнее использовать другой вариант – создать ещё один документ: «Зачет авансов». Он может содержать лишь один реквизит – Контрагент и при проведении производить погашение всех имеющихся у клиента задолженностей по проектам за счет имеющегося аванса. Алгоритм погашения задолженностей при проведении документа может быть таким же, как в документе «Приход денег» (случай, когда проект в документе не указан). Отличие будет только в том, что распределяться на погашение задолженностей будет не сумма оплаты, а предварительно выбранный из регистра остаток суммы аванса по клиенту.

Заметим, что, хотя создание дополнительного документа «Зачет авансов» позволяет подстраховаться от возможной претензии к решению (о том, что ресурсы регистра не выводятся «в ноль»), заниматься его созданием имеет смысл только в том случае, если на экзамене останется время после выполнения основной части задания. Все-таки эта ситуация не совсем однозначная, и гораздо важнее выполнить те пункты, которые явно описаны в задании.

Отрицательные остатки регистра – это всегда плохо?

То, что в нашем решении используются отрицательные остатки регистра «Взаиморасчеты», может показаться не только странным, но и противоречащим требованиям экзамена. В описании ошибок, за которые может быть снижена оценка, есть и такое:

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

Про отрицательные остатки в задании ничего не сказано: нет ни явных указаний по их использованию, ни явного запрета. Но в данном случае можно сослаться на то, что отрицательные значения остатков предусмотрены нашей учетной схемой и не противоречат реальной практике ведения учета. Знак остатка в нашей схеме всего лишь указывает на направление задолженности (долг клиента или долг компании), то есть он расширяет допустимую область значений остатков регистра. Отрицательную сумму задолженности можно легко интерпретировать как аванс. В отличие, например, от ситуации с отрицательными остатками товаров на складе: логически объяснить такую ситуацию сложно, учетной схемой она, как правило, не предусмотрена и однозначно трактуется как ошибочная.

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

Отражение авансов – какие варианты?

Согласно условию задачи, когда сумма оплаты превышает задолженность клиента по отгрузке, часть поступающих от клиента денег на сумму переплаты должна учитываться как аванс. Также сказано, что «авансы числятся за клиентами без учета проектов», то есть значимым при учете аванса будет только клиент, от которого поступили деньги, авансы в разрезе проектов не предусмотрены.

Взаиморасчеты ведутся в двух разрезах: по клиентам и по проектам, поэтому в регистре «Взаиморасчеты» имеются два измерения: Контрагент и Проект. Для того чтобы понимать, когда в регистре содержится информация об авансе, аванс должен быть как-то обозначен. Можно использовать один из двух способов:

• Не заполнять значение в измерении Проект. В этом случае аванс будет обозначаться пустой ссылкой на справочник «Проекты»
• Выбрать в справочнике «Проекты» некоторый элемент и использовать его в качестве специального значение измерения Проект для обозначения аванса. Удобнее всего реализовать это с помощью создания предопределенного элемента справочника.

Эти два варианта практически равнозначны. Использование предопределенного элемента справочника более удобно при дальнейшем выводе информации в отчет, так как в табличном документе будет сразу отображаться наименование предопределенного элемента – «Аванс», и не нужно создавать вычисляемое поле для преобразования пустого значения в строку.

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

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

Погашение задолженности по проектам при оплате

В условии задачи сказано: «В документе «Приход денег» проект может не указываться. В этом случае погашаются задолженности по отгрузке по проектам в порядке их дат оплаты». Поэтому для решения задачи нужно найти все проекты клиента, по которым есть задолженности, выстроить их в порядке увеличения дат оплаты и погашать задолженности по этим проектам в пределах суммы оплаты из документа.

Нетрудно заметить, что, если в задаче заменить клиента на товар, проект на партию, а в качестве даты поступления партии использовать дату оплаты из проекта, то получим классическую задачу поиска партий товаров при списании по методу FIFO (подробнее см. в главе «14. Что нужно знать о партионном учете и методах учета себестоимости для успешной сдачи экзамена» общего раздела). Поэтому для нашей задачи будем использовать алгоритм, аналогичный тому, который применяется при проведении расходной накладной при партионном учете (подробнее см. в главе «17. Использование обработки проведения для документа Расходная накладная» общего раздела).

Заметим также, что распределение суммы платежа по задолженностям клиента по проектам понадобится только в том случае, если в документе «Приход денег» проект не указан. Если же проект в документе указан, возможно как погашение задолженности по тому проекту, который указан в документе, так и отнесение суммы платежа на аванс. И в том, и в другом случае объекты, на которые нужно относить сумму платежа, известны, и их поиск не потребуется.

Таким образом, в документе «Приход денег» в зависимости от того, указан ли проект, реализуем разные алгоритмы. Если проект в документе указан, будем использовать «новую» методику проведения: сначала выполним движение по погашению задолженности по проекту на всю сумму платежа, а затем проверим остаток задолженности по проекту. И если в результате получилась переплата, ее сумму отнесем на аванс. Если же проект в документе не указан, будем использовать «старую» методику: сначала найдем все проекты, по которым есть задолженности, а также суммы этих задолженностей, и затем выполним движения по погашению задолженностей по проектам. Оставшуюся после этого сумму платежа учтем как аванс.

Нужны ли контроль остатков и блокировка?

Отрицательные остатки ресурса Сумма регистра «Взаиморасчеты» являются частью решения и интерпретируются как задолженности компании перед клиентами (авансы). Поэтому контроль отрицательных остатков в обычном понимании тут не требуется (более подробно о контроле остатков можно прочитать в главе «7. Старая и новая методики контроля остатков – их преимущества, недостатки и рекомендации, какую методику выбрать в решении» общего модуля). Более того, в этой задаче нет таких ресурсов, из-за нехватки которых проведение документов было бы невозможно.

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

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

Обратные ситуации (когда задолженность компании будет по проекту или когда задолженность клиента будет по авансу) считаются некорректными. Но в условии задачи при проведении документов предусмотрены механизмы отнесения суммы переплаты на аванс и погашения аванса при отгрузке. Эти действия выполняются при проведении документов автоматически и предотвращают появление некорректных данных в регистре. Поэтому отменять проведение документов из-за невыполнения каких-либо условий не потребуется.

Запрет пустых значений

Относительно документа «Приход денег» в условии задачи сказано явно, что проект там может быть не указан. Что же касается обязательности указания проекта в документе «Расходная накладная» – в задании про это ничего не говорится.

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

Так как для обозначения авансов в нашей учетной схеме используется пустая ссылка на справочник «Проекты», запрещать пустые значения для измерения Проект регистра «Взаиморасчеты» не будем.

А для поля Контрагент в документах «Приход денег», «Расходная накладная» и регистре «Взаиморасчеты» запрет на пустые значения установим. По логике задачи клиент должен быть всегда указан. Вывод об этом можно сделать на основании фразы из задания: «…взаиморасчеты с клиентами ведутся в разрезе проектов». То есть взаиморасчеты ведутся именно с клиентами, а не по проектам в целом.

Что не требуется делать при решении задачи

В задании работа с номенклатурой никак не упомянута. Более того, там есть фраза «Учет остатков номенклатуры не ведется». Поэтому на экзамене нет смысла тратить время на организацию складского учета номенклатуры, создавать процедуры для пересчетов суммы по количеству и цене в строке документа, для расчета суммы документа по суммам из строк.

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

Практическая реализация

Создание объектов конфигурации

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

Справочник «Контрагенты» из каркасной конфигурации нас полностью устраивает.

Справочник «Проекты» отсутствует – добавим его со следующими реквизитами:

• ДатаОплаты (Дата; Состав даты – Дата):

Рисунок 1 – Структура справочника «Проекты»

Документ «Приход денег» (ПриходДенег) отсутствует – добавим его со следующими реквизитами:

• Контрагент (СправочникСсылка.Контрагенты)

• Проект (СправочникСсылка.Проекты)

• СуммаПоДокументу (Число 12, 2; Неотрицательное):

Рисунок 2 – Структура документа «Приход денег»

Документ «Расходная накладная» уже имеется в каркасной конфигурации. Изменим его, как описано ниже.

В документе «Расходная накладная»:

• Реквизиты документа:

• • • Добавим реквизиты:
      • Контрагент (СправочникСсылка.Контрагенты)
      • Проект (СправочникСсылка.Проекты)
    • Изменим тип реквизита СуммаПоДокументу на (Число 12, 2; Неотрицательное)

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

В результате документ «Расходная накладная» будет иметь следующую структуру:

Рисунок 3– Структура документа «Расходная накладная»

Для реквизитов Контрагент и Проект установим свойство «Проверка заполнения» в значение «Выдавать ошибку»:

Рисунок 4 – Свойства реквизита Контрагент документа «Расходная накладная»

Рисунок 5 – Свойства реквизита Проект документа «Расходная накладная»

Регистр накопления «Взаиморасчеты» отсутствует – добавим его. Вид данного регистра – Остатки:

Рисунок 6 – Основные свойства регистра накопления «Взаиморасчеты»

Структура регистра:

• • Измерения:
    • Контрагент (СправочникСсылка.Контрагенты)
    • Проект (СправочникСсылка.Проекты)

• • Ресурсы:
    • Сумма (Число 12, 2).

Рисунок 7 – Структура данных регистра накопления «Взаиморасчеты»

В качестве регистраторов регистра установим документы «Приход денег» и «Расходная накладная»:

Рисунок 8 – Регистраторы регистра накопления «Взаиморасчеты»

Для измерения Контрагент установим свойство «Запрет незаполненных значений» в Истина»:

Рисунок 9 – Свойства измерения Контрагент регистра накопления «Взаиморасчеты»

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

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