Показать сообщение отдельно
Старый 27.12.2005, 22:47   #26  
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
RecId в Динамиксе будет 64-битный в рамках таблицы. Примерно как komar писал по поводу Скалы. Читайте "Layman’s Specification".

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

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

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

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

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

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

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

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

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

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

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

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

Про привязку складов (хотябы) к счетам ГК помолчу лучше.
__________________
С уважением,
glibs®