Остатки товаров на складах по партиям по методу ФИФО, если партий нет (РАУЗ). СКД

В системах КА и УПП прогресс идет в сторону отказа от партионного учета и перехода на РАУЗ. При этом партий в чистом виде нету.
Данный отчет динамически восстанавливает партионный учет и показывает какие партии товара остаются на складах.

Арт.: 150818

Настройки отчета
Внешний вид
Настройки отчета
Внешний вид

4800 руб.

Если партионного учета нет, но очень хочется, то можно Laughing. Развитие систем 1с сейчас идет по пути отказа от партионного учета, но среди клиентов иногда встречаются ярые его сторонники. Таким бывает лучше сделать, чем объяснить, что это невозможно. Так появился данный отчет. Он показывает документы поступлений товаров, вычисленные с учетом всех перемещений товара между складами по методу ФИФО.

 

Отчет построен на регистрах ТоварыНаСкладах и ТоварыВРознице. От ТоваровОрганизаций пришлось отказаться по причине РЛС по организациям и доработок в проекте. Характиристики и серии номенклатуры не учитываются. Отчет основан на шаблоне типового отчета, входящего в состав КА и УПП. Основная СКД  формируется из таблицыЗначений, вычисляемой внутри отчета.

 

Алгоритм формирования отчета:

1. Берем специальную СКД для вычисления положительных остатков товаров на складах и скопировав туда отбор из настройки отчета получаем таблицу значений с остатками товара. На этом этапе отбрасываются минуса, поэтому отчет не сойдется со стандартными отчетами по остаткам на количество отрицательных остатков.

2. Вычисляется из каких приходных (увеличивающих количество) документов состоит данный остаток. Вычисляется одним запросом. Документы определяются по методу ФИФО. Методика распределения остатка на приходные документы есть на инфостарте. К исходной таблице добавляются колонки Документ и СкладОтправитель. Последняя заполняется в случае, если документ - перемещение товаров. Строк тоже, естественно, прибавляется.

3. Тут начинается ноу-хау

В цикле ограниченном 10 или полностью пустой колонкой СкладОтправитель надо вычислить из каких партий образовались остающиеся в таблице перемещения. Вычисляется это все одним запросом примерно так:

  • Отобрать по каким складам и номенклатурам требуется уточнение (перемещения одной номенклатуры могут придти с разных складов)
  • Построить ФИФО цепочку движений по документам данным складамОтправителям\номенклатурам с вычислением остатка на начало и окончания каждого документа
  • Соединив таблицы вычислить в основной таблице остаток на моменты перемещений на складе отправителе
  • Построив ФИФО для каждого перемещения вычислить из каких документов эти перемещения взяли свое количество
  • Уничтожить временные таблицы и соединить результат вычислений с данными, поданными на вход пп3 по которым вычислений не требуется. Полученную таблицу обозвать так же как и поданная на вход. В этом случае на любой итерации получаем унифицированные данные и запрос\код не изменяется.

4. Как и говорилось выход по достижении максимального числа итераций=10 или если вычислять уже нечего - перемещений нет.

5. К получившейся таблице цепляем цену из табличной части документа поступлениеТоваровУслуг дабы вычислить сумму. Ориентировочно. Прихоть клиента.

6. Результат подаем на вход основной компоновке данных и отчет формируется дальше уже сам.

 

Замечания:

В пп3 при получении цепочек надо учитывать, что остаток склада на дату отчета может быть не нулевым.

Для построения фифо используются таблицы с нарастающими итогами. Подобные вычисления обычно вгоняют сервера в штопор, но не в данном случае. Вычисления оптимизированы по периодам. Сначала вычисляется по месяцам, а затем уже по документам внутри месяца. Т.е. соединения каждый с каждым есть только внутри месяца.

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

 

 Демо версия с закрытым кодом и  ограничением на количество номенклатуры не более 3. Остальное отбрасывается на первом этапе.

Статистика:
Просмотры 24283
Загрузки 1
Рейтинг 3
Создание 07.09.12 14:45
Обновление 19.01.15 21:15
№ Публикации 150818
Характеристики:
Теги
Рубрики Анализ учета Оптовая торговля Розничная торговля
Кому Бухгалтер ,
Пользователь
Тип файла Внешний отчет (ert,erf)
Платформа Платформа 1С v8.3
Конфигурация 1С:Комплексная автоматизация 1.х ,
1С:Управление производственным предприятием
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Управленческий учет
Доступ к файлу Платные (руб)
Код открыт Не указано
Наименование Файл Версия Размер
Остатки по партиям на складах ДЕМО .erf 44,84Kb 154 Скачать
1. Техподдержка 07.09.12 16:49
Такая штука была бы полезна для Бухгалтерии. особенно когда некоторые бухи ведут учет "по-средней"
2. aves 07.09.12 17:39 Сейчас в теме
(1) РН остатков там нет. Данные можно взять из РБ.
Теоретически возможно. Будет ли спрос - вопрос?
+ там вроде нет шаблона универсального отчета - придется придумывать еще и оболочку.
3. kapustinag 07.09.12 20:52 Сейчас в теме
Если клиент, заказавший и получивший этот отчет, работает в реально использующейся производственной информационной базе - с десятками складов, тысячами позиций номенклатуры, интенсивным вводом документов движения ТМЦ - то он не сможет этот отчет реально использовать. Разве что ввести в алгоритм искусственные ограничения на количество складов и/или количество позиций номенклатуры и/или на период. И иметь СУПЕРкомпьютер в качестве сервера. Кроме того, если учитывать серии и характеристики - а их придется учитывать - количество цепочек резко возрастет. На большой базе ведомость по партиям товаров на складах может формироваться довольно долго, если указан большой период и много группировок. А ведь он формируется по уже записанным в регистр "Партии товаров на складах" данным. Данный отчет будет вычислять все "на лету", и серверу будет очень тяжело.
Поэтому "плюс" за алгоритм и его реализацию, а вот насчет практического применения - сомневаюсь.
Светлый ум; +1 Ответить
4. aves 07.09.12 23:43 Сейчас в теме
(3) Серии не ведем, а в качестве характеристик используем вид упаковки, так что для нас не актуально. Кроме того в данном случае алгоритм придется усложнять на 2 момента - большую детализацию и корректировки серий и характеристик,чтобы искать исходную номенклатуру+х+с после преобразования.
Попробую снять статистику на нашей базе - отпишусь.
5. aves 08.09.12 00:15 Сейчас в теме
(3) кроме того это остатки - период тут не применим, хотя общий объем имеет влияние, т.к. нарастающе итоги строятся целиком. Да и группировок много не сделать. Номенклатура\Склад и документ + все реквизиты.
6. kauksi 11.09.17 13:03 Сейчас в теме
Нет отбора по складу и номенклатуре.

Оставьте свое сообщение

См. также

ЕГАИС++. Опт, производство, импорт

Полнофункциональное расширение (ранее известное как Модуль 1С-ЕГАИС) для взаимодействия типовых конфигураций 1С и ЕГАИС, предоставляющее максимум возможностей по работе с УТМ. Получение и отправка ТТН, отправка акта о постановке на баланс и...

8970 7176 руб.

SALE! 20%
SALE! 20%
SALE! 10%

Бонусная система в 1С для УТ 10.3

Подсистема призвана упростить и автоматизировать процесс расчета и начисления бонусов покупателей. Бонусная система работает с конфигурациями 1С:УТ 10.3, 1С:Розница. Механизм реализован в начале 2013г. и работает до сих пор с постоянными со...

30000 руб.