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

19.08.10

Разработка - Математика и алгоритмы

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

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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование По подписке [?] Купить один файл
Информационная база "Полигон"
.dt 1,31Mb
110
110 Скачать (1 SM) Купить за 1 850 руб.
Конфигурация "Полигон"
.cf 121,74Kb
30
30 Скачать (1 SM) Купить за 1 850 руб.
Отчет по статистике товаропотока для УТ
.erf 8,69Kb
28
28 Скачать (1 SM) Купить за 1 850 руб.

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

См. также

Математика и алгоритмы Программист Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    3619    stopa85    12    

38

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    8167    user1959478    52    

36

Математика и алгоритмы Разное Платформа 1С v8.3 Конфигурации 1cv8 Россия Абонемент ($m)

Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.

2 стартмани

29.09.2023    3550    maksa2005    8    

26

Математика и алгоритмы Инструментарий разработчика Программист Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    11292    8    SpaceOfMyHead    19    

61

Математика и алгоритмы Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.

03.04.2023    4799    RustIG    9    

25

Механизмы платформы 1С Математика и алгоритмы Программист Платформа 1С v8.3 Россия Бесплатно (free)

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

23.11.2022    3954    gzharkoj    14    

25

Математика и алгоритмы Программист Платформа 1С v8.3 Россия Абонемент ($m)

Обычно под распределением понимают определение сумм пропорционально коэффициентам. Предлагаю включить сюда также распределение по порядку (FIFO, LIFO) и повысить уровень размерности до 2-х. 1-ое означает, что распределение может быть не только пропорциональным, но и по порядку, а 2-ое - это вариант реализации матричного распределения: по строкам и столбцам. Возможно вас заинтересует также необычное решение этой задачи через создание DSL на базе реализации текучего интерфейса

1 стартмани

21.03.2022    9127    7    kalyaka    11    

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

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

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

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

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

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

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

... такаяВОТбалаМУТЬвот ...
ildarovich; +1 Ответить
5. ildarovich 7935 19.08.10 12:06 Сейчас в теме
(3) Абсолютно согласен.

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

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

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

... вот ...

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

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

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

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

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

... вот ...

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

...
9. Арчибальд 2709 19.08.10 13:40 Сейчас в теме
(8)
механизм проведения и перепроведния на конкретном предприятии
И я об этом. Не в типовой конфигурации, а в оттюнингованной под конкретику. Добавляем в документы общий реквизит "ДатаАктуализации" и, пользуясь ей, то как дубинкой для воспитания нерадивых юзеров, то как гибким инструментом срубания бабок на пересортице, то как оптимизатором восстановления последовательности, - делаем что хотим.
Шёпот теней; +1 Ответить
13. ildarovich 7935 20.08.10 11:12 Сейчас в теме
(7) Такая возможность рассматривалась. Правда, параметр назывался ДатаКоррекции, а не ДатаАктуализации, но по сути это тоже самое. Пока скажу только, что смысл есть, причем не только из соображений логики.
16. NCCSOFT 56 23.08.10 09:21 Сейчас в теме
(7) Элегантный механизм может быть реализован в виде отдельного нового метода
ПровестиВсеДокументыЗаОднуСекунду("FIFO");

И только там, где себестоимость изменилась - происходит её Update в базе, на что уйдет всё остальное время, за минусом этой одной секунды на проведение.
Практическое доказательство что это возможно еще сделал в 2008 году Проведение по FIFO всей базы за 1 секунду ....
10. ildarovich 7935 19.08.10 20:18 Сейчас в теме
(6) Я не противопоставляю доработку типовых конфигураций и создание принципиально новых. Можно заниматься и тем и другим: пропалывать грядки, распаханные и засаженные 1С и пробовать выращивать что-либо новое в чистом поле.
Обратите внимание на механизм резервирования в Управлении торговлей 11, механизм остатков в Логистике и управлении складом 3 - они появились казалось бы на пустом месте.
12. Шёпот теней 1782 20.08.10 08:54 Сейчас в теме
(10) ... а мне нравится ВАШ математический подход к проблеме ... ! ... проблема только не в "изготовлении" а в "повторении" и в "распространении" ... да и с "пониманием" будут проблемы ...

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

... вот ...

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

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

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

... вот ...
14. hogik 443 20.08.10 17:40 Сейчас в теме
(12)
Александр.
1) Про "актуальные остатки по складу на реальную секунду" мы уже беседовали в другой теме. ;-) Никакой "временной оси" для их получения не требуется, т.к. это одно число (штуки на полке). Остатки на НеРеальную секунду надо либо хранить, либо насчитывать. Если хранить, то блюсти последовательности. Если не хранить, то оптимизировать скорость алгоритма их "динамического" расчета. И делать этот расчет только когда это требуется, а не тупо считать всегда при "проведении" документов и тщательно оберегать последовательностями. ;-) При этом расчет производить и в отчетах и в "проведении" документов. Точнее при применении функции, типа, ПолучитьНаДатуЧегоНиБудь() во всех модулях системы. Простейший алгоритм это просмотр всего движения от актуального "итога" предыдущего расчета до требуемой даты. За актуальность "итога" отвечает любое изменение движения документом, стоящего "раньше" актуального - просто сбрасывается флаг актуальности "итога" на дату, указывающий на НеАктуальность всех "итогов" расположенных "ниже".
Интересный алгоритм для реализации SQL-ем. ;-)
Вот такой алгоритм. Или я ошибаюсь?
2) "или отказ от ТА был смелым творческим эксперментом"(с)
- Не думаю. Причины отказа - это еще один шаг в осмыслении понятия "документ". Его места на оси времени, в схеме базы данных и в сути "автоматизации" предприятия (не только учета). Думаю, что они придут к тому, что документ это, например, только НомерДатаВремя твердой копии в схеме базы данных (образно говоря). А всё остальное содержание "документа" (агрегата данных, подсхемы) ссылается на ЭТО. И "документ" не является единым целым. Т.е. объектная или иерархическая (сетевая) модель хранения данных и представления предметной области. Но это другая тема. Можно, если хочешь, поговорить и об этом... ;-)
newold2; dddxddd; +2 Ответить
11. hogik 443 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С надо бы приблизить к реальности. Т.е. иметь не только ДатуДокумента (дату, с которой в БД записываются движения), но и ДатуАктуализации (дату проведения)."
- Дык, они это и попытались сделать. ;-) Пока документ не проведен он имеет "любую" дату. А когда проводится получает, на их взгляд, "истинную" дату. Есть еще "промежуточные" состояние - типа, "полу-проведен". ;-) Перфокарточная, пакетная бухгалтерия... :-(
15. anig99 2852 22.08.10 09:07 Сейчас в теме
плюс за осуществление мечты использовать в 1с хоть какой-нибудь математический аппарат!
Арчибальд; +1 Ответить
17. Поручик 4694 23.08.10 11:52 Сейчас в теме
(15) плюс, конечно.
Только смотрю на это произведение и куда его присобачить? :D Перепахать типовую, чтобы быть вздёрнутым на воротах проходной в назидание другим. Местное франьё дебильное заклюёт, он что-то сделал, мы разобраться не можем.
18. anig99 2852 23.08.10 12:14 Сейчас в теме
(17) альтернативная подсистема
19. Шёпот теней 1782 23.08.10 12:53 Сейчас в теме
... а зачем телеге - реактивный двигатель ... ? ... вот ...
20. molot 285 24.08.10 23:40 Сейчас в теме
Мммм.... Вот есть же в 8-ке забавный механизм определения записей регистра, которые необходимо рассчитать заново при изменении других записей этого регистра... Только это - в регистрах рассчета... Почему, елки-палки, так сложно было придумать подобный механизм для регистров накопления? Дык нет же, присобачили к, в общем-то, неплохой платформе самое кривое, что было в 77 - последовательности, да еще и в почти не измененном виде...
21. Новиков 292 16.09.11 15:53 Сейчас в теме
К сожалению сейчас только увидел эту статью. Автору яростно плюсу за его труд. Очень похвально, что среди нас остались еще люди, способные применять для решения задачи такие фундаментальные подходы.

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

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

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

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

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