Страница 2 из 2
Добавлено: 15 окт 2007, 09:15
Disillusioned
Если речь идет о контрагентах, то у них есть уникальный атрибут ИНН. На практике бывает, что в момент обращения клиента ИНН еще не известен и потому не должен возбраняться ввод контрагентов без ИНН. Впоследствии при вводе ИНН сначала осуществляем поиск объекта по данному значению (SQL). Если находим существующий объект с введенным ИНН, то переподчиняем ему всех потомков текущего контрагента (тоже SQL), а текущий объект (который является дублем) отправляем в утиль. Если совпадения ИНН нет, изменяем атрибуты текущего объекта.
Добавлено: 15 окт 2007, 10:26
gali
проблема весьма актуальная, сталкиваемся постоянно. Единственное, к чему я пришла, нельзя завязываться на административные меры - дохлый номер. А что-то делать надо, у нас та-а-акой зоопарк развели, дали независимость татарстану и башкортостану, украину в упор не замечают. Так что, если появится рациональное решение, делитесь.
Добавлено: 15 окт 2007, 11:08
Alexey
Тогда у меня есть, наверное, актуальное предложение, ко всем кто сейчас пишет и будет писать в этой теме... давайте каждый опишет информацию которая вводиться у него по контрагенту обязательно, т.е. в любом случае пользователь ее вводит, сделаем некую общую структуру и от нее будем плясать... и искать реальных выход, так как данный вопрос актуален у всех... и так, у наших заказчиков все предельно просто (нам повезло), :
1) Наименование
2) Сокращенное наименование
3) Город
4) Адрес
5) УНП
6) Банк
7) Расчетный счет
А вот при выборе контрагента происходит обычный выбор по наименованию, пока так, но надо сделать эту процедуру более оптимальной... вот буду работать над этим в этой теме... Следующий ход за Вами господа...
Добавлено: 15 окт 2007, 11:22
Александр
При создании нового объекта мы вводим всего 3 поля, остальное заполняется потом и разными людьми
(кстати идентификация в дальнейшем по ИНН - неплохая мысль)
итак
Обязательные поля (Описание объекта)
1. Полное (точное) ЮРИДИЧЕСКОЕ название организации без кавычек(правда операторы на момент ввода его могут и не знать или оно может существенно отличаться от сленгового названия - но это уже другая тема) Редактирование -свободное.
Необязательные поля (Атрибуты объекта)
2. Форма собственности Редактирование -список ранее введенных значений или свободное.
3. Аббревиатура (сокращенное или англоязычное наименование) Редактирование -свободное
все остальное - адрес - реквизиты - и т.д. вводятся позже и на данном этапе неактуальны(наверно)
Добавлено: 15 окт 2007, 15:18
gali
у нас еще проще, но это из-за специфики нашего контингента и задачи, с которой мы начали. При регистрации входящей корреспонденции мы вводим только то, что стоит в письме в качестве отправителя. Ввод в классификатор, а в создаваемый объект выбор из последнего.
С ИНН неплохо, но что делать с иностранцами? Что делать с ошибками ввода ИНН?
Добавлено: 16 окт 2007, 08:49
Disillusioned
Если нет уникального и, желательно, цифрового атрибута(ов), однозначно идентифицирующего(их) запись, дубли может определить только человек (поиск подобных записей лишь информационная поддержка этого процесса).
С другой стороны, если есть проблемы с жесткой идентификацией сущностей, переживать по этому поводу вроде как бессмысленно - т.к. все на самом деле зависит не от разработчика, а от квалификации и исполнительности пользователя.
Добавлено: 16 окт 2007, 09:01
Александр
да нет давай все таки уйдем от человеческого фактора, наверняка Алексей или еще кто предложит нечто...
на мой взгляд обязательна нужна информационная поддержка в виде какой нибудь хитрой хп

в плане скорости

Добавлено: 16 окт 2007, 11:28
Alexey
Здесь скорее, если нет ничего прямо указывающего на принадлежность атрибута, прийдется все же использовать человеческий фактор и я соглашусь с Disillusioned, но ведь это можно сделать и немного подругому... Суть идеи следующая... честно скажу... подсмотрел, не в такой конечно интерпретации но все же, и так излагаю...
Так постановка задачи всем ясна... если коротко убрать дубли и так начнем...
Пользователь имеет возможность выбора контрагента или ввод его вручную... и затем выбор, или как то подругому не суть дела...
Нужно создать некий интерфейс верификации... Правда все же прийдется выделить человека, или несколько часов у какого либо человека...
Пусть пользователь вводит как ему удобно, далее создаем интерфейс который анализирует похожие записи и человек имеющий доступ к этому интерфейсу выбирает как должно быть вот кратенько и все... опять отвлекли и не дали дописать нормально мысли... но думаю суть уловили... найду время, где ж его найти, напишу точно... вот завтра сяду и специально дома напишу весь этот алгоритм в тексте и выложу здесь... все точка... ух достали меня... прямо с утра... ироды... ребята и девчата

) примите мои извинения...