Пересчет средних цен

[WiRuc]

Не подскажете, какой алгоритм при пересчете средних цен в расходных ордерах? Стандартная функция Галактики работает как-то криво (вылезают минусы, хотя кол-во по приходу=кол-ву по расходу), поэтому хочу ее переписать. У нас партионный учет,списание склад-мол-партия.

[Галя]

Важно например, если приход и расход в один день, чтобы приход все же стоял в карточке складского учета вперед расхода. А вообще, методика пересчета обычная: берется на дату пересчета количество и общая стоимость МЦ в днном разрезе учета и вычисляется средняя цена, которая и проставляется в соответствующий расходный ордер

[ecasoft]

Круто

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

Надеюсь помог. Игорь

[Галя]

А у нас все замечательно со стандартным пересчетом работает. Выдается протокол ошибок, по которому сами пользователи быстро учатся находить и исправлять косяки.
На самом деле все эти ошибки с минусовыми ценами происходят из-за неотлаженного регламента работы пользователей и невыполнения инструкций (они должны быть) - как правильно все сделать например, если по каким-то причинам пришлось все же переоприходовать товар задним числом.
Как говорится, автоматизировать хаос невозможно

[WiRuc]

Мы только начинаем работать, если можете, то просветите как надо правильно оприходывать товар задним числом.
Опишу подробней, какова ошибка. При пересчете цен Галактика ругается на отрицательное кол-во (надо 1, расчетное -1).
В карточке складского учета на этот день вначале идут расходы, затем приход и затем еще один раход в кол-ве 1.
Сумма прихода за этот день равна сумме расхода за этот день. Галактика также показывает, что кол-во в разрезе 0.
В чем ошибка и как ее найти?

2 Игорь
Возможно вы правы и лучше написать функцию контроля. Но и в этом случае надо знать алгоритм расчета средних цен в Галактике.
Что мне собственно и надо.

[Галя]

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

[WiRuc]

Попробовал, порядок не изменяется. Да и какая разница в каком они идут порядке? Главное, чтобы приход>=расход на эту дату.

[ecasoft]

В один день если даже расходы идут раньше приходов, то это несущественно (такого нет понятия в БД "РАНЬШЕ в течение одного дня"..т.к. в Галактике Вы не работаете по индексу, который совмешает в себе понятие даты операции и времени последней модификации..поэтому для Галактики понятие РАНЬШЕ в течение дня не существует при рассмотрении таблицы ордеров.

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

Kн Цн - количество и цена прихода;
К Цу - количество на складе до прихода и цена учетная до прихода;

Новая цена = ((Кн*Цн) + (К*Цу)) / (Кн+К);

Но если МЦ немного, то можно воспользоваться просто пересчетом штатный. Если проверять глазами,то обычно ошибка такая: в карточке когда смотрят, то не учитывают разрез учета. Лучше в карточке проверить наложив фильтры по разрезам учета и смотреть.
Хуже ошибка, когда делали ордера к примеру по какому-то молу, а затем мола удалили из каталога МОЛОв. Надо понимать, что БЕЗ МОЛ - это тоже разрез хранения. Но в карточке удаленный МОЛ видиться как будто отсутсвует МОЛ. Такие исправлять сложнее, хотя в принципе тоже можно конфигуратором поставить ссылку на мола и будут видны различия.
Скорее всего у Вас все же ошибка в разрезе. Есть накладные, которые оприходованы в одном разрезе, а в расходных накладных разрез указали не точно. В итого по расходу может быть недостача. То, что в один день расходы и приходы не должно влиять на расчеты, в каком бы порядке они не были. 100% не дам, то по-моему искать все же надо в первичке ошибку - не туда оприходовали откуда берете.


Порядок работы задним чистом такой: если изменяли дату прихода или количество прихода или цену прихода или дату или количество в расходе в одной из накладной (акте излишков или списания, инвентаризационной ведомости и т.д.) или ордере (хотя с ордерами мы не рекомендуем вообще напрямую работать), которая была оформлена по отпускаемой МЦ ранее, то надо пересчитать по этой МЦ цены в расходных ордерах с момента исправления до текущего, используя соответствующий пункт меню.

Удачи.

[Deinis]

2 Косякин Игорь:
"Программа проверки же работала на фоне всем..ничего не исправляла, а позволяла выявить неверные последовательности операций оприходования и расхода, при которых появлялись остатки с минусом, выявить МЦ и периоды"

Игорь, а вы можете раскрыть секреты программирования? Как можно загнать в память кусок кода, который будет все время в ней сидеть и что-то контролировать, аки антивирус какой?
Очень меня (да и не только меня, думаю) занимает этот вопрос.

[Саша Г.]

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