Пересчет себестоимости отгрузок

[IvanHARD]

Подскажите, пожалуйста, какие проводки создаются при пересчете себестоимости продаж через "Закрытие и коррекция"?
При уменьшении себестоимости отгрузки я ожидал увидеть сторно , но, похоже, аксапта делает реверс. Так ли это? Можно ли изменить поведение системы?

[slava09]

Еще ниразу не видел "сторно" при пересчете склада!!! Однозначно: аксапта делает нормальные проводки по увеличению себестоимости и реверс проводки по уменьшению себестоимости. К сожалению, настроить "сторно" проводки я не знаю как, но подозреваю, что это не возможно.

[Андре]

Цитата:

К сожалению, настроить "сторно" проводки я не знаю как, но подозреваю, что это не возможно.

Без программирования - нет. Кстати, я так понимаю, мы говорим про проводки по ГК. Да и с программированием не уверен, что все будет просто, так как корректирующие проводки создают те же классы, что и обычные.

[IvanHARD]

т.е. при уменьшении себесетоимости отгрузки готовой продукции проводка Д43 К90 - норма, и добиться Д90 К43 с отрицательной суммой нельзя?

[slava09]

Без модификаций нельзя.

[ppson]

Цитата:

Изначально опубликовано IvanHARD
т.е. при уменьшении себесетоимости отгрузки готовой продукции проводка Д43 К90 - норма, и добиться Д90 К43 с отрицательной суммой нельзя?

Локализация такая .

[Peter Savintsev]

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

Для примера возьмем проводку списания материалов Д20 К10 на сумму 1000.

Как известно, сторнирующие проводки отличаются от обычных тем, что в поле Коррекция у них стоит Да (LedgerTrans.Correct = NoYes::Yes), а реверсированные - это проводки с обратной корреспонденцией. Для нащего примера сторнирующей проводкой будет Д20 К10 -1000, а реверсирующей Д10 К20 1000.

За создание проводок отвечают классы LedgerVoucher и LedgerVoucherObject. Последний при создание объекта прнимает параметр Correction, который и отвечает за то, будет ли проводка сторнирущей или реверсированной. Важное замечание: документ ГК может быть либо целиком сторно, либо целиком реверс. То есть ситуация, когда часть провдок в рамках одного документа ГК являются сторнирующими, а часть реверсированными, невозможна (в рамках стандартного функционала, естественно ). Чтобы убедится в этом, достаточно взглянуть на конструктор класса LedgerVoucherObject newVoucher, который принимает в качестве параметра помимо прочего документ ГК для проводки (_voucher) и признак сторно (_correction).

Теперь помотрим на механизм закрытия склада. При закрытии создается множество проводок с ОДНИМ документом ГК. За это отвечает класс InventAdjustPost и его метод updateNow. Поскольку используется один ваучер, то все его проводки будут либо сторно, либо, как в стандартном функционале, реверсом.

Вернемся к нашем примеру. Предположим теперь, что было списано два вида материалов. Возникли две проводки: Д20 К10 1000 и Д20 К10 500. В ходе закрытия склада система обнаружила, что себестоимость первого материала была на 100 руб. меньше, а второго - на 200 больше. Хотелось бы, чтобы при закрытии возникли две проводки: Д20 К10 -100 и Д20 К10 200. Однако, всвязи со всем вышесказанным, система не может сделать такие проводки в рамках одного документа ГК. Поэтому имеем Д10 К20 100 и Д20 К10 200. Если же слегка подправить метод InventAdjustPost.updateNow, то опять же получится лажа: Д20 К10 -100 и Д10 К20 -200.

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

[Peter Savintsev]

Цитата:

Изначально опубликовано ppson

Локализация такая .

Локализация тут не при чем. Механизм закрытия склада в плане создания проводок ГК в локализованной версии не менялся. Проблема тут гораздо глубже...

[jaran]

Также столкнулись с подобной проблемой.
В стандарном функционале никогда не пойдут развернутые обороты обороты по главной книге и складским проводкам.
Бухгалтерам часто необходимо посмотреть обороты по ГК и по номенклатурам, которые разносяться по соответствующим счетам ГК.
Увы...
Они не знаю, где верная цифра.
Другая ситуация - в главной книге создается под одним Voucher на одну дату, т.е. закрыте покрывает период 01/01/2004-31/01/2004
Обороты и сальдо по ГК за 01/01/2004-07/01/2004 будут не верными, а
01/01/2004-31/01/2004 - сальдо верное.

Как вариант - своя модификация по "дописыванию" проводки в ГК с тем же Voucher, что и в складской проводке.
Но много подводных камней. Например в какой момент запускать эту обработку. Есть большая вероятность, что коррекция по складским проводкам за закрытый период прошла полностью.

[Андре]

В случае, если вам нужно сторно не при закрытии склада а в журналах - все гораздо проще. Надо просто поправить код, где создается LedgerVoucherObject, передав туда параметр correct. Если выполнять сторно отдельным журналом - проблем не будет.

[Peter Savintsev]

В свете открытия, сделанного slava09 (см. http://www.axforum.info/forums/showt...&threadid=7761), модификация по созданию сторно-проводок при закрытии уже не кажется мне столь сложной (но не менее опасной!!!). Общая идея такая: заставить класс InventAdjustPost создавать проводка в две итерации. Сначала создаются проводки, которые должны быть не-сторно, затем, с таким же документом ГК, сторно-проводки. Основной проблемой тут, на мой взгляд, будет определение критерия того, какие записи из InventSettlement должны создавать прямые проводки, а какие сторно.

[bio_unit]

Цитата:

Изначально опубликовано Peter Savintsev
В свете открытия, сделанного slava09 (см. http://www.axforum.info/forums/showt...&threadid=7761), модификация по созданию сторно-проводок при закрытии уже не кажется мне столь сложной (но не менее опасной!!!). Общая идея такая: заставить класс InventAdjustPost создавать проводка в две итерации. Сначала создаются проводки, которые должны быть не-сторно, затем, с таким же документом ГК, сторно-проводки. Основной проблемой тут, на мой взгляд, будет определение критерия того, какие записи из InventSettlement должны создавать прямые проводки, а какие сторно.

Никаких проблем нет, нужно смотреть знак коррекции в InventSettlement и направление складкой проводки.
Двух итераций не надо можно и одной.

[Peter Savintsev]

Цитата:

Изначально опубликовано bio_unit


Никаких проблем нет, нужно смотреть знак коррекции в InventSettlement и направление складкой проводки.

Да, пожалуй, такой способ пойдет.

Цитата:

Изначально опубликовано bio_unit

Двух итераций не надо можно и одной.

Под двумя итерациями я подразумевал двухэтапную разноску с помощью LedgerVoucherObject, сначала с параметром _correction = NoYes::No, потом _correction = NoYes::Yes.

[Peter Savintsev]

Повторюсь, модификация опасная. Я бы не рекомендовал ее делать. Разве что если будут ОЧЕНЬ серьезные причины. Не исключено, что в следующих версиях Аксапты механизм закрытия склада перепишут и что будет тогда со всеми этими наворотами, неизвестно.

Сейчас подумал еще об одной тонкости - отмене закрытия. Как известно, при отмене создаются проводки ГК, сторнирующие проводки, возникшие при закрытии. Так вот как должны отменяться сторно-проводки закрытия при отмене, я что-то не могу пока сообразить.

[bio_unit]

Цитата:

Изначально опубликовано Peter Savintsev
Повторюсь, модификация опасная. Я бы не рекомендовал ее делать. Разве что если будут ОЧЕНЬ серьезные причины. Не исключено, что в следующих версиях Аксапты механизм закрытия склада перепишут и что будет тогда со всеми этими наворотами, неизвестно.

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

[konfet]

Цитата:

Сообщение от Peter Savintsev

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

Для примера возьмем проводку списания материалов Д20 К10 на сумму 1000.

Как известно, сторнирующие проводки отличаются от обычных тем, что в поле Коррекция у них стоит Да (LedgerTrans.Correct = NoYes::Yes), а реверсированные - это проводки с обратной корреспонденцией. Для нащего примера сторнирующей проводкой будет Д20 К10 -1000, а реверсирующей Д10 К20 1000.

За создание проводок отвечают классы LedgerVoucher и LedgerVoucherObject. Последний при создание объекта прнимает параметр Correction, который и отвечает за то, будет ли проводка сторнирущей или реверсированной. Важное замечание: документ ГК может быть либо целиком сторно, либо целиком реверс. То есть ситуация, когда часть провдок в рамках одного документа ГК являются сторнирующими, а часть реверсированными, невозможна (в рамках стандартного функционала, естественно ). Чтобы убедится в этом, достаточно взглянуть на конструктор класса LedgerVoucherObject newVoucher, который принимает в качестве параметра помимо прочего документ ГК для проводки (_voucher) и признак сторно (_correction).

ВОПРОС К НАРОДУ.
Ситуация со времен написания данного поста (2004 год) никак не изменилась? Имеем 3.0 SP4 с указанным в ветке поведением системы: при операции коррекции - закрытия склада, вместо создания сторно - система создает реверсивные проводки и, соответственно, плывут обороты по 20 счету и воют бухгалтера.
Было ли сие пофиксено в SP5 или, быть может, в каких-то дальнейших хотфиксах? Если нет - то может кто-нибудь добрый поделится рабочим решением проблемы в виде проектика?

[Raven Melancholic]

Цитата:

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

ВОПРОС К НАРОДУ.
Ситуация со времен написания данного поста (2004 год) никак не изменилась?

Нет, не изменилась. Более того, в DAX4 то же самое. Про DAX2009 сказать не могу (не видел). Проектик дать не могу (собственность фирмы, а не моя), но идея модификации следующая (правда InventAdjustPost не переписывали, а создали свой):

• в методе updateNow создаем не один, а два LedgerVoucher и LedgerVoucherObject - один с флагом корректировки correct, а другой !correct.
• в методах updateItem* (точнее у нас такой метод один, просто есть иерархия классов - свой класс для каждого типа) расширяем список полей группировки таким образом, чтобы понять направление проводки (приход или расход);
• ну и в updateTrans разбираемся какой из LedgerVoucher использовать (учитывая, что мы отказались от использования локализаторских извращений с mapSettlement, то для нас это все - вам же придется думать как их обрабатывать).

PS: еще одна деталь - желательно в InventTrans иметь поле, которое позволит определить, был ли при разноске кредит-ноты сторно или реверс.

[konopello]

Цитата:

За создание проводок отвечают классы LedgerVoucher и LedgerVoucherObject. Последний при создание объекта прнимает параметр Correction, который и отвечает за то, будет ли проводка сторнирущей или реверсированной. Важное замечание: документ ГК может быть либо целиком сторно, либо целиком реверс. То есть ситуация, когда часть провдок в рамках одного документа ГК являются сторнирующими, а часть реверсированными, невозможна (в рамках стандартного функционала, естественно ). Чтобы убедится в этом, достаточно взглянуть на конструктор класса LedgerVoucherObject newVoucher, который принимает в качестве параметра помимо прочего документ ГК для проводки (_voucher) и признак сторно (_correction).

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

Выполнял недавно модификацию, которая изменяет данную логику, и она мне далась довольно малой кровью. Была выполнена следующая модификация:

ledgerVoucherTransObject = LedgerVoucherTransObject::newCreateTrans(
                                                                    _ledgerVoucher.findLedgerVoucherObject(),
                                                                    this.postingBalanceSheet(),
                                                                    this.accountBalanceSheet(),
                                                                    this.dimension(),
                                                                    Companyinfo::standardCurrency(),
                                                                    costAmount,
                                                                    0);

                ledgerVoucherTransObject.parmCorrect(this.correctLedgerTransObject() ? this.correctLedgerTransObject() : ledgerVoucherTransObject.parmCorrect());

                _ledgerVoucher.addTrans(ledgerVoucherTransObject);

[fed]

мои пять копеек: Привязка признака сторнирования к всему ваучеру исчезла еще во времена версии 3.0. Теперь признак сторнирования можно привязывать к постингу (LedgerVoucherTransObject). Механизм корреспонденции не позволяет корреспондировать сторнирующую и обычную проводки (что логично). Теперь по смыслу задачи. Кусочек кода по понятным причинам тоже не могу привести Задача решается следующими шагами:
1. Добавляется признак сторнирования в шапку журналов
2. Добавляется признак сторнирования в строки журналов (инициализируется из шапки)
3. Метод inventJournalCheckPost.postLedgerTransправится таким образом, чтобы parmCorrect() у ledgerObjectVoucher инициализировался из признака сторнирования в строке журнала.
4. В inventTrans добавляется поле с признаком сторнирования. (Correct). Метод inventMovement.initInventTransFinancial() правится так, чтобы копировать в складскую проводку признак сторнирования из ledgerVoucherObject
5. В классе inventCostItemDim (или в таблице inventTrans) создается статический метод SetSettlementCorrect. Он заполняет в inventSettlement признак коррекции в том случае, если знак суммы положительный, а корректируемая складская проводка – списание или если знак суммы отрицательный, а корректируемая складская проводка – приход. При наличии в складской проводке признака сторнирования (из пункта 4) – логика инвертируется. При любых созданиях/обновлениях inventSettlement из кода закрытия/пересчета склада (класс inventCostItemDim) перед вызовом update/insert вызывался бы метод setSettlementCorrect.
6. Класс inventAdjustPost и его наследники правится так, чтобы группировать проводки еще и по признаку сторнирования (correct) из inventSettlement. При создании объекта ledgerVoucherTransObject - parmCorrect инициализируется из ключа mapSettlement.
7. После того как я все это сделал – выяснилось что у меня случилась засада входящими накладными расходами. Они тоже создаются как записи в inventSettlement и разносятся классом inventAdjustPost. Учитывая что в тех классах, которые создают inventSettlement по накладным расходам признак коррекции не заполняется, то при некоторых операциях (кажется при возврате накладной с накладными расходами или при вводе отрицательных накладных расходов) все разваливалось. Изначально - я глупо заткнул эту дырку, просто передавая в inventAdjustPost какой-то параметр, который приводил к тому что признак коррекции не подставлялся из inventSettlement, а брался из исходного ledgerVoucher. Несколько позже я эту дырку починил более правильным способом. Я нашел все классы в которых создается inventSettlement (InventTransAdjust и еще парочка кажется) и вставил туда код, который правильно выставляет поле сторнирования в inventSettlement.

[konfet]

Всем ответившим спасибо. Будем рыть.
То, что эта очевидная недоработка в локализации не была устранена российским Microsoft-ом в течении 4 лет - говорит о многом