Отчет по дефектуре позволяет планировать закупки товара на основе анализа продаж за выбранный период и остатков товара на указанную дату. Актуален больше для розницы, поскольку используется "действительное количество дней в продаже" (когда остаток на начало дня больше нуля, или в течение дня было поступление товара). При желании, не сложно переделать под "классический" вариант, когда "количество дней в продаже" = "дата конца периода анализа" - "дата начала периода анализа" + 1, тогда отчет будет актуален и для оптовых продаж.
Файлы
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.
Выводит за период:
артикул,
номенклатура,
дата последней закупки (с переходом на документ поступления товара),
дата последней продажи (с переходом на документ продажи),
проданное количество товара за период,
действительное количество дней в продаже (когда остаток на начало дня больше нуля, или в течение дня было поступление товара),
текущий остаток (на указанную дату),
количество дней продажи, на которое хватает текущего остатка,
необходимый запас товара (на указанное в отчете количество дней),
требуемое количество закупки товара,
закупочная цена,
сумма закупки.
Например, товара А, согласно анализа продаж за выбранный период, в среднем в день продавалось 2 штуки.
Остаток товара на текущий момент: 5 штук.
Дней запаса: 7.
Требуемый товарный запас: 2 * 7 = 14 штук.
Необходимо докупить товара: 14 - 5 = 9 штук.
Поддерживается ТС ПИоТ.
Передача дополнительных тегов в чек с 01.09.2025 согласно приказа от 26.03.2025 № ЕД-7-20/236@. Поддерживаются новые ставки НДС 5%, 7% и 22% при продаже через ККТ.
Подключение фискального регистратора к 1С 7.7 в режиме онлайн-кассы в соответствии с 54-ФЗ.
Поддержка актуальных версий драйверов ККТ: ДТО 10 и ДТО 8 для Атол, 5.16-5.20 для Штрих-М / Торговый баланс М (PosCenter).
Поддержка операторов ЭДО: Сбис (Тензор), Контур.Диадок, ЭДО лайт, Калуга Астрал, Такском и пр.
Поддержка оптовой и розничной продажи маркированной продукции (алкоголь, табак, обувь, лекарства, шины, одежда, белье, парфюмерия, молочная продукция, вода, пиво, автозапчасти, моторное масло и пр.).
Поддержка онлайн и офлайн (через Локальный Модуль ЧЗ) проверки маркировки в разрешительном режиме (РР).
ПО «Информационный киоск» предназначено для организации offline доступа клиента (покупателя) к информации о товарах, услугах или дисконтных картах посредством сканирования штрих-кода. Основная цель – мгновенно предоставить наиболее актуальную информацию о цене, остатках, наименовании товара (услуги) или накоплениях, держателе, состоянии дисконтной карты.
Отчет позволяет сформировать книгу учета доходов для патентной системы налогообложения (ПСН), используя данные из проведенных документов по выбранной фирме и за выбранный период.
По умолчанию используются документы вида "Отчет ККМ" и "Реализация Розница". Можно подключить другие виды документов.
Отчет предназначен для использования с конфигурациях "1С:Торговля и Склад 7.7, редакция 9.2" (релиз 932 и выше) и "1С:Комплексная, редакция 4.5" (релиз 446 и выше).
Можно легко адаптировать под другие конфигурации, т.к. код открыт. Выкладывается как инструмент для разработки с целью реализации в собственных конфигурациях.
Отчет предоставляется в виде внешней обработки, внесения изменений в конфигурацию не требует.
Разагрегация (получение кодов маркировки, товаров, входящих в "агрегатированные" поставщиком упаковки) для табачной продукции по коду маркировки коробки - получаем коды всех блоков, входящих в эту коробку, по коду любого блока из нее получить список кодов пачек в блоке.
Позволяет запросить в виде дерева содержимое (коды маркировки) табачной продукции. Отсканировав или вставив в строку ШтрихКод упаковки, можно запросить из ЦРПТ вложенные коды
Требует наличия ЭЦП(КриптоПро или VipNet, ЕГАИС РуТокен ЭЦП 2.0 не подойдет! ) и регистрации в системе МОТП "Честного знака".
Конфигурация позволяет продавать обувь в соответствии с новыми законами, причем сохранена возможность работы как со старыми штрих кодами, так и с новыми. Т.е., сканируя DataMatrix, программа извлекает EAN13 и позволяет осуществлять подбор товаров по EAN13.
Конфигурация на базе Торговля и Склад 7.7.8.7. В архиве только свои модули, и инструкция по обновлению.
Рабочее РМК на 7.7. Можно работать с принтером чеков, можно с кассой АТОЛ, а можно и одновременно. В качестве бэк используется стандартная Розница 2.2.
Упс! При исправлении прошлой ошибки внес новую :) Исправил :)
Уважаемые, пожалуйста скачайте новую версию отчета. Предыдущая версия ВРЕТ!
Сорри :)
--
Pan Klyaxa: "и еще почемуто в поставщике вместо справочника контрагентов поподаешь в виды свойств"
Отчет-то делал для себя, поэтому отбор по "основному свойству номенклатуры" назвал "поставщик", т.к. у меня основное свойство номенклатуры - поставщик товара.
Если ДатаДок > ПоследняяЗакупка Тогда
{...1П ДЕФЕКТУРА.ERT(168)}: Операции сравнения на больше-меньше допустимы только над значениями совпадающих базовых типов (число, строка, дата)
2 ELENAB: Не все так плохо :)
2 valent:
Первая ошибка: связана с тем, что я не предусмотрел вариант, когда в партии не указан приходный документ. Видимо у вас метод расчета себестоимости "по среднему"?
Вторая ошибка: тоже моя ошибка, всегда формировал отчет при условии, что дата остатков совпадает с датой конца периода анализа, поэтому просмотрел эту ошибку. Исправлено.
Пожалуйста проверьте.
Спасибо всем, кто принял и принимает участие в тестировании моих разработок.
Жду новых комментариев!
"Дамы и Господа! Не забываем "плюсовать" рейтинг и оставлять комментарии! В противном случае - при несоответствии рейтинга количеству скачиваний - доступ к обработке будет ограничен."
А какое реальное соответствие рейтинга и количество скачиваний?
А то я вот тоже подумываю закрыть доступ к обработкам!?
2 Starik: "А какое реальное соответствие рейтинга и количество скачиваний?"
:))) Да кто ж его знает?
Просто вначале, когда я размещал первые обработки, качать - качали, а рейтингов и комментариев не оставлялли. Стало как-то грустно, закрыл доступ и повесил этот призыв - оставлять комментарии. Результат через некоторое время проявился, стали иногда оставлять комментарии и рейтинг плюсовать, открыл обратно доступ ко всем обработкам и больше не закрывал. Призыв помещаю в каждую разработку - эффект не очень большой, но все-таки есть. Всем, кто откликнулся на него, мои - огромное спасибо и признательность!
так посмотрел я отчетик прикольный понравился, неплохо былобы добавить еще и разбивку по складам.
и еще почемуто в поставщике вместо справочника контрагентов поподаешь в виды свойств.
)))
А вот с разбивкой по складам - увы. Отчет строится по регистру "Партии", а в нем нет измерения "склад". Если МОЛ реально не используется в учете, то можно вместо склада использовать МОЛ, присвоив каждому складу своего уникального МОЛ. Тогда отбор по МОЛ будет аналогичен отбору по складу.
2 valent:
про колонку "Количество дней продажи" - хорошая идея, сделаю :)
а вот про "реальное количество дней продаж в заданном периоде" - не очень понял, что под этим подразумевается?
про колонку "реальное количество дней продаж в заданном периоде" вопрос снимается здесь.
Просто интересно, можно ли получить реальное количество дней продажи, т.е. для примера: если за 30 дней анализируемого периода продажи были только 1, 5, 10 (всего 3 дня).
2 valent:
По поводу востребованности товара: мне думается, что это не очень подходящий показатель, хотя... может ты и прав, может кому-то нужен этот показатель. Подумаю, наверное добавлю.
По поводу регистра "Продажи" - в принципе, можно, но есть ряд моментов:
1. там только обороты, определить дейстительное количество дней, которое товар был в продаже, не получится - нет остатков, хотя можно брать из запроса по регистру остатков;
2. нет информации о дате закупки;
3. нет отбора по МОЛ.
Блин, старею :)
Окончательно исправил ошибку, которую внес при "исправлении прошлой ошибки".
Уважаемые, пожалуйста скачайте новую версию отчета.
Сорри :)
А все можно было бы построить на одном запросе к регистрам ОстаткиТМЦ. Будет быстрее.
"//{{ЗАПРОС(Сформировать)
|Период с ВыбНачПериода по ВыбКонПериода;
|Обрабатывать НеПомеченныеНаУдаление;
|Без итогов;
|Номенклатура = Регистр.ОстаткиТМЦ.Номенклатура;
|Количество = Регистр.ОстаткиТМЦ.Количество;
|Внутреннее = Регистр.ОстаткиТМЦ.Внутреннее;
|Функция КоличествоНачОст = НачОст(Количество);
|Функция КоличествоРасход = Расход(Количество);
|Функция КоличествоКонОст = КонОст(Количество);
|Группировка Номенклатура без упорядочивания без групп;
|Группировка День;
|Условие(Внутреннее<>1);
Вы, извините, глупость сморозили ;) Сами-то подумайте, отчет еще раз посмотрите, попробуйте, используя свой запрос, получить такой же отчет. Думаю, быстро сами все поймете :)
to: wolfsoft
Глупость - не глупость, но я надеялся, не надо будет разжевывать мою мысль. :)
И на моей работе мой отчет используется (и выполняется в разы быстрее твоего) :)
До твоего отчета мне надо добавить пару мелочей, но суть-то таже самая:
Среднесуточные продажи = продажи/кол-во дней наличия.
У тебя
Если (ОстатокКолво > 0) или (Запрос.КоличествоПриход > 0) Тогда
ДнейВПродаже = ДнейВПродаже + 1;
КонецЕсли;
У меня ДнейВПродаже вычисляется методами ТаблицыЗначений:
ТЗ.НоваяКолонка("КолвоДней");
ТЗ.Заполнить(1,,,"КолвоДней");
ТЗ.Свернуть("Номенклатура","КоличествоРасход,КолвоДней,КоличествоКонОст");
2 lordmb: Спасибо, за ап :)
По твоей мысли, которую ты не хочешь разжевывать, мои вопросы, которые мне бы тоже не хотелось разжевывать, так как они очевидны:
1. Как твоим ОДНИМ запросом получить отчет, когда, например, анализируем продажи за сентябрь-октябрь 2006 года, а остатки берем текущие на 24-11-2006?
2. Как твой запрос учитывает возвраты?
3. Как твоим запросом получить выручку?
4. Как твоим запросом получить дату и документ последней закупки и последней продажи?
И т.д. и т.п.
Если это называется - "пара мелочей" - то не вижу смысла продолжать обсуждение.
2 lordmb: И еще добавлю, я не хотел Вас оскорбить или обидеть, и я не думаю о Вас плохо :) Нормальный процесс обсуждения :) В принципе, можно подумать про свертку (Ваш предыдущий пост), но в моем случае это скорее всего не ускорит работу, потому что обход группировки все равно делать надо... А основные "тормоза" в отчете появились именно после добавления тех мелочей, которые я перечислил ниже, до этого он работал намного быстрее.
Обработка просто СУПЕР ! То что нужно, большинству работников занимающихся заявками для поставщиков , я лишь добавила вывод цены товаров не учавствовший в продажах, и все идеально !
Огромное спасибо !!!!!
Я пошел другим путём.Проанализировав по каждой розничной точке сколько чего продается за неделю, поставил минимальный остаток товара на каждую номенклатурную позицию. И заявку делаю согласно минимального остатка по конкретной розничной точке. А если на сезонную закупку (зимние тех. жидкости для автомобилей, например) уже рассчитываю из предыдущей сезонной продажи. Хотя торговля - такой процесс, что предсказать бывает сложно: 2 года назад закупил стеклооомыватель, что и к лету остался, а в прошлую зиму еще и дозаказывали такое же количество 2 раза.
