| 0
- 22.06.2016 - 11:11
|
есть файл экселя. в нем технические параметры комплектующих. Причем у разных единиц набор параметров может отличаться по количеству параметров (у кого-то только один диаметр присоединительной резьбы, у другого - два диаметра, у третьего четыре, у пятого есть еще и угол изгиба и т.п.). Т.е. заранее сколько будет полей (и листов) в файле неизвестно. Но хотелось бы использовать эти данные в запросе через внешний источник данных. Вот только непонятно, как обработчик будет работать с такой структурой... Кто-нибудь делал что-нибудь похожее?     | |
| 1
- 22.06.2016 - 11:50
| ну в 1С 7.7 делали ))) | |
| 2
- 22.06.2016 - 12:15
|
0-bma1 > А эти самые ексели, что, делаются разными людьми, со своим собственными хохряками? Тады никак. Иначе вначале разрабатываем шаблоны. И пока не удастся исполнителей им следовать (уговорами, угрозами увольнения, отстрелом, ets.) про обработчик даже не думаем. 1-101 > В 7.7 формировали ТЗ, в 8.х можно формировать структуру. Тем паче, что Клиент ТЗ не знает. | |
| 3
- 22.06.2016 - 12:24
| SQLite можно припахать. Два шага: на первом создаем .db, на втором из 1С присасываемся к .db | |
| 4
- 22.06.2016 - 12:48
|
(1) На клюшках любой дурак сделает. (2) Ну, что-то типа правил заполнения создать можно. Но все равно, структура листов будет разная. Вот это и смущает. | |
| 5
- 22.06.2016 - 12:49
| по моим представлениям в таких задачах надо четко условится о спецификациях обмена, должно быть четко понятно, что находится в каком файле и как расположено. То есть полностью формализован интерфейс обмена или как VZ называет шаблоны. Тогда открываешь, читаешь вид, затем по виду берешь нужный алгоритм и разбираешь | |
| 6
- 22.06.2016 - 12:51
| либо читать как есть и потом парсить ) | |
| 7
- 22.06.2016 - 12:59
| 6-USSR > "потом парсить" - это просто откладывать неизбежное на другой этап. Алгоритм распознавания никак не изменится. | |
| 8
- 22.06.2016 - 13:02
| (7)я согласен ) | |
| 9
- 22.06.2016 - 13:04
| Наличие четких спецификаций существенно повышает ответственность сторон, участвующих в процессе ) ID вида файла, в нем ID видов листов, в листе ID параметров и их значения | |
| 10
- 22.06.2016 - 13:07
|
2(5) Формально правила будут примерно такие: на каждом листе номенклатура с одинаковым набором параметров. На листе первой строкой идут слово "артикул" и потом названия колонок (стандартизованные, названия параметров из внутренней документации берется (там есть чертежи всех этих комплектующих с ключевыми размерами и их обозначениями латиницей и цифирью, типа L - Длина (общая), LT12 - длина хвостовика первого присоединения (у всех)), DD31 - диаметр третьей присоединительной части, FX1 - смещение оси первой присоединительной части от базы по оси х и т.п.) И со второй строки сами позиции и значения параметров без пропусков. Конструктора так ведут свою документацию. Проанализировать врукопашную файл без запросов - элементарно, а вот загнать его во внешний источник данных, чтоб внутри запроса его раскручивать и в отчеты можно было выводить - тут уже у меня затык в мозгах... | |
| 11
- 22.06.2016 - 13:21
|
10-bma1 > Просто для каждого варианта таблицы делаешь отдельный файл .db - Type1.db, Type2.db ets. В каждой таблице свой набор полей. Потом, при соединении просто пишешь: ПараметрыСоединения = Новый ПараметрыСоединенияВнешнегоИсточникаДанных; ПараметрыСоединения.СтрокаСоединения = "DRIVER=SQLite3 ODBC Driver;Database=" + Type1 + ";BigInt=1;"; ВнешниеИсточникиДанных.Type1.УстановитьОбщиеПараме трыСоединения(ПараметрыСоединения); ВнешниеИсточникиДанных.Type1.УстановитьСоединение( ); Запрос = Новый Запрос(); Запрос.Текст = "ВЫБРАТЬ .... Как-то так ... | |
| 12
- 22.06.2016 - 13:25
| 2(11) Заранее варианты не создать. Это же конструктора, они себе черта в ступе нарисуют и в свой файлик закинут. И там будет такой набор параметров, что никак заранее предусмотреть не можно. | |
| 13
- 22.06.2016 - 13:45
| 12-bma1 > Ну, извини. У компа интеллекта нема. Для него слово "Диаметр" - просто набор байтов. Он их не понимает. | |
| 14
- 22.06.2016 - 13:57
| (13)По поводу диаметра не совсем соглашусь, потому что в прикладном решении, которое будет читать (это видимо 1С) можно завести словарь идентификаторов и программа будет прекрасно понимать, что "диаметр" это "диаметр", а не просто набор байтов | |
| 15
- 22.06.2016 - 14:19
| 2(13, 14) Да ничего там расшифровывать не надо. Данные будут называться как колонки в экселе: LT12, FX2 etc. так пользователям и требуется. | |
| 16
- 22.06.2016 - 16:56
| Выход: написать "преобразователь", который будет превращать неформализованные мысли конструкторов в структурированные таблицы. И уже эти таблицы - давать на вход отчета. | |
Интернет-форум Краснодарского края и Краснодара |
