Письма с превышением уплаты за год

[lubezniy]

Я кажется нашёл источник проблемы. Попробуйте.

Точно... Такие косяки я массами правил в sverka.pas, а до xmlwork руки не дошли. Полный объём тестовых данных после правки одной строки обработался за 3 минуты (!). Завтра же будет версия. Спасибо огромное.

[lubezniy]

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

Если уберут уплаты, будет уже неплохо - всем будет меньше возни.

[vk65]

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

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

[lubezniy]

Уважаемый Виктор! Похоже, что VK65 настолько увлёкся самим процессом совершенствования программы, что отвлёк Вас от сообщений LEONID and SOVA64 по поводу предполагаемых изменений в формах и принципе отчётности с 2011 года. Обратите пристальное внимание!!!

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

[Михаил Иванович]

Уважаемый Виктор! Похоже, что VK65 настолько увлёкся самим процессом совершенствования программы, что отвлёк Вас от сообщений LEONID and SOVA64 по поводу предполагаемых изменений в формах и принципе отчётности с 2011 года. Обратите пристальное внимание!!!

[lubezniy]

Я кажется нашёл источник проблемы. Попробуйте.

Чёрт... я уже выложил версию.
Спасибо, завтра буду пробовать.

[vk65]

после прочтения вот этого сообщения Leonidа
https://www.buhsoft.ru/forums/showth...t=23802&page=2

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

А мне после этого:

Сообщение от upfr06
Коллега, просветите - что же будет с 2012 года? СЗВ-100?

судя по предсказаниям, конец света

[lubezniy]

Дорогие Виктор и Vk65!
Ваше деловое общение вызывает искреннее уважение!
Но после прочтения вот этого сообщения Leonidа
https://www.buhsoft.ru/forums/showth...t=23802&page=2

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

Уважаемая Sova64!
Лично я успел внимательно прочитать эту тему и не питаю никаких сомнений в том, что не успею стопроцентно усовершенствовать программу до конца света. Вместе с тем, будучи в должной степени загруженным по работе, я понимаю разницу между рабочими часом и двумя и потому не считаю низкую скорость обработки несущественным недостатком, если только он не обусловлен объективными причинами. А отсутствие этих объективных причин показывается тем, что по итогам наших с vk65 вчерашне-сегодняшних обсуждений и усовершенствований скорость обработки в новой версии удалось поднять практически вдвое. И, если по итогам последующих работ выявится возможность дальнейшего сколь-нибудь значительного увеличения скорости обработки без создания лишних проблем для пользователей, я непременно сделаю это в программе.
Что же касается вопросов перспективности использования этой программы в свете возможных изменений, то лично я этим изменениям буду только рад. Но, судя по сообщениям пользователей, кому-то всё равно придётся подчищать хвосты с переплатами после того, как эти изменения появятся в более или менее рабочем варианте. Сколько времени это будет продолжаться, предсказать трудно. Но в любом случае подчистка хвостов нередко делается "по остаточному принципу", в т. ч. и по части временных ресурсов. Так что и тут эта работа актуальной будет.

[vk65]

Возможно, есть смысл покопаться в самом xmlwork.pas - вдруг там удастся что-то ускорить.

Я кажется нашёл источник проблемы. Попробуйте.

[lubezniy]

Попробую повнимательнее посмотреть логику работы. А пока - просто мои мысли на этот счет.
На момент нажатия кнопки "обработать" известен рег.номер. После этого можно:
- Создать список файлов, относящихся к данному страхователю.
- Файлы, превышающие определенный размер, порезать на части, оставив у каждой из частей заголовок исходного файла.
- Создать новый список файлов.
- Продолжить обработку.

И в таком раскладе логика работы упирается в чтение (полное или частичное) файла и посимвольный поиск какого-то по счёту (скажем, 50-го) или последнего (при частичном чтении) закрывающего тэга СВЕДЕНИЯ_О_СТРАХОВЫХ_ВЗНОСАХ_И_СТРАХОВОМ_СТАЖЕ_ЗЛ. У меня фактически используется тоже посимвольный поиск, дающий такое время в процессе обработки. Может, в таком раскладе это и даст некоторое ускорение, но это нужно экспериментировать. Возможно, есть смысл покопаться в самом xmlwork.pas - вдруг там удастся что-то ускорить.
А со списком файлов при таком алгоритме всплывают дополнительные проблемы. Пользователю в протокол для поиска информации нужен номер не части разбитого, а целого нормального файла.
Что касается рег. номеров в именах файлов, здесь мне интересно бы узнать, чей номер проставляется в имя файла, сдаваемого не страхователем, а, скажем, представителем по доверенности. Если ставится номер отправителя (представителя), то делить файлы по номерам уже нельзя.

[lubezniy]

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

[vk65]

Уже нельзя: ограничение в 200 опять вступило в силу даже для СЗВ-6-2.

Видимо, ноги у этого ограничения растут из того же места.
Если бы изначально было введено ограничение в ~50, проблема решилась бы сама собой. А в данный момент, у Вас же в наборе есть файл на 2620 ЗЛ. И он уже никуда не денется, ведь данные нужно обрабатывать с 2010 г.

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

Попробую повнимательнее посмотреть логику работы. А пока - просто мои мысли на этот счет.
На момент нажатия кнопки "обработать" известен рег.номер. После этого можно:
- Создать список файлов, относящихся к данному страхователю.
- Файлы, превышающие определенный размер, порезать на части, оставив у каждой из частей заголовок исходного файла.
- Создать новый список файлов.
- Продолжить обработку.

[lubezniy]

Виктор, Вы меня видимо не поняли. Допустим, есть реальная организация с 1000 ЗЛ. Можно всех работников выгрузить в 1 файл.

Уже нельзя: ограничение в 200 опять вступило в силу даже для СЗВ-6-2.

А можно в 50 файлов по 20 чел. И второй вариант Вашей программой будет обработан значительно быстрее, так как основное замедление происходит при парсинге строки Data.

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

[vk65]

Не получится, если только не хочется ещё больше замедлить процесс

Виктор, Вы меня видимо не поняли. Допустим, есть реальная организация с 1000 ЗЛ. Можно всех работников выгрузить в 1 файл. А можно в 50 файлов по 20 чел. И второй вариант Вашей программой будет обработан значительно быстрее, так как основное замедление происходит при парсинге строки Data.

[lubezniy]

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

Не получится, если только не хочется ещё больше замедлить процесс (по сравнению с тем, что я ещё не выложил). Мой парсер (весь целиком прописан в xmlwork.pas) обрабатывает тэги не по очереди, как другие, а рекурсивно, начиная с корневого тэга (т. е., ФайлПФР) и заканчивая последним child-ом. На выходе выдаётся полный массив тэгов с атрибутами, вложенными тэгами и их содержимым. Поэтому обрабатывается сразу весь файл. И именно этот этап, на мой взгляд, занимает больше всего времени: формирование структуры TSZV6File - это уже цветочки. Для смены расклада нужно переписывать почти всю логику программы и фактически заново её отлаживать.