Выполнение отложенных движений по расчетам с клиентами. Управление взаиморасчетами

Все взаиморасчеты с контрагентами (клиентами и поставщиками) ведутся в разрезе трех измерений:

• организация,
• партнер/контрагент,
• объект расчетов.

В качестве объекта расчетов могут выступать:

• заказ,
• накладная,
• договор

Тип объекта расчетов выбирается на уровне соглашения.

Расчеты с клиентами

Для начала создадим типовое соглашение о продажах и в качестве объекта расчетов выберем заказы клиентов ЗК (самый детализированный вариант):

В соглашении также указывается и график оплаты ЗК (то, каким образом и в какие сроки будет оплачен ЗК). В нашем примере ЗК будет оплачиваться через 5 дней после отгрузки (т.е. постоплата):

Тут же можно наложить фильтр на тип оплаты, принятой в рамках соглашения:

Помимо постоплаты может быть выбран аванс и предоплата.

Разница между ними в том, что аванс предполагает вариант, что товара у нас еще вообще может не быть (т.е. мы даже не сможем организовать обеспечение товаров в ЗК, пока не зарегистрируем поступление аванса по нему), а предоплата предусматривает, что товар есть в наличии на нашем складе и будет отгружен сразу после оплаты.

Теперь создаем сам ЗК, видим что график оплаты заполнился по соглашению:

При этом дата платежа заполняется на основании поля Желаемая дата отгрузки (т.к. оно пустое, для расчета используется Дата отгрузки ):

Теперь на основании ЗК оформляем реализацию:

В списке ЗК меняется текущее состояние:

При двойном клике на нем открывается отчет по состоянию выполнения:

Теперь необходимо зарегистрировать поступление оплаты от клиента. Самый быстрый способ - на основании ЗК создать Поступление безналичных денежных средств . Но есть и другой способ - в журнале Безналичные платежи использовать закладку К поступлению :

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

На второй вкладке видим, что в качестве объекта расчетов используется именно ЗК. Благодаря выбору статьи ДДС в соглашении, она теперь подставляется сама:

Теперь ЗК готов к закрытию, долгов нет:

Состояние расчетов можно отслеживать с помощью отчета Ведомость расчетов с клиентами :

Теперь проведем эксперимент - создадим несколько реализаций по нашему соглашению, но без использования ЗК:

В отчете можем увидеть, что в качестве объекта расчетов показаны именно документы продажи (несмотря на то, что взаиморасчеты ведутся по заказам):

Теперь зарегистрируем оплату от клиента по этим реализациям, при этом создадим одну платежку:

В расшифровке платежа выбираем тип заполнения Списком и нажимаем Подобрать по остаткам :

В списке выделяем нужные, переносим в платежку:

Обращаю ваше внимание, что в журнале нет информации о состоянии оплаты реализаций:

Эту информацию можно достать только из ведомости:

Взаиморасчеты с поставщиками

На этот раз пример немного усложним - для начала введем авансовый платеж поставщику:

При этом объект расчетов оставим пустым:

В отчетах по закупкам будем использовать Ведомость расчетов с поставщиками :

Теперь создаем заказ поставщику (взаиморасчеты будем вести в разрезе заказов). Чтобы отнести на него оплату, нужно сделать зачет аванса:

В открывшемся окне помощника по зачету оплат находим аванс, при необходимости корректируем сумму зачета и нажимаем Зачесть/Перенести аванс :

Теперь видим, что аванс зачтен, нажимаем Выполнить в верхней части формы:

В результате заказ становится полностью оплаченным:

Сейчас в отчете можно увидеть, что часть аванса осталась нераспределенной, а по заказу для выведения расчетов в ноль осталось оформить приходную накладную:

Взаимозачет задолженности

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

У нас в программе уже зарегистрирован автоматически одна операция - это отражение факта зачета авансов:

Т.е. дебиторская задолженность (долг поставщика перед нами) по платежке программа перебросила на кредиторскую задолженность (наш долг перед поставщиком) по заказу поставщику:

В комментарии есть отметка об автоматическом создании:

Вот список операций, для которых можно использовать взаимозачет:

Сверка взаиморасчетов

Из раздела Казначейство открываем журнал документов Сверка взаиморасчетов , создаем новый с использованием помощника:

Настраиваем отбор:

Выбираем необходимых контрагентов по данному партнеру, по которым необходимо сделать сверку:

Устанавливаем дату формируемых сверок:

По окончании создается подобная сверка. Для большей информативности изменим вариант детализации:

К примеру, добавим вывод объектов расчетов:

После этого нажимаем Заполнить по данным организации :

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

По кнопке Печать распечатывается Акт сверки взаимных расчетов :

Вопрос: Запуск фонового задания под нужным пользователем

Здравствуйте!
Есть 1С:Предприятие 8.3 (8.3.11.2924), УТ 11.3.4.93 клиент - сервер.
В этой конфигурации движения по регистру "Расчеты с клиентами по документам " выполняется не в момент проведения документа, а регламентным заданием "Выполнение отложенных движений по расчетам с клиентами\поставщиками".
При этом иногда регламентное задание выдавало ошибку, т.к. пыталось сделать движения в закрытом периоде (Ранее даты запрета редактирования). В настройках регламентного задания прописали специального пользователя, у которого дата запрета открыта, после этого все стало работать.
Однако, есть необходимость сделать, чтобы данные движения по регистрам делались в момент проведения документа, а не тогда, когда запустится фоновое задание по расписанию.
Если запускать сам код, который выполняет регламентное задание при проведении документа, то возникает та же ошибка - закрыт период. И если программно запускать фоновое задание запускающее этот же код в момент проведения документа, то оно вызывает точно ту же ошибку, т.к. период закрыт, а фоновое задание, запускаемое программно, запускается под именем текущего пользователя, а у него дата запрета закрыта. Однако, когда запускается фоновое задание по расписанию, у которого установлен "правильный" пользователь в планировщике, то все проходит на ура. Вот как это сделать программно, как программно запустить фоновое задание под нужным пользователем "через планировщик" как это делают стандартные регламентные задания, подскажите пожалуйста?

Ответ:

Разве не под тем, под которым настроено?
Это должно быть глюк конфигурации

Lis2007 сказал(а):

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

Нажмите, чтобы раскрыть...

Вопрос: Регламентные задания

(Серверный вариант базы) Есть несколько регламентных заданий, выполняющихся по расписанию, один раз в сутки, ночью....
В Общих модулях описаны процедуры, которые запускаются регламентно.
Параллельно с этим сделал из интерфейса принудительный запуск этих же процедур вручную.
Процедуры выполняют довольно сложные действия (регаментные работы по итогам трудового дня связанные с проведением документов и движениями по регистрам. Алгоритм работает верно, так как работает уже около года....
Проблема вот в чем....
Иногда. ИМЕННО ИНОГДА! Регламентное задание выполняется и прерывается аварийно по причине ошибок в проведении документов. Это происходит периодами. Может целую неделю, подряд каждый день вылетать аварийно... а может неделю продержаться нормально, без ошибок.
Парадокс в другом....
Если я запускаю все эти же процедуры вручную, принудительно, из интерфейса. Ошибок не бывает НИКОГДА.
Это что значит?

Ответ:

DAK сказал(а):

Происходит это ночью.... никто в базе не сидит..... ничего не открыто.....

Нажмите, чтобы раскрыть...

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

Вопрос: Справочники и Регламентное задание

Добрый день!

Столкнулся с проблемой.
Платформа 1С 8.1, База лежит на сервере MSSQL, 1С сервер x64
Есть регламентное задание которое запускается.
После запуска происходит запрос, который получив данные о некотором списке документов, анализирует данные об их контрагентах, вызывая функцию находящуюся в общем модуле этого регл. задания с параметром ссылка на контрагента.

Вот функция
Функция КонтрагентСогласен(Контрагент) Экспорт

Если Контрагент.Согласен = Истина Тогда
Возврат Истина;
иначе
Возврат Ложь;
КонецЕсли;
КонецФункции

Регламентное задание завершается с ошибкой.
Пишет что {ОбщийМодуль.Модуль()}: Метод объекта не обнаружен (Согласен)

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

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

Ответ:

Контрагент - ссылка на эл. справочника контрагенты.

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

Если Контрагент.Согласен = Истина Тогда...

Вопрос: Ошибка подключения к WinSCP для регламентных заданий 1С

Подключаюсь следующим способом.
sessionOptions = Новый COMОбъект("WinSCP.SessionOptions"); Буду очень рад вашей помощи. Может кто сталкивался с выгрузкой/загрузкой данных через WinSCP при помощи регламентных заданий.

Ответ: Разобрался с проблемой, поставил новую версию WinSCP. Не стал перекидывать библиотеку в папку с windows и прописал следующую команду %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe "Путь до файла с новой библиотекой" /codebase /tlb:WinSCPnet64.tlb
После этого регламентные задания стали цепляться к WinSCP.

Вопрос: Уведомление при выполнении регламентного задания

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

Вопрос: Новое регламентное задание

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

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

Ответ:

Draco сказал(а):

вроде же регламентные задания на стороне сервера отрабатывают, а на сервере Сообщить.. вроде же только на клиенте такое

Нажмите, чтобы раскрыть...

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

Вопрос: ошибки с регламентным заданием

добрый вечер.написал регламентное задание по обработке заказа.но оно ругается на ошибки.то "Предупреждение" в модуле объекта не нравиться-заменил на сообщить то "ПользователиИнформационнойБазы.ТекущийПользователь().ОсновнойИнтерфейс.Имя" на имя ругается,то на рабочую дату(заменил на текущую()) а вот имя менять не знаю стоит ли дальше будет на что то ругаться.как правильно сделать?

Ответ: Регламентные задания вызываются на сервере, а не на клиенте.

В синтакс-помощнике описаны, какие процедуры доступны в каких местах.

Например предупреждение нельзя вызвать на сервере:
Предупреждение (DoMessageBox) ...
Доступность:
Тонкий клиент, веб-клиент, толстый клиент, мобильное приложение(клиент).

Проверка модуля сразу может проверять и ругаться, если поставить галку:

Вопрос: Регламентное задание с параметром

Конфа: Комплексная автоматизация, платформа 8.3
Любопытная проблема, с некоторого времени перестало выполняться регламентное задание по обмену между базами. Если вручную обмен запустишь то все хорошо, если через регламентное задание то Ж.

Возникает ошибка "Недостаточно фактических параметров для метода фонового задания".

Само регламентное задание типовое "ВыполнениеОбмена" которое вызывает процедуру:

Процедура ВыполнитьОбменДаннымиДляНастройкиАвтоматическогоОбменаДанными(КодНастройки) Экспорт Если НЕ ЗначениеЗаполнено(КодНастройки) Тогда Возврат; КонецЕсли; НастройкаОбмена = Справочники.НастройкиВыполненияОбмена.НайтиПоКоду(КодНастройки); Если НЕ ЗначениеЗаполнено(НастройкаОбмена) ИЛИ НастройкаОбмена.ПометкаУдаления Тогда Возврат; КонецЕсли; ПроцедурыОбменаДанными.ВыполнитьОбменПоНастройкеАвтоматическогоВыполненияОбменаДанными(НастройкаОбмена, Ложь); КонецПроцедуры

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

Т.е. из-за параметра "КодНастройки" скорее всего и возникает данная ошибка!

Однако посмотрев большинство типовых регламентных операций я увидел что многие содержат параметр! Например:

Процедура РасчетЦеныНоменклатурыРеглЗадание(Настройка) Экспорт Процедура ДопроведениеДокументов(Настройка) Экспорт

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

Кто нибудь сталкивался с такой проблемой, или кто нибудь знает как типовые конфигурации умудряются указывать в объекте метаданных "Регламентные задания" процедуру с параметром?

Например в конфе бухгалтерия 3.0 есть регламентное задание "ЗапускДополнительныхОбработок" которая вызывает процедуру с 2 параметрами:

Процедура ВыполнитьОбработкуПоРегламентномуЗаданию(ВнешняяОбработка, ИдентификаторКоманды) Экспорт...

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

Пробовали вертеть это расписание по разному с детальным расписанием и без него, с повтором и без повтора.
Интервал повтора в случае ошибки - 0. Задание выполняется без ошибок.
Есть у кого-нибудь соображения?

Ответ:

nomad_irk сказал(а):

При записи программно сформированного рег. задания оно будет выполнено независимо от расписания. Следующее выполнение будет по расписанию, либо при перезапуске 1С сервиса.

Нажмите, чтобы раскрыть...

Блин, похоже все было именно так.
Когда рег.задание отрабатывало оно записывало свои настройки (перечень объектов по которым надо пробежаться и расписание). Точно не скажу как и когда оно менялось - в отладке не увидел этого, но после того, как закомментировал запись настроек проблема исчезла.

Вопрос: Регламентное задание не отправляет почту через Outlook

Здравствуйте.
1С:Предприятие 8.2 (8.2.19.90)

Использую отправку писем через outlook.

Outlook = Новый COMОбъект("Outlook.Application"); Письмо = Outlook.CreateItem(0); Письмо.Subject = пТемаПисьма; . ......... Попытка Письмо.Send(); ЗаписьЖурналаРегистрации("РЗ", УровеньЖурналаРегистрации.Предупреждение, "6"); Исключение КонецПопытки;

Если запускаю интерактивно обработку, письмо отправляется.
Через регламентное задание использую туже процедуру. Регламентное задание отрабатывает без ошибки. Строка
Письмо.Send();
отрабатывает. Я в этом уверен, потому что далее отрабатывает запись в журнал регистрации

ЗаписьЖурналаРегистрации("РЗ", УровеньЖурналаРегистрации.Предупреждение, "6");

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

Ответ:

На сервере 1С почтовый клиент есть? пользователь от которого стратует рег задание у него какие права?

Внедряя или обслуживая 1С, многие сталкиваются с проблемой расчета себестоимости – то копейки зависают, то вообще непонятно какой порядок формирования себестоимости. И тут, судя по комментариям на форумах, вспоминают про волшебный документ корректировки регистров.) Я являюсь ярым противником применения этого документа и соглашаюсь на него только в случае, когда нужно свернуть базу. Поэтому, читая статьи и видя обработки по их применению для корректировки регистров партий, первым делом мне хочется написать огромными буквами – «Муля, НЕ НЕРВИРУЙ меня!!!». Мои партнеры, программисты-внедренцы 1С, об этом в курсе и даже подшучивают – «Шепотом скажи «корректировка регистров» и очень быстро беги как можно дальше!». Но это сугубо мое мнение. Предвижу после прочтения море возмущения – «Да в 1С баг на баге в расчете себестоимости!», «1С-ники в каждом новом релизе или обновлении вместо того, чтобы исправить старые ошибки добавляют кучу новых!» и в том же духе. Даже в мыслях не возникает желание оспаривать это.))) Но хочу заверить, что все это устранимо своими силами, если в этом разобраться.

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

С 2009 года ежедневно занимаюсь приведением в порядок регистров партий в разрезе складов, характеристик, качества (в УТ3, аналог УТ11 для Украины, добавилось еще и такое – Вид запасов и Аналитика учета партий). Имея опыт работы в УТ2, УТ11, УТ3 и какое-то понимание в финансовом учете, я хочу немного рассказать о последствиях его применения.

Программисты-внедренцы , исправляя ошибки корректировками регистров в регистрах партий гарантировано в довесок к своей работе получают следующее:

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

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

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

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

Кто еще что-то может дополнить – буду рада прочитать в комментариях.

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

Документ корректировки регистров партий => Неверно рассчитанная себестоимость => Недостоверные данные при расчете большей части финансовой отчетности => Некорректные данные большинства финансовых показателей предприятия => Принятие неверных управленческих решений => И, как результат, возможно возникновение вопроса, – «по всем показателям у нас все прекрасно, но ГДЕ ДЕНЬГИ? ».

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

Поэтому я просто советую, прежде, чем применять документ корректировки регистров партий задайте себе один простой вопрос – «А надо ли мне это «счастье»?».

Предлагаю несколько практических решений, основанных на опыте ежедневного выравнивания последовательностей и закрытия месяцев, для решения проблем с расчетом себестоимости в УТ3 (аналог УТ11 для Украины). Возможно, кому-то они пригодятся и для УТ11. В базе ежедневно около 100 пользователей (+50 торговых, набивающих заказы с мобильной 1С) и порядка 1000-1500 только документов заказов покупателей (а добавьте теперь к этому реализации, приходные кассовые, расходные ордера и прочее-прочее).

Для начала хочу обратить Ваше внимание на несколько условий, без которых эти решения не будут работать:

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

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

Живой пример: Наш клиент с 2009 года. Были ситуации, когда не представлялось возможным пару-тройку дней закрывать период. Первый разы переживала – «70 магазинов... Вот же ж сейчас мне начудят… Придется потратить кучу времени на нудную работу…». Каково же было мое удивление, когда все оказалось в порядке и выравнивание последовательностей заняло ровно столько времени, сколько и раньше. То есть, сотрудники, зная о том, что прошлый период открыт, не рискнули где-то что-то «ковырнуть» задним числом. Все последующие разы и новые проекты по внедрению только укрепили мое мнение о том, что ежедневное закрытие периода работает и это возможно.

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

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

Совет – закрывать месяц(-а) каждый день. Это кто и как посчитает нужным, но так меньше проблем и, соответственно, уходит меньше времени на исправление ошибок, так как иногда приходится перенести что-то куда-то, и тогда плывут цифры в разрезе недели, например.

Итак, у Вас возникли ошибки при закрытии месяца при расчете себестоимости в УТ3. В чем могут быть причины:

Отрицательные остатки по регистру «Товары организаций».

Как все понимают, в этом случае необходимо исправить все «минуса» с учетом всех разрезов (организаций, видов запасов, УКТВЭД и ГТД (УТ3), характеристик, качества). Это позволит устранить большинство ошибок, потому что данные из этого регистра берутся для расчета «Партий товаров организаций», «Себестоимость товаров», «Партии расходов на себестоимость товаров» и т.д.

Предостережение : при возникновении отрицательных остатков по видам запасов при закрытии месяца (в УТ3) не советую использовать встроенные механизмы. Проблем будет еще больше. Лучше ручками просто еще раз провести проблемные документы. Обычно все сразу становится на место.

Если, все же, ошибки остались, то причин может быть несколько:

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

   Не проставлен документ основания в возврате товара от покупателя.

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

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

Как показала практика - это позволяет устранить 99% ошибок, которые возникают при расчете себестоимости. Оставшийся 1% - это частные случаи, которые решаются в индивидуальном порядке. Например, ошибки при расчете себестоимости комиссионного товара после проведения отчета комиссионера (УТ3). Это вообще тема для отдельной статьи.) Мы с моим напарником, программистом-внедренцем, потратили довольно прилично бессонных ночей на нахождение и исправление 4-х ошибок в коде именно по этому документу. Хотя, нам ничего не мешало просто ввести документ корректировки и забыть про это, как про страшный сон!

Как видите, все решаемо и без документа корректировки регистров, хоть и не всегда быстро. Если следить за всем этим каждый день, то сложностей не должно быть. У меня ежедневное закрытие месяца в УТ3 занимает на данные момент 0,5-1,5 часа со всеми «шаманствами» в виде переноса непроведенных документов, контроля отрицательных остатков и т.д. Если крайне необходимо закрыть месяца за больший период, то и тут мы выработали свою методику, которая, например, позволяет закрывать год за 3,5 – 4 часа. И это при огромном документообороте. С другой стороны, если пользоваться простой кнопкой «Выполнить операции» в обработке закрытия месяца, то это может занять 8, а то и 10 часов!

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

P . S . Отдельно хочу передать большой привет и огромное спасибо разработчикам УТ3 за то, что не оставляют нас и наш ум без работы!). Помимо этого счастья по товарному учету, у меня еще много "Когда? Зачем? Почему?" по финансовому. Но это отдельная тема. И, несмотря на это, я прекрасно понимаю, что 1С (в частности УТ3) - это, при правильном подходе, один из мощных инструментов для управленческого учета и контроля для бизнеса, например, малого и среднего.

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

• При выполнении операции Зачет оплаты
• Регламентным заданием
• Данная операция при таком способе ведения взаиморасчетов не выполняется

Для того, чтобы использовать учет по договорам, необходимо включить специализированную функцию в настройках продаж (Администрирование – CRM и продажи – Договоры с клиентами ).

Помощник Зачет оплаты предназначен для зачета оплат непривязанных к расчетным документам. Эта функция доступна в различных документах. Рассмотрим на примере Реализации товаров и услуг .
Перейдем в список документов продаж (Продажи – Документы продажи ).

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

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

Вернемся к форме документа реализации. Вверху на панели есть кнопка Зачет оплаты .

При нажатии, открывается форма помощника зачета оплаты.

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

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

Информация о том будут ли вестись договора с клиентами, работающими в соответствии с теми условиями, которые определены в соглашении, регистрируется на страницеУсловия продаж .

Аналогичным образом в соглашениях с поставщиками регистрируется необходимость оформления договоров с поставщиками.

Оформление договоров

Договора заключаются между конкретной организаций торгового предприятия и организацией стороннего предприятия (контрагентом).
Отдельно регистрируются договора с покупателями, поставщиками, комиссионерами и комитентами. Новый договор рекомендуется оформлять на основании соглашения, оформленного с клиентом или с поставщиком.

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

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

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

Для договора предусмотрены следующие статусы:Не согласован ,Действует ,Закрыт . При вводе договора в действие следует указать период действия договора. Оформление документов возможно только по действующим договорам.

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

Список тех договоров, которые заключены с клиентами и поставщиками можно посмотреть в соответствующих разделахПродажи (Запасы и закупки ).

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

Работая в списке договоров, менеджер может отобрать договора по их статусу, а также вывести список тех договоров, по которым истекает срок действия. Используя командуУстановить статус можно изменить статус договора. Например, закрыть те договора, по которым истек срок действия.

Оформление документов в рамках договора

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

Указание договора в документах продажи

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

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

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

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

Расчет и контроль задолженности по документу зависит от того, какой порядок учета расчетов используется.

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

Указание договора в документах поставки

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

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

■ По заказам/накладным , то показывается задолженность по конкретному документу.
■ Если применяется порядок учета расчетовПо договорам , то показывается задолженность по в целом по договору. Информацию о сроках задолженности можно проконтролировать в отчетеАнализ расчетов с поставщиками , в соответствии с указанными сроками оплаты в заказе поставщику и накладным.

Указание договора в платежных документах

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

Оформление предоплаты по договору клиента

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

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

Автоматическое распределение оплат по документам отгрузки и поставки в рамках договора

Автоматическое распределение оплат по документам отгрузки (поставки) производится регламентным заданиемВыполнение отложенных движений по расчетам с партнерами .
Распределение оплат зависит от применяемого в документах отгрузки (поставки) порядка учета расчетов.

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

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

Распределение оплат по конкретным документам можно проанализировать в соответствующих отчетах Анализ расчетов с клиентами (Анализ расчетов с поставщиками).