Полигон-2

Добрый день.

С некоторых пор коллекция выросла до объёмов, в которых стало трудно найти, где именно лежит та или иная вещь.
Точно известно, когда/у кого/почём она была куплена, а в какой именно коробке и где на стеллаже она находится, уже не помню. Ситуация ещё более усугубилась переездом, когда коробки паковались в спешке, без описи, и по приезду они так же без распаковки ставились на стеллажи.

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

В идеале хотелось бы видеть в ней следующее:
1. Реестр единиц хранения, в котором будут учитываться отдельные предметы. Оформленный в виде таблицы, в которой будет инвентарный номер (можно сквозной порядковый), описание, и набор характеристик: габариты, масса, где/когда/у кого покупалось, цена, и т.п. Будет удобно, если этот реестр можно будет упорядочивать по группам/направлениям коллекции, но не обязательно.

2. Реестр ящиков и коробок, в которых упакованы одна или более единиц хранения. Номер коробки, тип, габариты, масса брутто, примечания. Удобно, если бескоробочные места хранения будут помечены каким-либо признаком, но необязательно, можно и в примечание вносить.

3. Самое интересное и важное - реестр стеллажей. Он должен содержать номер стеллажа, тип, число секций и число полок в каждом. Обязательно должен быть трёхмерный чертёж стеллажа, в котором будут отмечены места хранения коробок. С разбивкой по полкам и секциям. Чтобы можно было выбрать нужную коробку в реестре № 2 - и она подсветилась бы каким-нибудь цветом на чертеже стеллажа. Поиск значительно упростится.

Никому не попадалось что-нибудь подобное?
В принципе, можно и самому попробовать наваять, но опыт написания приложений с графическим интерфейсом невелик.

Schicchi написал:

[q]

Её использование позволяет решать подобные задачи крайне эффективно с минимальными трудозатратами.

[/q]

Угу. Конфигурация "1С:Даунгрейдер". "РаритетПриходнаяНакладная", "РаритетПродажаНаМолотке", "РегистрЯщикиКоробки".
Ну ее нафиг, такую эффективность. Если адаптировать какую-либо существующую конфигурацию (да хотя бы УТ), то на 1% нужного функционала там будет 99% барахла для торгового предприятия, который нужно или выпиливать (дофига времени), или терпеть. Если писать с нуля, то "минимальные трудозатраты" на 1С будут в несколько раз выше, чем просто наваять таблички на MS SQL [Firebird, SQLite] (нужное подчеркнуть) и морду для их заполнения на C# [Delphi] >нужное подчеркнуть> . Тем более что "трехмерные чертежи стеллажей" средствами 1С и не сделаешь, все равно надо какие-то внешние COM-объекты использовать.

Могу наваять на Delphi. Единственный вопрос - нужна ли парольная защита или нет ?

oldpcmuseum написал:

[q]

Использую в своём музее платформу 1С и купленную ранее конфигурацию для учета техники.

[/q]

Какой порядок цены у такого решения?
Эта конфигурация работает "из коробки" или надо ее дорабатывать?

Для себя я этот вопрос пока решаю с помощью сайта и книги Экселя, в которой макросы генерируют обновления для БД сайта. Но инвентаризация и точное расположение - это действительно сложные вопросы для самодельного ПО.

DrPass
Сарказм по поводу русскоязычного языка разработки понятен, тем не менее в своём сегменте 1С-ке просто нет равных. И разработка новой конфигурации в 1С будет ощутимо проще и быстрее чем огород из C# и SQL БД. Специализированное средство по определению решает задачу эффективнее универсального. А 3D модель стелажа IMHO из разряда "бантиков". Продуманная система адресации ячеек с маркировкой физических мест хранения IMHO будет достаточной для эффективного поиска требуемых данных. Рабочая конфигурация создаётся за пару вечеров, а "бантики", при большом желании, можно реализовывать в процессе работы.

DrPass

[q]

1C является специализированным средством как готовая учетная система.

[/q]

Под специализированностью имелось ввиду не существование готового решения, которое нужно "допилить", а тот факт, что 1С проектировалась как средство для разработки бизнес приложений. Типичной задачей такого приложения является ввод данных пользователем с последующим сохранением в БД и дальнейшим отображением в виде форм/отчетов. При этом в обязательном порядке должен присутстсовать функционал по сортировке данных, поиску в соответствии с заданными критериями, работе со справочниками. В спец. средстве такой функционал обеспечивается системой. Т.е. для того чтобы создать функционал по работе с простейшей таблицей, в 1С требуется описать структуру таблицы, нарисовать дизайн формы и весь перечисленный функционал начинает работать без дополнительного кодирования. В C# и других подобных универсальных средствах разработки, упомянутый функционал придётся создавать самому. Интеграция с БД в спецсредствах существует на уровне языка разработки, в универсальных средствах - на уровне библиотек. Спору нет, по "фенечкам" универсальные средства оставляют 1С позади. Но если наша задача может быть классифицирована как бизнес приложение и рамки, которые накладывает платформа 1C нас не стесняют, средствами 1С задача будет решена в разы быстрее. Именно по той причине, что 1С является более высокоуровневым средством чем, например C#.

А как у 1С с визуализацией? В моём случае локация места хранения это, пожалуй, наиболее важная фича, ради чего стоит затеваться со складской программой. Сами реестры можно худо-бедно вести и в экселе (сейчас в нём и веду, по мере инвентаризации буду дополнять, но без 3D-чертежа текстовое описание точного места хранения будет весьма расплывчатым).

8000 не такие уж деньги, если в ней это делается - можно купить...

Чётко разметить места внутри стеллажа нет возможности, т.к. коробки очень разные, мелких на полку влезает 5 рядов по глубине, а крупных коробок и штук типа ДВК - всего 1-2; по высоте вообще как получится, "сколько влезло до следующей полки". Держать пустые места непозволительная роскошь, стеллаж не безразмерный.

borisfox написал:

[q]

А как у 1С с визуализацией?

[/q]

В том-то и дело, что никак. В том смысле, что вообще никак. Только использованием внешнего софта, например, ActiveX-рисовалок

Schicchi написал:

[q]

Я говорю о платформе, не о конфигруации. Средство разработки не может проектироваться как "cредство ведения бухгалтерского и материального учета".

[/q]

Я имел в виду, что "средство разработки" там родилось как побочный продукт средства ведения учета. Оно проектировалось как инструмент, которым можно было что-то подшаманить в логике программы, а не для создания приложений. Это уже потом, когда выросло поколение 1С-программистов, из него стали делать что-то, похожее на платформу разработки. И только в последние годы оно стало для этого пригодным.


Schicchi написал:

[q]

Создайте простейший справочник в 1С и Delphi и сравните полученный функционал.

[/q]

А можно поконкретнее? А то я могу вам ответить тем же
Вы же поймите, что есть такое понятие, как "опыт". И у любого программиста, который закончил институт и хоть немного поработал, уже есть и красивый функциональный грид, и освоенный инструмент для работы с СУБД, и сделать в несколько кликов шикарный справочник, с футерами, сортировками, группировками и т.д. - это действительно элементарно.


Schicchi написал:

[q]

Мнение о том, что 1C "примитивный, кошмарный и неэффективный инструмент" может быть только у людей, которые не сталкивались серьёзно с разработкой/поддержкой учетных систем и 1С в частности.

[/q]

Вы не спорьте о вкусе плюшек с человеком, который их ест регулярно, и легко отличит вкусную и свежую от пересоленной и черствой Вы вот, к примеру, наверняка неплохой 1Сник. Но при этом понятия не имеете о возможностях других средств разработки, для вас оно замерло на уровне 90-х. Иначе бы вы не писали вещи вроде "Интеграция с БД в спецсредствах существует на уровне языка разработки, в универсальных средствах - на уровне библиотек." Даже если вы можете увидеть какие-то недостатки в подходе "подключил библиотеку и используешь классы для работы с СУБД" по сравнению с "используешь объект Запрос", то самый банальный пример - C# и LINQ.

Schicchi написал:

[q]

Инструмент, безспорно, специфичный, но повторюсь, свои задачи решает на отлично.

[/q]

Это верно. Но проблема 1Сников как раз в том, что они плохо знают другие инструменты, и это понятие "свои задачи" для 1С расширяют на "любые задачи", пытаясь на 1С разработать всё, что угодно.

borisfox написал:

[q]

Попробую пока по старому, реестры в экселе

[/q]

Зависит от количества ежедневных обновлений реестра и от количества задействованных работников. Если у тебя магазин, и за приёмку, за складирование и за выдачу отвечают разные люди - ёкселем не отделаешься: тебе нужна "мега-база" и несколько терминалов для работы с ней, иначе - всё запутается и будет разворовано (теми-ж работниками). Но если сие - твоя личная коллекция, и за все приход-расходные операции отвечаешь ты сам - нафиг тебе "мега-база"? Для удобства восседания на заднице? Ежли уж "очень чешется", перенеси из ёкселя в акцесс (M$access == настольная DB), как раз по профилю будет. А лучше - сразу садись за C(+++) и delphi и пиши своё с опорой на mysql (или аналоги). На время кодинга пользуй ёксель. Грамотно составленные таблицы коего сможешь потом относительно легко импортнуть в свою БД...

Schicchi написал:

[q]

а в том что предметно-ориентированные системы и языки (к которым относится 1С) предоставляют разработчику в распоряжение более высокий уровень абстракции чем универсальные средства разработки.

[/q]

Уровень абстракции может быть более высокий. Но вы совершаете типичную ошибку многих теоретиков. Дело в том, что уровень абстракции - это совершенно кхм... абстрактная штука, извините за каламбур. Которая вообще никакого отношения к эффективности инструмента не имеет. Это ни хорошо, и не плохо, это просто свойство платформы. Производительность же разработчика на какой-либо платформе (при условии, что он ей владеет) зависит от богатства ее библиотек, удобства инструментов и от количества готовых наработок. И только.
Как я уже говорил, вам нужно перестать мыслить шаблонами 90-х. Понятие "универсальная среда разработки" сейчас - это не текстовый редактор, дебаггер и набор библиотек. Ваши задачи по рисованию табличек, с фильтрами, с группами, с поиском - это типовая работа для 90% программистов мира, и естественно, универсальные инструменты разработки также давно позволяют делать их мышкой за несколько минут. Вы не поверите, но на тулбаре справочника 1С действительно нет ничего такого, что нельзя было бы просто включить в свойствах продвинутого грида.
Разработчик 1С может быстро наваять справочник. Два справочника. Может быстро сделать открытие одного справочника из другого. Пусть даже он справится на пятнадцать минут быстрее, чем разработчик C#. Но потом разработчика попросят сделать импорт справочника из экселя, и тут 1Сник уже будет возиться с COM-объектом. А когда его попросят сделать так, чтобы этот импорт работал на тех компьютерах, где нет экселя, и 1Сник сдастся. А еще 1Сника могут попросить сделать внизу таблички документов раздел "итого" с суммами. И он сядет полностью переписывать форму... А еще 1Сника могут попросить, чтобы было можно работать с программой с планшета
Это я перечислил пару элементарных задач, с которыми можно столкнуться сразу же при разработке обычной примитивной программы складского учета. И представьте себе, это всё делается элементарно с помощью универсальных средств разработки.
Поэтому еще раз повторюсь: 1С хороша там, где вам подходит готовая конфигурация, которую надо просто доработать. Использовать ее как платформу разработки приложений с нуля неэффективно, и не разумно. Оправдано только в тех случаях, когда либо надо интегрировать ваше приложение с 1С, либо когда вы другими инструментами разработки просто не владеете.

У меня такая есть. Правда, в виде веб-приложения.
Делал один студент на диплом под украинские требования инвентаризации, как тут - http://www.vs.com.ua/index.php?pageid=230

PHP+mysql. Локально можно развернуть на denwer-е, на котором оно и писалось.
В общем, кому нужно - пишите.