С течением времени совершенствуются платформы, разрабатываются новые отчёты и типовые конфигурации, дополняющие отечественные привычные базы данных новыми нужными возможностями. Но кое-какие неприятности всегда сопровождают нас, несмотря на научно-технический прогресс.
Одной из таких неприятностей есть справочник «Агенты» любой конфигурации. С течением времени он обрастает дополнительными папками, появляются тысячи и сотни новых элементов. И тут начинается неприятность «дублей».
Причем она одинаково неприятна для любых конфигураций: Бухгалтерии, Торговли, и других, а также созданных «с нуля». Наличие дублей угрожает множеством неприятностей. Разглядим несложной пример:
Имеется обычный справочник «Агенты». В бухгалтерии появляется счет на оплату от ООО «Компания Квазар». Человек начинает искать контрагента в справочнике и не находит, по окончании чего заводит этого контрагента в базу.
И вот тут начинаются неприятности. Записать его возможно множеством способов:
Для простодушной и наивной программы [advert=103]1С[/advert] все эти наименования будут различными. Более того – наличие либо отсутствие дополнительного пробела кроме этого делает элементы различными. Затем, сотрудник, оформляющий поставку от данного агента обязан последовательно попытаться любую из этих комбинаций, дабы отыскать это предприятие.
Аргументы оппонентов типа «а он отыщет в памяти, он отыщет и т.д.» отметаю сходу. А вдруг контрагентов 10.000? А вдруг сотрудник сменился? И таких «в случае если» много.
Обстановка существенно усугубляется, в случае если в справочнике имеется папки. В этом случае агенты будут повторяться не только в справочнике в целом, но и в папках. По большому счету наличие папок в справочнике агентов мне думается совсем недопустимым.
Поясняю. Папки призваны поделить контрагентов на группы по какому-либо неповторимому показателю. В случае если показатель не неповторим (к примеру, при наличии папок Покупатели и Поставщики агент есть и тем и вторым), то появляется коллизия.
Штатные механизмы справочников 1С не разрешают регламентировать наличие одного и того же элемента в двух группах в один момент. Исходя из этого появляется пара вариантов (допустим, у нас что-то купил отечественный поставщик, т.е. он уже имеется в папке Поставщики):
В первом случае папки прекратят иметь суть по большому счету, потому, что агенты перестают соответствовать данным показателям (покупателей и Поставщиков). Второй случай еще хуже – потому, что мы потеряем возможность конкретно делать выводы о состоянии взаиморасчетов с данным агентом (для обнаружения задолженности необходимо будет поочередно вырабатывать отчеты по обоим агентам).
Пиковая обстановка, это в то время, когда применение папок Поставщики и Покупатели, накладываясь на неверное занесение агентов в базу, ведет к тому, что однообразные агенты много раз повторяются (под различающимися наименованиями) в различных папках. Несложнее говоря, структура справочника станет таковой:
1. Папка Поставщики
1.1. Квазар ООО
1.2. Компания Квазар
2. Папка Клиенты
2.1. ООО Квазар
В этом случае определение состояния взаиморасчетов делается уже не проблемой, а подвигом. Избежать этого возможно несколькими методами, совместное применение которых делает защиту от дублей более действенной. Разглядим эти методы в двух разрезах: организационном (все мероприятия смогут быть реализованы пользователем самостоятельно) и техническом (внедрение экспертами дополнительных механизмов в штатный справочник агентов).
Перенос документов и справочников между однообразными конфигурациями 1с 8.х
