Существуют ли недостатки у Axapta

[mazzy]

Спасибо, TasmanianDevil

[George Nordic]

Ну! Так давай! Вот ветка, где можно обсудить все баги и кривизну Российской локализации:
Российская функциональность в Microsoft Axapta
Просто RecId и утечка памяти не локализованы т.е. с местных-то спросить нечего А вот насчет функционала - можно и поспорить, что и как было сделанно, и почему так, и как надо было правильно.

С Уважением,
Георгий.

[komar]

Это не всегда есть хорошая практика в некоторых системах, как я уже упоминал, открытие новых таблиц для новых периодах соответствует логике работы системы, но в Акзапте это не так. Такая практика в Акзапте, наверное, возможна, если:

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

[Garic]

А зачем это делать именно в новый год?
Что мешает закрыть период и после этого уже перейти, хотя конечно транзакции переносить не самое приятное занятие
Насчёт сравнительных отчётов. Ничего не мешает сделать InventTransBalances и т.п, наверно достаточно будет даже сводного за периоды.

[Pavel]

Цитата:

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

А зачем это делать именно в новый год?

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

Старая компания
- в течение первого квартала довводятся данные
- делается выверка/корректировка отчетного года
- закрывыется отчетный период, формируется фин.результат
- сдается отчетность

Кстати, проще с аудитом информации...

P.S. перед глазами живой пример с изменением ЕСН и одновременным расчетом з/п за новый период и корректировками/перерасчетами в прошлом году в одной базе/компании.

[Галина]

Цитата:

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

В жизни происходит следующее:
- вводишь входящие сальдо прошлого периода по мере их формирования

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

[Pavel]

Цитата:

Сообщение от Галина

А как быть с сальдо по клиентам , особенно учитывая, что если используется например -при выписки счета клиенту кредитный лимит? Текущие операции по клиентам-нужно уже заносить с учетом прошлой информации.

Если сальдо по клиенту выверено, то заводится в разбивке по открытым проводкам. "Заводится" - это выгрузить из базы/компании прошлого года, загрузить в журнал нового года, провести. В некоторых системах - стандартная функциональность.

Если все проводки открыты, значит сопоставление (применение) в системе не востребовано, следовательно, можно свернуть. В некоторых системах сверка проводок тоже вещь стандартная, однако требует внимания к валютным операциям и их переоценке.

[Тимур]

Цитата:

Сообщение от Галина

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

Что касается кредитного лимита, то все зависит от того, как часто он устанавливается и меняется. На практике я видел такую кредитную политику, по которой лимит одному клиенту мог изменяться каждые 2-3 недели. Пока готовились начальные остатки для переноса в новую систему, значения кредитных лимитов вводились в с учетом задолженности, сложившейся на данный момент без точной выверки расчетов (лаг несколько дней).

[Галина]

Т.е. чтобы сразу вводить текущие операции по клиентам (с учетом кредитного лимита)-нужно перенести до 05 января 2005 года (или когда клиент начнет вводить тек-операции)? А к 05 января да и 10 января-вряд ли сальдо будет выверено -хотя бы потому что банк еще не разнесен.

[komar]

Обсуждение российской локализации медленно расползается по форуму:

Российская функциональность в Microsoft Axapta

День Microsoft на Softool’04

[komar]

В продолжение - родилась ветка для распиливания функционала учета в различных стандартах
Трансляция и двухвалютный склад

ранее обсуждалась
Трансляция в Главной Книге

это чтобы не повторяться.

[komar]

Спасибо за информацию! Однако, прошу, по возможности, держаться в рамках темы - а именно обсуждения системы Axapta.

[Lazy_Tiger]

Господа, возвращаясь к нашим баранам.
ОЧЕНЬ ОЧЕНЬ ИНТЕРЕСНО, таки проблемы пересчета/закрытия склада Microsoft вообще собирается решать? Я тут почитал переписку своего партнера с MBS, датированную еще началом-серединой 2004 года на эту тему.
В результате спустя год (!!) вместо решения проблем, в SP4 появились заглушки и все. Кто тут говорил про "приоритетность" и все такое?
Хоть каждый день открывай запросы, толку ноль. Одни отмазки, запросы просто закрываются и все.

[Pavel]

Цитата:

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

В результате спустя год (!!) вместо решения проблем, в SP4 появились заглушки и все.

Не новый подход. Еще в 2001 году мы обсуждали на форуме вариант использования стандартной международной аксапты с российским меточным файлом как альтернативу корявой локализации.

[komar]

Цитата:

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

Господа, возвращаясь к нашим баранам.
ОЧЕНЬ ОЧЕНЬ ИНТЕРЕСНО, таки проблемы пересчета/закрытия склада Microsoft вообще собирается решать? Я тут почитал переписку своего партнера с MBS, датированную еще началом-серединой 2004 года на эту тему.
В результате спустя год (!!) вместо решения проблем, в SP4 появились заглушки и все. Кто тут говорил про "приоритетность" и все такое?
Хоть каждый день открывай запросы, толку ноль. Одни отмазки, запросы просто закрываются и все.

Насколько я понимаю (пусть меня поправят, если я неправ), но после создания механизма "многопользовательского" закрытия склада никаких других переделок не ожидается. А в какие проблемы вы уткнулись?

[Lazy_Tiger]

18.06.2004 12:45:00 GMT+03:00
1. Складская модель - средневзвешенная на дату
2. Складская аналитика - склад, финансовый склад включен.
3. 1-го числа приходуем 10 штук номенклатуры на склад "Основной" по 50 рублей за штуку (всего 500 рублей).
4. 2-го числа перемещаем 5 штук со склада "Основной" на склад "Магазин".
5. 3-го числа через заказ списываем 5 штук со склада "Магазин".
4. Затем проводим коррекцию приходной проводки на 300 рублей. Разносим ее 1-м числом.
5. 30-м числом месяца делаем пересчет себестоимости.
6. Видим, что у проводок по перемещению и заказу себестоимость стала 400 рублей (верная).
7. Затем закрываем склад раньшей, чем пересчет, датой. Например, 15-м числом. Видим, что в одной из половинок перемещения себестоимость 550 рублей вместо 400 рублей.


Ответ:
бла бла бла... "Указанная в этом Вашем запросе проблема решается комплексно вместе с некоторыми другими проблемами, связанными с пересчетом и закрытием склада, известными в версии Microsoft Axapta 3.0. Ожидается, что исправление для Microsoft Axapta 3.0 SP2 и SP3 будет опубликовано в январе-феврале 2005 года."

На дату ПЕРВОНАЧАЛЬНОГО запроса внимание обратите(!!!)

Состояние: в SP4 сделали залипучку. Не исправили, а именно залипучку сделали. Которая сводится к 1 оператору if()

[Recoilme]

Цитата:

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

18.06.2004 12:45:00 GMT+03:00
1. Складская модель - средневзвешенная на дату
2. Складская аналитика - склад, финансовый склад включен.
3. 1-го числа приходуем 10 штук номенклатуры на склад "Основной" по 50 рублей за штуку (всего 500 рублей).
4. 2-го числа перемещаем 5 штук со склада "Основной" на склад "Магазин".
5. 3-го числа через заказ списываем 5 штук со склада "Магазин".
4. Затем проводим коррекцию приходной проводки на 300 рублей. Разносим ее 1-м числом.
5. 30-м числом месяца делаем пересчет себестоимости.
6. Видим, что у проводок по перемещению и заказу себестоимость стала 400 рублей (верная).
7. Затем закрываем склад раньшей, чем пересчет, датой. Например, 15-м числом. Видим, что в одной из половинок перемещения себестоимость 550 рублей вместо 400 рублей.

1. Складская модель ФИФО (да не суть важно, у вас везде все глючит)
2. 1-го числа приходуем 10 штук номенклатуры на склад "Основной" по 50 рублей за штуку (всего 500 рублей).
3. 3-го числа через заказ списываем 5 штук со склада "Основной".
4. Делаем пересчет - видим в расходе 250 руб
5. Делаем коррекцию приходной проводки на 100 руб
6. Делаем пересчет
7. Открываем книгу, видим фигу
Внимание вопрос к ALEG
А майкрософт вообще тестирует свои программы??? Или каждый клиент должен наступить на эти грабли, детально разобраться в механизмах и понять что каждый предыдущий пересчет надо отменять перед послед-м пересчетом/закрытием?
Да в конце концов неужели нельзя просто свои qtysettled писать в соседнее поле, например, если уж Вы не можете без них не фига ничего посчитать?

[mazzy]

Lazy_Tiger, это исправили в международном SP4.
Видео с разъяснениями механизма расчета себестоимости

Цитата:

7. Затем закрываем склад раньшей, чем пересчет, датой

Анекдот:
Купили русские мужики японскую бензопилу. Решили опробовать.
Подсунули доску:
- Вжик, - сказала японская бензопила
- О! - сказали русские мужики.
Подсунули бревно:
- Вжик, - сказала японская бензопила
- О! - сказали русские мужики.
Подсунули железный лом
- Кряк, - сказала японская бензопила
- Э-э-э! - разочаровано махнули рукой русские мужики.

Вообще говоря, рекомендуют отменять пересчеты, которые сделаны ПОСЛЕ даты закрытия... Там еще остались траблы с подчиненными производственными и wms заказами... Насколько я помню... В общем, текущее закрытие должно быть последним.

[Lazy_Tiger]

Цитата:

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

Lazy_Tiger, это исправили в международном SP4.
Видео с разъяснениями механизма расчета себестоимости
Вообще говоря, рекомендуют отменять пересчеты, которые сделаны ПОСЛЕ даты закрытия... Там еще остались траблы с подчиненными производственными и wms заказами... Насколько я помню... В общем, текущее закрытие должно быть последним.

0) в SP4 - не исправили. А поставили залипуху, включив дурочку. При этом судя по переписке в течении года имели все ж совсем другие планы.

1) По поводу отменять - цитату из документации плииз. Она ж у нас первоисточником является?

2) А что делать если себестоимость нормальную хочется иметь не спустя 2 месяца? А то ведь и пересчет и закрытие и самое смешное - ОТМЕНА пересчета и закрытия это операции отнюдь не на 15 минут, а все ж таки на 6-8 часов минимум. А если я полный пересчет запущу за месяц, так она и за 2 суток не посчитает, хоть заоптимизируйся, увы.

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

P.S. Ни производственных, ни WMS-заказов у меня нет.
P.P.S. Отнюдь не обязательно считать по средней как выяснилось, это просто пример такой.

[mazzy]

Цитата:

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

Сергей, ты знаешь другой способ получить корректный 41 счет? Так что пример про пилу он как бы не к месту нифига.

Ясно. Извини, что вмешался. Я думал, ты решение ищешь...

ОК.
Да-да... Майкрософт маздай... Пошел за попкорном.