Изменение времени документов, перенос документов в начало дня. 1С 7.7

08.10.19

Задачи пользователя - Корректировка данных

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

Скачать файлы

Наименование Файл Версия Размер
Перенос документов вначало дня.ert
.ert 110,50Kb
7
.ert 110,50Kb 7 Скачать

Запускать обработку надо монопольно. При нажатии "Сформировать" все документы будут перенесены на начало дня (начиная с указанной  в модуле даты с сохранением последовательности и интервалом 1 секунда).

 
 Техническая реализация переноса времени на начало дня

Обработка написана в комплексной конфигурации 4.2 (7.70.424). Версия платформы 7.70.027.

 

См. также

Комплект обработок 1С 7.7 для работы со справочниками и документами

Чистка данных Корректировка данных Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

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

1 стартмани

13.05.2021    7824    8    etmarket    0    

3

Сверки и переносы документов между базами 7.7 и 8, исправление расхождений. Реализации. Поступления. Корректировки отгрузки, поступления. Счета-фактуры выданные, полученные; исправленные выданные и полученные. COM-объект 1С8 (ОФ)

Корректировка данных Акт сверки Платформа 1С v7.7 Платформа 1С v8.3 1С:Управление торговлей 10 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Россия Бухгалтерский учет Управленческий учет НДС Абонемент ($m)

Пример реализации сверок между базами и исправления расхождений в обе стороны, из 7.7 -> в 8.3 и из 8.3 -> в 7.7 на обычных формах. Фундаментальные обработки, которые работают на постоянной основе и поддерживают идентичность данных между базами основных поставщиков и основных покупателей (их соответствие прописано в модуле). Используется Новый COMОбъект("V77.Application"), пример использования внешнего источника данных. Реализация в поступление. Поступление в поступление. Корректировка поступления в корректировку отгрузки. СчФ выданный в СчФ полученный. Исправление СчФ полученного в исправление СчФ выданного. Перенос документа Реализация 7.7 в Поступление 8, Перемещение 7.7 в Поступление 8. Акт сверки взаиморасчетов (несколько организаций). Все обработки запускаются в базе 1С Предприятие 8 (обычные формы).

1 стартмани

03.10.2019    14659    30    ksnik    6    

4

Универсальный подбор и обработка объектов для 1С: Предприятия 7.7 "UChoice.ert"

Корректировка данных Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Универсальная обработка 7.7, представленная здесь, до сих пор почему-то по функционалу гораздо беднее, чем общеизвестная типовая "Универсальный подбор и обработка объектов" (UNIREPS82\UniversalSelection) 8.2-8.3", мне не хватило возможности выполнить произвольный код обработчика объектов. Данная обработка "UChoice.ert" является полным аналогом "UniversalSelection", представляет собой консоль выполнения произвольного кода, позволяет делать с объектами информационной базы 1С 7.7 абсолютно все, что угодно, а не узкий, сложно настраиваемый набор команд, на мой взгляд, она существенно превосходит имеющиеся аналоги, поэтому ничем другим кроме нее я не пользуюсь.

1 стартмани

04.04.2019    16339    28    ksnik    9    

4

Переход на НДС 20% для 1С:7.7

Корректировка данных Бухгалтерский учет 7.7 1С:Упрощенное налогообложение 7.7 Россия Бухгалтерский учет НДС Абонемент ($m)

Для 1С:Предприятия 8 переход на НДС 20% сделан, а для 7.7 я не нашел. Выкладываю.

1 стартмани

24.12.2018    18502    34    pentanom    25    

5

Исправление отрицательных номеров строк табличной части документов

Корректировка данных Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Обработка, исправляющая ситуацию с отрицательными номерами строк в табличной части

1 стартмани

31.08.2017    13353    1    C0mmander_Alex    1    

3

Групповая обработка документов и справочников v.7.7

Корректировка данных Платформа 1С v7.7 Конфигурации 1cv7 Россия Абонемент ($m)

1. Обработка позволяет совершать следующие действия над объектами: а. СПРАВОЧНИКИ: удаление; пометка на удаление; снятие пометки на удаление. б. ДОКУМЕНТЫ: удаление; пометка на удаление; снятие пометки на удаление; проведение; отмена проведения; выключить проводки; включить проводки. 2. Действия могут быть ограничены некоторыми условиями. 3. Существует отбор по видам объектов. 4. Есть возможность обработать подчиненные справочники.

1 стартмани

30.04.2017    22230    78    DUH    0    

5

Универсальные обработки документов и справочников для 1С: Предприятие 7.7

Корректировка данных Платформа 1С v7.7 Конфигурации 1cv7 Россия Абонемент ($m)

Обработки можно использовать в любой конфигурации 1С-Предприятия 7.7. Обработки позволяют просмотреть/изменить значения любого реквизита документов/справочников, существующих в базе. В обработках реализован множественный отбор по значениям реквизитов (для табличной части документов тоже). В обработке документов реализованы следующие действия: Перенумерация; проведение; отмена проведения; пометка на удаление; непосредственное удаление; снятие пометки удаления; изменение реквизитов; очистка реквизитов; удаление строк табличной части; вывод на печать и в файлы *.xls,*.csv,*.dbf,*.xml реквизитов шапки и табличной части. В обработке справочников реализованы следующие действия: Перенумерация; пометка на удаление; непосредственное удаление; снятие пометки удаления; изменение реквизитов; очистка реквизитов; очистка истории значений периодического реквизита; перенос справочника в другую базу подобной конфигурации по OLE; вывод на печать реквизитов и истории значений периодических реквизитов; вывод реквизитов в файлы *.xls,*.csv,*.dbf,*.xml; отчет по структуре справочников, вывод и обработка ссылок на выбранные элементы.

1 стартмани

23.11.2016    38173    210    SanchoD    15    

13

Выводим из suspect базу 1С 7.7 на sql server 2000, а также "Перемещение баз данных SQL Server в новое местоположение с помощью операций Detach и Attach"

Корректировка данных Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

База данных помечается Suspect, когда SQL Server не может читать файлы данных, связанные с базой данных с жесткого диска. В этом случае сделать бекап базы нельзя, но можно попробовать образ диска. После того как возможность читать файлы данных восстановлена, вы можете перезапустить службу SQL Server, и если возможно, произойдет автоматическое восстановление. Что делать, если информационная база 1С7.7 на SQL Server 2000 перешла в состояние suspect? Если это произошло утром и бекап сделан, Вы, конечно, можете грохнуть и раскатать базу заново (вечером это проблематичнее), но не торопитесь - возможно, поможет detach+attach или другие методы, изложенные в данной публикации.

1 стартмани

08.11.2016    22747    ksnik    5    

5
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. CheBurator 3119 08.10.19 01:14 Сейчас в теме
наращивание времени как сделано? что суммируется? как сделан переход на минутах и часах?

примечание боковое: по 10 секунд в общем случае - "плохо".
надо смотреть в каком времени первый непереносимый документ и впихивать переносимые ДО этого документа. соответсвенно надо посчитать дельту наращивани времени.
2. ksnik 578 08.10.19 03:49 Сейчас в теме
(1) я открыл код, пересчет прямой: время=ЧЧ*60*60+ММ*60+СС и обратный к нему.
надо смотреть в каком времени первый непереносимый документ и впихивать переносимые ДО этого документа

это зачем? оно же изменит последовательность проведения документов?
5. CheBurator 3119 08.10.19 15:14 Сейчас в теме
(2) для переноса документов "в начало дня" - все переносимые "в начало дня" документы в общем случае должны быть ДО первого неперносимого документа.
.
По наращиванию времени - я так и знал!!!
(смотри у меня публикацию пр финт ушами с временем документа).
Для переноса достаточно оперировать только СС, если секунды задашь больше 60 - платформа это правильно проглотит сама. это работает в пределах дня, дальше 23.59-59 или 00-00-00 не уйдет документ сколько бы большое значение СС ни было. Пользуйся!
7. ksnik 578 08.10.19 16:09 Сейчас в теме
(5) багофичи это зло ибо делает код черезжопным, в моей программе ошибок нет.
Я указал на то что перенос документа через документ ломает логику взаиморасчетов.
8. CheBurator 3119 08.10.19 19:52 Сейчас в теме
(7) багофичи - на вкус и цвет, согласен.
9. CheBurator 3119 08.10.19 20:20 Сейчас в теме
(7)
Я указал на то что перенос документа через документ ломает логику взаиморасчетов.

уу, название ппубликации вводит в заблуждение. поправить бы хорошо.
потому что перенос документов в начало дня - это перенос в начало дня.
здесь по факту перенос ВСЕХ (это ключевой момент) документов, лежащих после времени "Ч" до конца дня - в "правильную" последовательность документов ПОСЛЕ "Ч". Конечно, а таком контексте выполнения задачи, мое замечание неверно.

Однако, тут все равно вылезет ошибка другого рода (но похожая, так как связана с нарушением очередности документов), в общем случае:

Последнее правильное время=14 сек (Док0). Считаем что все проведение было сделано правильно, ГП не нарушена.

Исходная цепочка:
Док1, 15 сек
Док2, 15 сек
Док3, 16 сек
Док4, 16 сек

По идее, после обработки (сдвиг по 1 сек на документ) получится так:
Док1, 15 сек (14+1), ОК
Док2, 16 сек (14+2) - конфликт с Док3, Док2 ляжет и проведется ПОСЛЕ ЕЩЕ НЕ ОБРАБОТАННОГО Док3 (другой результат проведения получится чем до переноса) и не факт что Док2 проведется вообще
Док3, 17 сек (14+3) - конфликт с Док4, Док3 ляжет и проведется ПОСЛЕ ЕЩЕ НЕ ОБРАБОТАННОГО Док4 (другой результат проведения получится чем до переноса) и вдобавок проведение док3 будет опираться на неверные результаты проведения Док2 и не факт что Док3 проведется вообще
Док4, 18 сек (14+4) - проведение док4 будет опираться на неверные результаты проведения Док2 и Док3 и не факт что Док4 проведется вообще.

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

Для получения гарантированного правильного результата следует ОБЯЗАТЕЛЬНО восстановить ГП последовательность документов от Док0 до последнего перенесенного документа. Или переписать алгоритм переноса.
12. ksnik 578 08.10.19 21:41 Сейчас в теме
(9) Сергей, спасибо за подробное объяснение принципа действия алгоритма. На самом деле алгоритм рабочий, переписывать его не надо. Но Ваша постановка задачи к которой Вы применили алгоритм не имеет смысла. Никто не переносит документы на секунду назад, 100 % случаев возникает необходимость перенести на несколько часов, поэтому описанная Вами ситуация практически не возможна.
Док3 (другой результат проведения получится чем до переноса) и не факт что Док2 проведется вообще

На самом деле практические задачи для решения которых мной предназначен алгоритм в публикации такие:
1) алгоритм поможет изменить время документов на заранее выбранное, каждый следующий документ на следующую секунду, но не с 15й секунды на 14ю, ибо это не имеет смысла.
2) алгоритм поможет если надо перенести документы на начало дня, хоть на 00 часов - не ломая последовательности.
3) алгоритм поможет, когда кто-то установил точку актуальности на конец текущего дня (провел документ концом дня) и документы перестали проводиться. Теперь, чтобы нормализовать ситуацию, время документов нужно изменить и документы перепровести, затем перенести точку актуальности на последний проведенный документ. Решать эту задачу в разделенном режиме смысла нет, так как в разделенном режиме пользователи напрасно будут мучать базу - все равно документы не проводятся, да и точку актуальности на последний документ можно установить только в монопольном режиме.
13. CheBurator 3119 08.10.19 23:10 Сейчас в теме
(12) все пункты работают только если верить что " 100 % случаев возникает необходимость перенести на несколько часов, поэтому описанная Вами ситуация практически не возможна."
- практически не очень вероятно, да. но вполне может случится казус.
ибо в приведенном примере - алгоритм породит некорректные данные.
а сработает ли такой пример в реальности - зависит исключительно от количества доков которые надо перенести, периода времени на котором эти доки находятся и зависимостей документов (и результатов их проведения) друг от друга.
в общем случае - алгоритм нерабочий. да, я тоже оцениваю вероятность трабла как маленькую.
Но я бы посоветовал, во избежание либо в конце кода перепровести все перенесенынные документы в хорологической последовательности или сначала все документы перенести в виде непроведенных, а потом перепровести. и это ВСЕ обернуть в транзакцию.
.
транзакция в коде - как у вас - излишняя.

И что главное - Док.Провести() - в случае непроведения НЕ ВЫЗОВЕТ ИСКЛЮЧЕНИЯ. что может в такой (или разновидностях такой логики обработки чуть более сложной) привести к ЯВНОЙ ОШИБКЕ в итогах переноса.
.
та позже, в вашем коде, в случае если Док.Провести() не проведется - скорее всего упадет на ЗафиксироватьТранзакцию(), ибо транзакция уже отатана назад неявно.
14. ksnik 578 09.10.19 00:38 Сейчас в теме
(13) Спасибо за подробное замечание!!
Док.Провести() - в случае непроведения НЕ ВЫЗОВЕТ ИСКЛЮЧЕНИЯ

Согласен что Док.Провести() в данном контексте выглядит сомнительно и вызывает вопрос, ну ни разу не бывало проблем. Согласен красивее выглядит
		Если Провед=1 Тогда
			    Если Док.Провести()=0 Тогда
			        ф = 1/0;
			    КонецЕсли;
			Иначе
				Док.Записать();
			КонецЕсли;

но практически это пока не испробовано. Ну ни разу у меня не было проблем с этим, возможно причина в СтатусВозврата(0)+транзакции, надо провести тест...
15. ksnik 578 09.10.19 01:13 Сейчас в теме
(13) в общем Вы не правы, все у меня отлично работает, тест пройден успешно. Оно несколько лет используется. Не могло оно глючить.
1)В тестовой базе берем любой документ, в начале обработки проведения пишем:
Процедура ОбработкаПроведения()
    Если Сумма > 0 Тогда
		СтатусВозврата(0);
		Возврат;
    КонецЕсли;
...
КонецПроцедуры 

Я для примера в документ Аккредитив добавил, установил признак проводить в оперативном учете. Реструктуризация прошла...
2)создаем и проводим с нулевой суммой
3)редактируем реквизит сумма = 1р
4) запускаем мою обработку
Смотрим результат, попробуйте повторить сами:
1
Документ не проведен! :Аккредитив АкСцНС000001 (09.10.2019)
ЗафиксироватьТранзакцию();
{\\путькобработке\ПЕРЕНОС ДОКУМЕНТОВ ВНАЧАЛО ДНЯ.ERT(64)}: Ошибка при выполнении процедуры ЗафиксироватьТранзакцию
16. CheBurator 3119 09.10.19 02:02 Сейчас в теме
(15) все правильно, я об этом и сказал выше, что сломается на ЗафиксироватьТранзакцию.
неудачное проведение как таковое не вызывает исключения. поэтому ошибка проведеняи документа - не отлавливается. и то что это неудачное проведение стопорит систему - просто удачное стечение обстоятельств что напарывается на ЗафиксироватьТранзакцию в лишней обертке транзакции (я думаю что вы рассчитывали что неудачное првоедение вывалится в исключение),

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

В приведенном коде по-правильному д.б. типа
Если Док.Провести()=0 Тогда Прервать; КонецЕсли;
.
По большому счету - эти мои замечания про Провести() - относятся больше к общему подходу к программированию в части правильности написания кода.

В вашем коде за счет избыточности - в результате отлавливается, ну и ок.
Пусть код так и будет.
17. ksnik 578 09.10.19 07:16 Сейчас в теме
(16) У меня есть практический совет о "прервать" применительно к обработкам документов. Если требуется однозначно прекратить выполнение кода (вот как например требуется в данном случае) я всегда вместо "Прервать" пишу "ф = 1/0;", это красивее выглядит. Ато дальше после "Прервать" может что-нибудь нехорошее произойти.

п.с. У меня ведь тоже багофича получиласть, поэтому код статьи и обработку поправлю после удачного применения нового алгоритма на практике.
18. ksnik 578 10.10.19 11:11 Сейчас в теме
(13)
транзакция в коде - как у вас - излишняя.

Транзакция у меня в коде нужна для того, чтобы в случае выявленной ошибки распроведение не произошло и документ, который не удалось перенести, остался нетронутым (проведенным).
19. ksnik 578 10.10.19 12:04 Сейчас в теме
(18) дело в том, что если документ был проведен но теперь не может быть перепроведен может возникнуть необходимость разобраться почему он не проводится и выполнить эти условия, чтобы не поломать учет. И тогда при повторном запуске обработка переноса документов продолжит свою работу в штатном режиме.
10. CheBurator 3119 08.10.19 20:28 Сейчас в теме
(7) Имхо
В данном коде обертывать обработку единственного документа В МОНОПОЛЬНОМ Режиме - совершенно излишне. В приведенном коде при любой ошибке - выполнение стопорится (логику по крайне мере такую я наблюдаю).

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

Итого: транзакции если убрать и оставить только попытку - ничего в логике не поменяется.
?
20. ksnik 578 10.10.19 13:48 Сейчас в теме
(10)
надо продумать что будет при исправлении допустим ошибки непроведения и повторном запуске обработки).

Итого: транзакции если убрать и оставить только попытку - ничего в логике не поменяется.


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

Если транзакцию убрать, произойдут необратимые изменения, которые потом надо будет исправлять, тратить на это время.
11. CheBurator 3119 08.10.19 20:32 Сейчас в теме
(7) Не уверен, точно не помню, но что-то так:
Выполнение Док.Провести() вообще сомнительно в таком применении.
возможно проведение сломается с синтаксической ошибкой и вывалится в Исключение.
А вот если проведение просто НЕ ПРОВЕДЕТСЯ о вернет результат проведения - 0 (штатно как обычно установкой статусвозврата(0) - никакое исключение не произойдет. Поэтому надо типа внутри попытки
Результат = Док.Провести();
Если Результат =0 Тогда
//искуственно вызвать исключение или прерваться явно
3. sanek_kop 15 08.10.19 09:22 Сейчас в теме
Если база SQL, то я бы посоветовал использовать 1C++ и писать напрямую в необходимые таблицы. На практике это экономит достаточно много времени. В условиях когда работа предприятия встала, время работы - очень важный параметр. Изначально делали примерно так же как в этой обработке, только выбирали последний правильный документ (с верным временем) и перепроведение делали с интервалом в 1 секунду. После того как переписали на SQL длительность обработки с 15-20 минут уменьшилось до 5-10. Причем львиную долю. времени занимает установка ТА.
4. ksnik 578 08.10.19 11:08 Сейчас в теме
(3) вариант с 1C++ менее универсален так как для его реализации не достаточно функционала 1С. А код обработки можете написать сюда?
6. CheBurator 3119 08.10.19 15:15 Сейчас в теме
Если через 1С++ чистить нудевые записи в итогах таблицы то перенос ТА идет быстро на границе месяцев.
Оставьте свое сообщение