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

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

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

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

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

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

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

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

а также темы  Нюансы и подводные камни задач по взаиморасчетам в разрезе проектов и Как реализовать ведение взаиморасчетов в разрезе проектов на экзамене раздела по оперативному учету.

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

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

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

Если покупателю разрешен кредит, отгрузка товаров в счет кредита возможна только в том случае, если сумма накладной не превышает остаток разрешенного ему кредита и если нет просрочки оплаты (платеж отсрочен не более, чем на срок кредита). Каждая отгрузка товаров уменьшает остаток кредита на сумму накладной. При оплате доступный покупателю кредит восстанавливается на сумму оплаты (но не более, чем до разрешенного размера кредита, установленного покупателю). Период просрочки оплаты рассчитывается от самой ранней не полностью оплаченной накладной.

Например, покупателю разрешен кредит на 20000 рублей и на срок 15 дней.

История взаиморасчетов с покупателем следующая:

• На момент предоставления кредита предоплаты и задолженности у покупателя нет
• 10 числа происходит отгрузка товаров на сумму 14000 рублей
• 12 числа – оплата на сумму 4000 рублей
• В период с 13 по 25 числа можно оформить продажу покупателю в кредит ещё на сумму не более 10000 рублей
• 23 числа покупателю отгружены товары в кредит по второй накладной на сумму 9000 рублей
• С 26 числа отгрузки покупателю в кредит запрещены, т.к. на это число долг по первой накладной (10000 рублей) остается неоплаченным более, чем разрешенный срок кредита (15 дней). Запрет действует, хотя покупатель не использовал полностью всю сумму предоставленного ему кредита (остаток суммы кредита на 26 число равен 1000 рублей).

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

Отгрузка товаров оформляется документом “Расходная накладная”, а оплата — документом “Приход денег”.

Складской учет товаров не ведется.

Требуется реализовать описанную выше схему работы.

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

Взаиморасчеты за период с 01.01.2018 по 31.01.2018

Контрагент	Накладная	Нач. ост.	Отгрузка	Оплата	Кон. ост.
Купим всё
	Накладная № 1 от 15.01.2018		3 000	3 000
	Накладная № 2 от 18.01.2018		10 000	10 000
	Предоплата	5 000	13 000	12 000	4 000
Купим всегда
	Накладная № 321 от 20.12.2017	1 500		1 500
	Накладная № 4 от 18.01.2018		11 000	8 000	3 000
	Предоплата		2 000	2 000

Замечание.

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

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

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

Анализ задачи и описание основных объектов учетной схемы

Проанализируем условие задачи и определим объекты, которые понадобятся для её решения. Также выясним взаимосвязи и взаимодействия объектов.

Основным объектом в этой задаче является покупатель. Именно с покупателем ведутся расчеты, покупатель фигурирует и при продаже, и при оплате. Для хранения информации о покупателях понадобится справочник; его название — традиционное: «Контрагенты». Для этого справочника будет достаточно стандартного реквизита Наименование.

Документы, которыми производится оформление операций отгрузки товаров покупателям и поступление оплаты от покупателей, в условии задачи указаны явно:

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

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

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

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

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

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

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

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

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

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

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

В условии задачи сказано, что срок фактически предоставленного кредита исчисляется с самой ранней не полностью оплаченной накладной. Вычислить этот срок мы всегда сможем, подсчитав количество дней между датой накладной, по которой есть задолженность (реквизит Дата измерения РасходнаяНакладная регистра), и актуальной датой.

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

У регистра «Кредиты покупателям» будет одно измерение Контрагент (ссылка на справочник «Контрагенты») и два ресурса: СуммаКредита (число с точностью в 2 знака после запятой) и СрокКредита (целое число) — срок кредита в днях, в течение которого покупатель должен погасить задолженность по отгрузке.

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

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

Необходимость делать регистр периодическим следует из описания логики предоставления кредита. На неё указывает следующая фраза в условии задачи: «Для постоянных покупателей может быть предоставлен товарный кредит…». Слово «постоянных» в этой фразе подразумевает то, что кредит может быть предоставлен покупателю не сразу, а спустя некоторое время, когда с ним сложатся устойчивые доверительные отношения. То есть во взаиморасчетах с покупателем может быть период без предоставления кредита, затем период, когда кредит ему предоставлен. Кроме того, со временем условия кредита могут меняться в ту или иную сторону в зависимости от платежной дисциплины покупателя, его ценности для компании (объемов покупки) и иных причин.

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

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

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

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

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

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

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

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

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

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

Заметим также, что пустое значение в измерении РасходнаяНакладная регистра «Взаиморасчеты» — это одно из возможных значений наряду со ссылками на конкретные документы. Это специальное значение, которое обозначает предоплату. Им можно оперировать, как и любым другим: его можно записывать, анализировать, по нему можно делать отборы. А потому считать, что возможность наличия пустых значений в измерении РасходнаяНакладная – это напрасная трата дискового пространства, было бы неверным.

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

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

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

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

Некоторые вопросы, касающиеся проектирования регистров, рассмотрены также и в статье Принцип “один отчет – один регистр” – это догма при сдаче экзамена 1С:Специалист по платформе?

Какие методики использовать при проведении документов?

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

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

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

Процесс проведения документа «Расходная накладная» можно реализовать и так, чтобы сначала выполнялось основное движение (формирование долга покупателя за отгруженные товары), а потом уже выполнялись проверки и необходимые корректировки (то есть некое подобие «новой» методики проведения). Однако из-за того, что и в этом случае понадобится получать из регистров все те же данные, что при использовании «старой» методики, использование этого подхода в данной задаче нецелесообразно: вместо оптимизации это приведёт, скорее, к обратному эффекту — «утяжелению» проведения за счет избыточной операции записи.

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

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

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

• Размер предоплаты
• Разрешенный размер (сумма) кредита
• Разрешенный срок кредита.

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

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

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

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

При проведении документов будет иметь место конкуренция за ресурсы. Такими ресурсами являются:

• Суммы задолженностей клиентов по накладным (при разнесении оплаты)
• Суммы предоплат у покупателей (при зачете предоплат при отгрузке)
• Остатки сумм разрешенных кредитов и фактические сроки использования кредитов (при отгрузке).

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

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

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

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

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

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

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

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

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

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

Справочник «Контрагенты» из каркасной конфигурации нас полностью устраивает. Для нашей задачи никакие дополнительные реквизиты для контрагента не нужны, достаточно только наименования.

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

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

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

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

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

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

Реквизиты документа «Расходная накладная»:

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

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

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

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

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

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

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

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

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

• Измерения:
  • Контрагент (СправочникСсылка.Контрагенты)
  • РасходнаяНакладная (ДокументСсылка.РасходнаяНакладная)
• Ресурсы:
  • Сумма (Число 12, 2) — отрицательные значения в нашей учетной схеме являются допустимыми; знак в регистре обозначает направление задолженности.

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

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

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

Для измерения РасходнаяНакладная свойство «Запрет незаполненных значений» устанавливать не будем: в нашей учетной схеме пустое значение для расходной накладной является допустимым и обозначает предоплату.

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

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

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

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

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

• Измерения:
  • Контрагент (СправочникСсылка.Контрагенты)
• Ресурсы:
  • СуммаКредита (Число 12, 2; Неотрицательное)
  • СрокКредита (Число 3, 0; Неотрицательное) — срок кредита в днях.

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

Для измерения Контрагент установим свойство «Запрет незаполненных значений» в Истина  (по условию задачи параметры кредита устанавливаются для конкретного контрагента, пустое значение будет считаться ошибкой):

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

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