Алгоритмы в учетных системах

Clarion, Clarion 7

Модератор: Дед Пахом

Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Недавно попробовал снять несколько роликов с озвучкой для пользователей. Не все гладко получилось, голос, как я понял, надо качать, как мышцы. :-)
Думал, стоит ли сюда что-то постить. Потом решил, пусть будет, так как приведенные ниже решения сложились после бурных обсуждений в clalist в 2003-2004 годах. Когда что ни кларионист, то богатырь был. :-)

Аудиторский след. Штука из разряда must be в серьезной системе. Идею транзакционного лога тогда подробно описал Владимир Уколов. У них на заводе использовалась какая-то старая буржуинская система, это оттуда. Другой вариант это физический лог (можно так назвать), когда в логе сохраняются старое и новое значение каждого поля. Это отстаивал, насколько помню, Олег Руденко, у него было какое-то свое решение в проектах.
http://finsoftrz.ru/mp4/audit.htm

Работа без проведения документов. Всегда не нравился механизм проведения документов в 1С Предприятии. Зло лютое, когда документы могут изменяться задним числом, а это практически всегда так. По сути, некорректная организация многопользовательской работы. Но они 1С, им все можно. После опыта работы с проводными системами, я тогда сразу забился отказаться от данной методики в пользу расчета итогов "на лету".
http://finsoftrz.ru/mp4/doc_no_prov.htm

Оптимизация производительности расчетов. Когда-то я выкладывал достаточно подробную статью с описанием применяемых алгоритмов. Этот ролик иллюстрация, как оно работает в реальной жизни.
http://finsoftrz.ru/mp4/calc_optim.htm

Конкурентная выписка накладных. Тоже активно обсуждали в clalist. Тогда тот-же Владимир Уколов рассказал, как он применил построчное сохранение накладных в базе MS SQL, и это сильно увеличило скорость выписки на складе в условиях нехватки товаров. Насколько помню, Андрей Мялин тогда закричал, вы что, так нельзя, или сразу всю накладную сохранять, или не сохранять. Олег Руденко написал, что он пробовал тоже такую методологию, но в последних проектах предпочитает сохранять документ целиком, так как это гораздо проще в реализации, а у клиентов мало денег, чтобы оплачивать такую разработку. У меня ситуация была тоже связана с работой в условиях нехватки товаров на складе, поэтому я пошел путем, как Владимир. И таки да, реализация внутрях сложная. Зато и бонусы налицо.
http://finsoftrz.ru/mp4/nakl_conc.htm

Наслаждайтесь, может, кому идеи пригодятся. Лучше один раз увидеть решение из реальной жизни, чем десять раз написать.
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
ingasoftplus
Ветеран
Сообщения: 425
Зарегистрирован: 26 Декабрь 2006, 17:07
Откуда: Оттуда :)
Благодарил (а): 87 раз
Поблагодарили: 5 раз

Алгоритмы в учетных системах

Сообщение ingasoftplus »

:ty:
только без колонок (когда можно выкрутить громкость) почти ничего не слышно
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Я у себя на планшете на максимальной громкости нормально слышу. В принципе, можно пересобрать, громкость задаётся в параметрах. У меня на основном компе колонки, в них громко слышно было.
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Отказ от использования механизма проведения документов позволяет значительно уменьшить размер базы данных, уменьшить количество ее модификаций, значительно повысить надежность, сделать информацию прозрачной для пользователя.
В этом ролике речь идет про использование приема денормализации базы данных и критических реквизитах документов.
Ролик с озвучкой.
http://finsoftrz.ru/mp4/denorm.htm
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 7322
Зарегистрирован: 07 Июль 2005, 10:19
Откуда: г. Ростов-на-ДоМу
Благодарил (а): 13 раз
Поблагодарили: 48 раз

Алгоритмы в учетных системах

Сообщение Игорь Столяров »

Спасибо ! С удовольствием посмотрел. С Вашего разрешения выскажу своё субъективное мнение. :)

От внесения изменений в содержание при проводке и от избыточности содержания с дублированием
в нём данных из шапки документа мы полностью отказались лет 12-15 назад точно ...

У нас: как Вы и сказали - действительно, содержание накладной всегда индексируется, но только по товару.
Этого более чем достаточно для всех выборок движения в любых запросах. Это всё замерялось и тестировалось.
И какой же выигрыш по объёму БД, если в содержании делается несколько мощных ключей ? Это будет падать. :(

Я понимаю причины, но не должно быть ограничений: если пользователь отменил изменение документа,
то документ восстанавливается в первоначальном виде.

И конечно пардон, но присутствует ошибка нормализации БД. Как только мы вводим избыточность и одни и те же данные
(дата накладной и т.д.) начинаем хранить в разных списках - проверено: рано или поздно это начнёт сбоить при какой-то
нештатной операции.

С тем, что бы с разных станций в сети редактировать один документ - наверно я просто вообще не понял смысла ... :(
За теми кто отстал - не возвращаться. (С) Кодекс
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Игорь Столяров писал(а): 01 Июнь 2021, 22:55

С тем, что бы с разных станций в сети редактировать один документ - наверно я просто вообще не понял смысла ... :(
Нет, я про такое не говорил. У нас с разных рабочих мест редактировать один и тот же документ нельзя, выставляется логическая блокировка в системной таблице.
Если имеется ввиду конкурентная выписка накладных, то это другое. Если несколько пользователей параллельно выписывают товары (каждый в своей накладной), то свободный остаток контролируется сразу, с учётом того, сколько навыписывал каждый, а не в момент сохранения документа.
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 7322
Зарегистрирован: 07 Июль 2005, 10:19
Откуда: г. Ростов-на-ДоМу
Благодарил (а): 13 раз
Поблагодарили: 48 раз

Алгоритмы в учетных системах

Сообщение Игорь Столяров »

finsoftrz писал(а): 01 Июнь 2021, 23:33 то свободный остаток контролируется сразу
Понял. Это видимо специфика конкретной реализации. В общем случае речь может идти о резервировании остатка.
Потому, что не должно быть разрыва между учётным и фактическим остатком товара. А по факту остаток товара
изменяется только в момент его выдачи кладовщиком (вот для этого у нас и существует операция "Проводка"). :)
За теми кто отстал - не возвращаться. (С) Кодекс
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Игорь Столяров писал(а): 01 Июнь 2021, 22:55 Спасибо ! С удовольствием посмотрел. С Вашего разрешения выскажу своё субъективное мнение. :)

От внесения изменений в содержание при проводке и от избыточности содержания с дублированием
в нём данных из шапки документа мы полностью отказались лет 12-15 назад точно ...

У нас: как Вы и сказали - действительно, содержание накладной всегда индексируется, но только по товару.
Этого более чем достаточно для всех выборок движения в любых запросах. Это всё замерялось и тестировалось.
В этом случае получается, что при расчётах движений по товару Вы будете считать от начала работы с базой данных? Если учесть, что не просто выборка операций, а фифо, то будет медленно работать и молотить кучу лишней информации. Опять таки, а как быстро получить, например, ближайшую цену закупки товара в магазине на нужный момент? Сохранение в строках идентификатора склада появилось относительно недавно, как раз по причине того, что потребовался контрольный отчёт об отклонениях цен закупки от предыдущих более заданного процента, на большой базе данных.
Может, у Вас небольшие базы данных или более простой функционал? Интересно было бы услышать о реализации фифо у Вас. Насколько помню, Вы вообще запрещает редактировать проведённые документы. Сами понимаете, что отмена проведения документа влияет на остатки и движение всех товаров, которые в нем есть, что не есть хорошо, т.к. искажает остатки и отчёты.
И какой же выигрыш по объёму БД, если в содержании делается несколько мощных ключей ? Это будет падать. :(

Выигрыш в объёме данных по сравнению с проводной системой. У них помимо таблиц с документами ещё куча регистров. Например, в 1с на одну отгрузочную накладную, в зависимости от сложности конфигурации, может быть создан десяток разных регистров, которые заполняются при проведении документа. А регистр парционного учёта может содержать по несколько строк на одну строку исходной накладной. И у каждого регистра свои записи и индексы. Индекс с 4 лонгами не такой уж и тяжёлый, во всяком случае, по сравнению с регистрами, копейки.
Много лет работает, не падает. Почему должно падать? Просто не надо использовать файл северный режим работы.

Я понимаю причины, но не должно быть ограничений: если пользователь отменил изменение документа,
то документ восстанавливается в первоначальном виде.

Таки да, это компромисс. Я, конечно, подробно изучал вопрос. Внутренняя реализация и так достаточно сложная, много чего намешано. Поэтому я решил, что можно на такую схему пойти. Это крайне редко бывает, когда пользователь меняет критические реквизиты, а потом закрывает документ без сохранения изменений. Но программа должна отрабатывать все возможные сценарии.

И конечно пардон, но присутствует ошибка нормализации БД. Как только мы вводим избыточность и одни и те же данные
(дата накладной и т.д.) начинаем хранить в разных списках - проверено: рано или поздно это начнёт сбоить при какой-то
нештатной операции.
Когда технология отлаживалась, то бывало. Но уже давно никаких проблем не возникало. Есть процедура проверки содержимого базы данных, она расхождения отлавливает. У крупных клиентов запускается автоматом в ночное время и шлёт мне на почту отчёт о результатах. То есть, если бы проблемы имели место, я бы увидел.
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Игорь Столяров писал(а): 01 Июнь 2021, 23:47
finsoftrz писал(а): 01 Июнь 2021, 23:33 то свободный остаток контролируется сразу
Понял. Это видимо специфика конкретной реализации. В общем случае речь может идти о резервировании остатка.
Потому, что не должно быть разрыва между учётным и фактическим остатком товара. А по факту остаток товара
изменяется только в момент его выдачи кладовщиком (вот для этого у нас и существует операция "Проводка"). :)
Да, это резервирование товара. Данный процесс может сильно зависеть от вида бизнеса. Почему не может быть разрыва между фактическим и учёным остатком? Сколько угодно, для выравнивания и проводятся инвентаризации.
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 7322
Зарегистрирован: 07 Июль 2005, 10:19
Откуда: г. Ростов-на-ДоМу
Благодарил (а): 13 раз
Поблагодарили: 48 раз

Алгоритмы в учетных системах

Сообщение Игорь Столяров »

finsoftrz писал(а): 02 Июнь 2021, 0:26 для выравнивания и проводятся инвентаризации
Здесь полностью согласен. Но инвентаризация - это операция контроля и устранения проблем с расхождением остатков.
Например из-за пересортицы похожих товаров при выдаче. Но если менеджер Антонина начала выписывать (!!!) накладную
и ушла на биопаузу, а в системе теперь учётный остаток не соответствует фактическому - это не есть хорошо ... :shock:
За теми кто отстал - не возвращаться. (С) Кодекс
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Нет, у нас не так. Есть 3 состояния накладной - выписывается, утверждена, выключена. И есть текущий и свободный остаток. Когда накладная выписывается (обычное состояния после создания нового документа), то уменьшается свободный остаток. По нему контролируется доступность товаров при конкурентной выписке. Когда документ утверждается, то уменьшается текущий остаток. То есть, если нет других накладных в состоянии выписан, текущий и свободный остаток выравниваются. Таким способом осуществляется автоматическое резервирование товаров.
Когда утверждать накладную, это решает пользователь. Я рассуждал, как Вы сейчас, если правильно понял. Когда выписываем, то резервируем, когда отгрузили на складе, утверждаем окончательно. Но, как показывает практика, пользователи предпочитают утверждать документы сразу после выписки. Было обсуждение на эту тему (речь, конечно, про оптовку, где работают от выписки). Мне сказали, что им так удобнее, они сразу в одном месте видят все операции с товаром, а то, что не отгрузили ещё, понятно по другим признакам. Я тогда задумался, в принципе, логика в их словах есть.
В 1с, к слову, зачастую делают вначале отдельный документ Счёт (или с другим названием, в зависимости от конфигурации), который резервирует товары, но без функции конкурентной выписки. Потом на его основании создаётся накладная, которая при проведении снимает товары с резерва и уменьшает фактический остаток. В нейтральном положении (в нашей терминологии "выписан"), у них документ ни на что не влияет.
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 7322
Зарегистрирован: 07 Июль 2005, 10:19
Откуда: г. Ростов-на-ДоМу
Благодарил (а): 13 раз
Поблагодарили: 48 раз

Алгоритмы в учетных системах

Сообщение Игорь Столяров »

finsoftrz писал(а): 02 Июнь 2021, 7:59 В нейтральном положении (в нашей терминологии "выписан"), у них документ ни на что не влияет.
У нас аналогично. Выписанный документ ни на что не влияет.
Товар по нему может быть зарезервирован или выдан - но это действие (операция), которая должна быть выполнена отдельно.
Я понимаю, что есть местная специфика - но в общем случае документ это целостная транзакция.

Банальный пример. Торгуем офисной мебелью. Кресло состоит из спинки и крестовины - они разные и подбираются по заказу.
Поэтому нет смысла "на лету" резервировать спинки, если недостаточно крестовин. А в момент выписки список мы не знаем
ещё какие крестовины будут выписаны и т.д. Поэтому на резерв (или выдачу) ставиться полностью сформированный документ.
За теми кто отстал - не возвращаться. (С) Кодекс
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Да, так и есть, организация выписки сильно зависит от вида бизнеса. В моих темах (продукты и хозка) резервируют сразу, там нечего собирать и выяснять. Разумеется, на складе по факту может не быть каких-то товаров. Кладовщики их вычеркивают и получают в отгрузку на них самих. После чего бегут пересчитывать товары с попыткой выяснить пересорт, чтобы не попасть на деньги.
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
finsoftrz
✯ Ветеран ✯
Сообщения: 4549
Зарегистрирован: 06 Ноябрь 2014, 12:48
Благодарил (а): 6 раз
Поблагодарили: 34 раза

Алгоритмы в учетных системах

Сообщение finsoftrz »

Вообще, чем универсальнее система, тем больше телодвижений приходится делать пользователям, больше ошибок, хуже восприятие информации. Когда система специализируется на определенные виды бизнеса, то для этих тем все оптимально, но, если пытаться использовать для других целей, становится неудобно. Поэтому я сознательно ограничиваю основной проект продуктами и хозкой и не рекомендую для специфических товаров (электроника, мебель, одежда, обувь). Хотя бывает, приходят пользователи, которые торгуют чем не поподя. Например, спортивными тренажерами или носками на вайберис. Я говорю всегда, у нас под такие темы заточено, если устраивает, то пользуйтесь, не устраивает, поищите другой софт.
C6/C11, ШВС, tps/btrieve.
Аватара пользователя
Игорь Столяров
Ветеран движения
Сообщения: 7322
Зарегистрирован: 07 Июль 2005, 10:19
Откуда: г. Ростов-на-ДоМу
Благодарил (а): 13 раз
Поблагодарили: 48 раз

Алгоритмы в учетных системах

Сообщение Игорь Столяров »

finsoftrz писал(а): 02 Июнь 2021, 8:27 организация выписки сильно зависит от вида бизнеса.
Но всегда ведь существует соблазн найти общее решение вопроса ... ;) Не работать же всю жись с алкашкой да хозкой. :)
И здесь возникает дилемма. Либо мы по быстрому переносим существующую на конкретном предприятии бизнес модель в учётную
систему, либо мы реализуем решение, которое будет охватывать максимально возможное кол-во бизнес-моделей учёта. :)

Кстати, упомянутая всуе 1С всегда идёт по второму пути.
За теми кто отстал - не возвращаться. (С) Кодекс
Ответить