Enot5467,

Если в конкретную конфу, да еще и на движке Торговли - прямая запись самое оно ;) Я и сам так у себя сделал, правда 5 лет - это, конечно, перебор. Вместе с изучением структуры Торговли ушло чуть больше месяца. :) Для Бухгалтерий же прямая запись, особенно извне - действительно кактус. При желании, конечно, можно и в бухдвижек напрямую писать, но... бухам обновили релиз, появился новый счет\субконто\перечисление и... начинаем есть кактус заново :)
C дургой стороны, если у вас оперативный\управленческий учет в другой программе, для чего тогда нужна Торговля? Только если это какая-то часть КИС, дополняющая штатную Торговлю, функционал которой проблематично реализовать в той же 1С. Но наличие многокомпонентных КИС с разнородными и несостыкованными модулями - показатель, что пора задуматься о собственом ИТ отделе. Или, если он есть, о разумности его содержания в том составе, который привел к появлению мышек, основные функции которых - поедание кактусов :) Хотя я тоже знаю у нас конторы, в которых есть должности типа "оператор обмена 1С" - причем доведено до такого безо всяких "прямых записей", штатный УРИБ, базы dbf, никаких изысков... просто баз очень много и разных... Ну и соответственно есть "ревизионный отдел", который разгребает косяки учета товаров, допущенных в результате косяков обмена. :)

Enot5467,

Продавливать железом неповоротливость 1Ски - это само собой :) На сотню рабочих мест восемь серваков разной степени крутости - видел такое :) Как бы еще объяснить то, что при переходе на новую систему, в которой дублируется функционал преждней системы, добавляется еще куча функционала, из которого остро востребован только один модуль, и под все это удовольствие требуется два новых сервака общей стоимостью под $3000? Это не считая полугодового срока внедрения, на два порядка большей стоимости лицензий и опять таки дописки отсутствующего функционала самостоятельно потом, или согласие на растягивание внедрения еще на полгода...

Enot5467Может и так, может и не поворотливая по сравнению с другими системами. Только тут надо выбирать (по моему мнению) немного другой уровень абстракции. Ведь рассуждаю о возможностях СКЛ сереверов и ОЛАП кубов, мы же не вспоминаем какой-нибудь ассемблер или голый С, хотя на них обработка данных будет еще быстрее. (кажется я опять в лирику ухожу) Просто встает вопрос: зачем делать сложнее, дороже и не понятней, при этом по скорости не быстрее?
В том то и дело, что на порядки быстрее. Рассуждения о возможностях SQL и OLAP - это не про 1С, она не использует эти возможности. Дело даже не в абстракциях, с этим 1Су как раз большой плюс за создание инструментов разработки под более высокий уровень абстракций. Дело как раз в том, как эти абстракции чисто технически реализованы.
Enot5467
К тому же я не видел еще ни одного собственника, которому интересно как сервера устроены. Скорее собственник деньги будет считать, нежели нюансы админства/программирования.
Как вы тогда объясняете то, что многие собственники по мере роста предпочитают отказываться от услуг франча и брать собственного 1Сника?
Как вы объясните огромное количество переписанных, написанных с нуля и просто "изнасилованных" конфигураций только лишь для того, чтобы не покупать по новому серваку каждый год?
Enot5467
А еще бухов жалко после таких "писателей", когда вместо 15 минутного обновления они видят несколько дней экспериментов. При чем постоянно что-то не работает...
Полностью согласен с вами. "Тот кто тронет конфу бухучета, тот в ней и погибнет!" :)
Интеграция с БУ и НУ должна быть такой, чтобы возможность обмена данными не требовала модификаций бухгалтерских конфигураций. Онлайновый обмен для бухов не нужен, скорость работы тоже. Возможностей платформы вполне достаточно реализовать какой угодно вариант загрузки данных.
Enot5467
Хороший пример с калькулятором: садясь за рабочее место, мы же не задумываемся как реализована логика логического ИЛИ, или какой ток идет с солнечной батарее. Другими словами калькулятор это черный ящик с кнопками. Ни у кого даже в мыслях не возникает припаять туда датчик и измерять шаги. Так же и с 1С: все что снаружи (кнопки т.е.) это можно делать в конфигураторе, а то что внутри, скорее всего будет лишним.
Что делать, если вечером на калькуляторе можно посчитать не более десятка сложений в минуту? Если для того, чтобы выполнять на нем сотню сложений требуется подставлять его под 100-ватную лампочку? а для умножения - под две? Особенно когда деньги на лампочки у вас уже есть, а на покупку калькулятора на батарейках еще нет?

Enot5467Егоров Александр,

Хорошо, оно все так и есть, я не против прочих технологий, т.к. сам постоянно 1С скрещиваю со всякими СКЛ-ми, вёрдами и прочим, что попадается. А еще программирую на ассемблере немного. Но при этом даже в мыслях не было переписать что-то СКЛ-ное, хотя там багов не мало. Взять тот-же контроль стека после каждого чиха, это же такая просадка в производительности. Или выделение памяти... когда для каждого модуля куча перевыделений, хотя соседние операции занимают практически одно и то же место.
Смысл в том, что для чего система делается, там и применяется.
Ни разу не сталкивался с желанием что-то изменить в движке того же mssql :) Как-то вот всегда устраивала его скорость работы и требовательность к ресусрам. Речь идет не о мелкой шлифовки багов (которые есть в каждой сложной системе, и их наличие не зависит от языка, на котором система написана). Речь идет о том, что весьма несложной доработкой системы можно увеличить производительность системы на порядки, а не на проценты. Но при этом система снимается с поддердки производителем, что естественно. Но эта же система (говорю сейчас только про 77, и только про УУ) так или иначе всегда требует доработки (изменение процессов предприятия, появление новых, отмирание старых и т.д.) - система и так лишается поддержки производителем в большинстве случаев, почему бы помимо модернизации логики еще и не сделать оптимизацию? Которая в том числе снижает затраты на железо?

Enot5467Ну а если есть желание и возможности что-то поулучшать, то есть готовые алгоритмы что-бы не залезть при этом в лужу. Например в случае с ситуацией автора, мне кажется эффективней сделать анализатор структуры базы для всех видов хранений, кроме файлового. Создать модуль по настройке переноса данных (типа Наименование переносить в наименование). Обязательно сделать контроль кода в модулях объектов, т.к. там часто располагается очень много логики. Добавить модуль котроля прав, обязательно вставить механизм разрешения коллизий. Ну и разработать исполняемую часть. И тогда все заработает без проблем.
Я боюсь стоимость такой разработки превысит стоимость той самой программы автора, для которой требуется экспорт в 1С. :) Автору не нужна универсальность. Ему достаточно эскпоротировать один единственный вид документа.
Enot5467
Может мы немного по разному это понимаем, а может и я не так изъясняюсь, но моё мнение остается прежним: либо получится быстро и ооочень криво, либо ровно, но очень долго
Ну, не сказал бы что очень по разному. Просто получится быстро и красиво, но строго для одного конкретного релиза 1С. Универсальность же потребует либо модификации конфы, что нежелательно. Либо полноценной разработки и "реверс-инжиниринга" платформы, что долго, дорого, не совсем законно, и не сказать бы что особо востребовано. Тем, кому нужен быстрый обмен своих систем с 1С - сделают его сами. Тех, кому скорость обмена не особо важна - вполне устроят штатные средства обмена. Или "1С:Конвертация данных", или "1С:Консолидация". Здесь основная проблема это то, что платформа 1С запрещает прямой доступ к данным, но не предоставляет никакого API для взаимодействия с конркетной конфигурацией без запуска всей платформы по OLE\COM. Из-за чего не получается сделать "универсально, быстро и красиво".

badboychik,

Восьмерку только начинаю крутить, про ее сервер уже знаю, но как быть с файловой конфой? Насколько я понял - в файловом варианте 8-ка также будет грузиться вся.
Для 77 "пакетный" режим работы - суть тот же запуск всего приложения, только не по событию извне, а по расписанию.
Да и парсер dd\dds еще не все - как быть с перечислениями, периодикой и прочим, чего найти можно только в md?

Смысл как раз и был - отговорить автора от прямой записи в таблицы 1С :) Особенно если требуется как можно более простой код. И особенно когда планируется взаимодейсвтие с разными конфигурациями 1C. :)

Set2009,

Вы забыли еще в скрипт добавить и перенос и получение кодов всех справочников, перечислений и прочего 1Сного, требуемого для правильного заполнения документа. :)
Хотя конечно, можно и в скрипте все сделать, безо всяких обработок 1С. Дело вкуса...
Выбор, собсно, лишь в том, кто и что будет должен рихтовать при обновлении\изменении конфы - vbscript или обработку 1С. Ну и соответственно кто должен разбираться в тонкостях атрибутов 1С документов\справочников - автор системы-"экспортера" или 1Сник, обслуживающий конфигурацию-"импортер".