Возможно, что разработчикам пока было некогда обратить внимание на то, что экспорт/импорт одинаково неполон во многих местах PLI.
На мой взгляд, необходима однотипная доработка для того, чтобы все имеющиеся справочники/списки/правила могли экспортироваться корректно.
Для чего это нужно? - для того чтобы освободить команду разработчиков от «допиливания» интерфейса редактирования справочников, списков, таблиц. В Excel'е все эти функции реализованы, протестированы и доступны. Имело бы смысл делегировать эти компетенции во внешние ПО, а в PLI поддержать корректный Экспорт/Импорт. И тем самым сэкономить трудоресурсы разработчиков и тестировщиков за счёт «большого брата» (MS Excel, Open Office, grep, sed, awk, и т.д.)
Почему я так считаю?
Я попробовал воспользоваться Правилами автозамены текста. Вещь удобная, но обнаружились значительные ограничения.
Поясню в чём дело.
Один мой поставщик пишет названия брэндов не в латинице, а в кирилице. И я не могу на это повлиять (хотя считаю что это по меньшей мере странно)
Соответственно, для успешного автоматического сопоставления необходимо выполнить замену названий брэндов (cyr->lat) в следующих полях:
- Наименование,
- модель,
- артикул,
1. В Exel'e создал список соответствий брендов (cyr->lat) на основе экспорта "Правил автозамены текста"
Обращаю внимание, что в Excel-файл экспортировались не все поля, а только 3 поля:
- Искать Заменить Поставщик
- А4 тэч --> A4Tech
Джет-А --> Jet.A
Хьюлит Пакард --> HP
ЭлДжи --> LG
итого около 150 позиций
Вижу, что при импорте правил некоторые атрибуты проставляются значениями "по умолчанию":
- А - Ок, пусть будет включено, хотя для особых случаев может понадобится управлять (поддержать (де)сериализацию при экпорте-импорте)
УР - учётом регистра желательно управлять (поддержать (де)сериализацию при экспорте-импорте)
УП - учётом пробелов желательно управлять (поддержать (де)сериализацию при экспорте-импорте)
У - удалением текста желательно управлять (поддержать (де)сериализацию при экспорте-импорте)
УБ - удалением блоков текста желательно управлять (поддержать (де)сериализацию при экспорте-импорте)
РВ - признаком regexp желательно управлять (поддержать (де)сериализацию при экпорте-импорте)
Назначение - крайне важно управлять (поддержать (де)сериализацию при экспорте-импорте) иначе при импорте назначение потеряется.
В настоящее время я не знаю как (кроме как вручную в PLI) создать 150 правил, которые будут отличаться от имеющихся 150-ти только "Назначением".
Найти - Ок, вопросов нет, экспорт/импорт работает
Заменить - Ок, вопросов нет, экспорт/импорт работает
СНБ - лично мне (пока) не нужно, но для унификации желательно управлять (поддержать (де)сериализацию при экспорте-импорте)
СКБ - лично мне (пока) не нужно, но для унификации желательно управлять (поддержать (де)сериализацию при экспорте-импорте)
Поставщик - Ок, вопросов нет, экспорт/импорт работает.
Прайс-лист - назначение данного поля не очевидно. В документации написано «тображение названия файла прайс-листа поставщика». Видимо действительно только отображение.
Из PLI мне не удалось его изменить, соответственно я засомневался: как отработает система правило, в котором установлен Поставщик, а прайс будет подгружен новый прайс этого же поставщика ?
Пожелание команде разработчиков: обратите внимание на функции экспорта/импорта. Их реализация избавит вас от необходимости развивать, тестировать и поддерживать скучные типовые функции, доступные в большом количестве офисных пакетов и спец. средств.
Ваше конкурентное преимущество – понимание насущных потребностей пользователей специфичного ПО по обработке прайсов и наличие более-менее стабильного фреймворка. Используйте свои ресурсы на развитее основных бизнес-функций, а технологические оставьте на откуп 3rd party SW.
Это не критика. Это пожелание успеха
