subject: RE: Выгрузка из 1с \ загрузка в оутлук
Народ, помогите!?
надо придумать экспорт выборки карточек товара из 1С в табличный файл (это пока не обсуждаем)
и импорт его в оутлук, в общие папки на эксченже (эксченж тоже пока не обсуждаем, ибо просто частный случай оутлучной папки, дайствовать будем VB с оутлуком - эксченж, видимо, ни причем - что оутлук ему отдает, то и раскладывает в свои уже папки)
по табличному файлу (dbf, xls... как получится...)
нужно нагенерить объектов (переделанный контакт с кучей полей пользователя)
в соответствующей папке, с соответственно таблице заполненными полями...
вроде и задача не особо сложная, и что-то никого найти не могу...
описание всей затеи, кому интересно:
примерно так:
0. все очень нестрого, везде нечеткая логика, по несколько вариантов работы на один пункт, и очень много нечетких, субъективных условий, параметров итп..
1. есть одежда, которую надо заказывать
2. ее дохрена, и с разными поставщиками разные условия работы по заказу...
Кто пришел к человеческому виду заказов, по каталогам, а у кого их нет... Не заморачиваются - нравится - берите, Не нравится - ваши трудности... Вам надо - вы каталоги и снимайте...
3. поэтому уже нельзя просто помнить, требуется вести записи, легкие для понимания, и легкие для получения на выходе документа-заказа поставщику...
(который бы в идеале подписывать и требовать исполения, сроки, неустойки, итп... Но это и предоплаты, а пока невозможно... Потому и просто договоренности устные почти... Посылаем, конечно, по почте, но это только примерные ориентиры, согласования, переписка...) При этом требуется гибкость и удобство интерфейса - типа фотку ОЧЕНЬ просто и быстро драгнуть прямо в карточку с сайта, к примеру...
Юзеры очень некомпьютерные, а надо данные подшивать, другим отдавать в понятном структурированном виде, колаборатьтся итп, ведь после заказа нужен будет контроль исполнения заказа, при приходу - то ли вообще нам отгружают... Причем важно - пришедшее - именно с такой рюшкой и именно заказанного цвета?
А иначе нафиг не надо такое, или состав не тот...
Учетные программы неприемлемы - там все очень строго...
Тот же 1с - застрелиться... Заказ может содержать только карточки товара, которые есть в базе.
Но они точны - дальше некуда, со всеми параматрами, а где их взять пока идут терки типа "а вот помните, в прошлом году на выставке была моделька зелененькая такая, ну еще там на пуговке, с бантиком на попе?"
Какие там нах артикулы итп при таких разговорах... И какую карточку включить в заказ?
В которой заполнено только наименование, да и то - описательное, не точное? А как в том же 1с указать, что по этой модели надо Только 3 размера на девченок худеньких, да еще в 4 цветах, и если есть, то 5й и 6й на их усмотрение, "но только не фиолетовый"
- это что, на все такие неточные карточки позаводить, на цвета * размеры... Это только один артикул, который еще не знаем точно будет ли вообще...
Столько мороки, а фабрика скажет - нуегонах, нет такой пряжи, а закупать под вас если - берите по 1000 штук...
Тут уж мы сами скажем нуегонах... А работы будет проделано пустой в 1с - не в сказке сказать, не бульдозером убрать...
Представь себе сделать такую кашу из... рабочей базы... Причем не из какой нибудь, а из основной учетной - часть карточек захотелось бы использовать, имеющихся...
+ к ним назаводить столько неточных... Все в одной базе... Во гимор будет...
4. очень многое не повторяется, поэтому заказы не всегда могут использовать наработанную базу карточек товара
5. соотношение в заказах товара нового и того, который уже может быть описан в базе примерно 60% на 40% или даже 70 на 30%...
6. для заказа важна картина в целом, и для заполнения магазина могут использоваться свойства товара, которые учитывать в торговле не очень важно, (они будут учитываться, но в другой базе и по-другому, только по точным фактам, товаровед заведет) хотя и желательно - набор параметров в заказе несколько другой, и шире. Приоритеты другие - не учесть каждую ерунду точно, а обеспечить закупку нужного товара, заполнение ниш итп в ассортиментном ряду непрерывным спектром товара, на все требования, группы итп... Ну и примерно оценить сроки, суммы... а по учету уже реальные факты пойдут...
(Это все тоже предмет тёрок, никакой формализации этого в программы не светит...) А что там состав чуть дугой, или не раздобыли товар №1 а вместо него взяли №101 и 102 - это уже не важно, пробела нет, товар выбрали и сочли, что он подходит и будет продаваться - остальное проблемы учета товарного, в 1с, товаровед разберется... Тем более, данные заказа напрямую в учет не долны попадать - херня получится... Эти данные, неточные(1), едут поставщику\производителю, там неточно(2) выполняются, потом ПО ФАКТУ(3) в учет приходуется - не "что собирались", а именно по факту...
7. система заказа состоит вообще-то из 3х частей...
7.0 менеджер по закупке\стилист создает ассортиментную политику, несколько абстрактную от реальности, а не сразу прямо заказ, Но так дело обстоит не во всем... Одни групы - формируем задачу, что искать, потом ищем и заказываем, другие - смотрим и заказываем, что есть, + куча исключений и прочая женская логика
(ой, счас накажут %)
Последовательность, приоритеты, методика примерно такие:
Нужны к сезону следующие группы товара: юбки короткие, длинные, платья, жакеты, итп...
Какие именно: яркие | спокойных расцветок итп параметры, (с учетом того, что уже имеется) Откуда их брать: вспоминаем старые удачные модели, выбираем новые по образцам и каталогам...
На примере юбок:
На летний сезон нужны: юбки
Короткие, средние, длинные....
Яркие, спокойные......
Из старого - 1,2,3,4,5,6,7...
Из каталога А - 1,4,5,6,8,11,
из каталога Б - 4,6,8,9 ...
По каждой модели размерные ряды, причем не полные - что-то от меньшего до среднего, Что-то только большое, итп...
Подход к разным двум частям заказа
(оформившиеся желания, по повтору удачного старого и выбранного нового, по заполнению 3й части - ассортимента) разный...
7.1 "дозаказ" - модели такие были, и хотим их еще раз. В базе учета они описаны в виде карточек, Но никто особо уж в этом ковыряться не будет... Если что и хотим повторить, то "по памяти" закупщика, продавцов...
"помнишь вот такие [/... /... /... /... ] кофтюли - улетали с юбками 33А как комплект - на ура, еще берем..."
7.2 "собственно заказ" - то чего еще не было, но видели образцы, или они уже у нас, или каталог, или еще что-то такое...
Долго я думал, как это реализовать...
Пришли к тому, что сначала ведут записи, простые и не очень точные(в некоторых параметрах), но с соблюдением некоторых законов... Совсем простых...
Запись в базе заказов - описывает 1 артикул, со всеми вариациями по размеру, а не одну конкретную вещь Для каждой вариации по цвету делается отдельная запись...
Вообще говоря, производители кАзлы... Должны вариации метить по разному, артикул должен быть кодом товара, вариации (кроме разве что, размеров, не все (мало кто кроме нас) по ним аналитику ведут) с соответствующей разницей маркировки...
Но... Пока так, как есть:
Юбка А1 красная, 44-1шт 46-4шт итп + описание и куча параметров...
Юбка А1 зеленая, 44-3шт 46-5шт итп + описание и куча параметров...
Юбка А1 синяя, 44-6шт 46-8шт итп + описание и куча параметров...
...
Юбка А44 красная, 42-1шт 44-1шт итп + описание и куча параметров...
Юбка А44 зеленая, 44-2шт 46-3шт итп + описание и куча параметров...
Юбка А44 синяя, 44-4шт 46-4шт итп + описание и куча параметров...
...
А потом, по ним, делаем документ...
А что там - все это ноухау - на тебе файлик, открой и посмотри прям так, все очень просто и понятно...
Если у тебя оутглюк есть
, чтоб поиграться - создай папку типа "контакты", а эту форму опубликуй там за главную...
И посмотри...
Вся прелесть этой штуки в количестве и скорости... Пока открыл одну карточку - не оценишь... Просто прикинь...
Программеры - все забывают одну мелочь:
Если юзверю неудобно - забъет... И следующий тоже подза и забъет...
В инете правило 3 кликов, а то покупатель уроет к конкуренту и там купит...
А собственный юзверь все 100 кликов на 1 позицию делать "будет, я сказаль?" - фих...
И еще программеры забывают делать тесты не на 3 записях, а * 1000...
(и еще полезно в качестве юзера представить свою маму, если только она не программер
- представить с закрытыми глазами, как ты ей показываешь, учишь там, объясняешь... Надолго ли тебя хватит, если поменять маму на девочек с недостаточным опытом...) И тут же становится все ясно. А формально тестят - 3 записи сгенерил, вложенных окон наплодил (1с -у жас в этом плане, цену к примеру поставить - на одну позицию еще ничего, а на 100 - озвереешь... Это только если ставить, когда все понятно, а если еще смотреть 2 отчета, думать, смотреть на сам предмет и советоваться, мнения продавцов спрашивать, и только потом ставить - ох...)
Пока можно себе позволять не генерить отчеты \ документы по такой базе автоматом, а отборами \ группировками \ сортировками - вывести на экран только то, что надо, Выделить, и в эксель... А там уж немного разукрасить и отправить как документ...
Но это не страшно, и вообще, трудно по-другому придумать...
