| Регистрация Правила Главная форума Поиск |
| 0
- 02.12.2012 - 19:24
|
1С 7.7 ТИС на терминальном сервере + УРБД Примерно 30 ползователей Хочу избавить от лишнего в-принципе документа, который до этого формтировал один регистр опер.учета и сделать проведение по этому регистру в "родительских" документах: реализация, перемешение, чек ккм, поступление, оприходование, списание, комплектация, строкаавансовогоотчетазакупкатмц. Вот думаю, что лучше: 1. создать реквизит в 11 видах документа - строку неограниченной длины или 2. просто создавать внешний файлик для каждого документа и считывать из него ТЗ при проведении или 3. Создавтаь непроводящийся подчиненный документ с этой табличной частью - но туту очень много всяческих проблем начинает вожникать (в т.ч. с пометкой на удаление, распроведением, изменением и т.д.). ЕЩЕ СУШЕСТВЕННЫЙ МОМЕНТ. МНЕ НУЖНЫ ТОЛЬКО ДВИЖЕНИЯ РЕГИСТРА ,А САМИ "ВТОРЫЕ" ТАБЛИЧНЫЕ ЧАСТИ МНЕ НУЖНО ХРАНИТЬ НО МАКСИМУМ МЕСЯЦ. ЧТО ПОСОВЕТУЕТЕ???     | | |
| 41
- 03.12.2012 - 17:50
|
(38) "если все товары из документа удалили" - если такое сплошь и рядом - что-то надо в консерватории править. Опять же проверку соответсвия родителя и дочки - делать при ИНТЕРАКТИВНОМ закрытии родителя. | | |
| 42
- 03.12.2012 - 17:53
| 39 - VZ Так родительский документ же не удаляется. ПриУдалении не пойдет | | |
| 43
- 03.12.2012 - 18:24
| 42-Путевый лист > Что значит "не пойдет"? Я выше предлагал ссылку на связь располагать именно в родительском, основном документе. Ссылку на всомогательный, дочерний документ, содержащий дополнительную ТЧ. В этом случае, если в ПриУдаленииДокумента делать перехват основного документа, то все логично: по ссылке удаляем сначала вспомогательный, потом основной. Перехватывать же вспомогательный не нужно: раз удаляем - значит, удаляем. Юзер видит его (вспомогательный) только в связке с основным, и удалить документ отдельно не может (скрыть от него журнал достаточно просто). Ну, а для себя, любимого, в административный целях, сделаешь административную обработку. И разрешишь просмотр журнала. | | |
| 44
- 03.12.2012 - 18:39
| 43 - VZ У меня все так сейчас и есть как ты описал+вспомогательный документ сам делает движения регистра. Из-за этого получается много тормозов а главное все становится непрозрачно. Вот как раз от этого я и думал избавиться. | | |
| 45
- 03.12.2012 - 18:51
| Иногда делают из табличной части две ТЗ на форме и через них работают интерактивно. ТЗ перезаполняются при выборе соответствующей закладки. | | |
| 46
- 03.12.2012 - 18:53
|
(38) по 2. - в предопределенной ПриЗакрытии() сверяй ТЧродителя и ТЧ дочки. . опять же если регулярно имеет место быть "товары из документа удалили" - надо или в консерватории что-топравить или смотреть где манипуляции с "подбором" В ТЧ родителя и дочки не состыковываются... Опять же - может быть все-таки проще разбиение строки родителя делать в самом родительском документе...? | | |
| 47
- 03.12.2012 - 19:17
| 44-Путевый лист > А нахрена держатель горшка делает движения? Поручи это его хозяину. От своего отцовского имени. | | |
| 48
- 03.12.2012 - 19:21
|
все одноЭсники - по определению туп... пардон, незаточенные "У меня все так сейчас и есть как ты описал+вспомогательный документ сам делает движения регистра." делай движения в основном документе - проблем будет меньше | | |
| 49
- 03.12.2012 - 19:22
| А нафига два документа сейчас-то? Ладно раньше за быстродействие боролись, но сейчас у меня ноут круче чем сервер в самом моем крутом клиенте 5 летней давности. Одна табличная часть, в которую ссыпаны все реквизиты плюс реквизит "ИмяТЧ". На форму кидаем две таблицы значений, которые при открытии заполняем по данным из табл. части. При записи - сначала сбрасываем из таблиц на форме все в ТЧ объекта. | | |
| 50
- 03.12.2012 - 19:27
|
А давайте посмотрим, сколько таблиц будет задействовано, если хранить доп.тч в подчиненном документе: DH, DT, 1SJOURN, 1SCRDOC, плюс при создании будут использоваться 1SDNLOCK и 1SUIDCTL. Не слишком ли много для дополнительной ТЧ? А если учесть, что у ТС нередки ситуации с конфликтами блокировок, так это вообще непозволительная роскошь. | | |
| 51
- 03.12.2012 - 19:39
| 48 - Helen1986 А ыф читайте внимательно что я пишу. Именно из-за того что решил перенсти проведение в основной документ - я и оздачился где хранить вторую ТЧ, тем более что на один товар может приходится несколько подчиненных строк с метражами | | |
| 52
- 03.12.2012 - 19:42
| 49 - Reaper Ваша идея мне как раз очень по душе, тем более что для самых больших документов - я оставлю как и было - пусть проводится отдельным документом - это для ОтчетаККМ который создается при закрытии кассовой смены | | |
| 53
- 03.12.2012 - 19:58
| 50-Billi > Если движения будет делать один документ, а другой будет выступать регистром значений (в режиме чтения), тормозов не прибавится. А в интерактивном режиме (редактирование) блокировки страданий не вносят. | | |
| 54
- 03.12.2012 - 20:02
|
53-VZ >А на кой вообще ради этого задействовать столько таблиц? Юзать справочник в этой ситуации проще. | | |
| 55
- 03.12.2012 - 20:09
|
53-VZ >Не зависимо от того, будет делать доп. документ движения или нет, в любом случае для сохранения целостности записывать оба документа надо в одной транзакции, чтобы была возможность отката. А следовательно абсалютно не важно один документ делает движения или оба. И в любом случае время записи двух документов будет в два раза больше времени записи одного. | | |
| 56
- 03.12.2012 - 20:11
| 55 - Billi А как ты относишся к варианту Рипера??? Все просто хранить в одно | | |
| 57
- 03.12.2012 - 20:15
| 55 - Billi Все хранить в одной тч, то есть добавить 4 реквизита тч: ИмяТЧ,Метраж,РодБухт, а количество он и в Африке количество | | |
| 58
- 03.12.2012 - 20:15
| 56-Путевый лист >Нормальный вариант. Только вот с интерфейсом малёха помучаешься. :) | | |
| 59
- 03.12.2012 - 20:28
| 58 - Billi Придется конечно, но туту уж ничего не поделаешь. Вот другой вопрос, что мне эта вторая тч нужна недолгое время - вот поэтому и думаю как проще всего сделать. Со второй ТЧ в справочнике я делал План выпуска изделий, но это был один документ в месяц и конечно его юзал один юзер да и не проводил он ничего | | |
| 60
- 03.12.2012 - 20:30
| (50) 1SDNLOCK и 1SUIDCTL - настолько мизерные файлы, что блокировки на них - можно во внимание не принимать.. если нет явных транзакций, которые блокируют (или иных "косяков") | | |
| 61
- 03.12.2012 - 20:31
|
> плюс реквизит "ИмяТЧ" - вы его еще строкой неограниченной длиный сделайте и обновляться будет при каждом перерисовке формы (если криво сделать) - тогда вероятность блокировок - на чтение из общей таблицы блолбов - повысятся...? или на чтение блокировк ане накладывается..? | | |
| 62
- 03.12.2012 - 20:33
| 60 - Чучундер Ну а ты-то что предпочел бы, какой вариант??? | | |
| 63
- 03.12.2012 - 20:33
| 60-Чучундер >тут вопрос не в размере, а в том, что при записи нового документа наглухо блокируется как минимум шесть таблиц. | | |
| 64
- 03.12.2012 - 20:36
| 61 - Чучундер ИмяТЧ - это числовой реквизит имеющий значение 0 или 1 | | |
| 65
- 03.12.2012 - 20:37
| 59-Путевый лист >я тебе уже давно говорю, переходи на скуль, и забудешь проблему размера базы. | | |
| 66
- 03.12.2012 - 20:40
| (63) там доки настолько мизерные, что блокирование этих таблиц ДОЛЖНО БЫТЬ вообще не видно для пользователей. Почти всегда блокировки/затыки выскакивают на общий журнал.. ибо пиплы любыт журналы превращать в подобия отчетов - нахреначать туда отборов, реквизитов с сортирвоками и прочей хни - оно и обновляется долго. | | |
| 67
- 03.12.2012 - 20:40
| (62) пофиг. хоть справочник, хоть подч.док. - ПРОБЛЕМА У ТЕБЯ НЕ В ЭТОМ, как мы уже выяснили.. ;-) | | |
| 68
- 03.12.2012 - 20:42
|
65 - Billi oxo 4 - 30.11.2012 - 20:50 2 поиск яндексом - безуспешно 3 нестандартная, более 10, СКЛ, 7.7 Блокировки общего журнала | | |
| 69
- 03.12.2012 - 20:44
| Цитата:
| | |
| 70
- 03.12.2012 - 20:45
| 68-Путевый лист >ключевое слово: "нестандартная", хз, что там понаписано, умеючи любой скуль можно подвесить, даже в базе с одим пользователем и одним документом. | | |
| 71
- 03.12.2012 - 20:46
| Вопрос в том, что при обилии работающих пользователей в ДБФ базе - как быстро выяснить - если явно словлена транзакция - кто держит ресурс? | | |
| 72
- 03.12.2012 - 20:46
| ПутевыйЛист - у тебя база скульная или дбфная? | | |
| 73
- 03.12.2012 - 20:49
| 72 - Чучундер ДБФ!!! | | |
| 74
- 03.12.2012 - 20:50
| 71-Чучундер >Вроде как одинэска какие-то служебные файлики создает, при блокировке объектов. Может их пошарить? Хотя хз. | | |
| 75
- 03.12.2012 - 21:17
| 74 - Billi 1С правда что-то создает в пользовательском каталоге. но ведь таблицы могут блокироваться разные и влияние блокировок разное. Вот как понять кто какую таблицу заблокировал??? | | |
| 76
- 03.12.2012 - 22:15
|
(74), (75) выяснить просто - делаем обработку, в ней открываем явную транзакцию, создаем (например) Док.Новый(), ставим Предупреждение("Стоп") - смотрим - в папке с базой - в папке юзверя - в темповом каталоге 1Ски - в темповом каталоге системы . - это "рецепт" если точно не знаем создает или нет... . а дальше (если файлики создаются) - уменя есть мелкая мысль... | | |
| 77
- 03.12.2012 - 22:36
|
хихи "ИмяТЧ,Метраж,РодБухт, " однако, сир, партионный учет городите? хранить данные о разбиении по рулонам (рулон считаем партией) глубоко фиолетово где - можно хранить в подчиненном доке - можно добавлять строки в док с одинаковым товаром/материалом и данными ИмяТЧ,Метраж,РодБухт - можно добавить в док скрытые колонки МетражХ,РодБухтХ где Х от 1 до некоторого максимального количества (допустим, максимально из 7 бухт отгрузка) работать это все будет примерно одинаково по скорости и времени блокировки базы. Засада здесь в другом - Редактирование документа задним числом (пока кто то редактирует, другой может хапнуть временно освободившиеся остатки) и привет достоверности остатков по партиям (актуально если отслеживаются остатки по рулонам) - при перепроведении - должны браться теже самые партии (рулоны, авоськи) - еще там куча засад, часть которых разруливается программно, часть - дисциплиной Вся идеология 1це (разбиение по партиям в момент проведения) - изобретение тупоголовых. Для формального списания в целях себестоимости. Реально тем, кому действительно требуется такой партионный учет (по бухтам, по срокам, по ГТД) и кто реально хочет это отслеживать, все разработки 1це до фонаря. Ибо дядя Вася кладовщик режет из той бухты, которая удобно лежит. А не из той, из которой будет списывать программа. Поэтому если хотите иметь реальные остатки - вносите ручками данные, из какого рулона реально отрезали. И приходуйте по рулонам (рулон - партия). Примерно таже задача стоит и при отслеживании остатков по ячекйкам склада. Только в этом варианте - человек должен забирать ТМЦ из указанной ячейки и не проявлять лени (а до этой ячейки ближе идти) | | |
| 78
- 03.12.2012 - 22:41
|
чем то это мне напоминает Чучундера с его предложениеми в (76) [img] http://www.zagony.ru/admin_new/foto/2010-4-9/1270807153/mojj_khozjain__idiot_20_foto_13.jpg[/img] | | |
| 79
- 03.12.2012 - 22:42
|  | | |
| 80
- 03.12.2012 - 22:49
| 77,78 Helen1986 Вы с точностью описали весь мой алгоритм который бессбойно работает у меня аж с 2003 года. Но с увеличением базы и этих самых кабельных товаров - я принял решение - для упрощения и улучшения прозрачности механизма - перенести проведение и все нужные проверки из процедур ПриЗаписи в которых проводится документ бухт в процедуру Проведения ссамого родительского документа. Получается что так все проще, точнее и понятнее | |
Интернет-форум Краснодарского края и Краснодара |
