А можно реанимировать тему? Чем дело-то закончилось?
У меня похожая задача. Переходим на стандартную себестоимость со средней. Аналитика одна - склад. Финансовой не была, но очевидно, что при стандартной себестоимости все аналитики могут рассматриваться как финансовые. Нормального выхода из ситуации придумать не удалось. Наилучшие результаты дает переоценка всех (то есть вообще всех, включая уже закрытые) приходов по одной себестоимости (например, стандартной) и пересчет. Но остаются ошибки округления, добавленные средней, и как от них избавиться - непонятно.
Добавлю свои 5 копеек.
Цитата:
Сообщение от
mazzy
Хм... Мысль интересная.
Т.е. предложение такое:
1. включить галочку финансовый учет по партиям в аналитиках.
2. на дату Х по каждой номенклатуре, каждому складу и по каждой партии оприходовать единицу номенклатуры по какой себестоимости (например 1000 рублей или указанная в справочнике номенклатуры цена на складе или...)
3. на дату Х по каждому складу и по каждой партии списать единицу принятого товара
4. Закрыть на дату Х.
Не сработает, к сожалению. Проводки по списанию будут сопоставлены с той самой приходной проводкой, которую мы сделали на шаге 2. То, что было раньше закрыто, никак этим затронуто не будет.
Цитата:
Сообщение от
fed
Вообще - наиболее методологически верным было бы, наверное, сделать функциональность отмены закрытия склада отдельной датой (то есть - не датой закрытия, а произвольной). Технически это, кстати не очень трудно. Достаточно подправить дату в классе inventAdj_cancel и у отмененного/отменяющего сопоставления не ставить признак canceled в таблице складских сопоставлений. Тогда можно было бы отменить все старые закрытия текурщим месяцем.
Потом, правда, пришлось бы еще и курочить само закрытие таким образом, чтобы в нем дата создаваемого сопоставления и проводки в ГК была бы отделена от последней даты закрываемого периода. Тогда можно было бы перезакрыть старые периоды текущим месяцем.
Интересный вариант. Но ведь отмена закрытия не создаст новых сопоставлений. Соответственно, сумма по сопоставлениям не будет равна CostAmountAdjustment в проводке. Не будет ли в связи с этим проблем?