А есть под Linux какая-нибудь программка для простейшего складского учета?

[antares0]

Просто для интереса как соотносятся монолит и юникс-вэй?
У меня на фирме "заявка на перемещение" менеджеру и транспортная накладная. Как это отражает бух и отражает ли не в курсе.

[trdm]

Прога планируется монолит, но unix-way.
В принципе, на данный момент, ТОРГ-12 не требуются.

Если ты нормальный, отзывчивый к клиентам торговец, то ТОРГ-12, ТТН и Счет-фактуру лучше сразу планировать.
Их будут требовать бухгалтера клиента, а клиенты теребить тебя.

[Sanchess]

2 antares: транспортная накладная - это которая 1-Т? А заявка на перемещение как выглядит?

[antares0]

Транспортная накладная - это транспортная накладная. У нас внутренний управленческий учет.
Заявка на перемещение - товар, основание - > менеджеру, принимает решение: да, нет, потом - > кладовщику, транспортная накладная - > другой кладовщик, закрыл транспортную, принял товар.

[BIgAndy]

Транспортная накладная - это транспортная накладная. У нас внутренний управленческий учет.
Заявка на перемещение - товар, основание - > менеджеру, принимает решение: да, нет, потом - > кладовщику, транспортная накладная - > другой кладовщик, закрыл транспортную, принял товар.

Большая ошибка идти от требуемых документов,а не от бизнес-процессов. Несколькими постами выше я прописал лементарные операции и те вопросы, на которые любому предпринимателю приходится давать ответ. Документы под каждую транзакцию можно, в конце концов, придумать самому. При таком подходе (от документа) получаем неудобоваримую систему с документоориентированным интерфейсом.

Также видно, что системы , которые прикручивал Trdm не универсальные, а специфичные. Вместе с тем, что в хранении ГСМ, что в хранении сыра складские процессы практически одни и те же за редким исключением (как то процесс списания нескоько различается по процедуре, но для матмодели это не существенно)

Ха ТЗ порадовал. Краткость - сестра таланта.

Теперь вопросы топегстартеру:
ВЫ собираетесь работать с программой один или будет несколько человек, имеющих к ней доступ?
У вас есть иерархия товаров и артикулов. Как то:
Хозтовары::Бытовая химимя::СМС,
Хозтовары::железоскобяные товары,
Хозтовары::Бытовая химимя::моющие средства для кухни... и т.д и т.п

Вам надо знать что у вас на складе, а самое главное на ккаком и где хранятся?

[trdm]

Большая ошибка идти от требуемых документов,а не от бизнес-процессов.

По моему обшему мнению соль тут есть, но больше маркетинговой трухи в глаза, когда одну вещь продают под 2-мя разными названиями, причем у той вещи где в названии бизнес-процессы цена в десятки раз выше потому что название современней. и поскольку уровней абстракции в подходе "бизнес-процесс" больше с клиента можно содрать больше научив его той штуке которую изобрели специалисты по тюнингу.
это такой подход: изобрети проблему и продай решение. Лохоразвод ИМХО.

При таком подходе (от документа) получаем неудобоваримую систему с документоориентированным интерфейсом.

вижу вас не устраивают системы, для понимания которых вы не нужны, а как-же. Клиента не развести.
Документ есть обобщенная хозяйственная операция.
Почему простота и ясность, обкатанная десятилетиями хуже той мутноты которую ты впариваешь?

Также видно, что системы , которые прикручивал Trdm не универсальные, а специфичные. Вместе с тем, что в хранении ГСМ, что в хранении сыра складские процессы практически одни и те же за редким исключением.

Та ты что? Одни и теже. А ты в курсе того, что хотя и сыр и ГСМ учитываются (о как ты угадал) в нескольких единицах измирения ГСМ: килограммы и литры; сыры: штуки и килограммы, но у ГСМ-а есть своя специфика, он отпускаеся в литрах, а для учета килограммов применяется коэффициент, который зависит от температуры. Сыр не расширяется в размерах при допустимых диапазоах температур.
Кстати внедрял я типичные 1С-ные конфигурации, минималки - очень удобная вещь для расширения под любую торговлю, кроме медикаментов. Для них родимых много переделывать приходилось. Легче было купить спец-конфигурацию.

У вас есть иерархия товаров и артикулов. Как то:
Хозтовары::Бытовая химимя::СМС,
Хозтовары::железоскобяные товары,
Хозтовары::Бытовая химимя::моющие средства для кухни... и т.д и т.п

На счет иерархии товаров согласен, вещь удобная.
А вот насчет иерархии артикулов, увольте - допотопное средство. Уже не в арсенале. (хотя у на молочке работает, но персоналу пришлось выучить простынь артикулов).
Иерархия товаров в 1С-се нормально сделана, но встречал и на дельфе корявое дерево с приляпанной справа таблицей: не понравилось - нельзя развернуть полностью и найти по коду или наименованию.
У меня есть процедурина которая любую плоскую выборку из БД превратит в нормальное дерево с иерархией. Часто ей пользуюсь. Хотя и не очень оптимально сделана, но работает..

[antares0]

БИЗНЕС-процессы на складе?
там кстати как раз процесс описан, хоть и не бизнес.

[BIgAndy]

БИЗНЕС-процессы на складе?

Да, именно они. Без их формализации и строиь нечего.
Вот примеры оформления (простейшие)
:

там кстати как раз процесс описан, хоть и не бизнес.

ну, назвать это описанием, ане стебом трудно
Требование формализовать бизнес-процесс - не дурь. ибо тогда можно избехжать кучи лишних телодвижений и прояснить многие тонкости.

Если вам не нужна аналитика, воспользуйтесь тремя таблицами калька :приход, расход и товары. Из таблицы товары вы сможете создать выпадающий список для избежания ошибок ввода товаров , и сформируте сводную таблицу в том виде, котором вам надо. В этом случае не надо ничего формулировать, а будете вводить данные как вам будет угодно. Но так же будут делать все, кто будет иметь доступ к файлу.

Однако в BAse можно сделать проще. Но тут надо более формализовать задание: Как минимум, сформулировать политику доступа и политику разграничения прав на таблицы, формы и отчеты, записи и столбцы. А также кто сможет воодить данные, кто их редактировать, кто стирать и прочее.

MySQL может быть применен только для самых простых схем работы. В остальных случаях, если потребуется строить распределенную обработку данных, придется пользоваться более кашерными RDBMS (Postgres,DB2,oracle, они тоже бесплатны при определнных условиях.)

Потребуется определить: используете и вы весы, используете ли сканеры штрих кодов и прочее оборудование. Тогда без серьезного интрефейса или хотя бы base обойтись.

Знаете что? Скачатйе и запустите БизнесПак и сформулируйте, что увам там не подходит. Так будет проще.

[villager]

2 Sanchess: как то сразу не обратил внимания - а зачем Вам вообще ноут на складе? Кладовщик должен принять ТМЦ на хранение (согласно приходного документа), положить на полку и отметить этот факт в карточке складского учета. При получении расходного документа - быстро найти товар, выдать, и опять отметить это в карточке складского учета. Комп для этого нужен только при огромных объемах. А у Вас то и кладовщика еще нет (скорее всего).

А учет нужен для управления. Приход вносим в комп, затем расход (и печатаем накладную на отпуск товара для кладовщику). Смотрим остатки. Принимаем решение о закупке. Делаем инвентаризацию склада(сверка фактического наличия с компьютерным).
Если товар хранится на торговых точках - перемещаем товар на них, принимает от них отчеты о продажах (за день, неделю), возвраты и т.д., вносим в комп, опять делаем инвентаризацию на торговых точках.

ВСЕ. держим руку на пульсе. Все остально (по схеме BIgAndy) понадобится в случае успеха. Тогда придется внедрять другую (взрослую) систему (за взрослые деньги)

а для простейшего учета достаточно даже 2 таблицы - товары и движение (кол-во с плюсом - это приход, с минусом расход). тогда для подсчета остатков по товару достаточно простой команды SQL

[BIgAndy]

2 Sanchess: как то сразу не обратил внимания - а зачем Вам вообще ноут на складе? Кладовщик должен принять ТМЦ на хранение (согласно приходного документа), положить на полку и отметить этот факт в карточке складского учета. При получении расходного документа - быстро найти товар, выдать, и опять отметить это в карточке складского учета. Комп для этого нужен только при огромных объемах. А у Вас то и кладовщика еще нет (скорее всего).

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

Кроме того, плох тот ефрейтор, который не желает стать генералом.

[trdm]

Требование формализовать бизнес-процесс - не дурь. ибо тогда можно избехжать кучи лишних телодвижений и прояснить многие тонкости.

А никто и не говорит, что это дурь.
Дурь в данном случае поручать формализацию доморощенным специалистам.
Те картинки, что вы понавыкладывали в советское время назывались технологическими картами процесса. Просто процесса без лишней приставки "бизнес", которую теперь модно вставляю всегда и не к месту.
Они создавались техниками-технологами. Широкое распространение они получили в производстве.
Что собственно и правильно, по скольку было большим косяком разнести две последовательные точки сборочной линии на большое расстояние - затраты на транспортировку.
Но даже в те времена понимали, что лишний формализм - это глупость. По этому такие карты составлямись министерствами в целом на отрасль.
Вместо разрисовки схем использовались общие должностные инструкции, правила техники безопасности, уточняющие приказы и т.п.
Я же говорю: старая конфета в новой обертке, под новым брендом а по этому с большой ценой.
Не нужно формализовать простые вещи! Большая ошибка, закопаетесь.
Достаточно должностных инструкций и текущих распоряжений - они покрывают большинство регламентов.

[villager]

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

Кроме того, плох тот ефрейтор, который не желает стать генералом.

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

для контроля лучше вести учет в компе согласно документов (бумажек с подписями- сдал/принял), выводить остатки, и идти проверять склад-все ли на месте


"Бизнес-процессы" - красивые слова слова хорошо продаются, но не гарантируют правильную функциональность

[BIgAndy]

Дурь в данном случае поручать формализацию доморощенным специалистам.

Это элементарные меры безопасности при разработке продукта на сторону. Чтобы потом формальных претензий не выставлялись. Или вынести в обтдельный блок работу специалиста по формализации Бизнес-процесса.

Те картинки, что вы понавыкладывали в советское время назывались технологическими картами процесса.

Аппсолютно верно. Только в современной нотации технологические элементы ведения бизнеса называют бизнес-процессом. На самом деле это понятие шире, ибо включает "когнитивные технологии".

Просто процесса без лишней приставки "бизнес", которую теперь модно вставляю всегда и не к месту.
Они создавались техниками-технологами. Широкое распространение они получили в производстве.

И вы это рассказываете человеку у кого нсколько производственных бизнесов ?

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

Э-э-э нет.. Вспомните до сих пор актуальные в складской логистике инструкции П7 и П8. Складская логистика с советских времен не претерпела изменений. Только связи стали более устойчивыми и гибкими.
Более детализиованные техпроцессы реализовались средсвтами отраслевых министерств и

Не нужно формализовать простые вещи! Большая ошибка, закопаетесь.

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

Ничего подобного. Инструкции должны немедленно отображаться на програмный продукт. Иначе есть лема: если еть инструкция - она неизбежно булдет нарушена. У нас есть правило: Инструкия актуализирется при внесении изменений в нужный модуль или правила БД.

Например у нас неоднократно было, что поставщики присылали (сознательно) товар, который мы не заказывали. просто в рамках своей акции "А вдруг понрвится, потом будут заказывать" Кладовщик, естественно зная, что надо сравнить заказ с заявкой, сравнивает, но не может отелить одну железяку названием от другой с почти таким же, ибо не его это компетенция . Сумма приблизительно в пределах заявки и подозрений не вызывает. А инструкция гласит: "сравнить со всеми параметрами (вес, размеры, внешний вид, дизайн, название, артикул материал, органолептические свойства.) заказанного и полученного товара При подозрении на различие заказанного и полученного товара получить подтверждение, отказ или консультацию у лица, вставившего даный товар в заявку ". Кладовщик же не сравнивает по этим параметрам, или сравнивает, но к концу смены и внимание рассеяно.
Мы же сделали к этому правилу маленький интерфейсик, где кладовщик сравнивает с заявкой, в которой прописаны и отображаются все необходимые свойства вплоть до вншнего вида. И тут же выявляет несоответсвие. Или отправляет на согласование с заказавшим работником.. В любом случае процесс идентификации товара и решение о его приемке на склад становятся явными и всегда можно восстановить историю приемки товара и нати виновного в приеме товара, который нам не был нужен. Это самый мягкий пример, но были и нсайды, когда поставщики договаривались с менджерами и кладовщиками о поставке ненужной продукции или по несогласованным ценам.


За 2008 год таким образом мы сэкономии около 12-13% (!) от сумм, направляемых на закупки. и приблизительно на стоько же ненужные или сверхлимитные запасы на складе.
Ни один адынжс такого сделать никогда не сможет.

[BIgAndy]

В то время как в Win постепенно избавляются от него, совершенно неуместно переносить на Линукс эти атавизмы типа монолитных программ, бизнес-логику в СУБД и пр

И да и нет. БД тоже может быть структурирована на мелкие независимые, но связанные области ранения данных и правил.
И, собственно правило KISS нико не отменял. Монолитные программы - ИМХО зло. они не гибкие и трудно и дорого модифицируемые. Правда, к этому стремятся все почти разработчики.

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

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

"Бизнес-процессы" - красивые слова слова хорошо продаются, но не гарантируют правильную функциональность

Если их парвильно понимают и реализуют - приносит.
Просто, как правило, большинстов присутсвующих на форумах является составляющей частью этих бизнес-процессов и даже не догадываются о том, что они выполняют некоторые правила, спроектированные кем-то. Людей, проектирующие эти сущности бизнес-процессов, а ,тем боее людей, которые их (бизнес-процессы инициализирует) инициируют на форуме немного.

[trdm]

Например у нас неоднократно было, что поставщики присылали (сознательно) товар, который мы не заказывали. просто в рамках своей акции "А вдруг понрвится, потом будут заказывать"

это вы еще легко отделываетесь существуют монстры с агрессивным маркетингом которые отпускают ходовой товар только с нагрузкой из какого-нить барахла.

За 2008 год таким образом мы сэкономии около 12-13% (!) от сумм, направляемых на закупки. и приблизительно на стоько же ненужные или сверхлимитные запасы на складе.
Ни один адынжс такого сделать никогда не сможет.

вранье, от специалиста зависит.

Ни один адынжс такого сделать никогда не сможет.

Да легко, я же говорю, от специалиста зависит:

[BIgAndy]

Да легко, я же говорю, от специалиста зависит:

Ну, это уже расширения к стандартным конфигурациям... Какой смысл программить на идиотском диалекте 2С , когда все то же реализуется меньшим количеством кода в специально написанных придложениях.
При миграции на линукс мы изучали адынэс по косточкам совместно с франчайзерами. им очень хотелось нам впихнуть эту поделку.

Зы. Там, ( на скриншоте) как я понял, сравнение уже после оформления прихода/приходной накладной. А у нас в процессе оформления.

это вы еще легко отделываетесь существуют монстры с агрессивным маркетингом которые отпускают ходовой товар только с нагрузкой из какого-нить барахла.

Это фигня. Мы даже получаем товар от сетевых компаний минуя их сетевые дистрибутивные заморочки. Например не во многих магазинах вы увидете "Амвей" в розницу совершенно легально.. А всего навсего во время несанкционированной презентации в офисе фирмы отловили очередного дистрибютера, провели ео по нескольким инстанциям для сбора доказательств, что он работает именно от АМВЕйЯ и предложили мировое соглашение... Так что с этим товарищами-то как раз легко. Труднее с теми, кто ставит менеджерам условия расширения методом "катания".
Зы. Посмотрел сейчас... за 2008 год такое "застопеное"коичество его скопилось к отгрузке обратно за счет поставщика, что аж возрабовался.. Ибо раз в течение года не забрали, непросроченный товар подлежит "уничтожению"..

[trdm]

Да легко, я же говорю, от специалиста зависит:

Ну, это уже расширения к стандартным конфигурациям...

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

Какой смысл программить на идиотском диалекте 2С , когда все то же реализуется меньшим количеством кода в специально написанных придложениях.

Что-бы не тратить лишние бабки а заказывать и получать именно тот функционал, который необходим в данный момент.

[Sanchess]

Доброго времени суток всем!

2 BIgAndy:

Теперь вопросы топегстартеру:
ВЫ собираетесь работать с программой один или будет несколько человек, имеющих к ней доступ?
У вас есть иерархия товаров и артикулов. Как то:
Хозтовары::Бытовая химимя::СМС,
Хозтовары::железоскобяные товары,
Хозтовары::Бытовая химимя::моющие средства для кухни... и т.д и т.п

Вам надо знать что у вас на складе, а самое главное на ккаком и где хранятся?

Планируется, что с программой буду работать я. В дальнейшем, будет как минимум, еще один человек.
Артикулов нет, есть просто названия товаров (но если писать прогу, то поле под артикул нужно зарезервировать)
Иерархия есть, типа того:
- топливо
- бензин
- керосин
- мебель
-столы
-стулья
По складам - да, нужно знать где и сколько чего.
Бухучет на настоящее время не нужен. Нужны в первую очередь остатки товара на складе и печать накладных (тех самых, скан которой я уже выкладывал).
При проектировании БД можно зарезервировать поля, которые будут в дальнейшем использоваться для документов, о которых в этой ветке уже было сказано. На данный момент нужно то, что нужно.

[antares0]

Я бы нестал пытатся резервировать того что еще нет.

[Sanchess]

2 antares0: ну ладно, давайте попробуем рассмотреть кусок БД. Например "склад". Вот будет таблица - "склад". Какие поля в ней будут? Пока что мне будет достаточно:
1. Первичный ключ (назовем его wh_id)
2. Наименование места хранения (строковый тип, может быть "Склад_1", "Склад_2", "Дом", "Гараж").
Нормально? Я ничего не упустил?

[trdm]

Текущая карточка. Можно по ней смоделировать.

[antares0]

Гм, никогда не считал себя гуру БД, хотя и их тоже делал.
Хорошо бы с этим на спец. ресурс, но оттуда пошлют читать теорию.
По тексту.
Что хранит таблица? Если это склад, то где товары?
Если это список складов то почему он называется склад.
1. Ключ может быть инкриментом или uuid. Не то что бы на этом этапе важно, но все таки.
2. Если это все таки склад, то я бы не стал совать в него одноврменно, в одну таблицу несколько мест хранения. Таблицы хоть и одинаковые по структуре разные по содержанию. Хотя вопрос спорный и имеет и другие решения.

[BIgAndy]

Что хранит таблица? Если это склад, то где товары?
Если это список складов то почему он называется склад.

Э-э-ээээ как у вас все в голове намешано...

[trdm]

Что хранит таблица? Если это склад, то где товары?
Если это список складов то почему он называется склад.

Э-э-ээээ как у вас все в голове намешано...

Да уж, ребяткам явно не хватает знаний по разработке ИС(информационных систем), исследования ПО(предметных областей) и теории реляционных БД.
Я ж предупреждал, оставте это профессионалам, которые обучены этой специальности.
Дешевле заплатить им. У не обученного человека на это уйдет не сопоставимо большое количество времени
(относительно времени, которое затратит профи.). Это без учета времени на исправление ошибок проектирования.

[antares0]

Что хранит таблица? Если это склад, то где товары?
Если это список складов то почему он называется склад.

Э-э-ээээ как у вас все в голове намешано...

И тут пришли великие професмоналы и раскритиковали все нафиг (:
главный принцип - или молчать, или помогать.

[BIgAndy]

Да уж, ребяткам явно не хватает знаний по разработке ИС, исследования ПО и теории реляционных БД.
Я ж предупреждал, оставте это профессионалам, которые обучены этой специальности.

Ну, тогда новые профессионалы не рождались бы... Кто ничего не делает - то ничего не получает.

Sanchess! пока не заморачивайтесь струтурой таблиц. вы на выходе можете получить совсем не то, что предполагаете изначально.

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

[antares0]

тогда еще докинте несколько начальных шагов формализации, а то так по посту в день еще долго будет тянутся.

[trdm]

И тут пришли великие професмоналы и раскритиковали все нафиг (:

И что с того?

главный принцип - или молчать, или помогать.

Ну и ковыряйтесь сами в свое песочнице.

[BIgAndy]

И тут пришли великие професмоналы и раскритиковали все нафиг (:
.

Э-эм... Как бы это вам сказать.. Что раскритиковали профессионалы - вас это не радует? Если бы мне на ранних этапах предлагали такую помощь и критику, я бы вопил и прыгал от радости, ибо такая дискуссия передвами раскрывает такие глубины с подводными скалами, о которые вы самостоятельно воч тобы то ни стало ударитесь, что вы даже не представляете.
Но вы же можете возразить?
Это первое.

главный принцип - или молчать, или помогать

Вы опубликовали свое мнение на открытом к дискуссии ресурсе, и тут все могут высказывать свое мнение. И профессионалы и не очень. Затыкать рты как-то не очень. Это второе.
Вы не предполагаете, что у других участников могут ыбть отличные от ваших принципы
Если вы хотите руководить дискуссией, то таки надо что делать, активно вступая в переписку, а не ждать, пока решение принесут на блюдечке. По-любому этого не будет и за вас эту систему в добром умственном здравии никто делать не будет. Но помощь в освоении оказать могут. Только надо пользоваться таковым ресурсом с умом.
Это третее.

[BIgAndy]

тогда еще докинте несколько начальных шагов формализации, а то так по посту в день еще долго будет тянутся.

Все очень просто. опишите поэтапно здесь все действия, которые вы производите "с момента подъема до отбоя".. В том числе как ругаетесь с работниками, по каким вопросам.