26.02.2006, 19:59 | #61 |
Участник
|
Цитата:
Сообщение от Сисой
Не совсем так. В 1С есть два режима проведения расходных документов, один из которых делает примерно то же, что и Аксапта, но тормозит не по децки при большом кол-ве документов. И есть второй режим, когда "раскрутка" партий и расчет себестоимости производится регламентно, в конце периода. Вот его-то и использовали во время тестов. В принципе, это корректно, т.к. на больших внедрениях УПП именно этот режим и используют. Но сравнение с Аксаптой в данном случае 1С проигрывает.
Регламентный расчет себестоимости можно делать каждый день и тогда можно получить среднюю себестоимость на дату, правильно? Является ли такой вариант работы приемлимым для сколько нибудь значительного числа фирм? |
|
26.02.2006, 19:59 | #62 |
Участник
|
Цитата:
Сообщение от brahma
А если расход делается не задним числом, то расчет себестоимости производится по правильному алгоритму или тоже по средней на дату?
Штатными средствами только по средней на дату. Цитата:
Сообщение от brahma
Получается, что при корректировке себестоимости корректируются и финансовые и складские проводки?
Цитата:
Сообщение от brahma
Если я правильно понял, то расчет себестоимости в режиме проведения документа есть некоторый компромис между точностью и производительностью системы? Точная себестоимость будет получена после закрытия склада?
|
|
26.02.2006, 20:04 | #63 |
Участник
|
Цитата:
Сообщение от brahma
Регламентный расчет себестоимости можно делать каждый день и тогда можно получить среднюю себестоимость на дату, правильно? Является ли такой вариант работы приемлимым для сколько нибудь значительного числа фирм?
Если делать именно таким образом, то коррекции при закрытии будут очень небольшими. А само закрытие будет выполняться очень быстро. Проблемы возникают у тех, кто полностью игнорирует принципы работы штатного механизма, а закрывать начинает чере полгода-год после начала работы. Тогда закрытие действительно может выполняться несколько суток. Тогда приходится выкручиваться, занимаясь различными ухищрениями. Если регламентные процедуры закрытия выполнять регулярно (хотя бы раз в месяц, а лучше раз в неделю), то и себестоимость будет достаточно точной, и быстродействие хорошим. |
|
26.02.2006, 20:09 | #64 |
Участник
|
Средняя себестоимость на дату считается на начало даты или на конец? Влияют ли уже сделанные проводки на среднюю себестоимость?
|
|
26.02.2006, 20:11 | #65 |
Участник
|
Цитата:
Сообщение от brahma
Средняя себестоимость на дату считается на начало даты или на конец? Влияют ли уже сделанные проводки на среднюю себестоимость?
Что значит "уже сделанные проводки"? Это значит "уже сделанные коррекции"? Если я понимаю правильно, то влияют. |
|
26.02.2006, 20:23 | #66 |
Участник
|
Цитата:
Сообщение от mazzy
Что значит "уже сделанные проводки"? Это значит "уже сделанные коррекции"?
Если я понимаю правильно, то влияют. |
|
26.02.2006, 20:29 | #67 |
Участник
|
Возвращаясь к УПП.
Получается, что реализовать такой режим работы в УПП должно быть довольно просто, но разработчики не делают этого? Получается что практически все компоненты для данного решения есть. Регламентная процедура пересчета себестоимости, алгоритм расчета по средней. |
|
26.02.2006, 20:58 | #68 |
злыдень
|
Цитата:
Сообщение от brahma
А для MS SQL есть русскоязычная документация? Вроде MSDN не переводится на русский язык. Да и утилиты к серверу не локализованы.
Я думаю, что 1С будет поставлять скомпилированную сборку вместе со своим продуктом. Так что это не проблема. А какие проблемы с администрированием? Можете дать ссылку на описание этих проблем? Есть результаты тестов независимых экспертов? Дайте пожалуйста ссылку на эту информацию. Проще наверное было бы на Sybase. Вы уверены, что будут продавать PostgreSQL? Откуда сведения? А под что он оптимизирован? 2. Естественно будет 3. www.sql.ru например. Бывают СУБД требующие минимум администрирования (ms sql, firebird, interbase), а бывают нет. Постгри не из первых 4. Да. Есть. Я не доверяю "официальным источникам". У меня есть скрипты и результаты TPC-R тестов для ряда СУБД сделанных автором СУБД Yaffil. Ему по барабану. Опираюсь на них. Ссылки в открытых источниках нет. Могу прислать если интересно. 5. Уверен. Вчера пиво с Нуралиевым пили . Вы всегда такие вопросы задаете? Другого логического объяснения я не нашел. Время покажет. 6. Unix. Зайдите в интернет наконец, я Вам не поисковый робот! Цитата:
Первая версия была выпущена в 1989 году, затем последовало еще несколько переписываний системы правил (rule system). Отметим, что коды Ingres и Postgres не имели ничего общего ! В POSTGRES была реализована поддержка таких типов как многомерные массивы, что уже шло в противоречие с реляционной моделью, timetravel - хранение версионности объектов (впоследствии, в версии 6.3 этот тип был удален, так как его поддержка требовала больших усилий, а версионность могла быть реализована на стороне приложения с помощью триггеров). В 1992 году была образована компания Illustra, а сам проект был закрыт в 1993 году выпуcком версии 4.2. Однако, несмотря на официальное закрытие проекта, открытый код и BSD лицензия сподвигли выпускников Беркли Andrew Yu и Jolly Chen в 1994 году взяться за его дальнейшее развитие. В 1995 году они заменили язык запросов POSTQUEL на общепринятый SQL, проект получил название Postgres95, изменилась нумерация версий, был создан веб сайт проекта и появились много новых пользователей (среди которых был и автор).
http://sai.msu.su/~megera/postgres/t...ostgresql.html В многоплатформенных СУБД есть такое понятие в "платформозависимая оптимизация ". Если по русски - критические алгоритмы переписываются на ассемблере х86. В постгри они не переписаны. Вобщем если хотите дальше разбираться - пользуйтесь поиском, я устал тут подборки ссылок организовывать... Тесты и скрипты вышлю если надо.
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ Последний раз редактировалось Recoilme; 26.02.2006 в 21:01. |
|
26.02.2006, 21:19 | #69 |
Участник
|
Цитата:
Сообщение от brahma
Если я правильно понял, то расчет себестоимости в режиме проведения документа есть некоторый компромис между точностью и производительностью системы? Точная себестоимость будет получена после закрытия склада?
1С использует крайние случаи: 1. Списать себестоимость максимально точно по выбранной учетной политике. 2. Вообще не определять себестоимость на уровне проводок до закрытия периода. Аксапта использует компромиссный метод. Тем не менее, 1С на практике позволяет контролировать маржинальный доход в течение месяца, используя систему цен номенклатуры (прайсов), часть из которых может автоматически обновляться по данным закупок (т.е. храним последнюю цену поставщика). |
|
26.02.2006, 21:33 | #70 |
Участник
|
Цитата:
Сообщение от Recoilme
1. Да. Навалом. Вы давно не были в книжных магазинах. Когда зайдете - сравните
Цитата:
Сообщение от Recoilme
3. www.sql.ru например. Бывают СУБД требующие минимум администрирования (ms sql, firebird, interbase), а бывают нет. Постгри не из первых
Цитата:
Сообщение от Recoilme
4. Да. Есть. Я не доверяю "официальным источникам". У меня есть скрипты и результаты TPC-R тестов для ряда СУБД сделанных автором СУБД Yaffil. Ему по барабану. Опираюсь на них. Ссылки в открытых источниках нет. Могу прислать если интересно.
Цитата:
Сообщение от Recoilme
5. Уверен. Вчера пиво с Нуралиевым пили . Вы всегда такие вопросы задаете? Другого логического объяснения я не нашел. Время покажет.
Цитата:
Сообщение от Recoilme
6. Unix. Зайдите в интернет наконец, я Вам не поисковый робот!
|
|
26.02.2006, 21:48 | #71 |
Участник
|
Цитата:
Сообщение от brahma
Регламентный расчет себестоимости можно делать каждый день и тогда можно получить среднюю себестоимость на дату, правильно? Является ли такой вариант работы приемлимым для сколько нибудь значительного числа фирм?
|
|
26.02.2006, 22:42 | #72 |
Участник
|
Цитата:
Сообщение от Сисой
1С на практике позволяет контролировать маржинальный доход в течение месяца, используя систему цен номенклатуры (прайсов), часть из которых может автоматически обновляться по данным закупок (т.е. храним последнюю цену поставщика).
|
|
26.02.2006, 23:35 | #73 |
Участник
|
Цитата:
Сообщение от mazzy
Это есть и в Аксапте, и в Навижине.
|
|
27.02.2006, 00:02 | #74 |
Участник
|
Цитата:
Сообщение от brahma
А чем этот подход хуже оценки средней на дату?
Чем обновление цены продажи хуже алгоритма списания себестоимости по средней на дату? Вообще говоря, это совершенно разные вещи. |
|
27.02.2006, 00:17 | #75 |
Участник
|
Цитата:
Сообщение от mazzy
Раз уж зашла речь о новостях с семинара
Вот, например, http://1c.realnet.ru/forum/f?ak=26223 В частности, http://1c.realnet.ru/forum/f?ak=26205#25 почти цитата из сказанного на семинаре. |
|
27.02.2006, 09:30 | #76 |
Модератор
|
2 brahma: mazzy меня уже опередил. А Recoilme, судя по всему, расстроен тем, что, если бы стояла цель действительно оптимизировать быстродействие, то 1С оптимизировала бы платформу под SQL2005 или Oracle.
Я не прав? С Уважением, Георгий |
|
27.02.2006, 10:56 | #77 |
злыдень
|
Цитата:
Сообщение от George Nordic
2 brahma: mazzy меня уже опередил. А Recoilme, судя по всему, расстроен тем, что, если бы стояла цель действительно оптимизировать быстродействие, то 1С оптимизировала бы платформу под SQL2005 или Oracle.
Я не прав? С Уважением, Георгий Я расстроен тем что выбрали уродского слона вместо птички (firebird). По всем показателям это должен был быть он. Этот выбор дал бы офигительной толчок к развитию данной СУБД. А оптимальным по быстродействию для баз данных 1с (1-10 гиг) - был бы MySql, а не монстры. Но мускул платный для коммерческого использования. Если бы выбрали firebird - сиквел 90% юзверей нафиг не уперся бы. Учитывая его распространенность, надежность, отсутствие администрирования, запуск на 486 машинах, версионность, развитие, быстродействие, мультиплатформенность и т.д. Вобщем 1С в своем репертуаре... ну и фиг с ними
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
27.02.2006, 11:38 | #78 |
Участник
|
Цитата:
Сообщение от George Nordic
А Recoilme, судя по всему, расстроен тем, что, если бы стояла цель действительно оптимизировать быстродействие, то 1С оптимизировала бы платформу под SQL2005 или Oracle.
Я не прав? Может быть использование PostgreSQL преследовало другую цель? Например, предоставить дешевое решение для мелких и средних фирм, которым не нужно быстродействие SQL2005 или Oracle, так как у них достаточно маленькие объемы данных, но уже не хватает файлового варианта. На самом деле, как мне кажется, таких фирм достаточно много. Если посмотреть по сайту 1С, то основная масса внедрений это 10-30 работающих. |
|
27.02.2006, 11:40 | #79 |
Участник
|
Цитата:
Сообщение от Recoilme
Нет
Я расстроен тем что выбрали уродского слона вместо птички (firebird). По всем показателям это должен был быть он. Этот выбор дал бы офигительной толчок к развитию данной СУБД. Вобщем 1С в своем репертуаре... ну и фиг с ними |
|
27.02.2006, 11:56 | #80 |
Участник
|
Цитата:
Сообщение от Recoilme
Я расстроен тем что выбрали уродского слона вместо птички (firebird).
Вобщем 1С в своем репертуаре... ну и фиг с ними Вообще-то интересно проследить за мыслями разработчиков 1С. Я думаю, после выхода беты мы узнаем, почему было сделано так. |
|
Теги |
1c, сравнение систем, axapta |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|