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

[antares0]

Болое того. В моем ТЗ есть еще подроные треолвания к реализации back-end'а для подоной системы, что возможно только на RDBMS.

Это чтож за за ТЗ такое?
Чисто гипотетически, может уже стоит посмотреть на системы побольше?
Про ledger/ledgerSMB еще не упоминали. Но не в курсе насколько он развит в части склада.

[antares0]

Болое того. В моем ТЗ есть еще подроные треолвания к реализации back-end'а для подоной системы, что возможно только на RDBMS.

Что-то крутое ТЗ для простейшего склада.
Чисто гипотетически, может стоить посмотреть на большие системы. Или, прости господи, спонсировать доработку нужного.
Про ledger/ledgerSMB не упоминали. Про xTuple тоже, хотя последння переведенная версия осталась истрией.

[AndreyZh]

Здрасте, человек вышел с проблемой: нужна простая программа складского учета. А ты ему рекламу в нос?

Обидно! Хотел помочь, как разработчик и сразу обосрали! Только полный слепец мог тут увидеть мою рекламу, да и ещё и бесплатного программного продукта!

Уважаемый Андрей! Не смотря на то,ч что многие интересные

Где Вы видели, что свой инструмент позиционировал, как современный, т.ч. "склеивать" разные идеи это некорректно!

сам факт использования клипера xBase и VFP на линуксовом форуме может и должен быть причной пожизенноого бана и игнора...

Мой продукт под линуксом уже используют в 6 магазинах, а Ваш?

Да ладно больше не буду предлагать подробные требования к реализации back-end'а для подобной системы - желающие могут учиться на "своих ошибках". Единственно замечу, что "независимых от 1С разработчиков" осталось настолько мало, что грызня между ними выглядит как по-идиотски!

Еще раз извините, что вмешался в Вашу беседу!!!

[trdm]

Здрасте, человек вышел с проблемой: нужна простая программа складского учета. А ты ему рекламу в нос?

Обидно! Хотел помочь, как разработчик и сразу обосрали! Только полный слепец мог тут увидеть мою рекламу, да и ещё и бесплатного программного продукта!

Дык ты читай чего чел пишет: у него линукс (openSuse10.2) чего ты ему в нос виндовую софтину суешь?

[BIgAndy]

Обидно! Хотел помочь, как разработчик и сразу обосрали! Только полный слепец мог тут увидеть мою рекламу, да и ещё и бесплатного программного продукта!
Где Вы видели, что свой инструмент позиционировал, как современный, т.ч. "склеивать" разные идеи это некорректно!

Извините, если вас лично обидел. Но данная программа хоть достаточно "продивнутая", ну никак не под линукс

Мой продукт под линуксом уже используют в 6 магазинах, а Ваш?

Ваш продукт не может использоваться под линуксом, поскольку в линуксе mz/pe файры не запускаются. В линуксе ELF. А запускают в этих магазинах под вайном.
А значит, невозможно разделение пользователей на уровне PAM.

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

Единственно замечу, что "независимых от 1С разработчиков" осталось настолько мало, что грызня между ними выглядит как по-идиотски!

Еще раз извините, что вмешался в Вашу беседу!!!

Нет уж, вы еще раз извините, если вас лично обидел. Буду рад с вами побеседовать в дальнейшем.. Выпад был не в ваш адрес, а в адрес архитектуры приложения...

[trdm]

Мой продукт под линуксом уже используют в 6 магазинах, а Ваш?

Хотя функционал в нем заложен хороший, главным недстатком является файл- ориентированная архитектура.

Я не уверен. dbf - ные базы на моей памяти держали 80-90 пользователей (1Сv7). Так что на определенном уровне нормально.

[BIgAndy]

Я не уверен. dbf - ные базы на моей памяти держали 80-90 пользователей (1Сv7). Так что на определенном уровне нормально.

К сожалению я вижу обратное: постояные переклички "выйдете из программы все, база зависла" И блокировка записи производится в этом случае приложением. Кстати "переидексация" -прямое следствие таковой реализации СУБД. На уровне корректно работающей RDBMS подобные коллизии невозможны..

Зы в случае конкретно 1С RDBMS используется как просто хранилище даных. Приложения, скорее всего не обрабатывают события от сервера БД. Тем более не используют все возможности движков RDBMS, а опять-таки, логика управления базой реализована на уровне серверного приложения в лучшем случае, но есть подозрения, что и на уровне API пользовательского приложения

[trdm]

Я не уверен. dbf - ные базы на моей памяти держали 80-90 пользователей (1Сv7). Так что на определенном уровне нормально.

К сожалению я вижу обратное: постояные переклички "выйдете из программы все, база зависла" И блокировка записи производится в этом случае приложением. Кстати "переидексация" -прямое следствие таковой реализации СУБД. На уровне корректно работающей RDBMS подобные коллизии невозможны..

У меня другой опыт. несколько десятков баз. Серваки Win 2000/ Win NT/ Novell. Только один раз позвали - упал на колени файл журнала. Часа 2 востанавливал с пом. редактора. Хорошо структуру знал. Так что фифти/фифти. За "зависла" фаберже надо отрывать админу или тому, кто тянул сеть и не смотрел за ней, или тому, кто любит вайн.

[BIgAndy]

За "зависла" фаберже надо отрывать админу или тому, кто тянул сеть и не смотрел за ней, или тому, кто любит вайн.

У меня другой подход: приложение и бек-энд должны быть настолько хорошо спроектированы, настолько "железно", что ни один разрыв, ни одна поломка не должны вывести систему из квазиравновесного состояния ни одному даже самому одареному одмину. Просто он не должен суметь сдеалть такое.
Именно поээтому в качестве бэкэнда выбраны всего три RDBMS,обладающие соответсвующими качествами и осталвяющие в актуальном состоянии данные даже при физической порче HD.
Как раз такая авария произошла в пятницу. Один из дисков (а одмин почему-то с воткнул IDE WD )просто потерял головку и расчертил один из дисков (на нем хранились данные DB2 в RAW формате. ). В общем восстановили штатными средствами всего за три часа. При этом БД ни на секунду не прерывала работу.

[trdm]

Ты не путай рейды и алгоритмы. Не реально такие системы проектировать.
Обычно системы проектируются в расчете на стабильное железо и стабильные сетевые хранилища.
Исключая конечно веб приложения. Сложную систему под такие требования не спроектируешь.
Вернее спроетировать то можно, но количество кода будет возрастать в разы.
Например: начал транзакцию, блокирнул объекты - связь порвалась. Че делать?

[aikus]

Господа, а давайте сначало узнаем ТЗ, а уж потом начнём флудить. А иначе вся беседа ананизм напоминает - тешишь своё самолюбие умными фразами, а пользы топик стартеру не доставляешь.

PS это всё мой мнение, которое может быть сколь угодно далеко от истины.

[BIgAndy]

Вернее спроетировать то можно, но количество кода будет возрастать в разы.
Например: начал транзакцию, блокирнул объекты - связь порвалась. Че делать?

Вот вот вот.. Именно поэтому DB2, а не оракл. И, скоре всего можно будет Postgre начиная с версии 8.6 (по крайней мере таргеты так спроекированы)

Ты не путай рейды и алгоритмы. Не реально такие системы проектировать.

Мой опыт и мое первоначальное образование говорят именно об обратном.

Обычно системы проектируются в расчете на стабильное железо и стабильные сетевые хранилища.
Исключая конечно веб приложения. Сложную систему под такие требования не спроектируешь.

Причем в линуксе достаточно просто (безотноситеьно того, что написано выше. Хорошие RDBMS могут кластеризироваться самостоятельно без посредничества ОС).
В данном случае я описывал отказоустойчивость от сбоя IDE диска, который ни разу не был задействова в RAID, а был присобачен средствами самой rdbms в raw формате. Тоесть даже низкоуровневое форматирование было произведено средствами RDBMS, а не ОС,)
Нет, как раз с бек-эндом проблемма решена и на железном уровне и на уровне транзакционном (после поднятия упавшего RDBMS все точки транзакций остаются на своем месте, тем более если они зафиксированы при помощи точек отката,_ и тем более не страшно, если начавшиеся транзакции все-тки пропадут. ибо в этом как раз достоинство транзакций .
теперь остается только корректно научить работать с транзакциями прикладное ПО (user-side и middleware). Обычно стандартных обработчиков ог\шибок бывает достаточно. В c++/ пацкале еще надо писать некие бубны, а вот в старВасике все обрабатывается на уровне UNO. Пожтому я и говорил, что сокращет количество требуемого кода.

[Sanchess]

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

2 AndreyZh: возможно, когда-нибудь такая программа мне понадобится.

2 всем: ну вот, собственно, нашел я шаблон ТЗ, и заполнил его как смог возможно, что-то упустил, но все равно, просьба не пинать если что не так
Как я уже писАл ранее - в большой торговле я ни в зуб ногой.
Выкладываю скан накладной, используемой для внутреннего учета и ТЗ. С ней все просто - заполняется организация, дата, номер, наименование товара, ед. изм., кол-во, сдал и принял.
Поехали?

[antares0]

ОС на базе ядра Линукс

заменить на работающую под управлением ОС Линукс. А то петросян от зависти сдохнет.
Торгующие предприниматели тоже, как-то не очень.
вобще ну n страниц, ну этож е-мое. Нужно уважать чужое время.

По теме.
ТЗ написано под ananas-inventory.
Если "Религиозные обострения" то посмотри на то что, vilager пишет.
OOBASE тоже хорошо, но немножко уметь надо.

[trdm]

Доброго времени суток всем!
Как я уже писАл ранее - в большой торговле я ни в зуб ногой.

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

[Sanchess]

2 antares0: все, что необходимо заменить - заменим. нужно узнать мнение других участников форума.
P.S.: религиозными обострениями не страдаю.

[Sanchess]

2 trdm: ну просил же - не пинать
Хорошо. Давайте возьмем за основу Вашу минималку. Предположим, учитывая Ваш многолетний опыт, программа должна "уметь" (из поста №2):
Документы:
- Приходная;
- Расходная;
- Счет-Фактура;
- Ввод остатков товаров;
- Списание;
- Инвентаризация;
Отчеты:
- Остатки товаров
- Движения товаров;
Пара журналов:
- Общий
- * на каждый вид документа.
Так?

[antares0]

2 trdm: ну просил же - не пинать
Хорошо. Давайте возьмем за основу Вашу минималку. Предположим, учитывая Ваш многолетний опыт, программа должна "уметь" (из поста No.2):
Документы:
- Приходная;
- Расходная;
- Счет-Фактура;
- Ввод остатков товаров;
- Списание;
- Инвентаризация;
Отчеты:
- Остатки товаров
- Движения товаров;
Пара журналов:
- Общий
- * на каждый вид документа.
Так?

В принципе в такой постановке это отличается от ТЗ только количествено.

[Sanchess]

2 antares0: ждем ответа от trdm, затем будем прояснять по пунктам. Главное, не пинайте! я думаю, можно прийти к общему мнению

[antares0]

trdm признает только 1С и свои разработки.
Общее мнение на форуме?! Сынок, это фантастика :)
Есть твое мнение, о том что ТЕБЕ необходимо для работы. Оно с временем будет менятся.

[villager]

2 trdm: ну просил же - не пинать
Хорошо. Давайте возьмем за основу Вашу минималку. Предположим, учитывая Ваш многолетний опыт, программа должна "уметь" (из поста №2):
Документы:
- Приходная;
- Расходная;
- Счет-Фактура;
- Ввод остатков товаров;
- Списание;
- Инвентаризация;
Отчеты:
- Остатки товаров
- Движения товаров;
Пара журналов:
- Общий
- * на каждый вид документа.
Так?

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

счет-фактура - это тоже не документ по движению ТМЦ. Документ покупателю для оплаты, не более, и к учету отношения не имеет.
НО.
Если нужно резервировать товар по счет-фактуре, то можно делать внутренний документ перемещение товара с с основного склада на "склад" зарезервированного товара. Тогда всегда можно будет посмотреть остатки по такому складу и вернуть товар из резерва.

это все ИМХО, с учетом моего скромного опыта

[trdm]

trdm признает только 1С и свои разработки.

почему?
у меня просто свое мерило разных аппликейшинов и поделок: дизайн, КПД, расширяемость, оверхед, надежность, потребление памяти (в терминальных режимах сверх актуально).
может показаться, что я "признаю" 1С-ные разработки. Да, так и есть, но лишь некоторые пару процентов от того, что свояла 1С. )))
Люблю их за надежность и безгеморное применение.

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

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

2 trdm: ну просил же - не пинать

ладно, извини.

[Sanchess]

2 antares0: trdm может признавать что угодно, но его 16 лет против моих меньше месяца заставляют "прислушиваться к старшим"
Общее мнение на форуме - да, фантастика. Не спорю. Но истина, как известно, рождается в споре.
У меня, конечно, есть мнение о том, что мне необходимо для работы, но не факт, что мое мнение правильное.
И если уж браться за разработку программного продукта, то лучше я адаптируюсь к более правильному, чем появится никому кроме меня не нужное ПО.
Разве не так?

2 villager: давайте сначала разберем список по пунктам. Я знаю, что такое счет-фактура. Сейчас она мне на фиг не нужна, но в дальнейшем она мне понадобится, т.к. кое-какие планы на будущее имеются. А инвентаризация такая как Вы ее описали - штука нужная. Так что все в порядке.

P.S.: ждем ответа trdm.

[trdm]

2 antares0: ждем ответа от trdm, затем будем прояснять по пунктам. Главное, не пинайте! я думаю, можно прийти к общему мнению

чего вы от меня хотите? Что-бы написал это все? В свое время, как только с отчетником разберуть: нужно же в чем-то отчеты да документы выгонять да хранить...
а пока над этим работаю: http://www.1cpp.ru/forum/YaBB.pl?num=1218452481/119#119
ПС. Сколько ты можешь заплатить за подобную систему?

[Sanchess]

2 trdm: я никого ничего не прошу писать. У меня есть хорошая толстая книга по Qt4.5. К тому же, чтобы что-то писать, нужно знать, что писать. А вот это я и пытаюсь выяснить.

[antares0]

2 antares0: trdm может признавать что угодно, но его 16 лет против моих меньше месяца заставляют "прислушиваться к старшим"
Общее мнение на форуме - да, фантастика. Не спорю. Но истина, как известно, рождается в споре.
У меня, конечно, есть мнение о том, что мне необходимо для работы, но не факт, что мое мнение правильное.
И если уж браться за разработку программного продукта, то лучше я адаптируюсь к более правильному, чем появится никому кроме меня не нужное ПО.
Разве не так?

Понимаешь, обсуждение идет в стиле " а хорошо бы". И это хорошо и то неплохо.

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

[Sanchess]

2 antares0: еще писать нечего, но отвечу - да, я
минималку trdm'a можно брать за основу?

[antares0]

Да можно. Но первичку и печатные формы (счет-факту, ТОРГ-12) лучше выделить сразу. Я в БухУчете не силен, посему просим помошь зала.

[antares0]

в ananas-inventory эта минималка в принципе есть. Поэтому можешь посмотреть для примера.
Програму будет монолитной или скриптово-обвязочной (python, QtScript на выбор). Вбор не осмысленный скорее по желанию.

[Sanchess]

Прога планируется монолит, но unix-way.
В принципе, на данный момент, С-Ф и ТОРГ-12 не требуются.
Как будет считаться передача товара на торговую точку? как внутреннее перемещение?