Регистры накопления

[optron]

Добрый день всем.
В 1С есть хорошая функция - "регистры накопления". При любой операции бросаешь туда сведения о приходе - расходе и она отлично (а главное, быстро) выдает остатки и оборот по нужному периоду.
Есть ли такой функционал в Клаше? Стандартно, вроде бы нет. Может быть кто - то создавал подобное?
А то сейчас функция подсчета остатков при достаточно бурном обороте занимает около 40 минут на серваке.

[Игорь Столяров]

Привет !
Наверно это реализуется не средствами инструментальной среды разработки, а структурой БД и функциями ее обслуживания.
Можно сделать, например, отдельные индексированные списки в которых будут хранится обороты за день, месяц и остатки на начало дня (месяца).
Информация в этих списках накапливается и обновляется при добавлении (или проводке) первичных документов "бурного" оборота.
Тогда несложно делается функция запроса оборотов и остатков за указанный период, которая быстро вернет результат
без обработки всего массива первичных документов, по индексированным спискам оборота и остатков. Вот и все.

[optron]

Согласен. Тоже уже прихожу к тому, что следует создавать отдельные оборотные таблицы.
Я просто к тому, что в 1С это уже изначально реализовано и реализовано просто и "визуально".

[Игорь Столяров]

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

[FinSoft]

Добрый день всем.
В 1С есть хорошая функция - "регистры накопления". При любой операции бросаешь туда сведения о приходе - расходе и она отлично (а главное, быстро) выдает остатки и оборот по нужному периоду.
Есть ли такой функционал в Клаше? Стандартно, вроде бы нет. Может быть кто - то создавал подобное?
А то сейчас функция подсчета остатков при достаточно бурном обороте занимает около 40 минут на серваке.

Привет. Дело хозяйское, я бы обратил внимание, что львиная доля проблем в эксплуатации 1с предприятия связана с их механизмом регистров. Меняете, к примеру, приходную накладную задним числом, и поплыли итоги. Поскольку код в модулях проведения документов нельзя контролировать на уровне платформы, то и наладить автоматический пересчет регистров не получается. Чего они только не пробовали, результат оставался прежним - некорректная многопользовательская работа. Последняя "придумка" - вообще отказаться от парционного учета товарооборота.
В кларионе мы не связаны с необходимостью использования подобного подхода. И это огромный плюс. Чтобы решить проблему с производительностью, логично формировать остатки на определенную дату, одновременно закрывая период от изменений. А расчеты выполнять от ближайших остатков. Мы также формируем некоторые сводные итоги в отдельных таблицах, но только для закрытых периодов. Программа использует их по мере обнаружения. Т.е. пользователи могут самостоятельно решать, с каким интервалом закрывать периоды, в зависимости от времени отклика системы. А в открытом периоде итоги считаем всегда динамически на основании документов. Есть пара исключений. Текущие остатки в разрезе товар/склад все же сохраняются в отдельной таблице. А в модуле бухгалтерского учета некоторые результаты расчетов сохраняются в специальном кэше, актуальность которого отслеживается по логу изменений в базе данных. Последнее связано со спецификой работы бухгалтеров.

[optron]

Приветствую, FinSoft.
Так то оно так. В принципе, у меня так всё и происходит. Остатки передаются из месяца в месяц и период закрывается (типа). Закрыть полностью его не могу, так как списание расходов (в моем случае - тупо проставление дат накладным) происходит ну о-о-чень нерегулярно. Может попасть накладная как текущего периода, так и с прошлого года (они у меня передаются, если не проставлена официальная дата). Получается типа как 2 бухгалтерии в одном программном продукте - одна "официальная", другая - "реальная", где проставлена дата или нет, товара на складе реально быть не должно, а официально - существует.
Кроме того, товар может иметь внутренние перемещения между подразделениями (а их около сотни), которые нужно отловить. При обычных складских остатках - дело наживное. Подсчитывается всё быстро, а вот когда формируем отчет, начиная от малооценки (ИиП) с проставленными инвентарными номерами, которые также имеют внутренние перемещения, вот тогда и происходят танцы с бубнами, так как сначала пляшем от ИиП, затем попадая в складские остатки. А позиций около 100 тысяч.
Спасибо за описания траблов с 1С-кой, так как пригодится.

[kreator]

optron, а каких размерах таблиц идёт речь? Наверняка есть SQL сервер. Какой? Просто 40 минут ждать остатки - это, действительно, беда.

[optron]

Ну это один такой суммарный около 40 минут крутится. В основе то своей, более простые - от секунд до пары минут.

В расходе - около 100 тысяч записей, в приходе - на текущий момент - около 10 тысяч записей.

Ежемесячная оборотная таблица включает в себя около 15 тысяч позиций.

Суммарный объем баз - около 50 мегабайт.

SQL на серваках крутятся любые, в принципе. MySql поставить без проблем, в принципе.
Оракл крутится, Постгресс. Базу могут выделить и там и там.
Клаша работает с tps базами, так как, как обычно, дела идут, останавливаться невозможно, а перерабатывать функционал на SQL некогда, да и мануалов нормальных нет по клаше с SQL. Хотя, конечно, хочется именно этим и заняться.

[FinSoft]

Когда-то давно писал статью по поводу оптимизации производительности. Вот ссылка, может будет полезно:
www.finsoftrz.ru/articles/powers.html
Совмещать реальный и официальный учет в одной базе при таком количестве номенклатуры довольно геморойно, т.к. бухи постоянно норовят что-то исправить далеко позади. На мой взгляд, лучше под официальный учет делать одну или несколько отдельных баз (если юриков/ип несколько). У нас есть клиенты, работающие и так, и так. Если ведут в одной базе, то остатки сохраняются раздельно (товарные остатки, взаиморасчеты, касса и т.п.).

[Игорь Столяров]

Когда-то давно писал статью по поводу оптимизации производительности.

Неожиданно интересная статья, спасибо.
И еще написал небольшое предложение в личные сообщения, посмотрите пожалуйста.

[kreator]

ИМХО. Оптимизировать работу файл-серверной модели в данном контексте - пустая трата времени. Нужен SQL. К примеру, у меня. Sybase ASA 7.0 (древняя-предревняя) на Phenom 4-х ядерном (не ахти что сейчас). Таблица документов (накладные на приход, расход, возврат и т.д) - записей чуть-чуть за 100000. Таблица содержимого накладных (в ней ссылка на товар, кол-во, цена и т.д.) - где-то за 1000000 записей. В запросах участвуют ещё связанные таблицы справочников (адресаты, товар, единицы измерений ...). Промежуточные итоги нигде не накапливаются. Получение всех остатков на какую-нибудь дату на центральном складе занимает 2-3 мин максимум, при том, что пользователей много и они частенько гоняют отчёты, а не просто вводят информацию.
Поэтому, путь к увеличению производительности системы (я его прошёл с успехом): 1. Переход на SQL. 2. Покупка мощного серверного оборудования. 3. Оптимизация базы (таблицы, индексы) и SQL запросов (возможностей море) (до этого, правда, ещё руки не дошли).

[FinSoft]

Тут речь идет не просто о подсчете остатков товаров на складе, а об определении наценки продаж в различных разрезах. То есть о распределении отгрузок (списаний, перемещений, возвратов) по приходным накладным. Это довольно ресурсоемкая процедура при любом раскладе.
У нас файл-серверный вариант используется довольно редко. Речь идет о встроенных базах, работающих, как правило, на терминальных серверах. Сейчас, после появления недорогих решений (я бы обратил внимание на tsplus, если нужно хорошо, легально и недорого), вопрос целесообразности перевода баз на sql чисто дело вкуса разработчика.

[optron]

Ну вообще то вопрос о sql базах начальством ставится, так как к ним ну очень удобно и очень стандартно цепляться из любых других программных систем. Так, что, всё равно, видимо, придется в ту сторону смотреть.

[Андрей]

Знатокам просьба большая кратко описать механизм оперативного расчета, например остатков.

Пусть в какой то таблице есть остаток товара по складу. Пусть форма на приход и расход одна (физически, для пользователя делаем 2 представления). Проводим документ, в котором может быть
а) Приход (добавление) - тут нужно просто остаток увеличить на кол-во в текущем документе
б) Расход - остаток уменьшить на кол-во в текущем документе
в) Удаление ошибочно введенного док-та - уменьшить, если приход, увеличить, если расход
г) Исправление ошибочно введенного док-та - а тут то и посложнее.... надо определить разницу (корректировку) и соответственно уменьшить/увеличить остаток.
.... все кажется ?


Как ентно все реализовать ? А именно

1) Как в одном документе перехватить эти 4 варианта ? Пусть программистко 1 и 2 варианты тождетственны, остается 3 варианта
Думается, что нужно удаление через форму делать, во-первых. Далее через SELF.Request ? Например SELF.Request=InsertRecord - это 1- и 2 варианты и т.д

2) Что делать с в) и г) ?
3) А еще бы хорошо и завернуть обе файловых операции в транзакцию ? Как это сделать в форме ?

В общем вопросы, вопросы... Наверняка у многих качественно решенные... отпишитесь pls/ Обязуюсь, составить тестовый приимер и все примерно опробовать

[Игорь Столяров]

Ни в коем случае не претендуя, на то что Вы называете "знатоком" я хотел бы уточнить:

1. Судя по слову "склад" речь идет о накладных. Движение товара формируется на основании содержания накладной.
Соответственно, все что Вы написали должно выполняться и для строки содержания накладной и для всей накладной в целом ...

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

3. Если интересно я Вам сбросил ссылку в личные сообщения на пример программы учета, в которой некая схема реализована.
Посмотрите если интересно, все сделано на Clarion.