Цитата:
Изначально опубликовано =DeaD=
Хорошо, 1С-овскими терминами - типичная проблема с перепроведением базы и стронированием - есть документ "Приходная накладная" на товар А в кол-ве 10шт на склад №1 (где в тот момент уже есть 20шт товара А), есть два перемещения товара А на склады №2 и 3 по 15шт.
Хорошо. Есть эти документы.
По идее во время прихода надо включать контроль и разрбраковку. В Аксапте это называется обязательная регистрация и карантинный склад. Причем, в идеале, контроль и разбраковка должна выполняться как на основном складе, так и на складах-приемниках.
Обратите внимание! Не "есть документ", а был фактический приход. Т.е. было реальное событие, и это реальное событие отразили в системе. Отразили А и Б. Все. Все что знали то и записали.
Цитата:
Изначально опубликовано =DeaD=
Позже выясняется что это было поступление товара не А, а "А со штрихом". Так как склады 2 и 3 являются складами структурных подразделений мы не можем из подразделения закупок волевым решением определить кому пришел "ущербный" товар.
Как это не можетм?
Где физически лежит товар А? А где лежит товар "А со штрихом"?
Или вы опять заставили людей ввести в систему что-то чего никогда не было?
Цитата:
Изначально опубликовано =DeaD=
Поэтому по-хорошему нужно создать проект нового поступления товара, потом создать проекты новых перемещений между складами (если мы раскидываем плохой товар поровну), дождаться подтверждения их другими подразделениями и потом "провести" все стронирующие документы.
Конечно же нет! С чего это вы решили старую историю выкинуть, и переписать заново?
Регистрируется возврат товара А поставщику. Затем от поставщика регистрируется новый документ. Это если перепутал поставщик и в реале поставил не тот товар.
Если же перепутали кладовщики, то товар А списывается на убытки и из прибыли возникает товар "А'". Это обычная и штатная операция пересортицы. Она может выполняться отдельно, а может в рамках инвентаризации.
В результате вы видите, что один сотрудник зарегистрировал документ от поставщика, другой одобрил регистрацию на складе, а затем был возврат или пересортица за счет приыбли.
Т.е. что было в реале, так и надо отражать в системе.
Цитата:
Изначально опубликовано =DeaD=
Это только один пример, но он показывает в чем проблема - при внесении изменений в сделку (выпиской стронирующих документов) мы имеем несколько субъектов, которые должны "передоговориться" между собой, чтобы не допускать произвола или "некорректного состояния" данных (отрицательных остатков).
Вопрос собственно в том - есть ли что-то подобное в Аксапте или нет вообще, или это не часть методологии Аксапты, но в некоторых решениях сторонние компании это реализовывали?
Ага. Понятно.
Есть. Но механизм не является универсальным в Аксапте.
Механизм одобрения вкраплен в некоторые места, которые разработчики посчитали важными. Это одобрение финансовых журналов, подтверждение прихода и отгрузки товара (регистрация и комплектация). Подтверждение прихода работает и в случае перемещения со склада на склад.
Механизм одобрения является двухуровневым - один готовит второй одобряет. Многоуровневые одобрения есть только в управлении платежами.
Теперь что касается конкретно вашего вопроса. Скорее всего в Аксапте надо подходить к решению с другой стороны. Т.е. не разгребать вашу ситуацию, а настроить работу и Аксапту так, чтобы она не допускала таких возникновения таких ситуаций. Тогда из разряда ежедневных данная задача действительно перейдет в разряд нештатных.
Кстати, обратите внимание, что в Аксапте нет никаких средств, которые помогли бы задним числом обмануть систему.
