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

Cane Cat FisherВот я и добиваюсь - где лежит этот признак (пропуска уровня дерева для объекта)? А все говорят, что он как-бы и не нужен...
Если он лежит, то лежит в справочнике городов. Но я также подозреваю, что он не нужен (допустим, в деревне Бобруевка торжественно построили первую улицу - уверены ли Вы, что успеете поменять соответствующий признак в справочнике раньше, чем к вашим клиентам/операторам придет человек с соответствующей пропиской в паспорте?)

Cane Cat FisherТогда встает вопрос проверки правильности (допустимости) адреса. Является ли адрес "г. Москва, кв.1" правильным? Как это определить?
Москва кв. 1 - неправильный, check должен его отсекать.

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

Cane Cat FisherА это значит, что адрес "Москва, д.1" будет признан правильным. И в адресах москвичей будет немало мусора, проскользнувшего сквозь логику системы. Конечно, его будет легко выбрать, распечатать, и, как сказал классик, ейными мордами операторам в харю тыкать. Но зачем, если можно изначально его не допускать?
Вопрос в цене этого "недопускания". Если она устраивает - согласен, надо не допускать.

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

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

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

Cane Cat FisherНу, это вопрос сводится вообще к методике и своевременности обновления геоинформационных данных.
Именно. И на сегодняшний момент вряд ли даже соответствующая госслужба может быть уверена в своевременности обновления. Вы для себя уверены - завидую Вам, если так :)

Cane Cat FisherДолжны ли мы позволять операторам местного уровня, (разумеется, особо уполномоченным и ответственным, согласно выданных прав), редактировать списки и атрибуты населенных пунктов, улиц, государств? Если да - проблема решается сама собой,
Не решится. Клиент стоит перед случайно выбранным оператором, а "особо уполномоченный и ответственный" в этот момент может обедать, болеть, загорать на Канарах, уволиться, наконец.....

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

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

Cane Cat FisherНо есть ситуации, когда правильность оформления адреса принципиально важна. Это случается, когда клиент становится должен нам денег, и мы должны его:
Один из моих работодателей в том числе занимался и коллекторскими услугами :)

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

Потребкредитование - песня отдельная и в общем печальная.

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

BelyОтправить на уточнение - отправить специально обученному человеку, а он уже примет решение, исправит и отправит на исполнение. Вот именно этот человек и должен говорить "Зуб даю..."
Не надо путать. Есть процесс актуализации адресной информации - имени специально обученного человека. А есть оператор, который говорит "ну вот такой адрес записан в паспорте" и дает в этом зуб.

BelyЕсли этот адрес некритичен, то и проверка может быть "предупреждающая".
А если адрес важен сильно - то зубу оператора доверять нельзя.
Одно не связано с другим. У нас не синхронный процесс.

BelyПришел клиент в банк, принес паспорт, в паспорте несуществующая улица.
Где гарантия того, что паспорт не подделан?
А настоящая улица, стало быть, гарантирует от подделки? Смешно, право слово.

Каждый отвечает за свой участок работы. Оператор - за то, чтобы верно вбить данные. "Эксперт по улицам" - за корректность адресов и разбор сложных случаев. "Эксперт по поддельным паспортам" - за личность клиента. etc.

BelyВторой вариант - принял оператор от клиента пакет для курьерской доставки.
Улица написаная в адресе доставки - не найдена. Где курьеру искать эту улицу? В какой части света?
Спрашивать у отправителя и дальше согласно бизнес-процессу для этого случая. Вот уж воистину замечательный пример: построили в деревне Бобруевка новую улицу, Матроскин с Шариком купили себе там квартиру, а послать им фоторужье я не могу, потому как какой-то дурацкий клерк говорит, что такой улицы нет.

BelyЭто один из признаков, что документ может быть недействительный.
Вот пусть этот признак адекватно обрабатывается - отправкой на некоторый дополнительный контроль.

Еще раз, внимательно: данные надо ввести и сохранить. Дальше, если они неадекватны - обработать по особой схеме. Но ситуация "программа не дает нажать на кнопку "Сохранить"" в данном случае бредова. Отказ от сохранения - правильная мера в тех случаях, когда оператор может "прямо тут же" исправить неверные данные на верные; случаи типа "такой улицы нет" к этому не относятся (если, конечно, адрес написан четко и речь не идет об опечатках).

BelyВот стоит курьер с фоторужъем, смотрит на адрес: Москва, проектируемый пр. 2345 и думает - какой-разтакой дурацкий клерк принял эту посылку у разтакого клиента.
Если он именно так стоит и думает - зря грешит на клиента. Ему надо думать "какой-разтакой дурацкий менеджер не отстроил наш бизнес-процесс". Надеюсь, нам обоим понятно, как нужно действовать в такой ситуации в нормальном случае.

BelyPS: иногда лучше отказаться сразу, чем браться за работу которую непонятно как выполнить.
Есть такое. Но не в столь тривиальных случаях. Это все равно как если коллега просит у меня сто рублей до завтра, а я потребую с него бизнес-план.

BelyИмено это я и говорил, вобщето...
Говорили. Равно как и я говорил об этом в том, на что Вы отвечали:

softwarerВыбор конечно зависит от бизнеса, от конкретной ситуации, но в общем случае, я полагаю, адрес таки должен быть внесен в программу [возможно с пометкой - "надо разобраться"]

Я возражаю на то, что Вы сказали: "зуб должен давать не оператор, а другой" и показываю, что есть два разных человека:

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


Эксперт, который дает зуб за то, что подозрительный адрес правилен.