Платежные документы (прием)

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

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

Контроль налоговых реквизитов на соответствие инструкции 107н.

Добавить в настройку принимаемого документа правило предварительного контроля "Контроль по банковским алгоритмам", а в справочнике банков для банка отправителя включить опции контроля "Контроль налоговых показателей (03100)" и "Контроль заполненности статуса составителя".

Особые условия контроля для платежных документов по ЕНП (единый налоговый платеж) определяются следующими реквизитами документа (признак ЕНП): счет получателя 03100643000000018500 р/с, БК дохода в 104 поле 18201061201010000510 .

Разбивка строки КБК по отправителю/получателю.

Только при приеме в версии формата TXPP120101 и позже, строка КБК документа автоматически разбивается на отправителя (КБК строки) и получателя (код дохода из 104 поля), если платеж осуществляется в пределах одного р/с и заполнено 104 поле налогового платежа.

Обмен платежками с дополнительными классификаторами поддерживается через поле "Резерв" PPST.REZERV (по ТФФ: тип string, размер 40, но при приеме в "Бюджет-СМАРТ" размерность поля проверяется не строго).

Для ЗКР - поле "Примечание на строку" ZRST.NOTE_KBK, для БО - поле "примечание на строку" BNDESCR.NOTE, для РР - поле "Примечание на строку" APPOFSTR.NOTE_POFSTR .

Анализ поля с дополнительными классификаторами осуществляется по шаблонам регулярных выражений, если включен снос дополнительных классификаций из назначения/примечания. Для этих целей есть системный шаблон "Доп.классификаторы" с областью применения "Прочее" и формулой разбора (?:1;|2;)? \(? [РЕГ REGKLASS ;] [ЗДЧ PRP ;] [ДТЬ PRG ;] [УСЛ SVC ;] [НРЦ TFD ;] [ИПЦ TFS ;] [АИП FAIP ;] \) . Т.е. по умолчанию, если не создавать свой пользовательский шаблон, предполагается применение специальных префиксов:

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

Либо нужно использовать разбор шаблонов назначения платежа и сносить дополнительные классифкаторы и БО из назначения платежа:

Если в принимаемом файле указано БО, то соответствующее БО ищется в базе данных по реквизитам:

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

Синхронизация Договоров и Документов о приемке.

Если в принимаемом документе заполнены реквизиты с информацией об оплате контрактов (вид реестра, реестровый номер, идентификатор), то с учетом ИНН плательщика ищется Договор с таким же [реестровый номер + ИНН заказчика] и Документ о приемке с таким же [Идентификатор документа о приемке/этапа + ИНН заказчика].

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

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

Синхронизация счета получателя осуществляется согласно настройки приема "Идентификация счетов по номеру счета +" и с учетом настроек по синхронизации корреспондента (т.е. в платежке должен быть указан ИНН владельца счет получателя). Если р/с получателя совпадает с р/с счетом отправителя, и не указан л/с получателя (PPT.LS_PAY_RCP), то делается попытка распознать номер л/с получателя в наименовании получателя.

Найденные тем или иным образом л/с проверяются на соответствие шаблону нумерации счетов, согласно примитива FINDLS (см справочник "Регулярные выражения (примитивы)"), либо, при отсутствии примитива, на соответствие шаблону ЧЧЧЧЧСССССЧ , где "Ч" - любая цифра, "С" - любой символ (цифра или буква).

При электронном приеме осуществляется корректность заполнения реквизитов по оплате контрактов:

1. Если значение "Вид реестра" (VID_REESTR)= '02', то должны быть заполнены "Реестровый номер контракта" (NOM_REGISTER) и "Идентификатор документа о приемке/этапа" (ID_DOC).

2. Если "Реестровый номер контракта" (NOM_REGISTER) заполнен значением длиной 19 символов, то должен быть заполнен "Вид реестра" (VID_REESTR) значением '02'.

Первичный (подтверждающий, основание) - документ, являющийся основанием для проведения платежа: счет-фактура, накладная, договор и т.п.

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

Прием осуществляется автоматически, выбирать сопроводительные документы не надо - для этого подтверждающие файлы в общем случае должны иметь имя, удовлетворяющее следующей маске: <имя_файла_пп>.<расш_файла_пп>.<кодБП>.<номер_пп>.<имя_файла_док_осн>.<расш_файла_док_осн> , где

<имя_файла_пп> - имя файла-посылки с платежным документом,

<расш_файла_пп> - расширение имени файла-посылки с платежным документом,

<кодБП> - код БП (УБП), по которому принимается платёжный документ,

<номер_пп> - номер принимаемого платежного документа,

<имя_файла_док_осн> - произвольное имя файла первичного документа,

<расш_файла_док_осн> - расширение имени файла первичного документа, в соответствии со стандартами ОС.

Разделителем является символ точка "." . В случае, если текстовый файл принимаемой посылки содержит только одно платежное поручение (в одном файле один документ), то поля "КодБП" и "Номер_пп" можно не указывать: <имя_файла_пп>.<расш_файла_пп>.<имя_файла_док_осн>.<расш_файла_док_осн> .

Пример 1. Принимается пакет документов 00004K01.PPA, в котором несколько платежных документов, и в т.ч. есть платежное поручение № 77, отправителем в платежке является "Школа №7" с кодом УБП 12345. Файлы первичных документов для этого документа должны иметь имя 00004K01.PРA.12345.77.договор1.jpg , 00004K01.РРA.12345.77.счетфактура.xls и т.п. Где 00004K01.PРA - имя файла принимаемой посылки, 12345 - код УБП школы, 77 - номер принимаемого платежного поручения.

Пример 2. Принимается пакет документов 00004K02.PPA, в котором содержится только одно платежное поручение № 33, отправителем в платежке является "Школа №13" с кодом УБП 54321. Имена файлов первичных документов для этой платежки допустимо сформировать в виде 00004K02.PРA.договор1.jpg , 00004K02.РРA.счетфактура.xls и т.п. Где 00004K02.PРA - имя файла принимаемой посылки.

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

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

Дополнительный контроль входящих документов:

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

1 - соответствие л\с плательщика из PP.LS_PAY с л\с в назначении платежа (исключая 02* л/с),

2 - наличие строки реквизитов PPST (т.е. КБК и суммы) в строках назначения платежа,

3 - наличие строки реквизитов назначения платежа (КБК и суммы) в строках PPST п/п.

Если в назначении платежа только одна комбинация БК (одна строка), то контроль будет требовать наличия этой комбинации во всех строках файла PPST (если их несколько).

Допустимо отсутствие в назначении дополнительной классификации, а так же БО и/или суммы, и наличие их в строках PPST (не считается ошибкой).

4 - если из назначения полученно два л/с, то первый из них должен быть счетом открытия для второго. Например, при назначении
(914-0702-0200300590-611-900080 - л/с 02713001300) 03801013130 =4975.00 Субсидия на ...

контроль проверит, что бы в справочниках л/с 03801013130 был открыт на л/с бюджета 02713001300.

5 - наличие во внебанковском документе (р/с и БИК одинаковы в отправителе и получателе) дополнительной классификации получателя, указанной в назначении платежа. В назначении платежа дополнительной классификацией получателя считается код, разобранный шаблонами регулярных выражений в примитив ADDKLASSRCP .

п.п. 2 и 3 сверяются по полной КБК (расходы, доходы, источники) + №БО + сумма строки. Сумма в назначении может отсутствовать, сверяется только при наличии. Учетный номер БО в ряде форматов обмена отсутствует, сверяется только при наличии поля в формате и при отключенной настройке "1. Не контролировать наличие обязательств для документов в счет БО, ДО".

Протокол несоответствия выводится в виде: Реквизиты строк и назначения платежа не соответствуют друг другу.

2.Проверка статуса счета закрыт/заблокирован. Опция не анализируется. Статус счета проверяется всегда: отказ в приеме документов по закрытым счетам.

3.Замена запрещенных символов. Опция не анализируется, автозамена не осуществляется - отказ в приеме документа при наличии запрещенных символов.

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

5.Контроль наличия получателя налоговых платежей в справочнике "ИМНС/Администраторы". Опция не анализируется, вместо неё следует использовать предварительный контроль "Наличие получателя в справочнике "Администраторы".

7.Первичный контроль по банковским алгоритмам. Опция не анализируется, вместо неё следует использовать предварительный контроль "Проверка на соответствие банковским требованиям".

8.Не контролировать наличие РНК для документов. Опция включается, если не ведется учет документов "Договор". При отключеной опции в случае указания в платежке реестрового номера контракта требуется наличие документа "Договор" с таким реестровым номером.

9.Контроль соответствия счета открытия для л/с в НСИ и в файле. Опция не анализируется, используется настройка приема "Идентификация счетов по номеру счета +".

10.Поиск БО по строгому совпадению номера документа. Опция не анализируется, устарело.

11.Платежи внутри одного р/с принимать как п/п. Опция не анализируется. Для внебанковских документов по 02 л/с бюджета всегда формируется платежка, для р/с бюджета - всегда мемордер, кроме платежек по оплате контракта (в файле приема заполнено поле PPTCONTR.VID_REESTR).

12.В п/п внутри одного р/с не синхронизировать счет получателя. Поддерживается только для старых форматов обмена вида FK|2008.06 и т.п.: дополнение к опции 11 по внутренним платежам: если ВКЛючено (т.е. не синхронизировать), то счет получателя заменяется на неизвестный л/с. Для форматов вида TXPP опция не анализируется.

Не контролировать наличие РНК для документов» добавить «Не контролировать наличие ИДН для документов».

Уровень контроля на повторный прием и контроль назначения платежа.

Синхронизация справочников при электронном обмене.

Задает поведение программы при синхронизации получаемых данных с НСИ Бюджет-СМАРТ.

Данная настройка не влияет на обработку реквизита "получатель": при отсутствии получателя в справочнике комплекса (по комбинации [Номер счета + ИНН + БИК банка] ) или неоднозначной его идентификации (несколько подходящих записей), он заменяется на неизвестный параметр (см "Настройки параметров по умолчанию"), а получатель из посылки сохраняется в образе документа, без предупреждения. Такие платежки нормально печатаются и выгружаются, но их нельзя редактировать.

Задаются критерии по которым проводится сравнение докуметов, при их совпадении документы считаются одинаковыми. Рекомендуемое значение настройки: №, дата, сумма, счет отправителя, счет получателя.

Определяет перечень отчетов (документов), автоматически формируемых после приема.

Дополнительная обработка входящих документов.

•

Сносить региональную БК из назначения платежа - позволяет принять п/п с региональной классификацией при отсутствии по ТФФ поля для нее. Определение кода региональной классификации осуществляется разбором шаблонов назначения платежа, заданных в настройке приема "Шаблон разбора назначения платежа". Разбор проводится независимо от вкл/откл контроля шаблона назначения платежа.

•

Сносить номер БО из назначения платежа - позволяет принять платежный документ в счет БО при отсутствии по ТФФ поля для него (например, ТФФ 7.0 TXPP110101). Определение номера БО осуществляется с применением регулярных выражений. Разбор проводится независимо от вкл/откл контроля шаблона назначения платежа.
Если вычисленное БО найдено в Сведениях о БО , то найденный номер БО проставляется по отправителю.
Если прием осуществляется в форматах, предусматривающих указание БО (FK|2005.12), то указанное в платежке БО будет перезаписано без предупреждения номером БО из назначения платежа.

•

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

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

•	ИНН, КППУ, Наименование - формировать с помощью автомата - реквизиты плательщика пересоздаются (образ документа/печатная форма) согласно настройки "Дерево настроек - НАСТРОЙКИ - Общие - Автомат формирования первичного образа - настройка - Настройка вариантов формирования реквизитов отправителя".

•

В межбюджетных трансфертах вычислять плательщика по ОКАТО (105) - применяется для платежных документов по межбюджетным трансфертам (перечисления в другой бюджет по виду расхода 5хх либо КОСГУ 251 или 254) для замены плательщика и получателя платежа с целью оформления платежного документа по МБТ согласно требованиям комплекса.
Условие применения: если статус налогоплательщика 8 (поле 101) и, либо вид расхода 5хх либо КОСГУ документа "251" или "254" , и получатель платежа привязан к счету отправителя, то при приеме корреспондент отправитель платежа будет заменен на учреждение, имеющее такое же ОКТМО какое указано в 105 поле платежного документа. Одновременно будет заменен получатель платежа на такое же учреждение: с целью наличия в получателе платежа корреспондента из справочника, что может использоваться в отчетности и для анализа. Счет отправителя не меняется.

•

В субсидиях на госзадание вычислять плательщика по ИНН получателя - перечисления субсидий в БУ/АУ. Условие применения: если р/с получателя является счетом бюджета БУ/АУ, и вид расхода документа: 6хх (кроме 630), 45х, 46х, 81х, 82х, а получатель платежа имеет тип корреспондента БА/АУ и привязан к счету отправителя (справочник л/с, вкладка "Корреспонденты"), то при приеме корреспондент отправитель платежа будет заменен на получателя.
Если применяется КОСГУ, то вид расхода не анализируется, а используются условия по КОСГУ: 241, 530.

•

Замена плательщика в 14-х л/с - в документах по выплатам с лицевых счетов по переданным полномочиям заменять отправителя на учреждение, прикрепленное к л/с на вкладке "Корреспонденты" (см справочник лицевых счетов). Условие применения: л/с заведен с типом "Лицевой счет получателя по переданным полномочиям" (SYS_LS_PBS_PP), и к нему привязан единственный корреспондент с типом БУ/АУ на вкладке "Корреспонденты" - он и проставляется в отправителе документа.

•	Вычисление по ОКАТО с учетом ИНН получателя платежа (дополнение к п.2) - должно отмечаться совместно с п. "В межбюджетных трансфертах вычислять плательщика по ОКАТО (105)", если кроме ОКАТО нужно учитывать ИНН получателя.

•

Наименование банка плательщика формировать из справочника - если ВКЛючено, то наименование банка плательщика, указанное в принимаемом файле, заменяется данными из справочника "Банки", а при отсутствии - из "Справочника БИК ЦБ РФ". При этом если счет получателя существует в справочнике "Счета корреспондентов", то наименование банка (и город - см следующий пункт) берётся для банка, указанного в справочнике счетов. Иначе, если платеж сядет на неизвестного корреспондента, наименование банка берется из справочника "Банки" согласно БИК плательщика, указанного в принимаемом файле, при условии что такой БИК в справочнике единственный.

•	- добавить к наименованию город - если ВКЛючено, то перенаименование банка по данным справочника "Банки" осуществляется с добавлением населенного пункта (см поле "Город" в справочнике "Банки") через пробел с использованием префикса "г." перед населенным пунктом.

Это сообщения, озаглавленные "Ошибка в структуре файла:" и далее указание № строки, № поля в формате, наименования поля и причина (превышение длины, незадано и т.п.). Например: не заполнено обязательное поле № 10 (NUM_LS_PAY).

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

Что делать: отослать файл отправителю (формирователю) посылки с протоколом приема для устранения ошибки.

Сообщения о ненайденом счете с указанием № счета, наименования корреспондента и пустым БИК банка. Например:

Документ №11 от 01.09.2006 пропущен! Справочник 'Счета корреспондентов': не найден cчет '03030303030', корреспондент '1111111111 Орнарская сельская администрация', банк ' '.

•	в настройке приема "Идентификация счетов +" задан параметр "по счету открытия", а счет открытия данного счета в справочной системе и в посылке не идентичны. См. алгоритм синхронизации счетов при приеме документов. Что делать: очистить настройку "Идентификация счетов" и попробовать повторить прием .

Если в момент приема в комплексе выполняются действия, блокирующие применение функций контроля, то в протоколе приема либо в реестре принятых документов будет выведено сообщение "Выполняется критическая системная процедура - контроль не может быть выполнен!" и документы будут отклонены.

1. Навигатор: СПРАВОЧНИКИ \ СЧЕТА И БАНКИ \ Банки.

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

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

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