Двумерные штрих-коды – символики, разработанные для кодирования большого объема информации (до нескольких страниц текста). Такой код считывается с помощью специального сканера и позволяет быстро и безошибочно считывать информацию с документов. Это сделано с целью повышения эффективности ввода данных с бумажных носителей, то есть для быстрого считывания бухгалтерской и налоговой отчетности, подготовленной на машиночитаемых бланках с нанесением двухмерного штрих-кода символики PDF417.
Для печати машиночитаемых форм налоговых деклараций с двухмерным штрих-кодом PDF417 необходимо, чтобы на компьютере пользователя был установлен единый модуль печати машиночитаемых бланков и шаблоны машиночитаемых бланков.
Поддержка технологии формирования машиночитаемых бланков с двухмерным штрих-кодом включена в комплект форм регламентированной отчетности 1С. Скачать последнюю версию модуля двухмерный штрих-код PDF417 можно на сайте ФГУП "ГНИВЦ ФНС России" по ссылке http://www.gnivc.ru/inf_provision/form_templates/
После загрузки установите модуль:
Теперь приступаем к печати необходимого документа.
Проделаем это на примере бухгалтерского баланса. Заходим в меню Отчеты, Регламентированные отчеты, выбираем бухгалтерский баланс. После заполнения баланса переходим к печати, нам необходимо выбрать из двух предлагаемых вариантов первый: «Печатать сразу бланк формы с двухмерным штрихкодом PDF417».
Если выбрать "Показать бланк формы с двухмерным штрихкодом PDF417", то после выполнения необходимых подготовительных процедур на экране откроется форма предварительного просмотра, в которой предусмотрены возможности для просмотра сформированных отчетов и их непосредственного вывода на печать. Вот так будет выглядеть баланс с двухмерным штрих-кодом:
Для корректной обработки подготовленной печатной формы в налоговом органе, необходимо соблюдать некоторые требования к печати:
- Документ должен печататься только с одной стороны листа, не допускается печать сразу двух страниц на одном листе.
- Следует обратить внимание на качество печати. Считывание информации производится специальным сканером и для правильного распознавания им информации печать должна быть четкой и контрастной. Пятна, полосы и размытости от принтера, а также дефекты бумаги в зоне штрих-кода могут привести к неправильному считыванию. В данном случае нет гарантии, что до приемки дойдет та информация, которую Вы отправили, несмотря на правильность составления, выгрузки и шифровки.
- Изменение геометрических размеров печатаемых форм недопустимо.
- Листы отчетности в виде машиночитаемых форм не надо скреплять степлером или подшивать в скоросшиватель - это может повредить блок двухмерного штрихкода. Подготовленную печатную форму в виде машиночитаемой формы необходимо подписать и поставить печать.
Подготовленную таким образом отчетность необходимо представить в вашу налоговую инспекцию так же, как вы обычно это делаете.
Второй экземпляр можно подготовить для того, чтобы инспектор поставил на титульном листе отметку о приеме. Однако мы рекомендуем оставить себе "обычную" печатную форму отчетности - в том виде, как она утверждена Минфином России, без двухмерного штрих-кода.
В случае возникновения ситуации, при которой необходимо восстановить резервную копию информационной базы, работающую в рамках распределенной информационной базы, можно воспользоваться следующими рекомендациями.
Процедура восстановления информационной базы корневого узла
Напомним, что корневым узлом считается информационная база, у которой свойство Главный узел содержит значение Неопределено.
Восстановление корневого узла сводится к восстановлению резервной копии информационной базы.
После восстановления информационной базы корневого узла необходимо восстановить обмен данными в распределенной информационной базе. Для этого, над всеми информационными базами - узлами распределенной информационной базы - необходимо выполнить действия, аналогичные описанным в разделе "Процедура восстановления информационной базы подчиненного узла" данной статьи.
Процедура восстановления информационной базы подчиненного узла Процедуру восстановления информационной базы подчиненного узла можно разделить на несколько этапов:
* Восстановление в информационной базе подчиненного узла конфигурации главного узла
- Отключение от распределенной информационной базы - осуществляется путем установки свойству Главный узел значения Неопределено.
Для этого в режиме 1С:Предприятия необходимо выполнить метод менеджера планов обмена:
- Загрузка конфигурации главного узла - для восстановления работы в распределенной информационной базе необходимо полное соответствие конфигураций главного и подчиненного узлов. Для выполнения этого условия необходимо загрузить конфигурацию (.cf), полученную из главного узла, в информационную базу подчиненного узла (режим объединения конфигураций в данном случае использовать нельзя).
* Синхронизация номеров сообщений между главным и подчиненным узлами.
Для правильного обмена сообщениями в распределенной информационной базе необходимо, чтобы соблюдалось условие: номер принимаемого сообщения должен быть больше номера, записанного в реквизите НомерПринятого узла, соответствующего информационной базе - источнику сообщения.
Номер сообщения получается путем добавления единицы к номеру последнего принятого сообщения (значение реквизита НомерОтправленного узла, соответствующего информационной базе - приемнику сообщения).
* Подключение к распределенной информационной базе.
Для подключения информационной базы подчиненного узла обратно в распределенную информационную базу необходимо установить свойству Главный узел прежнее значение.
* Синхронизация данных главного и подчиненного узлов.
Синхронизация данных может выполняться в обе стороны: от главного узла в подчиненный и от подчиненного узла в главный. В обоих случаях достаточно лишь выполнить регистрацию требуемых данных в службе регистрации изменений (для этого можно воспользоваться методом менеджера планом обмена ПланыОбмена.ЗарегистрироватьИзменения()).
После выполнения описанных действий работа распределенной информационной базы может продолжаться в обычном режиме.
Введение
Многие из Вас, наверное, сталкивались с такой проблемой как, удаление элементов в справочниках, а значит, знают, какую кучу проблем это приносит. Я видал много способов восстановления порушенного справочника. Все их можно свести к следующему:
Заводится новый элемент справочника, аналогичный удаленному элементу, а потом он заносится во все документы, вместо удаленного элемента. Дальше все различается только способом занесения элемента в документы. Кто все исправляет в руки, кто пишет обработку - все зависит от опыта и квалификации исполнителя. После чего, необходимо перепровести все измененные документы. В общем, долгая и нудная работа, не всегда дающая 100% результат правильного восстановления. Есть, правда, один быстрый способ, основанный на формате DBF, точнее методах работы с ним.
Вот об этом мы и поговорим. Итак, что нам для этого надо. Иметь голову, наполненную мозгами, умелые ручки, знания основ перевода чисел из одной системы счисления в другую и любой редактор DBF файлов. Я, к примеру, использую winDBFview фирмы "Гэндальф".
Часть 1. Нам повезло.
С начала, собственно, о формате DBF и методах работы с ним. Думаю, рассказывать обо всем формате нет смысла, это тема отдельной статьи, поэтому расскажем о нем вкратце, для понимания тех действий, которые необходимо совершить.
Итак, что такое DBF формат и с чем его едят. Файл DBF можно разделить на две части: заголовок и, собственно, набор данных. В заголовке находится вся служебная информация, показывающая из каких полей состоит запись, типы этих полей, размер данных в полях, количество записей, размер записи, и откуда в файле начинаются записи, но это сейчас ни к чему. В наборе данных находятся, собственно, записи данных. В начале каждой записи стоит специальный байт - признак удаления. То есть когда вы говорите программе удалить запись, она ее фактический не удаляет, а ставит в первый байт записи метку о том, что данная запись удалена.
Отсюда следует, что если найти запись соответствующую удаленному элементу и сбросить признак удаления, переиндексировать базу, то можно обнаружить что, правильно удаленный
элемент будет восстановлен не только в справочнике, но всех документах.
Для тех, кто не знает что почем, показываю на примере:
Рабочая конфигурация ТиС, удалили элемент справочника товаров.
Запускаем winDBFview и выбираем Файл - Открыть. В появившемся окне диалога находим папку, в которую установлена база и открываем там файл. А какой? Вот ведь вопрос: как узнать? Да просто. Запускаем какую-нибудь оболочку, переходим в папку с базой и находим файл"1Cv7.DD". Открываем его для просмотра и находим там следующую строчку - "Справочник Номенклатура" - в нашем случае, у вас, вместо "Номенклатура" ставим название порушенного справочника (как он называется в конфигураторе) . И видим приблизительно следующее (см. рис. 1). То, что у меня выделено под надписью "Name" и есть искомое нами имя файла. Открываем его в редакторе DBF файлов, и смотрим. В поле CODE содержится код элемента справочника, а в поле DESCR наименование элемента. Как будете искать - уже дело техники и возможностей редактора. Найдя нужный элемент, сбрасываем байт пометки на удаления и сохраняем сделанные изменения.
Часть 2. Нам не повезло.
Но может быть, что вы не смогли быстро приехать к месту событий (всякое в жизни бывает). Приступили к восстановлению элемента. Запустили редактор. И начали искать и не нашли удаленный элемент. Куда он делся? Опять вернемся к формату DBF, и посмотрим, что происходит при добавлении новой записи. С начала программа ищет помеченные на удаление записи и если не находит, то добавляет новую запись. А если находит, вы правы, пишет вместо нее. И что делать, неужто опять все в руки?
Внимательно смотрим листинг файла "1Cv7.DD". Видите перед полем CODE поля ID и PARENTID. Для чего они нужны. Из описания поля (см. рис. 1), следует, что это какой-то идентификатор объекта. Оказывается 1С все равно, на тот код, что вы указали в справочнике элементов. Сама для себя она каждому объекту присваивает свой код. Значит, если мы узнаем этот код, то сможем создать запись полный аналог удаленной. Хм.... А как узнать этот код?
Есть много способов. Я, надеюсь, предлагаю вам самый простой. Итак, начнем.
Запускаем 1С. Лезем в Сервис - Монитор пользователей - Журнал регистрации. В появившемся диалоге делаем отбор: "во всем журнале, отбор по признаку удаление элемента справочника", жмем "ОК".
И смотрим журнал (см. рис. 2). Видите, там, где написано "Номенклатура 2258 04 ....", это и есть удаленный элемент справочника, его нам и надо восстановить. Сверху присутствует
строка: "<Объект не найден>(36201/)", 36201 - это и есть ID объекта. Создаем в справочнике новый элемент - полный аналог удаленному элементу. Выходим из 1С. Запускаем редактор, находим созданный нами элемент и поле ID ставим найденный. Внимательный читатель может сразу заметить существенное различие между соседними записями. Вот сейчас мы и переведем найденный идентификатор к нужному виду.
Перевод из одной системы счисления в другую, подробно изучается в школах и институтах, поэтому на этом останавливаться не будем. Изучив весь справочник, замечаем, что в идентификатор состоит из цифр и заглавных букв латинского алфавита. То есть может содержать все цифры от "0" до "9", и буквы от "A" до "Z". Значит, используется тридцати шестеричная система счисления 10 цифр плюс 26 букв. Приступим:
* 36201 делим на 36, получаем 1005 в остатке 21;
* 1005 делим на 36, получаем 27 в остатке 33;
В конце имеем три числа: 27, 33, 21. Заменяем их соответствующими значениями из приведенной ниже таблицы и получаем ID объекта RXL. Записываем его вместо ID созданного нами элемента. Номер можно получить средствами самой 1С использую функцию _IdToStr() и наоборот получит десятичное число из его тридцати шестеричного представления _StrToId().
Запускаем 1С, индексируем базу и смотрим, что имеем (см. рис. 3)
Что и требовалось получить. Пользуйтесь.
При работе с запросами нередко возникает ситуация, когда результат запроса необходимо упорядочить по представлению некоторого ссылочного поля. Например, необходимо упорядочить список номенклатуры по представлению. Заметим, что упорядочивание непосредственно по полю Представление приведет к не вполне ожидаемому результату - результат будет упорядочен в порядке возрастания ссылок объектов. Данный эффект проявляется из-за того, что поле Представление является виртуальным и на уровне базы данных состоит из нескольких полей, из которых уже в момент получения значения поля получается строка - представление. При упорядочивании же по этому полю произойдет последовательное упорядочивание по реальным полям, из которого оно состоит, в результате чего упорядочивание произойдет не по строковому представлению, а по внутренней ссылке поля.
Пример неправильного упорядочивания:
На самом деле, упорядочивание по представлению является довольно сомнительной операцией с точки зрения полезности результата. Для примера достаточно посмотреть на представления документов - эти строки содержат в себе даты, а упорядочивание дат как строк не даст осмысленного результата. Для того чтобы обеспечить упорядочивание, которое будет отвечать ожиданиям пользователей, следует использовать упорядочивание непосредственно по ссылочному полю и дополнительно указать в запросе ключевое слово АВТОУПОРЯДОЧИВАНИЕ. В таком случае запрос получит для каждого ссылочного поля реальные поля, по которым его необходимо упорядочить (для документа это будет дата и номер, для справочника - основное представление) и произведет упорядочивание по ним.