[quot FinSoft]Андрей Ж. Добрый день! Что-то скучно стало в "ERP системах"...Конечно больше интересует мегасуперплатформа, а точнее есть ли приведённый отчётик в любой её стандартной конфигурации? - Если есть, то пожалуйста укажите конфу, версию, релиз...
Спасибо за "купеческую" щедрость в ответе , но основное примечание, где меня "раздирает" любопытство - это в любой её стандартной конфигурации СуперМегаГигаСистемы. То, что на её платформе можно многое сделать прекрасно понимаю. Второй "прикол" данного отчётика - простота восприятия, построения и полезность для бизнеса и отсутствие "аналога" данной аналитики является ИМХО большим упущением. Теперь по остальным примечаниям - конечно в "УС Land" это реализовано

FinSoft В стандартных такого не видел . В заказной когда-то делал и по поставщикам, и по покупателям, и по товарным группам, и по прайсам. Только в более развернутом виде. Там можно было, например, вывести детализацию по товарам и подготовить заказ на закупку. На мегаплатформе это было не очень удобно, но работало.
В принципе в УС есть несколько систем заказов, в разрезах поставщиков, разделов, виртуальных объектов, анализируя, в том числе прогнозируемый спрос и т.д. На рисунке отражу самую примитивную из них .

Но раздирает любопытство по СТАНДАРТНЫМ КОНФАМ Ц-1 - это предмет спора?

P.S. Ко мне обратился товарищ-оптовик из Рязани и я отправил его к Вам на сайт рекомендовав "Купецъ"... Надеюсь Вы не в обиде?

Добрый день уважаемые разработчики!

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

Изначально (у них существенно более примитивный его вариант) данный тип анализа был подсмотрен в системе "Фолио", а здесь его радикальное расширение и углубление (обычный способ воровства идей для УС Land).

Параметры построения отчета: Указываем период времени для анализа товарных запасов, тип себестоимости (в УС - это виртуальное понятие, основной суммовой анализ), накладываем ограничители на произвольную группу складов/отделов, поставщиков, разделов учёта и т.д., выбираем товарный объект для анализа (Ассортимент, Поставщик, Раздел прайса, Свободный код, Склад/отдел, Алкогольный код, Метка товаров (коллекция виртуальных объектов), Серия/ каталожный номер/ артикул, страна происхождения ( в последнем разрезе, из-за соблюдения коммерческой тайны отражено на картинке )

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

iscrafmАндрей Ж.,
в чем смысл? В различных системах есть множество различных отчетов. Каких-то оригинальных показателей на приведенной картинке не наблюдается. В том или ином виде они присутствуют в разных системах.
В чём тогда проблема? Дайте пожалуйста скриншот и параметры построения "схожей" аналитики, где бы компоновались основные атрибуты данного отчёта, т.е. товарные остатки рассматривались бы в "динамике". А так же можно было его делать по любым товарным объектам.

iscrafmдаю. Смысла в этом нет (в давании), просто была готовая картинка из документации. Основная мысль: оборотка в том или ином виде есть в любой системе. Ничего удивительного в отчете нет. Какой смысл делать подобные вещи (я имею ввиду банальные отчеты) предметом споров?
Ничего с лупой смог рассмотреть! - Типичное "не то"... Это в некотором роде видоизмененная оборотка, не рассмотрел по чему, т.е. остаток на начало/приход/расход/остаток на конец - таких у меня "вязанка". Более того имеются варианты для выгрузки в офис, используя которые аналитики получали, в некотором роде углублённый анализ по товародвижению.

Чем "отчет типа Фолио" отличается от "обычной" оборотки:
1. Собраны разные "товарные" количественно-суммовые измерители.
2. Анализируется статистика по отгрузкам на уникальные объекты: адреса, клиенты, накладные. Т.е. параметры "частоты" продаж по объектам учета.
3. Самое главное - товарные объекты "оживают", демонстрируя свои качественные для бизнеса свойства.
4. Товарный разрез может быть любым, т.е. можно "пропустить" поставщиков, отсеив "беспонтовых" или, например проанализировать товарные группы (полный список приведён).

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

iscrafmЯ и спрашиваю: какой смысл в обсуждении ее наличия в любой системе?
Обсуждать кого либо или некую систему не хотелось бы! Но очень много систем на данном уважаемом форуме позиционируются, как "готовое, а то и комплексное решение для торговли"... Надеюсь найти "единомышленников" в плане анализа типичных торговых процессов малого предприятия.

iscrafmВагон и маленькая тележка, как говорится.
Покажите пожалуйста "маленькую тележку", указанной мной конструкции?

iscrafmне знаю, что такое "отчет типа Фолио"
Ответил выше указав, что идеологию аналитики "спёр" из системы "Фолио!.

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

Придётся указать оценку одинэсников (в "холдинге" используется на части подразделений ц-1, а на части УС)... "более того создание оной уже оценили одинэсники в одной из фирм... Ответ босса им - не надо!" --- 2 месяца и 34000 руб.

Уважаемые господа iscrafm, rmv_RU, FinSoft - большое вам спасибо за подробные комментарии и ценные советы, которые требуется осмыслить и наверняка использовать при развитии системы... Не в плане "поспорить", а так "мысли в слух" попробую объяснить своё видение по вашим примечаниям.

iscrafm, rmv_RU рассуждают, как разработчики инструментария для разработчиков, а не решений для "конечного" пользователя, что с одной стороны порождает некое "непонимание" разных взглядов на одну проблему, а с другой, как не пародоксально дикую "оторванность" от реального СМБ? Теперь по сообщениям:

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

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

1. Все отчеты можно разделить условно на два вида - остатки на дату и оборотка. Из их комбинации можно получить "динамические" остатки. Все три варианта достаточно просты в реализации и в том и ином виде реализованы в любой из систем.
Конечно среди "отчетов" должны быть и есть различные взгляды на "остатки" и "оборотки" по различным бизнес-объектам, но кроме этого имеются аналитики:
1. "Дебиторки"/"Кредиторки" на дату и в срезе периодов
2. Различного рода реестры: накладных, операций и т.п.
3. Прогнозирующий анализ всего и вся.
4. Дистрибьютерская и регламентная отчетность и очень многое другое.

Даже казалось бы самое простое "остатки на дату" (в УС Land есть отчёт с данным названием) является очень многогранной темой - к этому сообщению приложу скрин параметров настройки данного отчета.

2. Поставщики и страны происхождения и прочая лабуда с точки зрения разработчика является не более чем аналитикой и может меняться от проекта к проекту наличие и отстутствие по большому не является ни конкурентным преимуществом ни недостатком. Конкурентным преимуществом является удобство добавления аналитики в цепочку бизнес-процессов.
Данная точка зрение имеет право "быть" и множество обсуждений здесь было на темы "готовое решение vs платформа" . Здесь Вы высказываете мнение с позиций разработчика/пользователя "платформы" - у меня иной взгляд. Если модератор захочет можно снова пообсуждать данный холивар без привязки к конкретным ERP/учётным системам, а обсуждаемая система теоретически относится к классу программ, когда владелец мелкого бизнеса получает "всё и сразу", а не обещания элементарно и быстро сделать это в течении ХХХ часов.

3. Я предпочитаю строить отчеты из кирпичиков. Кирпичик - процедура, возвращающая срез данных (оборотка или остаток на дату) только по одному бизнес объекту (оборотка по товару, дебиторка на дату, оборотка по кредиторам и тп) в необходимыми уровнями группировки (задаются на входе процедуры) и фильтрами (задаются на входе процедуры), тут есть проблемы, связанные к примеру с тем что некоторые показатели не обладают свойством аддитивности, но они вполне решаемы . Сам по себе кирпичик является вполне самостоятельным отчетом.
Это для меня самая ценная идея, которая бы позволила упростить аналитический контур пакета и дать возможность пользователям подстраивать её под "эксклюзивные" нужды. Хотя сделал парочку отчетов с такой возможностью, но ими не пользуются, т.к. бизнесу нужно зарабатывать, а программисту обслуживать их требования. Кроме этого, если идти "на поводу" у всех, то отчетная система УС Land содержала около десятка тысяч, а не всего 300 отчетов.

4. Сложные отчеты, включающие несколько бизнес-объектов и элементы анализа (эластичность спроса к примеру) можно строить, выбирая необходимые кирпичики. Как показала практика, кирпичков на порядок меньше, чем отчетов, построенных на их основе.
Согласен! Но уже заметил, что я программист/разработчик для бизнеса, а не для других программистов.

PS. Прднимитесь немного с уровня "нашел новую аналитику и ощастливил клиента" и будет вам щастье.
Счастье возможно, а деньги?


Теперь по обещанным "остаткам на дату" . Большинство ограничителей будет понятно "разработчикам для бизнеса", замечу только, что "группа" - произвольный набор "товарных объектов", определяемый по множеству критериев (подробнее см. e-book по отчетам ). Форматы:
1. Босс - в любых ценах, наценки, группирования по разделам и поставщикам в любых комбинациях
2. Бух - суммы, цена, налоги и прочее
3. Кл - только в нужных ценах продажи, штуки и упаковки
4. Рев - одноименные товары склеиваются и основные атрибуты товаров5. Роз - товары, анализ и атрибуты сертификатов
6. Кол-во - виды количественных характеристик товаров (вес, объем, литраж, упаковки и т.д.)
7. Суммы - количества, средние цены по любым товарных объектам (отражу уточнения)
8. Динамика - анализ остатков, в зависимости от "продаваемости" товаров (отражу уточнения)
9. Уп - количественно-суммовые показатели для оптовок
10. Ал - в любых "бухловых" разрезах
11. Е - в атрибутах системы ЕГАИС и расчет акцизов

FinSoftДумаю, что отчет полезный.
Добрый вечер! Сразу видно, что мы работаем с одним "контингентом" пользователей.

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

2. Если в программе можно учитывать не только отгружено, но и затребовано по строкам в накладных, то удобно добавить сюда информацию о дефиците. Это поможет выявить причину падения продаж, возможно, допущены ошибки в планировании закупок
Здесь уже подвергался "обструкции" за встроенный в систему подход "от продаж", а не от "заказов и планировния", который используется в серьёзных системах. Более того "от продаж" работает 100% пользователей и попытки внедрить системы "от заказа" были безуспешны. Хотя данный оперативный функционал в системе имеется и даже используется, а именно имеются две автоматизированные подсистемы "заказов" по которым программа может автоматически создавать отгрузку и сохранять/отображать статистику по "неудовлетворенным заявкам" в куче разрезов... но это оперативный, а не аналитический функционал. Конечно, если кому-то "взбрендит" включить его в аналитические отчеты, то это будет сделано.

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

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

P.S. К сожалению "эпопея" еще не закончилась, но в начале марта один крендель лишил меня дополнительного месячного дохода уверенно ляпнув , что задачу под которой я "подписывался" и гарантировал решение в течении 3 недель он, как нормальный специалист (репутация действительно у него была хорошая) сделает за пару дней. Результат: поработав "сутками" в качестве программиста и оператора в течении уже 45 дней он не решил задачу целиком (100% автомат, обещанный мной) и насколько знаю скоро будет уволен... Жалко его , а ведь его доходы превышали мои, да и репутация в городе была очень хорошей!

iscrafmFinSoftУ меня есть клиент, у которого операторы при выписке накладных или чеков бьют вначале сколько покупатель просит, а затем сколько можно реально продать (программа, конечно, автоматически предлагает вторую цифру по свободному остатку).
очень полезный параметр, для анализа спроса. Фактическая отгрузка означает только фактическую отгрузку, не более. Очень многие покупатели спрашивают товар в большем количестве, чем имеется на складах, а вынуждены покупать, то что есть. Поддерживаю. Тоже применяю.
Кто же говорит, что данная возможность бесполезная?

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

FinSoft .... Да нет, вполне реально. Берется похожая форма отчета с параметрами , рихтуется диалоговая часть . Расчет оборотки по товарам вызывается одной строкой (плюс передача через стек ограничителей, конечно), возвращает готовый результат в виде таблицы в памяти . Схлопываем эту таблицу до нужного уровня детализации. Затем перебираем все отгрузки за период (это процентов на 90 рисуется мышкой) и подтягиваем дополнительные значения к результату (количество накладных, адресов, покупателей и т.п.). Расчет коэффициентов прямо в результирующем сп иске. Плюс откомпилить и вставить в меню.
Хочу отметить, что дал оговорки - когда данная задача может быть реализована и они практически совпадают с Вашими мыслями. Только не 1-2 часа, а 1-2 дня! Графическое представление замучаетесь рисовать? Так же отметил - в система должны вестись анализируемые атрибуты, т.е. "без пруда не вытащишь и рыбку из него".

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

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

Трудозатраты (заняло времени):
20% - продумывание атрибутов, структуры, размещения информации
10% - копипастный dos кодинг
40% - рисование графической формы в генераторе отчетов и её вылизывание
25% - отладка всех веток (параметров настройки) отчета
5% - реализация новых замечаний пользователей.

Объем (строки) построителя отчета... Грубо сколько видов частей:
10% - диалоговая форма, из неё 70% контроль введённых значений (рукописная часть)
80% - чистая "математика" - выборка информации из таблиц и её преобразование.
10% - подгонка данных для отражения в формах вывода.

Таким образом "насколько можно автоматизировать разработку диалоговых окон и проектирование вообще" смогло бы съэкономить максимум 20% времени. Не верите? Попробуйте создать аналог у себя и дайте временную раскладку!

FinSoftЯ еще не упомянул кучу обвесов, которые автоматически подключатся к диалогу. Например, кэширование отчета, когда программа может определить, что отчет с теми-же параметрами сделан недавно другим пользователем и попросить его отдать готовые результаты. Или регистрацию в событийном логе с сохранением ключевых параметров для системы слежения. Или автоматическое подключение к системе сбора статистики использования диалогов. Или автоматическая регистрация в системе управления правами пользователей.
Garya когда то по поводу своих "больших" сообщений процитировал - у меня нет столько врремени, что бы писать кратко ! То, что Вы написали - это иной подход к "написанию" программ, где на фазу "проектирования" тратится 90% времени, но правда в результате получаются более "красивые" с программисткой позиции решения, которые, к слову "не впёрлись" реальным пользователем этой программы -- им нужен результат! А цена его достижения - дело десятое.

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