Как сделать сотрудникам детей

Публикация № 1489073 28.10.21

Задачи пользователя - Адаптация типовых решений

Табличная часть ТабличнаяЧасть регистр сведений РегистрСведений проектирование анализ

За этим провокационным заголовком скрывается небольшая задача, которая, однако, вызвала некоторую дискуссию в кулуарах на последней конференции. Как хранить список детей сотрудников - в табличной части справочника или в регистре сведений?

При кажущейся простоте задачи из анонса, у меня набралось почти два десятка обстоятельств, которые могут повлиять на выбор способа решения. Разумеется, все нижесказанное справедливо для более общей задачи: как "привязать" к элементу справочника таблицу с необъектными данными, неважно, будь то список детей, складов или номенклатуры. Учет детей взят исключительно в качестве примера, для удобства демонстрации.

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

 

Вариант 1: Справочник Сотрудники с табличной частью

 

 

Вариант 2: Справочник Сотрудники2 и регистр сведений Дети с ведущим измерением Сотрудник

 

 

1. Удобство ввода

По удобству ввода информации первый вариант безусловно смотрится выигрышнее: гораздо удобней редактировать данные напрямую в таблице, чем открывать в отдельном окне каждую запись регистра

 

 

против

 

Что можно сделать со вторым вариантом? Добавить таблицу на форму, при чтении формы ее заполнять, а при записи - записывать в регистр. Тогда внешне форма элемента справочника не будет отличаться от варианта 1.

&НаСервере
Процедура ПриЧтенииНаСервере(ТекущийОбъект)
	Набор = РегистрыСведений.Дети.СоздатьНаборЗаписей();
	Набор.Отбор.Сотрудник.Установить(Объект.Ссылка);
	Набор.Прочитать();	
	ТаблицаДети.Загрузить(Набор.Выгрузить());
КонецПроцедуры
&НаСервере
Процедура ПриЗаписиНаСервере(Отказ, ТекущийОбъект, ПараметрыЗаписи)
	Набор = РегистрыСведений.Дети.СоздатьНаборЗаписей();
	Набор.Отбор.Сотрудник.Установить(ТекущийОбъект.Ссылка);
	Набор.Загрузить(ТаблицаДети.Выгрузить());
	Для каждого Запись Из Набор Цикл   
		Запись.Сотрудник = ТекущийОбъект.Ссылка;
	КонецЦикла; 	
	Набор.Записать();
КонецПроцедуры

Обратите внимание: необходимо использовать именно ПриЧтенииНаСервере и ПриЗаписиНаСервере, а не ПриСозданииНаСервереПередЗаписьюНаСервере или ПослеЗаписиНаСервере.

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

Таким образом второй вариант у нас разделился на два: 2а - с редактированием записей регистра и 2б - с редактированием в таблице формы и сохранением набора записей.

2. Отмена изменений 

Предположим, что пользователь, изменив какой-нибудь элемент справочника, хочет закрыть его, не сохраняя данные. Очевидно, что в варианте 1 и 2б это возможно, а в варианте 2а - нет. Также при создании нового элемента в варианте 2а невозможно добавить детей, не сохранив самого сотрудника. Эти два случая могут вызвать у неопытного пользователя вопросы и, возможно, привести к ошибкам.

3. Объектные блокировки

Платформа содержит неплохой механизм объектных блокировок, не позволяющий одновременного редактирования объектов. В нашем случае для варианта 1 все хорошо - два пользователя не могут одновременно редактировать список детей, в варианте 2а - список изменять могут, не могут только одновременно редактировать одну строку, в варианте 2б все печально - во время редактирования таблицы с детьми, другой пользователь или процесс может изменить этот список, и при окончании редактирования все изменения другого пользователя пропадут. Что тут можно сделать? ЗаблокироватьДанныеДляРедактирования здесь не поможет, единственный вариант - запоминать первоначальный набор записей и проверять его перед записью (конечно, проверка и запись нового набора должна сопровождаться управляемой блокировкой).

4. Создание копированием

Про создание копированием разработчики часто либо вообще забывают, либо вспоминают в последний момент. В первом варианте табличная часть с детьми, как компонент объекта, копируется в новый объект автоматически. Со вторым вариантом несколько сложнее. Чтобы получить аналогичный эффект, необходимо для варианта 2б: при создании формы заполнять таблицу данными копируемого объекта, а для варианта 2а: прочитать и запомнить табличную часть копируемого объекта, и при первой записи сотрудника заполнить подчиненный набор записей с детьми.

5. Отборы в списке

Здесь все просто: в первом варианте отбор по табличной части работает "из коробки":

 

 

Во втором варианте это так не работает. Вообще.

6. История изменений

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

 

 

А вот с регистрами все по-другому.

Очевидно, что историю изменений надо смотреть у записей регистра. Так вот, в варианте 2а мы редактируем каждую запись по отдельности, т.е. вместо регистрации одного факта изменения списка детей сотрудников, мы получаем  отдельные, не связанные друг с другом записи в истории изменений. К тому же работа с записью в этом случае идет через менеджер записи, а значит неявно через два набора записей, т.е. одно изменение порождает две записи в истории. Это приводит к тому, что мы в принципе не можем увидеть события изменения - только удаление и добавление, даже в том случае, когда меняется ресурс или реквизит регистра.

 

 

 

В варианте 2б немного иначе. В нем мы записываем записи набором. Здесь платформа понимает, что в каких-то записях набора мы можем изменить ресурс или реквизит, и правильно указывает флаг изменения. Но изменение одного из измерений платформа также считает удалением/добавлением:

 

 

7. Регистрация факта изменений

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

8. Общие реквизиты

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

9. Получение объекта

Цитата с ИТС: "При чтении отдельных реквизитов объекта из базы данных следует иметь в виду, что вызов метода ПолучитьОбъект или обращение к реквизитам объекта через точку от ссылки приводит к загрузке объекта из базы целиком, вместе с его табличными частями." Если табличных частей несколько и/или они объемные по количеству строк или колонок, то это может отрицательно сказаться на производительности. В таком случае вынос табличной части в регистр может дать положительный эффект, особенно если данные табличной части используются достаточно редко.

10. Права доступа

Тут все очевидно: для первого варианта доступ к сотруднику и его детям определяются одними и теми же ролями, для второго - могут быть разные роли. Это может иметь смысл, когда разные пользователи имеют разные уровни доступа. При отсутствии прав на доступ к данным о детях вариант 2а будет работать автоматически, в варианте 2б в коде надо дописать необходимые проверки.

11. Удаление

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

12. Порядок работы с данными

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

13. Данные табличных частей всегда записываются вместе с объектом, в отличие от записей регистра. Это плохо.

Иногда данные табличных частей могут часто и/или интенсивно меняться. Чтобы не перезаписывать каждый раз объект (а при этом тратится время на выполнение обработчиков записи), лучше использовать отдельный регистр.

14. Данные табличных частей всегда записываются вместе с объектом, в отличие от записей регистра. Это хорошо.

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

15. Удаление записей регистра

Нельзя забывать что записи регистра записываются и удаляются наборами. Нужно быть вдвойне осторожным, чтобы при записи пустого набора не забыть и не перепутать элементы отбора. Чтобы создать себе проблему достаточно одной строки  РегистрыСведений.Дети.СоздатьНаборЗаписей().Записать(); Испортить содержимое табличных частей несколько сложнее. 

16. Периодичность

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

17. Нумерация

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

18. Уникальность набора полей

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

19. Длина индекса

 

 

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

И последнее:

Хотя, возможно, оно должно быть первым. Проектирование должно начинаться с построения бизнес-модели и предваряться проведением анализа. При этом должны быть получены ответы на вопросы: 1) являются ли данные таблицы неотъемлемой частью элемента справочника? Например: список номенклатуры для накладной - неотъемлемая часть, а список произведенных ремонтов для оборудования - нет. 2) Согласно методики разработки 1С справочники предназначены для хранения условно-постоянной информации. Являются ли данные таблицы условно-постоянной информацией? 3) Являются ли строки таблицы объектами, на которые могут быть ссылки? Если да – то реализовывать таблицу надо вообще не регистром или табличной частью, а, например, подчиненным справочником. На вопросы необходимо ответить в рамках разрабатываемой системы, с учетом требований к разрабатываемой системе.  В зависимости от ответа на эти вопросы должен быть сделан первоначальный выбор между рассматриваемыми вариантами.

Пример такого анализа:

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

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

 

Что же мы получили в итоге? Как видим, при всей кажущейся простоте поставленной задачи, есть немало обстоятельств, которые необходимо учесть при проектировании качественной системы.  Очевидна необходимость тщательного анализа и требований заказчика, и структуры, и объема данных, а также методики работы с ними. Причем сделать такой анализ надо как можно раньше, чтобы потом не было мучительно больно(с) 

На этом все. Как обычно приветствуются замечания / дополнения / комментарии.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. RustIG 1652 28.10.21 09:26 Сейчас в теме
2. rpgshnik 3317 28.10.21 10:08 Сейчас в теме
В контексте данной задачи сделал бы первый вариант ТЧ в справочнике.

По второму варианту возник вопрос, тип у измерения Имя какой? И как будите решать проблему если родители "веселые" и у них два Пети.
MegasXXX; +1 Ответить
3. Alxby 938 28.10.21 10:17 Сейчас в теме
(2) В рамках примера - абсолютно неважно какой тип у измерения Имя. А если родители "очень веселые", то у них два Пети могут быть еще и близнецами - тогда в списке детей не будет ключа (в рамках этого примера конечно же). Это будет лишним доводом за табличную часть. Интереснее будет ситуация, когда оба родителя являются сотрудниками, - здесь надо серьезно поработать аналитикам, чтобы понять как в рамках разрабатываемой системы правильно учитывать это обстоятельство.
4. Alxby 938 28.10.21 10:35 Сейчас в теме
(3)Кстати, сейчас только мысль пришла, - ситуация, когда у детей совпадает имя и год рождения, не такая уж и нереальная - если у супругов есть дети от предыдущего брака, то они вполне могут быть одного возраста и имени.
8. rpgshnik 3317 28.10.21 11:10 Сейчас в теме
(3) говорят измерение со строковым типом моветон...
10. Alxby 938 28.10.21 11:22 Сейчас в теме
(8)Для регистров с виртуальными таблицами - да. Для длинных строк тоже - да, легко поймать ошибку из п.19.
41. insurgut 206 10.11.21 22:39 Сейчас в теме
(3) ребенок - это физ. лицо, у которого если СНИЛС. И он у всех уникальный. Установить в качестве измерения не строку, а физ. лицо - и проблем никаких с "веселыми" родителями не будет.
43. him1974 13.11.21 18:11 Сейчас в теме
(41) Вы предлагаете всех детей "запихнуть" в справочник физлица? конфигурация ЗУП. Ну ну :)) у нас работает 30 000 + 15 000 ветеранов. Хотите добавить n-ое количество десятков тысяч в справочник? :)
44. Alxby 938 13.11.21 21:34 Сейчас в теме
(41)Дети могут иметь иностранное гражданство, т.е. СНИЛС не будут иметь.
5. ixijixi 1421 28.10.21 10:41 Сейчас в теме
Разработчики ЗУП тоже озадачились этим вопросом, в итоге склонились к подчиненному справочнику, хотя сначала была ТЧ.
Прикрепленные файлы:
Irwin; Jogeedae; DrAku1a; 0x00; +4 Ответить
6. Alxby 938 28.10.21 10:48 Сейчас в теме
(5) Значит для тех задач, которые решает ЗУП, такая структура предпочтительней. Но это разумеется не предел - в данной структуре у элемента РодственникиФизическиеЛица только одна степень родства, а для каких-нибудь систем может быть важно, что Иванов Петя сын одного сотрудника и внук другого. В таком случае напрашивается отдельная таблица для родственных связей. Она тоже может быть как регистром, так и справочником(!).
itoptimum; +1 Ответить
7. rpgshnik 3317 28.10.21 11:08 Сейчас в теме
(6) На предприятие работает Дед1, у него есть сын1 и дочь1, которые так же работают на предприятие, у него есть брат1 у которого есть жена брата1 и они тоже работают на предприятие, у жены брата1 от первого брака родилась дочь2 которая работает на предприятие, у сына1 и его жены сына1 родился сын2, который тоже работает на предприятие и вступил в брак с дочерьею2, у который был сын3 от первого брака Петя, а у сына2 был так же сын4 от первого брака и его зовут Петя, родились в один год сын3 и сын4, так же у дочери2 и сына2 родился общий ребенок сын5. Вопрос как организовать степень родства на первом и втором варианте и как назовут сына5?
Jogeedae; itoptimum; +2 Ответить
9. Alxby 938 28.10.21 11:20 Сейчас в теме
(7)Ну, разумеется, сына5 надо назвать Петя - нельзя нарушать семейную традицию). А как организовать степень родства в системе, зависит от назначения системы и требований к ней. Возможно, что будет достаточно указанной в статье табличной части, а степень родства вообще не будет нужна. А возможен и такой вариант: справочник Сотрудники + справочник ФизическиеЛица, связанный с сотрудниками 1:1 + Регистр сведений или справочник, хранящий связи М:М между двумя элементами справочниками ФизическиеЛица, степень родства и периодом действия этой связи.
rovenko.n; +1 Ответить
11. RustIG 1652 28.10.21 11:25 Сейчас в теме
(7) пора рисовать "как максимум" графы или "как минимум" структуру подчиненности...
rpgshnik; +1 Ответить
12. Alxby 938 28.10.21 11:30 Сейчас в теме
(11)Скорее ориентированный граф, дерева здесь будет недостаточно
RustIG; rpgshnik; +2 Ответить
28. Dragonim 134 29.10.21 07:17 Сейчас в теме
(7) У вас простая структура которая соответствует общепринятой. Существует только три вида родства сын/дочь, отец/мать, супруг/супруга, все остальные производные. Причем человек может быть только в одном виде основного родства с другим человеком, а ни как не в двух. Мы же рассматриваем общепринятую систему.

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

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

При этом построить полный граф можно только на конкретный момент времени, потому что некоторые связи не обязаны быть постоянными.
Dmitryiv; +1 Ответить
29. Alxby 938 29.10.21 08:20 Сейчас в теме
(28)Тогда уж два - отец/мать - производное от сын/дочь. В каких-то случаях еще могут понадобиться "приемный", "опекун". Причем даже здесь возможна избыточность: то, что Петя является сыном сотрудника, однозначно следует из того, что он является сыном его жены. А в реальности вполне могут работать все родственники - какое-нибудь семейное предприятие, или традиционные ремесла в горах Кавказа, или оленеводческое хозяйство на Крайнем Севере. С тем, что связи непостоянны, согласен, причем непостоянными могут быть любая из этих связей.
rovenko.n; itoptimum; +2 Ответить
42. him1974 13.11.21 18:09 Сейчас в теме
(28) Как у Вас обстоят дела с ВУС на предприятии? Например, на нашем, сотрудникам ВУС требуются все степени родства, даже бывшая жена или муж. Для чего? А для того, что если человек был женат и развелся, далее ушел на войну и его там убили, то кому то сообщить нужно, пусть даже бывшей жене или мужу. Как то так.. Это вообще то требования нашего военкомата.
* Предприятие военное
46. Alxby 938 13.11.21 21:44 Сейчас в теме
(42)+
А еще это может быть необходимо для обеспечения секретности, и не только на военных предприятиях
47. Alxby 938 13.11.21 21:48 Сейчас в теме
(42)Как, кстати, у вас на предприятии с обеспечением работы с персональными данными? Если для ФОИВ согласия физического лица на хранение перс.данных не требуется, то для предприятия, наверное, оно необходимо. А если бывшая жена не даст такое согласие?
48. him1974 14.11.21 01:26 Сейчас в теме
(47) ВУСу плевать на любые информационные системы на предприятии, они военные. Если положено иметь данные по всем возможным родственникам, то они должны быть. У них приказ иметь на всех печатные персональные карточки с заполненными полями. На случай войны завод должен иметь такое то количество таких то специальностей.. и т.д.
Не хочет бывшая жена предоставлять свои перс. данные, то в инфе. удалим, ВУС - нет :)
50. Umix 130 26.11.21 00:06 Сейчас в теме
(5)

Все же не так глупы были "предки" на протяжении всей истории.
А в данном конкретной среде: нет-нет да 1С77 периодически напоминает о себе. Не так плохи были решения того времени. Точнее цели те же, инструментарии, как и способы их достижения разные.
13. RustIG 1652 28.10.21 12:21 Сейчас в теме
(0)
1. постоянно сталкиваюсь с подобными вопросами - что выбрать: ТЧ или РС? К примеру, "номенклатура поставщиков (контрагентов) - в итоге сделал через табличную часть в разрез типовому варианту регистру сведений...

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

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

То же самое можно делать с табл. частями - информацию скрыто дублировать в регистры сведений.

2. Удобство ввода - на настольном ПК , на мобильном телефоне - оно разное. Есть третий универсальный вариант - переопределять форму ввода - рисовать и программировать свою форму ввода/редактирования/удаления сведений - и уже не важно, где хранятся сведения - в ТЧ, в РС...

3. 1с - бизнес-ориентированная среда разработки... Поэтому универсально решить задачу не получится. Для вашего примера - дети нужны для чего? для расчета вычетов?
Я в свое время программировал расчет зарплаты сотрудников с учетом вычетов на детей и других вычетов - так вот просто исключил детей как сущность в управленческой программе. Не было у меня взаимосвязей между родителями и детьми (имена, пол и т.д.). Данные по детям хранились в ЗУП, в управленческой программе есть документ "Вычет" с табличной частью "Сотрудники": по каждому сотруднику вычет просто начислялся бухгалтером один раз. Из месяца в месяц документ копировался и редактировался, когда новый сотрудник нанимался, прежний - увольнялся... Хранение сведений и проверка на непротиворечивость происходит в ЗУП...
14. Alxby 938 28.10.21 13:10 Сейчас в теме
(13)1. Дублирование информации, вообще говоря, - зло, иногда, правда, необходимое. В каждом конкретном случае должны быть веские причины, чтобы это допускать. Все дело в обеспечении согласованности данных. Раз одни и те же данные (или же данные и вычисляемые на их основе другие данные), хранятся в разных местах, то теоретически они могут быть не согласованы. Допустим ваш алгоритм работы с этими данными работает как часы, и записывает только согласованные данные. Но вы уверены, что тот, кто будет дорабатывать эту систему об этом будет знать? А если он сделает обработку, меняющую записи периодического регистра и даже не подумает о регистре с последним актуальным состоянием? Надо сделать автоматический пересчет непериодического регистра при изменении периодического? Это непросто, я слегка коснулся этого в 7 пункте. А наверное, надо еще и запретить менять непериодический без изменения периодического? А как это сделать надежно и навсегда? Хорошо, если подобные вещи заложены в платформу, но даже здесь разработчики, чтобы бороться с такими коллизиями, придумали тестирование и исправление ИБ - пересчет итогов. Поэтому и в Вашем случае необходимы средства для поиска подобных коллизий и средства для их устранения.
2. Своя форма действительно спасает во многих случаях, главное не забывать реализовать функционал, который в типовых формах есть "из коробки". Например, те же объектные блокировки.
3. Собственно в этом и был основной смысл статьи - способ решения определяется требованиями к системе, с учетом тех 19 обстоятельств, которые приведены в статье.
ixijixi; RustIG; +2 Ответить
15. RustIG 1652 28.10.21 14:05 Сейчас в теме
(14)
Дублирование информации, вообще говоря, - зло

подсистема Версии объектов - не что иное, как дублирование информации
20. Alxby 938 28.10.21 15:02 Сейчас в теме
(15) я может ошибаюсь, но разве среди версий хранится текущая версия? или только предыдущие? В любом случае хранение версий здесь скорее всего преследует информационную цель и не влияет на основные функции системы.
16. RustIG 1652 28.10.21 14:06 Сейчас в теме
(14)
Дублирование информации, вообще говоря, - зло

В УТ уже стандарт объявлять оборотные и регистры остатков с одними и теми же измерениями... Для разных отчетов - свои системы хранения! Я еще лет 10 писал об этом публикацию на ИС.
19. Alxby 938 28.10.21 14:58 Сейчас в теме
(16)
В УТ уже стандарт объявлять оборотные и регистры остатков с одними и теми же измерениями...

Здесь скорее всего есть одна точка изменения этих регистров - модуль проведения документа. Это существенно сглаживает проблему. До тех пор, пока не появится энтузиаст, который будет писать в регистр вне документа. А архитектура должна быть максимально устойчива к появлению таких энтузиастов.
21. RustIG 1652 28.10.21 15:17 Сейчас в теме
(19) Дублирование желательно производить в одном модуле - пример я вам предоставил.
И , кстати, я один из тех энтузиастов, которые применяет запись в регистры вне документа - у меня на этот счет была статья, положительно принятая сообществом. В общем, вы молодец, что описали тут все это.
Но это уже для некоторых пройденный этап...Я лишь попробовал расширить ваше восприятие.
23. Alxby 938 28.10.21 15:34 Сейчас в теме
(21)Думаете я все это не применяю?))) За более 20 лет работы у меня накопился мешок таких, гм, подходов. Все, имеющие мало-мальски продолжительный опыт работы с 1С, понимают, что на практике как правило невозможно разработать архитектурно идеальную, быстро работающую в многопользовательском режиме систему без всяческих костылей ухищрений. Всегда надо искать компромисс между идеальностью, сложностью, быстродействием, скоростью разработки, удобством разработки и использования. Главное, необходимо понимать плюсы и минусы каждого проектного решения, и эти решения принимать осознанно, всячески пытаясь уменьшить негативные последствия.
26. RustIG 1652 28.10.21 16:01 Сейчас в теме
(23) ну все понятно... все уже вами детально описано в публикации... пора переходить от слов к действию :) работать, короче, надо :)))))))))))
17. RustIG 1652 28.10.21 14:08 Сейчас в теме
(14)
Раз одни и те же данные (или же данные и вычисляемые на их основе другие данные), хранятся в разных местах, то теоретически они могут быть не согласованы.


Во всех типовых такое - на ИС полно отчетов, показывающих расхождения или ошибки в учете...Это норм.
18. Alxby 938 28.10.21 14:55 Сейчас в теме
(17) То, что это часто встречается, не делает это хорошим. Еще раз подчеркну, что если мы собрались делать нечто подобное, то мы должны а) быть уверены что плюсов будет больше, чем минусов (например существенно возрастет быстродействие, или же мы сможем реализовать необходимые разграничения доступа), б) иметь средства для поиска и исправления коллизий, регламент для использования этих средств, инструкцию, что делать, если коллизии привели к катастрофическим нежелательным последствиям. А вообще, по моему мнению, архитектура, в которой нет места подобным проблемам лучше, чем архитектура, в которой это есть, зря что ли умные люди придумали понятие "Нормальные формы"
22. RustIG 1652 28.10.21 15:21 Сейчас в теме
(18) что-то да, что-то нет....
у вас 30 клиентов, каждый ДЕНЬ кому-то что-то надо дописать в конфу - у вас нет развернутого ТЗ. У вас есть одна задача которая "перед носом", а что там понадобится через год или два - никто не знает... Делайте ТЧ если это решит задачу, делайте РС, если это лучше сейчас для отчета....

В целом, о чем вы написали, это из разряда философии "В чем смысл жизни"... Можно жить и не думать, а можно запрограммировать и на лету изменять архитектуру - пример с ЗУПом вам показали - как ТЧ переросла в ПодчиненныйСправочник....
24. Alxby 938 28.10.21 15:48 Сейчас в теме
(22)И вновь я с частично соглашусь, а частично - нет. За что я люблю 1С - за относительную легкость изменения архитектуры. Но легкость изменения - это только техническая легкость. Если Вы будете разрабатывать тиражный массовый продукт, то Вам зададут вопрос: а после такого изменения архитектуры у всех наших 1500 клиентов ничего не сломается? И здесь уже надо будет смотреть в сторону "доказательного программирования" (термин здесь не очень подходит, но лучшего я не могу подобрать). А когда вы задумаетесь, что в принципе, теоретически, может пойти у клиента не так, то обнаружите, что чем больше "скользких" мест в архитектуре, тем больше может быть проблемных кейсов.
25. RustIG 1652 28.10.21 15:59 Сейчас в теме
(24) мы с вами говорим об одном и том же.
мы не спорим, по крайней мере я не спорю. я вас прекрасно понимаю.
вы сейчас спорите с разрабами ЗУП, у которых 1 млн пользователей, и которые трансформировали ТЧ в под. справочник.

Ну, пожурили, их, и полно, хватит...
Что с этого?
Жизнь продолжается...

Они как программировали , так и будут....

Кто хочет, почерпнет из вашей публикации дозу полезной инфы...
27. Alxby 938 28.10.21 16:04 Сейчас в теме
(25)
мы с вами говорим об одном и том же.

я тоже пришел к такому выводу. Предлагаю на этом прекратить засорять комментарии к статье, а если необходимо - продолжим разговор в личке или очно на предстоящей конференции.
30. rovenko.n 03.11.21 11:00 Сейчас в теме
Прочел всю статью. Надеялся, что будет четкий ответ. Теперь вопросов больше, чем ответов. Спасибо тебе, автор
:-)
31. Alxby 938 03.11.21 12:00 Сейчас в теме
(30)А кто обещал что будет легко? )) Надеюсь, что хотя бы стало понятнее как искать ответы. Удачи!
rovenko.n; +1 Ответить
32. rovenko.n 03.11.21 12:16 Сейчас в теме
33. DrAku1a 1581 05.11.21 14:05 Сейчас в теме
Однозначно плюс за раскрытие темы выбора "Табличная часть или регистр сведений"!

Но неплохо бы добавить в рассмотрение подчиненный справочник, как описано в (5).
На вскидку:
Плюсы: не считывается по ссылке с основным справочником, не копируется (хотя это может быть и минусом, зависит от задачи), при этом управляется ролями и механизмы истории изменений - работают.
Минусы: сложно создавать при создании нового элемента (когда вводишь сотрудника, в этой-же карточке, не записывая, хочется наклепать ему и детей), и избыточная ссылочность (ссылка, код, пометка удаления - излишние), удалять тоже немного сложнее. Всё это решается программно.
34. Alxby 938 05.11.21 15:07 Сейчас в теме
(33)Да, вы правы, не помешало бы такое сравнение провести. Но, как правило, если стоит выбор между объектным (ссылочным) типом и необъектным (ТЧ, регистры), то этот выбор делается быстро - здесь обычно бывает "необходимость ссылки на... " против "легкость создания/удаления". Так что я сознательно ограничил статью сравнением именно необъектных данных (кстати, на правах оффтопика, кто вспомнит еще один вид необъектных данных? Нет, это не внешние источники). А если говорить об объектных данных, то гораздо интереснее другое: какие именно объектные данные лучше использовать в том, или ином случае? Для актов (если нет проводок) что лучше - справочник или документ? а для договоров? почему? А когда лучше использовать задачи, а когда справочники? А можно документом заменить задачу? а задачу, не привязанную к бизнес-процессу? Я часто на собеседованиях подобные вопросы задаю - отличный способ проверить знания кандидата.
35. TimofeySin 157 06.11.21 14:10 Сейчас в теме
Мне нравится с регистром: Дети.СрезПоследних :) Вообще по скольку дети после 18 лет пропадают, то нужен наверное регистр :)
36. Alxby 938 08.11.21 15:32 Сейчас в теме
(35)Далеко не во всех сферах дети пропадают после 18 лет. Даже после естественной кончины родителей, да и самих детей тоже, информация об этих родственных связях может иметь значение - например для защиты авторских прав. В нашей стране, если мне память не изменяет, это - 70 лет. Что уж говорить о правах на престол - там вообще речь может идти о столетиях))
37. SergeMalikov 571 09.11.21 15:24 Сейчас в теме
Извиняюсь может выскажусь излишне резко. Но лично мне кажется изложенные подходы к проектированию архитектуры решения несколько дилетантскими. Для хранения информации о родственных связях спроектировал бы регистр сведений с измерениями: ОбъектСвязи тип СправочникСсылка.ФизическиеЛица; СубъектСвязи тип СправочникСсылка.ФизическиеЛица; ВидСвязи тип СправочникСсылка.СтепеньРодства
38. Alxby 938 09.11.21 16:24 Сейчас в теме
(37)А если в конфигурации нет справочника ФизическиеЛица, а есть только справочник Сотрудники? Надо завести дополнительно ФизическиеЛица? А какую информацию там хранить? Дублировать ли там данные сотрудников? или хранить там только детей? А тогда может не нужен справочник ФизическиеЛица, а нужен только справочник Дети? А как решить проблему, указанную в пункте 2? А если ссылка на справочник Дети больше нигде не понадобится, может не надо заводить регистр и справочник, а достаточно только регистра? Основная идея статьи была не в том, как правильно хранить информацию о детях, а в том, что в зависимости от требований к системе, могут быть разные решения, а при выборе решения из нескольких, необходимо учитывать факторы, приведенные в статье.
39. SergeMalikov 571 09.11.21 17:23 Сейчас в теме
(38) Если в конфигурации нет справочника ФизическиеЛица а вам необходимо хранить информацию о физических лицах то стоит его завести. Хранить в справочнике Сотрудники информацию о физических лицах (детях) это моветон. Сущности предметной области желательно использовать по назначению. При выборе архитектурного решения желательно пользоваться правилами: - не плодить новые сущности без необходимости: информацию о сотрудниках хранить в сущности "сотрудники", а информацию о физических лицах в сущности "ФизическиеЛица"; -делать архитектуру решения устойчивой к изменению требований. Сейчас вам понадобилось хранить данные о детях а завтра может понадобится хранить данные о родителях (братьях, сестрах). Будите переделывать каждый раз? При выборе решения из нескольких я бы посоветовал в первую очередь поискать аналогичное решение в типовых конфигурациях. Как говорится все уже придумали до вас.
40. Alxby 938 09.11.21 18:25 Сейчас в теме
(39)Да, возможно, стоит добавить этот совет в статью - "при разработке архитектуры надо поискать аналогичные решения и сделать так же как сделано в них" :). А если серьезно, то нет, я не считаю, что надо бездумно копировать архитектуру чужих систем. При выборе из нескольких вариантов нужно четко понимать, чем эти варианты различаются, какие последствия принесет тот или иной выбор, что лучше для нашей системы. И это основной принцип который надо учитывать при выборе, а вовсе не "ищем что-нибудь похожее". С тем, что надо не плодить сущности - согласен, и поэтому мне непонятно, зачем нужен регистр и дополнительный справочник, когда можно обойтись табличной частью (разумеется, если такой вариант полностью покрывает требования заказчика). С тем, что надо делать систему устойчивой к изменениям - тоже согласен, но с оговоркой, что надо оценить вероятность этих изменений и сложность вариантов. Но эта тема выходит далеко за рамки статьи. Вот представьте, что к вам пришел новый сотрудник, которого вы должны обучить, как разрабатывать архитектуру. Вы можете изложить ход своих рассуждений, которые приводят к тому, что для связи ОбъектаСвязи и СубъектаСвязи вы выбрали регистр, а не табличную часть?
unknown181538; RustIG; +2 Ответить
49. RustIG 1652 14.11.21 10:03 Сейчас в теме
(39)
Как говорится все уже придумали до вас.

На самом деле, еще никто не придумал до нас "всё"...
Исторически складывается так - что все экспериментируют, учатся на своих ошибках....
Обсуждают иногда на форумах... Но окончательного идеального решения нет - до сих многие сферы учета находятся в зачаточном состоянии...

Вот пример из жизни - лет 10 назад в типовых было так:
инвентарный номер основного средства в справочнике - это код справочника ОсновныеСредства;
табельный номер сотрудника - это код справочника Сотрудники,
затем через два года разработчики типовых изменили свое мнение - сделали эти сущности отдельными реквизитами....
Я об этом писал в публикации "Перенумерация кодов справочников и номеров документов"...

Разработка (в том числе изменение архитектуры решения) - весьма гибкая и изменчивая сущность....
Короче, никто еще не придумал до нас "всё"...
unknown181538; +1 Ответить
45. Alxby 938 13.11.21 21:41 Сейчас в теме
Как интересно расходятся ветки комментариев... Я наверное перемудрил с названием, может надо было просто назвать статью "Сравнение ТЧ и РС":) ? Но, в любом случае, спасибо всем участником обсуждения - нашел для себя несколько тем для обдумывания.
Оставьте свое сообщение

См. также

Не заполняется ведомость в банк. ЗУП 3.1.24.408

Зарплата Адаптация типовых решений Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

ЗУП (3.1.24.408 февраль 2023 года). Делюсь опытом исправления ситуации, когда из-за наличия старых «хвостов» в регистре накопления «Зарплата к выплате» не заполняется ведомость в банк и в кассу (выплата зарплаты) старыми сотрудниками. Причем, вновь принятые сотрудники (в 2023 году) по кнопке «Заполнить» в ведомость попадают, а старые нет. Возможно, опыт будет полезен и сократит время поиска ошибки.

06.03.2023    526    2ncom    0    

1

Автоматическое создание задачи исполнения при бронировании помещений в 1С: Документооборот

Адаптация типовых решений Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Простая настройка для автоматического создания задач исполнения при использовании блока бронирования помещений для 1С: Документооборот 2.1.

01.03.2023    321    ketr    0    

2

При начислении заработной платы за декабрь 2022 в ЗУП 3.1.24.308 при участии в проекте Сколково начисляются страховые за весь год

Зарплата Адаптация типовых решений Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Россия Налоговый учет ФОМС, ЕФС Бесплатно (free)

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

11.01.2023    2103    hottion    9    

2

[После] Новогодние задачи 2023

Математика и алгоритмы О жизни Бесплатно (free)

Не желаете ли очередную порцию интересных задач?

03.01.2023    1153    Alxby    18    

4

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Если хочется низко-низкоуровневого программирования с битами и байтами

Математика и алгоритмы Платформа 1С v8.3 Абонемент ($m)

Все знают, что подавляющее большинство современных компьютеров работает в двоичном коде, т.е. оперирует всего двумя значениями - битами - "0" и "1". Потом из них складываются байты, слова, кило-, мега- и гигабайты etc. Но что происходит внутри процессора, как именно обрабатываются двоичные числа, например выполняются арифметические операции? Об этом — в публикации. Статья, я думаю, будет особенно интересна тем читателям, у которых во время обучения не было соответствующих курсов.

1 стартмани

01.12.2022    736    Alxby    16    

9

Доработка визуализации ЭП для 1С:Документооборот государственного учреждения КОРП

Адаптация типовых решений Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

В этот раз хочу поделиться с вами решением одной практической задачи для одного из проектов Компании Омега, а именно доработки механизма визуализации электронной подписи, т.к. это потребовало проработки 3-х различных способах взаимодействия со сторонним ПО: работа с com-объектом Word (вставка в .doc), разбор структуры docx и создание картинки для дополнения ЭП и вставки этого добра в pdf.

01.12.2022    757    zeltyr    0    

9

Корректный вывод суммы и сроков в печатной форме

Адаптация типовых решений Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Простой лайфхак для вывода суммы или числа дней В скобках и склоняемых единиц измерения или валюты ЗА скобками.

16.11.2022    691    vladimir-89    0    

11

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Дополнительные сведения в типовых конфигурациях 1С

Адаптация типовых решений Платформа 1С v8.3 1С:Бухгалтерия 3.0 Бесплатно (free)

В статье рассказывается, как использование дополнительных сведений помогает расширить функциональность типовых конфигураций без «снятия с замка» и с минимумом программирования.

08.11.2022    4853    accounting_cons    16    

27

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

Механизмы платформы 1С Платформа 1С v8.3 План видов характеристик Абонемент ($m)

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

1 стартмани

20.09.2022    2883    Alxby    9    

45

Автоматизация ОТК: как лакокрасочная компания снижает себестоимость изделий на 3–5%

Адаптация типовых решений Внедрение ИТ-системы Платформа 1С v8.3 1С:ERP Управление предприятием 2 Управленческий учет Бесплатно (free)

Добиться высокого качества продукции минимальными усилиями? Легко. Читайте кейс компании «Внедренцы и программисты»: как доработка «1С:ERP» помогла лакокрасочной компании отсеять некачественное сырьё и сократить себестоимость изделий.

19.09.2022    515    ystetsenko    4    

6

Видеокурс-практикум: как подготовить и написать ТЗ, ЗНР, ЧТЗ. Промо

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

3 500 рублей

Сжатие фотографий физических лиц в ЗУП 3.1

Адаптация типовых решений Платформа 1С v8.3 1С:Зарплата и Управление Персоналом 3.x Россия Бесплатно (free)

Сжатие фотографий физических лиц при загрузке, плюс обработка уже загруженных фото.

06.09.2022    932    mrChOP93    5    

16

Не заполняется субконто счета 10.07 в распределении расходов на себестоимость товаров

Закрытие периода Адаптация типовых решений Платформа 1С v8.3 Бухгалтерский учет 1С:ERP Управление предприятием 2 Бухгалтерский учет Налоговый учет Бесплатно (free)

При выполнении закрытия месяца не заполняется себестоимость в распределении расходов по счёту 10.07, разбираемся, почему, и показываю решение для тех, кто не использует отдельное ведение партнеров и контрагентов.

17.08.2022    814    Volfy    0    

1

Изменение размера штампа электронной подписи (ЭП) в файле Docx

Документооборот и делопроизводство (СЭД) Адаптация типовых решений Платформа 1С v8.3 1С:Документооборот Россия Бесплатно (free)

В конфигурации 1С:Документооборот реализована возможность вставки изображения электронной подписи (ЭП) в файлы формата Docx, Doc, Odt. В данной статье мы расскажем, как изменить размер вставки изображения ЭП в файлы формата Docx.

25.07.2022    1724    iclect    5    

8

Распознавание и загрузка документов в 1С Промо

Универсальная программа-обработка для распознавания любых сканов или фото первичных документов в 1С (счета-фактуры, УПД, ТТН, акты и тд). Точность распознания до 98%.

от 11 рублей

Добавление собственного виджета в 1С:Документооборот версии 3.0

Документооборот и делопроизводство (СЭД) Адаптация типовых решений Механизмы типовых конфигураций Платформа 1С v8.3 1С:Документооборот Россия Бесплатно (free)

В данной публикации я хочу описать процесс добавления собственного виджета для отслеживания задач по видам документов в 1С документооборот версии 3.0.

18.07.2022    2486    ArseniyFenix    2    

44

Опрос пользователя в цикле с оповещением (управляемые формы)

Адаптация типовых решений Платформа 1С v8.3 Управляемые формы Бесплатно (free)

Пример вопроса пользователю по каждой строке при обходе таблицы значений в цикле с помощью оповещения.

01.06.2022    984    nikolasx    10    

6

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

Как настроить вывод списка документов 1С в режиме предприятия? Часть 1. Настройка колонок

Адаптация типовых решений Инструкции пользователю Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной статье представлена подробная инструкция по настройке списка документов программных продуктах 1С в режиме предприятия. Ответим на следующие вопросы: 1. Как убрать колонку? 2. Как добавить колонку? 3. Как вывести свой реквизит (Добавленный в режиме «Предприятие» или расширением/доработкой). 4. Как поменять порядок вывода колонок ? 5. Как добавить дополнительный элемент, которого нет в документе. (Например: Контактное лицо).

12.05.2022    4052    Yotata    6    

10

Еще раз о дополнительных реквизитах и дополнительных сведениях

Адаптация типовых решений БСП (Библиотека стандартных подсистем) Механизмы типовых конфигураций Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Дополнительные реквизиты и сведения существуют давно. Задумка очень хорошая. Суть этих механизмов понятна всем. По этому поводу написано много. Что тут можно сказать нового? Однако бес, как всегда, в деталях. Как создавали реквизиты в объектах типовых конфигураций, так и продолжаем это делать. Почему это происходит? За всех сказать не могу. Могу рассуждать только на своем примере. Являясь убежденным практиком, одно могу сказать вполне определенно. Если что-то на практике недостаточно удобно, то останется оно главным образом в теории... Если не приложить немного усилий.

11.05.2022    8480    user1374747    19    

48

Допиливаем типовой отчет "Связанные документы" (структура подчиненности) так, чтобы он видел документы из расширения конфигурации

Адаптация типовых решений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Наконец-то мы перешли на платформу 1С 8.3.20 и смогли отказаться от режима совместимости в 1С ЕРП. Это позволило нам окончательно закрыть вопрос о перемещении ВСЕХ добавленных объектов из самой конфигурации в её расширение.  Одним из камней преткновения на пути к переезду, был вопрос работы типового отчета "связанные документы".  Ну что же, давайте вместе его решим.

02.05.2022    9296    dima_home    66    

66

Пример доработки проведения в ERP 2.5 по одному регистру накопления

Адаптация типовых решений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

В дополнение к публикации № 1343740 показан быстрый способ встраивания в механизмы конфигурации проведения существующего документа "ПриобретениеТоваровУслуг" по добавленному новому регистру накопления "АТХ_ПартииНоменклатурыДляРемонтовТверь_НД". Пример реализован на 1С:ERP Управление предприятием 2 (2.5.7.390).

27.04.2022    1895    vsasav    5    

29

Получение контактной информации из отбора

Адаптация типовых решений Универсальные функции БСП (Библиотека стандартных подсистем) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Универсальная функция получения контактной информации из отбора компоновки данных. Весь код в статье.

25.03.2022    1729    ixijixi    0    

11

Работа с 1С:Аналитика Промо

Онлайн-курс предусматривает изучение возможностей системы “1С:Аналитика”, которая работает как составная часть платформы “1С:Предприятие” и обеспечивает оперативный просмотр и анализ необходимых данных.

4500 рублей

Не удалось сделать проверку отзыва сертификата в 1С (при маркировке, директ-банк, 1С-Отчетность, ЭДО)

Адаптация типовых решений ЭДО и ОФД Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

Если возникает ошибка при подписании ЭЦП документов в 1С, при проверке и подписании маркировки и документов в ЧЗ, при подключении к директ-банку и всем, что связано с электронной подписью.

18.03.2022    5824    ClickUp    10    

19

Доработка новой Транспортной накладной (с 01.03.2022 г.) при помощи расширения

Адаптация типовых решений Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Бесплатно (free)

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

15.03.2022    2248    niko11s    1    

4

Авансы, кредиты и предоплаты ФФД 1.05. Изменение типовой УТ 10.3.72.3

Адаптация типовых решений Универсальные функции Механизмы типовых конфигураций Платформа 1С v8.3 1С:Управление торговлей 10 Бесплатно (free)

Изменение типовой конфигурации Управление торговлей 10.3.72.3 и ниже для случаев, когда клиент оплачивает частично по накладной. В расчетной части чека должны быть типы оплат "Постоплата кредит" - сумма оставшегося долга, "Зачет аванса" - сумма предыдущих оплат. Также исправлена ошибка при оплате за накладную, в которой указаны товарные позиции с разными ставками НДС.

05.03.2022    744    andrew.ab    0    

1

Ошибка во внешней обработке СБИС

Адаптация типовых решений Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Бесплатно (free)

При загрузке корректировочных счетов-фактур обработка не подтягивала основания.

18.01.2022    2078    sv_baranov    3    

1

Не выводятся подписи ответственных лиц в печатных формах. Как победить проблему [БП 3.0]

Печатные формы Адаптация типовых решений Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

Проблема: ни в одной печатной форме (ПКО, РКО, кассовая книга, счет, накладные и пр.) не подставляется ФИО руководителя, ФИО главного бухгалтера, кассира.

19.10.2021    3084    config    4    

4

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

СПАРК помогает предотвратить мошенничество со стороны компаний и предпринимателей, благодаря актуальным сведениям о компаниях и системе выявления факторов риска.Сервис позволяет управлять налоговыми рисками и комплексно оценивать благонадежность контрагентов.

Отправка ссылки на документ в обработку вызовом из формы документа, управляемая и обычная формы

Адаптация типовых решений Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Бесплатно (free)

По шагам рассматривается настройка открытия формы обработки из формы документа в управляемой и обычной форме. При открытии формы обработки в реквизит ДокументОснование должен автоматом проставляться документ, из которого выполнялся запуск обработки. Автоматизация выбора документа в обработке.

21.09.2021    2893    etmarket    5    

1

Google почта, IMAP и 1C на обычных формах

Адаптация типовых решений Email рассылки Платформа 1С v8.3 Бесплатно (free)

В настоящее время огромное количество пользователей продолжает работать на конфигурациях 1С для обычных форм. Это отличные, проверенные временем конфигурации. Но компания 1С давно их перестала активно развивать, и некоторые вещи не решить без доработок. Столкнулся с невозможностью работы конфигураций на обычных формах с самым распространенным почтовым сервисом, а именно Google почтой. Почта от Google давно поддерживает работу через IMAP протокол, вместо устаревшего POP3. Также через IMAP работают почти все почтовые ящики, поэтому эта статья пригодится Вам, даже если Вы используете другой ящик с IMAP, нежели гугловский. Итак, поехали....

30.07.2021    2464    lisrws    4    

7

УНФ - установка даты запрета редактирования для регистра сведений

Адаптация типовых решений Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 Бесплатно (free)

В типовой конфигурации УНФ дата запрета редактирования распространяется только на документы. Иногда требуется распространить дату запрета на регистры сведений - например на "Цены номенклатуры". В статье будет описание как это можно сделать. Указанные доработки можно выполнить как в конфигурации, так и в расширении.

28.06.2021    1921    teyana    0    

5