В выписке указывается ИНН банка... Никто не дорабатывал так, чтобы по наименованию контрагента  проводить дополнительную идентификацию?
Оно (наименование) содержит вот такие разделители //. И в принципе никаких особых сложностей не видно. Однако если кто-то знает про какие-то подводные камни - расскажите, плз.

Плательщик выглядит как-то так:

ПАО СБЕРБАНК//ПРИМЕРНАЯ НАДЕЖДА ПАВЛОВНА//444055501401//РОССИЯ 119361 МОСКВА Г МОСКВА УЛ ТВЕРСКАЯ-ЯМСКАЯ Д 1 КВ 1//

лучше не закрузку пилить, а постобработку сделать

(2) Не вижу принципиальных различий, по-любому реализация планируется в расширении.

(3) посмотри на код загрузки, в скольких строках нужно будет разобраться?

и сколько строк займет постобработка?

захренячить плательщика в комментарий, а потом распарсить отдельно, типа в (2) как

(5) он и так уже есть в назначении

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

Наверное, никто никогда такой ерундой не занимался...

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

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

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

В общем тут можно много и долго писать...

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

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

Т.е. основной риск видится в дублировании из-за невозможности обеспечить корректный ввод? Не нашли по наименованию и создали ещё одного.