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

[Голова 2уха]

7. реверс, а не сторно в складских журналах
8. включение НДС в стоимость материалов - вручную с большой трудоемкостью. Раньше еще была проблема с обработкой неоплаченного НДС в этом случае, но эта проблема после нового года отпадет сама собой
9. включение накладных расходов в стоимость материалов (например, когда нужно распределить отдельную накладную на несколько закупок)
10. закрытие периода и распределение затрат
11. товары отгруженные
12. ....

[mazzy]

Цитата:

Сообщение от Голова 2уха

7. реверс, а не сторно в складских журналах

Почитайте. Были обсуждения.
С точки зрения кладовщика сейчас есть две операции - приход на склад и расход со склада. Приход в ячейку и расход из ячейки. Это логично.

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

Ребяты, пожалуйста, думайте.
Ваши желания могут исполняться. Вы этого не боитесь?

Цитата:

Сообщение от Голова 2уха

9. включение накладных расходов в стоимость материалов (например, когда нужно распределить отдельную накладную на несколько закупок)

Мать! ФАК: http://forum.mazzy.ru/index.php?showtopic=1403

Цитата:

Сообщение от Голова 2уха

10. закрытие периода и распределение затрат

Сейчас придет Pavel и толково объяснит почему в Аксапте этот модуль "отсутствует" и вообще не развивается.
Будет новый в 4.0.

Цитата:

Сообщение от Голова 2уха

11. товары отгруженные

что имеется в виду?

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

[Голова 2уха]

Цитата:

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

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

ничем она не заполнена, нужно просто исправить ошибку. корректирующие проводки в Аксапте есть, но это реверс.

[komar]

--распределение накладных, выставленных отдельным счетом
--связь списания РБП с их начислением
--связь русских "догворов" с международными "контрактами"

--George Nordic, неужели Вы и вправду будете что-то делать с этими граблями?

[mazzy]

Цитата:

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

--распределение накладных, выставленных отдельным счетом

И тебе ФАК. Ссылка в предыдущем сообщении.

Цитата:

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

--связь русских "догворов" с международными "контрактами"

Я бы сформулировал задачу по-другому.
Полный отказ от русских договоров. Возврат к контрактам.
Доделать связь оплат с контрактами, связь оплат со счетами на оплату.

Но это нереально. Судя по последним постановлениям партии и правительства...

[komar]

Цитата:

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

И тебе ФАК. Ссылка в предыдущем сообщении.

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

[mazzy]

Цитата:

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

Пропорционально физическим параметрам поставки. С возможностью их регистрировать отдельным счетом. ФАК я читал - я же его и перевожу на нерусский

1. Спасибо, что переводишь.
2. Тогда я нифига не понял чего именно ты хочешь.

[komar]

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

[mazzy]

Цитата:

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

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

А подумать?
операция 1, 01.01.2006 - товар1 (коньяк), расход 10 шт, склад1, ячейка1
операция 2, 05.01.2006 - товар2 (туалетная бумага), приход 7 шт, склад 1, ячейка 1
операция ?, 10.01.2006 - хотим исправить операцию 1, поскольку перепутали товар, надо было выдать со склада 2 совсем другой товар.

Итак, расхода реально не происходило?
Да, конечно. Реально товар 1 давно своровали (выпили). А ячейку давно заполнили другим товаром.

Что дальше? Делать сторно только на том основании, что "расхода реально не происходило"?

Ребяты, еще раз!
Пожалуйста. Думайте. Очень-очень прошу.

В Аксапте масса неудобных и действительно нелогичных вещей.
Но почему-то народ в первую очередь просит делать ее еще более нелогичной...

[Голова 2уха]

Цитата:

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

Что дальше? Делать сторно только на том основании, что "расхода реально не происходило"?

Ребяты, еще раз!
Пожалуйста. Думайте. Очень-очень прошу.

никто не мешает сделать сторно и отразить недостачу, например.

[glibs]

Цитата:

Сообщение от Голова 2уха

никто не мешает сделать сторно и отразить недостачу, например.

Вот тут не согласен тоже.

Давайте разберемся сначала со следующим. На основании какого первичного документа вы в учете регистрируете "сторно" по складу?

[glibs]

RecId в Динамиксе будет 64-битный в рамках таблицы. Примерно как komar писал по поводу Скалы. Читайте "Layman’s Specification".

Насчет утечек памяти... ну гадость наприятная. Но сейчас можно работать с ax32.exe от сп3, который работает весьма неплохо. Подождем сп5, там посмотрим.

С функционалом (включая баги... а точнее даже желание их править) действительно ж...

Лирическое отступление. Если кто-то захочет возразить, что Микрософт имеет очень огромное желание исправить баги (ну, примерно как я могу иметь желание стать... пусть будет богаче Била Гейтса), то меня это не интересует. Конец лирического отступления.

Сторно по складу — действительно вещь спорная. Откуда у вас берутся ошибки? Вы операции на основании первичных документов заводите или как? Если вы неправильно указали ячейку, например, то можно редактированием складской аналитики ситуацию поправить. Если количество меньше, то сделайте еще один документ. А больше у вас не должно быть возможности указать, т.к. до того, как один головотяп что-то неглядя разнесет, второй должен это скомплектовать (а без этого ничего не должно разноситься).

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

Теперь еще несколько реальных недостатков.

Ну, отсутствие переоценки банковского счета это так... совсем ерунда. Раньше обещали сделать в 4.0, но согласно исходных обещаний мы уже на ней года полтора "работаем". А переоценки нет. И это при том, что серьезный разработчик такую вещь максимум за 4 часа осилит. Да здравствует соответствие Аксапты ПБУ в полном объеме! И еще каким-то практикам бухучета.

Реальная проблема есть с исправлнеием ошибок в накладных. Например, если мы ошиблись в цене, то исправить ошибку можно только породив еще минимум 2 складские проводки. Это серьезно мешает разбираться что вообще происходит на складе несчастному складу. Если оформлять такие переделки документами и одобрять на складе, склад просто скопытится. Как правило, это делают без его ведома. И хорошо, если не ошибаются с датой и количеством. Я, конечно, понимаю, что есть проблема себестоимости и связи книжки операций по клиентам с ГК через вакучер, но слишком уж много проблем такое упрощение работы разработчикам доставляет пользователям.

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

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

Этот список можно продолжать и продолжать. И не раз это на данном форуме делалось. И не два. И не три. И даже не тридцать три... И каждый раз после этого следуют реплики типа "ну вот опять все ворчат без конкретики... где факты?". Как будто все и впрямь от нефиг делать ворчат или прямо дураки какие-то. Как-то тоже уже начинают надоедать эти провокации. Пользуйтесь поиском, господа! (см. п. 2.5 правил).

PS. Прочитал я "Layman’s Specification". И несколько раз просканировал... Ну, и где же SCM? Где цепочки поставок? Где учет товаров в пути? Где распределение расходов на доставку и включение их в себестоимость? Ну где хотябы накладные расходы на внутреннее перемещение?

Про привязку складов (хотябы) к счетам ГК помолчу лучше.

[komar]

Цитата:

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

Ну, и где же SCM? Где цепочки поставок? Где учет товаров в пути? Где распределение расходов на доставку и включение их в себестоимость? Ну где хотябы накладные расходы на внутреннее перемещение?

Во! Это ответ mazzy на вопрос, что я хочу. Накладные расходы на доставку хочу. Хотя бы.

[mazzy]

Цитата:

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

Во! Это ответ mazzy на вопрос, что я хочу. Накладные расходы на доставку хочу. Хотя бы.

Вы с глебом хотите разные вещи.
Глеб хочет дополнительных статусов.
Действительно, сейчас есть статус заказано у поставщика и зарегистрирован физический приход.
Между этими статусами нет ничего. Что сильно затрудняет отслеживание товаров в пути.
И связанные с этим вещи.

Накладные расходы на доставку в Аксапте есть.
Накладные расходы на доставку можно регистрировать при любом статусе прихода. Даже после окончательного финансового прихода. И любые накладные расходы повлияют на себестоимость не только оприходованного, но и уже проданного товара.

[komar]

Цитата:

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

Накладные расходы на доставку в Аксапте есть.
Накладные расходы на доставку можно регистрировать при любом статусе прихода. Даже после окончательного финансового прихода. И любые накладные расходы повлияют на себестоимость не только оприходованного, но и уже проданного товара.

Регистрировать их отдельным счетом нельзя. Распределять на несколько разных накладных по разным (!) заказам тоже не очень-то получится. Это не накладные расходы, это очередной глюк переводчиков - markup - есть надбавки, и отсюда и все их ограничения.

[mazzy]

Цитата:

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

Регистрировать их отдельным счетом нельзя.

Можно. Ссылку на ФАК я уже давал.

Цитата:

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

Распределять на несколько разных накладных по разным (!) заказам тоже не очень-то получится.

О, да. С этим согласен.
Действительно постоянно приходится добавлять в алгоритм распределения условие по нескольким заказам. После чего распределяет на насколько заказов. Действительно - неаккуратненько

komar, ты забываешь о контрактах...
Ладно, ок... зачем убавлять пункт? пусть правят.

komar, только одно... ты сейчас говоришь совершенно не о том, что действительно надо править.
сказал бы о структуре себестоимости.
сказал бы о ГТД и о том, что ее обязательно надо вводить на стадии физического прихода, хотя о ней мы узнаем только на стадии финансового прихода...
сказал бы о сопоставлении в разных валютах.
сказал бы о том, что вторичная валюта существует только в ГК.

В общем, повторюсь: проблем в Аксапте - вагон и маленькая тележка.
Но почему-то хотелки даже у... из области бантиков... Действительно, в коде жестко прописано условие - распределять по одному заказу... Елы палы! Какая досада!

[Тимур]

Собственно мнение по данному документу было изложено больше года назад.
День Microsoft на Softool’04

[komar]

Цитата:

Сообщение от Тимур

Собственно мнение по данному документу было изложено больше года назад.
День Microsoft на Softool’04

Хороший, кстати, список. До сих пор актуален в каждом пункте.

[Голова 2уха]

1. Причем здесь ведение поставщики и клиенты на одном счете. Раздельное ведение авансов тоже не при чем. Все счета расчетов являются активно-пассивными, за исключением авансов выданных и полученных.
Ну хорошо, сделаю я субсчета 71Д - активный для выдачи денег подотчетнику, 71К - для отражения использования подотчетных сумм. Может быть и перерасход сумм, выданных в подотчет, и неполное использование - т.е. счет активно-пассивный. Ну буду видеть я раздельные сальдо по счета 71Д и 71К, но на каком подотчетнике какие остатки - аксапта при расчете сальдо по счету не учитывает. Т.е. если не проведено сопоставление хотя бы по одному подотчетнику, правильное сальдо даже при таком подходе по 71 счету я не увижу. Если вести подотчетников как обычно, на одном счете отражать и выдачу, и погашение, то я просто не вижу сальдо по этому счету! Потому что Аксапта его не рассчитывает, а смешивает операции по разным подотчетным лицам.

Из-за чего сыр-бор? модификация на два дня - например добавить в российские фин. отчеты дополнительный тип расчета - сальдо с учетом контрагентов. Больше никакие модули Аксапты в данном случае не затрагиваются

2. Если свалить накладные расходы на отдельный счет, в конце месяца мы списываем расходы на те же счета, на которые было списание материалов. Комбинаций счетов и аналитик, на которые шло списание, может быть несколько сотен. Еще как правило, списывается не весь остаток накладных расходов, а только часть, относящаяся к израсходованным материалам. Так что можно получить траблу создания большого количества проводок и расчета сумм для них. Не знаю как остальные, но я делала для специальную форму и модификацию. С накладными расходами по товарам немного проще.
Ах, ну да, забыла, аналитический учет ведь можно не вести

3. по поводу модуля ОС.
ну так, по мелочи, по фиче практически в каждой операции.
Закупка - мелкая фича с округлениями по закупке ОС (когда закупается несколько ОС, общая первоначальная стоимость из-за округления не всегда совпадет с закупочной стоимостью), бага с суммовой.
Ввод в эксплутацию - фича со списанием только с того склада, на которое ОС закупалось. Не приходилось править, патаму что пока никто не вел ячеистый склад и соответственно не перемещал ОС.
Амортизация - "забыли" про неамортизируемые ОС. Вывернуться можно, но непонятно, что делать потом с налоговыми разницами. Видимо, лапами, хорошо, если таких ОС мало.
Декларируется возможность вести учет ОС по МСФО, но например МСФО предписывают пересмотр метода амортизации и срока службы в случае необходимости, а в аксапте поменять амортизационную группу и метод низя.
Инвентаризация - недостающие ОС списываются, а не отражается недостача. Можно конечно при инвентаризации поменять профиль, не считая что сама инвентаризация может идти несколько месяцев, и за это время ОС могут и просто выбывать.
Переоценка - не соответствует ПБУ, не учитывает результаты предыдущих переоценок, слава богу, мало кто этой операцией пользуется. Операция опять же есть в МСФО и опять же им не соответствует (там тоже учитываются результаты предыдущих переоценок).
Выбытие - не хранится история по НДС, если ОС учитывается с НДС. А при выбытии это должно быть учтено.
Есть НМА, но нет первичных форм для НМА (НМА-1).
Перемещение - фича с тем, кто счет амортизации поменять можно, а аналитику (автоматом) низя (например, может быть нужно в налоговом учете).
Привязка счета амортизации к местоположению мне тоже не очень нравится, оно же (местоположение) выводится в печатные документы по ОС.
Нет учета оборудования к монтажу (и первичной документации по нему).
Нет ОКОФ (шифры аналитического учета - это скорее нормы, действовавшие до 2002г).
Можно еще набрать.

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

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

[ppson]

Цитата:

Сообщение от Голова 2уха

13. по поводу модуля ОС.
ну так, по мелочи, по фиче практически в каждой операции.

Ну можно добавить, что по учету ОС:
2) не отслеживаются сумма процентов по кредитам (займам) связанные с приобретением ОС, которые в налоговом учете отражаются как внереализацонные расходы
3) Не отследить в налоговых регистрах ОС разницы, когда расходы включаются в стоимость ОС по бухгалтерскому учету, а в налоговом учете вообще исключаются из состава расходов (например командировочные сверх лимита, страхование персонала и т.д.).
4) Не остлеживаются постоянные разницы по тем ОС, которые находились в запасе, и не были введены в эксплутацию. По бухучету такие ОС амортизируются, по налоговому - нет.

5) Нет настройки разноски по уменьшению стоимости ОС в результате переоценки, которое больше чем произведенные ранее увеличению стоимости ОС.
6) Полностью самортизированные основные средство нельзя продать.
7) Сторнирование закупок/заказов ОС.