Скл.аналитика сайт, перенос и фин.аналитик

[TasmanianDevil]

Цитата:

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

Эммм... Разве правильно вообще пытаться что-то увидеть в складском движении в разрезе фин. аналитик?

Не в складском(InventTrans), а в финансовом движении(LedgerTrans), отражающем складское.

Цитата:

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

И второе. Надо ли выдумывать задачу сверки АХ с самой собой, при этом вынужденно прибегая к методу, который, в сущности, вообще не должен работать?

Надо.
Сравнение данных физического движения учетных сущностей и финансового отражения этих движений - одна из стандартных процедур финансового учета, являющаяся подтверждением достоверности оного. Чем больше пересекающихся по сути аналитических разрезов (не важно, как они в ГК реализованы - субсчетом или финаналитикой) в этих множествах данных - тем более детально и глубоко можно вести речь о степени достоверности учета. Это справедливо не только для AX.

[fed]

Цитата:

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

Надо.
Сравнение данных физического движения учетных сущностей и финансового отражения этих движений - одна из стандартных процедур финансового учета, являющаяся подтверждением достоверности оного. Чем больше пересекающихся по сути аналитических разрезов (не важно, как они в ГК реализованы - субсчетом или финаналитикой) в этих множествах данных - тем более детально и глубоко можно вести речь о степени достоверности учета. Это справедливо не только для AX.

С другой стороны - если физические и финансовые движения учетных сущностей получены из одного и того же исходного документа с помощью одного и того же программного обеспечения, то какой смысл в этой выверке ? Если у нас баги в программе, то выверка нужна только на стадии запуска (пока не отладились); Если у нас пользователи могут данные руками удалять - то вообще грош цена такой учетной системе.
То есть - выверка несет ценность только в том случае, если один и тот же исходный документ проводится двумя разными сотрудниками и порождает два разных набора проводок (и финансовых и модульных). Может быть - в других системах что-то подобное есть, но в Аксапте я таких мест не вскидку не могу вспомнить. Можно конечно упомянуть о физических и финансовых складских движениях, но для того чтобы поймать закупки/продажи которые мы забыли отинвойсировать в конце периода, совсем не нужно тяжелых механизмов сверки. Вполне достаточно простенького отчета по inventTrans с комбинацией условий по datePhysical и statusIssue/statusReceipt. Да и не обязаны финансовые складские проводки всегда идти одним учетным периодом с физическими. Вполне возможно - что мы физически товар списали 31ым числом, а накладную оформили и выручку признали только в тот момент когда товар до точки консигнации доехал.

[Bega]

Во-первых такая подробная сверка - это требования наших методологов от бухгалтерии.

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

[Ivanhoe]

Ну вот получилось расхождение из-за округлений - выявили это сверкой. Какие дальнейшие шаги? Переносить руками округления? Сторнировать? Что-то еще?

[TasmanianDevil]

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

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

[Bega]

Цитата:

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

Ну вот получилось расхождение из-за округлений - выявили это сверкой. Какие дальнейшие шаги? Переносить руками округления? Сторнировать? Что-то еще?

Да, переносить руками.

[Bega]

Сальдо в разрезе отделов в ОСВ по бух.счету по сумме должны совпадать с сальдо по ОСВ по ТМЦ. Нам еще постоянно приводят в пример 1С, в которой все всегда сходится - на части предприятий холдинга стоит 1С.

Ни у кого таких проблем нет в Аксапте? Или на небольшие расхождения просто не обращают внимания?

[fed]

Цитата:

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

Сальдо в разрезе отделов в ОСВ по бух.счету по сумме должны совпадать с сальдо по ОСВ по ТМЦ. Нам еще постоянно приводят в пример 1С, в которой все всегда сходится - на части предприятий холдинга стоит 1С.

Ни у кого таких проблем нет в Аксапте? Или на небольшие расхождения просто не обращают внимания?

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

[Geo]

Цитата:

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

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

+1
Однажды писали такую выверку, в Navision правда. Потребовалось, когда нашли косяк. Написали, запустили - "нашли" удаленные руками складские проводки. Исправили. Больше об использовании этого отчета я не слышал.

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

На мой взгляд, такая выверка стоит в одном ряду с требованиями печати точной себестоимости в расходных складских документах или создания отчета, который "подтвердит правильность расчета FIFO". А то и вообще с гипотетическим случаем ведения параллельно двух одинаковых баз, чтобы иметь возможность "сверять" их между собой...

[Bega]

Речь, собственно шла не об отчете, а о функционале, который бы правильно перемещал суммы с одной фин.аналитики на другую в журналах переноса/заказах на перемещение. Под сверкой я имею в виду сравнение сальдо по бух.счетам в разрезе фин.аналитик с суммами в остатках в наличии. Это не значит, что абсолютно необходимо искать причины небольших расхождений, просто бухгалтеру нужно видеть эту разницу, чтобы вручную куда-нибудь распределить.

[Geo]

Вот, как мне кажется, похожая тема:
"Оборотно-сальдовая по номенклатуре. есть такой отчет???"
Оборотно-сальдовая по номенклатуре. есть такой отчет???

[Geo]

Цитата:

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

Речь, собственно шла не об отчете, а о функционале, который бы правильно перемещал суммы с одной фин.аналитики на другую в журналах переноса/заказах на перемещение. Под сверкой я имею в виду сравнение сальдо по бух.счетам в разрезе фин.аналитик с суммами в остатках в наличии. Это не значит, что абсолютно необходимо искать причины небольших расхождений, просто бухгалтеру нужно видеть эту разницу, чтобы вручную куда-нибудь распределить.

Я извиняюсь за непонимание, но зачем эту разницу, ежели она найдется, куда-то вручную распределять? В чем экономический смысл операции?

[Bega]

Цитата:

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

Я извиняюсь за непонимание, но зачем эту разницу, ежели она найдется, куда-то вручную распределять? В чем экономический смысл операции?

Вот пример: есть цеха Цех1 и Цех2, в Аксапте они в виде складов, на обоих настроена разноска на 20-й счет, с разной фин.аналитикой "Отдел" (001, 002). Есть перемещения сырья из сырьевого склада в цеха (20<-10) и перемещения между цехами (20<-20). При закрытии месяца бухгалтеру нужно видеть сумму НЗП на остатках и ту же сумму НЗП в сальдо 20-го счета в разрезе фин.аналитик. Если есть разница, бухгалтер ее куда-нибудь "девает", чтобы в результате суммы равнялись. Смысл в том, что необходимо поддерживать соответствие между ГК и УЗ, хотя это и не экономический смысл.