Один из вариантов восстановления последовательности партионного учета - избранное перепроведение документов
olsensМногие помнят о проблеме медленного проведения и перепроведения документов в связке 1С 7.7 - MS SQL.
С этой же проблемой и я столкнулся когда-то, после того, как перевел торговую базу своего предприятия с DBF на SQL.
Тогда же и была реализована эта технология. Хотя сама идея появилась у меня несколько раньше.
Дано: партионный учет товаров, FIFO, списание себестоимости в момент перепроведения документа. До 2500 документов с движениями по регистрам товарного и денежного учета в день, что составляло около 60000 в месяц. В среднем, 22 строки на документ Реализации ТМЦ. Частые корректировки в товарных документах текущего месяца "задним" числом. Продажи в разрезе ТП. Контроль директором себестоимости/наценки on-line. Среднее время проведения документов Реализация ТМЦ (как самых "тяжелых") 2-2,5 секунды.
Надо: быстро, желательно в пределах 4-5 часов восстанавливать всю последовательность перед закрытием месяца. Причем жизнь показала, что процесс может повториться 2-3 раза. При этом - не внося никаких изменений в структуру и кодинг конфигурации.
Посмотрим на движения по регистру "Партии Наличие" документа Реализация ТМЦ:
Мы знаем, что при списании Партий ТМЦ списывается остаток с той партии, что пришла первой. Если количество списываемого товара более количества на остатке данной партии, происходит списание с последующих партий.
Посмотрим в "Ведомость по партиям ТМЦ":
Есть пересписание по партии. А какие условия могут привести к этому?
1. "Переползание" документов из предыдущей партии;
2. Уменьшение количества/стоимости в документе поступления/оприходования;
3. Увеличение количества в документах списания;
4. Возможно, был удален возврат товара с этой партии;
5. Возможно перемещен документ по времени журнала документов - из конца дня в начало, или более того - из одного дня в другой.
Нас уже не волнует кто, когда, что, где и зачем. Наша цель - убрать "красноту".
Если это делать "руками" что для этого надо? Правильно, перепровести последовательно документы под номерами 3845 и 3846. После этого они "соскользнут" на следующую партию. Затем обновляем отчет, и смотрим, нет ли "красноты" на следующей партии.
При этом для всех остальных документов перепроведение не сыграет никакой роли! Все товары так и останутся в пределах своих "родных" партий.
Ну а что нам мешает написать аналитический модуль, который будет проверять это соответсвие партий? Ничего.
Анализ показал, что подобные подвижки в общей массе движений составляют не более 10% от общего числа документов в месяц. А перепровести 6000 все же проще, чем 60000.
Значит, последовательно, для каждого документа из обрабатываемого периода, строим таблицу соотношения количества товаров в документе, остатков по партиям и движений по регистру партий данного документа:
Расхождения в остатках и партиях выделены цветом.
Собственно, сам факт хотя бы одного расхождения в подобной таблице - уже сигнал, что данный документ должен быть перепроведен.
Кстати, в прямом SQL-запросе возможно реализовать вариант полного анализа подобных ситуаций, что нам и удалось в результате сделать: запрос возвращал нам только строки с недостатком товара. Для данного примера, это были бы строки товаров №№ 3, 6, 8.
Нашли расхождения - перепровели. Потом следующий.
По аналогии был организован анализ оплаты.
Подобный подход позволил производить предварительный анализ со скоростью до 5 документов в секунду. А учитывая тот факт, что сам анализ уже не требовал блокировать базу переходом в монопольный режим и не мешал процессам создания и проведения текущих документов, в дальнейшем восстановление последовательности часто происходило не только по ночам, но и в рабочее время без особых помех для сотрудников.
Программа Defy
