jsmith82 (59) А что из альтернатив было?

ну, я то в отличие от рупора понимал, что написать рекурсивную выгрузку всей базы в xml самому куда сложнее чем парочку галочек в КД поставить

ну дк

нет, ну может человек просто не понимает всей сложности того, чего он предлагает. Вполне искренне

ЗлобнийМальчик ну, я то в отличие от рупора понимал, что написать рекурсивную выгрузку всей базы в xml самому куда сложнее чем парочку галочек в КД поставить

Не очень, если честно, понимаю, про какую рекурсивную выгрузку всей базы в xml идет речь, и зачем оно надо. По собственному опыту знаю вот что:

Да, на первых порах, делая свои обмены, приходилось попотеть, не сильно, но ощутимо. Писать много кода, тестировать, исправлять... Потом, когда накопил уже достаточно много рабочего кода на самые распостраненные случаи, за счет схожести структуры данных, написание новых обменов превратилось просто в небольшие правки уже работающего, оттестированного кода. За счет же того, что исправление ошибок и доработки обмена, написанного кодом, проще во много раз, а работает самописный обмен куда надежнее и быстрее всей это махины с правилами обмена и КД, и для работы с ними не нужно изучать и использовать еще 1 дополнительный инструмент, помимо конфигуратора, первоначальные трудозатраты были компенсированы многократно. На текущий момент у меня есть рабочий код для следующий случаев: УТ-БП, УТ-ЕРП, ЕРП-БП, БП-ЗУП.
Что касается же КД - возможно, существуют какие-то случаи, мнет неизвестные, где описанный мной процесс проиграет КД, но я, слава богу, с такими не сталкивался, и представить мне их, честно сказать, сложно, для регулярной передачи данных в обе стороны между перечисленными мной конфигурациями моего обмена, написанного кодом, хватает за глаза. Помню свой последний опыт с КД - посреди белого дня мне звонит бешеный бухгалтер и орет в трубку, что у нее ни с того ни с сего встал обмен, и она сейчас не сдаст отчетность... Смотрю ошибку - там стандартная типовая муть про правила обмена, xml и т.п. И началось - выгрузка правил обмена, загрузка их в КД, анализ мегатонных xml... И все это под аккомпонимент криков сначала бухгалтера, а потом и директора, про то, что 1с говно, программисты 1с сволочи, и, что если отчет они не сдадут, денег они мне платить не будут. Проблему я все же решил, но зарекся в будущем когда-либо еще связываться с этой сранью. И знаете что - за 4 года ни разу ни пожалел, что-то не работает - отладчиком потыкал f10 до нужной строки, поправил, и все, 5 минут, притом что такие случаи очень редки, ибо простой явный код работает как часы. Нужно что-то доработать - точно также - копировать/вставить, немного правок, и все, готово, не говоря уже о том, что кодом легко напишешь то, на что КД в принципе не способна. Из клиентов тоже никто еще не жаловался.

Рупор Галактики если честно, понимаю, про какую рекурсивную выгрузку всей базы в xml идет речь, и зачем оно надо

Происходит выгрузка объекта, у объекта есть реквизиты, они ссылаются на иные объекты и т.д. и т.п. Таким образом, выгрузка какого-нибудь документика превращается в выгрузку десятков, нескольких десятков объектов.
Это общий принцип. Разумеется, с помощью КД можно указать что выгружать и как.

jsmith82 Происходит выгрузка объекта, у объекта есть реквизиты, они ссылаются на иные объекты и т.д. и т.п. Таким образом, выгрузка какого-нибудь документика превращается в выгрузку десятков, нескольких десятков объектов.
Это общий принцип. Разумеется, с помощью КД можно указать что выгружать и как.

И в чем проблема? Ты хочешь сказать кодом нельзя прописать, что выгружать и как? Давай возьмем партнеров - у них договора, соглашения, КИ, контактные лица, у КЛ своя КИ, еще у них есть контрагенты, там свои договора, своя КИ, что-то еще вроде есть. Рекурсивнее некуда, по моему. Дня два вроде у меня ушло на прописание/отладку всего этого кодом. И этот код у меня остался навсегда, если нужно сделать новый обмен - я беру этот код, правлю его (бывало, и не правил), и вуаля, новый обмен готов. И не поверишь, братишка, мне не нужны никакие конвертации, правила и т.п.

А как быстро сможешь создать обмен для произвольных конфигураций?
Если ещё, например, 77?

jsmith82 И на что же КД неспособна?

Сделай на правилах обмена следующую задачу:

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

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

Сколько потов с тебя сойдет, чтобы сделать подобное с правилами обмена?

Ты сейчас описываешь какой-то интерфейс типа понасыщенней, чем типовой интерфейс обработки УниверсальныйОбменДанными..., где есть возможность выбора флажками типов объектов, для которых указаны правила выгрузки данных.
Но к КД собственно это большого отношения не имеет.
Во-вторых, интерфейс регистрации, контроля этой же регистрации и отбора наличествует среди типовых механизмов.
В-третьих, если требуется какой-то дополнительный интерфейс, то это отдельный вопрос.
Из примеров.. Писал в том году обмен УТ 10 - Клиент ЭДО. Была обработка с формочкой с настройками, сам обмен согласно КД с помощью типовой функциональности.

jsmith82 Чтобы объективно судить о твоей поделке (не только аспект того, что есть заточенные варианты обмена под популярные маршруты, а и прочие ништяки), нужно побольше узнать о ней.

Ну ты спроси, что хочешь узнать :) Я никому не навязываю свой путь, не нравится - КД ждет тебя.

Рупор Галактики Я никому не навязываю свой путь

Ты обсираешь КД. И ведёшь себя немного по-дилетантски, как будто так и не осилил типовые механизмы.

jsmith82 А как быстро сможешь создать обмен для произвольных конфигураций?

Я давно не делал обменов с нуля, не знаю, но там в любом случае будет нечто общее в структуре данных, не думаю, что возникнут проблемы. Берем кусок кода, путем копировать/вставить из конфигурации просто меняем названия реквизитов, прописываем логику, если надо (логику тебе КД автоматом тоже не пропишет), ничего сложного в принципе.

Рупор Галактики Ниче, что там логика разная везде?

Логика везде разная. Логику ты же сам руками прописываешь.

jsmith82 Не совсем понимаю, про что ты. Передать документ? Кидаешь свой массив ссылок в поле структуры Параметры типового модуля типовой обработки. Выгрузит, что надо.

Ничего на это сейчас ответить не могу. В типовые механизмы обменов давно не заглядывал. Если там действительно есть возможность вызвать функцию с передачей туда нужной ссылки и она тебе сразу ее передаст в приемник, хорошо, значит насыщенный интерфейс для типовых обменов сделать можно без проблем, я очень рад. Только, я надеюсь, эта функция не в отдельной базе с КД находится, да? :) Эта функция ведь в конфигурации источнике, откуда ты отправляешь, я же прав? :)

Функциональность располагается в типовой обработке УниверсальныйОбменДанными...
Обычно встроена, но можно и в виде внешней юзать

jsmith82 Не совсем понимаю, про что ты. Передать документ? Кидаешь свой массив ссылок в поле структуры Параметры типового модуля типовой обработки. Правило выгрузки данных использует произвольный алгоритм с параметром. Выгрузит, что надо.

А зачем тогда правило выгрузки, если алгоритм все равно произвольный? Не проще ли этот произвольный алгоритм сразу запихать в свою обработку, прикурить интрефейс и го? Правила обмена и КД тогда зачем? К тому и было сказано про шизофрению. Зачем плодить все эти ненужные звенья?

Рупор Галактики А зачем тогда правило выгрузки, если алгоритм все равно произвольный?

Правило выгрузки предполагает обработку выгружаемых объектов. В коде известной обработки Универсальный... происходит данное действо.
Сам же произвольный алгоритм предполагает нетиповую выборку выгружаемых данных. Если ты в запросе пропишешь какие-то параметры, то их значения можно передать в поля структуры Параметры, имеющей какой-то контекст в этой обработке. И использовать их при установке параметров запроса.
Это касаемо твоей "точечной выгрузки объектов".
Ну ты понел.

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

Так и том и речь... Зачем все это?)) Правило выгрузки, загрузки, все эти события, настройки, насыщенный api и т. п. Все это лишний код и трудозатраты. Какую практическую пользу и выгоду все это несет? И почему вместо всех этих правил не сделать просто вот так:

Функция выгрузитьНоменклатуру(источник, connection)
	
	поискПозиции = новый запрос;
	поискПозиции.Текст = "ВЫБРАТЬ
	                    |	Номенклатура.Ссылка КАК Ссылка
	                    |ИЗ
	                    |	Справочник.Номенклатура КАК Номенклатура
	                    |ГДЕ
	                    |	Номенклатура.ЭтоГруппа = ложь
	                    |	И Номенклатура.Наименование = &Наименование";
	поискПозиции.УстановитьПараметр("Наименование", Источник.Наименование);
	найденныеПозиции = поискПозиции.Выполнить().Выгрузить();
			
	если не найденныеПозиции.Количество() тогда
		НоменклатураОбъект = справочники.Номенклатура.СоздатьЭлемент();
		НоменклатураОбъект.Наименование = Источник.Наименование;
	иначе
		НоменклатураОбъект = найденныеПозиции[0].ссылка.ПолучитьОбъект();
	конецесли;
	
	если не Источник.СтавкаНДС.isEmpty() тогда
	
		если Connection.Перечисления.СтавкиНДС.indexof(Источник.СтавкаНДС) = 5 тогда
			СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.БезНДС;
		иначеесли Connection.Перечисления.СтавкиНДС.indexof(Источник.СтавкаНДС) = 2 тогда
			СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.НДС10;
		иначеесли Connection.Перечисления.СтавкиНДС.indexof(Источник.СтавкаНДС) = 3 тогда
			СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.НДС10_110;
		иначеесли Connection.Перечисления.СтавкиНДС.indexof(Источник.СтавкаНДС) = 0 тогда
			СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.НДС18;
		иначеесли Connection.Перечисления.СтавкиНДС.indexof(Источник.СтавкаНДС) = 1 тогда
			СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.НДС18_118;
		иначеесли Connection.Перечисления.СтавкиНДС.indexof(Источник.СтавкаНДС) = 4 тогда
			СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.НДС0;
		//иначеесли Источник.СтавкаНДС = Connection.Перечисления.СтавкиНДС.НДС20 тогда
		//	СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.НДС20;
		//иначеесли Источник.СтавкаНДС = Connection.Перечисления.СтавкиНДС.НДС20_120 тогда
		//	СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.НДС20_120;
	конецесли;
	
	иначе
		СтавкаНДСВПриемнике = Перечисления.СтавкиНДС.НДС18;
	конецесли;
	
	НоменклатураОбъект.Артикул = Источник.Артикул;
	НоменклатураОбъект.ВариантОформленияПродажи = перечисления.ВариантыОформленияПродажи.РеализацияТоваровУслуг;
	
	НоменклатураОбъект.ЕдиницаДляОтчетов = НайтиЕдиницуИзмерения(источник.ЕдиницаДляОтчетов.Наименование);
	НоменклатураОбъект.ЕдиницаИзмерения = НайтиЕдиницуИзмерения(источник.БазоваяЕдиницаИзмерения.Наименование);
	
	если не источник.единицахраненияостатков.isempty() и источник.единицахраненияостатков.вес <> 0 тогда
		НоменклатураОбъект.ВесЕдиницаИзмерения = Справочники.УпаковкиЕдиницыИзмерения.НайтиПоНаименованию("кг");
		НоменклатураОбъект.ВесЗнаменатель = 1;
		НоменклатураОбъект.ВесИспользовать = истина;
		НоменклатураОбъект.ВесЧислитель = источник.единицахраненияостатков.вес;
	конецесли;
	
	НоменклатураОбъект.ИспользованиеХарактеристик = перечисления.ВариантыИспользованияХарактеристикНоменклатуры.НеИспользовать;
	НоменклатураОбъект.Качество = перечисления.ГрадацииКачества.Новый;
	//НоменклатураОбъект.КодДляПоиска = "?";
	НоменклатураОбъект.КоэффициентЕдиницыДляОтчетов = 1;
	НоменклатураОбъект.ОсобенностьУчета = перечисления.ОсобенностиУчетаНоменклатуры.БезОсобенностейУчета;
	
	если источник.Услуга тогда
		НоменклатураОбъект.ТипНоменклатуры = перечисления.ТипыНоменклатуры.Услуга;
		НоменклатураОбъект.ВидНоменклатуры = справочники.ВидыНоменклатуры.НайтиПоНаименованию("Услуга");
	иначе
		НоменклатураОбъект.ТипНоменклатуры = перечисления.ТипыНоменклатуры.Товар;
		НоменклатураОбъект.ВидНоменклатуры = справочники.ВидыНоменклатуры.НайтиПоНаименованию("Товар");
	конецесли;
	
        //НоменклатураОбъект.ВерсияДанных = Источник.Наименование;
	//НоменклатураОбъект.ДополнительныеРеквизиты = Источник.Наименование;
	//НоменклатураОбъект.Импортер = Источник.Наименование;
	//НоменклатураОбъект.ИмяПредопределенныхДанных = Источник.Наименование;
	//НоменклатураОбъект.Код = Источник.Код;
	//НоменклатураОбъект.КодОКВЭД = Источник.Наименование;
	//НоменклатураОбъект.КодОКП = Источник.Наименование;
	//НоменклатураОбъект.КодРаздел7ДекларацииНДС = Источник.Наименование;
	//НоменклатураОбъект.КодТНВЭД = Источник.Наименование;
	//НоменклатураОбъект.Комментарий = Источник.Комментарий;
	
        если Источник.НаименованиеПолное = "" тогда
		НоменклатураОбъект.НаименованиеПолное = Источник.Наименование;
	иначе
		НоменклатураОбъект.НаименованиеПолное = Источник.НаименованиеПолное;
	конецесли;
	
        ////НоменклатураОбъект.Неизвестноеимясвойства = Источник.Наименование;
	//НоменклатураОбъект.НоменклатурнаяГруппа = Источник.Наименование;
	//НоменклатураОбъект.НомерГТД = Источник.Наименование;
	//НоменклатураОбъект.ОсновнаяСпецификацияНоменклатуры = Источник.Наименование;
	//НоменклатураОбъект.ПериодичностьУслуги = Источник.Наименование;
	//НоменклатураОбъект.ПометкаУдаления = Источник.Наименование;
	//НоменклатураОбъект.Предопределенный = Источник.Наименование;
	//НоменклатураОбъект.ПродукцияМаркируемаяДляГИСМ = Источник.Наименование;
	//НоменклатураОбъект.Производитель = Источник.Наименование;
	//НоменклатураОбъект.Родитель = Connection.справочники.Номенклатура.НайтиПоНаименованию(Источник.Наименование);
	//НоменклатураОбъект.Ссылка = Источник.Наименование;
	
       НоменклатураОбъект.СтавкаНДС = СтавкаНДСВПриемнике;
	
        //НоменклатураОбъект.СтатьяЗатрат = Источник.Наименование;
	//НоменклатураОбъект.СтранаПроисхождения = Источник.Наименование;
	//НоменклатураОбъект.Услуга = Источник.Наименование;
	//НоменклатураОбъект.ЭтоГруппа = Источник.Наименование;
	
	если не Источник.Родитель.isempty() тогда
		СинхронизироватьРодителя(НоменклатураОбъект, Источник, Connection);
	конецесли;
	
	возврат НоменклатураОбъект.Ссылка;
	
КонецФункции

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

(96) Ты серьезно мне сейчас хочешь сказать, что даже начинающий программист 1с испытает трудности с кодом типа того, что я сейчас привел? Ну не гони, не надо)) Это для КД нужны специальные знания и навыки, опыт, а этот код без труда раскусит даже новичек. В этом отношении самописный обмен получается еще выгоднее, чем КД.

(98) Спасибо за пищу для ума. Сегодня уже смотреть не буду, но заценю.

(96) Не стоит спорить, этот персонаж не научился толком в 1С и планирует за год написать свою ERP систему. О каком знании КД можно говорить?

jsmith82 (98) Спасибо за пищу для ума. Сегодня уже смотреть не буду, но заценю.

тебе же пищу для ума бабка давала

нет ну в написании своего кода вместо КД есть своя прелесть - когда я работал с КД, код выполняемый при помощи ВЫПОЛНИТЬ изрядно бесил

(103) Для семёрки код генерится
По идее можно и для 8-ки доработать :)

(94) а если взять любую реальную конфигурацию, в которой справочник номенклатуры ссылается на 100500 других справочников и регистров, которые, в свою очередь ссылаются на другие объекты, и все это надо корректно выгрузить, то как будет выглядеть код?

(105) не так уж много. Представь что у тебя есть 10 друзей, у каждого из них есть по 10 друзей и т.д. Казалось бы людей от третьей линии друзей должно быть уже 1000, но это явно не так. Скорее всего на третьей линии будет человек 20-30

(105)Как-как. [...]. Но пейсателям буквами своих ЕРП-систем во сто крат лучше клятой адинэски это невдомёк.

(105) Я в (98) выложил пример, выгрузка всех данных по физическим лицам из УПП в ЕРП кодом. Само физлицо, сотрудник, воинский учет, семья, образование, история ФИО и др. Скачай, да посмотри, как это выглядит)) Можешь даже поюзать, если хочешь, я не против))

Рупор Галактики воинский учет, семья, образование, история ФИО и др.

Это всё несложные регистры

jsmith82 Это всё несложные регистры

Ты мне сейчас хочешь сказать, что по тому же воинскому учету все данные хранит лишь 1 регистр сведений? Нет справочников воинские звания, военкоматы и т. п.?

(112) Не, я видел твой код

jsmith82 Тут в другом, собственно, дело. Зачем городить простыни кода, если можно сделать через КД.

Затем, что делать через КД значительно более трудозатратно, чем кодом, плюс для КД нужны знания и опыт (что важно) самой КД, а значит спец со знанием КД будет стоить дороже, и найти и его будет сложнее. Решение, сделанное кодом значительно проще в поддержке и доработке, работает быстрее (в теории, не замерял), чем решение на КД. Отказоустойчивость у решения, сделанного кодом, выше, чем у решения на КД (как ты видел, мой код простой как 3 копейки, там ломаться просто нечему). Для меня достаточно.

А теперь ты мне скажи, какие преимущества у КД?

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

что еще немаловажно - для типовых есть готовые правила, допилить которые явно быстрее, чем воротить все с нуля

Рупор Галактики Затем, что делать через КД значительно более трудозатратно, чем кодом

Наборот же

Рупор Галактики плюс для КД нужны знания и опыт (что важно) самой КД, а значит спец со знанием КД будет стоить дороже, и найти и его будет сложнее

КД это мастхэв так-то

Рупор Галактики Решение, сделанное кодом значительно проще в поддержке и доработке

Ну-ну, проще...

Рупор Галактики Отказоустойчивость у решения, сделанного кодом, выше, чем у решения на КД (как ты видел, мой код простой как 3 копейки, там ломаться просто нечему)

Отказоустойчивость какого характера?

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

что еще немаловажно - для типовых есть готовые правила, допилить которые явно быстрее, чем воротить все с нуля

Вот опять... Хоть ссы в глаза, а все божья роса... Объясняю еще раз:
Во первых, не так страшен черт, как его малюют, поверь мне :) Там все не так страшно, как кажется на первый взгляд. Прописать все это вполне реально, и не особо долго. Ты вот скачай пример и посмотри, увидишь, все не так уж и страшно.
Во вторых - код, который ты написал, не убежит от тебя никуда, тебе больше не придется все это заново писать. Чуть-чуть поправить, если только. Вот представь - ты один раз прописал выгрузку номенклатуры из Ут в БП. Потом, тебе надо сделать выгрузку реализации из Ут в БП, где, в том числе нужно переносить номенклатуру из документа (рекурсия!!!). Но код переноса номенклатуры и все ее зависимых данных то у тебя уже есть, ты его просто берешь и используешь в переносе реализаций. И таким образом со временем у тебя уже набирается код для всех основных случаев, ты его просто правишь. Бинго!
В третьих, я тут никого не агитирую идти таким путем. Если ты считаешь, что КД лучше, что на ней все быстрее и проще - вперед КД и толпы ее адептов ждут тебя. Мне не нравится КД и типовые обмены, я их не использую. Если у тебя другие предпочтения, твое право.

Рупору надо не ограничиваться критикой КД, а сразу выбросить нах тормозную яву, с ее куевой горой дырявых абстракций, безмозглым сборщиком мусора и изоляцией разраба от железа и ОС глючными фреймворками. К чему полумеры? Только ассемблер, только хардкор!

Рупор Галактики Мне не нравится КД и типовые обмены, я их не использую.

Почему? Есть обоснование кроме как какой-то бух начала орать из-за какой-то ошибки?

jsmith82 Наборот же

Ты говоришь, мой пример простой, хорошо - прикинь, как и сколько ты будешь делать это на КД. Я сделал, протестировал и выгрузил данные меньше, чем за день.

jsmith82 КД это мастхэв так-то

Не могу сказать, что это плюс.

jsmith82 Ну-ну, проще...

Представь, что у тебя обмен валится с неизвестной тебе ошибкой, как быстро ты найдешь проблемное место в моем примере и в своей его реализации на КД?

jsmith82 Отказоустойчивость какого характера?

Чем меньше элементов в системе (звеньев в цепи), тем меньше вероятность, что система выйдет из строя (цепь порвется). Именно поэтому всегда стремятся сокращать количество элементов (звеньев) к минимуму.

(113) Посмотрел пример кода Рупора. Такой перенос на более-менее серьезном обмене данными будет умирать. В отличие от типовых нет кэширования выгружаемых объектов. Каждый раз лезет искать в базу, через "быстрый" ком. В отличие от типовых нет разделения кода на логику работы с данными базы и транспорт. Когда база-источник уедет от базы-приемника в другую сеть, поделие Рупора прикажет долго жить, в типовом обмене понадобится выбрать вид транспорта - файл вместо ком.

Типичный образчик наколенного кода "молодого специалиста". Прогать научился, но типовых возможностей не знает, поэтому изобретает велосипеды. Думать и проектировать дальше сиюминутной потребности не может. Как говорил киевский златоуст в подобном случае - в завтрашний день не каждый может смотреть.

С таким подходом за убийцу ерп браться немного рановато ИМХО.

jsmith82 Почему? Есть обоснование кроме как какой-то бух начала орать из-за какой-то ошибки?

обоснований и примеров я тебе привел достаточно. Ты не привел ни единого своего аргумента, ни контраргумента к моим. Все что ты мне пытался сказать в этой теме - стандартные сектантские фразы типо "ниасилил", "не по стандартам", "не так, как в типовой". Тут прям как в песенке Арии - "им бы пить и жрать в 3 горла день и ночь, будь ты трижды гений, им нельзя помочь."

Рупор Галактики обоснований и примеров я тебе привел достаточно

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

(121)

ТеньД Такой перенос на более-менее серьезном обмене данными будет умирать.

Более-менее серьезном обменен данными это сколько?

ТеньД В отличие от типовых нет кэширования выгружаемых объектов. Каждый раз лезет искать в базу, через "быстрый" ком.

Ком более чем адекватная технология. У меня нигде ничего не умирает. Не могу понять до сих пор, почему у 1с-ников ком вызывает такую же реакцию, как имя Сатаны. С нормальным железом (это не значит - квантовый компьютер, просто с нормальным), нормальной виндой, с нормально настроенной сеткой все работает на ура. Да, я специально использовал такую архитектуру, такой код проще, более гибкий в поддержке, вероятность отказа и падения все этого дела ниже. Что ты предлагаешь, собрать все эти данные сразу одним запросом? Уверен, что все вот прямо так что нужно соберешь? Что не будет каких-то особых условий в некоторых случаях? Что не потребуется все равно за чем то слазить в источник? Что потом с этой массой данных можно будет нормально работать? Я - нет.

ТеньД В отличие от типовых нет разделения кода на логику работы с данными базы и транспорт.

Как ты понимаешь это самое разделение на логику работы с базой и транспорт? Какие ты видишь плюсы в его использовании?

ТеньД Когда база-источник уедет от базы-приемника в другую сеть, поделие Рупора прикажет долго жить, в типовом обмене понадобится выбрать вид транспорта - файл вместо ком.

Конкретно эта обработка - разовая выгрузка, там ничего никуда уже не уедет. Для уезжающей в другую сеть базу есть веб-сервисы, я об этом говорил.

ТеньД Типичный образчик наколенного кода "молодого специалиста". Прогать научился, но типовых возможностей не знает, поэтому изобретает велосипеды. Думать и проектировать дальше сиюминутной потребности не может. Как говорил киевский златоуст в подобном случае - в завтрашний день не каждый может смотреть.

Я не понимаю, тут где-то написано, что писал ТОП 1 Кодер 1с мира?) Не нравится - удали, сожги, забудь. :) Для меня то, что мои обмены работают как часы и клиенты не обращаются ко мне с жалобами на скорость работы и ошибки, а мне не надо тратить тонны времени на поддержку всего этого, не надо забивать голову всякими КД, АБВГД, и т.п., я сделал и забыл, достаточный аргумент в пользу моего подхода. Не поверишь - ЕРП на 50 + человек, несколько бух-й, все работает без проблем.

ТеньД С таким подходом за убийцу ерп браться немного рановато ИМХО.

Ну, раз ты так говоришь...

И все таки, возвращаясь к теме, чем же КД лучше написания обмена кодом? Пусть даже кодом правильным с твоей точки зрения - с кэшированием, разделением на логику и транспорт и т.п.

(126)

Более-менее серьезном обменен данными это сколько?

Начиная с 10000 объектов примерно.

Ком более чем адекватная технология.

Адекватная. Но ... У любой технологии есть свои границы применения. Для массовой отправки данных ком плохо подходит из-за низкой производительности. Медленный он. Но проблема не только в ком. Про кэширование объектов ты не понял фразу?

Как ты понимаешь это самое разделение на логику работы с базой и транспорт? Какие ты видишь плюсы в его использовании?

Аналогично общепринятой практике. Не только 1с ессно. Плюсы очевидны:

1) можно относительно легко поменять способ доставки данных.
2) разделение высокоуровневой логики работы с данными базы и транспорта позволяет писать более понятный, структурированный и легче поддерживаемый код

Конкретно эта обработка - разовая выгрузка, там ничего никуда уже не уедет.

Я именно это и написал. Для разовой выгрузки вполне норм подход. Для более серьезных задач интеграции лучше взять КД.

Для уезжающей в другую сеть базу есть веб-сервисы, я об этом говорил.

Т. е. вместо одного переноса типовыми средствами, в котором можно обычном юзеру банально переключить транспорт с ком на сервис ты написал 2 отдельных обмена, через ком и сервис? Ты правда думаешь что так проще жить?

И все таки, возвращаясь к теме, чем же КД лучше написания обмена кодом? Пусть даже кодом правильным с твоей точки зрения - с кэшированием, разделением на логику и транспорт и т.п.

1) Работает быстрее, за счет более эффективного алгоритма.
2) Универсальнее за счет возможностей настройки отборов, видов транспорта без влезания в код.
3) Отказоустойчивее. Там где упадет с ошибкой перенос на основе КД, там свалится и твой код, но твой сумеет упасть еще в нескольких случаях, в которых "выживет" типовой обмен.

ТеньД (126) Т. е. вместо одного переноса типовыми средствами, в котором можно обычном юзеру банально переключить транспорт с ком на сервис ты написал 2 отдельных обмена, через ком и сервис? Ты правда думаешь что так проще жить?

Изначально делал все на ком, потом перешел на веб-сервисы. У относительно крупных клиентов сейчас все на веб-сервисах, там бывают сложности с правами, неоднородная архитектура, линукс. Ком использую очень редко, только если клиент совсем маленький, там его производительности хватает. Принцип у веб-сервисов в основном такой - клиент галками выбирает объекты (документы), программа ему выбранные объекты и все сопутствующие данные собирает в xml, отправляет в приемник, приемник читает/записывает, шлет файл-ответ, где по каждому объекту есть инфа - записался, нет, если нет то почему. У одного все тоже самое, но автоматом по регламентному заданию. Для каких-то разовых вещей ком по моему подходит более чем. Я соглашусь, в приведенном мной примере можно задать определенные вопросы по производительности, но для небольших объемов ее хватит, я считаю что тут важнее простота и надежность. Да, я считаю, что так проще жить. :)

ТеньД 1) Работает быстрее, за счет более эффективного алгоритма.
2) Универсальнее за счет возможностей настройки отборов, видов транспорта без влезания в код.
3) Отказоустойчивее. Там где упадет с ошибкой перенос на основе КД, там свалится и твой код, но твой сумеет упасть еще в нескольких случаях, в которых "выживет" типовой обмен.

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

Рупор Галактики Ком более чем адекватная технология. У меня нигде ничего не умирает. Не могу понять до сих пор, почему у 1с-ников ком вызывает такую же реакцию, как имя Сатаны. .

у сапёров ком вызывает ещё более бурную реакцию, поверьте.

ЗлобнийМальчик у сапёров ком вызывает ещё более бурную реакцию, поверьте.

А если не секрет, вы с 1с куда перешли?

Рупор Галактики А если не секрет, вы с 1с куда перешли?

В SAP он перешёл. Работает в Германии.

(130)

Принцип у веб-сервисов в основном такой - клиент галками выбирает объекты (документы), программа ему выбранные объекты и все сопутствующие данные собирает в xml,

Как ты выходишь из положения, когда юзер не знает какие объекты ему надо выбрать? Для справки, типовые обмены работают в одной упряжке с планами обмена, передавая в базу-приемник только измененные объекты.

я считаю что тут важнее простота и надежность.

При регулярном пользовании обмена, такая простота играет против надежности.

все сразу пишется кодом в xml и читается также

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

Чем тебе не нравится влезать в код? Прописал что нужно, и все. Зачем городить настройки, если можно просто поправить код?

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

Примеры и пруфы в студию.

ОК. При изменении структуры данных или проблем ком-коннектора твой и типовой обмены упадут одинаково. Типовой обмен переживет работу под бесправным юзером, разделение данных, а твой упадет.

ТеньД Как ты выходишь из положения, когда юзер не знает какие объекты ему надо выбрать? Для справки, типовые обмены работают в одной упряжке с планами обмена, передавая в базу-приемник только измененные объекты.

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

ТеньД При регулярном пользовании обмена, такая простота играет против надежности.

Это, прости меня, как?))

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

Прости, я не знаток типовых обменов, не знаю, что он и как там кэширует, но мне сложно представить, что простой механизм типа посмотрел в БД., взял, записал в xml, отправил, столкнется с какими-то сложностями с производительностью, разве что сложности с производительностью будут у самой 1с.

ТеньД Мне нравится. Не нравится юзерам, которые и будут работать с обменом. Не понравится прогу, на которого упадет сопровождение твоего обмена, поскольку его будут часто дергать из-за него.

Я не очень понимаю, про каких юзеров идет речь. В моем варианте юзер отборами выбирает, что нужно передать и передает. Программист пишет код. Зачем в эту простую и эффективную схему вводить еще какие-то звенья, настройки и т.п., и кому это может понравиться, я не понимаю.

ТеньД ОК. При изменении структуры данных или проблем ком-коннектора твой и типовой обмены упадут одинаково. Типовой обмен переживет работу под бесправным юзером, разделение данных, а твой упадет.

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

Хватит сраться. Пиши ERP!

(135)

Там не бывает случая, когда юзер не знает, что ему надо выгрузить.

У тебя вырожденный случай. Кейс: сидит бухгалтерия. 3-5 бухов ковыряют доки. Иногда задним числом. В конце дня выгружают их. Как выгружающий бух отследит какие доки надо выгрузить? Будет всех опрашивать?

Это, прости меня, как?

При изменении условий "простой" обмен упадет. "Сложный" можно перенастроить самому юзеру.

не знаю, что он и как там кэширует

Типовая обработка читает выгружаемый объект 1 раз (если спецом в КД не указано обратное). Прочитанный объект держится в памяти, перед чтением объекта сперва проверяется не загружен ли он уже, если загружен возвращается на него ссылка. Не надо дергать базу.

простая передача данных через веб-сервис и xml точно не будет падать чаще, чем типовой обмен, не надо сочинять.

Я тебе написал 2 реальных кейса

Типовой обмен переживет работу под бесправным юзером, разделение данных, а твой упадет.

Господа, я вот искренне не понимаю, почему столь элементарные, по моему, вещи ля любого программиста, вызывают у вас такие сложности? Разработка обмена - дело вовсе не тяжелое. Немного тяжело в начале, да, но и то, тяжело разбираться во всей этой структуре данных, что от чего зависит, что куда входит, что как соотносится. Сам код пишется элементарно - копировать вставить, копировать/вставить имена реквизитов, все, вот вам написанный код. Код обменов элементарен, когда рабочий, тестированный код у тебя уже есть, править его элементарно. Надо из ком в xml - скопировал в приемник, скопировал в источник, в источнике поправил на запись в xml, в приемнике - на чтение из xml, протестил - все, вот обмен через веб-сервис. Не, ну в чем сложности то, але?)))

(139)

В твоем случае делается регистр сведений, куда при изменении (проведении или записи) валится инфа, что такой-то объект был создан или изменен, после чего регламентное задание смотрит туда и передает только те объекты

Не нужно городить регистр сведений для такой задачи. Почитай мануал про план обмена и не рожай очередной велосипед.

И какие такие пользователи тебе настройками эти изменения поправят? Знаешь бухгалтеров имеющих желание и разбирающихся в КД?

Нормальные "продвинутые пользователи", эникеи сисадмины, саппорт. В КД они ессно лезть не будут, изменение правил обмена не их ума дело, но с частью мелких проблем разобраться могут. Например, поменять имя файла обмена при недоступности сетевого ресурса.

Оно читает данные с жесткого диска и хранит в оперативке? А потом проверяет, нет ли объекта в оперативке, и если есть, обращается к нему? А нафига оно его там держит то тогда?

Чтобы не читать его повторно из базы. Пример, ты выгружаешь справочник договоров. Элементов много. В договоре есть реквизит "Организация". Организаций мало. Зачем при выгрузке каждого договора читать из базы организацию, если можно прочитать и выгрузить один раз и дальше только подсовывать номер уже выгруженного объекта?

ТеньД Не нужно городить регистр сведений для такой задачи. Почитай мануал про план обмена и не рожай очередной велосипед.

Да, совсем забыл про план обмена, конечно, можно использовать его.

ТеньД Например, поменять имя файла обмена при недоступности сетевого ресурса.

Ну это уже совсем какие-то мелочи/текучка, подобные вещи так или иначе довольно просто решаеются, я на счет этого даже заморачиваться смысла не вижу. Опять же, если реально будет надо, я тоже могу xml не отправлять через веб-сервис, а сохранить где-то.

ТеньД Чтобы не читать его повторно из базы. Пример, ты выгружаешь справочник договоров. Элементов много. В договоре есть реквизит "Организация". Организаций мало. Зачем при выгрузке каждого договора читать из базы организацию, если можно прочитать и выгрузить один раз и дальше только подсовывать номер уже выгруженного объекта?

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

Все это никаким образом не проясняет собственно главный вопрос - чем же собственно технология разработки обменов с помощью КД и правил обмена лучше, чем разработка обменов просто кодом?

Я считаю что разработка обменов кодом по сравнению с КД:

1. Быстрее. Реально быстрее. Если кто-то не согласен - возьмите мой пример, который тут все назвали простым и нубским, и попробуйте сделать функциональный аналог на КД. Кто-то возразит, что в КД есть автосопоставление. На что отвечу, что уже написанный тобой код, который ты копируешь и вставляешь - вот тебе тоже самое автосопоставление, но быстрее и проще. Править и отлаживать этот скопированный код куда быстрее и проще, чем доделывать правила, созданные автосопоставлением.

2. Проще в поддержке и доработке. Опять же, уже писал. Представьте, что у вас в обмене выскочила неизвестная ошибка. Где вы быстрее и проще найдете и поправите ее? В моем примере или его аналоге на КД? представьте, что вам нужно добавить еще какие-то данные туда, сделать какую-то доп. логику, например ввод каких-то документов, источников для которых в УПП нет. Где вы сделаете это быстрее и проще? В моем примере или на КД?

3. Надежнее. Тоже уже писал. Чем меньше элементов в системе (звеньев в цепи), тем меньше вероятность, что система выйдет из строя (цепь порвется). Именно поэтому всегда стремятся сокращать количество элементов (звеньев) к минимуму. Для обменов, особенно на больших объемах, я считаю этот пункт особенно важным.

4. Экономичнее. Для разработки обменов на КД нужны знания КД и опыт работы с ней, а это время и доп. деньги на специалиста, плюс найти его сложнее. Для разработки обменов кодом нужно только знание языка 1с.

Какие же плюсы у КД и правил обмена?

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

Не нужно думать, что я фанат написания всего на низком уровне. Я ничего не имею против таких классов, как ТаблицаЗначений, Запрос, ЧтениеXML и т.п., или таких технологий, как react.js, angular.js, Hibernate, Qt. Но все эти вещи несут реальную практическую выгоду и помогают разработчику. Сказать тоже про КД я, к сожалению, не могу. По моему, это такой же абсурд, как если бы разработчики Hibernate, на каком-то этапе разработки решили, вместо того, что бы ее развивать, влепить какую-нибудь надстройку над ней, например Hibernate Plus Easy Edition. Ну это же трэш...

(142)

А как оно поймет, что договоров много, а организаций мало, и что организации неплохо бы закешировать?

Само не поймет, надо подсказать. В КД есть специальная галка для этого.

1. Быстрее. Реально быстрее.

Зависит от кол-ва правил. Если надо будет как в типовых обменах гонять туеву хучу объектов, то КД быстрее. Для пары-тройки правил особой разницы не будет, особенно если служебные процедуры для использования при обмене уже написаны заранее.

2. Проще в поддержке и доработке.

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

3. Надежнее.

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

4. Экономичнее. Для разработки обменов на КД нужны знания КД и опыт работы с ней, а это время и доп. деньги на специалиста, плюс найти его сложнее.

КД - индустриальный стандарт. Какие там могут быть сложности?

Сказать тоже про КД я, к сожалению, не могу.

Это ты КД 3.0 не видел. Вот где настоящий абсурд и сон разума.

ТеньД
Зависит от кол-ва правил. Если надо будет как в типовых обменах гонять туеву хучу объектов, то КД быстрее. Для пары-тройки правил особой разницы не будет, особенно если служебные процедуры для использования при обмене уже написаны заранее.

Говорил уже об этом, это нивелируется наличием у тебя уже готового кода. Представь, что тебе нужно сделать перенос заказа клиента, реализации, и счета-фактуры со всей рекурсией из Ут в ЕРП. Объектов более чем. У тебя уже есть код для переноса, скажем, поступления товаров и услуг со всей рекурсией. Ты просто берешь этот код, копируешь его нужное количество раз. Правишь код переноса документа (не так уж сильно, как ты понимаешь), рекурсия (номенклатура, партнеры, контрагенты и т.п.) у тебя остается неизменной, и вот твой обмен готов. В будущем, если надо сделать тоже самое, ты просто берешь и копируешь уже готовый код, вообще делать ничего не надо. Ты мне можешь сказать - на написание первоначального кода переноса поступления с рекурсией уйдет много времени. Я тебе отвечу - уж точно не больше, чем на овладение КД (во много раз меньше, как ты понимаешь). Ты мне скажешь - знания КД останутся с тобой навсегда. Я тебе отвечу - твой код от тебя тоже никуда не убежит, а КД тебе нигде кроме правил обмена больше нафиг не надо. Есть ли смысл забивать этим голову? Я думаю нет.

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

Это тоже уже разбирали. Ты правда думаешь что даже новичек в программировании 1с испытает трудности с простым кодом в стиле

приемник.ИНН = источник.ИНН;

? :)

ТеньД Надежность хардкода - плата за отсутствие гибкости.

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

ТеньД Ты даже не понял при каких условиях твой код упадет, несмотря на 2 повторения. Похоже ты не работаешь с системами, где применяется разделение данных и настройка прав.

Я тебе писал вроде про кейсы, которые ты привел. Простенькая передача данных через веб-сервис тоже переживет работу под бесправным в домене юзером. Для бесправности в 1с есть УстановитьПривилегированныйРежим(); Про какое разделение данных ты говоришь?

ТеньД КД - индустриальный стандарт. Какие там могут быть сложности?

Что в твоем понимании индустриальный стандарт? Почему ты думаешь, что КД индустриальный стандарт?

ТеньД Это ты КД 3.0 не видел. Вот где настоящий абсурд и сон разума.

Видел. Открыл и сразу закрыл.

У меня такое впечатление складывается, что никто из вас никогда вообще не подходил к юзеру и не спрашивал - а чего ты хочешь? А как тебе удобней? Попробуйте, много интересного узнаете.

короче, обмен кодом это не комильфо, вот и всё

удобство юзера может сделать типовую не типовой

(144)

Простенькая передача данных через веб-сервис тоже переживет работу под бесправным в домене юзером. Для бесправности в 1с есть УстановитьПривилегированныйРежим(); Про какое разделение данных ты говоришь?

Судя по примеру кода, ты находишь объекты методами НайтиПоКоду и НайтиПоНаименованию. Если у юзера нет права на чтение объекта - такой код упадет. Типовая обработка читает объекты запросом, собирая его из кусков начиная с "ВЫБРАТЬ РАЗРЕШЕННЫЕ ". Она выживет, твоя нет.

Разделение данных выглядит примерно вот так:

Использование метода НайтиПоКоду чревато выпадением ошибки: "Требуемая операция не может быть выполнена, т.к. установлены не все разделители ИБ". Правильно выбирать данные запросом.

Рупор Галактики Я считаю что разработка обменов кодом по сравнению с КД:

1. Быстрее. Реально быстрее

Во многих случаях - да, быстрее.

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

спор затянулся

jsmith82 Хватит сраться. Пиши ERP!

Господи, ты все никак забыть не можешь, что ли... Да, компания, где я не так давно работал сисадмином, а сейчас плотно сотрудничаю как сторонний специалист (не по 1с, 1с я последнее время занимаюсь факультативно, только со старыми клиентами, или знакомыми, если попросят.) решила попробовать написать свое ЕРП-решение, после долгих споров рассуждений, часть которых ты лицезрел, учредителям было предложено следующее решение - 1 системный архитектор, 1 бизнес-аналитик, 7 разработчиков на старте. Бэк на c++, на линукс, БД - Postgres, фронт сначала на веб, потом, после успешного запуска, полноценное клиентское приложение. Руководство сначало было за, но потом интерес поугас, и сейчас они эту ему пока отложили, насколько я знаю. Не отказались полностью, но отложили. Да, братишка, такое бывает, придется теперь тебе с этим жить.

1 системный архитектор, 1 бизнес-аналитик, 7 разработчиков на старте. Бэк на c++, на линукс, БД - Postgres, фронт сначала на веб, потом, после успешного запуска, полноценное клиентское приложение.

Это уже выглядит более реалистичным планом, чем написание ЕРП в одно лицо за год.

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

Как посчитали бюджет, сразу энтузиазм поубавился. Знакомо.

[smile=:D]

ТеньД Это уже выглядит более реалистичным планом, чем написание ЕРП в одно лицо за год.

Я тут где-то написал, что собирался 1 написать ЕРП за год?

ты не написал, что за ЕРП

(151) 8 человек по 150 тыщ = 1,2 млн = 14,4 млн за год с неясным итогом за 14 млн можно внедрить SAP FI

Fynjy с неясным итогом

При адекватном подходе все белее чем ясно.

Fynjy внедрить SAP FI

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

В долгосрочной перспективе так себе, на мой взгляд.

(156) ржу не могу. Вы за год даже склад\логистику толком не нарисуете. Я знаю минимум 3 примера - "сами" рисовали розницу для своих суперов. Итог печальный во всех 3 примерах - 2 купили ПО, 1 продолжает мучаться и тратить деньги на 6 программцов.

(157)

Fynjy Вы за год даже склад\логистику толком не нарисуете.

Все мы нарисуем, поверьте.

Зайдите как-нибудь в Спортмастер, попросите продавца поискать что-то вам на складе, увидите, на чем они работают. Ничего, вроде не умерли пока. Сам лично работал в федеральной сети компьютерных магазинов и СЦ, вся сеть работала на самописной системе, отлично все работало, косяков не припомню. Знаю компанию, у которой своя система на php/js с очень симпатичным интерфейсом, никаких проблем. Тут все зависит от подхода к делу, я вам также могу тонну примеров неудачных внедрений тиражируемых решений (сап, 1с, etc...) привести)))

(158) успехов, покажешь потом гениальное решение, а мы поржем.

Fynjy (158) успехов, покажешь потом гениальное решение, а мы поржем.

А что так агрессивно то?)) Бомбит от того, что кто-то действительно умеет программировать, а ты просто обслуга для конфигуратора?))

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

Fynjy (160) почему же бомбит - ржу не могу. Ты просто мал и туп и не видал больших залуп. А по поводу твоего умения программировать то твое субъективное мнение ...

ну ну)))