Поле "Стандартная себестоимость"

[Maxim Gorbunov]

А как Вы при этом будете разницу между Вашей отчетностью и стандартной объяснять?

[Recoilme]

Цитата:

Сообщение от glibs

Если вас не затруднит, м.б. вы сможете аргументы назвать.

Ежедневное закрытие склада не есть самоцель в этой ситуации как мне кажется. Т.е. руководство в данном случае интересует оперативное получение информации по марже. Для получения информации по марже можно идти разными путями, два самых очевидных это актуализация себестоимости непосредственно в системе или получение этих же значений вне системы.

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

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

Есть ещё один неплохой путь. Развитие пути 1
Путь 3. Оптимизировать алгоритм рассчета себестоимости. В случае ускорения алгоритма примерно в 40 раз - можно оперативно актуализировать себестоимость. Данный путь, в виде законченного решения, я надеюсь, будет предложен в ближайшее время на коммерческой основе всем желающим в разделе рынок ЕРП систем.

Путь 4. Комплекс отчетов и алгоритмов анализа, как развитие пути 2, тоже надеюсь будет предложен, но позже

[glibs]

Цитата:

Сообщение от Recoilme

...
- после даты закрытия невозможна разноска (а как же вчерашние документы??)
...

Я не говорил, что нужно сегодня уже закрывать склад за вчера. Ежедневно закрывать склад можно и с отставанием в 10 дней или даже месяц.

Цитата:

Сообщение от Recoilme

...
- желателен момнопольный доступ на время выполнения (блокировки, тяжелый алгоритм)
...

1. Закрытие склада за один день происходит быстро. Гораздо быстрее, чем за месяц.

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

Цитата:

Сообщение от Recoilme

...
руководство в данном случае интересует оперативное получение информации по марже.
...

Вы не находите, что то, что написано выше, противоречит тому, что написано ниже?

Цитата:

Сообщение от Recoilme

...
в случае разноски операций задним числом
...

Тут уж нужно либо не разносить операции задним числом, либо не апелировать к оперативному получению актуальных данных по марже.

[Recoilme]

2 glibs:
У нас принципиальное различие в подходах. Мне кажется Вы в первую очередь думаете о "простоте" реализации, а я больше о "полноте" реализации.

По существу:
Дело в том что не всякое руководство устроит получение информации с отставанием в 10 дней. Если многие компании и мирятся с такой ситуацией, то это от безысходности, а не от "бест практис". Я же просто хотел осветить и другие варианты решения данной проблемы, но не настаиваю на них, отметив что предложенный путь не тривиален. Но реализуем вполне.

По поводу выше-ниже - вполне можно и разносить задним числом и пересчитывать каждый раз заново например за поледние 2 недели. Это противоречие решаемо.

[AlexeyBP]

По поводу трудоемкости закрытия склада ежедневно:
Как корректно посчитать рост базы данных при ежедневном закрытии/пересчете и сравнить с ежемесячным закрытием?
При закрытие участвуют таблицы: InventTrans, InventSettlement, LedgerTrans (если обновляем главную книгу). Корректно ли сравненить рост количества записей при закрытии / пересчете за месяц и за день?

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