FinSoftНечаянно засветил сайт...
Извините! (помню Ваше желание пока не светиться) Не моглось писать, что то умное про "себя", но засветил свой "бизнес подход" - только "коньчик" покажите (конкурентов заставляю показывать), а я за него вытащу всё что мне нужно для "очернения" и "победы" у заказчика.

iscrafm, "Возьмите тот же FireBird и будете вспоминать о нем в разы реже, чем о DBF"
По заказу, очень давно делали "дисконтный сервер" для маленькой сетки.. В начале было Delphi+Paradox, но видно чел решил изучить FireBird и переписал с использованием данной СУБД...

Бизнес на этой програмке у него не пошёл, хотя и установил в 2-5 фирмах. Бросил эту программу и даже "искал счастья денег" в Мск. Уже 4 года "отбивается" от клиентов тем, что "код утерян". Мне пришлось искать спеца по FireBird, который примерно раз в квартал (в каждом) "оживляет" данную систему чего - то правя в БД. А пару раз клиентам меняли карты, по причине "нового" пополнения БД (были невосстановимо разрушены). Тема и программа "больная", т.к. скорее всего мне придёться писать данный контур для "УС".

iscrafmчто касается "искать спеца"... там нет ничего необычного. Все,можно сказать, стандартно. Одна из наилегчайших в освоении и адмнистрировании (при полном его отсутствии) СУБД. Вопросы начинаются на очень больших объемах, но микробизнесу это не грозит. А если учесть возможность "встраивания"... Хотя, претендетов на эту роль масса. И DBF в этом ряду вспоминается только как история. Объетивно.
Мне сложно рассуждать о теме (лёгкости FireBird), т.к. знания только в объеме достаточном для постановки задачи и контроля исполнения... Вижу только факты ! Можно было бы сказать классическую фразу о "кривых руках", но мне не нужно "охмурить" клиента, а лишь помочь в "сторонней" задаче существующему клиенту. Как следствие мне известны сложности нахождения "абы какого спеца", не говоря уж такого, для которого "одна из наилегчайших в освоении и адмнистрировании". Для прикола посмотрите http://www.sql.ru/forum/actualthread.aspx?tid=781880 - "наивные албанцы" в Саратове ищут спецов на Oracle... на 15тыр.

FinSoftНепонятно, откуда такие выводы. Просто обсуждать прикладной функционал не так интересно - за многие годы работы все его уже давно обсосали со всех сторон.
То есть Вы полагаете, что все бизнес-задачи в Вашей программе решены? Пусть не так жёстко, а для малого бизнеса то же решены? И Вы уверены, что они решены, как реально хотят потенциальные (реальные наверняка "пообвыклись") пользователи?

ViPRosаааааааааааааааааааа
Добрый день!
Пока милые девушки - оперши во главе с их "мамочкой" (гл.бухом) не пускают на сервер... Пару замечений, отвечу после работы (сегодня короткий, надеюсь день)

Ув. Сахават Вы вероятно, что-то интересное хотели "объявить", но каюсь - не понял... Объясните, как гаишнику "медленно и два раза".

FinSoftАндрей Ж.пропущено...
То есть Вы полагаете, что все бизнес-задачи в Вашей программе решены? Пусть не так жёстко, а для малого бизнеса то же решены? И Вы уверены, что они решены, как реально хотят потенциальные (реальные наверняка "пообвыклись") пользователи?
Есть вопросы стратегические, есть тактические. Обычная ситуация, когда есть понимание, как реализовывать ту или иную функцию, но реально включена в проект она будет только при наличии запросов от клиентов и на их деньги. Решение стратегических вопросов - это наши деньги, наши инвестиции, этим надо заниматься постоянно. Обсуждение тактических вопросов, если на них нет клиента, воспринимаются слишком абстрактно.
Здрасьте!
Согласен и не очень одновременно.... Обоснуйте более развёрнуто:
1. С одной стороны сам часто "возмущался", когда, напрмимер АВистам задавали "непотребные", высосанные из пальца задачи... Считая нет нужды, зачем время тратить!
2. С другой есть множество задач... Многие более-менее описал Garya, которые интересны в практическом плане, но просто клиенты их пока не понимают, что бы сформулировать и виде "заказа" на разработку.

Добрый день! Вот и закончилась трудовая неделя :-(

Очень многие нюансы учёта и многие технологии зависят от определения «товара» в системе . Мне кажется, что многие программы в вопросе понятия «товар» несут идеологию «советской системы бухучёта», что заставляет их разработчиков придумывать хитроумные механизмы манипуляций с товарами и их связями с другими учётными объектами.

В «УС Land» вся информация по товарам, материалам, сырье, услугам, основным средствам храниться в одной таблице Wares . Для ведения данной инфы рекомендуется единственное ограничение «при изменении цены закупа или поставщика вводится новая карточка товара», что необходимо для ТОЧНОГО расчёта дохода и расчётов с поставщиками. Т.е. в системе может находится «куча» одноимённых товаров. Но даже это может и не быть «минимальным оперативным объектом» - допустимо (и многие ведут) размельчение «товара» по партиям (датам прихода) или по другим ключевым для бизнеса атрибутам, например «дата розлива/производства», «ГТД» или «серийный номер».

Посмотрим на справочник товаров, где будет виден ещё одна «изюминка» системы – при просмотре табличных объектов программа «старается» отразить максимум полезной информации в «таблице» (без открытия карточки объекта), что у некоторых начинающих пользователей вызывает ассоциации с «газетным текстом».

Так же «открыт» один из режимов справочника и вообще их более 40… Свойство системы по возможности интегрировать взаимосвязанные объекты (управлять одними из других) и получать всю полезную информацию «из одного источника». Здесь мы смотрим, как «товар» распределён по складам.

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

Для управления программой достаточно знать несколько клавиш (подробно при вызове подсистемы помощи):
Insert – Добавление строки
Tab – изменение
Delete – удаление
Enter – подтверждение
Esc – отказ
F3 – принудительный вызов справочника
F2 – вызов меню задач режима (задачи вызываются выбором из меню или нажатием "горячих клавиш")… Вот данное меню мы рассмотрим на картинке .

Оно же показывает, что скрывается за внешней примитивностью интерфейса программ системы и что «уместилось» в 100000 строк её исходного кода , ведь это один из сотен оперативных режимов системы .

И наконец посмотрим на КАРТОЧКУ ТОВАРА... Здесь переопределяется большинство атрибутов "товара" (ещё десяток через меню). Почти все атрибуты можно отключить в режиме "администратор/настройка/задание полей справочников/справочник товаров".

Заполняется данные карточки "молнееносно":
1. Берём "похожий" товар (встаём на него), напрмер меняется только цена закупа
2. Дублируем карточку товара (вообще практически для всех объектов системы можно создавать "клоны", отличающиеся атрибутом "код объекта")
3. В "дубль" заходим в режиме изменения (Tab)
4. Меняем только необходимые реквизиты
5. Остальные "пачкой" подтверждаем клавишей PgDown

Пока всё! Жду вопросов или "критики" в форме вопросов?

iscrafmАндрей Ж.Очень многие нюансы учёта и многие технологии зависят от определения «товара» в системе . Мне кажется, что многие программы в вопросе понятия «товар» несут идеологию «советской системы бухучёта», что заставляет их разработчиков придумывать хитроумные механизмы манипуляций с товарами и их связями с другими учётными объектами.

немного не понял, что понимается под идеологией «советской системы бухучёта» и хитроумными манипуляциями. Но в целом, подход обычно такой:
определение "товара'"- это общее описание свойств. Существует еще понятие объекта учета запаса (название не столь важно), которое определяет перечень характеристик, которые являются именно атрибутами карточки учета запаса. Все карточки учета запаса действительно хранятся в одной, обычно, таблице. Перечень атрибутов, по которым эта карточка создается - настраивается. При отсутсвии в картотеке карточки по заданному набору атрибутов - создается новая. Т.е. никаких хитроумных манипуляций. Или что все же имелось ввиду?
Добрый вечер!
Какое хоть описание работы с номенклатурой (расчёта себестоимости, прайса, бухпроводок и других "смежных" тем) большинства учёток почитать, то возникает уверенность, что работать (считать) можно лишь по fifo/lifo/среднее. "Народ" ломает "копии", обсуждая наилучшие алгоритмы расчёта данных понятий и "тужиться" показать всеобъемлемость отработки данных понятий в "своих" системах.

Не желания "поднимать" данные пресс-релизы - сами их наверняка читали. «Советской системы бухучёта» - данные темы неоднократно на форуме обсуждались, основном в аспекте "от куда растут ноги у современных учёток"... Но в общем - это идеология программ, где первичным является "журнально-ордерная" система бухгалтерского учёта, на которую пытаются "навесить" функционал управленческого учёта и анализа. Тем десятки, горы теоретического словоблудия - нет желания их реанимировать... Желающие понять наверняка поняли, что мной было сказано .
В каждой программе "по своему" разделены понятие товары/заказы/запасы/карточки и так далее... Мне нужно было данную тему пояснить, так как без понимания оной сложно будет понять подсистемы производства/заказов/электронного обмена/складской логистики и так далее.

iscrafmт.е. такое понятие как "номенклатурный справочник" отсутствует?
Термины могут быть различны у программ - в "УС Land" это называется "ассортимент", но радикальное отличие, что базовое понятие "товар", описанное выше, а "ассортимент" - виртуальная надстройка над "товаром", используемая в части оперативных режимах и при построении отчётов... В том числе в терминах lifo/fifo :)

iscrafmВодка "Журавли" по 50 руб и таже самая водка по 55 - суть разные номенклатуры и записи в базе данных
Это разные записи в справочнике товаров (надеюсь цену закупа имели в виду)! Это даёт множество возможностей реализованных понятными для user и простыми для системы, например решение задач типа:
1. Расчёт рентабельности поставки
2. ТОЧНАЯ прибыль (доход) от реализации
3. Изменение цен закупа "задним числом", например зависящие от условий оплаты
4. Оприходование и начало продаж товара без "полного комплекта" сопроводительной документации и так далее...

iscrafmи такое понятие как нормализация не применяется?
В данном случае ПРИМЕНЯЕТСЯ, но с оговоркой: "товар" - это минимальная оперативная единица учёта , которая ссылается да другие справочники по связи "один ко многим". Задавая вопрос Вы ИМХО подразумевали "вложенность связей":
1. Справочник уникальных наименований (один ко мн.) -->
2. Некая таблица (в терминах 1С - номенклатура) содержащая описание реквизитов объектов -->
3. Куча справочников, но объекты которых ссылается таблица 2.

У меня НАОБОРОТ... Почему и так подробно описывал выше:
1. Таблица полного набора реквизитов "товара". Очевидно, что наборы части реквизитов у большинства одноимённых товаров повторяются, что является нарушением реляционных правил . Но у меня не РСУБД , т.е. "академически" ВСЁ НЕПРАВИЛЬНО. (один ко многим) -->
2. Куча справочников, но объекты которых ссылается таблица 1, в том числе справочник "ассортиментов", котрый может (не обязательно - об этом ниже) содержать уникальные наименования "товаров" со своим набором реквизитов.