Банковская выписка

Справочники, которые нужны для загрузки/создания банковской выписки
Ведение справочной информации/Реестр участника бюджетного процесса/Ведение банковских счетов ФК (OEBS_РП_Справочники п.13.2)

Закладка «Информация о счете (1)»
Блок «Наименования»
В блоке «Наименования» указываются наименования следующих атрибутов записи, выбранной в табличной части справочника (поля заполняются автоматически):
Органа ФК;
Банка;
Банка (латин.);
Адрес банка (латин.);
Типа счета;
Бюджета;
Валюты.

Закладка «Дополнительные атрибуты (3)»:
«Источник оплаты ЗКР» – символьное поле, максимальное количество символов – 1. Указывается код источника оплаты заявки на кассовый расход. Значение выбирается из списка. Возможные значения:
«0» – «За счет резерва» (значение по умолчанию);
«1» – «Консолидированная заявка»;
«2» – «-» (прочерк).
Примечание. Данный признак необходим, для того чтобы определить, будут ли ЗКР/ЗНП включаться в заявку на подкрепление счета (консолидированную).
Для счетов 40601 и 40701, работающих по Приказу №13н, устанавливается признак «1».
Для уровня УФК выбираются значения «0» или «1».
Значение «-» устанавливается только для счета 40105% на уровне МОУ.

Закладка «Показатели анализатора (2)»:
«Действует с» – поле даты. Указывается дата начала действия записи.
«Действует по» – поле даты. Указывается дата окончания действия записи.
«Наименование показателя» – указывается полное наименование показателя.
«Акт.?» – поле выбора. Указывается признак актуальности записи.
«Примечание» – указывается текст примечания к показателю.

Ведение справочной информации/Реестр участника бюджетного процесса/Ведение справочника банков

Ведение справочной информации/Настройка справочников/АСФК: Универсальная форма ведения ассоциаторов/Технические параметры банков

Типы банковских выписок
БВИ – итоговая банковская выписка
БВП – промежуточная банковская выписка
БВА – автоматическая банковская выписка
БВЗ – банковская выписка закрытого контура
Первые две грузятся, вторые создаются в ППО.

Загрузка Банковской выписки
Согласно формату УФЭБС Выписка состоит из ED211, ED101, ED108, ED104 и др.
ED211 – строки банковской выписки
ED101, ED108, ED104 и др. – документы, которые могут быть по банковской выписке (ED101 – пп, ED108 - реестр на общую сумму, ED104 - инкассовое поручение.
Перечень основных таблиц базы данных:
XXT_BS_DOC_REGISTRY — основная таблица АСФК
XXT_CM_PAYMENTS_DOC_ALL - платежные документы
XXT_CM_STATEMENT_HEADERS_ALL— заголовки банковских выписок
XXT_CM_STATEMENT_LINES_ALL— строки банковских выписок
XXT_CM_RECONCILE_ASSOC – таблица-связка между строками банковский выписки и
классифицированными/неклассифицированными поступлениями (Кт строки), заявки (дебетовые строки)
XXT_CM_CLASS_RECEIPTS — классифицированные поступления
XXT_CM_UNCLASS_RECEIPTS — неклассифицированные поступления
XXT_BC_INVOICES_DOC – заявки (ЗКР, ЗЗК …)
Проблемы загрузки
Для анализа проблем загрузки банковской выписки необходима следующая информация:
Результаты и логи работы конкарентов (запросов) - АСФК: Отчет о загрузке банковской выписки и АСФК: Загрузка и импорт банковских документов v.2.0;
Файлы банковской выписки при загрузке которой возникли проблемы.
Данные конкаренты запускаются под пользователем XXTBSXBR.

Пример ошибки при загрузке банковской выписки
https://jira-support.otr.ru/browse/SF-832323
Приложен журнал запроса АСФК: Загрузка и импорт банковских документов v.2.0

Ошибка:
[ED105 No.30369] register_error: Попытка повторной загрузки ЭД. (2340:XXT_CM_PAYMENTS_DOC_ALL_U2) DIGEST=0702615000|20170925|30369|Кр|40702810660200100234|040702615|40101810300000010005|040702001|4642.56
Говорит о том, что документ, который грузят, уже есть в системе.
Внимание! Не удалось связать строки выписки с платежными документами!
Список дублированных платежных документов: ----------------------------------------------------------------------------------------------------
STATEMENT_LINE_ID=252115440:
ЭПД DOC_GUID=55D3C7BD-705C-0266-E053-0A3A05B50CC5, из файла "601500110200000000PACKETEPD40303049_xml_plat.ED", загружен 03.08.2017 10:26:14
ЭПД DOC_GUID=55D54ABC-B314-02F0-E053-0A3A05B5A271, из файла "601500110200000000PACKETEPD40303049_xml_plat.ED", загружен 03.08.2017 10:26:14
----------------------------------------------------------------------------------------------------
надо устранить дубли, затем подкинуть на загрузку любой файл, запустится запрос по привязке кредитовок
Скриптом:
select * from xxt_cm_payments_doc_all p
where p.Epd_Doc_Order_Num = ‘94190' --номер ЭПД в течении дня
and p.Creator_Id = '4501002901' --id составителя
and p.Payment_Date = ‘25.09.2017' --дата БВИ
После чего в одной из пп изменить номер ЭПД. Квитование выписки происходит только автоматически при обработке банковских документов, т.е. для того, чтобы выписка сквитовалась, нужно подбросить банковский документ на загрузку.

Выписка загружена!
Для того, чтобы по Выписке зачислились поступления, выписка должна быть в статусе 002 (изначально, если не стоит автоматической обработки, выписка загружается в 001 статусе).
Типы поступлений определяются справочниками:
Ведение справочной информации/Настройка справочников/АСФК: Универсальная форма ведения ассоциаторов/ФК: Привязка типа поступления к типу РС и виду средств
Ведение справочной информации/Настройка справочников/АСФК: Универсальная форма ведения ассоциаторов/ФК: Привязка типа поступления к типу РС и типу ЛС

Если есть проблемы по зачислению банковской выписки, необходимо снять лог анализатора по конкретной пп, которая по мнению региона неверно зачислена (неверный вид поступление или КБК или ЛС). Данные в логе не зависят от того, как выверена пп сейчас, и затрагивает НСИ – те, что действуют в конкретный момент запуска скрипта, соответственно результат может отличаться от того, что было у региона при обработке выписки. Для этого необходимо воспользоваться скриптом из https://www.asfk-support.ru/jira/browse/KB-252 (Скрипт для формирования лога в отпут по обработке пп по анализатору ). Для примера возьмем https://jira-support.otr.ru/browse/SF-901436
Интересующая нас часть лога:
- Анализируется кредитовый платежный документ №801432 из выписки №951732 о
т 05.03.2018 (строка 37)
- Анализируемые параметры:
- l_doc_date (дата выписки) = 05.03.18
- l_acc_pay_code_type (тип счета плательщика) = 01
- l_acc_rec_code_type (тип счета получателя) = 07
- l_bcc_code (КБК из 104 поля) = 00000000000000000180
- l_bcc_type (тип КБК из 104 поля) = 20
- l_payment_purpose (назначение платежа) = (06031220490059612 л/с
03951000510) Перечисление субсидии на иные цели. Код целевой субсидии 03
-03. Cоглашение 051-02-2018-013 от 22.02.2018 за 2018 г., без НДС
- l_receiver_inn (ИНН получателя) = 2628057919
- l_receiver_kpp (КПП получателя) = 262801001
- l_payer_inn (ИНН плательщика) = 7710256289
- l_payer_kpp (КПП плательщика) = 770301001
- l_payer_bank_account (р/с плательщика) = 40105810700000001901
- l_payer_bank_bik (БИК плательщика) = 044501002
- l_receiver_bank_account (р/с получателя) = 40501810700022000002
- l_acc_rec_code_budget (бюджет р/с получателя) = 99010001
- l_acc_pay_code_budget (бюджет р/с плательщика) = 99010001
- l_payment_operation_type = 01
- l_bcc_type_for_oper =
- l_kosgu_type (тип КОСГУ) = 20
- g_payment.receiver_name (наимен. получателя) = УФК по Ставропольскому
краю ( ФГБУ "Национальный парк "Кисловодский", л/с 21216Ж36320)
- Проверка на соответствие КЛВ по счетам ФБ/ГВФ и ЕКС
- Результат проверки: 'E'
- Проверка на соответствие КЛВ по ЕКС в валюте на покупку валюты
- Результат проверки: 'E'
- Проверка на соответствие КДБ
- Результат проверки: 'E'
- Проверка на соответствие КЛВ по подкреплению счетов 40302 БС/МБ
- Результат проверки: 'E'
- Проверка на соответствие поступлениям типа КПД (2 счета в УФК)
- Результат проверки: 'E'
- Проверка на соответствие "КЛА" на счете бюджета (поступление доходов от
использования имущества, находящегося в государственной и муниципальной
собственности)
- Результат проверки: 'E'
- Проверка на соответствие Временным средствам лицевых счетов Федеральных
Бюджетов
- Поиск на соответствие ВКР.(kvl)
- Запускаем проверку на ВКР.(kvl)
->(2): XXT_CM_V_IDENTIFY.V_IDENTIFY_REC 14:19:56.101
- Анализ п/п. Дата=05.03.2018 Guid =66A62760-1822-01D8-E053-0A1503CC8FB4
- Удаление строк XXT_CM_V_IDENT_TMP rowcount= 0 l_update=0
->(3): XXT_CM_V_IDENTIFY.V_PA_TABLE 14:19:56.122
- Анализ возвратов п/п. Дата=05.03.2018 Счет банка=40501810700022000002 Би
к банка=040702001
- Добавлено лицевых счетов для анализа = 223
->(4): XXT_GL_TRADING_DAYS_PUB.get_current_trading_day_unit1 14:19:58.240
- p_application_id = 20003, p_responsibility_key = 50549
<-(4): XXT_GL_TRADING_DAYS_PUB.get_current_trading_day_unit1 14:19:58.240
- trading_day(cache) = 13.03.18
DBG: XXT_CM_V_IDENTIFY.V_PA_TABLE 14:20:04.656
- Добавлено кодов БК для анализа = 7259
<-(3): XXT_CM_V_IDENTIFY.V_PA_TABLE 14:20:04.656
- Успешный выход.
->(3): XXT_CM_V_IDENTIFY.V_IDENTIFY_LS 14:20:04.686
- Анализ лицевых счетов. Дата=05.03.2018 Счет банка=40501810700022000002 Б
ик банка=040702001 pnNastrOff=0
->(4): XXT_CM_V_IDENTIFY.V_FIDENTIFY_PROPS 14:20:04.717
- Start test 123.RETURN.Aнализ возвратов в примечании.
<-(4): XXT_CM_V_IDENTIFY.V_FIDENTIFY_PROPS 14:20:04.816
- End test 123.RETURN.Aнализ возвратов в примечании.
->(4): XXT_CM_V_IDENTIFY.V_FIDENTIFY_PROPS 14:20:04.817
- Start test 123.V_IDENTIFY_LS.BCC.Aнализ БК.
<-(4): XXT_CM_V_IDENTIFY.V_FIDENTIFY_PROPS 14:20:04.900
- End test 123.V_IDENTIFY_LS.BCC.Aнализ БК.
<-(3): XXT_CM_V_IDENTIFY.V_IDENTIFY_LS 14:20:04.929
- Не найдено признаков возвращаемости документа или расходной БК.
DBG: XXT_CM_V_IDENTIFY.V_IDENTIFY_REC 14:20:04.937
- Количество платежных документов для сохранения 0
- При тестировании сохранение не запускаем!
<-(2): XXT_CM_V_IDENTIFY.V_IDENTIFY_REC 14:20:04.937
- Нормальное завершение! x_return_status=E
DBG: XXT_CM_BANK_STMT.PROCESS_STATEMENT_LINE 14:20:04.937
- Проверка на соответствие поступлению в ЗК
- Результат проверки: 'E'
- Проверка на соответствие Подкреплению счетов 40501/40601/40701 с 14 ЛС (
КДН)
- Результат проверки: 'E'
- Определение типа для поступления на счет НУБП/АУ/БУ
- Пройдена проверка на соответствие КДН (НУБП/АУ/БУ)
- Определен тип поступления 'КДН'. Запуск API формирования поступлений (PE
RFORM_ANALYSIS)
->(2): XXT_CM_BANK_STMT.perform_analysis 14:20:05.231
- p_doc_guid=66A62760-1822-01D8-E053-0A1503CC8FB4p_log_id=123
->(3): XXT_BS_OPERATION_PUB.get_gvar_value 14:20:05.231
- p_name = OP_CODE
<-(3): XXT_BS_OPERATION_PUB.get_gvar_value 14:20:05.232
- Normal completion. Variable value is
DBG: XXT_CM_BANK_STMT.perform_analysis 14:20:05.232
- Start perform_analysis
- Checking parameters
- Get data from cashe
->(3): XXT_CM_CHECK_PARAMETRS_EPD.ANALYZER 14:20:05.232
- p_cl_type = 'КДН', p_log_id = 123, l_doc_date = 05.03.2018
- Проверка параметров NOT NULL
- Определение типа расчетного счета плательщика
- Полученное значение типа расчетного счета плательщика = 01
- Определение расчетного счета получателя
- Полученное значение расчетного счета получателя = 40501810700022000002
- Определение типа расчетного счета получателя
- Полученное значение типа расчетного счета получателя = 07
->(4): XXT_CM_CHECK_PARAMETRS_EPD.analyzer40501_40601_40701 14:20:05.233
- l_doc_date = 05.03.18, l_inn = 2628057919, l_kpp = 262801001
- Код бюджета x_budget_code = 99010001
- Поиск л/с в наименовании получателя
- Л/с, определенный из наименования получателя l_pa_code = 21216Ж36320
- Поиск л/с в справочнике "Ведение ЛС НУБП/АУ/БУ" и определение типа л/с
- По справочнику определены лицевой счет: x_pa_code = 21216Ж36320, l_pa_ty
pe = 21, l_pa_schema_code =
- Из справочника л/с определен учетный номер получателя x_su_code = Ж3632
- Поиск учетного номера получателя в Сводном Реестре с учетом ИНН или Наим
енования
- По справочнику определены учетный номер получателя: x_su_code = Ж3632, l
_client_type = 2, l_org_type = 03
- Определяем показатели на л/с
- Определены показатели: КР_ЗАДОЛ,СМТ
- Поиск КОСГУ в п/п (вызов def_kosgu).
->(5): XXT_CM_CHECK_PARAMETRS_EPD.DEF_KOSGU 14:20:05.414
- p_cl_type = КДН
- Анализ КОСГУ в 104 поле = '00000000000000000180'
- КОСГУ в п/п найден x_kosgu = '180', x_kosgu_type = '20'
<-(5): XXT_CM_CHECK_PARAMETRS_EPD.DEF_KOSGU 14:20:05.414
- Успешное завершение def_kosgu.
DBG: XXT_CM_CHECK_PARAMETRS_EPD.analyzer40501_40601_40701 14:20:05.415
- l_kosgu = 180, l_kosgu_type = 20
- Определяем код главы учредителя (XXT_RD_PA_PUB.get_ppp_code).
->(5): XXT_RD_PA_PUB.GET_PPP_CODE 14:20:05.415
- P_PA_CODE=21216Ж36320 P_BUDGET_CODE=99010001
- Checking code PA.
->(6): XXT_GL_TRADING_DAYS_PUB.get_current_trading_day_unit1 14:20:05.415
- p_application_id = 20003, p_responsibility_key = 50549
<-(6): XXT_GL_TRADING_DAYS_PUB.get_current_trading_day_unit1 14:20:05.415
- trading_day = 13.03.18
DBG: XXT_RD_PA_PUB.GET_PPP_CODE 14:20:05.436
- Checking code NUBP.
- Checking parent code UBP.
- Checking code PPP.
<-(5): XXT_RD_PA_PUB.GET_PPP_CODE 14:20:05.463
- Successfully completed
DBG: XXT_CM_CHECK_PARAMETRS_EPD.analyzer40501_40601_40701 14:20:05.464
- l_ppp_code = 051
- Поиск кода ФАИП в назначении платежа: "(06031220490059612 л/с 0395100051
0) Перечисление субсидии на иные цели. Код целевой субсидии 03-03. Cогла
шение 051-02-2018-013 от 22.02.2018 за 2018 г., без НДС"
- Код ФАИП из НП l_faip_code =
- Проверяем признак "Работа по НУБП" справочника бюджетов
- l_is_72n = Y
- Поиск кода субсидии в назначении платежа: "(06031220490059612 л/с 039510
00510) Перечисление субсидии на иные цели. Код целевой субсидии 03-03. C
оглашение 051-02-2018-013 от 22.02.2018 за 2018 г., без НДС"
- l_st_code =
- Код субсидии x_subsidy_target_code =
- Вид средств x_fund_source_code = 90
- "C правом расходования" x_expence_right = N
<-(4): XXT_CM_CHECK_PARAMETRS_EPD.analyzer40501_40601_40701 14:20:05.476
- Успешное завершение analyzer40501_40601_40701
DBG: XXT_CM_CHECK_PARAMETRS_EPD.ANALYZER 14:20:05.476
- Анализатор вернул следующие атрибуты классифицированного поступления:
- x_su_code = Ж3632
- x_pa_code = 21216Ж36320
- x_dop_pa_code =
- x_bcc_code = 00000000000000000180
- x_bcc_type =
- x_fund_source_code = 90
- x_budget_code = 99010001
- x_okato_code =
- x_funds_in_transite =
- x_subsidy_target_code =
- x_faip_code =
- x_expence_right = N
- x_inn = 2628057919
- x_kpp = 262801001
- x_adm_inn =
- x_adm_kpp =
- x_renter_pa_not_found =
- x_renter_pa =
- x_nvs_code =
- x_adm_list =
- p_cl_type = КДН
DBG: XXT_CM_CHECK_PARAMETRS_EPD.log_msg 14:20:05.477
- Работа анализатора завершена. Платеж классифицировался.

Из текста лога видно, что из назначения платежа анализатор код субсидии не определили, поэтому зачислено было без него.
Другой пример обращения https://jira-support.otr.ru/browse/SF-857344 .
Главная часть из лога:
- Результат проверки: 'E'
- Проверка на соответствие КЛБ №1 (перечисления доходов с 40101 на 402xx/4
04xx)
- Проверка пройдена успешно. Запуск API формирования поступлений (process_
klb)
->(3): XXT_CM_BANK_STMT.process_klb 11:58:10.397
- p_doc_guid = 5D6203B9-847C-01DE-E053-0A200215F42F, p_log_id = 123456
- Проверка параметров NOT NULL
- Поступление пришло с текущего ОрФК
- Ищем документ "Заявка на перечисление со счета поступлений УФК", детализ
ирующий состав поступления
- Документ "Заявка на перечисление со счета поступлений УФК" не найден
Лог анализатора не нашел документ, по которому было перечисление со счета 40101. Причина в комментарии региона - Обнаружили, что в ЗПД дата реестра неверная - 06.11.2017, а нужно 07.11.2017.

БВП и БВА
Главное различие:
БВП присылает банк (самостоятельно или по запросу ТОФК) БВА создает пользователь в программе запросом «ФК: Создание автоматических банковских выписок (БВА)» (по одному расчетному счету или по набору счетов), на основании загруженных платежных поручений из банка
Обработка выписок в ППО производится одинаково и аналогично БВИ.
После загрузки банковской выписки итоговой ни по БВП ни по БВА не должно быть строк в таблице XXT_CM_RECONCILE_ASSOC

БВЗ
БВЗ – та часть выписки, которая формируется в ОК и шипментами отправляется в ЗК, где обрабатывается и доводится до конечного статуса. Обработка и статус из ЗК приходит в ОК так же шипментами. Без закрытой, т.е. статус 999 БВИ на конечный статус не перейдет.
Строки БВИ, которые определят отношение пп к ЗК:
Select * from xxt_cm_statement_lines_all set modified='Y', for_sec_cntr=‘Y’
Если данные параметры есть на строках БВИ, то по Операция «Формирование выписки для ЗК» формируется БВЗ, которая автоматически выгружается в ЗК. ГУИДы пп по строкам к БВИ и БВЗ разные, но ГУИДы пп и самой БВЗ в ОК и ЗК одинаковые.
Как пример обращения где не формировалась БВЗ: https://jira-support.otr.ru/browse/SF-361083 .
Все основные ошибки есть в https://www.asfk-support.ru/jira/browse/KB-423 , как и примеры их решения.
Бывает ситуация, когда в ОК шипименты грузятся непоследовательно, и тогда смены статуса не происходит. Если пользователь подтверждает корректность проводок в ОК, то статус по БВЗ можно изменить апдейтом:
update xxt_bs_doc_registry r set r.business_status=‘999' where r.doc_guid=‘ГУИД БВЗ‘
В ЗК БВЗ так же обрабатывается (аналогично БВИ в ОК), но на поступлении есть чек-бокс «отказать в ЗК», ее используют по поступлениям, которые ошибочно были отправлены в ЗК.