[quot skidoo84]Понятно что делается Прочей транзакцией, только как система понимает что необходимо отсторнировать ТМЦ именно по стоимости , которая была сформирована при отгрузке? [quot skidoo84]

Делается прочей транзакцией посредством проставления себестоимости операции вручную. Себестоимость берется из журнала транзакций (складских операций) по той операции, которая сторнируется. Для удобства можно добавить ОГП с указанием кода сторнируемой складской транзакции (сделать запрос для списка).Если указывать себестоимость не вручную, то можно попробовать средствами персонализации возвращать себестоимость операции посредством связи со сторнируемой операции через ОПГ.

skidoo84Спасибо, понял. Т.е. в любом случае доработка.

Доработка если операцию делать удобной. А на первых порах можно просто брать сумму списания из складских транзакций и ставить «руками» в строку прочей транзакции.

Да и еще: желательно предусмотреть поле – причина корректировки (со справочником). Иначе потом не докопаетесь, по какой причине была проведена корректировочная операция и была ли действительно корректировка или реальная операция. Бухгалтерия еще и отчет в дальнейшем может потребовать по проведенным корректировкам за период, так, что уточняйте задачу.

UrriНарод, у человека ж не просто расход, а перемещение!
Делается обратное перемещение, а никакие не прочие транзакции.
Или я чего-то недопонял?

Если это сторно неверного сделанного перемещения, то при обратном перемещении необходимая себестоимость не подтянется. Да и при обратном перемещении бухгалтерской справкой не отделаешься, придется документально оформлять или в системе просто путаница будет. А прочей транзакцией и удобно и быстро и можно в ОПГ забить признак сторно.

Искандер ДвурогийЗабавно. В большинстве систем гораздо более нижнего уровня подобная функциональность есть (даже в 1С), а гордые разработчики OEBS подобной фигней не заморачиваются. Они тоже индусы?

Архитектура старая – еще конца 80-х. Легче новую систему написать, чем грамотно все переделать. При нынешних временах и модульности как таковой с выгрузками быть не должно, да и подходы к организацию системы другие. Как никак, а 20 лет для крупных систем и их идеологии уже порог. В те времена задача ставилась примерно так - как делался GAAP (РСБУ и т.д.) вручную, так мы его и автоматизируем. Поэтому и отдельные модули (оборочки, журналы, журналы ордена, главные книги), поэтому проблемы с получением оборотов, поэтому проблемы с интеграцией разных областей и прозрачностью процессов. У нас в первой половине 90-х такие же модульные системы писались с Главной книгой в виде отдельных АРМ-ов с выгрузками между модулями и т.д. (пример: Финэко, Бест и т.д).
Те, кто будут писать и пишут сейчас учитывают положительный и отрицательный опыт предыдущих поколений и там таких проблем нет.

Почему? Там отличия в том, что есть плановая цена позиции, которая рассчитывается специальным запросом в CM. Если до запуска программы корректировочная операция будет содержать сумм =0, если после то плановую цену, проставленную в транзакции источнике программой СМ. В чем-то аналог при средневзвешенной за период.