Учёт остатков в разрезе фин. аналитики

[miklenew]

Есть такая задача.
Разработать механизм учёта остатков в разрезе фин. аналитики (бизнес направление). Исключить возможность переноса складского остатка с фин. аналитики (бизнес направление) на остаток с другой фин. аналитикой (бизнес направление).
Возможные решения:
1) Разделить склады на более мелкие единицы в разрезе фин. аналитики (бизнес направление). Склад1_бн1, Склад1_бн2 и т.д. А в таблицу складов ввести эту фин аналитику.
2) Добавить складскую аналитику (бизнес направление) со значениями фин. аналитикой (бизнес направление).
3) Ввести фин. аналитику в inventSum. (Изменить стандартные механизмы, чтоб система отличала остатки с одинаковым InventDimId но с разной фин. аналитики (бизнес направление). Самый трудоёмкий и подводных камней уверен будет много.
4) Подбирать фин. аналитики (бизнес направление) при переносе остатков из проводок, образовавших этот остаток. С точки зрения архитектуры не правильно. Да и со скоростью не понятно, что в конце получиться.
--------------------------------
Уверен, что на разных проектах с подобной проблемой сталкивались не раз. Хотелось бы узнать какое на ваш взгляд самое правильное решение. И если уже делали выбор, то с какими подводными камнями в дальнейшем столкнулись. Если есть какие-то ещё мысли, даже если они не опробованы буду благодарен если поделитесь.

[slava09]

А почему нужно исключать возможность переноса остатков между направлениями?

[miklenew]

До конца не знаю.
Так звучит постановка задачи.
Знаю, что это как-то связано с распределением бюджетов. И то, что закуплено под одно направление не дожно продоваться другим направлением.

[YellowSubmarine]

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

ИИХО верен п.2. Он наименее трудоемок и требуется корежить стандартный функционал по минимуму по сравнению с остальными вариантами.

С уважением, Александр.

[miklenew]

Цитата:

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

Приходилось задумываться над подобной проблемой, хотя всегда удавалось убедить в нецелесообразности подобной задачи.
ИИХО верен п.2. Он наименее трудоемок и требуется корежить стандартный функционал по минимуму по сравнению с остальными вариантами.
С уважением, Александр.

Спасибо за совет.
Если помните причину отказа от данной задачи не могли бы написать.
Может мне тоже удастся её списать.

[glibs]

1) в общем случае похоронит шансы использования Аксаптовского WMS (если вы только физически не разделите складские площади).

2) IMHO, наименьшее зло. Если в лоб решать задачу.

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

[YellowSubmarine]

Цитата:

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

Спасибо за совет.
Если помните причину отказа от данной задачи не могли бы написать.
Может мне тоже удастся её списать.

Ну откудаже я помню... Я эти причины каждый день в таких количествах генерю...
Но логика такова:
1. Стандартная функциональность не поддерживает возможности вести остатки в разрезах финансовой аналитики.
2. Возможность доработки существует (см.п 2 в исходном посте).
3. Доработка изменяет десятка два системных классов, что чревато потенциальными ошибками, причем не все ошибки возможно поймать сразу ри тестировании и опытной эксплутации.
4. Ошибки не обнаруженные сразу сложны в исправлении (помним, что неправильно сделанные проводки сложны в исправлении) и как правило требуют написания нетривиальных джобов (и времени).
5. Бизнес готов идти на риски из п.5, чтобы таким образом изменить аксапту под себя?
6. Стандартная функциональность имеет функциональность компаний, что в данном случае и требуется применить. Почему бы не использовать функциональность компаний, а тратить неделю - другую на доработку? А эту неделю - другую потратить на что-то иное?

Вот как-то так. Добавьте вашей специфики и выкладывайте тому, кто к вам с этой задачей пришел.

С уважением, Александр.

[YellowSubmarine]

Цитата:

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

1) (недостача имеется в виду, а также всякого рода "уронил/поцарапал/сломал") без жребия не определить.

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

С уважением, Александр.

[Vals]

Цитата:

6. Стандартная функциональность имеет функциональность компаний, что в данном случае и требуется применить

Голосую за применение компаний.

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


Опять же, если рассматривать решение с компаниями, то нужно учесть особенности бюджетирования (настройки и реализацию наверняка придётся пересмотреть) и консолидации.

Хотя вариант с компаниями более перспективный.

Как дополнительные меры можно посоветовать обратить внимание на настройку проверки разноски по фин аналитике, также возможно для клиентов установить склады по умолчанию для БН и запретить редактировать в заказах и т.д.

[slava09]

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

[Atani]

У нас, в целом, сделано в соответствии с пунктом 2 (новая складская аналитика).

У нас используется логистический модуль; для управленческого учёта делаются многочисленные отчеты, выгрузки; все операции происходят в одной аксаптовской компании.

Первая складская аналитика - Склад
Вторая складская аналитика - Ячейка. В справочник Ячеек введено поле Фин. аналитика, и в нём Ячейки привязываются к БН-ам. Это сделано, поскольку на БН у нас отведено 2 фин. аналитики. Кроме того, может оказаться несколько Ячеек, привязанных к одному БН-у.

Некоторые результаты, кванты опыта:

1. У нас несколько физических складов, Ячейки заводятся по мере появления не представленного ранее владельца товара. Таким образом, количество ячеек стремится к X*Y (Количество складов, умноженное на количество БН-ов)

2. Остатки на складе делились между БН-ами и ложились на соответствующие ячейки. Шум баталий был слышен издалека, но это были разборки между БН, и в Аксапту попадал только результат этих разборок.

3. Старые Ячейки (остатки старой оргструктуры) - удалили. В результате пользователи стали изредка получать ошибки при оприходовании старых закупок и при возвратах по старым заказам: "На складе таком-то такой-то ячейки не существует".
В принципе, эти вещи можно было бы отследить до удаления, но хочу отметить сам факт наличия таких вопросов: "Что делать со старой оргструктурой?" и "Что делать со старыми заказами/ закупками/переносами и проч. историей в текущем периоде?".
Практически любые решения что-то делать у нас вели к job'ам произвольной сложности по перекодировке.

4. Модификации в основном коснулись складских отчетов, в которых добавилось поле БН

5. В целом, понадобилось примерно полгода, чтобы из Аксапты стали выводиться достаточно чистые данные, а также заработала вся бизнес-цепочка, связанная с разделением на БН-ы.
Уверен, результат появился бы гораздо раньше и проще, если бы все предварительные этапы у нас проводились _предварительно_. Т.е., новая оргструктура утверждена заранее, склад разделен заранее, перекодировки сделаны заранее и т.д. Если этого не сделать, велик риск после часа Х появиться грязным данным. Из фин. отдела слышны были недоуменные возгласы типа: "чей товар продан с ячейки 'общая'?" ну, и совершенно нетривиальной задачей оказалось определить остатки в разрезе БН на начало часа Х постфактум, если к тому моменту они ещё не были разделены, поскольку у складов своя кипучая жизнь с категориями, отличными от "БН".

Таков наш опыт, конструктивные комментарии приветствуются :-)

Вариант с разделением по компаниям мне тоже нравится, но мне видятся в нём и свои [возможные] недостатки:
1) Что делать, если на предприятии уже налажен учет по компаниям, скажем, по юр. лицам, которые как-то наискосок сочетаются с БН-ами ?

2) Деление товара по БН - виртуальное, и кладовщик вполне резонно хочет видеть все остатки в разрезе своего склада. А в случае деления с помощью компаний, на мой взгляд, фишка как раз в том, чтобы жестко разграничить видимость.

С уважением, Сергей

[miklenew]

Всем спасибо кто поделился своей точкой зрения.