В эксперименте не участвуют:
а) упаковка, которая включена в перечень товаров, участвующих в эксперименте, и товар, который упакован в такую упаковку, не включен в перечень товаров, участвующих в эксперименте.

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

Проблемы формирования отчета:

1. В шапке отчета указано «дата ввоза товаров, упаковки».
Что есть дата ввоза, дата подачи ДТ, дата выпуска или дата фактического пересечения границы? А в случае выпуска до подачи это дата подачи/выпуска заявления, или дата подачи/выпуска ДТ по заявлению или все-таки дата пересечения границы?
Что есть дата ввоза, когда ИМ 40 завершает ранее открытую таможенную процедуру? Например, завершение временного ввоза, или процедуры таможенного склада. Ведь в этом случае фактический ввоз (например, в режиме ИМ 70) мог быть год или два назад.

2. Масса ввезенного товара/упаковки округляется до кг. Что указывать, если вес меньше кг и по правилам округления округляется до 0? Такие товары/упаковки надо учитывать, но ставить сумму сбора 0, или не учитывать вообще?

3. Распределение веса в случае, когда товар упакован в несколько видов упаковки. Вес всей упаковки можно рассчитать, как разницу между весом нетто и брутто, но как его распределить между двумя или тремя упаковками? Вопрос риторический…

4. Вес поддонов. Очень часто при заполнении ДТ вес поддонов указывается только в одном из товаров. Например, везется партия из 5 товаров, которые находятся на 10 паллетах. Общий вес паллет составляет 250 КГ. Если он указан в первом товаре, который не является товаром эксперимента, то такой товар и его упаковка (все 10 паллет) в отчете не отразятся. Или наоборот, вес всех паллет попал в товар, который должен быть в отчетности. Соответственно весь вес паллет будет учтен, хотя «отчетный» товар может занимать лишь часть одной из паллет.

5. Наличие индивидуальной упаковки. При наличии индивидуальной упаковки в ДТ не всегда указывается чистый вес товара (без учета всех видов упаковки). Например, везем ящик водки, есть картонная коробка и есть бутылка, вес коробки определить можно, а вес пустой бутылки нет, потому что в 38-й графе не будет указан вес водки без бутылки.
Но и бутылка и коробка, это упаковки, которые подлежат утилизации.

6. Определение, является ли упаковка попадающей под утилизацию. В ДТ в части упаковки указывается лишь код вида упаковки по классификатору, например, код BX – коробка или CK – бочка. Исходя из кода упаковки не всегда возможно определить материал, то ли коробка картонная, то ли пластиковая, то ли деревянная и, как следствие, невозможно однозначно определить попадает ли упаковка под утилизацию, а если и попадает, то в какой группе
товаров/упаковки ее необходимо учитывать.

https://otrs.alta.ru/otrs/index.pl?Action=AgentTicketZoom;TicketID=9338076#14432389

Если все сложно, то можно записаться тут: https://www.alta.ru/support/remote_installation_request/
И Вам помогут перенести дистанционно (с 9ти до 18 мск по будним дням)

c:\alta\altaupd.exe –pgtdwin –oc:\alta\ -quiet –d 

Этот исполняемый файл ставим в планировщик заданий windows на нужное время, например ежедневно в 00:00. После этого каждый день в полночь будет запускаться программа обновления и обновлять программу ГТД. При этом после обновления ГТД перезапускаться не будет (указан ключ -d).

Программа обновления altaupd.exe имеет следующие ключи запуска:

-p - определяет программу Альта, которая будет обновляться.

Возможные имена программ описаны в файле aupdater.ini - определяются именами разделов, например,

-pgtdwin - ГТД windows;

-o - задает каталог, где установлена обновляемая программа, например -oC:\alta\;

-setup - Показывает окно настроек программы, где задаются параметры связи; - Хост, Прокси и т.д.;

-check - Позволяет проверить наличие обновления. Если обновление есть, в каталоге программы создается файл <имя программы>.UPD.

При работе не создается никаких окон и не выводится никаких сообщений - altaupd проверяет обновление и закрывается;

-quiet - Обновлять "тихо". Не показывает окно с новостями и загружаемыми файлами, не требует человеческого вмешательства;

-r1 - Режим сервера. В этом режиме Aupdater создает зеркало каталога ftp.alta.ru\upl_gtd на локальной машине в каталоге \update\tempsrv;

-bXXX - ключ для перезапуска программ после процесса обновления. XXX - зашифрованная в HEX формат строка перезапуска;

-?(h) - Выводит окно со списком ключей запуска;

-d – не перезапускать программу после обновления

Посмотреть, включен ли клиент можно в админке. Будет надпись "Запросы доступны" или "Запросы НЕ доступны".

Контейнеры тоже вроде заработали нормально, можно ставить на слежение.

По клиентам, не подходящим под эти требования, буду и далее вручную подключать.

ВОЗМОЖНЫЕ ОШИБКИ И СПОСОБЫ ИХ УСТРАНЕНИЯ

Тип ошибки Сообщение Тип сообщения Действия
Ошибка авторизации Сообщение об ошибке TP.99999 Повторно инициируйте процесс авторизации. Дважды кликните на сообщение со статусом
Требуется оплатить платежи и типом MY.00102

Ошибка платежа Сообщение об ошибке TP.99999 Повторно инициируйте процесс оплаты. Дважды кликните на сообщение со статусом Требуется оплатить платежи и типом MY.00103
Повторно передавать запросы на оплату возможно до тех пор, пока оплата не будет проведена успешно.

·         Версия SQL-сервера, на который переносится база данных, не должна быть ниже версии сервера, откуда переносится база.

·         Если данные переносятся с целью их последующего объединения утилитой MergeDB, то необходимо учитывать, что в редакции Express существуют ограничения на размер базы данных. Если при объединении этот размер будет превышен, операция завершится с ошибкой.

Для переноса данных необходимо воспользоваться оснасткой Microsoft SQL Server Managment Studio, которую можно найти в меню Пуск - Программы - Microsoft SQL Server.

1. Сначала необходимо сделать резервные копии основной и всех дополнительных баз данных Альта-ГТД, которые дожны быть перенесены.

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

В открывшемся окне в блоке Назначение укажите, что создание резервной копии производится на диск (установлено по умолчанию), и задайте месторасположение файла резервной копии.

Обратите внимание, что там должен быть определен только один файл.

Нажмите ОК.

Повторите эту операцию для всех остальных баз, которые требуется перенести.

2. Перенесите полученные файлы резервных копий на другой SQL сервер.

3. Восстановите базы данных.

Для этого необходимо в Managment Studio выбрать в списке Базы данных, и в контекстном меню выполнить команду Восстановить базу данных.

В открывшемся диалоге на закладке Общие в блоке Источник необходимо выбрать Устройство и указать месторасположение файла резервной копии.

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

В блоке План восстановления отметьте нужный резервный набор данных.

Важно! Необходимо запомнить соответствие старой и новой баз данных.

На закладке Файлы установите флажок Переместить все файлы в папку и/или задайте путь к новому месторасположению файлов в списке в колонке Восстановить как.

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

Примечание: указанный каталог должен существовать.

Нажмите ОК.

Аналогично восстановите все другие базы.

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

Для этого необходимо выполнить запрос. В Managment Studio в панели инструментов нажать кнопку Создать запрос, и в открывшееся окно вставить приведенный ниже скрипт.

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

Обратите внимание, что в последнем случае новое имя рабочей базы данных указывается после символа @, префикс _gtd_ed@ изменяться не должен!

use [gtd_new]
go

update EdMsgs
set MsgDB = 'NewDB_ED'
where MsgDB = 'OldDB_ED'
go

use [gtd_ed_new]
go

update [version]
set Program = '_gtd_ed@gtd_new'
go

Использовать 2008 крайне нежелательно ввиду "корявости" полнотекстового поиска.

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

Следует отметить, что, как и у всех продуктов Mocrosoft, чем выше версия, тем больше системных ресурсов они требуют.

Поэтому я бы рекомендовал не гнаться "за модой", и выбрать 2012 или 2014, хотя ничто не мешает выбрать и более свежую версию.

По производительности (общие рекомендации).

SQL сервер - это продукт, который очень любит, когда установлено много памяти. Если его никак не ограничивать, он по умолчанию будет использовать всю доступную.

Поэтому памяти рекомендуется 16+ Гб.

Второй аспект - скорость доступа к данным. Чем больше размер самой БД, тем более скоростной доступ должен быть организован.

Поэтому тут два варианта - либо периодически "подрезать" базу данных, либо ставить производительные диски, например, SSD, либо организовывать RAID-массив.

Еще одна рекомендация - под данные БД желательно выделять отдельный диск. Т.е. на одном диске устанавливается система, а на другом - база данных.

В любом случае, рекомендуется поддерживать оптимальный размер базы данных порядка 30-60 Гб (в зависимости от производительности сервера).

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