gifts2017

Еще один взгляд на проблему «жизнь без последовательностей». Часть вторая (практическая)

Опубликовал Сергей (ildarovich) в раздел Программирование - Теория программирования

В [1 - http://infostart.ru/public/62938/] был предложен метод корректировки списаний по партиям при изменении документов задним числом. Использование данного метода позволяет контролировать остатки при неоперативном проведении и поддерживать учет по партиям всегда в актуальном состоянии, то есть обходиться без механизма последовательности документов. Собственно метод заключался в решении задачи правильного списания по партиям как задачи линейного программирования.

В доказательство работоспособности метода приводится следующая «каркасная» конфигурация «Полигон», в которой этот метод реализован.

 

Конфигурация "Полигон" включает :

- обработку для автоматического формирования тестового массива документов поступления и реализации по заданным параметрам на основе модели теории массового обслуживания;

- окно настройки конфигурации (выбора испытываемого метода);

- обработку для автоматического изменения документов при тестировании быстродействия метода;

- справочник товаров;

- документы поступления и реализации с одной табличной частью, содержащей колонки номенклатура, количество, цена;

- основную структуру данных в виде непериодического независимого регистра сведений для хранения структуры списаний, имеющего измерения номенклатура, поступление, реализация, ресурс количество и два служебных реквизита;

- вспомогательный регистр сведений для хранения результатов тестирования времени записи измененных документов;

- отчет на СКД по количественным и суммовым остаткам партий товаров;

- отчет на СКД по количественному и суммовому движению партий товаров;

- отчет на СКД по прибыли;

- диаграмму на СКД для результатов тестирования метода;

- общие модули, начинающиеся со слова «метод», реализующие различные алгоритмы корректировки списания партий.

В виде отдельного файла прилагается отчет для конфигурации УТ, позволяющий получить параметры синтетического теста из реальной информационной базы для выбранного склада (число товаров, приходов, расходов, средний запас). Значения полученных параметров передаются в конфигурацию «Полигон» через буфер обмена Windows.

Для работы с конфигурацией рекомендуется сначала соответствующей обработкой сформировать некоторый массив документов, затем выбрать в настройках «Метод22Наглядно» и попробовать изменить одну позицию в любом документе. При записи этого документа программа покажет ход решения в виде последовательности таблиц с рассчитанными значениями целевой функции. Время обработки при этом может быть весьма существенным. Оно уходит на подготовку таблиц для комментариев решения. Далее рекомендуется выбрать в настройках «Метод2х2» и попробовать менять документы (количество товара в строках документов поступления или реализации), оценивая время отработки изменений. Рекомендуется сначала увеличивать поступление, а затем уже его уменьшать, либо уменьшать количество в реализации, а затем его увеличивать, так как в другом случае велика вероятность отказа в записи из-за контроля остатков при последующих списаниях. При отключенном комментировании результаты измерений времени работы метода будут записываться. Далее можно запустить автоматическую процедуру для изменения документов в цикле. Затем можно посмотреть диаграмму, показывающую среднее время, затраченное алгоритмом на изменение количества в одной позиции документа в зависимости от глубины изменений или длины цепочки документов по данной номенклатуре, следующих за изменяемым.

Внимание! При запуске обработки формирования массива документов регистр результатов испытаний очищается!

В двух словах об основных идеях…

Для баланса введена особая расходная накладная с номером «СТОК», которая 31.12.3999 списывает все остатки товара.

Корректировка структуры списания производится перед записью документов. Для этого:

  1. Запросом вычисляется разница (дельта) количества товара в табличной части и структуре списаний.
  2. Для каждой номенклатуры с ненулевой дельтой в таблицу значений «ТаблицаСписаний» (или в дерево значений «ДеревоСписаний») запросом выбираются все списания, произведенные позже изменяемого документа.
  3.  В таблицу (дерево) списаний вносятся изменения в зависимости от вида документа и знака дельты для соблюдения ограничений в смысле [1]. Например, при увеличении прихода, просто увеличивается списание расходом «СТОК».
  4. Таблица (дерево) списаний «оптимизируется» в смысле [1]. То есть меняется для достижения минимума целевой функции при соблюдении ограничений [1].
  5. Изменившиеся строки таблицы (дерева)  списаний (в колонке «база» хранится начальное количество) записываются в набор данных регистра, обнуленные строки удаляются.

«Оптимизация» таблицы (дерева) списаний заключается в следующем:

  1. Ищутся пары строк - списаний (П1, Р2) и (П2, Р1), для которых выполняется условие П1 раньше П2, а Р1 раньше Р2. Наличие таких пар свидетельствует о «дефекте» в структуре списания и возможности уменьшения ЦФ. При отсутствии таких пар алгоритм заканчивается, найдя оптимум.
  2. Минимальное количество из найденных «перекрещивающихся» списаний забирается и добавляется к списаниям, составленных парами (П1, Р1)  и (П2, Р2)  (два списания меняются на два, поэтому метод назван «2х2»). Это позволяет не нарушить ограничения.
  3. Повторяется шаг 1.

Поиск пар строк ведется как поиск пересекающихся отрезков-списаний. Отрезки соединяют ось времени поступлений с параллельной осью времени реализаций, причем начало каждого отрезка-списания соответствует моменту поступления, а конец – моменту реализации. Для экономии времени поиска «дефекта» отрезки группируются в узлах дерева значений по поступлениям, а внутри одного узла – сортируются по времени реализации.  Далее проверяются только пары из смежных поступлений.

Главной отличительной особенностью технической стороны предлагаемого решения является выбор независимого непериодического регистра сведений для хранения информации о списании партий в информационной базе. То есть в конфигурации для работы с остатками не используются регистры накопления. Регистр сведений СписаниеПартий имеет измерения: номенклатура, документ поступления, документ реализации; ресурс количество и два реквизита: дата поступления и дата списания. На основе информации из этого регистра по номенклатуре и документу поступления легко находятся документы реализации данной партии и решаются остальные задачи партионного учета.

Формирование тестового массива документов производится на основе представления товаропотока как совокупности случайных потоков поступлений и реализаций одной единицы товара. То есть товар поступает через случайные интервалы, затем также случайное время лежит на складе. Интенсивности потоков поступления и обслуживания определяются моделью СМО (системы массового обслуживание) из заданных параметров. Приходы разделяются случайными интервалами и объединяют товары, поступившие раньше следующего прихода. Аналогично расходы разделяются случайными интервалами и объединяют товары, поступившие позже предыдущего  расхода. Все случайные интервалы подчиняются экспоненциальному закону распределения, то есть потоки являются пуассоновскими.

В целом после проверки предлагаемого метода с помощью данной тестовой конфигурации, можно сделать вывод, что метод работоспособен. Он решает возложенные на него задачи за приемлемое время. Например, на запись измененного в одной позиции документа трехмесячной давности уходит примерно две секунды при 7 500 всех последующих документов и 500 документов по данной номенклатуре. Очевидно, именно последний параметр определяет затраты времени на корректировку.

Анализ возможностей дальнейшего ускорения предлагаемого метода показал, что ускорение возможно. При этом может потребоваться достаточно далеко отойти от идеи, 

изложенной в работе [1].  Поэтому данную публикацию следует рассматривать как пояснение идеи из работы [1] в виде программного кода и доказательство работоспособности подхода и только как промежуточный результат при поиске еще более эффективных методов.

Например, в той же конфигурации запрограммирован более очевидный метод «1х1», который на длинных цепочках документов в данный момент работает примерно в четыре раза быстрее метода «2х2». С точки зрения алгоритмов решения транспортной задачи этот метод является способом получения опорного решения методом «северо-западного угла». Найден и еще более быстрый алгоритм, о котором можно будет рассказать отдельно.

Возвращаясь к заголовку статьи "жизнь без последовательностей"...

После практического опробования одного из подходов к решению данной проблемы, можно еще раз, но более точно высказать следующую мысль: за счет некоторых дополнительных расходов при записи документов можно отказаться от механизма последовательностей платформы 1С:Предприятие. Само понятие последовательности документов остается. Оно используется при получении правильной структуры списания. Просто мы восстанавливаем последовательность списания сразу при изменении документа, не откладывая эти действия «на потом». За что и платим некоторым дополнительным временем записи документа. Совершенствуя алгоритмы корректировки списания партий, можно сделать это время достаточно малым, а в среднем - ничтожным. За это мы получаем постоянный контроль остатков при неоперативном проведении и актуальное состояние списания партий, снимаем необходимость перепроведений. 

Можно спорить: насколько это нужно? Есть документы и за и против. Они известны. Видимо, отталкиваться необходимо от требований конкретной задачи.

Кстати, интересный дополнительный аргумент для сторонников перманентного пор ядка в учете партий товаров: при таком подходе можно отказаться от механизма резервирования,  заменив его проведением накладной в будущем - контроль остатков не даст нам продать "зарезервированный" таким образом товар!

Предупреждая возможные замечания к реализации методов, необходимо добавить, что:

1.       Использование регистра сведений вместо регистра накопления для хранения информации о списании партий применено осознанно, с полным пониманием того, что при этом увеличится время получения отчетов по суммовым оборотам партий. Ставилась задача посмотреть: каким в принципе может быть минимальное время корректировки, чтобы затем утяжелять метод дополнительными механизмами типа итогов или агрегатов.

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

3.       Рассмотрение ограничено только методом «ФИФО». 

4.       Вместо момента времени всюду используется просто время документов. Учет этой детали нетруден, но усложняет понимание логики алгоритмов и отчетов.

5.       В практических задачах логику корректировки структуры списания лучше перенести в процедуру проведения документа, что упростит управление блокировками.

6.       Модель СМО, выбранная для генерации тестового набора документов, не позволяет по отдельности регулировать число товаров и среднее число строк в документах. Поэтому для экспериментов не следует брать реальное число товаров в базе – в документах будет слишком много строк.

7.       Замеры времени указаны применительно к файловому варианту платформы 8.1, установленной на ноутбуке PCG-6122V.

 

Скачать файлы

Наименование Файл Версия Размер
Информационная база "Полигон" 102
.dt 1,31Mb
19.08.10
102
.dt 1,31Mb Скачать
Конфигурация "Полигон" 26
.cf 121,74Kb
19.08.10
26
.cf 121,74Kb Скачать
Отчет по статистике товаропотока для УТ 24
.erf 8,69Kb
18.08.10
24
.erf 8,69Kb Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Сергей (ildarovich) 19.08.10 10:14
2. Александр Рытов (Арчибальд) 19.08.10 10:30
Ну вот, глюк, комменты исчезли.
Я к тому, что задача поиска пар "двумерна" (в "измерениях" МассивПриходов х МассивРасходов). А в 1х1, как я понял из описания, по этим "измерениям" мы оптимизируемся по отдельности.
В алгоритм я лезть не стал, на задачу смотрю с эстетической точки зрения старого оптимизатора :D
3. Александр Шишкин (Шёпот теней) 19.08.10 11:32
... хм ... трудно ВЫсказать что-либо по столь аргументированному труду ...

но "занимаясь" теорией можно сказать следующее:

... если нужно знать реальные остатки по складам (партия, количество, цена, себестоимость, и др), в рамках единой системы учёта, то как не вертетЬся а "временная ось" тут или там, в том или ином виде появится ... а если ОНА, временная ось, появилась то остальное только "форма" работы с ней (т.е. с последовательностями документов) ...

можно выбрать 7-ый путь ... можно 8-ный ... можно, как встречалась в обработке (тут на ИС), перепроведение только касающихся данной номенклатуры (документов или строк документа) ...

... но факт остаЁтся фактом ... перетасовка документов в учёте (хоть бумажном, хоть электронном) без наличия временной оси - НЕвозможна ... следовательно влияние "перемен" на ВСЮ цепочку зависмых документов избежать не получится ... !

... вечных двигателей не придумано ... нет учёта без "временной оси" ... вот ...

п.с. ну "форма" ... ну а "форма" она и останется только "формой" ... хоть УУ хоть БУ - а данные -то надо собирать ...

... такаяВОТбалаМУТЬвот ...
ildarovich; +1 Ответить 3
4. Сергей (ildarovich) 19.08.10 11:55
(2) Я видел Ваши комментарии. Вы совершенно верно подметили, что трудоемкость метода 2х2 зависит от числа документов по данной номенклатуре нелинейно и даже, возможно, квадратично. Это также подтверждается графиком. Правда, названия методов давались из других соображений.
Строго говоря, метод 1х1 оптимизационным не является - это просто "линейный" метод заполнения матрицы с учетом ограничений, приводящий, из-за особенностей целевой функции, к тому же решению, к тому же достаточно очевидный. По ходу работы он производит больше изменений в структуре списания, фактически, строя ее заново.
Метод 2х2, как видно из последовательности таблиц в решении, производит точечные изменения в структуре списания, но требует поиска этих точек, на который и уходит львиная доля времени.
5. Сергей (ildarovich) 19.08.10 12:06
(3) Абсолютно согласен.

Но есть проблема выбора лучших алгоритмов и структур данных для решения этой задачи (прежде всего, с точки зрения минимизации затрат времени), которую я и пытаюсь решить.
Шёпот теней; +1 Ответить
6. Александр Шишкин (Шёпот теней) 19.08.10 12:33
(5) ... поэтому и указал "... перепроведение только касающихся данной номенклатуры (документов или строк документа ..." ...

... особенно важен поиск таких документов или строк (что то же вызывает отдельную проблему) ... или идти путём 1С (общим чохом) ...

... всё таки "проще" наладить дисциплину работы с документами - чем возиться с "ЗЧ" (задним числом) ... особенно если учесть глобальность 1С и её попытки позиционироваться для крупных и очень крупных предприятий (разветвлённые, разделённые базы) ...

... вот ...

... мне кажется вопрос больше касается и "упрощении" учёта и упрощения механизма перепроведения (полного, по-отдельным документам, по отдельным строкам документам) ... чем (не научных) попыток отказаться от "временной оси - последовательностей" ...

... 1С - существует ... переделывать никто не будет .... механизмы новых перепроведений в рамках штатных объектов более полезны чем поиск новых "последовательностей" ... яркий тому пример обработки ВалерычА и anig99 и других товарищей ...

... вотНЕпопад ...
7. Александр Рытов (Арчибальд) 19.08.10 13:08
(6) Лом, конечно, согнуть трудно.
Но одно дело просто осознавать, что механизм последовательностей 1С на редкость коряв, и другое - иметь элегантную альтернативу (хотя применения в широких масштабах она не найдет).
А вообще, Документ 1С надо бы приблизить к реальности. Т.е. иметь не только ДатуДокумента (дату, с которой в БД записываются движения), но и ДатуАктуализации (дату проведения). Тогда проведения задним числом вообще не будет, и появляются широкие возможности для оптимизации алгоритмов проведения.
romankoav; ildarovich; +2 Ответить 4
8. Александр Шишкин (Шёпот теней) 19.08.10 13:25
(7) ... идея конечно "интересная" !!! но с точки зрения:

"... если нужно знать реальные остатки по складам (партия, количество, цена, себестоимость, и др), в рамках единой системы учёта, то как не вертетЬся а "временная ось" тут или там, в том или ином виде появится ... а если ОНА, временная ось, появилась то остальное только "форма" работы с ней (т.е. с последовательностями документов) ... "

какое это имеет отношение ... всЁ равно будем вынуждены "лопатить" всю последовательность взаимосвязанных объектов чтобы "высчитать новую реальность" ... остатки, партия, цена, себестоимость ... .... .... ......

... вот ...

п.с. всЁ таки проще "создать" механизм проведения и перепроведния на конкретном предприятии упростив его ... и ! одновременно ужесточив дисциплину работы с документами (в этом корень основной проблемы в повседневной работе) - а здесь "мама родная ... ! ..." ...

...
9. Александр Рытов (Арчибальд) 19.08.10 13:40
(8)
механизм проведения и перепроведния на конкретном предприятии
И я об этом. Не в типовой конфигурации, а в оттюнингованной под конкретику. Добавляем в документы общий реквизит "ДатаАктуализации" и, пользуясь ей, то как дубинкой для воспитания нерадивых юзеров, то как гибким инструментом срубания бабок на пересортице, то как оптимизатором восстановления последовательности, - делаем что хотим.
Шёпот теней; +1 Ответить
10. Сергей (ildarovich) 19.08.10 20:18
(6) Я не противопоставляю доработку типовых конфигураций и создание принципиально новых. Можно заниматься и тем и другим: пропалывать грядки, распаханные и засаженные 1С и пробовать выращивать что-либо новое в чистом поле.
Обратите внимание на механизм резервирования в Управлении торговлей 11, механизм остатков в Логистике и управлении складом 3 - они появились казалось бы на пустом месте.
11. Владимир (hogik) 19.08.10 23:57
(3)
1) "если нужно знать реальные остатки по складам ...."временная ось" ... появится ..."
- Реальные остатки существуют в независимости от порядка кладки/взятия предмета с полки.
2) "то остальное только "форма" работы с ней (т.е. с последовательностями документов)"
- Не последовательностью документов, а последовательностью действий ("хоз.операций"). Например, для прихода 100 позиций товара можно оформить 1 документ или 100 документов. Суть реальных действий от этого не меняется - осуществляется приём 100 позиций товара.
3) "перетасовка документов в учёте (хоть бумажном, хоть электронном) без наличия временной оси - НЕвозможна"
- Т.е. берем пачку документов за месяц подобранную по дате. Находим документ #3 за первое число, вносим исправления (условно говоря), кладем обратно в пачку между документами #2 и #4. А потом, бедный бухгалтер, обязан пощупать все документы с #4 по последний документ пачки? Зачем? ;-)
4) "влияние "перемен" на ВСЮ цепочку зависмых документов избежать не получится"
- Т.е. например оприходовали товар по 100 рублей. Продали по 120. Обнаружили ошибку в приходе - надо было приходовать по 90 рублей, изменили. Лезем в расходную накладную и меняем цену на 110 рублей. Звоним покупателю и ... ;-) Или надо перещупать все, вроде, зависимые документы для пересчета "себестоимости"? Как пересчет "себестоимости" влияет на, уже существующие, документы отражающие факт совершения хоз.операции?
(6)
1) "... "проще" наладить дисциплину работы с документами - чем возиться с "ЗЧ" (задним числом) ... особенно если учесть глобальность 1С ... "
- Наладить дисциплину работы с документами для "пакетного" бух.учета, думаю, вполне реально. Под это и заточена "глобальность 1С" ;-). Но суть-причина "ЗЧ" двоякая.
Первая - это правила учета документов в бухгалтерии. И решается простым признаком запрета изменения документа. Например, по дате, получения твердой копии (распечатки), цифровой подписи ответственного лица и т.д.
Вторая - установка зависимостей документов в базе данных и, как следствие, сложность реализовать "ЗЧ" в алгоритмах системы. А т.к. "ЗЧ" существует всегда, для систем ориентированными не только на "б.учет", то решать вопрос эффективного изменения документов "ЗЧ" необходимо.
2) ... вопрос больше касается и "упрощении" учёта и упрощения механизма перепроведения ... чем ... попыток отказаться от "временной оси - последовательностей" ...
- Ключевое слово "учет". В системах учета нет противоречий. Заднего числа не существует, а "временные оси" и, как следствие, "последовательности" - существуют. В реальной жизни - всё наоборот. ;-)
3) "1С - существует ... переделывать никто не будет"
- Будет. Сама 1С переделает в следующих версиях... ;-) На мой взгляд они к этому идут, если сравнивать 7.7 и 8.х. Вот уже появились регистры сведений, точка актуальности, вроде, почти исчезла, документ перестаёт быть "документом", ведётся активная борьба с "запросными" СУБД-ами... ;-)
(7)
"Документ 1С надо бы приблизить к реальности. Т.е. иметь не только ДатуДокумента (дату, с которой в БД записываются движения), но и ДатуАктуализации (дату проведения)."
- Дык, они это и попытались сделать. ;-) Пока документ не проведен он имеет "любую" дату. А когда проводится получает, на их взгляд, "истинную" дату. Есть еще "промежуточные" состояние - типа, "полу-проведен". ;-) Перфокарточная, пакетная бухгалтерия... :-(
12. Александр Шишкин (Шёпот теней) 20.08.10 08:54
(10) ... а мне нравится ВАШ математический подход к проблеме ... ! ... проблема только не в "изготовлении" а в "повторении" и в "распространении" ... да и с "пониманием" будут проблемы ...

ведь казалось бы доступ к таблицам - построчный (в эСКуэЛ-е) ... а ПЕРЕпроводим все документы ... зато ОДИН механизм и УНИВЕРСАЛЬНО ...

... вот ...

(11) ... хм ... перетасовать документы можно ... если не нужно знать актуальные остатки по складу на реальную секунду ... иначе - временная ось ... и т.д. + хитрая взаимосвязь и взаимовлияние документов друг на друга ...

... на мой взгляд 7-ная ТА была самым лучшим способом ... если данных много можно свести её период к полу-месяцу - неделе ... но видимо при "больших" обЪёмах это стало не выгодно или отказ от ТА был смелым творческим эксперментом ...

... ДатаАктуализации - конечно же хороша ... ! ... но основной проблемы не снимает ...

... вот ...
13. Сергей (ildarovich) 20.08.10 11:12
(7) Такая возможность рассматривалась. Правда, параметр назывался ДатаКоррекции, а не ДатаАктуализации, но по сути это тоже самое. Пока скажу только, что смысл есть, причем не только из соображений логики.
14. Владимир (hogik) 20.08.10 17:40
(12)
Александр.
1) Про "актуальные остатки по складу на реальную секунду" мы уже беседовали в другой теме. ;-) Никакой "временной оси" для их получения не требуется, т.к. это одно число (штуки на полке). Остатки на НеРеальную секунду надо либо хранить, либо насчитывать. Если хранить, то блюсти последовательности. Если не хранить, то оптимизировать скорость алгоритма их "динамического" расчета. И делать этот расчет только когда это требуется, а не тупо считать всегда при "проведении" документов и тщательно оберегать последовательностями. ;-) При этом расчет производить и в отчетах и в "проведении" документов. Точнее при применении функции, типа, ПолучитьНаДатуЧегоНиБудь() во всех модулях системы. Простейший алгоритм это просмотр всего движения от актуального "итога" предыдущего расчета до требуемой даты. За актуальность "итога" отвечает любое изменение движения документом, стоящего "раньше" актуального - просто сбрасывается флаг актуальности "итога" на дату, указывающий на НеАктуальность всех "итогов" расположенных "ниже".
Интересный алгоритм для реализации SQL-ем. ;-)
Вот такой алгоритм. Или я ошибаюсь?
2) "или отказ от ТА был смелым творческим эксперментом"(с)
- Не думаю. Причины отказа - это еще один шаг в осмыслении понятия "документ". Его места на оси времени, в схеме базы данных и в сути "автоматизации" предприятия (не только учета). Думаю, что они придут к тому, что документ это, например, только НомерДатаВремя твердой копии в схеме базы данных (образно говоря). А всё остальное содержание "документа" (агрегата данных, подсхемы) ссылается на ЭТО. И "документ" не является единым целым. Т.е. объектная или иерархическая (сетевая) модель хранения данных и представления предметной области. Но это другая тема. Можно, если хочешь, поговорить и об этом... ;-)
newold2; dddxddd; +2 Ответить
15. Александр Медведев (anig99) 22.08.10 09:07
плюс за осуществление мечты использовать в 1с хоть какой-нибудь математический аппарат!
Арчибальд; +1 Ответить 1
16. Павел Кучеренко (NCCSOFT) 23.08.10 09:21
(7) Элегантный механизм может быть реализован в виде отдельного нового метода
ПровестиВсеДокументыЗаОднуСекунду("FIFO");

И только там, где себестоимость изменилась - происходит её Update в базе, на что уйдет всё остальное время, за минусом этой одной секунды на проведение.
Практическое доказательство что это возможно еще сделал в 2008 году Проведение по FIFO всей базы за 1 секунду ....
17. Сергей Ожерельев (Поручик) 23.08.10 11:52
(15) плюс, конечно.
Только смотрю на это произведение и куда его присобачить? :D Перепахать типовую, чтобы быть вздёрнутым на воротах проходной в назидание другим. Местное франьё дебильное заклюёт, он что-то сделал, мы разобраться не можем.
18. Александр Медведев (anig99) 23.08.10 12:14
(17) альтернативная подсистема
19. Александр Шишкин (Шёпот теней) 23.08.10 12:53
... а зачем телеге - реактивный двигатель ... ? ... вот ...
20. Малышко В.Н. (molot) 24.08.10 23:40
Мммм.... Вот есть же в 8-ке забавный механизм определения записей регистра, которые необходимо рассчитать заново при изменении других записей этого регистра... Только это - в регистрах рассчета... Почему, елки-палки, так сложно было придумать подобный механизм для регистров накопления? Дык нет же, присобачили к, в общем-то, неплохой платформе самое кривое, что было в 77 - последовательности, да еще и в почти не измененном виде...
21. Алексей Новиков (Новиков) 16.09.11 15:53
К сожалению сейчас только увидел эту статью. Автору яростно плюсу за его труд. Очень похвально, что среди нас остались еще люди, способные применять для решения задачи такие фундаментальные подходы.

По поводу выхлопа от предложенного решения (имхо): кто помнит, еще до самого бета-тестирования 1С 8.0, на партнерках проскакивало что платформа САМА будет вычислять нужную последовать документов в случае если они проводятся задними числами на временной оси и САМА же опять перепроводить эту самую последовательность. И! И в методичках самых первых от 2004 года, вообще пишут открытым текстом - что использование механизма последовательностей является плохой "устаревшей" тенденцией. Прошло с того года почти 7 лет: к чему пришли? К идеи - что в момент проведения документов нужно контролировать только жизненно-необходимые параметры (и то не всегда), а все остальное дописывать некими регламентными заданиям когда-то там ночами в конца месяцов, кварталов, лет. И кстати - новый механизм контроля остатков при проведении в 8.2 "Здравствуй" тоже! Поэтому, логично предположить, что теперь "с облаками" все будет плавно двигаться к тому, что на клиенте будет только фиксация какая-то элементарная самого факта, что оператор что-то сделал. Все остальные просчеты/портянки фифо/раузы-хренаузы будут делаться уже на серверах по специальным джобам-регламентам. В свете этого, думаю что автор может как-нибудь доработать его интересую идею до этой концепции, и вполне возможно замутить некую подсистемку. А почему бы и нет!?

В любом случае - автору удачи!
agrustny; +1 Ответить
22. Осипов Сергей (fixin) 07.12.11 14:30
Честно говоря, по описанию не осилил. Подход уловил, но как реализуется на практике, не очень понял. Надо скачать и смотреть код.

Не знаю, учел ли автор такой момент, что все движения по номенклатуре после текущего движения из регистра сведений можно получить ОДНИМ(!) запросом, соответственно, для экономии времени записывать только те записи, которые менялись. Тогда скорость будет еще больше. Вроде на использование этого нюанса автор не обратил внимания.

Вообще описание очень сложное. Рекомендую упростить для чайников.
23. Сергей (ildarovich) 07.12.11 16:42
(22) Так и делается. То есть выбирается вся структура списания номенклатуры после даты изменяемого документа до бесконечности. Вот запросы для выборки и для записи. Собственно время одной итерации складывается из времени чтения из регистра сведений, времени обработки в оперативной памяти, времени записи в регистр сведений. Я пытался оптимизировать все три операции. Основной интерес был в алгоритме обработки в оперативной памяти: казалось, что если изменение структуры списания малы, то также малыми изменениями можно привести ее к требуемому виду. Также внимание уделялось и записи, но там есть момент, который трудно обойти: запись в регистр сведений ведется "гранулами", которыми является таблица с фиксированными отборами. Мы заинтересованы выполнять запись гранулой максимального размера. Такой гранулой может быть либо все (сначала времен) списания по номенклатуре, либо по номенклатуре+приход. А промежуточного варианта нет! То есть запись все же идет не одним оператором, а порциями. В основе там то, что Update делается через Delete+Insert. 1C пока не собирается менять позицию по этому вопросу, хотя в последних версиях SQL возможность Mesh-Update (возможно, путаю термин) имеется. С другой стороны, это "технологические", а не алгоритмические ограничения. И они, судя по профилировщику, не столь существенны - запись не более четверти времени занимает от времени всей итерации.
Прикрепленные файлы:
25. Сергей (Che) Коцюра (CheBurator) 15.09.13 15:18
Обеспечение правильной последовательности документов по количеству - задача решенная. При любом изменении задним/неоперативным числом - можно практически мгновенно сказать - есть нарушения (уход в минус) в количественном учете (от точки изменения до сейчас) или нет - и для этого не надо колошматить кучу документов.

А вот задача правильного контроля нематериальных сущностей - сумм/партионки - тут уже все сложнее...
26. Сергей (Che) Коцюра (CheBurator) 15.09.13 15:18
27. Андрей Овсянкин (Evil Beaver) 10.12.13 09:58
Математика - царица наук. Статьи ildarovich у меня всегда на отдельной почетной полочке.
Вот и эту статью положу на видное место. Разбираться потом буду, и стопудов, оно того стоит :)
28. Александр Зубцов (iov) 11.12.13 13:46
Ребята а можно свою ложку дегтя? А контролируются ли появление минусов за период с документа по оперативный ? то есть минусы которые могут появится в результате корректировки задним числом в другом дне например?
29. Сергей (ildarovich) 11.12.13 20:06
(28) Контролируется полностью вся цепочка от измененного документа до последнего, который может быть и в будущем. Понятия оперативного проведения в этом методе нет. Можете скачать конфигурацию и проверить.
30. Сергей (Che) Коцюра (CheBurator) 12.12.13 19:04
(28) см (25) - при любом изменении задним числом я могу практически мгновенно сказать - есть ли уход в минуса на всем протяжении от изменения до точки актуальности. Без всякой проверки кучи документов и проверки всей цепочки.
31. Александр Зубцов (iov) 12.12.13 19:14
(30) Таки и вопрос не для поедателей "собак" учета. Я сотни раз видел как этот маленький нюанс забывается...
32. Сергей (Che) Коцюра (CheBurator) 12.12.13 19:19
Все эти "минуса" и все их сопровождающее - от отсутсвия порядка в учете. И нежелания нагибать клиента (покпателя/поставщика) под работу правильно. Поэтому - все траблы чужих по отношению к нашей конторе людей - вылазять "минусами". У меня все проблемы - исключительно при псевдоисправительных действиях. Когда НАДО - а правильно или неправильно - никого не интересует. а ты потом за полторы тыщи км - мечешься как угорелый
33. Александр Зубцов (iov) 12.12.13 19:25
(32) Зп 1снега фикси состоит из
10% внедрении нового функционала
20% Исправлении типового функционала
30% Ошибок учета.
40% Из "неправильно но очень нужно вчера в другой валюте на китайском языке написанном арабской вязью для очень перспективного клиента и чтобы цены динамически от яркости солнца и глубины океана подбирались на группу по постоянно меняющимся правилам. А И ЧТОБ САМО"!!!
34. Александр Зубцов (iov) 12.12.13 19:26
35. анд гру (agrustny) 17.04.14 11:28
Все серьезно: полигон и термоядерные испытания мегатонной продукции.
Проблема, боюсь, в том, что 1С покупается для печати отчетности в одобренном государственным бюрократическим аппаратом виде, а не наведения порядка в учете или тем более ускорения работы сервера, поддерживающего учет. Если 1С будет работать в 2 раза быстрее - никто за это им копеечки лишней не выдаст, а вот если вдруг что-то не так будет с отчетностью - сильно обидятся. По-моему, Нуралиев в каком-то интервью рассказывал, что на старте (в смутные времена) у них был момент, когда он полагал, что их закроют ко всем чертям по причине незнания бухгалтерских форм.
А вообще фактическая неспособность программы контролировать причинно-следственные связи - это, конечно, крупное хулинство полное безобразие. Очень хочется Вас яростно плюсовать, как тут любят выражаться. (blank space to be filled by smailik)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа