В 1С:Зарплата и управление персоналом 8 начисления делятся на Основные и Дополнительные. И когда появляется потребность зарегистрировать новое начисление возникает вопрос: А в какой список включать это начисление?
Обычно все начисления добавляют в основные или вообще как получится - Поэтому постоянно приходится сталкиваться с тем, что разовые доплаты находятся в основных начислениях, а доплаты, которые зависят от времени засовывают в дополнительные и пытаются считать вручную.
Хотя неправильное отнесение начисления к тому или иному виду во многих случаях не является критичным (хотя бывает и наоборот), все же лучше следовать правилам, определенным в конфигурации.
Принцип здесь простой: все начисления, которые имеют протяженность во времени, а также те, которые зависят от времени (отработанного и неотработанного) должны быть включены в Основные начисления.
Остальные начисления, можно включать в Дополнительные.
В инфраструктурах, активно использующих возможности web-сервисов 1С, нередко возникает потребность получения не только массивов данных из базы, но и различных файлов. Сам файл через веб-сервис так просто не передашь, но на его основе можно создать объект ДвоичныеДанные, который, в свою очередь, уже сериализуется в base64Binary. После такой операции наш веб-сервис без проблем передает данные и получателю остается только выполнить на своей стороне обратное преобразование и сохранить файл.
В качестве примера такого механизма я буду создавать в 1С счет на оплату на основании переданных через сервис ИНН контрагента и суммы, и возвращать PDF печатной формы. На этот раз, кроме примеров кода, дополнительно был записан скринкаст разработки.
Для начала создадим в пустой конфигурации справочник "Контрагенты" с реквизитом "ИНН" и документ "Счет" с реквизитами "Контрагент" и "СуммаДокумента".
Теперь добавим пакет XDTO "test_ws"с пространством имен "http://www.test-ws.org", в котором опишем тип объекта "File". Он будет содержать свойства:
Часто бывает потребность загружать данные из текстовых форматов, причем информация для загрузки бьется на 2 и более файлов.
Хорошо бы посредством SQL запроса выбирать данные из этих файлов и производить загрузку! Это вполне возможно и я считаю этот способ наиболее грамотный для решения таких задач!
Рассмотрим вариант как это сделать! Имеем 2 файла:
- Head_XXXXX.txt
- Rows_XXXXX.txt
Где XXXXX – порядковой номер пары файлов
Структура строки в Head_XXXXX.txt
Структура строки в Rows_XXXXX.txt
В каждой паре файлов несколько Заказов. Необходимо загрузить эти заказы в БД 1С
Для этого воспользуемся Microsoft.Jet.OLEDB.4.0
Для того чтоб данный драйвер корректно понимал структуру файлов необходимо в каталоге расположения данных файлов, перед выполнением запросов, создать специальный текстовый файл schema.ini cо следующими строками:
Как видим, здесь мы задаем структуру таблицы из файла.
Остается только выполнить запрос к полученной текстовой БД и обработать результат:
Когда возникает необходимость покупки ПО 1C, как правило, большая часть покупателей оказываются перед множеством выбора среди различных способов их приобретения, представляемых фирмой "1С" своим клиентам.
Кроме того, что пользователям доступны десятки различных решений, специально разработанных для разных задач одинаковое решение может выпускаться в виде различных вариантов, например, базовая поставка и версия ПРОФ . Непосредственно, об отличиях и особенностях базовых и ПРОФ версий решений компании "1С" будем говорить дальше.
Базовая поставка программ 1С - это, обычно, бюджетное ПО для одного пользователя. Как известно, базовые поставки предыдущей версии программ 1С:Предприятие 7.7 компанией "1С" теперь не выпускаются (например, купить базовая 1с ЗиУП 8 маожно, а вот ее аналог для 1С:Предприятие 7.7 больше не производится), то мы сравним возможности и ограничения базовой и ПРОФ версии программ 1С Предприятие 8.
Итак, базовая версия программ 1С - это, во-первых, локальная версия программы. Может возникнуть вопрос, но ведь и в описании к версии ПРОФ, так же написано "в комплект поставки включена лицензия на одного пользователя"? Разница заключается в том что, если в дальнейшем возникнет потребность добавить по локальной сети второго пользователя, для совместной работы нескольких пользователей, то для версии ПРОФ, достаточно купить клиентскую лицензию 1с, цена которой, как правило, меньше стоимости основной поставки. В базовой же версии организовать совместную работу по локальной сети нескольких пользователей невозможно. Ни покупка клиентских лицензий, ни покупка нескольких базовых версий не позволит работать нескольким сотрудникам в одной компьютерной сети.
Кроме вышеуказанного, относительно версии ПРОФ, базовая версия имеет ряд дополнительных ограничений, в том числе:
* не поддерживается изменение конфигурации, можно использовать только типовую конфигурацию и устанавливать ее обновления;
* не поддерживается ведение учета по нескольким фирмам в одной информационной базе; при этом имеется возможность ведения учета нескольких компаний в разных информационных базах на одном компьютере;
* одновременно с одной информационной базой может работать только один пользователь;
* не возможна работа в варианте клиент-сервер;
* не возможна работа распределенных информационных баз;
* не возможны COM-соединение и Automation-сервер.
Не смотря ни на что, базовая версия имеет ряд своих преимуществ. Несомненно - это ее цена! Купить 1С Предприятие 8.1 базовую версию для небольшого предприятия, где с программой будет работать только один сотрудник, будет по-настоящему бюджетным решением. Зарегистрированные пользователи имеют возможность бесплатного получения обновлений программы на инетрнет-сайте пользователей.
Кроме того, если Вы уже приобрели базовую версию, но в последствии выяснилось, что теперь Вам нужна версия ПРОФ. Можно будет приобрести ПРОФ версию этой же программы путем upgrade, т.е. заменой базовой версии на ПРОФ с зачетом стоимости.
Каждый из тех кто продает свой интеллектуальный труд, не раз сталкивался с необходимостью создания демо-версии разработки, дабы продемонстрировать клиенту функциональность, но при этом сохранить для клиента потребность в приобретении полнофункциональной версии. В этой статье я хотел бы рассмотреть несколько не сложных примеров создания демо-версий обработок/отчетов для платформы «1С:Предприятие 8».
Перед тем как приступить, собственно, к сути вопроса, хотелось бы сделать небольшое отступление для «крутых хакеров». Как известно, штатные возможности 1С, не представляют достаточно надежных средств для защиты исходного кода, поэтому приведенные здесь примеры – это исключительно защита от ПОЛЬЗОВАТЕЛЯ и ничего более.
Да и в целом, по моему глубокому убеждению, открытость кода в 1С – это одно из важнейших (если не самое важное) её достоинств. Поэтому я сторонник «установки пароля на модуль, поставки без исходного текста», только в случае демо-версии разработки. А при приобретении обработки, клиент приобретает её ЦЕЛИКОМ, в том числе и исходный код.
Для начала, немного общих моментов. Для того что бы ограничить использование нашего «уникального» функционала, будь-то алгоритм проведения документа или процедура формирования отчета, необходимо вынести код в модуль объекта и скрыть его от пользователя. Это можно достичь двумя путями. Во-первых установка пароля на модуль объекта. Что бы установить пароль, откройте модуль объекта, далее в меню «Текст» выберите пункт «Установить пароль». Во-вторых поставка без исходного кода. Что бы получить обработку/отчет без исходного кода, необходимо сначала создать поставку включающую в себя наш отчет без исходного кода, а затем сохранить его как внешний. Настройка поставки производится в диалоге «Конфигурация > Поставка конфигурации > Настройка поставки».
Итак, пример № 1. Ограничение по времени использования. Заключается в том, что функционал работает в течении определенного, ограниченного времени, например 10 дней. Для этого, нам надо как-то «запомнить» дату первого запуска, сделаем это с помощью реестра Windows.
Таким образом, осталось только вставить проверку на продолжение работы в нашу основную процедуру, например:
Для особо хитрых пользователей, можно сделать запрос точного времени из Интернета, что бы защититься от изменения системного времени. Например, так:
Пример №2. Ограничение по количеству выполнений. То есть к примеру, отчет в демо-версии можно сформировать не более 5-ти раз. Делается аналогично предыдущему варианту, разница заключается лишь в том, что в реестр на этот раз будем записывать номер текущего запуска.
Пример №3. Реализация защиты «пароль-ответ». Недостаток предыдущих способов, заключается в том, что полнофункциональная версия является отдельной разработкой, которую клиенту необходимо переслать, привести, установить и т.д. При использовании же, следующего способа, всё что потребуется для получения полной версии разработки – это зарегистрировать обработку, т.е. ввести правильный код.
Суть этого способа состоит в том, что при запуске у клиента формируется некий уникальный ключ, для которого, по только нам известному алгоритму, можно сформировать «ответный пароль». И в случае совпадения пары ключ-ответ обработка считается успешно зарегистрированной.
В качестве такого уникального ключа можно, к примеру, использовать серийный номер жесткого диска, MAC-адрес, имя пользователя и т.д. Рассмотрим пример с серийным номером жесткого диска.
Алгоритм получения «ответного значения» по ключу, ограничен лишь Вашей фантазией. Здесь же, в качестве примера, я буду использовать простую перестановку символов в обратном порядке.
Таким образом, наша процедура проверки и подтверждения регистрации будет выглядеть так:
Осталось только вставить проверку регистрации в нашу основную процедуру:
На данный момент, существуют различные декомпиляторы, плагины к Total Commander и др. разработки, позволяющие получить исходный программный код, даже если он закрыт паролем или поставляется в скомпилированном варианте. Дабы чуть-чуть усложнить жизнь пользователям умеющим пользоваться Google, можно ключевые моменты алгоритма, такие как работа с реестром или проверка регистрационного кода, дополнительно вынести во внешний шифрованный скрипт.
Начиная с Windows Script 5.0, появилась возможность чтения зашифрованных сценариев машинами сценариев. Поэтому любой сценарий написанный на VBScript или JavaScript, может быть выполнен в зашифрованном виде. Что бы преобразовать код на VBScript в зашифрованный вид, воспользуемся бесплатной утилитой «Windows Script Encoder», которую можно скачать с сайта Microsoft. В результате, например скрипт создания в реестре Windows раздела «HKEY_CURRENT_USER\Software\1C\1Cv8\Report», будет выглядеть следующим образом: #@~^ZAAAAA==jY~UtVV{ZMnlD+64N+^OvJU^DbwYcj4+^Vr#@#@&j4VsR"noqDrOPJuF;jw?KWDhCM+ 'FZ'F;-%'InwKDOwr~\(HE^V@#@&hyAAAA==^#~@
Приведу пример функции, осуществляющей проверку введенного пользователем регистрационного кода, с использованием шифрованного скрипта:
Эта функция вернет «Истина», если в качестве регистрационного кода передать ей строку «dce8a7196f14». Аналогичным образом можно скрыть и всю работу с реестром. Но, тем не менее, не следует забывать о существующих специализированных программных продуктах, позволяющих отслеживать чтение и запись реестра.
В заключении, хочется сказать, что как известно, надежная защита для программного продукта – это такая защита, стоимость взлома которой, превышает стоимость законного приобретения. Поэтому для крупных проектов следует использовать более надежные средства от незаконного копирования и использования, такие как вынос ключевых функций во внешние dll, аппаратные ключи защиты и пр. Здесь же я попытался привести несколько простых примеров в качестве основ так сказать… Источник
Механизм распределенных информационных баз предназначен для создания территориально распределенных систем на основе идентичных конфигураций 1С:Предприятия 8. Этот механизм позволяет переносить как данные 1С: Предприятия, так и изменения конфигурации информационной базы.
В тех случаях, когда предприятие представляет собой территориально распределенную структуру, зачастую сохраняется потребность в ведении единой системы учета. То есть необходимо иметь возможность работать в едином пространстве документов, получать отчеты, отражающие состояние дел как в территориально удаленных подразделениях предприятия, так и на предприятии в целом и т.п. При этом не всегда имеется возможность организовать работу всех подразделений с единой информационной базой в режиме он-лайн.
Для решения подобных задач и предназначен встроенный механизм. Распределенная система в этом случае должна иметь древовидную структуру, в которой существует корневой узел и определено отношение "главный - подчиненный" для каждой пары связанных узлов. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.
Обмен измененных объектов данных между каждым связанным узлом выполняется в формате ХML файлов. Перенос данных непосредственно между периферийными ИБ невозможен. Поэтому изменения данных, произведенные в одном из периферийных узлов распределенной ИБ попадают в другие периферийные узлы только через центральную ИБ.
В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.
Внесение изменений в конфигурацию возможно только в одном (корневом) узле распределенной системы. Изменения конфигурации передаются от главного узла к подчиненным.
Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.
Для того, чтобы документы, элементы справочников и другие объекты, созданные в разных узлах распределенной ИБ можно было различать, если это необходимо, в настройках программы можно указать префикс узла распределенной базы. В этом случае в при создании нового объекта (к примеру документа) будет автоматически добавляться указанный префикс.
В основе механизма распределенных информационных баз лежат универсальные механизмы обмена данными, такие как служба регистрации изменений, инфраструктура сообщений, XML-сериализация и чтение/запись XML-документов. Однако механизм распределенных информационных баз содержит ряд специфических возможностей, недоступных через универсальные механизмы обмена данными.
К таким возможностям относится интерактивное создание начального образа информационной базы, а также интерактивное чтение и запись изменений, которые могут быть выполнены сразу же, после указания того, что данный план обмена будет использовать механизм распределенных информационных баз. Таким образом, распределенная информационная база может быть создана без какого-либо дополнительного программирования, исключительно средствами визуального конструирования. При этом обмен в распределенной информационной базе будет осуществляться на основе некоторых алгоритмов, изначально заложенных в платформе.
Все действия, выполняемые при интерактивном обмене, могут быть продублированы программно, и кроме этого разработчик имеет возможность программно управлять принятием и отправкой изменений, а также выполнять реструктуризацию распределенной информационной базы, добавляя новые и удаляя существующие узлы.
Служба регистрации изменений
Суть регистрации изменений состоит в том, чтобы иметь перечень измененных элементов данных которые должны быть переданы в очередном сообщении тому или иному узлу, с которым производится обмен данными. При каждом изменении данных регистрируется, что имеются изменения, которые предстоит передать во все узлы, с которыми поддерживается обмен этими данными. При получении подтверждения приема сообщения, в котором были отправлены изменения, записи регистрации изменений должны быть удалены.
Состав данных, которыми осуществляется обмен, описывается в Плане обмена и представляет собой перечень элементов данных.
Для каждого элемента данных, указанного в плане обмена, ведется своя таблица регистрации изменений. Таблицы имеют разную структуру, в зависимости от того, для каких элементов данных регистрируются изменения, но все-таки структуры таблиц подобны. Каждая запись указывает на некоторый элемент данных, некоторый узел и содержит номер сообщения, в котором это изменение передано в первый раз.
При описании состава данных в плане обмена, для каждого элемента данных есть возможность указать признак Авторегистрации. Авторегистрацию можно «Разрешить» или «Запретить». Если авторегистрация разрешена, то при изменении данных регистрация изменений будет выполнена автоматически. Если запрещена, то регистрацию изменения можно выполнить «вручную», средствами встроенного языка.
Инфраструктура сообщений
С точки зрения плана обмена, между узлами происходит обмен сообщениями. Каждое сообщение содержит изменения данных, изменения конфигурации (если это распределенная информационная база) и ряд служебной информации. Каждое сообщение точно ассоциировано с планом обмена, имеет уникальный номер и имеет одного отправителя и одного получателя.
Сообщение оформляется как документ XML, имеющий определенную структуру. Инфраструктура сообщений позволяет формировать нужную структуру сообщения, и контролировать ее корректность. В частности, инфраструктура сообщений поддерживает нумерацию сообщений, и позволяет получать подтверждения от узла-получателя о приеме сообщений. Такое подтверждение содержится в каждом сообщении, приходящем от узла-получателя в виде номера последнего принятого сообщения.
Коллизии
При работе в реальных распределенных ИБ один и тот же объект может изменяться одновременно в различных узлах распределенной ИБ. И при переносе измененных объектов из одной ИБ в другую может случиться так, что в какую-либо ИБ будет загружаться объект, зарегистрированный в самой этой ИБ как измененный. Такая ситуация носит название коллизии.
Приведем описание действий системы в наиболее типовых вариантах коллизий: Один и тот же объект изменен более чем в одной ИБ.
Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются. Объект, измененный в одной ИБ, удален в другой.
В данном случае принцип заключается в том, что изменение всегда "главнее" удаления. В случае, если на центральную ИБ прибывает файл переноса, в котором содержится информация, что некоторый объект удален на периферийной ИБ, то в центральной ИБ объект не удаляется, а в записи таблицы регистрации изменений данный объект помечается как измененный. То есть при очередном обмене объект будет восстановлен в той ИБ, в которой он был удален, причем само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ. Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.
При загрузке изменений, если загружается информация об удалении объектов, автоматически включается механизм контроля ссылочной целостности и выполняется проверка наличия ссылок в данной ИБ на объекты, которые переданы как удаленные.
В случае обнаружения коллизии такого рода, вне зависимости от того на какой из ИБ она была обнаружена, выполняется следующее: удаление не выполняется, а в таблицу регистрации изменений заносится запись о том, что объект должен быть перенесен в адрес той ИБ, из которой была прислана информация о его удалении.
При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Таким образом на сегодняшний день платформа 1С:Предприятие предоставляет очень удобный механизм, использование которого относительно просто и не требуется никаких навыков в программировании, а благодаря механизму автоматического обмена от пользователя даже не требуется думать об актуальности его распределенной информационной базы.
Система компоновки данных (СКД) – является визуальным средством для построения и вывода отчетов, без использования кодирования на языке 1С. Т.е. мы можем задавать источники данных, способ их вывода на экран, при этом, не написав ни строчки кода.
Сама идея СКД не является чем-то новым, данный принцип использован во множестве программ. Нечто похожее реализовано в MS Access, MS SQL 2005, также существуют встраиваемые в различные среды разработки компонент, самый типичный FastReport.
В 1С уже есть конструктор выходной формы , который может формировать простые отчеты.
Но когда возникает потребность в формировании отчетов с сложной структурой, тут приходится полученный конструктором отчет серьезно переделывать. Также в типовых конфигурациях (УПП, УТ, БП) можно формировать отчеты на основе «УниверсальныйОтчет». В других конфигурация есть свои механизмы, например в конфигурациях фирмы Рарус формирования отчетов происходит на основе создаваемого вручную макета:
Часто бывает потребность загружать данные из текстовых форматов, причем информация для загрузки бьется на 2 и более файлов.
Хорошо бы посредством SQL запроса выбирать данные из этих файлов и производить загрузку! Это вполне возможно и я считаю этот способ наиболее грамотный для решения таких задач!
Имеем 2 файла:
- Head_XXXXX.txt
- Rows_XXXXX.txt
Где XXXXX – порядковой номер пары файлов
Структура строки в Head_XXXXX.txt :
Колонка1 20 символов – Номер заказа
Колонка2 5 символов – Код контрагента
Колонка3 10 символов – Дата заказа
Колонка4 10 символов – Дата доставки
Колонка5 10 символов – Дата сбора
Колонка6 4 символов – Количество строк в ТЧ
Структура строки в Rows_XXXXX.txt :
Колонка1 20 символов – Номер заказа
Колонка2 7 символов – Артикул номенклатуры
Колонка3 9 символов – Количество в базовых ед. изм.
В каждой паре файлов несколько Заказов.
Необходимо загрузить эти заказы в БД 1С
Для этого воспользуемся Microsoft.Jet.OLEDB.4.0
Для того чтоб данный драйвер корректно понимал структуру файлов необходимо в каталоге расположения данных файлов, перед выполнением запросов, создать специальный текстовый файл schema.ini cо следующими строками:
Как видим, здесь мы задаем структуру таблицы из файла.
Остается только выполнить запрос к полученной текстовой БД и обработать результат:
Основные начисления и дополнительные - в чем разница? .gif)
