BiTel

При загрузке из файла платежей уникальность по ID проверяется только в пределах месяца.
Наступил новый календарный месяц - все старые платежи ( с прошлого месяца ) загрузились повторно.

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

UPD: индекс тоже не уникальный однако ...

а вы платежи какой датой грузите? разными? вам все равно когда они пришли?

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

о какой таблице речь? contract_payment?

payment_register_item_*

не понял, а зачем файл повторно загружать? да еще в следующем месяце?

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

странные у вас реестры...
а в недельных точно ни чего не теряется?
может надо ещё и месячные загружать и годовые (на всякий случай )

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

Так что насчет проблемы ?
Будет ли работать проверка по id на уникальность ?

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

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

И как делить ?
приходит реестр за неделю. в нем есть проведенные платежи и не проведенные. по дате платежа я не могу отсортировать, потому что платеж может прийти через день или два и например его дата 29.08 а проведен он 01.09 и если его грузить повторно 3.09 он корректно уйдет в отсев. А если он первый раз проведен 30.08, то 3.09 он честно проверит "уникальность в пределах месяца сентябрь" и проведется повторно. Смотреть в базе проведенные платежи и отсеивать ? А в чем смысл уникального id тогда, если приходиться проверять до загрузки ?

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

у вас КАЖДАЯ запись в реестре имеют дату проведения?

нет, есть дата платежа, а проведен он может быть в любой день позже

так в биллинг он заноситься по дате платежа или дате проведения?

сам платеж заноситься нормально - дата платежа и баланс насчитываются правильно.
но при этом в таблицу payment_register_item_* заноситься за текущий месяц, а не по дате платежа. И уникальность по id проверяется тоже в пределах текущего месяца, а не месяца соответствующего дате платежа.

ну что могу сказать:
1) пишите скрипт предобработки реестров.
или
2) обращайтесь в хелпдеск, обсудим возможность, стоимость и сроки.

1 какой предобработки ? проверять наличие данного платежа по id ?
2 а чинить багу не собираетесь ? или это у вас платное ?

Если это бага, то бесплатное.

_________________
I'm clever. I've got a computer.

1) делите реестры на месяцы по дате платежа
2) нет тут баги, программа делалась по ТЗ под определенный тип реестра, ваши реестры под это ТЗ не попадают.

3) Хотите чтобы ваши реестры работали - хелпдеск -> ваше ТЗ -> $$ -> доработка -> profit

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Ну а что, непонятна ирония, так оно и есть. Приходит недавно зареганый человек с десятком сообщений, про которого мы не знаем кто это и требует(sic!) чтобы была исправлена какая-то там на его взгляд бага.

_________________
I'm clever. I've got a computer.

Димон это не ирония. Это третий пункт который ему необходимо сделать Иронию я обычно в оффтоп прячу )

dimOn писал(а):

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

Значит мне все таки есть на что надеяться когда я прошу что то поправить И репу не зря копил окажется

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Я же вроде по русски выше написал что как бы я не делил реестры они все проверяются по id только для загруженных в текущей месяце. Если у меня есть платеж загруженный в прошлом месяце то избежать его повторной загрузки можно только исключив его из реестра.



Судя по ответам и советам тут есть непонимание или отсутствие желания понять.
Можно увидеть ТЗ, надеюсь это не коммерческая тайна ?

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

Если разработчикам нет интереса исправлять баги в продукте без вливания $$ - так и скажите. Мне конечно удивительна такая позиция, но как информация будет полезной

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

Хорошо, согласен, есть бага в доке, неправильно описано, исправим.

Где в документации описан тот алгоритм, который вы хотите ? покажите . На самом деле, там просто не описано это . Там не описано, что уникальность в приделах месяца. Но если не описано, это еще не означает что это бага..Если бы там было написано что уникальность сквозная явно и это было бы не так , то это бага. А тут просто забыли описать. За годы сущестования функционала никому не понадобилось то, что хотите вы. Значит это уже расширение функционала да еще и специфическое (никому не нужно больше) , значит точно не бага. Изначально например туда только платежи грузились . А потом по чей-то заявке и расходы добавились .Это тоже бага была ?