█ 17.10.2019 15:03
Алкодекларацию сдали - можно расслабиться и передохнуть...
Картинка для описания отчета лежит давно, но как-бы времени не было на размещение её и текста, да и не знал куда это разместить - вот и решил создать новую тему: просто в "УС Land" более 300 видов отчетов - слишком много, что потихоньку удалял их из системы, а тут встала задача не решаемая раньше в системе...
Нужно было строить аналитику по произвольной пачке покупателей, да и желательно иногда по адресам, да и по выборочной группе товаров или товаров поставщика с анализом ещё рентабельности работы с покупателями. Существующий отчет об уходе только по одному покупатели или его адресу, а оставшийся дилерский отчет не давал анализа рентабельности работы с клиентом... да и был излишне заморечен в алгоритмах, что бы его допиливать... Пришлось делать новый и по просьбе пользователей разместил его вызов рядом со "справкой об уходе":
Второе требование: слишком много ограничителей у "справки", что обычные пользователи путаются и тратят много времени на построение... хотя и есть подсистема сохраняемых запросов. Покажу настройку справки:
Однако и гибкость построения не должна была потеряться
Думал, думал и придумал:
Все довольны и активно пользуются даже те, кто отмечал, что он им никогда не будет нужен. Приведу фрагмент формы вывода!
P.S. Будут вопросы - отвечу!
Картинка для описания отчета лежит давно, но как-бы времени не было на размещение её и текста, да и не знал куда это разместить - вот и решил создать новую тему: просто в "УС Land" более 300 видов отчетов - слишком много, что потихоньку удалял их из системы, а тут встала задача не решаемая раньше в системе...
Нужно было строить аналитику по произвольной пачке покупателей, да и желательно иногда по адресам, да и по выборочной группе товаров или товаров поставщика с анализом ещё рентабельности работы с покупателями. Существующий отчет об уходе только по одному покупатели или его адресу, а оставшийся дилерский отчет не давал анализа рентабельности работы с клиентом... да и был излишне заморечен в алгоритмах, что бы его допиливать... Пришлось делать новый и по просьбе пользователей разместил его вызов рядом со "справкой об уходе":
Второе требование: слишком много ограничителей у "справки", что обычные пользователи путаются и тратят много времени на построение... хотя и есть подсистема сохраняемых запросов. Покажу настройку справки:
Однако и гибкость построения не должна была потеряться
Думал, думал и придумал:
Все довольны и активно пользуются даже те, кто отмечал, что он им никогда не будет нужен. Приведу фрагмент формы вывода!
Код:
Справка об уходе товаров по накладным за период с 01.07.19 по 31.07.19 Стр. 44
----------------------------------------------------------------------------------------------------------------------------------
Наименование товара - объединяются одноименные |Количество|Товарообор|Себестоим.|СуммаДоход|Наценка|СрЦПрод|СрЦ.Зак|ПоВесу|ПоОб.
----------------------------------------------------------------------------------------------------------------------------------
Вост. сладости Кроха(лес.ягоды) 3кг (Шнайдер) 3.000 372.00 309.00 63.00 20.388 124.00 103.00 3
----------------------------------------------------------------------------------------------------------------------------------
По адр: SKU: 42 Литр: 0.000 Упак: 76 200 26480 22491 3988 17.733 132.73 112.74 172
==================================================================================================================================
Покуп. А: 1 SKU: 42 Л: 0.0 У: 18455 200 26480 22491 3988 17.733 132.73 112.74 172
......
>>> Шма**************************ский тракт р
Адр Соку*********** т.
Утро в Париже печ (творог) 2,6 кг (элит) 5.200 860.60 707.20 153.40 21.691 165.50 136.00 5
.....
>>> Я*******А. ИП
Адр Вол************гер т.
Пармезан ТМ La Paulina 7.480 4921.84 4712.40 209.44 4.444 658.00 630.00
----------------------------------------------------------------------------------------------------------------------------------
По адр: SKU: 1 Литр: 0.000 Упак: 7 7 4922 4712 209 4.444 658.00 630.00
==================================================================================================================================
Покуп. А: 1 SKU: 1 Л: 0.0 У: 18844 7 4922 4712 209 4.444 658.00 630.00
Кл: 122 А: 165 SKU: 314 Л: 0.0 У: ****4 ***52 *****051 *****033 ****** **.812 **** ****** *****
P.S. Будут вопросы - отвечу!
█ 07.01.2020 13:59
Делу [УС Land и реальные клиенты] - время? а потехе [УСЕга и виртуальный мир] час? 
Проблема!
Организационный процесс: по EDI, почте в виде XLS приходят заказы, так же для "мелочи" вводятся руками -> правятся заказы, создаются планы на производство, первичка развозящим продукцию водителям -> отсылаются по EDI подтверждения и уведомления -> операторы проводят цикл производства -> автоматически по данным преобразованным заказов создаётся бухгалтерская первичка...
Где-то удаляют товары из накладных, где-то не могут произвести, где-то появляется недовоз или пересорт... Через некоторое время (до 3 суток) водители привозят накладные с вычерками. Когда-то отправляют по EDI корректировки, а когда забывают, что очевидно по объему документооборота - увидите по уникальным номерам документов.
Ключевые крупные покупатели: АО Тандер, юр.лица Х5, ООО Лента присылают по EDI акты рассогласования, с небольшими (до 300 магазинов) сетями расхождения выявляются на этапах автоматизированных сверок... Потом опять операторы "глазками" выискивают и правят, перепечатывают бухгалтерские документы...
Задача: всё это выявлять самой программой. Проблема: заказы, накладные/счета фактуры, производственные процессы работают с разными программными товарными объектами. Однако состыковал и режим глобальной верификации вызывается из контура предзаказов:
Задаётся период для анализа заказов и допуская передвижку дат поставок интервал дат относительно дат заказов для "запаса" поиска накладных и других операций. Программа "ловит" документы по номерам, которые в теории должны быть уникальны и выводит реестр расхождений документов:
Проблема!
Организационный процесс: по EDI, почте в виде XLS приходят заказы, так же для "мелочи" вводятся руками -> правятся заказы, создаются планы на производство, первичка развозящим продукцию водителям -> отсылаются по EDI подтверждения и уведомления -> операторы проводят цикл производства -> автоматически по данным преобразованным заказов создаётся бухгалтерская первичка...
Где-то удаляют товары из накладных, где-то не могут произвести, где-то появляется недовоз или пересорт... Через некоторое время (до 3 суток) водители привозят накладные с вычерками. Когда-то отправляют по EDI корректировки, а когда забывают, что очевидно по объему документооборота - увидите по уникальным номерам документов.
Ключевые крупные покупатели: АО Тандер, юр.лица Х5, ООО Лента присылают по EDI акты рассогласования, с небольшими (до 300 магазинов) сетями расхождения выявляются на этапах автоматизированных сверок... Потом опять операторы "глазками" выискивают и правят, перепечатывают бухгалтерские документы...
Задача: всё это выявлять самой программой. Проблема: заказы, накладные/счета фактуры, производственные процессы работают с разными программными товарными объектами. Однако состыковал и режим глобальной верификации вызывается из контура предзаказов:
Задаётся период для анализа заказов и допуская передвижку дат поставок интервал дат относительно дат заказов для "запаса" поиска накладных и других операций. Программа "ловит" документы по номерам, которые в теории должны быть уникальны и выводит реестр расхождений документов:
Код:
Анализ расхождения данных предзаказов и созданных на их основе отгрузочных накладных за период заказов с 01.12.19 по 31.12.19
***** При обнаружении ошибок в первую очередь смотрите дублированные номера заказов или накладных. НОМЕР ОСНОВНОЕ!
По ТТН K8E9 №_139560 от 04.12.19 на сумму 2053.29 нет совпадения с суммой ТТН: 1945.08
По заказу №_139560 от 04.12.19 не совпадает:
01UU торт * Вишенка 800гр. шт К_Зак 1.000 ТТН 0.000 ЦенаЗак 108.2100 ТТН 0.0000
....
По ТТН KFYD №_149337 от 27.12.19 на сумму 816.13 нет совпадения с суммой ТТН: 1176.69
[Дубль №?] По заказу №_149337 от 27.12.19 не совпадает дата 27.12.19 или связка клиент+адрес. По заказу 00T200T7 по ТТН 01DS03M2
012O торт №10 сникерс 0.850кг. шт К_Зак 1.000 ТТН 3.000 ЦенаЗак 149.5300 ТТН 152.5100
...
01XC С*пирожное "Профитроли шоколад" К_Зак 1.000 ТТН 2.000 ЦенаЗак 66.4000 ТТН 64.8700
....
По заказу I11Y №_148124 от 26.12.19 на сумму 329.47 ПОЛНОСТЬЮ УДАЛЕНА накладная █ 02.04.2021 08:24
"УС Land" и реальным клиентам - время, а "УСЕга" час... а по разделу форума кажется, что наоборот… и конечно максимум времени уходит на реальные задачи, как пример:
Как-то возник "шум" - заказов на распределительные центры сетей много, диспетчера не успевают, водители скандалят, руководство "строит". Начали выяснять причины задержек отгрузок, нашли "виноватого" - программист
который должен что-то придумать для ускорения процессов?
Дальше был "цирк" - 4 часа смотрел по удаленке за работой диспетчера выявляя "узкие" места и потери времени... конечно роботы много медленнее чем реальные люди при компьютерах, но нашел несколько причин задержек, которые в теории мог бы уменьшить... обсудил с работниками и руководителем. В результате "мозгового штурма" мне было поставлено несколько слишком обобщенных задач и конечно "накидано" множество малореальных идей...
Одна из проблем. Есть заказ. Диспетчер в течении 10-15 минут просчитывал потребность в транспортном средстве, учитывая обязательность паллетных упаковок и возможностей их компоновок, а затем по предварительному анализу подбирал "свободный" транспорт имея в "голове" возможности по увеличению паллеты в высоту, грузоподъемность, возможности создания сборных паллет... для типов авто от "пирожка" до "фуры". Затем формировал задачу для кладовщиков по компоновке груза... и так по каждому "сложному" заказу, коих в день от 8 до 20.
Конечно были идеи ввести объемно весовые характеристики всех авто, маршруты их движения и по всем суточным заказам автоматически создавать схемы загрузок и развоза
Придумано, как всегда простое всех, устраивающее решение… нажатием одной кнопки в режиме формирования паллетных этикеток:
Программа по уже ведущихся атрибутов продукции давала предварительную справку о необходимых параметрах автомобиля, которые диспетчера знают, как дважды два и потенциальных возможностях компоновки груза на паллетах и всех возможных альтернативных вариантов:
Возможно это выглядит примитивно, но это сэкономило по 10 минут на каждом заказе и такая идея никому не приходила в голову более десятка лет, а я не работаю непосредственно на производстве, т.е. и не было возможности выявить проблемы.... Все довольны!
Как-то возник "шум" - заказов на распределительные центры сетей много, диспетчера не успевают, водители скандалят, руководство "строит". Начали выяснять причины задержек отгрузок, нашли "виноватого" - программист
который должен что-то придумать для ускорения процессов?Дальше был "цирк" - 4 часа смотрел по удаленке за работой диспетчера выявляя "узкие" места и потери времени... конечно роботы много медленнее чем реальные люди при компьютерах, но нашел несколько причин задержек, которые в теории мог бы уменьшить... обсудил с работниками и руководителем. В результате "мозгового штурма" мне было поставлено несколько слишком обобщенных задач и конечно "накидано" множество малореальных идей...
Одна из проблем. Есть заказ. Диспетчер в течении 10-15 минут просчитывал потребность в транспортном средстве, учитывая обязательность паллетных упаковок и возможностей их компоновок, а затем по предварительному анализу подбирал "свободный" транспорт имея в "голове" возможности по увеличению паллеты в высоту, грузоподъемность, возможности создания сборных паллет... для типов авто от "пирожка" до "фуры". Затем формировал задачу для кладовщиков по компоновке груза... и так по каждому "сложному" заказу, коих в день от 8 до 20.
Конечно были идеи ввести объемно весовые характеристики всех авто, маршруты их движения и по всем суточным заказам автоматически создавать схемы загрузок и развоза
Придумано, как всегда простое всех, устраивающее решение… нажатием одной кнопки в режиме формирования паллетных этикеток:
Программа по уже ведущихся атрибутов продукции давала предварительную справку о необходимых параметрах автомобиля, которые диспетчера знают, как дважды два и потенциальных возможностях компоновки груза на паллетах и всех возможных альтернативных вариантов:
Код:
{M5A1} ООО ГК "Приус" Заказ N_37521 от 01.04.21/12:09:11 02.04/08:42
Покупатель {01FJ} ***************** Доставка 01.04.21 время 08:00-20:00 Оплата б/н Сч/ф ДА
----T-------------------------------------------------------T--------T---------T-----------T----------T---------T---------T------¬
¦Н/п¦ Наименование ассортимента и его код ¦ЦелыхПал¦+Упаковок¦Или +Единиц¦ВсегоУпак.¦КорНаПал.¦ЕдинНаПал¦Фасов.¦
+---+-------------------------------------------------------+--------+---------+-----------+----------+---------+---------+------+
1 CR Торт *** новение 027O 1 77.000 77.0 154.0 2
2 СR*пирожное "***** со сливками" 01YG 2 36.0 108.000 292.000 128.0 384.0 3
3 СR-Торт "Сн*****" шт 01FI 4 308.000 77.0 154.0 2
L---+-------------------------------------------------------+--------+---------+-----------+----------+---------+---------+-------
ВесЗаказа 953.400 ОбЗак. 3.07555 7 36 108 Сумма 156.739,08 █ 12.03.2022 09:56
Казалось все уже «привыкли» к нюансу, что в данных многочисленных отчетах операции располагаются в «физическом» порядке и «нормально», когда «расходная» операция находится выше «приходной». Тогда в факультативном пересчете остатков после операции возможны «минуса» в данной колонке, но на конец даты они всё равно логичны и положительны. Однако при демонстрации отчетов «посторонним» лицам это вызывает у них ненужные вопросы, что выявилось в недавнее время во время аудита и налоговых проверок... Эти же проверки сподвигли и на создание нового отчета:
Отчёты/группы/Справка о движение группы ассортиментов. Создан новый отчет идеологически очень похожий на справку о движении группы товаров. Зачем, если есть движение по группе товаров?
- По товарам слишком сложный и обширный отчет, например форматы экспорта и вы-грузки в электронную таблицу имеют более 50 колонок;
- Для корректности все анализируемые товары нужно извлекать из архива. Здесь они бе-рутся автоматически:
- Как правило легче иметь дело с одной строкой справочника, а не с сотнями;
- Отчет по ассортимента допускает небольшие «подтасовки» информации для проверяю-щих от фискальных органов.
Набор ограничителей отчета такой же, как при движении группы товаров, но число ограничителей в 2 раза меньше, а по умолчанию задаются параметры, обычно используемые пользователями при получении информации о движении товаров и выброшены «экзотические» параметры настройки отчета. Конечно для более гибкой аналитики, остался отчет о движении группы товаров.
Отчёты/группы/Справка о движение группы ассортиментов. Создан новый отчет идеологически очень похожий на справку о движении группы товаров. Зачем, если есть движение по группе товаров?
- По товарам слишком сложный и обширный отчет, например форматы экспорта и вы-грузки в электронную таблицу имеют более 50 колонок;
- Для корректности все анализируемые товары нужно извлекать из архива. Здесь они бе-рутся автоматически:
- Как правило легче иметь дело с одной строкой справочника, а не с сотнями;
- Отчет по ассортимента допускает небольшие «подтасовки» информации для проверяю-щих от фискальных органов.
Набор ограничителей отчета такой же, как при движении группы товаров, но число ограничителей в 2 раза меньше, а по умолчанию задаются параметры, обычно используемые пользователями при получении информации о движении товаров и выброшены «экзотические» параметры настройки отчета. Конечно для более гибкой аналитики, остался отчет о движении группы товаров.
Код:
Справка о движении группы ассортиментов по все склады за период с 01.03.22 по 12.03.22 Нач.остаток 609.000 Стр. 21
----------------------------------------------------------------------------------------------------------------------------------
ДатаО|Номер|КодД|Опер.|Ф| От кого пришел товар,кому передан |Сумма опер.|Цена товар| Количество | Остаток
----------------------------------------------------------------------------------------------------------------------------------
01.03 BTGC ПрихП - СОБСТВЕННОЕ ПРОИЗВОДСТВО 6941.40 30.18 230.000000 839.000000
01.03 BTJH ПрихП - СОБСТВЕННОЕ ПРОИЗВОДСТВО 5703.88 62.68 91.000000 930.000000
01.03 BTJK ПрихП - СОБСТВЕННОЕ ПРОИЗВОДСТВО 2634.12 32.52 81.000000 1011.000000
01.03 BTJT ПрихП - СОБСТВЕННОЕ ПРОИЗВОДСТВО 311.25 62.25 5.000000 1016.000000
01.03 15159 QR05 Отгр. Б Агроторг ООО 191.34 63.78 3.000000 1013.000000
...
01.03 15537 QR6G Отгр. Б Центр реструктуризации ООО 200.34 66.78 3.000000 534.000000
...
09.03 17326 QSEJ Отгр. Б АО "Тандер" ММ 83.82 83.82 1.000000 141.000000 █ 01.07.2022 13:46
Ну такова специфика и идеология программы, что стараюсь не добавлять новых "пунктов меню" (отчетов), а новые задачи подключать к старым механизмам, если они идеологически подходят, т.ч. это новый отчет - альтернативная ветка существующего. Задача отчета: показать кто и сколько должен или оплатил в реальном и/или будущем периоде, если выбить из него долги и оплатит вовремя
Результат с расшифровкой показателей - это техника вводимая с 2019 года:
Результат с расшифровкой показателей - это техника вводимая с 2019 года:
Код:
Расширенный формат. Ожидаемая оплата с 02.07.22 по 12.07.22 Стр. 1
----------------------------------------------------------------------------------------------------------------------------------
Наименование и системный код покупателя |Опл.без отср|Кон.дата|Ждём реализ.|ПослОпл.|Просроч.долг|НачД.Отг|КонД.Отг
----------------------------------------------------------------------------------------------------------------------------------
*В*********т 2018 026S 2000.00 22000.00 15.06.22
...
Це***********************О 00T2 153879.82 28.06.22
Частное лицо 002Q 160.00 14.06.22
----------------------------------------------------------------------------------------------------------------------------------
Наличная 0,00 ТТН без отсрочки. Оплачено в анализируемом периоде
Реализаторы 14.884.801,91 ТТН с отсрочкой. Ожидаем оплату в периоде
Должники 7.388.645,08 Не оплачено, в том числе в период отсрочки █ 04.03.2023 11:09
В принципе данный отчет относится к теме: https://olegon.ru/showthread.php?t=37806, но всё же является отдельной аналитикой. В отличии от большинства отчетов программы он решает "единственную" задачу: в крупных ТС работают очень грамотные аналитики, закупщики, разработчики и т.к. и вся эта грамотная компания стремиться по максимуму развести и обмануть малый бизнес. Возвраты и бонусы для сетей запрещены законом, ну и что? - Заставим производителей проводить акции, например с условием: суммовая скидка по акции должна равняться Х процентам от общей отгрузки... те же бонусы, но вид сбоку. При этом пользуясь малограмотностью "малышей" в тихую X% превращается в Х*ХЗ%, но владельцы малого бизнеса обладают "чуйкой" - вот и решили перепроверять ТС своей аналитикой... и действительно нехило "разводят". Отчет вызывается:
Определяем простой набор ограничителей:
Где задаётся период, группа контрагентов, признак акции, набор товаров в отчете и .... Отчет создавался для меня очень долго, т.к. алгоритмы ТС не могли мне дать в виде ТЗ, а посему неоднократно переделывались формы, наборы цифр, все они сверялись с мнением ТС, но всё же осталось не выясеным, но мне уже данный отчет надоел... Относительно чего считать долю убытков по акции: относительно продаж вне акции - отгрузили на некую сумму, а затем Х% от этой суммы отдаём скидкой по акции... или же суммовую скидку считать относительно как бы общей продажи в "нормальных" ценах? Отчет имеет два варианта расчета конечной колонки. Покажу оба варианта - один выгружается в XLS, а другой представлен в печатной форме, а так, как "никто ничего" не вспомнит через неделю, то в конце отчетов даются расшифровки алгоритмов:
Определяем простой набор ограничителей:
Где задаётся период, группа контрагентов, признак акции, набор товаров в отчете и .... Отчет создавался для меня очень долго, т.к. алгоритмы ТС не могли мне дать в виде ТЗ, а посему неоднократно переделывались формы, наборы цифр, все они сверялись с мнением ТС, но всё же осталось не выясеным, но мне уже данный отчет надоел... Относительно чего считать долю убытков по акции: относительно продаж вне акции - отгрузили на некую сумму, а затем Х% от этой суммы отдаём скидкой по акции... или же суммовую скидку считать относительно как бы общей продажи в "нормальных" ценах? Отчет имеет два варианта расчета конечной колонки. Покажу оба варианта - один выгружается в XLS, а другой представлен в печатной форме, а так, как "никто ничего" не вспомнит через неделю, то в конце отчетов даются расшифровки алгоритмов:
Код:
Анализ влияния на ФХД продаж товаров по акциям за период с 01.02.23 по 28.02.23 Стр. 1
----------------------------------------------------------------------------------------------------------------------------------
Наименование ассортимента |КВнеАкц|СуммВнеАкц|СрЦенаПр|К.ПоАкц|СуммаПоАкц|СрЦенаПр|%СкПоАк|УбыткиПоАк|УбКВирт
-----------------------------------------------|-------|----------|--------|-------|----------|--------|-------|----------|-------
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10
----------------------------------------------------------------------------------------------------------------------------------
............................ | 39364| 3750602| 95.28| 3572| 289296| 80.99| 15.00%| 51044| 1.25%
----------------------------------------------------------------------------------------------------------------------------------
........................... | 21476| 3377316| 157.26| 1088| 145433| 133.67| 15.00%| 25666| 0.72%
----------------------------------------------------------------------------------------------------------------------------------
........................... | 46292| 7832606| 169.20| 6126| 881041| 143.82| 15.00%| 155478| 1.75%
----------------------------------------------------------------------------------------------------------------------------------
Итого по всем накладным 107132 14960524 139.65 10786 1315771 121.99 12.64% 190448 1.16%
Расшифровка колонок - алгоритмы расчета: 2. Продано единиц не по акциям, 3. На сумму, 4.=3./2., 5. Единиц по акции, 6. На сумму,
7.=6/5., 8 (Скидка акции. Влияют итоги сумм).=(1-(7/4))*100, 9(Потери по акции).=(4-7)*5, 10.(Потери к виртуй сумме). =9/((2+5)*4) 
█ 29.03.2024 10:37
Анализ ФХД/Аналитика зависания товаров, продукции, сырья.
В отчете акцентируется внимание на аспекты бизнеса, раннее никогда не анализируемые в системе, хотя данную информацию можно было извлечь, построив несколько других отчетов и консолидировав их данные в связанной электронной таблице. Видимо задача в такой формулировке раньше не стояла.
Исходная задача – выявить товары, продукцию, сырьё (далее МРЦ), которое «зависло» или плохо продаётся, или проанализировать на каких МРЦ, в зависимости от сроков их поступления, получается прибыль предприятия. Одна из «сложностей» - это то, что в программе ведутся несколько видов бизнеса и для каждого из них понимание «зависших МРЦ» различное:
1. «Чистая» оптовая или розничная торговля. Зависнуть могут товары, которые давно поступили от поставщиков и плохо продаются. Анализ продаж – возможно, что товар имеет плохую скорость продаваемости и в настоящий момент времени прибыль получаем от товаров поступивших более года назад или наоборот от более «свежих» приходов;
2. Торговая деятельность производственного предприятия. Зависнуть может готовая продукция или полуфабрикаты, т.е. она «балластом» лежит на складе не принося прибыли и у ней может закончится срок хранения;
3. Закупочная деятельность производства. Здесь может зависнуть сырьё или полуфабрикаты по причинам, что продукция, использующая их выведена из оборота или сырьё заменили аналогами.
В данном отчете анализируются все виды бизнеса и «движения» любых МРЦ на пред-приятиях, занимающихся любой деятельностью. При вызове отчета необходимо задать ряд на-строек для его корректного построение:
Определяем вид анализируемого бизнеса, задавая вид операции расхода МРЦ:
1. Продажа товаров. Поступления – это приход товаров от поставщиков;
2. Продажа продукции. Поступления – приход продукции из производства;
3. Расход сырья в производство. Поступление – приход сырья от поставщиков.
Расход по типу, заданному выше анализируем за период «с … по», относя его в периоды поступления МРЦ, т.е. общий расход за период – это сумма расходов трех периодов;
Вид поступления зависит от расхода – см. выше и поступления разбиваются на 3 периода:
1. От даты самой первой операции прихода в БД до задаваемой начальной (первой) даты;
2. От первой даты включительно по вторую дату;
3. Все поступления после второй даты.
Замечание. Данное разделение МРЦ по периодам поступления возможно, т.к. учет ведётся по партиям, т.е. каждое новое поступление имеет уникальный код товара, а иначе про-грамма определяет дату поступления по «первому» поступлению товаров с данным кодом.
Обязательно определяем группу разделов учета, а иначе программа не сможет отделять това-ры от продукции или от сырья и в отчет попадет весь справочник товаров.
Замечание. Понятно, что для видов «расхода» берем разные группы товаров. Для:
1. Разделы товаров для перепродажи:
2. Группу разделов «готовой продукции»;
3. Группу разделов сырья и полуфабрикатов.
Определяем тип цены расхода. Нужна для расчета дохода. Если анализ продажи, то в не зависимости от варианта выбора программа анализирует реальную цену реализации;
Определяем цену поступления (закупа), включая вариант с учетом затрат на производство.
Далее программа строит отчет, который так же можно вывести в электронную таблицу, а в печатной по каждому склеенному наименованию, включающего множество партий поступлений МРЦ отчет для одной номенклатуры имеет вид:
Где: Т-товарооборот в ценах отчета, С-себестоимость в ценах отчета, Д-доход, Н-процент на-ценки, К-количество в единицах измерениях. В приведенном варианте анализируется расход в производство, т.е. цена закупа и расход совпадает. Замечание. Поступление и расход рассчитывается, как расходуемое (поступаемое) количество за минусом возвращаемых.
В отчете акцентируется внимание на аспекты бизнеса, раннее никогда не анализируемые в системе, хотя данную информацию можно было извлечь, построив несколько других отчетов и консолидировав их данные в связанной электронной таблице. Видимо задача в такой формулировке раньше не стояла.
Исходная задача – выявить товары, продукцию, сырьё (далее МРЦ), которое «зависло» или плохо продаётся, или проанализировать на каких МРЦ, в зависимости от сроков их поступления, получается прибыль предприятия. Одна из «сложностей» - это то, что в программе ведутся несколько видов бизнеса и для каждого из них понимание «зависших МРЦ» различное:
1. «Чистая» оптовая или розничная торговля. Зависнуть могут товары, которые давно поступили от поставщиков и плохо продаются. Анализ продаж – возможно, что товар имеет плохую скорость продаваемости и в настоящий момент времени прибыль получаем от товаров поступивших более года назад или наоборот от более «свежих» приходов;
2. Торговая деятельность производственного предприятия. Зависнуть может готовая продукция или полуфабрикаты, т.е. она «балластом» лежит на складе не принося прибыли и у ней может закончится срок хранения;
3. Закупочная деятельность производства. Здесь может зависнуть сырьё или полуфабрикаты по причинам, что продукция, использующая их выведена из оборота или сырьё заменили аналогами.
В данном отчете анализируются все виды бизнеса и «движения» любых МРЦ на пред-приятиях, занимающихся любой деятельностью. При вызове отчета необходимо задать ряд на-строек для его корректного построение:
Определяем вид анализируемого бизнеса, задавая вид операции расхода МРЦ:
1. Продажа товаров. Поступления – это приход товаров от поставщиков;
2. Продажа продукции. Поступления – приход продукции из производства;
3. Расход сырья в производство. Поступление – приход сырья от поставщиков.
Расход по типу, заданному выше анализируем за период «с … по», относя его в периоды поступления МРЦ, т.е. общий расход за период – это сумма расходов трех периодов;
Вид поступления зависит от расхода – см. выше и поступления разбиваются на 3 периода:
1. От даты самой первой операции прихода в БД до задаваемой начальной (первой) даты;
2. От первой даты включительно по вторую дату;
3. Все поступления после второй даты.
Замечание. Данное разделение МРЦ по периодам поступления возможно, т.к. учет ведётся по партиям, т.е. каждое новое поступление имеет уникальный код товара, а иначе про-грамма определяет дату поступления по «первому» поступлению товаров с данным кодом.
Обязательно определяем группу разделов учета, а иначе программа не сможет отделять това-ры от продукции или от сырья и в отчет попадет весь справочник товаров.
Замечание. Понятно, что для видов «расхода» берем разные группы товаров. Для:
1. Разделы товаров для перепродажи:
2. Группу разделов «готовой продукции»;
3. Группу разделов сырья и полуфабрикатов.
Определяем тип цены расхода. Нужна для расчета дохода. Если анализ продажи, то в не зависимости от варианта выбора программа анализирует реальную цену реализации;
Определяем цену поступления (закупа), включая вариант с учетом затрат на производство.
Далее программа строит отчет, который так же можно вывести в электронную таблицу, а в печатной по каждому склеенному наименованию, включающего множество партий поступлений МРЦ отчет для одной номенклатуры имеет вид:
Код:
Аналитика зависания МРЦ по продажам за период с 25.01.24 по 29.02.24 Стр. 18
--------------------------------------------------------------------------------
Наименование товара из гр.с приходами в периодах |-20.01.24|По 20.02 |20.02.24-
--------------------------------------------------------------------------------
Сахар Т 324073 4337246 671272
С 324073 4337246 671272
Д
Н
К 5312.7 70200.8 10552.3 Часовой пояс GMT +3, время: 09:17.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.