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

(0) зачем убеждать? сделай ссылку с наименованием тем же числовым.

втихаря

Гемор не с этим что обмен делать, а стем что привыкли какие-то типовые обмены галочки расставлять, прогать разучились - жрите теперь! ;-)

(1) зачем?

(2) в тихаря не сделать, там вся база завязана на этом дурацком коде... я..ца отрежут сразу :)

Работает - не трогай
Сделай что-нибудь полезное пойди...

А зачем переделывать?
У меня в куче баз синхронизация именно по коду идёт... Правда, там завязаны ещё и внешние базы...

а пришли к выводу, что он всегда теперь должен быть закреплен за человеком - один и тот же не зависимо сколько раз пришел на предприятие.

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

(8) Ну вот видишь... а в ЗиКе, насколько помню, размножаются сотры.

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

(11) У вас самая лучшая прога и самая умная женщина-бухгалтер, см. (6)

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

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

(4) а чтобы никто не заметил.

(0) Задача программиста сделать что б работало и желательно правильно. Как ты этого добьешься - история умалчивает. Судя по всему опыта совсем нету, поэтому читай (6).

Ключ, ептыть, уникальный ключ. Все окей..

за один такой вопрос можно бить ногаме

(0)коленку прострелить.:-)
А вообще если не видят очевидного, то бесполезно убеждать.

Как-то работал по ТЗ клиента над обработкой обмена данными.
В ТЗ было указано не _что_ сделать, а _как_ сделать.
Выяснение конечных целей приводили к другому алгоритму, который освобождал бы от работы нескольких человек. Заказчик в лице заинтересованного человека не пошел на это. Вот такая бывает "автоматизация".