80-Зелёный тролль > А первым этапом я бы настаивал на переход на 8.3: одни интерфейсы форм чего стоят при разных правах: УФ все-таки весч...
Да и если этим пренебречь, то работу с новыми объектами придется делать дважды: 1С 8.2 уже приговорило.

+(81) А после того, как прекратит поддержку конф 8.2, прекратится и поддержка серверных компонент. И если у негры возникнут проблемы с xSQL, то шерифа эти проблемы не... Ты понял:)

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

83-Reaper > Угум-с. Тем паче обмен БП<->УТ 1С сопровождает.
Хоть здесь хлопот не будет.

пони сдох
доигрались, господа пикейные жилеты

[em]— … Сталлионград находился в тяжелом положении, и мы были вынуждены обратиться за помощью к Эквестрии,[/em] – вещала наш учитель истории, прокручивая рычаг проектора. На нём лениво проворачивалась лента диафильма,[em] – вот, вы видите момент заключения договора…[/em]
На картинке были изображены Сталлионградские пони – высокие, сильные, красного цвета, протягивающие маленькой, синей и змееподобной Селестии договор. Селестия ехидно улыбаясь, ногой загораживая еще более маленького, белого и не менее змееподобного принца Голден Мэйна. Прямодушные красные пони не замечали подвоха и доверчиво протягивали Селестии бумагу, скрепленную огромной красной печатью
Зрелище не вызывало особого интереса среди моих одноклассников, да и мне нудный повествовательный тон быстро наскучил. К тому же я слышал, что Селестия красивая. И вроде, даже не синяя...

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

Бессмертный пони - повторюсь после прочтения ветки: дешевле и быстрее всего в вашем случае - просто наладить выгрузку/обмен с копеечной 1С7 Производство+услуги+бухгалтерия и реализовать производственный/управленческий учет там.

Кстати, там же можно вести черный учет (изменение объемов, зарплата в конвертах, дармовые работы, откаты итп). В этом копеечном ПУБ до эры УПП вели учет крупные предприятия типа ЧТПЗ, УАЗ итд. Как там это реализовано:

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

2) Заполняете Справочник Техопераций (покраска итп) со стоимостями и нормами времени.

3) Продажник вводит Заказ на пр-во. Если заказ менятся на ходу - Корректировка Заказа на пр-во

4) Механизм Спецификаций делает все, что вы хотите - резервирует, переводит со склад на склад, формирует документы привычного вида (Треб-накл, лимитно-заборная карта итп), что очень полезно для борьбы с воровством

5) Готовая прод. приходуется и резервируетсяв разрезе Договоров/Счетов

6) Есть годный механиз учета некондиции и брака с переклассификацией

7) В любой момент (типа кризис, резкий спад, демпинг, конкурс, появление конкурента итп) - ПУБ позволяет даже посреди месяца получить себестоимость продукции "на сейчас", без закрытия месяца

8) Ведомость дефицита материалов - по сути готовый План закупок для МТС, учитывающий остатки, НЗ, введенные заказы и заявки на будущее. Нет точки заказа и мин. партии поставки, но есть мин. остаток, автоперевод из шт в кг, нормы выхода/отхода, привязка техопераций к материалу итп.

Этот механизм может оказаться настолько удобен, что в 8-ке можно будет вводить один документ Передача в пр-во последним днем месяца и один выпуск продукции. Можно настроить и полный обратный автообмен 7.7->8.2.

Так делают несколько известных мне заводов, не засоряя производственной "возней" свои белые и пушистые бухгалтерские базы

88-economist > идея неплоха. Всего несколько вопросов:
1, Возьметесь ли вы ее реализовать
2, Сколько вашего чистого рабочего времени это потребует, в течении какого срока вы его сможете выделить?
Нужно как минимум перенести и синхронизировать номенклатуру и склады из бухгалтерии, переводить выписываемый в бухгалтерии счет в заказ на пр-во, переносить готовую продукцию на склад в БП, для фикации отгрузки, ну и списание материала тоже, по каждому заказу отдельно.
3.Оцените, сколько времени потребуется для базового освоения этого функционала в ПУБ, сможете ли провести обучение в этом объеме?
4 Итоговая цена вопроса.
Можно в личку.

88-economist > Хмм... Одно дело "семерка" в ДБФ или "восьмерка" файловая.
Совсем другое - обе под SQL.
И переход DBF->SQL (равно как файловая->SQL) с какого-то момента, "вдруг", становится вовсе не добровольным.

90-VZ > Валера, я не понял, при чём тут твой мессидж про СУБД к (88)? И при чём тут переходы всякие? Затраты на лицензии всяческие и на всякие серверы 1С:Предприятия - фигня вопрос для более-менее рентабельного свечного заводика.

(89): +100500. Но с одной поправочкой: Не в личку, а сюдыть. Обществу тоже интересно.

91-DeiMos > "И причем здесь, казалось бы, Лужков?"
Я не о лицензиях. Я об SQL, который настраивать надоть. Вот ведь штука какая...
Или бум иметь два sql-сервера?

90-VZ >да пофиг. Однозначно развивать и даже поддерживать обмен с ПУБ будет некому. Семерка мертва.

93-Reaper > Я вот имею связку 77-8.3. С регулярной любовью. Но инициатор совокуплений не я :(

(93) как так 7-ка мертва? конфигурация Производство+Услуги+Бухгалтерия последний релиз 7.70.352 дата выхода 26.05.2014 17:31

[quote=VZ;35584369]SQL, который настраивать надоть[/quote]

- Вот с этого места можно подробнее?
Чего там настраивать-то?

96-DeiMos > Есть мастера более высокого разряда: [url]http://forums.kuban.ru/f1040/ne_mogu_ponyat-_chto_ne_tak_s_nastrojkami_1c_ili_sql_ili_eshe_chego-5809169.html[/url]

95-xxc > А я вот в конфе ЗиК обнаружил ошибку, связанную именно с обменом. Причем еще с БП2. А, может быть, и с БП1.6 (не смотрел).
Тянется до самого последнего релиза.
О как.

(98) интереса ради развернул демку 7.70.352 размер всего каталога ИБ < 110 МБ, из них > 54,5 МБ занимает Регламентированная (бухгалтерская) отчетность, самая огромная DBF - 1SCONST.DBF 320 КБ

[URL=http://saveimg.ru] [IMG]http://saveimg.ru/pictures/18-06-14/f5af12dfcf966a35c4dbd7d1c7ea2f50.jpg[/IMG][/URL]

до "недобровольного перехода DBF->SQL" (90), который необходим при приближении какой либо из DBF к 2 ГБ, еще работать и работать. вам конечно виднее, но как по мне, так хоронить (93) 7-ку преждевременно.

Руководство по ведению учета (89) в сети обнаруживается :)

Бессмертный пони - я не 1С-ник, но потролить люблю :-) По вопросам

1) Не возьмусь, но у себя сделал бы

2) Сколько чистого рабочего времени это потребует - 80 человек-часов.
- синхронизировать номенклатуру и склады - не обязательно, можно загрузить и дописывать.
- счет в заказ на пр-во - писать в 7-ке
- готовую продукцию на склад в БП - да, можно загружать хоть через TXT
- позаказная себестоимость в бухучете - зачем?

3. Сколько времени для освоения этого функционала 5-ю работниками - 40 чел-часов

4. Итоговая цена вопроса - как внедренец я бы запросил "за постановку и автоматизацию уровня MRP" - тысяч 150.

VZ - 77, чисто DBF-ы >3.5 Гб, 26 обычных клиентов - терпимо. Хоть и соглашусь что рисково. WRAP-ить можно.

"Учёные... выяснили, что люди всегда настроены излишне оптимистично: они говорят, что какой-то процесс займет два дня, а на самом деле уходит десять, или говорят — два месяца, а уходит больше тридцати пяти лет. Или, например, проводился опрос учащихся, к какому сроку они уверены на 50%, 75% и 99%, что завершат домашнюю работу. И лишь 13%, 19% и 45% из них завершают её к указанному времени. Учёные обнаружили причину. Испытуемых попросили описать идеальный и типичный варианты развития событий. И полученные описания были практически одинаковы. Если вы попросите человека спланировать что-то на будущее, то он обычно, представляя себе наиболее вероятный ход событий, забывает про возможность ошибок или неожиданностей. Большинство испытуемых не закончили работу к сроку, в котором были уверены на 99%, так что фактические результаты оказались хуже даже наихудшего сценария. Такой феномен называется ошибкой планирования, и лучший способ её избежать — учитывать, сколько времени занимало выполнение какой-либо работы в прошлом. То есть смотреть на процесс со стороны. Если же вы взялись за что-то впервые и существует возможность неудачи, вы должны быть очень-очень-очень пессимистично настроены. Настолько пессимистично, чтобы результаты точно превзошли ожидания."

102-VZ >программистам рекомендуют сроки на 7 умножать

95-xxc >ну подумаешь, платежки подправили. семерка может и не мертва, но подобна пациенту на ИВЛ - особо никуда не двинешь. ее даже установить нельзя без извращений, а чтобы дистрибутивы конфигураций разворачивать, я виртуальную машину держу

101
Из "Законов Мерфи"

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

(104) образное мышление и красноречие это прекрасно, но факт остается фактом: 7-ка легка, проста, функциональна и жива.

106-xxc >Ага, как Кобол. Я сам эксплуатирую несколько инсталляций семерки, но делать новые проекты не вижу смысла.
Точно так же у меня один комп на Pentium-133 работал до недавнего времени, но искать другие по комиссионкам я не собираюсь.

(107) что-то несоображается: разве Управление торговлей 11 и Бессмертный пони - это одно лицо? иначе непонятно, к чему последние фразы и умозаключения 1) делать новые проекты не вижу смысла 2) искать другие по комиссионкам я не собираюсь. разве кто-то настаивал в том, чтобы Управление торговлей 11 увидел смысл или что-то искал?

108-xxc >тогда уж пиши "разве Reaper - одно лицо?". Это он написал, что семерка мертва. Я поддерживаю, впрочем.
А последние фразы, про Pentium-133, называются "аналогия". Это такой полемический прием.
"Все понимать буквально" - это тоже полемический прием, но он у тебя не удался, извини

106-xxc > Во-первых, "семерка" легка для относительно простой структуры метаданных (вспоминая комплексную). Функциональность обрезана для современных технологий ("облака", планшеты). Жива для относительно небольших баз: без внешних костылей (типа 1cplus, sqlite) будет вязнуть в большой базе.
Физически - да, жива. Но морально устарела: у нее нет ниши, где её применение имело бы явное преимущество.

"Пациент скорее мертв, чем жив".

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

Если раньше были звонки с просьбами о работах по 77, на которые приходилось вежливо объяснять, что нам это не интересно, то сейчас пошли обращения о переходах на 8, потому как "уже несколько лет не можем найти специалиста, который бы помог разобраться с программой". Сдохла. Пусть дискетки ей будут пухом!

[quote=VZ;35598192]без внешних костылей (типа 1cplus, sqlite) будет вязнуть в большой базе[/quote]

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

(113+): Ещё неизвестно, что больше "вязнет" на крупных базах: 1Сv77 или 1Сv8.

113-DeiMos > Ну, во-первых, к "костылям" можно смело отнести и работу с не MSSQL. Поэтому про них не говорим.
В "семерке" есть одна большая проблема: блокировки. И она усугублена тем, что абсолютно все документы привязаны к одной таблице. А так же тем, что все периодические значения (те, что в "восьмерке" разнесены по регистрам сведенияй и характеристик) так же все завязаны на единственную таблицу. Хорошо, что регистры накопления есть.
Опять же, поля типа binary и memo штатно не задействованы: их можно организовать и использовать, но не штатным образом.
А главное, "семерка" крайне неэффективно использует функционал SQL. Ну очень неэффективно.
Может, и можно все это скомпенсировать тщательнейшей разработкой структуры. Только такие мастера уверенно и ладно костыли прикрепят ;)

Мауса на вас нет. /Вот он придет со своим супермонстром и убъет снеговика...

+115 И не надо про "супермностров": разрядность чисел на производительность и функционал никак не влияют. Скромная и нищая аптечка требуют более продвинутого функционала, что пользует Миллер на своем планшете стоимостью 200 миллионов.

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

Мертвых врагов не вспоминают...

(110) Во-первых, "семерка" легка для относительно простой структуры метаданных (вспоминая комплексную).


бред какой то. Наверное, автар селедки перел

Если примеры, когда файловая лучше SQL-ной. Вот мы, проанализировав трафик на файловой 77 пришли к выводу, что 1/4 нагрузки - это активно гоняемые отчеты 10-ти из 30 пользователй за "позапрошлые периоды" и по разным РУ. Сделали автобэкап "за вчера" на другие серваки - и уменьшили нагрузку на главный сервер на 50%, а "скорость 1С" по словам всех юзверей "заметно выросла". В случае с SQL-версией это было бы дольше, дороже, и медленнее.

И еще: одну и ту же задачу по десятку тяжелых запросов по проводкам решали на 8 и 7. После того как нашли и попробовали 7+1csqlite - от 8-ки отказались.