сумма без количества

[Apollon33]

Всем здравствуйте!
Есть небольшая проблемка.
Суть проблемы такова: Отчет "оборотно-сальдовая ведомость по складу" показывает, что по отдельной номенклатуре количество ноль, но есть деньги. Лежит номенклатура на 10 счете. Покапавшись немного, мне кажется, я нашел причину этого - коряво были распределены накладные расходы на себестоимость этой номенклатуры и, как следствие, закрытие складов отработало не совсем так. В итоге деньги зависли. Бухгалтер хочет их удрать (списать на 20), но убрать корректно, чтобы потом нигде ничего не вылезло. Но как это сделать? Возможно кто-то уже с подобной ситуацией сталкивался и нашел выход. Или сейчас разбирается.
(Есть нюанс: счет 10 (также как и 41 и 43) я могу увидеть только в разрезе номенклатур и просто сделать проводки по главной книге не получится).

[Apollon33]

да, забыл уточнить: система Ах 3.0

[mazzy]

Цитата:

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

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

В этом отчете какая-то фигня была со статусами.
То ли он учитывал физические движения, то ли не учитывал.
По-моему, копать стоит в этом направлении.

Поищите по "оборотно-сальдовая ведомость по складу" вроде обсуждалось неоднократно.

[Apollon33]

Цитата:

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

В этом отчете какая-то фигня была со статусами.

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

[Apollon33]

Собственно, поблема не в отчете. Он-то как раз нормально работает.
Вопрос как зависшие суммы убрать

[mazzy]

Цитата:

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

В итоге деньги зависли. Бухгалтер хочет их удрать (списать на 20), но убрать корректно, чтобы потом нигде ничего не вылезло.

Цитата:

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

Вопрос как зависшие суммы убрать

Ок.
Первое что посмотрите - это на каких проводках "зависли" суммы.
Если на открытых (valueOpen = NoYes::Yes), то ничего страшного - просто для этих проводок еще нет пары для закрытия. Процедура закрытия спишет сумму в следущие разы

(Примечание: Процедура закрытия закрывает вовсе не ВСЕ проводки до даты закрытия. Процедура закрытия закрывает полностью израсходованные проводки: для прихода есть расходы на все количество, для расходов есть приходы)

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

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

    while select sum(CostAmountPosted), sum(CostAmountAdjustment) from InventTrans
    group by ValueOpen
    where ...
    {
        info(strfmt("%1, %2, %3",InventTrans.ItemId, InventTrans.ValueOpen, InventTrans.CostAmountPosted+InventTrans.CostAmountAdjustment));
    }

одна из возможных причин - нарушение инварианта:
InventTrans.CostAmountAdjustment = sum(InventSettlement.CostAmountAdjustment)
(скорее всего, из-за того, что программисты вручную вмешивались в базу, не думая о целостности)
это нарушение лечится процедурой "проверка целостности данных компании".

если что-то другое - нужно смотреть.

================
возвращаясь к исходному вопросу:
"коряво были распределены накладные расходы на себестоимость этой номенклатуры и, как следствие, закрытие складов отработало не совсем так. Бухгалтер хочет их ... (списать на 20), но убрать корректно, чтобы потом нигде ничего не вылезло. Но как это сделать?"

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

добавлено:
3. если вам наплевать на фин.проводки, а волнует только корректность складского модуля, то просто добавьте записи в inventSettlement, привяжите их к какому-нибудь подходящему закрытию склада, и обновите поле InventTrans.CostAmountAdjustment (даже у закрытых проводок).
С точки зрения склада все будет корректно, но суммы в финансах и в складском модуле с этого момента будут безнадежно расходится.

добавлено 2:
4. если вас не пугает большой объем программинга и у вас проблема с закрытыми проводками, то разберитесь как выполняется коррекция (какие процедуры вызываются). И проэмулируйте все шаги этой коррекции в своей процедуре. Но помните, что стандартная коррекция выбирает только открытые проводки, а вам нужно только закрытые (НИКОГДА не обрабатывайте открытые и закрытые за один проход коррекции - у закрытых и у открытых гарантировано должны быть разные ваучеры и лоты).

[Apollon33]

вот откатывать закрытие очень не хотелось бы. слишком старые проводки - 2008 год.
попробовал исправить ситуацию через функционал "закрытие и коррекция". вроде как все отработало нормально, зависшая сумма убралась. когда делалал процедуру не ставил "галку" Обновление главной книги. Без нее, я так понимаю, система корректирует себестоимость, но не пишет корректирующую проводку. сейчас вот думаю, скажется ли это на корректности формирования других отчетов...

[mazzy]

Цитата:

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

...но не пишет корректирующую проводку в Главную книгу. сейчас вот думаю, скажется ли это на корректности формирования других отчетов...

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

[Apollon33]

Всем здравствуйте.
Хотелось бы вновь вернуться к этой теме, потому что проблема так и не разрешилась.
Была найдена еще одна причина (кроме указанной выше - корявое распределение накладных расходов), по которой могут зависать копейки. Это округление. У нас есть приходы и расходы по складу. При этом система округляет сумму до двух знаков. Вот и зависают копейки (с + или -). Вот конкретный пример:
Склад Номер партии Стоимость ед. Приход Расход Количество Себестоимость
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 80 3281,36
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 96 3937,63
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 64 2625,09
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 16 656,27
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 32 1312,54
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 16 656,27
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 48 1968,81
101 Зк-000325-ЛОТ0106727 41,02 Продано -999 -40975,92
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 16 656,27
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 16 656,27
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 32 1312,54
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 16 656,27
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 160 6562,71
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 160 6562,71
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 320 13125,43
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 160 6562,72
101 Зк-000325-ЛОТ0106727 41,02 Закуплено 320 13125,43
101 Зк-000325-ЛОТ0106727 41,02 Продано -553 -22682,39
0,01
Вот и хочется поинтересоваться у коллег консультантов \ разработчиков кто-то еще с подобным сталкивался и если да, то как решили эту проблему? Или Вы просто не показываете такие моменты в отчетах по складу?