AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.11.2007, 18:16   #1  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Учёт остатков в разрезе фин. аналитики
Есть такая задача.
Разработать механизм учёта остатков в разрезе фин. аналитики (бизнес направление). Исключить возможность переноса складского остатка с фин. аналитики (бизнес направление) на остаток с другой фин. аналитикой (бизнес направление).
Возможные решения:
1) Разделить склады на более мелкие единицы в разрезе фин. аналитики (бизнес направление). Склад1_бн1, Склад1_бн2 и т.д. А в таблицу складов ввести эту фин аналитику.
2) Добавить складскую аналитику (бизнес направление) со значениями фин. аналитикой (бизнес направление).
3) Ввести фин. аналитику в inventSum. (Изменить стандартные механизмы, чтоб система отличала остатки с одинаковым InventDimId но с разной фин. аналитики (бизнес направление). Самый трудоёмкий и подводных камней уверен будет много.
4) Подбирать фин. аналитики (бизнес направление) при переносе остатков из проводок, образовавших этот остаток. С точки зрения архитектуры не правильно. Да и со скоростью не понятно, что в конце получиться.
--------------------------------
Уверен, что на разных проектах с подобной проблемой сталкивались не раз. Хотелось бы узнать какое на ваш взгляд самое правильное решение. И если уже делали выбор, то с какими подводными камнями в дальнейшем столкнулись. Если есть какие-то ещё мысли, даже если они не опробованы буду благодарен если поделитесь.
Старый 05.11.2007, 18:52   #2  
slava09 is offline
slava09
Участник
Аватар для slava09
MCBMSS
Дети Юза
1C
 
1,642 / 237 (11) ++++++
Регистрация: 06.03.2003
Адрес: Украина, Киев
А почему нужно исключать возможность переноса остатков между направлениями?
__________________
С уважением Шатохин Святослав.
Старый 05.11.2007, 19:23   #3  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
До конца не знаю.
Так звучит постановка задачи.
Знаю, что это как-то связано с распределением бюджетов. И то, что закуплено под одно направление не дожно продоваться другим направлением.
Старый 05.11.2007, 19:49   #4  
YellowSubmarine is offline
YellowSubmarine
Участник
 
111 / 12 (1) ++
Регистрация: 18.12.2002
Приходилось задумываться над подобной проблемой, хотя всегда удавалось убедить в нецелесообразности подобной задачи.

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

С уважением, Александр.
За это сообщение автора поблагодарили: miklenew (1).
Старый 05.11.2007, 20:08   #5  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Цитата:
Сообщение от YellowSubmarine Посмотреть сообщение
Приходилось задумываться над подобной проблемой, хотя всегда удавалось убедить в нецелесообразности подобной задачи.
ИИХО верен п.2. Он наименее трудоемок и требуется корежить стандартный функционал по минимуму по сравнению с остальными вариантами.
С уважением, Александр.
Спасибо за совет.
Если помните причину отказа от данной задачи не могли бы написать.
Может мне тоже удастся её списать.
Старый 05.11.2007, 21:07   #6  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
1) в общем случае похоронит шансы использования Аксаптовского WMS (если вы только физически не разделите складские площади).

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

В случае с 1) вас ждет решение задачи с выяснением того, чей товар потеряли. Дело в том, что товар разной принадлежности физически (на вид, на ощупь и на вкус) абсолютно одинаковый. Различие только в учете. И если его не становится, то чей именно товар пропал (недостача имеется в виду, а также всякого рода "уронил/поцарапал/сломал") без жребия не определить.
__________________
С уважением,
glibs®
За это сообщение автора поблагодарили: miklenew (1).
Старый 05.11.2007, 21:15   #7  
YellowSubmarine is offline
YellowSubmarine
Участник
 
111 / 12 (1) ++
Регистрация: 18.12.2002
Цитата:
Сообщение от miklenew Посмотреть сообщение
Спасибо за совет.
Если помните причину отказа от данной задачи не могли бы написать.
Может мне тоже удастся её списать.
Ну откудаже я помню... Я эти причины каждый день в таких количествах генерю...
Но логика такова:
1. Стандартная функциональность не поддерживает возможности вести остатки в разрезах финансовой аналитики.
2. Возможность доработки существует (см.п 2 в исходном посте).
3. Доработка изменяет десятка два системных классов, что чревато потенциальными ошибками, причем не все ошибки возможно поймать сразу ри тестировании и опытной эксплутации.
4. Ошибки не обнаруженные сразу сложны в исправлении (помним, что неправильно сделанные проводки сложны в исправлении) и как правило требуют написания нетривиальных джобов (и времени).
5. Бизнес готов идти на риски из п.5, чтобы таким образом изменить аксапту под себя?
6. Стандартная функциональность имеет функциональность компаний, что в данном случае и требуется применить. Почему бы не использовать функциональность компаний, а тратить неделю - другую на доработку? А эту неделю - другую потратить на что-то иное?

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

С уважением, Александр.
Старый 05.11.2007, 21:18   #8  
YellowSubmarine is offline
YellowSubmarine
Участник
 
111 / 12 (1) ++
Регистрация: 18.12.2002
Цитата:
Сообщение от glibs Посмотреть сообщение
1) (недостача имеется в виду, а также всякого рода "уронил/поцарапал/сломал") без жребия не определить.
не проблема. Если вдруг одинаковый товар имеет разную себестоимость, то теряется самый дешевый
Если одинаковая себестоимость - то все равно, можно жребий кидать, можно по-очереди.

С уважением, Александр.
Старый 06.11.2007, 00:26   #9  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,765 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
6. Стандартная функциональность имеет функциональность компаний, что в данном случае и требуется применить
Голосую за применение компаний.

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


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

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

Как дополнительные меры можно посоветовать обратить внимание на настройку проверки разноски по фин аналитике, также возможно для клиентов установить склады по умолчанию для БН и запретить редактировать в заказах и т.д.
Старый 06.11.2007, 11:19   #10  
slava09 is offline
slava09
Участник
Аватар для slava09
MCBMSS
Дети Юза
1C
 
1,642 / 237 (11) ++++++
Регистрация: 06.03.2003
Адрес: Украина, Киев
Как решить задачу "нельзя продавать товар закупленный для другого бизнеса" если вы (вдруг) физически не отличаете один товар от другого?
Т.е. вопрос в том, насколько товары разных бизнес-направлений пересекаются?
Если это 10-20 позиций, то почему бы не "разрезать" товары по бизнес-направлениям и пользователям каждого бизнес-направления дать доступ на уровне записи только к его товарам, например. Ну это как еще вариант для рассмотрения.
__________________
С уважением Шатохин Святослав.
За это сообщение автора поблагодарили: miklenew (1).
Старый 06.11.2007, 14:26   #11  
Atani is offline
Atani
Участник
 
77 / 15 (1) ++
Регистрация: 25.07.2003
Адрес: г. Королёв М.О.
У нас, в целом, сделано в соответствии с пунктом 2 (новая складская аналитика).

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

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

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

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

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

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

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

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

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

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

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

С уважением, Сергей
За это сообщение автора поблагодарили: petr (1), miklenew (2).
Старый 06.11.2007, 20:01   #12  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Всем спасибо кто поделился своей точкой зрения.
Теги
как правильно, остатки, финансовая аналитика

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Активация номенклатурной аналитики - перенос остатков Storaenso DAX: Функционал 12 10.02.2009 14:40
Как избавиться от отрицательных фин. остатков номенклатуры? Julietta DAX: Функционал 6 23.01.2009 10:19
Сравнение в разрезе складской аналитики. longson DAX: Программирование 3 14.01.2008 13:45
Обязательность заполнения фин.аналитики в 4.0 Atar DAX: Функционал 4 13.12.2007 19:10
Допустимо ли так использовать фин. аналитики kosenkov DAX: Функционал 5 26.02.2006 18:17
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 19:00.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.