0
- 19.01.2016 - 16:15
|
Нужен методологический совет. Позвонила знакомая, возможно понадобится ей помощь. Жила-была база БП 3.0, горя не знала, обхем наживала. Но в один прекрасный солнечный день взяли ее домой 2 бухгалтера, и стали базы у каждго буха свое добро наживать. А теперь встретились бухи в горькой печали и не знают как им обратно 2 базы в одну засунуть ) Как проще всего провернуть такое мероприятие, желательно максимально штатными средствами. У меня мысли есть, но хочется услышать умные ) Просто может кто уже что-то подобное делал. Базы жили раздельно около квартала, за главную можно взять например первую. Конфигурации будем считать типовыми, если что обновить до одного одинакового релиза не проблема
| |
41
- 31.01.2016 - 01:58
| я к тому, что я готов всё сделать за 1500 тыс руб за квартал. срок - месяц за 1ый квартал, дальше стоимость квартала умножается на 2 в геометрической прогрессии. | |
42
- 31.01.2016 - 02:02
| потому что программно хрен сведёте по UIDам что старые что новые объекты к тому что должно получиться | |
43
- 31.01.2016 - 02:02
|
41-Зелёный тролль > ты наверно ошибся единицей измерения? за 1500 $ за квартал..? | |
44
- 31.01.2016 - 02:03
| новые могут быть тоже одним и тем же оговором/контрагентом и т.д. с разными UIDами соответственно | |
45
- 31.01.2016 - 02:05
| 43-Чучундер > оптовикам скидки, но тут попробовал перебивать заказы покпателей по вбитой номенклатуре и контагентам - скорость порядка 10 заказов в час. номенклатуры в заказе порядка 5 позиций. так что хрен там 1500$ за квартал. 1500 тыс рублей за квартал (в России живём). | |
46
- 31.01.2016 - 02:06
| вбивал сам из УТ10 в УТ11, непрерывно. там ещё куча доп реквизитов в нагрузку, что в заказ, что в номенклатуру, что в контрагентов с размещением по складам и т.п. так что говорю сугубо предметно. | |
47
- 31.01.2016 - 02:07
| енеджеры, типы цен, ставки НЛС, соглашения и т.д. и т.п. | |
48
- 31.01.2016 - 02:08
| менеджеры* ставки НДС* | |
49
- 31.01.2016 - 02:11
| и да, кто согласится переносить документы из УТ10 в УТ11 - гнать в шею. перенести можно, но получится полная хрень. | |
50
- 31.01.2016 - 02:11
| только остатки. и то руками править, зная пользователей. | |
51
- 31.01.2016 - 02:27
|
35-USSR > потому что ты как все одноэсники - тупой Как и я Одноэсина сделала правильно Ибо выбор договора в документ - операция интерактивная И нет никакой гарантии что юзверь выберет среди нескольких договоров правильный У меня так давно в тисе прикоучены виды договоров - опт, экспорт, комиссия..., А с учетом того что например золодильники продаются по договору1 а ковры по договору2 с одним клиентом - то вангую что скоро будет некий регистр сведений, в котором будет описываться товарная матрица договора - м.б не перечислением клиент-договор-номенклатура, а хотя бы на уровне видов/групп товаров | |
52
- 31.01.2016 - 02:29
|
45-Зелёный тролль > а тупо напечатьтать в жксель первички из базы А во вторую базу тянуть их из жкселей мокселей - на исе такие есть | |
53
- 31.01.2016 - 02:31
|
51-Чучундер > исполнитель и должен быть тупым. так что мы правильные. он (исполнитель, он же юзер 1Са) должен тупо указать реквизиты. проблема в том что топой исполнитель в УТ10 <> тупому исполнителю в УТ11. они [*****] разные сильно. и только тупые 1Сники могут поятнуть на двух тупых исполнителей. но не программно, а вручную. | |
54
- 31.01.2016 - 02:36
|
53-Зелёный тролль > как он тебе тупо укажет ПРАВИЛЬНЫЕ реквизиты если он ТУПОЙ? Все будет мигрировать в сторону настройки шаблоноспецификаций некотороых, и юзвери на большинство операций будут нужны чтобы по тлф ответить или кнопку старт нажать по команде из телефона Сложные задачи будут отданы на откуп вменяемому юзверю которых в конторе будет необходимый минимум, а сложных задач их мизер есть | |
55
- 31.01.2016 - 02:39
|
поскольку всё таки каким-то ограниченным правилам прописанным подчинюятся и УТ10 и УТ 11, то управляющая функция 1Сника состоит в том, чтобы осознатиь и адаптировать процесс эволюции товпого юзера УТ10 к тупому юзеру УТ11. сложность в том, что эта осознание приходит только в процессе работы обоих юзеров. то есть когда они вколачивают то что обычно - куда и что им надо вколотить. и есть всякие достаточно разные ситуации, которые предусмотреть программно. в 100 раз сложнее. нужно изменение методики ввода информации, с учётом её реализации в новом ПП. реально перенос доков занял полгода и результат не был принят заказчиком, не удовлетворил. а ручной ввод - норм. с учётом всякого разного, которое решается на месте, интерактивно. | |
56
- 31.01.2016 - 02:43
|
54-Чучундер > да нету свободных юзверей достаточно обычаемых у заказчика. они стоят прилично и загружены по самое то место. зато 1Сник могёт в процессе наблюдения за юзверями правильно адаптировать и реорганизовать их действия применительно к новому ПП. собственно я это уже не первый раз практикую. девки реально освоили кнтрл+с и кнтрл+в. говорю только что откуда брать и куда вставлять. отчеты сам анализирую. отчеты кстати тоже разные. эту мысль также до заказчика иногда приходится доносить. что те цифры которые он видел тут, теперь где-то там. | |
57
- 31.01.2016 - 02:46
|
56-Зелёный тролль > ну правильно В итоге если автоматизировать правильно то в фейсе ручного ваода надо нахрен позапиливать в ноль тире попрятать кучу ненужных по умолчанию настроенных реквизитов, остальное делается тупым юзверем | |
58
- 31.01.2016 - 02:48
| единственно что типовые переносы - кривые. приходится их сначала напильником. но если заказчик не тупой. то даже сам потом могёт инструментом пользоваться. тут главное нужный момент не пропустить - обыяно до ввода документов. а вводить день доки. потом как-то откатыывать, менять исходные данные на нужные и перепроводить введённое не каждый заказчик самостоятельно освоит и сделает. самому проще, быстрее и радостнее отдавать заказчику уже правильное. | |
59
- 31.01.2016 - 02:56
|
57-Чучундер > надо ещё определиться какие реквизиты ненужные... причём если они не нужные сейчас, не значит что они не нужные вообще. заказчик скажет "о! а почему! я хочу! так и надо!" в общем, мне уже программирование на 1Се в 8.3 совсем не прёт. так накрутили, что уже тупго пользоваться и то надо перечиваться по полной. а ведь есть технологии работы юзверей, методики учёта (ТМЦ, денег, долгов, расходов и т.п.) теперь любой переход с 1С на 1С - проект. поэтому на 77 и сидят люди. проще своё можифицировать, чем миллионы в замену ПО на более новое вливать, причём с тем же или худшим результатом, или вообще... без результата. как обычно бывает. вот как например, программер перенёсший доки, смогёт объяснитл юзерам тупым, как им теперь работать? да никак. и закзчик не знает как. никто не знает. нужен чел который сам всё попробует, осознает, адаптирует. без кодинга и открывания конфигуратора. тупо технология работы юзверей с ПО. а уже потом всякие ограничения прав, допобработки, печатные формы и т.п. - которое уже юзеры тупые придумают сами. | |
60
- 31.01.2016 - 06:20
|
Ну понаписали. Речь шла лишь про разрез по фирмам основного договора. Я не увидел особой пользы для бухгалтера. Специально обученных продвинутых юзеров я не встречал, может в Москве и есть. С договорами тоже особенных проблем нет, ну пару раз в квартал перепутают договор в выписке, потом построят оборотку, увидят незакрытые 62.01 и 62.02 и поправят. Программировать у меня тоже особого восторга не вызывает. Тут для меня несколько причин. 1 - старый стал и по большому счету ничего нового. Поработав на С, С++, VFP, трудно найти какой то особый кайф. Хотя платформа местами вызывает уважение 2. Некий разрыв между платформой и типовыми. На мой взгляд (возможно ошибочный) квалификация разработчиков типовых ниже, чем платформы. Код стал очень запутанным и сама концепция открытого кода уже мало что дает при отсутствии мало мальского документирования прикладного решения. 3 - в продолжение п2. Делаешь внешнюю печатную форму из встроенной и надо поправить совсем мизер. И что же? Приходится тащить кучу процедур и функций из различных общих модулей. Эти процедуры почему то не объявлены экспортными, по моему часто дублируются, много очень похожих. Могу ошибаться, но при внешней стройности внутри царит бардак. Если я хочу лишь немного что-то изменить, то повторное использование кода должно быть минимальным. 4 - совершенно бесцеремонные изменения структуры метаданных. Количество реквизитов с волшебным словом "Удалить" уже просто зашкаливает. Все таки культура проектирования должна быть повыше, чем просто "захотел и поменял". Так даже одинокие фрилансеры не делают | |
61
- 31.01.2016 - 06:23
| (60)БП3 по моему уже просто перегружена функционалом, в ней скоро уже пирожки на обед заказывать можно. Все-таки надо разграничивать прикладное решение для малых и средних фирм и для огромных организаций. Но огромные (типа нашего трубного завода или Мечела) не работают на 1С | |
62
- 03.02.2016 - 00:27
| 61-USSR > А на чем они работают? | |
63
- 03.02.2016 - 00:28
| Моя огромная организация работает на 1С77. | |
64
- 03.02.2016 - 00:36
|
60-USSR > присоединяюсь к твоему мнению. именно поэтому и я не на 8-ке - как программер. ну неинтересно мне копаться в очередном гуано пусть молодые копаются удобряются для роста а я старый мне - влом | |
65
- 03.02.2016 - 00:48
|
60-USSR > "Приходится тащить кучу процедур и функций из различных общих модулей" - чтоб не тащить (или тащить поменьше), обрати внимание на модуль менеджера документа (именно там подготавливаются данные к общим модулям печати). А обращаться к процедурам менеджера можно точно так же, как и к общим модулям. Комбинируй ;) | |
66
- 03.02.2016 - 03:22
|
65-VZ > не знаю как в 8-ке Но подготовить данные это можно сказать примерно половина если не меньше в сабжекте "печать документ" Могу ошибаться | |
67
- 03.02.2016 - 04:49
|
(65)Так я и комбинировал. Печать счета-фактуры по количеству процедур и функций производит просто ужасающее впечатление. А казалось бы надо полтора десятка строк в шапку и полтора десятка колонок табличной части. Ведь сама природная сложность счета-фактуры осталась прежней. А управляемые формы - отдельная песня, приходится иногда простые вещи через одно место....Но тут я не могу судить можно ли было сделать иначе (66)подготовить в 8.3 - это наверное 90% работы ) Приятностей и удобств много, но БП3 - это уже самопожирающий себя монстр С договорами разрулил, но там учет в БП3 начинался "с нуля". А вот у другого товарища - засада. Есть 2-3 десятка общих договоров (покупатель / поставщик), база на бух 7.7 из которой надо перенести остатки в БП3, но из нее переносили приходы в торговлю, их которой теперь и будет экспорт в БП3. С договорами короче основной геморрой, даже не знаю как поступить. Видимо надо базу Бух 77 сначала свернуть, а потом уже разрезать конфликтные договоры по покупатель/поставщик, иначе менять документы во всей базе. А может перенести остатки на начало года как есть, с общими договорами, а потом уже в БП3 и торговле синхронно разрезать эти злосчастные договоры. Тут был у одного товарища, там 2 разных франя делали ему внешнюю ТТН для УТ10. Франи то разные, а ТТН практически близнецы, обе недоделанные и обе по моему не из встроенной обработки | |
68
- 03.02.2016 - 04:54
| (65)Модуль менеджера же не самодостаточный, он как раз и тянет много из общих, типа "УчетНДС". Ну и проблема, что у самой внешней обработки, в отличие от документа, нет модуля менеджера ) | |
69
- 03.02.2016 - 05:21
| Прикольно, что программно можно создать приход и отгрузку на один и тот же договор. С извращениями можно даже и руками. Создать приход, записать не проводя его, затем поменять тип договора, создать отгрузку, все провести. Ну и оставили бы нам нерадивым возможность обычной работы с договорами | |
70
- 03.02.2016 - 15:07
|
69-USSR > я как то представлял себе, что например в документ отгрузка прописали договор типом "с поставщиком" - при проведении документа - пофиг программно или интерактьивно - должен отработать какой-нить "менеджер" и стопорнуть это дело.. а получается не так..? | |
71
- 03.02.2016 - 16:11
| (70)Не так, проводит на ура. Но вот если захочешь руками ввести поступление, а договор - покупатель, то просто в списке не будет договора, не сможешь выбрать. И не сможешь поменять вид договора, если есть проведенные документы другого типа.По моему какой то детский сад. Попробовал изменить константу, отключить учет по договорам. Из документа исчез, но аналитика по договору остается и сама придумывает 2 основных по типу расчетов | |
72
- 03.02.2016 - 16:13
| Люди десятки лет вели по договорам как было, и не парились. Нашлись реформаторы. | |
73
- 03.02.2016 - 18:06
| 72-USSR > они вообщем в правильном направлении двигаются. Вообщем по договору с поставщиком не должно быть возможности оформлять отгрузку на покупателя. И блокировка я считаю правильно стоит. другое дело что заблокировано только интерактивная возможность ошибки | |
74
- 03.02.2016 - 20:35
|
А если по сабжу - данная проблема сабжа в 1С77 решена давным-давно. Переходите на 1С77. | |
75
- 03.02.2016 - 20:38
|
И вовсе не через УРБД. Именно для вот таких внезапных катастрофических случаев, как в сабже, есть спец-обработки. Которые можно применить к двум сливаемым (вообще независимым) базам и получить идеальный результат. | |
| Интернет-форум Краснодарского края и Краснодара |