iscrafmАндрей Ж. А Вас не затруднит "копнуть" ! Что-то пока проблем подход "просто фиксация", затем при необходимость "анализ" в том числе по методам lifo/fifo/среднее никогда не вызывал!! Но скорее всего не знаю каких-то "подводных камней" - просвятите плиз!
при отсутствии "зеленого" слоя, который менее всего подвержен изменениям, любые нововведения ( в "желтом") приводят к необходимости корректировки "красного", который и без этого достаточно часто корректируется. Конечно, если реакция на изменения вообще не предполагается (используйте "как есть" или не используйте), то этим можно пренебречь. Но это уже больше из области позиционирования продукта.
Данная картинка мне понравилась, но с позиции "абстрактного разработчика абстрактной системы" мне кажется она не полной и не гибкой. Хотя заслуживает отдельной теоретической темы в разделе "разработки ИС".

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

Каждый элемент структуры априори НЕСТАБИЛЕН!

iscrafmАндрей Ж.Но так как в ряде (фирм) случаев и настроек изменение имени товара может привести к изменению структуры ассортиментов, то данная операция ЗАПРЕЩАЕТСЯ.
Если простая корректировка ошибочно введенного наименования товара может привести к "поломке" того, на основании чего работают не "прогерские" понятия, а бизнес-правила, типа подбора товара, то это уже затрагивает далеко не программистов.
По моему "прямо" указал, что эта программная надстройка запрещающая действия пользователя, приводящие к "противоречиям" с "настроенными" бизнес процессами предприятия.

ViPRosТут тема ЕРП....
Ха, ... Ха - где мной было упомянуто ругательство "ERP" в применении к "универсальной учётной системы малого предприятия"? Что же я "больной" использовать его ЗДЕСЬ ?

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

iscrafmАндрей Ж.пропущено...
По моему "прямо" указал, что эта программная надстройка запрещающая действия пользователя, приводящие к "противоречиям" с "настроенными" бизнес процессами предприятия. я говорю не о вынужденом запрете на банальную операцию (то что она запрещена, я прекрасно понял, с чтением все в порядке), а о причине такого запрета, который не дает пользователю исправить банальную опечатку .
Один из "принципов системы" гласит, что любую операцию можно исправить в любое время... Он и отвечает на "наезд" - пользователь может ! Другое дело, что это может быть длительный и малоприятный процесс, что связано с моими "ограниченными" ресурсами на "удовлетворяемость" всех мыслимых "действий пользователя", а так же "принудительной диетой" системы.

Разберём конкретный пример "банальной правки наименования товара". Предположим, что включена система автоопределения "ассортимента" + товар "старый" (было множество приходов) + "ассортимент" входит в состав множества спецификаций покупателей.

1. Ситуация. Исправили в одной карточки "товара", следовательно некое количество "выпало" из доступа из спецификаций. Это может быть ошибкой, но может быть спец.действием для исключения отпуска по спецификациям ?

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

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

ViPRosАндрей Ж.пропущено...
Типа "враги" что-ли? Для этого есть описанная раннее система самодиагностики и восстановления информации. Враг "пройти может", но будет обнаружен и уничтожен!
навиный
Система самодиагностики и восстановления развивается более 8 лет и постоянно (раз в квартал) находятся "нелогичные" варианты информации, которые включаются в подсистему. Нахожу их я по "наколке" пользователей - нормальный процесс .

ViPRosУниверсальная? чо означает
Различные направления малого бизнеса. Наверняка имеются "направления" учитываемые плохо или очень плохо , но система перманентно развивается ...

ViPRosучётная? что означает, что учитывает, как учитыват, для чего учитывает, в какой метрике учитывает,...
Учитывает "бизнес-объекты", связнные с малым предпринимательством и которые можно "описать" в количественно-суммовом выражении. При "обнаружении" новых классов объектов у новых заказчиков система пополняется механизмами учёта и анализа "новых" объектов.

ViPRosсистема? какие эементы, как связаны, синергия,...
Программный инструмент, мой опыт внедренца и разработчика, замкнутая и комплексная автоматизация реального (не бух) учёта и полезного анализа деятельности предприятия.

ViPRosМП?
Малое (микро) предприятие.

ViPRos«УС Land». ?????
"Мой крокодил - как хочу, так и называю...", но первая часть У ниверсальная ( У чётная) С истема, а вторая часть для облегчения перенастроек:
1. Имеет 4 буквы
2. Начинаеться с "L"
3. Имеет, хоть какой-то смысл :)

ViPRosАндрей Ж., в последний раз спрашиваю "бизнес-объект" - где в твоей проге задан что это такое? как структруирован, кокое поведеие
"УС Land" манипулирует с объектами (бизнес) трёх типов:

1. Реальные, предопределённые. Товары, склады, адрес хранения, накладные, некоторые налоги, покупатели, ABC критерий и так далее. Она их ведёт, контролирует "правильность" и логическую "непротиворечивость".
2. Условно виртуальные. Описаны в инструкциях рекомендации по использованию и анализу, поведение зависит от специфики бизнеса, правильность ведения не контролируется, доступен анализ в любой "аналитике". Примеры: Свои предприятия, кассы, расчётные счета, статьи затрат, виртуальные товары, бухгалтерские проводки, начисление зарплаты, ассортименты, транспортная логистика и что угодно (придуманное мной для конкретного предприятия).
3. Виртуальный объект. Элементы "платформы" (уже вижу летящие тухлые яйца) придуманные пользователями и указанные в "отведённых" местах (коллекциях ВО). Программа даёт доступ только к анализу данных объектов практически в любом отчёте. Уже приводил реальные примеры объектов здесь и в других темах: "типы покупателей" (опт, розница, сети, хорека), "начисление износа оборудования в процессе производства", "схема начисления з/пл агентам, зависящая от типа цены покупателя и %от вала"... Вообще я здесь "не при делах".

ViPRosМП - где в твоей проге заданы ограничение такие, что дает эту трактовку?
Ограничения:
1. Здравый смысл заказчика.
2. Моя "жадность" до "желания поиметь задачу".

В завершении на сегодня (нашел картинки).

1. ОБЫЧНАЯ схема товарно-денежных оборотов (отношений) ОБЫЧНОГО малого предприятия.

И пара практических технологий:

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

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

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

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

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

Запрет отпуска при наличии просроченных накладных от покупателя.

Анализ и запрет отпуска для определенных покупателей (параметры клиента) определенным оператором. Программа анализирует число просроченных накладных и число дней неоплаты накладных.

Запреты на отпуск при просрочке лицензий, договоров аренды торговых точек, запреты при превышении определённого числа дней неоплаты или числа неполностью оплаченых накладных и так далее (больше не помню)


II. Прием заказов у клиентов. Процесс приема заказов оптимизирован на максимальную скорость приема заказа по телефону или лично оператором, при этом программа подсказывает условия прежних сделок с клиентами, автоматически определяет цены и ограничители по покупателю. Кроме этого комплекс встроено множество автоматизированных технологий заказов от покупателей/своих торговых точек. Рассмотрим их подробнее:

1. LO. В комплекс входит свободно распространяемая программа заказа товаров покупателями или своими торговыми точками. Обычно заказы (посылки) пересылают по электронной почте, хотя возможно и на любых носителях информации, например дискетах. Суть технологии состоит в том, что: Вы создаете в электронном виде посылку, содержащую сведения о товарах, ценах для покупателя и возможно остатков. Кроме этого пересылается акт выверки с покупателем. Затем покупатель/торговая точка при помощи программы «Заказы LO» на основе данных посылки формирует заказ, который пересылает в электронном виде поставщику (пользователю Lack). После чего поставщик автоматически обрабатывает заказ, формируя отгрузочную накладную на покупателя. При этом программа ведет и контролирует список «не удовлетворенных» заказов.

2. КПК. Реализована интеграция с системой «Мобильная торговля». На карманный компьютер передаются остатки товаров, клиенты торгового агента, долги, просроченные накладные. На КПК составляется заказ, который автоматически обрабатывается в подсистеме предварительных заказов системы Lack. Кроме этого имеется подсистема сбора мерчандайзинговой информации, автосброса кассовых чеков. А так же имелись (см. помойку дистрибутива) подсистемы интеграции с КПК "Оптиум" и "Foenix".

3. LVZ. Эта система заказов эмулирует систему заказов КПК на персональных компьютерах (Notebook), что во многих случаях дешевле, чем использование карманных компьютеров. Кроме этого в данной системе реализован «драйвер», позволяющий автоматически переводить заказы «внешних» покупателей сформированные в структурированном виде, например в таблицах Excel в формат системы LVZ. В отличии от Lo система работает по нескольким покупателям и адресам тороговых точек – пачка наименований и реквизитов передается в LVZ.

Схема приведена на рисунке... Всем доброй ночи!

Доброе утро!
"Я наклонился посмотреть не наклонилась ли она, чтоб посмотреть не наклонился ли я"

iscrafmАндрей Ж.Но у меня не РСУБД , т.е. "академически" ВСЁ НЕПРАВИЛЬНО. это я уже понял. А как решаются банальные ошибки, типа исправления наименования номенклатуры? Методом правки во всех записях где оно встречается ?
автор Все объекты, ссылающиеся на "товар" содержат ссылку лишь на "код товара" (объекта) следовательно любые изменения НАИМЕНОВАНИЯ (любых других ревизитов) автоматически "изменяются" при простотре данных объектах.

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

Но так как в ряде (фирм) случаев и настроек изменение имени товара может привести к изменению структуры ассортиментов , то данная операция ЗАПРЕЩАЕТСЯ
iscrafmмда... чем дальше в лес, тем больше дров. Чуть выше говорили о том, что хранение данных не подчиняется реляционным правилам. Теперь внезапно оказывается, что все же подчиняется. Тяжело понять о чем речь, к сожалению. Есть все же какие-то общепринятые термины, предлагаю их использовать.

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

iscrafmя говорю не о вынужденом запрете на банальную операцию (то что она запрещена, я прекрасно понял, с чтением все в порядке), а о причине такого запрета, который не дает пользователю исправить банальную опечатку.
авторОдин из "принципов системы" гласит, что любую операцию можно исправить в любое время... Он и отвечает на "наезд" - пользователь может! Другое дело, что это может быть длительный и малоприятный процесс, что связано с моими "ограниченными" ресурсами на "удовлетворяемость" всех мыслимых "действий пользователя", а так же "принудительной диетой" системы.

Разберём конкретный пример "банальной правки наименования товара". Предположим, что включена система автоопределения "ассортимента" + товар "старый" (было множество приходов) + "ассортимент" входит в состав множества спецификаций покупателей.

1. Ситуация. Исправили в одной карточки "товара", следовательно некое количество "выпало" из доступа из спецификаций. Это может быть ошибкой, но может быть спец.действием для исключения отпуска по спецификациям?

2. Ситуация. Исправили везде. Следовательно пользователь (имеющий права) должен поменять во всех связанных объектах! Нормальное желание - программа даёт возможность это сделать легко... Режим на картинке "изменение пачки спецпрайсов клиентов". Но возможны и другие "задействования" этого (ВО - не контролируется программой), о которых по принципам виртуальных объектов программа знать не обязана!
iscrafmВы пытаетесь запутать? Выше говорите о длительном и малоприятном процессе (что похоже на реальность), через несколько строк - о том, что пользователь может сделать это легко. Но в качестве примера, почему-то, приводится корректировка совсем другого рода. Вы же сами понимаете, что здесь аудитория понимающая "что есть что", к чему тогда эти "дешевые", извините, трюки. Подобные клиенты здесь уже были, я не думаю что есть смысл им уподобляться.


Вы что-нибудь поняли из обсуждения этой фигни? - Я нет!