Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
 Формат обмена табличными данными  [new]
Megadragon
Member

Откуда: Украина
Сообщений: 12
Доброе утро! Требуется разработать формат реестров платежей населения за коммунальные услуги для импорта в БД PostgreSQL. Файлы реестров присылаются из банков и в конечном итоге используются для учёта оплаты коммунальных услуг и формирования квитанций.

Необходимые данные в реестрах:
— Общие для всего реестра: признак банка (например, МФО), признак организации (например, ЕДРПОУ или расчётный счёт) номер и дата реестра, общая сумма платежей и сумма комиссии.
— Для каждого платежа: номер лицевого счёта, фактическая дата оплаты (важно, например, при расчёте пени за просрочку оплаты), сумма платежа и код услуги. Также для восстановления Л/С (на случай, например, опечатки кассиром в банке – были такие случаи) могут указываться ФИО плательщика и адрес.

Немного предыстории:
Новая БД создана взамен старой на Oracle, которая перестала соответствовать требованиям законодательства (почему не доработали – начальство решило, что с нуля будет дешевле; есть и другие причины, которые не хотелось бы разглашать).
Ранее платежи присылались в формате DBF, причём каждый банк присылал файлы со своей уникальной структурой (хотя некоторые банки впоследствии соглашались со структурой других, но таких меньшинство). Некоторые банки даже присылали один и тот же реестр двумя DBF-файлами: тело – список платежей, и заголовок – файл из одной строки с общими данными реестра.

Поскольку новая информационная система предусматривает перезаключение договоров, начальство решило унифицировать структуру файлов. Учитывая опыт DBF-файлов некоторых банков, выдвинули требование, чтобы не перекодировать вручную разделители в числах (например, запятую в точку) и датах (например, слэш или дефис в точку). Пока что большинство из отдела разработки «за» JSON, считая DBF «устаревшим», также рассматриваем XML. CSV отсеяли быстро ввиду его «примитивности». У кого какие предложения насчёт формата?

Вроде ничего не забыл… Если есть вопросы – уточняйте.

Картинка с другого сайта.
29 май 19, 10:07    [21896373]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
miksoft
Member

Откуда:
Сообщений: 37679
Megadragon
CSV отсеяли быстро ввиду его «примитивности».
Ну и зря.
При нормальной спецификации он легче всего формируется и быстрее всех загружается.
Я бы предложил использовать его подвид TSV.
29 май 19, 11:09    [21896451]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
L_argo
Member

Откуда:
Сообщений: 891
Пока что большинство из отдела разработки «за» JSON
бугага. Как будто там нет проблем с разделителями в датах и в числах.
В ЖСОН вообще нет стандарта для хранения даты. Пиши, что хош.

Вы уверены, что те, кто присылал DBF, пришлют вам расово правильный JSON ?

В любом случае придется проверять вход.данные на валидность. Тчк/зпт в числах вообще не проблема и решается одной функцией.
С датой можно поступить аналогично, но придется указывать порядок следования токенов.
29 май 19, 11:21    [21896473]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
Megadragon,

https://ru.wikipedia.org/wiki/CommerceML
29 май 19, 12:33    [21896597]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
982183
Member

Откуда: VL
Сообщений: 3104
Megadragon
Ранее платежи присылались в формате DBF, причём каждый банк присылал файлы со своей уникальной структурой (хотя некоторые банки впоследствии соглашались со структурой других, но таких меньшинство). Некоторые банки даже присылали один и тот же реестр двумя DBF-файлами: тело – список платежей, и заголовок – файл из одной строки с общими данными реестра.


Ну так они будут присылать "как захотят", и в более "современном" формате.
Тут надо административно гайки закручивать и порядок наводить.
29 май 19, 13:17    [21896675]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
L_argo
Member

Откуда:
Сообщений: 891
982183
Ну так они будут присылать "как захотят", и в более "современном" формате.
+1. Или не будут. Причины найдут легко.
29 май 19, 14:23    [21896735]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
982183
Member

Откуда: VL
Сообщений: 3104
А иначе им придется каждый платеж отдельным ПП слать.
Что дорого.
29 май 19, 14:39    [21896747]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7830
Т.ч. исходя из вопроса, можно предположить, чоо топик-стартера только вчера приняли на работу в правительство РФ.

AFAIK

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

Напрямую импортировать в табличку БД не получится. Т.к. кроме собственно данных по "мелким"/одиночным перечислениям, есть еще и заголовок (header или footer, у кого как) с общими данныи по "объедененному" банковскому платежу. Т.к. все РЦ пытаются платежи агригировать и деньги перечисляют одной платежкой (за сутки), а не множеством мелких

По этой причине, запихать все данные в CSV не получится.

И в Почте России и в СберБанке есть и поля для показания счетчиков, как и через что их может заполнить "клиент", я не знаю. Те данные, которые видел я, там или мусор или пусто.

IMHO & AFAIK
29 май 19, 14:41    [21896749]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7830
в Сбербанке - ССБОЛ (Сбербанк Бизнес-Онлайн)
29 май 19, 14:42    [21896750]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
dvim
Member

Откуда: Санкт Петербург
Сообщений: 677
Megadragon,
реестров платежей населения

Вот я бы использовал текстовый формат обмена 1с и банк клиента....
По факту у всех банков реализована его загрузка/выгрузка.
29 май 19, 15:10    [21896782]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7830
На правах идеи

JSON и XML не очень удобен для просмотра сотрудником соответствующих отделов "глазами"
Даже от TXT, заказчик был не в восторге, пока я не научил их TXT файл с разделителем импортировать в Excel.

Если речь о своем формате, я бы предложил user-friendly Excel-XML. Программе пофиг, а пользователи будут счастливы. Т.к. в крайнем случае, если система "сглючит", всегда смогут посмотреть данные и, если нужно, ручками / на_счетах / святым_духом как нибудь их обработать

На одном sheet - данные о платежах
На втором sheet - общие данные о пакете
Первая строка - заголовки полей

Немного сложнее технически, но зато user-friendly.

dvim
Вот я бы использовал текстовый формат обмена 1с и банк клиента....
По факту у всех банков реализована его загрузка/выгрузка.

все есть в первом сообщении Т.С., т.ч. убрал в спойлер
+

1) "платежи населения за коммунальные услуги" у ряда организаций != ПД банка

Например в СбБОЛ и в Почта-России банковская платежка приходить одна на следующий день агригированная по всем платежам за пред. день, а расшифровка "платежей населения" в отдельном файле.

AFAIK аналогично выписки по эквайрингу из Сбербанка. Физическая банковская платежка будет одна, а эквайринговых платежей - много

2) Так же будет проблема с комиссией банка. Т.к. сумма по платежке != сумме платежа клиета-населения. Сбербанк (эквайринг и СбБол) и Почта-России по мере дохождения денег подвергнет их утряске и усушке на размер своей коммисии.

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

3) В идеале. хорошо бы еще уметь принимать и показания счетчиков. Теоретические такие поля в форматах и СбБОЛ и Почта-России существуют, но я о них ничего не знаю.

etc..etc..

IMHO & AFAIK
29 май 19, 16:02    [21896926]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
982183
Member

Откуда: VL
Сообщений: 3104
А СБ региональным провайдерам в каком виде данные передает по платежам?
29 май 19, 16:24    [21896985]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4750
Megadragon
Поскольку новая информационная система предусматривает перезаключение договоров, начальство решило унифицировать структуру файлов. Учитывая опыт DBF-файлов некоторых банков, выдвинули требование, чтобы не перекодировать вручную разделители в числах (например, запятую в точку) и датах (например, слэш или дефис в точку). Пока что большинство из отдела разработки «за» JSON, считая DBF «устаревшим», также рассматриваем XML. CSV отсеяли быстро ввиду его «примитивности». У кого какие предложения насчёт формата?


Э-э-э. По большому счету "формат" не сильно важен.
Главное модель данных, которые вы будете принимать.
Если они "ложатся" на плоскую структуру (таблица), то можно использовать CSV/XLS и т.д.
Если нет, то удобнее JSON, YAML, XML и пр

ИМХО имеет смысл подумать в сторону создания сервиса/API, для приема данных.
Соответственно описание данного сервиса/API и будет "форматом" данных.
30 май 19, 09:46    [21897480]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
L_argo
Member

Откуда:
Сообщений: 891
mad_nazgul
Соответственно описание данного сервиса/API и будет "форматом" данных.
Придумать формат - полдела. Его надо еще заставить использовать. Это гораздо сложнее.
30 май 19, 11:34    [21897559]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
alex55555
Member

Откуда:
Сообщений: 2129
Leonid Kudryavtsev
JSON и XML не очень удобен для просмотра сотрудником соответствующих отделов "глазами"
Даже от TXT, заказчик был не в восторге, пока я не научил их TXT файл с разделителем импортировать в Excel.

Ещё вариант - сразу делать в формате html.
30 май 19, 12:28    [21897609]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
982183
Member

Откуда: VL
Сообщений: 3104
L_argo
mad_nazgul
Соответственно описание данного сервиса/API и будет "форматом" данных.
Придумать формат - полдела. Его надо еще заставить использовать. Это гораздо сложнее.

Что сложного о?
Не принимать реестры, не соответствующие стандарту ....
30 май 19, 13:39    [21897673]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2167
982183
L_argo
пропущено...
Придумать формат - полдела. Его надо еще заставить использовать. Это гораздо сложнее.

Что сложного о?
Не принимать реестры, не соответствующие стандарту ....


так для этого надо иметь возможность этот формат всем навязать...
30 май 19, 13:52    [21897693]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7830
alex55555
Leonid Kudryavtsev
JSON и XML не очень удобен для просмотра сотрудником соответствующих отделов "глазами"
Даже от TXT, заказчик был не в восторге, пока я не научил их TXT файл с разделителем импортировать в Excel.

Ещё вариант - сразу делать в формате html.

Не покатит. Проблема с указанием типов данных. Даты, числа - поедут

В Excel XML можно указать и тип, и размерность (2 знака после запятой для денег, 3 знака или другое кол-во для показаний счетчиков) и так далее.

Если хорошо протестировать, можно даже добиться, что бы данные в файле можно было бы в Excel'е и править/добавлять.

В общем, на мой взгляд самый user friendly вариант. Т.к. сотрудники/бухгалтера/блондинки/старушки в XML, JSON не бум бум. И в ресурсоснабжающих организациях, и в управляющих компаниях, да и в РЦ не лучше. А системы глючат, часто и почти у всех (например сбербанк пару раз на один файла обмена присылал несколько платежей и наоборот, а система предполагала, что один файл обмена точно по сумме равно платежу). В таком случае посмотреть глазками, подправить ручками - крайне важная фича. Позволяющая не дожидаться, пока разгневанные гражданне дождутся очередной горячей линии с ВВП ))) Ну и понятное дело, что дождаться исправления бага от поставшика "информационной системы" иногда дольше, чем горячей линии. Одно дело IT, а другое слуга народа )))

p.s. сорри за политику, прсото тема такая. Обойти политику крайне сложно
30 май 19, 16:02    [21897805]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
Arm79
Member

Откуда: МО, Раменское
Сообщений: 3669
Просто XML )) Этого достаточно. Формат Excel XML сложный.
К XML добавляем XSD и сразу определяем строку и ошибку, если таковые есть

Скорость чтения, при использовании модели SAX очень высокая. Многословность XML нивелируется архиватором.

Что касается Excel - то идея в общем то неплохая, если не считать ограничения на кол-во строк. Но в любом случае Excel при наличии схемы тоже прекрасно открывает XML, и наглядность обеспечена.
30 май 19, 22:57    [21898081]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
alex55555
Member

Откуда:
Сообщений: 2129
Leonid Kudryavtsev
В общем, на мой взгляд самый user friendly вариант.

Вообще близко, но если уж у юзера установлена программа, воспринимающая этот самый обмен данными, то в ней смотреть полученное ещё более логично и удобно.
31 май 19, 13:07    [21898630]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2167
alex55555
Leonid Kudryavtsev
В общем, на мой взгляд самый user friendly вариант.

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


не надо недооценить силу тупизны

правки файлов вручную были есть и будут
31 май 19, 13:18    [21898662]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4750
L_argo
mad_nazgul
Соответственно описание данного сервиса/API и будет "форматом" данных.
Придумать формат - полдела. Его надо еще заставить использовать. Это гораздо сложнее.


Формат фигня. Модель данных все.
Не используют, потому что перевод с одной модели данных в другую модель данных может быть сложным, а иногда и не возможным.
31 май 19, 14:57    [21898838]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
alex55555
Member

Откуда:
Сообщений: 2129
МодальноеОкно
не надо недооценить силу тупизны

правки файлов вручную были есть и будут

Да, есть такая проблема.

Но всё же если инструмент для импорта удобный - никто руками в файлы лазить не будет. То есть здесь вопрос удобств, на которые разработчики часто и активно забивают.
1 июн 19, 15:50    [21899499]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
Сергей Фролов
Member

Откуда:
Сообщений: 1337
Megadragon,

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

Вот его описание: https://www.rkcsoft.ru/files/sberbank.pdf
10 июн 19, 13:54    [21905918]     Ответить | Цитировать Сообщить модератору
 Re: Формат обмена табличными данными  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 681
Сергей Фролов
Megadragon,

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

Вот его описание: https://www.rkcsoft.ru/files/sberbank.pdf


Жесть... Сколько избыточной и повторяющейся информации сбер гоняет по проводам. Это пример как НЕ надо делать.
10 июн 19, 17:44    [21906107]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Разработка информационных систем Ответить