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

потому что программно хрен сведёте по UIDам что старые что новые объекты к тому что должно получиться

41-Зелёный тролль > ты наверно ошибся единицей измерения?
за 1500 $ за квартал..?

новые могут быть тоже одним и тем же оговором/контрагентом и т.д. с разными UIDами соответственно

43-Чучундер > оптовикам скидки, но тут попробовал перебивать заказы покпателей по вбитой номенклатуре и контагентам - скорость порядка 10 заказов в час. номенклатуры в заказе порядка 5 позиций. так что хрен там 1500$ за квартал. 1500 тыс рублей за квартал (в России живём).

вбивал сам из УТ10 в УТ11, непрерывно. там ещё куча доп реквизитов в нагрузку, что в заказ, что в номенклатуру, что в контрагентов с размещением по складам и т.п. так что говорю сугубо предметно.

енеджеры, типы цен, ставки НЛС, соглашения и т.д. и т.п.

менеджеры* ставки НДС*

и да, кто согласится переносить документы из УТ10 в УТ11 - гнать в шею. перенести можно, но получится полная хрень.

только остатки. и то руками править, зная пользователей.

35-USSR > потому что ты как все одноэсники - тупой
Как и я
Одноэсина сделала правильно
Ибо выбор договора в документ - операция интерактивная
И нет никакой гарантии что юзверь выберет среди нескольких договоров правильный
У меня так давно в тисе прикоучены виды договоров - опт, экспорт, комиссия...,
А с учетом того что например золодильники продаются по договору1 а ковры по договору2 с одним клиентом - то вангую что скоро будет некий регистр сведений, в котором будет описываться товарная матрица договора - м.б не перечислением клиент-договор-номенклатура, а хотя бы на уровне видов/групп товаров

45-Зелёный тролль > а тупо напечатьтать в жксель первички из базы
А во вторую базу тянуть их из жкселей мокселей - на исе такие есть

51-Чучундер > исполнитель и должен быть тупым. так что мы правильные. он (исполнитель, он же юзер 1Са) должен тупо указать реквизиты.
проблема в том что топой исполнитель в УТ10 <> тупому исполнителю в УТ11. они [filolog]сцуко[/filolog] разные сильно. и только тупые 1Сники могут поятнуть на двух тупых исполнителей. но не программно, а вручную.

53-Зелёный тролль > как он тебе тупо укажет ПРАВИЛЬНЫЕ реквизиты если он ТУПОЙ?
Все будет мигрировать в сторону настройки шаблоноспецификаций некотороых, и юзвери на большинство операций будут нужны чтобы по тлф ответить или кнопку старт нажать по команде из телефона
Сложные задачи будут отданы на откуп вменяемому юзверю которых в конторе будет необходимый минимум, а сложных задач их мизер есть

поскольку всё таки каким-то ограниченным правилам прописанным подчинюятся и УТ10 и УТ 11, то управляющая функция 1Сника состоит в том, чтобы осознатиь и адаптировать процесс эволюции товпого юзера УТ10 к тупому юзеру УТ11. сложность в том, что эта осознание приходит только в процессе работы обоих юзеров. то есть когда они вколачивают то что обычно - куда и что им надо вколотить. и есть всякие достаточно разные ситуации, которые предусмотреть программно. в 100 раз сложнее. нужно изменение методики ввода информации, с учётом её реализации в новом ПП.
реально перенос доков занял полгода и результат не был принят заказчиком, не удовлетворил. а ручной ввод - норм. с учётом всякого разного, которое решается на месте, интерактивно.

54-Чучундер > да нету свободных юзверей достаточно обычаемых у заказчика. они стоят прилично и загружены по самое то место. зато 1Сник могёт в процессе наблюдения за юзверями правильно адаптировать и реорганизовать их действия применительно к новому ПП.
собственно я это уже не первый раз практикую.
девки реально освоили кнтрл+с и кнтрл+в.
говорю только что откуда брать и куда вставлять. отчеты сам анализирую. отчеты кстати тоже разные. эту мысль также до заказчика иногда приходится доносить. что те цифры которые он видел тут, теперь где-то там.

56-Зелёный тролль > ну правильно
В итоге если автоматизировать правильно то в фейсе ручного ваода надо нахрен позапиливать в ноль тире попрятать кучу ненужных по умолчанию настроенных реквизитов, остальное делается тупым юзверем

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

57-Чучундер > надо ещё определиться какие реквизиты ненужные... причём если они не нужные сейчас, не значит что они не нужные вообще. заказчик скажет "о! а почему! я хочу! так и надо!"
в общем, мне уже программирование на 1Се в 8.3 совсем не прёт. так накрутили, что уже тупго пользоваться и то надо перечиваться по полной. а ведь есть технологии работы юзверей, методики учёта (ТМЦ, денег, долгов, расходов и т.п.) теперь любой переход с 1С на 1С - проект. поэтому на 77 и сидят люди. проще своё можифицировать, чем миллионы в замену ПО на более новое вливать, причём с тем же или худшим результатом, или вообще... без результата. как обычно бывает.
вот как например, программер перенёсший доки, смогёт объяснитл юзерам тупым, как им теперь работать? да никак. и закзчик не знает как. никто не знает. нужен чел который сам всё попробует, осознает, адаптирует. без кодинга и открывания конфигуратора. тупо технология работы юзверей с ПО. а уже потом всякие ограничения прав, допобработки, печатные формы и т.п. - которое уже юзеры тупые придумают сами.

Ну понаписали. Речь шла лишь про разрез по фирмам основного договора. Я не увидел особой пользы для бухгалтера. Специально обученных продвинутых юзеров я не встречал, может в Москве и есть. С договорами тоже особенных проблем нет, ну пару раз в квартал перепутают договор в выписке, потом построят оборотку, увидят незакрытые 62.01 и 62.02 и поправят.
Программировать у меня тоже особого восторга не вызывает. Тут для меня несколько причин.
1 - старый стал и по большому счету ничего нового. Поработав на С, С++, VFP, трудно найти какой то особый кайф. Хотя платформа местами вызывает уважение
2. Некий разрыв между платформой и типовыми. На мой взгляд (возможно ошибочный) квалификация разработчиков типовых ниже, чем платформы. Код стал очень запутанным и сама концепция открытого кода уже мало что дает при отсутствии мало мальского документирования прикладного решения.
3 - в продолжение п2. Делаешь внешнюю печатную форму из встроенной и надо поправить совсем мизер. И что же?
Приходится тащить кучу процедур и функций из различных общих модулей. Эти процедуры почему то не объявлены экспортными, по моему часто дублируются, много очень похожих. Могу ошибаться, но при внешней стройности внутри царит бардак. Если я хочу лишь немного что-то изменить, то повторное использование кода должно быть минимальным.
4 - совершенно бесцеремонные изменения структуры метаданных. Количество реквизитов с волшебным словом "Удалить" уже просто зашкаливает. Все таки культура проектирования должна быть повыше, чем просто "захотел и поменял". Так даже одинокие фрилансеры не делают

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

61-USSR > А на чем они работают?

Моя огромная организация работает на 1С77.

60-USSR > присоединяюсь к твоему мнению.
именно поэтому и я не на 8-ке - как программер.
ну неинтересно мне копаться в очередном гуано
пусть молодые копаются удобряются для роста
а я старый
мне - влом

60-USSR > "[em]Приходится тащить кучу процедур и функций из различных общих модулей[/em]" - чтоб не тащить (или тащить поменьше), обрати внимание на модуль менеджера документа (именно там подготавливаются данные к общим модулям печати).
А обращаться к процедурам менеджера можно точно так же, как и к общим модулям.
Комбинируй ;)

65-VZ > не знаю как в 8-ке
Но подготовить данные это можно сказать примерно половина если не меньше в сабжекте "печать документ"
Могу ошибаться

(65)Так я и комбинировал. Печать счета-фактуры по количеству процедур и функций производит просто ужасающее впечатление. А казалось бы надо полтора десятка строк в шапку и полтора десятка колонок табличной части. Ведь сама природная сложность счета-фактуры осталась прежней.
А управляемые формы - отдельная песня, приходится иногда простые вещи через одно место....Но тут я не могу судить можно ли было сделать иначе
(66)подготовить в 8.3 - это наверное 90% работы ) Приятностей и удобств много, но БП3 - это уже самопожирающий себя монстр
С договорами разрулил, но там учет в БП3 начинался "с нуля". А вот у другого товарища - засада. Есть 2-3 десятка общих договоров (покупатель / поставщик), база на бух 7.7 из которой надо перенести остатки в БП3, но из нее переносили приходы в торговлю, их которой теперь и будет экспорт в БП3. С договорами короче основной геморрой, даже не знаю как поступить.
Видимо надо базу Бух 77 сначала свернуть, а потом уже разрезать конфликтные договоры по покупатель/поставщик, иначе менять документы во всей базе. А может перенести остатки на начало года как есть, с общими договорами, а потом уже в БП3 и торговле синхронно разрезать эти злосчастные договоры. Тут был у одного товарища, там 2 разных франя делали ему внешнюю ТТН для УТ10. Франи то разные, а ТТН практически близнецы, обе недоделанные и обе по моему не из встроенной обработки

(65)Модуль менеджера же не самодостаточный, он как раз и тянет много из общих, типа "УчетНДС". Ну и проблема, что у самой внешней обработки, в отличие от документа, нет модуля менеджера )

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

69-USSR > я как то представлял себе, что например в документ отгрузка прописали договор типом "с поставщиком" - при проведении документа - пофиг программно или интерактьивно - должен отработать какой-нить "менеджер" и стопорнуть это дело..
а получается не так..?

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

Люди десятки лет вели по договорам как было, и не парились. Нашлись реформаторы.

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

А если по сабжу - данная проблема сабжа в 1С77 решена давным-давно.

Переходите на 1С77.

И вовсе не через УРБД.
Именно для вот таких внезапных катастрофических случаев, как в сабже, есть спец-обработки.

Которые можно применить к двум сливаемым (вообще независимым) базам и получить идеальный результат.