Отчет по дефектуре позволяет планировать закупки товара на основе анализа продаж за выбранный период и остатков товара на указанную дату. Актуален больше для розницы, поскольку используется "действительное количество дней в продаже" (когда остаток на начало дня больше нуля, или в течение дня было поступление товара). При желании, не сложно переделать под "классический" вариант, когда "количество дней в продаже" = "дата конца периода анализа" - "дата начала периода анализа" + 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 раза.
