Здравствуйте!
Постоянно возникает одна и та же проблема: приходуют материалы в запас проекта, далее выводят в свободный, счета-фактуры, доп. дебетования вносят когда уже нет запаса проекта, но есть свободный. Потом усугубляют это всё хаотичным сторнированием и переводами между запасами, чтобы уж наверняка нельзя было вернуться к моменту первой проводки переноса между запасами и только тогда обращаются за помощью.
Вопросы:
1. Бухгалтерия говорит, что их средствами сделать ничего нельзя, надо раскручивать логистическую цепочку и путём сторно-ввода документов как-то выходить на правильную оценку каждого из запасов. Так ли это? Или есть какие-нибудь инструменты?
2. Есть ли у кого-нибудь подобная ситуация и можно ли поставить какие-нибудь ограничения? Например, запретить ввод с/ф и доп. дебетования при отсутствии запаса? Или это будет искусственное раскладывание граблей для других процессов, где списание до счёта-фактуры является нормой?

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

К примеру, зачем запас из проекта переводится в свободный? Как приходят счета и тд

Толку, что вы что-то запретите, если через день бухгалтера будут кричать, что они не могут счет-фактуру ввести или еще чего

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

Вывод в свободный в рассматриваемом случае для продажи другой организации. Тут даже не совсем так, как я описал, вывод сделан после с/ф и всех ДД, проблемы начались после сторнирования. В этом процессе были документы: ПМ по цене заказа, с/ф, ДД от перевозчика, ДД ГТД, вывод в свободный, /*с этого момента ошибочные действия*/ сторно ДД 1, сторно ДД 2, сторно с/ф, (запаса нет, отклонения не уходят на материал), сторно вывода в свободный, сторно ПМ.

В итоге имеем на счёте отклонений какую-то сумму, появившуюся в результате сторно двух ДД. Разве бухгалтер не может её куда-нибудь отнести? В данном случае, наверное, к доходам от реализации, поскольку была реализация. Или не может, поскольку были разные виды запаса? Вопрос, конечно, не в MM, но всё же

грань тут ограничивается требованиями или фантазией



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



нупишите нормальную инструкцию, расскажите процесс. Вы все-равно не сможете обезопасить от ошибок или странностей пользователей. Сторно - нормальный процесс, но надо понимать когда и зачем его собственно делать
Ровно как и остальные процессы типа перемещений запаса. Они могут быть нужны для бизнеса.
Для ограничений надо понять логику - кому что и зачем ограничивать. Спсобов множество, начиная от банальных ролей, заканчивая Z проверками при необходимости

Закупили под конкретный проект, проект закончился, часть материалов/оборудования осталась невостребованной. Чтобы частично возместить убытки, невостребованные ТМЦ продаются.

Инструкции-то нормальные, всем рассказано что можно делать, чего нельзя, но, во-первых, только в этом процесса участвуют 4 сотрудника, действующих независимо: кладовщик, закупщик, инженер по логистике и бухгалтер. По-правильному бухгалтер должен руководить процессом и организовать сторно в нужном порядке, на деле бухгалтер не всегда ответственно подходит к этой роли, т.е. выдаёт команду "сторнировать всё" без уточнения кому и в каком порядке.

Ладно, это всё философия. Выяснил, например, что бухгалтерия может распределить счёт отклонений на МВЗ, заказ или СГ, это работает, если материал был списан на собственные нужды. Но вот может ли отнести отклонение на реализацию?

ок, нормальный рядовой процесс

В качестве оптимизации можно подумать о включении в проект продажу лишних материалов, подвязать план фактурирования...
но тут кончено много записит от ведения проектов



Ну проблема видится во внутренних коммуникациях и процедурах. Собственно их и надо оптимизировать в первую очередь. SAP - это не волшебная таблетка и не AI, котрый будет думать за бухгалтера и кладовщика