Хочется к одному документу иметь несколько табличных частей, как в 8-ке.
Кто то делал подобное??

Я делал так:

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

vinogradoff писал(а) 26. Марта 2012 :: 05:33:

Набор данных для табличных частей различный. по этому и нужно разнести по разным таблицам, но все это относится к одному документу.

Satans Claws писал(а) 26. Марта 2012 :: 07:56:
Первый вариант - это и есть то, что описано мною выше, за исключением того, что "служебных" документов может быть более одного типа.
Второй вариант вызывает больше проблем, чем преимуществ. Сталкивался, но сам не применял, ввиду повышенной сложности и больших потерь в скорости при обработке.
Третий вариант тоже кое-где применяется, но это полезно только в том случае, когда данные не должны отражаться в движениях по регистрам.

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

Пример из жизни (вариант 1):
Переоценка в базе швейного производства мною была реализована следующим набором документов:

• Шапка - В шапке содержатся только параметры отбора и процент опрепроизводственных расходов с указанием статьи. ТЧ содержит список подчиненных документов.
• Лоскуты - ТЧ содержит список лоскутов с ценами (старыми, средними и новыми) и плотностями (аналогично).
• Материалы - по составу почти как и лоскуты, но не участвует в непосредственной переоценке. Используется в промежуточных расчетах.
• Номенклатура - список номенклатуры с новыми ценами.
• Элементы - нормы расходов со ссылкой на номенклатуру, элемент и новую стоимость. Шапка содержит вид норматива.

В среднем переоценка создавала до 50 документов и более.

Для вязального производства схема была аналогичной, однако не требовался документ для лоскутов, но док для материалов производил переоценку этих материалов.
В вязалке переоценка формировала около 15-20 документов за раз.

Количество обосновано составом номенклатуры. В вязалке она порядком меньше.

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

Satans Claws писал(а) 27. Марта 2012 :: 02:52:
Я говорю о том, что любой документ, делающий движения, должен хранить в себе данные для этих движений.

Satans Claws писал(а) 27. Марта 2012 :: 02:52:
Видимо, сказывается то, что крайне редко приходится сталкиваться со скульной семеркой, а из этого следует, что доп. данные хранятся не в той же базе, а значит могут терять синхронизацию по разным причинам.

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

Dmitry The Wing писал(а) 27. Марта 2012 :: 03:25:


Ну, тебя же не смущает, что данные документа сама 1С хранит аж даже в 3х таблицах.
Вообще, на мой взгляд - это в корне направильный подход. Ибо у тебя 1 учетный объект (1 учетное событие) - и ВСЕ движения должны делаться этим объектом. Да, для своего проведения он заглянет в доп. таб части (и абсолютно без разницы, как они будут реализованы).
А рассогласование в твоем случае возможно не менее, чем в моем: распровели документ доп части - и все.
Да и с проверками целостности документа на момент проведения хуже - будут или избыточные перекрестные проверки, или каждый документ проверяет целостность только своего куска данных (что никак не гарантирует целостность всего документа).
А обеспечение одновременного проведения-распроведения - тоже то еще развелечение.

Касательно групповых обработок - вот им, как раз, и не положено знать про доп таблицы и связные документы.
Групповое перепроведение должно сказать ровно 1 слово: "Проведись!". И документ должен провестись. Целиком и полностью.

PS про доп таблицы скуля - просто последние лет сколько-то основные базы исключительно на скуле и как-то само собой разумеющееся уже. (Более того - я с прямыми запросами под ДБФом даже и не работал).
А так - принципиально разницы нет, можно создать свои ДБФки и хранить данные в них, чтоб из ДБФной базы не цепляться к непонятному СКЛ-серверу.

Dmitry The Wing писал(а) 26. Марта 2012 :: 10:05:



А почему, скажем, под ТЧ_Номенклатура не сделать реквизит шапки? Я так понимаю, этот документ в ТЧ будет ровно один.
Да и ТЧ_Лоскуты и ТЧ_Материалы - есть ощущение, что тоже по одному.
Вот ТЧ_Элементы, похоже, да - их будет много.

Или это для обхода ограничения по количеству строк в документах (10К, вроде)?

Satans Claws писал(а) 27. Марта 2012 :: 04:23:
С этим проблем особых нет. Просто на кнопки "ОК" и "Провести" вешается определенная функция, которая сначала вызывает запись и все, что с этим связано, включая все необходимые проверки. Затем проводит документ-шапку (здесь отрабатывает обработка проведения). И в случае успеха проведения вызывает проведение всех подчиненных документов. Если хоть один подчиненный не провелся - у всех снимается проведение, как и у шапки.
Также не стоит забывать о перепроведении, т.е. эта функция вызывается и из ПриЗаписи, в зависимости от контекста вызова.

Satans Claws писал(а) 27. Марта 2012 :: 04:23:
В качестве механизма прямого доступа предпочитаю использовать 1sqlite, а ему пофик, дбф у тебя или скуль.

Satans Claws писал(а) 27. Марта 2012 :: 04:23:
И огребешь кучу проблем одновременного доступа. Именно их и решает использование SQL-сервера.

Satans Claws писал(а) 27. Марта 2012 :: 04:31:
Тут все зависит от объема переоценки.
Если переоценивается только 1 артикул, то одного документа для номенклатуры за глаза хватит, а если группа - то уже может не хватить.
Лоскуты - это обезличенные материалы - элементы нормативов, а в одно изделие используется от 2 до 5 лоскутов, т.е. документов может быть в 2-5 раз больше (может и не быть при повторении лоскутов).
Материалы - это конкретные полотна и другие материалы, которые группируются в лоскуты, а это увеличивает их число в сотни раз. Понятно, что в переоценке используются только существующие на остатках материалы, но их тоже может быть много.

Satans Claws писал(а) 27. Марта 2012 :: 04:31:
В дбф версии поле номера строки имеет тип nwmeric(4,0), т.е. максимальное число строк без нарушения индексов - 9999.