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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.05.2010, 00:03   #21  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
Цитата:
Сообщение от Geo Посмотреть сообщение
Эммм... Разве правильно вообще пытаться что-то увидеть в складском движении в разрезе фин. аналитик?
Не в складском(InventTrans), а в финансовом движении(LedgerTrans), отражающем складское.

Цитата:
Сообщение от Geo Посмотреть сообщение
И второе. Надо ли выдумывать задачу сверки АХ с самой собой, при этом вынужденно прибегая к методу, который, в сущности, вообще не должен работать?
Надо.
Сравнение данных физического движения учетных сущностей и финансового отражения этих движений - одна из стандартных процедур финансового учета, являющаяся подтверждением достоверности оного. Чем больше пересекающихся по сути аналитических разрезов (не важно, как они в ГК реализованы - субсчетом или финаналитикой) в этих множествах данных - тем более детально и глубоко можно вести речь о степени достоверности учета. Это справедливо не только для AX.
__________________
Мы летаем, кружимся, нагоняем ужасы ...
Старый 13.05.2010, 06:42   #22  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Надо.
Сравнение данных физического движения учетных сущностей и финансового отражения этих движений - одна из стандартных процедур финансового учета, являющаяся подтверждением достоверности оного. Чем больше пересекающихся по сути аналитических разрезов (не важно, как они в ГК реализованы - субсчетом или финаналитикой) в этих множествах данных - тем более детально и глубоко можно вести речь о степени достоверности учета. Это справедливо не только для AX.
С другой стороны - если физические и финансовые движения учетных сущностей получены из одного и того же исходного документа с помощью одного и того же программного обеспечения, то какой смысл в этой выверке ? Если у нас баги в программе, то выверка нужна только на стадии запуска (пока не отладились); Если у нас пользователи могут данные руками удалять - то вообще грош цена такой учетной системе.
То есть - выверка несет ценность только в том случае, если один и тот же исходный документ проводится двумя разными сотрудниками и порождает два разных набора проводок (и финансовых и модульных). Может быть - в других системах что-то подобное есть, но в Аксапте я таких мест не вскидку не могу вспомнить. Можно конечно упомянуть о физических и финансовых складских движениях, но для того чтобы поймать закупки/продажи которые мы забыли отинвойсировать в конце периода, совсем не нужно тяжелых механизмов сверки. Вполне достаточно простенького отчета по inventTrans с комбинацией условий по datePhysical и statusIssue/statusReceipt. Да и не обязаны финансовые складские проводки всегда идти одним учетным периодом с физическими. Вполне возможно - что мы физически товар списали 31ым числом, а накладную оформили и выручку признали только в тот момент когда товар до точки консигнации доехал.
Старый 13.05.2010, 09:42   #23  
Bega is offline
Bega
Участник
Аватар для Bega
 
382 / 444 (15) +++++++
Регистрация: 18.08.2005
Адрес: Москва
Во-первых такая подробная сверка - это требования наших методологов от бухгалтерии.

Во-вторых, у нас сложный производственный учет, множество перемещений между производственными подразделениями, встречные движения, сторно, возвраты. Используется метод средневзвешенной цены. К сожалению, после закрытия склада довольно часто возникают отклонения, например, по переносу ушла одна сумма, а пришла другая. И проблема здесь не в наших модификациях, в логике закрытия системы есть несколько мест, где могут возникать отклонения за счет например, округлений.
Старый 13.05.2010, 10:55   #24  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Ну вот получилось расхождение из-за округлений - выявили это сверкой. Какие дальнейшие шаги? Переносить руками округления? Сторнировать? Что-то еще?
__________________
Ivanhoe as is..
Старый 13.05.2010, 10:56   #25  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
885 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
fed, багов нет, нет удалений - есть управляющие параметры (типа профилей разноски) с заранее неизвестной разной степенью детализации (от общего для всех до отдельного для каждой сущности), могущие в силу разных причин (в т.ч. ошибочных действий) меняться, что отрицательно сказывается на достоверности учета и что впоследствии придется отлавливать так или иначе.

P.S.Отсутствие функционального и хронологического разделения создания физических и финансовых движений по одному и то му же документу в подавляющем большинстве случаев - это не всегда и даже не совсем достоинство, ибо случаи, когда за эти движения отвечать должны разные люди из разных подразделений, совсем не редки. Функциональное разделение создания этих движений на разные сущности в системе, как это сделано в закупке/заказе (отборочная накладная и накладная), не есть выход - подобное должно совершаться в момент переключения между несколькими состояниями одного единого документа документа.
__________________
Мы летаем, кружимся, нагоняем ужасы ...

Последний раз редактировалось TasmanianDevil; 13.05.2010 в 11:02.
Старый 13.05.2010, 11:00   #26  
Bega is offline
Bega
Участник
Аватар для Bega
 
382 / 444 (15) +++++++
Регистрация: 18.08.2005
Адрес: Москва
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Ну вот получилось расхождение из-за округлений - выявили это сверкой. Какие дальнейшие шаги? Переносить руками округления? Сторнировать? Что-то еще?
Да, переносить руками.
Старый 13.05.2010, 11:07   #27  
Bega is offline
Bega
Участник
Аватар для Bega
 
382 / 444 (15) +++++++
Регистрация: 18.08.2005
Адрес: Москва
Сальдо в разрезе отделов в ОСВ по бух.счету по сумме должны совпадать с сальдо по ОСВ по ТМЦ. Нам еще постоянно приводят в пример 1С, в которой все всегда сходится - на части предприятий холдинга стоит 1С.

Ни у кого таких проблем нет в Аксапте? Или на небольшие расхождения просто не обращают внимания?
Старый 13.05.2010, 11:18   #28  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Bega Посмотреть сообщение
Сальдо в разрезе отделов в ОСВ по бух.счету по сумме должны совпадать с сальдо по ОСВ по ТМЦ. Нам еще постоянно приводят в пример 1С, в которой все всегда сходится - на части предприятий холдинга стоит 1С.

Ни у кого таких проблем нет в Аксапте? Или на небольшие расхождения просто не обращают внимания?
Проблемы есть. И я сам пару раз писал выверки подобные. Но на мой взгляд - потребность в выверках говорит о низкой степени культуры учета в бухгалтерском сообществе. Потому как трудозатраты на выверку (даже автоматизированную. Или тем более автоматизированную ?) в 99% случаев, ЗНАЧИТЕЛЬНО выше потенциальных штрафов за ошибки в бухучете.
Короге говоря - вопрос не об Аксапте, а вообще о методологическом обосновании такого понятия как выверка.

Последний раз редактировалось fed; 13.05.2010 в 11:22.
Старый 03.06.2010, 17:28   #29  
Geo is offline
Geo
Участник
Аватар для Geo
 
258 / 47 (2) +++
Регистрация: 04.04.2008
Цитата:
Сообщение от fed Посмотреть сообщение
Проблемы есть. И я сам пару раз писал выверки подобные. Но на мой взгляд - потребность в выверках говорит о низкой степени культуры учета в бухгалтерском сообществе. Потому как трудозатраты на выверку (даже автоматизированную. Или тем более автоматизированную ?) в 99% случаев, ЗНАЧИТЕЛЬНО выше потенциальных штрафов за ошибки в бухучете.
Короге говоря - вопрос не об Аксапте, а вообще о методологическом обосновании такого понятия как выверка.
+1
Однажды писали такую выверку, в Navision правда. Потребовалось, когда нашли косяк. Написали, запустили - "нашли" удаленные руками складские проводки. Исправили. Больше об использовании этого отчета я не слышал.

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

На мой взгляд, такая выверка стоит в одном ряду с требованиями печати точной себестоимости в расходных складских документах или создания отчета, который "подтвердит правильность расчета FIFO". А то и вообще с гипотетическим случаем ведения параллельно двух одинаковых баз, чтобы иметь возможность "сверять" их между собой...
Старый 03.06.2010, 17:43   #30  
Bega is offline
Bega
Участник
Аватар для Bega
 
382 / 444 (15) +++++++
Регистрация: 18.08.2005
Адрес: Москва
Речь, собственно шла не об отчете, а о функционале, который бы правильно перемещал суммы с одной фин.аналитики на другую в журналах переноса/заказах на перемещение. Под сверкой я имею в виду сравнение сальдо по бух.счетам в разрезе фин.аналитик с суммами в остатках в наличии. Это не значит, что абсолютно необходимо искать причины небольших расхождений, просто бухгалтеру нужно видеть эту разницу, чтобы вручную куда-нибудь распределить.
Старый 03.06.2010, 17:47   #31  
Geo is offline
Geo
Участник
Аватар для Geo
 
258 / 47 (2) +++
Регистрация: 04.04.2008
Вот, как мне кажется, похожая тема:
"Оборотно-сальдовая по номенклатуре. есть такой отчет???"
Оборотно-сальдовая по номенклатуре. есть такой отчет???
Старый 03.06.2010, 17:49   #32  
Geo is offline
Geo
Участник
Аватар для Geo
 
258 / 47 (2) +++
Регистрация: 04.04.2008
Цитата:
Сообщение от Bega Посмотреть сообщение
Речь, собственно шла не об отчете, а о функционале, который бы правильно перемещал суммы с одной фин.аналитики на другую в журналах переноса/заказах на перемещение. Под сверкой я имею в виду сравнение сальдо по бух.счетам в разрезе фин.аналитик с суммами в остатках в наличии. Это не значит, что абсолютно необходимо искать причины небольших расхождений, просто бухгалтеру нужно видеть эту разницу, чтобы вручную куда-нибудь распределить.
Я извиняюсь за непонимание, но зачем эту разницу, ежели она найдется, куда-то вручную распределять? В чем экономический смысл операции?
Старый 03.06.2010, 18:06   #33  
Bega is offline
Bega
Участник
Аватар для Bega
 
382 / 444 (15) +++++++
Регистрация: 18.08.2005
Адрес: Москва
Цитата:
Сообщение от Geo Посмотреть сообщение
Я извиняюсь за непонимание, но зачем эту разницу, ежели она найдется, куда-то вручную распределять? В чем экономический смысл операции?
Вот пример: есть цеха Цех1 и Цех2, в Аксапте они в виде складов, на обоих настроена разноска на 20-й счет, с разной фин.аналитикой "Отдел" (001, 002). Есть перемещения сырья из сырьевого склада в цеха (20<-10) и перемещения между цехами (20<-20). При закрытии месяца бухгалтеру нужно видеть сумму НЗП на остатках и ту же сумму НЗП в сальдо 20-го счета в разрезе фин.аналитик. Если есть разница, бухгалтер ее куда-нибудь "девает", чтобы в результате суммы равнялись. Смысл в том, что необходимо поддерживать соответствие между ГК и УЗ, хотя это и не экономический смысл.

Последний раз редактировалось Bega; 03.06.2010 в 18:09.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Наборы фин. аналитик sta[z] DAX: Функционал 1 13.05.2009 17:38
Проблемы с отображением скл. аналитик ZVV DAX: Администрирование 22 09.01.2009 20:11
Фин. аналитика в проводках поставщиков Morpheus DAX: Программирование 5 26.10.2007 15:17
Аксапта 4.0 - иерархия фин. аналитик. slava09 DAX: Функционал 12 04.07.2006 10:04
Ограничение на количество фин. аналитик sever DAX: Программирование 0 13.01.2004 08:03
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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