Qual o cronograma previsto para a implantação da API do Módulo Recintos?

Resposta (atualizada em 05/07/2021):

O projeto iniciou no segundo semestre de 2019. Há 22 eventos mapeados e que foram desenvolvidos na API.
Cronograma:
- abril/2020: 11 eventos foram disponibilizados em ambiente de validação;
- dezembro/2020: outros 11 eventos foram disponibilizados em ambiente de validação, ou seja, todos os endpoints estão disponíveis para testes;
- julho/2021: atualização do ambiente de validação para testes;
- até novembro/2021: ambiente de produção e obrigatoriedade;

Quais intervenientes devem enviar eventos na API do Módulo Recintos:

Resposta:

Os perfis de autenticação que devem ser utilizados pelas empresas são: a) Depositário (DEPOSIT) ou b) Operador Portuário (OPERPORT). O processo de autenticação deve ser executado conforme descrito em Autenticação PUCOMEX (https://docs.portalunico.siscomex.gov.br/swagger/rcnt.html).

Devo utilizar e-CPF ou e-CNPJ para autenticação e posterior envio dos eventos?

Resposta:

Salientamos que o serviço de autenticação no Portal Único Siscomex será evoluído para aceitar somente e-CNPJ para fins da API-Recintos. A estimativa é que tal evolução ocorra em setembro/2020. Dessa maneira, a autenticação por e-CPF é temporária e utilizada apenas no ambiente de validação do Módulo Recintos. 

Devo utilizar e-CNPJ da filial ou da matriz para autenticação e posterior envio dos eventos?

Resposta:

Cada recinto deve utilizar o seu e-CNPJ de filial para autenticação e envio dos dados pois é esse CNPJ que está associado ao recinto dentro do cadastro.

Como o Recinto poderá verificar se o estoque no ADE02 está batendo com o estoque físico do terminal? Atualmente na DTE, geramos um arquivo do estoque no sistema do recinto no layout definido pela DTe e encaminhamos à ABTRA. Este arquivo é comparado com o estoque informado no sistema DTE (através dos eventos enviados em todas as operações) e devolve ao recinto um relatório com as divergências entre os sistemas. Este relatório é gerado diariamente e as divergências são corrigidas imediatamente pelo recinto.

Resposta:

O Módulo Recintos é uma API para recebimento de informações dos recintos aduaneiros. 

Para cada envio de eventos será devolvido um protocolo que atesta o recebimento das informações prestadas. 

Demandas por funcionalidades ou consultas que auxiliem a conformidade do recinto aduaneiro poderão ser estudadas nos moldes das iniciativas INTEGRA COMEX, por demanda dos intervenientes.

Existe uma ordem para envio dos endpoints disponibilizados? A ordem deverá seguir o fluxo de acordo com a ocorrência das operações no terminal, sem interrupções, independente de recusas de XMLs de pacotes anteriores relacionados à informação deste pacote?

Exemplos:

Ao enviar a informação de saída de um contêiner do terminal, caso o JSON da entrada deste contêiner tenha sido recusado, o terminal deve mesmo assim enviar o JSON da saída? Estes pacotes serão recusados caso os pacotes anteriores relacionados não estejam aceitos? O terminal deve obrigatoriamente corrigir o pacote de entrada antes de enviar o de saída?

Caso não tenha sido enviado o JSON de credenciamento de uma pessoa física, o terminal deve mesmo assim enviar o JSON de acesso da entrada e saída desta pessoa da área alfandegada?  Estes pacotes serão recusados caso os pacotes anteriores relacionados não estejam aceitos? O terminal deve obrigatoriamente enviar o credenciamento do usuário antes de enviar movimentação para este usuário?

Resposta:

Há algumas premissas no projeto da API do Módulo Recintos que visam facilitar o envio dos eventos:

1) O registro e envio, via de regra, deve ocorrer de forma simultânea à ocorrência física, ou seja, em ordem cronológica conforme a logística da carga no recinto aduaneiro;

2) Os eventos são independentes ainda que no mundo real haja um sequencialismo oriundo da logística;

Ou seja, se há um evento em contingência os eventos posteriores podem e devem ser enviados.

Respondendo os exemplos:

- Para a API os eventos são independentes e é possível enviar um evento sem que o antecessor dele (pela ordem logística) tenha sido enviado. É possível que a TI organize uma fila de envio de eventos em contingência para essas situações. Sempre lembrando que a regra é o item 1 (em ordem cronológica) mas nos casos de contingência ou não recepção, o recinto deve corrigir e/ou reenviar o evento.

- O mesmo vale para o exemplo do credenciamento de pessoa e o acesso de pessoa.

O credenciamento, via de regra, deve ocorrer antes, porém a API permite o envio do acesso de pessoa antes do credenciamento visto que os eventos são independentes para a solução tecnológica.

Dessa forma acreditamos dar a flexibilidade necessária no envio de eventos lembrando que o envio fora de ordem deve ser motivado (recusa do pacote, contingência, retificação...).

Existe algum limite de envio de requisições por segundo/minuto ou os eventos poderão ser enviados no momento que ocorrem, independentemente da quantidade?

Resposta:

O registro e envio, via de regra, deve ocorrer de forma simultânea à ocorrência física, ou seja, em ordem cronológica conforme a logística da carga, veículos ou pessoas no recinto;

O ambiente de validação deve ser utilizado apenas para que as equipes de TI implementem as integrações, ou seja, enviando poucos eventos.

Já no ambiente de produção os eventos devem ser enviados na medida em que ocorrem no mundo real.

Durante a validação posso entrar em contato com Serpro por canal específico?

Resposta:

Conforme a Notícia Sistemas n° 004/2020, as dúvidas ou problemas tecnológicos relacionados à api devem ser tratadas com o Serpro: pucomex-api-recintos@serpro.gov.br

Caso se trate de uma orientação de preenchimento de atributos podemos incorporar ao Perguntas Frequentes.

Caso se trate de um problema tecnológico o mais indicado seria a resolução do caso em concreto com o Serpro.

Orientamos que no contato com Serpro seja indicada a request e não apenas a response.

Notícia Sistemas n° 004/2020:

http://www.siscomex.gov.br/sistemas/sistemas-n-004-2020/

Qual a diferença entre o ID evento(chave) ou protocolo solicitado nos eventos? Todos campos são obrigatórios? Existe um padrão na API em geral para envio desses campos? 

Resposta:

O campo idEvento, atributo básico de todos os eventos, deve indicar os registros das tabelas do sistema do recinto de onde saíram os dados que compõem o evento. Por exemplo: chave tabela 1+ … + chave tabela n - tantas chaves quantas forem as tabelas necessárias para montar o registro do evento. Em caso de auditoria, permite que a RFB localize os dados no sistema do recinto.

Em se tratando dos atributos específicos dos eventos, para equipamentos georreferenciados (há uma lista desses equipamentos no evento de georreferenciamento) é necessário enviar o protocolo (atualizado) que corresponde ao envio do evento de georreferenciamento para aquele equipamento.

São coisas distintas.

Os campos CPF do operador da ocorrência e CPF do operador do registro são obrigatórios? A documentação técnica da API está dizendo que são obrigatórios.

Resposta:

O asterisco, indicador de campo obrigatório, será revisto na documentação da API pois há eventos, e apenas esses, em que não há operador de ocorrência ou de registro. Por exemplo, o acesso de pessoa via catraca com biometria ou o agendamento de acesso de veículos via portal do recinto aduaneiro.

Os endpoints Atribuição/Troca de Navio, Embarque/Desembarque no Navio e Posição do Contêiner estão fora do escopo de armazém alfandegado Aéreo, correto? 

Resposta:

Há eventos mapeados para a API do Módulo Recintos que são comuns a todos os modais (exemplo: acesso pessoas, acesso veículos, dentre outros) e há eventos próprios de um e outro modal, por exemplo: Atribuição/Troca Navio e Embarque/Desembarque de Navio, ambos para o aquaviário; Chegada ao Ponto Zero, na importação do modal aéreo.

Cada recinto aduaneiro vai implementar a integração com os webServices do seu ramo de operação.

Como faço para retificar informações em eventos já enviados? Devo enviar apenas parte retificada do evento ou todo novamente?

Resposta:

O envio de eventos retificadores substitui completamente as informações prestadas no evento retificado. 

Observar que no caso de evento retificador ou de exclusão, o protocolo do evento retificado ou excluído deve ser informado para possibilitar a correta vinculação.

Como deve ser o cancelamento de eventos já enviados? Devo informar todos os atributos do evento original?

Resposta:

Para cancelamento/exclusão de eventos enviados anteriormente é suficiente o preenchimento do cabeçalho do evento, indicando principalmente o "Protocolo do Evento retificado / excluído ".

Em relação a "dtHrOcorrencia", "dtHrRegistro", "cpfOperOcor" e "cpfOperReg", a distinção entre as informações de data e CPF de ocorrência e de registro é aplicada nos casos em que o sistema está fora do ar e nos demais casos as informações de ocorrência e registro seriam as mesmas? Ou seja, as informações de data e CPF de ocorrência só serão diferentes da data e CPF de registro se a TAG "contingencia" for "true".

Resposta:

Via de regra a "dtHrOcorrencia", "dtHrRegistro" e "cpfOperOcor" e "cpfOperReg" devem ser os mesmos quando não ocorrer contingência. Entretanto, também podem ser diferentes em situações em que não haja contingência, por exemplo: uma retificação.

Os campos CPF operador ocorrência e CPF operador registro podem ser transmitidos nulos. Considerar, por exemplo, o registro de entrada de pessoas pela catraca. Não há operador de ocorrência e nem de registro já que tudo pode ser automatizado via biometria. Por outro lado, em caso de pane na mesma catraca e/ou sistema de biometria, por exemplo, estes campos serão preenchidos quando do envio do evento pois houve uma entrada de pessoa com captura e registro manual de informações (CPF operador ocorrência) e a inserção (digitação) dos dados coletados em papel no sistema informatizado (CPF operador registro sistema).

Em caso de indisponibilidade da Ferramenta (sistema) dos Terminais para envio de informações para a aplicação API – Recintos existe alguma forma de contingência para informar os dados? (Algum portal para lançar estas informações?) Como devemos proceder em uma situação destas?

Resposta:

No caso de contingência, esses eventos devem se enviados após a normalização do sistema. 

O campo "Contingência [S/N]" indica que um evento ocorreu durante uma contingência. Transmitir como true sempre que ocorrer falha operacional no sistema do recinto que impeça o registro e/ou envio de informações.

O único padrão disponibilizado para estes serviços é o formato JSON? XML não existe no momento?

Resposta:

O único padrão é o JSON.

Realizando alguns testes de envio percebemos que a API aceita o envio do mesmo "ID EVENTO" para a operação de inclusão mais de uma vez. Gostaríamos de saber como seria este comportamento. Quando for enviado o mesmo "ID EVENTO" mais de uma vez para o mesmo evento para operação de inclusão. Como vocês procedem? Consideram o último envio? ou tratam de outra forma?

Resposta:

Os campos “idEvento” e “tipoOperacao” fazem parte das informações comuns a todos os eventos, as quais devem ser agregadas pelo interveniente responsável pelo seu envio.

O campo “tipoOperacao” possui os domínios: Inclusão, Retificação ou Exclusão. Esse campo determina se um evento foi recepcionado como um evento novo ou retificador/exclusão.

No caso de retificação ou exclusão de eventos, há a obrigação de informar o protocolo do evento retificado ou excluído para possibilitar a correta vinculação.

O envio de eventos retificadores substitui completamente as informações prestadas no evento retificado. 

O campo “idEvento” deve indicar os registros das tabelas do sistema do recinto de onde saíram os dados que compõem o evento. Logo, é o identificador do evento no Sistema do Recinto. Por exemplo, pode ser composto por: Chave tabela 1+ … + chave tabela n - tantas chaves quantas forem as tabelas necessárias para montar o registro do evento. Em caso de auditoria de sistema, permite que a RFB localize os dados no sistema do recinto. 

Para o campo “idEvento” não há validação, ou seja, o padrão adotado pelo recinto aduaneiro como identificador do evento será recebido neste campo.

Exemplificando: se a API do Módulo Recintos receber 2 eventos “tipoOperacao=Inclusão” vamos considerar 2 ocorrências no mundo real, uma para cada evento.

Caso o sistema de controle de acesso de pessoas fique off-line, devemos anotar no formulário de contingência e posteriormente entrar com esses dados no sistema de forma manual?

Resposta:

Este procedimento já consta inclusive na norma de alfandegamento.

Sempre que algum recurso apresenta falhas (catraca, ocr, balanças, o próprio sistema informatizado de controle do recinto, etc) os dados devem ser coletados de forma manual e inseridos no sistema do recinto assim que possível.

Com a nova API o que muda é que além de lançar os dados no sistema é necessário, ainda, enviar os eventos correspondentes imediatamente.

Verificar, ainda, que há informações nos pacotes sobre os CPFs de quem coletou os dados em papel e de quem inseriu os mesmos no sistema do recinto.

Os seguintes campos devem ser corretamente preenchidos, conforme a documentação técnica, nessa situação:

- Data e Hora da ocorrência do evento

Desc: Data e hora em que o evento ocorreu ou que se coletou, em formulário papel durante uma contingência, os dados do evento. Deve-se enviar, junto da data, o fuso horário no qual tal data e hora foi gerada.

- Data e Hora do registro do evento

Desc: Data e hora em que se efetuou o lançamento, no sistema informatizado, seja em operações normais, seja das informações coletadas durante uma contingência.  Deve-se enviar, junto da data, o fuso horário no qual tal data e hora foi gerada.

- CPF operador ocorrência

Desc: CPF da pessoa que coletou, em formulário papel durante uma contingência, os dados do evento.

- CPF operador registro sistema

Desc: CPF da pessoa que efetuou o lançamento, no sistema informatizado, seja em operações normais, seja das informações coletadas durante uma contingência.

- Contingência [S/N]

Desc: Indica que este evento ocorreu durante uma contingência. Via de regra deverá haver um evento (Ocorrências de indisponibilidade de equipamentos) para o equipamento envolvido. Transmitir como true sempre que ocorrer falha operacional no sistema do recinto que impeça o registro e/ou envio de informações em seu sistema.

Os eventos aplicam-se para cargas de cabotagem?

Resposta:

Toda carga dentro de área autorizada (REDEX) ou alfandegada está sujeita ao controle aduaneiro e, portanto, os eventos gerados por elas devem ser transmitidos na API.

Para um terminal especialista em exportação existe alguma tratativa especial para cargas que serão devolvidas para o exportador por qualquer razão?

Resposta:

Do ponto de vista da API, não. Os eventos mapeados devem ser transmitidos sempre que ocorrerem.

Operadores de cais público também deverão prestar informações no perfil "Operador Portuário"?

Resposta:

Sim.

Há prestadores de serviço que ingressam no recinto, por exemplo: coleta de lixo, retirada de sucatas, mecânicos e eletricistas. Devemos enviar eventos relacionados a esses acessos?

Resposta:

Todos os acessos de pessoas e/ou veículos ao recinto devem ser enviados.

/ext/credenciamento-veiculos
Todo veículo que ingressa no recinto deve estar credenciado.
Um dos campos desse evento é "Áreas permitidas de acesso" e neste campo devem ser identificadas as áreas que o veículo prestador de serviço pode acessar.
Por ser campo livre, é possível informar a finalidade desse acesso. Por exemplo: "área A2.5.1 - Coleta de lixo"

/ext/credenciamento-pessoas
Toda pessoa que ingressa no recinto deve estar credenciada.
Além do campo "Áreas permitidas de acesso", devem informar os campos "Materiais/ferramentas de trabalho" e "Motivação do credenciamento".
Por meio desses campos é possível deixar explícito tratar-se de prestador de serviço.

/ext/acesso-pessoas
Todo acesso de pessoa ao recinto deve ser enviado à API, exceto se ingressar conduzindo veículo(motorista).
Neste caso as informações do motorista constam do próprio evento de Acesso Veículo.

/ext/acesso-veiculos
Todo acesso de veículo ao recinto deve ser enviado à API, incluindo as informações do motorista, dentre outras pertinentes.

No json a ser enviado, como devemos informar campos quando não contiverem valores?

Resposta:

O interveniente deverá capturar e registrar em seu sistema e enviar ao Módulo Recintos, para cada operação que realizar, as informações da especificação,  excetuadas as informações inaplicáveis ao caso em concreto.

Atributos não obrigatórios quando inaplicáveis ao caso em concreto devem ser transmitidos nulos(null) ou omitidos no json.

Quais são as situações que demandam o envio de passivo?

Resposta (atualizada):

As situações abaixo demandam envio prévio do passivo no recinto considerando o momento de entrada em produção do Módulo Recintos:

Lista de Pessoas Cadastradas

Pessoas cadastradas para acesso à área alfandegada no sistema do recinto cujo credenciamento esteja vigente.

Enviar um evento de credenciamento de pessoas para cada pessoa cadastrada.

Lista de Veículos Cadastrados

Veículos cadastrados para acesso à área alfandegada cujo credenciamento esteja vigente.

Enviar um evento de credenciamento de veículos para cada veículo cadastrado.

Lista de Representantes Cadastrados

Pessoas que acessam o sistema do recinto em nome de cada cliente cuja representação e/ou habilitação esteja vigente. Diferente do cadastro de representação do Siscomex.

Enviar um evento de representantes para cada representante cadastrado.

Lista de Objetos Georreferenciados

As coordenadas de áreas e/ou equipamentos definidos.

Enviar um evento de georreferenciamento para cada área / equipamento cadastrado.

Situação do Pátio de Contêineres

Transmitir a situação atual do pátio de contêineres.

O recinto deve estabelecer um “marco temporal” e listar todas as unidades de carga que estão presentes no pátio naquele momento. Para cada uma delas, transmitir um evento de Acesso Veículos, se a unidade entrou pelo GATE ou Desembarque Navio, caso tenha chegado em navio. Em seguida, transmitir um evento de Posição Pátio Contêiner com os dados da localização da unidade no marco temporal escolhido. Por fim, um evento Atribuição / Troca Navio para cada contêiner que vai embarcar (exportação, transbordo, trânsito).

Situação das cargas armazenadas

Transmitir a situação atual dos armazéns de carga.

O recinto deve estabelecer um “marco temporal” e listar todas os lotes de carga que estão presentes no armazém naquele momento. Para cada um deles, transmitir um evento de Geração de Lotes e, em seguida, um evento de Armazenamento de Lote com os dados da localização do lote no marco temporal escolhido.

Situação do Pátio Veículos

Transmitir a situação atual do pátio de veículos.

O recinto deve estabelecer um “marco temporal” e listar todos os veículos que estão no pátio naquele momento. Para cada veículo deve transmitir um evento de Acesso Veículos referente ao ingresso do veículo no recinto.

Para cada situação, há um ou mais eventos que devem ser utilizados para transmitir o passivo.

Os dados dos pacotes passivos (enviados apenas na geração do estoque inicial) terão as mesmas estruturas e campos dos pacotes ativos (enviados a cada nova ocorrência)?

Resposta:

Sim, terão a mesma estrutura. Caso alguns atributos não tenham sido capturados na época não há o que transmitir nesses campos.

Quando devo enviar esse evento?

Resposta:

Um evento para cada pessoa credenciada para acessar o recinto (entrada/saída). Considerar acesso às áreas alfandegadas apenas. Transmitir logo que encerrar o ato de credenciamento.

Um evento para cada CPF credenciado.

Qual a relação entre os campos de “dtHrInicioValidade”, “dtHrFimValidade” e “credenciamentoAtivo”?

Resposta:

No credenciamento devem ser informados os campos “credenciamentoAtivo:true” e, quando existir, validade do credenciamento. 

Nos casos em que a validade do credenciamento seja informada, a RFB vai considerar credenciamento inativo quando do vencimento do prazo.

Para os casos que não exista validade de credenciamento, o evento deve ser retificado para “credenciamentoAtivo:false” quando for o caso. 

Por exemplo: no caso de funcionários não há validade de credenciamento logo no caso de demissão o evento de credenciamento deve ser retificado para “credenciamentoAtivo:false”.

O evento Credenciamento Pessoa deve ser enviado considerando as pessoas cadastradas com crachá "permanente" no sistema?

Resposta:

O evento "/ext/credenciamento-pessoas" deve ser enviado sempre que o recinto credenciar pessoas para acesso em áreas alfandegadas do recinto, conforme normas vigentes, inclusive conforme normas locais de unidades da RFB;

Neste evento há os campos “Lista materiais/ferramentas de trabalho”. Um visitante e/ou funcionário chega no Porto com uma maleta cheia de ferramenta, devemos listar todas as ferramentas? Caso sim, isso deverá ser descrito dentro do sistema ou devemos ter um formulário padrão da empresa, onde o visitante e/ou colaborador deverá listar todas as ferramentas e após isso devemos scannear, disponibilizar em um caminho público da empresa e enviado o caminho do arquivo via webservice?

Resposta:

Notar que o credenciamento é diferente do evento de efetiva passagem nas catracas.

O Credenciamento ocorre antes da efetiva passagem na catraca, é o momento em que a pessoa entrega documentos e é habilitada para entrada no recinto.

Neste momento deve ser inserida uma lista de materiais que a pessoa costuma utilizar ao entrar e que, a critério do protocolo de segurança local, pode / deve ser checada a cada acesso.

Se o recinto não adota este controle, esta lista pode ser vazia.

Se o recinto adota um controle simplificado ("bolsa de ferramentas", "caixa de ferramentas") no lugar de uma lista detalhada, pode (e deve) enviar desta forma (simplificada).

Observar que os eventos devem sempre refletir a situação "no mundo real".

É possível conceituar claramente a diferença entre credenciamento e acesso? Em muitas situações, esses dois eventos devem ocorrer em momentos muito próximos. Nessa situação, ainda assim, é obrigatório o envio dos dois eventos individualmente?

Resposta:

Sim, ambos os eventos devem ser enviados. São eventos distintos. O credenciamento, que é a coleta dos dados da pessoa que vai acessar o recinto, via de regra, ocorre apenas uma vez enquanto o acesso ocorre “N” vezes. 

Alguns recintos atuam com credenciamento com validade de, digamos, um ano. Neste caso, há um credenciamento, “N” acessos durante o ano e outro credenciamento no ano seguinte...

Não está claro no “Credenciamento-Pessoas”, para quais tipos de pessoas precisa ser enviado o CPF ou CNPJ do representado e nome do representado e qual a relação do evento “Representantes” ?

Resposta:

Preencher o campo "CPF/CNPJ do representado" do evento Credenciamento de Pessoas apenas quando existir relação de representação. Caso exista, pode ser informado no evento de credenciamento de pessoas e/ou no evento de Representantes para o caso de várias representações para a mesma pessoa credenciada.

Nos casos de credenciamentos de veículos ou de pessoas cadastradas em sistema comunitário de recintos, ou seja, sistemas ou cadastros compartilhados por vários terminais/recintos, podem enviar o evento de Credenciamento de Veículos ou Credenciamento de Pessoas apenas no recinto em que for efetuado o cadastramento inicial ou tais eventos devem ser replicados em todos os recintos em que o veículo ou pessoa ingressará?

Resposta:

Sempre que o compartilhamento de equipamentos e/ou sistemas for permitido pelas normas de alfandegamento então pode ser enviado apenas 1 evento no ato do credenciamento da pessoa ou veículo pelo recinto em que for efetuado o credenciamento. Importante incluir nas observações/motivação maiores detalhes.

Quando devo enviar esse evento?

Resposta:

Um evento para cada veículo credenciado para entrar / sair no recinto. Transmitir ao final do ato de credenciamento. Um evento deve ser transmitido para cada credenciamento de cavalo-trator, outro evento para cada semirreboque, outro para cada vagão…

Um evento para cada PLACA credenciada.

Qual a relação entre os campos de “dtHrInicioValidade”, “dtHrFimValidade” e “credenciamentoAtivo”?

Resposta:

No credenciamento devem ser informados os campos “credenciamentoAtivo:true” e, quando existir, validade do credenciamento. 

Casos em que a validade do credenciamento seja informada, a RFB vai considerar credenciamento inativo quando do vencimento do prazo.

Para os casos que não exista validade do credenciamento o evento deve ser retificado para “credenciamentoAtivo:false” quando for o caso.

Nos casos de credenciamentos de veículos ou de pessoas cadastradas em sistema comunitário de recintos, ou seja, sistemas ou cadastros compartilhados por vários terminais/recintos, podem enviar o evento de Credenciamento de Veículos ou Credenciamento de Pessoas apenas no recinto em que for efetuado o cadastramento inicial ou tais eventos devem ser replicados em todos os recintos em que o veículo ou pessoa ingressará?

Resposta:

Sempre que o compartilhamento de equipamentos e/ou sistemas for permitido pelas normas de alfandegamento então pode ser enviado apenas 1 evento no ato do credenciamento da pessoa ou veículo pelo recinto em que for efetuado o credenciamento. Importante incluir nas observações/motivação maiores detalhes.

Quando devo enviar esse evento?

Resposta:

Um evento para cada acesso (entrada ou saída) de pessoa no recinto. Transmitir imediatamente ao acesso (entrada ou saída).

Um evento para cada acesso de CPF.

A descrição do evento menciona "para cada agendamento ou acesso", isto se aplica a quais situações? Listam-se alguns exemplos: Caso exista um portal de agendamentos integrado ao software de Recinto Aduaneiro ou o software tenha a função de agendamento, assim que for registrado que uma pessoa irá ao recinto mesmo sem estar confirmado, seja para retirar uma mercadoria, ou seja ele um motorista, ou um acompanhante de motorista, deverá ser enviado evento Acesso Pessoa.

Resposta:

A documentação da API deve retificar a descrição do Evento "/ext/acesso-pessoas" para:

"Um evento para cada acesso ou agendamento (entrada ou saída) de pessoa ao recinto. Transmitir imediatamente ao acesso (entrada ou saída)" pois a especificação desse evento de pessoas não inclui agendamento.

Os questionamentos sobre agendamento apenas fazem sentido para o evento "/ext/acesso-veiculos" que pode ter os comportamentos agendamento/acesso.

Na informação "catraca" é necessário enviar alguma especificação de marca/modelo ou apenas a identificação no sistema da catraca correspondente ao acesso registrado? 

Resposta:

Usar o protocolo do Evento de Georreferenciamento relativo ao ponto de acesso utilizado.

Observar que grande parte dos eventos devem ser transmitidos com a indicação do protocolo de artefatos georreferenciados.

No evento de Georreferenciamento devem ser cadastradas as áreas e equipamentos do recinto, como por exemplo, câmeras, gates, catracas, balança, área alfandegada, etc.

No caso do evento de acesso de pessoas devem ser informados:

- Portão/catraca de acesso (georreferenciamento)

Desc: Portão ou catraca de acesso. Usar o protocolo do evento de georreferenciamento relativo ao ponto de acesso utilizado

- Lista de Identificação das Câmeras (georreferenciamento)

Desc: Lista de identificação das câmeras. Usar o protocolo do evento de georreferenciamento para indicar, nesta lista, todas as câmeras que cobrem a área de acesso

Para os campos portão/catraca de acesso e identificação da câmera neste evento há uma referência ao Georreferenciamento, teremos que ter uma tabela relacionando as catracas com as câmeras?

Resposta:

É necessário manter controle sobre quais câmeras "cobrem" cada ponto. 

Notar que há outros eventos que necessitam a indicação da lista de câmeras como passagem nos gates, eventos de lotes, pesagem, escaneamento, etc.

Para o acesso de pessoas deverá ser recolhida digital?

Resposta:

A API não prevê o envio dos dados biométricos. A obrigatoriedade no uso de biometria vem do alfandegamento e deve ser cumprida na forma determinada pelas unidades locais da RFB.

Quando devo enviar esse evento?

Resposta:

Um evento para cada agendamento ou acesso (entrada ou saída) de veículo ao recinto. Transmitir imediatamente ao agendamento ou ao acesso (entrada ou saída).

Um evento para cada agendamento / acesso PLACA/CHASSI/LOCOMOTIVA.

Outra dúvida, será exigido o envio das informações de entrada e saída de contêineres vazios?

Resposta:

Sim. Acessos de veículos, pesagens ou escaneamentos, dentre outros, de vazios devem ser informados.

Nosso sistema irá realizar o armazenamento de todos protocolos recebidos em eventos que gerenciamos. Em relação a eventos que referenciam protocolos de outros eventos, queremos confirmar a obrigatoriedade de envio deste protocolo.

Ex. Tenho sistema de controle de acesso X que faz cadastro e credenciamento do motorista. O credenciamento ocorre e ele armazena o protocolo recebido pelo Siscomex. Quando o veículo desse motorista entra com a carga no terminal, o sistema de gestão operacional Y vai enviar o evento de acesso. O sistema Y obrigatoriamente deve mandar o protocolo de credenciamento do motorista? Assim como o protocolo do agendamento?

Gostaríamos de confirmar se esses campos de protocolo são obrigatórios no evento agendamentos/acesso de veículos?

Obs. Talvez para um terminal que tenha um único sistema gerindo tudo, isso não seja importante, porém para terminais que utilizam sistemas diferentes essa informação é muito importante, pois interfaces entre esses sistemas precisarão ocorrer.

Respostas:

Considerar que existem 3 momentos:

01 – Credenciamento, quando o recinto recebe os dados / documentos do motorista (de qualquer pessoa…) e concede (ou não) o direito de acesso fornecendo crachá, coletando biometria, etc. Neste caso, o evento de credenciamento envia os dados básicos e documentos de cada pessoa.

02 – Agendamento, quando o recinto agenda uma data para o veículo (e o motorista…) entrarem no recinto.

03 – Acesso, quando o veículo, na data / hora agendada, efetivamente entra no recinto.

Nos caso 02,  indicar o protocolo do evento de credenciamento do motorista para que a RFB possa checar os documentos (se necessário).

No caso 03, indicar tanto o protocolo do credenciamento quanto o protocolo de agendamento.

No evento de acesso de veículos "/ext/acesso-veiculos" quando tratamos modal ferroviário temos que mandar um acesso único com o trem e a lista de vagões no momento do acesso.  

Tem vários terminais que registram a chegada dos vagões um a um, assim como sua pesagem, e não a chegada do trem de uma vez como um todo.

Podemos mandar um evento para cada placa de vagão quando ocorrer cada acesso? Repetindo as informações na lista do campo semi-reboques pois lá que enviamos dados como OCR, etc.

Respostas:

O recinto deve armazenar os dados durante a chegada dos vagões, enviando o evento Acesso de Veículos completo quando a composição estiver toda recebida. 

As pesagens devem ser enviadas conforme ocorrem, ou seja, por unidade de carga (vagão) pesada com a correspondente tara e demais informações.

No evento de acesso de veículos "/ext/acesso-veiculos" o campo "modal" hoje refere-se somente aos modais "rodoviário e ferroviário". Como será informado o caso de acesso de barcaças (fluviais)?

Exemplificando: Trata-se de barcaça ou conjunto de barcaças (comboio) que acessam o recinto. A barcaça, ou comboio, atraca no píer onde equipamentos como (swivertell ou grua) fazem o descarregamento da carga. As cargas são transportadas por esteiras até chegarem nas balanças de fluxo, onde são pesadas (bateladas). Após isto, a carga vai para o armazém ou pode ir para um navio. Não tem acesso de pessoas.

Respostas (atualizada):

O acesso de barcaças com cargas em recintos deve ser transmitido no endpoint "/ext/embarque-desembarque-navios" com as informações pertinentes, inclusive a pesagem.

O evento de pesagem (/ext/pesagem-veiculos-cargas) deve ser enviado quando a pesagem ocorrer em momento muito anterior ao embarque ou muito posterior ao desembarque do navio ou barcaça.

O evento "/ext/acesso-veiculos" será transmitido apenas para veículos rodoviários ou locomotivas/vagões do ferroviário.

O acesso de um veículo fazendo alguma travessia, pode ser transfronteiriça, por meio de barcaça e chegando ao recinto deve ser informado no evento "/ext/acesso-veiculos". Acrescentamos o modal “fluvial” na tabela de domínio correspondente para os casos de veículos que fazem travessia via barcaças para chegar ao recinto.

As informações referentes tanto a "listaDeclaracaoAduaneira" e "listaNfe" sempre devem ser preenchidas ou basta enviar uma delas?

Respostas:

Sempre que existirem as informações no momento do agendamento ou, principalmente, no acesso do veículo elas devem ser enviadas. Por exemplo, em uma exportação pode acontecer de existir a informação da NFe e ainda não ter Declaração Única de Exportação(DUE) no momento do acesso do veículo.

Que chassis devem ser incluídos na "listaChassis"?

Respostas:

Informar todos os chassis das mercadorias, inclusive o tipo “meios próprios” (Importação ou exportação de ônibus, cavalo-trator, semirreboque, veículos...), conforme determinação da unidade RFB local.

Caso não se tenha a informação do "imoNavio" da "listaConteiner", esta pode permanecer em branco?

Respostas:

O interveniente deverá capturar, registrar em seu sistema e enviar ao Módulo Recintos, para cada operação que realizar, as informações da especificação, excetuadas as informações inaplicáveis ao caso em concreto.

No mundo real os agendamentos são constantemente alterados (motorista, veículo, carga, navio, etc.). Isto está previsto?

Resposta:

Sim. Todos os eventos podem ser retificados quando necessário.

Quando houver troca de motorista dentro do terminal, haverá alguma crítica não permitindo o registro de saída do veículo com outro motorista?

Resposta:

A API do Módulo Recintos recebe dados e, portanto, não implica em qualquer  tipo de impedimento a que eventos ocorram no mundo real. Se a política do recinto (amparada em normas, inclusive da unidade local) permite esta troca, ela pode ocorrer. 

Na prática, temos dois acessos, um de entrada e outro de saída. O evento de entrada do veículo provavelmente vai espelhar os dados do agendamento para aqueles recintos que operam com agendamento prévio, mas não haverá esta crítica. O evento de saída não precisa de agendamento (salvo melhor juízo) e também não sofrerá crítica baseado nos dados do evento de entrada.

Quando devo enviar esse evento?

Resposta:

Um evento para cada pesagem efetuada em unidades de carga.

Usar este evento também nos casos em que a pesagem for efetuada em equipamentos de movimentação de Contêineres (RTG, etc) e, neste caso, não informar placas (veículos e semirreboques) e nem taras do conjunto transportador. 

Caso a pesagem aconteça via Portainer ou balança de fluxo na operação de embarque/desembarque navio, informar o peso aferido no evento Embarque/Desembarque Navio 04.15.

A pesagem dos volumes, nos casos de geração de lotes, deve ser informada no evento 04.09 – Geração Lotes

No caso de granel que ingressar ou sair do recinto via dutos, transmitir o presente evento com a soma das bateladas da balança de fluxo ao final da operação. 

Um evento para cada conjunto de PLACA/CONTÊINER/VOLUME pesado.

Transmitir após a pesagem.

Nas pesagens de CTRs de Exportação realizamos a pesagem do veículo carregado com o CTR na entrada e na saída pesamos o veículo vazio. Como devemos mandar esta pesagem no evento?

Resposta:

Usar o evento pesagem e usar um dos atributos de tara:

- Tara Cavalo-trator/truck/locomotiva

- Lista semirreboques/vagão

            - Tara

ou

- Tara (Peso do conjunto cavalo + carreta sem a unidade de carga)

Serão enviados: um evento com veículo + contêiner (pesagem carregado) e outro evento da pesagem do veículo vazio.

Em uma exportação, recebemos 1 cegonha com até 10 veículos, nesse caso o pesobrutobalanca corresponde ao total de 10 veículos e não do um veículo especificamente. Nesse caso o que devemos enviar?

Resposta:

Há 3 eventos que tratam de pesagem (Pesagem Veículo/Carga, Geração de Lotes,

Embarque/Desembarque Navio) a depender do tipo e momento da sua ocorrência.

Para os casos de pesagem em balança rodoviária, enviar o peso bruto total no evento de Pesagem de Veículo/Carga. 

Observar que serão prestadas as informações do evento que realmente ocorreu, conforme o modal e tipo de operação que o recinto já trabalha, essa é uma premissa do projeto.

Temos casos onde existe excesso laterais do qual a carga não consegue passar pela balança física, gerando assim entrada de carga como  IOP (impossibilidade de pesagem).

Nessas situações não será enviado o pesoBrutoBalanca, isso ocorrerá também no evento de geração de lotes. Principalmente com cargas soltas, veículos, hélices e afins.

Resposta:

Para o caso de excesso de peso ou de dimensões que acarretem impossibilidade física ou operacional para realizar a pesagem ou escaneamento, não serão enviados os eventos de Pesagem Veículo/Carga e/ou Inspeção Não Invasiva pois, de fato, não ocorreram.

Nessas situações, há um flag no evento “Controle de Agendamento / Acesso de Veículo” para informar que não será possível pesar ou escanear aquele veículo ou carga.

Para os casos de barcaças, onde se utiliza também de balanças de fluxo, como deverá ser feito o envio das pesagens? Por intervalos iguais a "dutos" ou no encerramento de cada barcaça (semelhante desembarque)? Pois a pesagem desse tipo de modal normalmente ocorrem via balanças de fluxo.

Resposta:

Informar um evento ao final do processo com a soma das bateladas da balança de fluxo.

No caso de dutos agora também será informado a pesagem ao final da operação.

Para o evento de pesagem de veículos de carga "/ext/pesagem-veiculos-cargas":

Um modal rodo ou ferro que acessa o terminal para realizar descarga ou carregamento faz 2 pesagens, sendo uma tara e outra peso bruto.

Nesse caso mandaremos 2 eventos. Para uma exportação, por exemplo, mandaremos o peso bruto na hora que entrou, e mandaremos a tara na hora que estiver saindo vazio. Mandaremos na entrada somente o campo pesoBrutoBalanca(pois só temos a tara no final)? E na saída mandaremos tara, taraconjunto e pesoBrutoBalanca com o mesmo valor?

Resposta:

As taras de veículo e semirreboque podem ser informadas em separado ou em conjunto e são excludentes, ou seja, caso o recinto opere com a tara do conjunto (cavalo / semirreboque), comum no modal aquaviário, informar esta e ignorar a tara em separado, conforme determinação unidade local.

As taras devem ser informadas em separado nos casos de recintos que possuem cadastro de taras, conforme determinação da unidade local. Esse tipo de cadastro é comum no modal rodoviário em que cargas de importação ou exportação ingressam no recinto e permanecem sob rodas até o desembaraço.

Para os casos em que a pesagem é feita no gate (ou balança interna), comum no modal aquaviário, usar a tara aferida na última pesagem do conjunto vazio. 

Caso o conjunto realize a primeira passagem no recinto “carregado / cheio”, retificar o evento assim que obter a tara do conjunto vazio.

Pesagens de veículos vazios, conforme determinação da unidade local, devem ser transmitidas com valores iguais para os atributos peso bruto da balança e tara individual ou tara do conjunto, conforme o caso.

Devo informar a pesagem da carga no evento Pesagem Veículo/Carga, Geração de Lotes ou no Embarque/Desembarque de Navio? Quando informar em cada um?

Resposta:

As pesagens de caminhões, contêineres ou cargas devem ser informadas de acordo com a ocorrência no mundo real e conforme normatização, inclusive determinações da unidade RFB local.

O evento de Pesagem de veículos/carga se destina a prestação de informação de pesagens de veículos que são pesados em balança rodoviária em recintos. Geralmente modais rodoviário e aquaviário.

Usar o evento Pesagem de veículos/carga também nos casos em que a pesagem for efetuada em equipamentos de movimentação de Contêineres (RTG, etc) e, neste caso, não informar placas (veículos e semirreboques) e/ou taras do conjunto transportador. 

Há casos em que a pesagem de contêineres ocorre via Portainer ou balança de fluxo (granel) na operação de embarque/desembarque do navio, nestes casos a pesagem será informada no próprio evento Embarque/Desembarque Navio.

Quando cargas são pesadas após desunitização, após descarga de veículo rodoviário, após o recebimento da companhia aérea, dentre outras situações, as pesagens serão informadas no evento de Geração de Lotes.

E nos casos de vagão que não são pesados.. caso dos líquidos onde o peso é aferido por arqueação. Como informar a pesagem?

Resposta:

Informar o peso aferido no campo de peso e observar que os campos de tara podem ser nulos.

Nos casos onde o recinto trabalha com operações casadas, ou seja, o veículo entrega uma exportação e já retira uma importação. Nessa situação não teremos o peso vazio do conjunto(cavalo+carreta), como proceder?

Resposta:

A pesagem do conjunto (cavalo+carreta) vazio e/ou carregado será enviada para a API do Módulo Recintos.

O que determina a pesagem do conjunto vazio são as normas, inclusive locais, e sempre que ocorra este tipo de pesagem deverá ser transmitida à API. 

Caso o recinto não seja obrigado a efetuar a pesagem do conjunto vazio, como por exemplo em operações casadas, não há o que se transmitir pois o evento não ocorreu no mundo real.

Devemos enviar o primeiro pacote da primeira pesagem dos contêiner como Inclusão e os demais pacotes de repesagem deste contêiner devem ser enviados como Retificação?

Resposta:

A retificação ou exclusão de eventos pressupõe o envio (Inclusão) do evento original. Inclusive, para o envio de eventos do tipo retificação/exclusão há validação em relação ao protocolo do evento original.

Casos de contingência devem ser tratados pela TI e reenviados com flag "contingencia:true".

Em relação aos exemplos abordados, observar que a retificação deve ser utilizada para informações erroneamente transmitidas.

No caso de pesagens do contêiner, caso ocorra repesagem por problemas técnicos ou operacionais notórios(por exemplo: veículo parcialmente fora da balança rodoviária) pode ser considerada uma retificação. Entretanto via de regra, toda pesagem e repesagem é considerada um evento independente sendo todas enviadas como Inclusão.

No nosso processo, o granel chega ao Recinto Alfandegado vindo da usina até o pátio por meio de correias transportadoras onde são pesadas por balança de fluxo. Visando a transmissão da API /ext/pesagem-veiculos-cargas e seus campos (pesoBrutoBalança, dutos e ncm), nesse caso, tendo em vista a similaridade entre os meios, podemos adotar para “Correia Transportadora” o procedimento de “Duto”?

Resposta:

O evento de pesagem pode ser transmitido de forma similar a dutos, ou seja, no caso de granel que ingressar ou sair do recinto via dutos (ou em situação similar via correia transportadora), transmitir o presente evento com a soma das bateladas da balança de fluxo ao final da operação com o adequado preenchimento dos campos pesoBrutoBalança, dutos, ncm e demais pertinentes. Preencher o atributo dutos até que atributo específico seja criado.

Quando devo enviar esse evento?

Resposta:

Um evento para cada inspeção não invasiva de unidades de carga.

Transmitir imediatamente após a finalização da inspeção.

Um evento para cada PLACA/CONTÊINER/VOLUME escaneados.

Quais arquivos devo enviar no evento de inspeção não invasiva?

Resposta:

Nesse evento devem ser enviados os arquivos de imagem do scanner, de assinatura da imagem e também um arquivo de metadados (geralmente xml) gerado pelo escâner.

Para enviar a imagem do scanner, devemos utilizar a API do Módulo Anexação? Como será o fluxo desses arquivos?

Resposta:

O evento deverá ser enviado diretamente para API do Módulo Recintos contendo os arquivos de imagem, de assinatura e de metadados (geralmente xml) gerado pelo escâner, além de outros campos definidos.

Qual a especificação do arquivo de imagem e do arquivo de assinatura?

Resposta:

O atributo arquivoAssinatura deve ser o conteúdo de um arquivo no formato p7s, codificado em base64.

Quando devo enviar esse evento?

Resposta:

Um evento para cada mudança de posição de veículo no pátio. Evento para os recintos rodoviários. 

Transmitir imediatamente a finalização do posicionamento.

Um evento para cada conjunto PLACA/CONTÊINER posicionada num box no pátio.

O evento de Posição veículos Pátio registra veículos que movimentam granel (recinto de granel) ou área de armazenagem de cargas do tipo veículos?

Respostas:

O evento de “Posição de Veículos no Pátio” deve ser principalmente utilizado para registro de informações de localização dos veículos (box ou posição no pátio) nos portos secos. Nesses casos, a carga de importação ou exportação, via de regra, entra no recinto sob rodas e permanece sob rodas até o desembaraço em uma posição no pátio.

O armazenamento de cargas deve ser registrado com os eventos Geração de Lotes e Armazenamento de Lote.

Quando devo enviar esse evento?

Resposta:

Um evento para cada mudança de posição da unidade de carga dentro do pátio. Não considerar os movimentos do tipo “house keeping”, quando a unidade retorna, em pouco tempo, para a mesma posição. Transmitir imediatamente a finalização do posicionamento.

Um evento para cada CONTÊINER posicionado no pátio.

Quando devo enviar esse evento?

Resposta:

Um evento para cada conjunto de LOTEs gerados por conhecimento.

Não considerar os movimentos do tipo “house keeping”, a exemplo de desunitização para verificação física de órgão anuente, casos em que a carga deve ser reunitizada em pouco tempo após o processo.

Exemplos de geração de lote; desunitização = n... lotes; baldeação imediata = n... lotes; depositada em armazém = n... lotes;

Baldeação, a transferência de mercadoria descarregada de um veículo e posteriormente carregada em outro. Nesse caso ocorre a geração lote e posterior carregamento lote.

Não aplicar para granel.

Transmitir imediatamente a geração de um conjunto de LOTEs por conhecimento.

Pode repetir o conhecimento na transmissão de um novo evento no caso de cargas com chegada parcial.

Em relação ao evento de geração de lote, nosso sistema gera um lote para identificar cada carga independente de estar num contêiner ou não. Por exemplo, um contêiner pode ter em seu interior 4 BL Houses. Neste caso, deve-se enviar 4 eventos de geração de lote para cada um dos lotes? Em porto seco de fronteira, quando a mercadoria entra e permanece sobre-rodas deve-se gerar o evento de geração de lote e armazenagem de lote?

Resposta:

A API-Recintos segue a lógica da ocorrência física de eventos no mundo real, ou seja, se o evento ocorreu então deve ser enviado aquele conjunto de dados pertinente.

Os eventos de lotes (geração de lotes, armazenamento de lotes e carregamento/entrega de lotes) somente devem ser enviados para a carga que passa a ser controlada por volumes, carga solta. Por exemplo, caso o contêiner seja desunitizado para armazenamento físico dos pallets então deve ser enviado o evento Geração de Lotes e Armazenamento de Lotes. Se o contêiner entrou no recinto e foi embarcado então, do ponto de vista da API, não deve ser enviado eventos de lotes. Nesse último caso, todos os eventos conforme o fluxo físico do contêiner devem ser enviados, por exemplo na exportação: evento Agendamento/Acesso de Veículos, Pesagem de Veículo/Carga, Inspeção Não Invasiva, Posição do Contêiner no Pátio, Embarque no Navio, dentre outros conforme o caso em concreto.

Observar que no caso de terminais do modal aéreo as cargas possuem um controle por volumes logo sempre serão transmitidos os eventos de lotes.

Nos casos de porto seco a mesma lógica deve ser seguida.

Via de regra, em porto seco de fronteira a carga permanece sob rodas e não sendo armazenada não haverá controle por volumes e consequentemente não ensejando envios de eventos de lotes para API-Recintos. Por outro lado, em portos secos de interior, via de regra ocorre o armazenamento e controle por volumes, nesses casos deverão ser enviados os eventos de lotes.

Geração de lote: existem cargas que são desovadas do CTR para saneamento ou conferência física, ficando às vezes por semanas fora do CTR e depois são reestufados no CTR de origem. Durante este tempo o CTR retorna para quadra ficando vazio neste período e depois é novamente posicionado para a estufagem da carga. Nestes casos, temos que informar a geração do lote ou somente se a carga for desovada em definitivo?

Resposta:

Não considerar os movimentos do tipo “house keeping”, quando a unidade retorna, em pouco tempo, para a mesma posição.

Se a desova for realizada unicamente para conferência física por interveniente e retornar ao contêiner (ova) em até 1 dia, os eventos de Geração de Lote e Posição do Contêiner não precisam ser informados.

Incluímos o atributo “vazio[sim/não]” no evento Posição Contêiner.

Na geração do lote gostaríamos de saber se ao recebermos uma carreta com carga para exportação precisamos fracionar, pesar e criar um numero de lote ou se podemos criar um lote único para carga e adotar o peso da balança rodoviária menos a tara do veículo como peso do produto? 

A forma de trabalho do recinto é que dita como será formado o lote. Presume-se que haverá ao menos um lote para cada carga de exportação, ou seja, para cada DUE. Entretanto há a hipótese de o recinto receber várias remessas (para formação de uma exportação) e decidir criar um lote para cada parte da carga recebida. Já o peso do produto pode (deve) ser feito na forma proposta.

No campo ListamercadoriaPerigosa, o campo Classe  deve ser enviado o código da classe de riscou ou a descrição? O campo Cod  é para ser enviado o código ou a descrição do ONU?

Resposta:

O campo mudou. Enviar apenas a lista de códigos de acordo com a tabela aduaneira Mercadoria Perigosa.

Caso ocorra um saneamento pela RFB e a carga após sanada retorne para o CTR de origem, temos que mandar este evento para o lote criado ou usaremos o evento posição de contêiner? Neste caso devemos informar a unitização do lote no contêiner alugado?

Cargas que foram desunitizadas e reunitizadas em contêineres alugados, devemos considerar como solta, enviando este evento ou considerar como contêiner e usaremos o evento posição de contêiner? – Esta situação ocorre muito em contêineres de cargas refrigeradas em abandono onde o Armador entra com mandato de segurança, exigindo o Contêiner vazio de volta

Resposta:

Quando ocorrer a desunitização deve haver a informação do evento Geração de Lotes, via de regra, seguido do evento Armazenamento de Lote.

Não considerar os movimentos do tipo “house keeping”, quando a unidade de carga retorna, em pouco tempo, para a mesma posição.

Se a desunitização for realizada unicamente para conferência física ou saneamento por interveniente público e a carga retornar ao mesmo contêiner (reunitização) e o contêiner retornar para a mesma posição em pouco tempo, até 1 dia, os eventos de Geração de Lote e Posição do Contêiner não precisam ser informados, porém, no caso contrário, precisam ser informados.

Incluímos o atributo “vazio[sim/não]” no evento Posição Contêiner.

No caso de desunitização e/ou conferência física por longo período e/ou  reunitização em contêiner diverso, os eventos Geração de Lotes, Armazenamento de Lote (se for o caso), Carregamento/Entrega de Lote e Posição do Contêiner devem ser informados.

Iremos enviar este endpoint sempre que houver o cadastro de uma desunitização da carga do contêiner de origem? Devemos enviar para algum outro processo, como saneamento de uma carga mesmo que ela retorne para o contêiner de origem após o saneamento?

Resposta:

Sim, quando ocorrer a desunitização deve haver a informação do evento Geração de Lotes, via de regra, seguido do evento Armazenamento de Lote.

Não considerar os movimentos do tipo “house keeping”, quando a unidade de carga retorna, em pouco tempo, para a mesma posição.

Se a desunitização for realizada unicamente para conferência física ou saneamento por interveniente público e a carga retornar ao mesmo contêiner (reunitização) e o contêiner retornar para a mesma posição em pouco tempo, até 1 dia, os eventos de Geração de Lote e Posição do Contêiner não precisam ser informados, porém, no caso contrário, precisam ser informados.

Incluímos o atributo “vazio[sim/não]” no evento Posição Contêiner.

No caso de desunitização e/ou conferência física por longo período e/ou  reunitização em contêiner diverso, os eventos Geração de Lotes, Armazenamento de Lote (se for o caso), Carregamento/Entrega de Lote e Posição do Contêiner devem ser informados.

Acredito que há a confusão do termo "lote" por conta do "lote de fabricação" da mercadoria. Sobre a questão da utilização do chassis para identificar o veículo(mercadoria) movimentado, seria interessante observar a forma adotada pela Antaq no SDP. Há uma definição de lote?

O lote é um termo usado para um número – código que identifique aquela carga de forma única, ainda que seja uma parcela do conhecimento de carga.

Deve ser suficiente para que o recinto saiba informar, de forma inequívoca, onde está aquela carga em particular. Não há um formato definido. 

Levar em conta, ainda, que todas as cargas dentro do recinto devem estar informadas na API. No caso de cargas desunitizadas usamos o conceito de lotes.

O conceito de lote está relacionado com a rastreabilidade e com o controle do que há no pátio ou armazém. Para cargas unitizadas temos o número da unidade de carga. Para carga desunitizadas devemos ter um número, que seja único dentro de cada recinto, para o mesmo fim.

Quando devo enviar esse evento?

Resposta:

Um evento para cada armazenamento/mudança de posição do lote dentro do armazém. Não considerar os movimentos do tipo “house keeping”, a exemplo do posicionamento para verificação física de órgão anuente, casos em que a carga  retorna, em pouco tempo, para a mesma posição.

Não aplicar para granel.

Transmitir imediatamente a finalização do armazenamento.

Um evento para cada LOTE armazenado.

Como devo proceder para informar o evento de armazenamento de lote após o posicionamento (não considerando House Keeping) de Lotes de Madeira. Como deverão seguir estas informações para o API – Recintos?

Exemplo: Pilhas de madeiras (Lotes) que ocupam espaço físico, com dimensões superiores a de um container (Altura, Largura, Profundidade).

Respostas:

O ideal é dividir em vários lotes, de acordo com a divisão do armazém. Por exemplo, se o lote ocupar toda uma quadra, informar um lote e, nos dados de localização, apenas a quadra. SE usar algumas pilhas de uma quadra, dividir em um lote por pilha e informar, no evento, a quadra e a pilha de cada lote. Notar que é ideal agrupar as mercadorias de um mesmo lote na mesma quadra / pilha. Facilita para montar os eventos e para eventual fiscalização.

Entendemos que este endpoint (armazenamento-lote) deve ser enviado apenas para cargas soltas ou cargas que foram desunitizadas e não retornarão mais para o contêiner de origem, correto?

Resposta:

O entendimento está correto. Nesses casos, haverá envio de eventos conforme a logística da carga sendo Geração de Lotes, Armazenamento do Lote e, em outro momento, Carregamento/Entrega de Lotes.

O evento Carregamento/Entrega de Lotes deve ser utilizado quando os lotes forem carregados ou unitizados em unidade de carga (caminhão, vagão, contêiner, ULD) ou entregue à companhia aérea. 

No caso de carga solta a ser carregada diretamente em navio, utilizar apenas o evento Embarque Navio informando o número do lote carregado.

Quando devo enviar esse evento?

Resposta:

Um evento para cada carregamento de lotes em unidade de carga – contêiner, caminhão, etc. Não considerar os movimentos do tipo “house keeping”, a exemplo do carregamento em caminhão para utilizar o scanner, casos em que a carga  retorna, em pouco tempo, para a mesma posição.

O evento deve ser utilizado quando os lotes forem carregados em unidade de carga(caminhão, vagão, contêiner, ULD aeronave) ou entregue à companhia aérea. 

No caso de carga solta a ser carregada diretamente em navio, utilizar apenas o evento Embarque Navio informando o número do lote carregado.

Transmitir imediatamente a finalização do carregamento.

Não aplicar para granel.

Um evento para cada conjunto de LOTES carregados do mesmo conhecimento.

Transmitir imediatamente ao carregamento de um conjunto de LOTEs por conhecimento.

Pode repetir o conhecimento na transmissão de um novo evento no caso de cargas com saída parcial.

Quando devo enviar esse evento?

Resposta:

Um evento para cada avaria ou extravio verificados em lote de carga.

Transmitir imediatamente a verificação da avaria/extravio.

Não aplicar para granel.

Um evento para cada LOTE com avaria/extravio.

Quando devo enviar esse evento?

Resposta:

Um evento para cada atribuição ou alteração de navio em que a unidade de carga ou carga solta irá embarcar. 

Transmitir imediatamente a atribuição ou alteração.

A atribuição (e muitas vezes também a troca de navio) ocorre antes mesmo do depósito do CTR no terminal, ou seja, teríamos o envio do evento Atribuição/Troca de Navio enviado antes do evento de entrada do CTR no terminal. Devemos enviar este JSON de Atribuição/Troca de Navio apenas após a entrada do CTR no terminal? Ou temos que enviar o JSON assim que o CTR for agendado (momento que teríamos a informação da atribuição da unidade ao Navio/viagem) ?

Resposta:

O navio de embarque deve ser informado tanto no “Agendamento de acesso de veículo” como no “Acesso de Veículo”.

Deve ser utilizado o evento “Atribuição/troca de Navio” nos casos em que:

 - a carga ingressou no recinto sem a informação do navio de embarque; ou

 - a carga ingressou informando navio de embarque, porém ocorreu alteração;

O recinto informa os dados, incluindo o navio, no momento do agendamento. SE houver mudança no navio antes de a carga entrar no recinto, não precisa enviar o evento de troca pois quando a carga efetivamente entrar(acesso de veículo) o dado correto será informado. A partir do momento em que a carga esteja no pátio, toda mudança deve ser informada.

O envio do evento atribuição e troca de navio será obrigatório para REDEX? Se sim, em qual momento devemos transmitir o mesmo? 

Resposta:

Sim. O navio de embarque deve ser informado tanto no “Agendamento de acesso de veículo” como no “Acesso de Veículo”.

Deve ser utilizado o evento “Atribuição/troca de Navio” nos casos em que:

 - a carga ingressou no recinto sem a informação do navio de embarque; ou

 - a carga ingressou informando navio de embarque, porém ocorreu alteração;

E quando tem rolagem de carga, muitas vezes não sabemos qual será o novo navio. O que fazer se o navio vai embora e o contêiner que estava amarrado a ele não tem o novo navio ainda?

Resposta:

Gerar o evento Atribuição/Troca de Navio deixando os dados do navio em branco até o momento em que se saiba o novo navio. Ao receber a informação do navio de embarque daquele contêiner, enviar evento retificador.

Quando devo enviar esse evento?

Resposta:

Um evento para cada embarque ou desembarque de unidades de carga no navio.

Transmitir imediatamente ao encerramento do embarque / desembarque de cada navio. Deve transmitir um evento para cada unidade de carga mas pode iniciar as transmissões quando encerrar o trabalho do navio.

Transmitir também nos casos de transbordo/baldeação entre navios.

Um evento por CONTÊINER/BULK embarcado ou desembarcado

Granel: um evento ao final do carregamento/descarregamento total do navio graneleiro.

No embarque de veículos, carga solta não possuímos a posição do navio para a carga , essa informação não será enviada?

Resposta:

Nesse caso não envia. O interveniente deverá capturar, registrar em seu sistema e enviar ao Módulo Recintos, para cada operação que realizar, as informações da especificação, excetuadas as informações inaplicáveis ao caso em concreto.

Campo portainer. Temos outros tipos de equipamentos para realização de embarque devido a características das carga, até o uso do equipamento do próprio navio. O campo portainer poderá ser enviado somente se ele for utilizado?

Resposta:

No caso de uso de equipamento do navio ou elemento móvel, não informar. Os elementos fixos (esteira ou portainer, por exemplo) vão estar na lista do evento de georreferenciamento e, portanto, serão informadas neste evento.

Alteramos o nome do atributo de: “Portainer” para: “equipamento de embarque ou desembarque”, por exemplo, o portainer ou outro cadastrado no evento Georreferenciamento.

Para o evento de embarque de navio, poderá ser enviado o peso aferido na arqueação ou somente o peso das balanças de fluxo para cargas a granel?

Resposta:

A documentação bem como a API está sendo atualizada e o evento Embarque/Desembarque Navio pode(deve) receber as seguintes informações:

- Peso bruto manifesto / VGM (Kg)

- Peso balança (Kg)

- Peso arqueação (Kg) (apenas para granel)

- Volume (metros cúbicos) (apenas para granel)

Quando devo enviar esse evento?

Resposta:

Lista de pessoas que acessam o sistema do recinto em nome de cada cliente ou que possuem representação via procuração. Diferente do cadastro de representação do siscomex. Toda representação via sistema ou papel deve ser informada.

Transmitir um evento para cada CPF/CNPJ.

Se no ato do credenciamento de uma pessoa o recinto conceder login/senha para acesso ao portal de internet devemos enviar os eventos “Credenciamento de Acesso de Pessoas” e “Representantes”?

Resposta:

Sim. O credenciamento de pessoas visando acessar fisicamente áreas alfandegadas do recinto deve ser informado no evento “Credenciamento de Acesso de Pessoas” já o credenciamento ou liberação de acesso à sistema como, por exemplo, um portal de recinto aduaneiro, deve ser informado no evento “Representantes”.

Não está claro no “Credenciamento-Pessoas”, para quais tipos de pessoas precisa ser enviado o CPF ou CNPJ do representado e nome do representado e qual a relação do evento “Representantes” ?

Resposta:

Preencher o campo "CPF/CNPJ do representado" do evento Credenciamento de Pessoas apenas quando existir relação de representação. Caso exista, pode ser informado no evento de credenciamento de pessoas e/ou no evento de Representantes para o caso de várias representações para a mesma pessoa credenciada.

Quais pessoas que acessam o sistema do recinto devem ser listadas?

Resposta:

Nos casos de acessos ao sistema do recinto, via portal web na internet ou acesso na intranet, todas as pessoas (usuários externos ao recinto, não os funcionários) que acessem informações de controle aduaneiro em nome de um representado devem ser enviadas neste evento para API-Recintos.

Quando devo enviar esse evento?

Resposta:

Um evento para cada agendamento ou conclusão de conferência física. Considerar todos os tipos de conferência, solicitadas por qualquer interveniente ou pelo proprietário da carga.

Transmitir um evento para cada agendamento ou conclusão de conferência recebida.

No caso de uma conferência com motivação ANVISA, devemos preencher o campo "solicitante" com o nome do Importador/ Despachante (que solicitou o posicionamento da unidade para conferência do órgão anuente ANVISA) ou o solicitante a ser informado seria o próprio órgão anuente "ANVISA"?

Resposta:

Conforme a documentação disponível, o atributo solicitante é uma tabela de domínio que será ajustada na medida em que existam necessidades.

Deve ser preenchida ordinariamente com RFB ou o órgão anuente que solicitou a verificação física.

O solicitante será juridicamente o importador quando ele fizer uso da verificação prévia ao registro da DI de que trata o Art. 10 da IN SRF n° 680/2006.

Quando devo enviar esse evento?

Resposta:

Um evento para cada lista de unidades que serão removidas. Verificar a normatização local sobre os prazos para que os recintos de destino informem o recinto onde a carga vai atracar sobre a remoção da mesma.

Transmitir imediatamente a recepção da lista de cargas a remover.

Um evento por LISTA CARGAS.

Este evento é apenas para contêineres de Importação? Quem deve informar este evento? O recinto de origem da carga (por exemplo, o operador portuário que fará a descarga das unidades do Navio) ou o recinto de destino da carga (terminal que receberá os contêineres listados para despacho em seu recinto)?

Resposta:

Neste evento devem ser informados os contêineres de importação que possuem informação prévia de trânsito simplificado.

As unidades locais da RFB já possuem normas disciplinando o tema.

Via de regra, o recinto de origem da carga (operador portuário que fez a descarga das unidades do Navio) é comunicado da previsão de trânsito simplificado de contêineres.

Tal comunicação é enviada previamente pelo recinto de destino da carga (recinto que receberá os contêineres para despacho) ao recinto de origem da carga.

O recinto de origem da carga deve enviar o evento para API-Recintos após a recepção da lista de contêineres com previsão de trânsito simplificado.

Quando devo enviar esse evento?

Resposta (atualizada):

Um evento para cada inclusão / alteração no 'line up' / 'agenda' de navios / aeronaves com atracação / pouso previstos para o recinto.

Transmitir a agenda (previsão), a chegada (atracação/desatracação pouso/decolagem) e a operação.

Evento aplicável para recintos com atracadouro ou pista aeronáutica próprios.

Exemplo de eventos para Navios:

Chegada (informa a viagem e escala de chegada, dados da embarcação, dentre outros)

evento 1 - previsão de atracação e desatracação;
evento 2 - previsão de atracação e desatracação + efetiva atracação
evento 3 - previsão de atracação e desatracação + efetiva atracação + início operação

Saída (informa a viagem e escala de partida, dados da embarcação, dentre outros)

evento 4 - previsão de atracação e desatracação + efetiva atracação + início operação + final operação
evento 5 - previsão de atracação e desatracação + efetiva atracação + início operação + final operação + efetiva desatracação

Exemplo de eventos para Aeronaves:

Chegada (informa o VOO e viagem de chegada, dados da aeronave, dentre outros)

evento 1 - previsão de pouso;
evento 2 - previsão de pouso + efetivo pouso
evento 3 - previsão de pouso  + efetivo pouso + início operação

Saída (informa o VOO e viagem de partida, dados da aeronave, dentre outros)

evento 4 - previsão de pouso + efetivo pouso + início operação + previsão de partida;
evento 5 - previsão de pouso + efetivo pouso + início operação + previsão de partida + final operação
evento 6 - previsão de pouso + efetivo pouso + início operação + previsão de partida + final operação + efetiva partida

Transmitir imediatamente a recepção da informação.

Quando devo enviar esse evento?

Resposta:

Um evento para cada bloqueio/desbloqueio de carga solicitado/efetuado diretamente no sistema do recinto. 

Não se trata do bloqueio no sistema Carga e/ou CCT.

Transmitir um evento para cada solicitação de bloqueio ou desbloqueio efetivada no sistema privado do recinto para conhecimento, contêiner, veículo ou lote.

Quando devo enviar esse evento?

Resposta:

Transmitir um evento para cada indisponibilidade e retorno à normalidade de cada equipamento definido no Evento de Georreferenciamento.

Tenho um equipamento (catraca ou câmera) que vai para manutenção técnica. Desativo ela no sistema. Devo enviar um evento de indisponibilidade com os dados requisitados para o endpoint "/ext/indisponibilidade-equipamentos" ou "/ext/indisponibilidade-equipamentos"? Quando devo utilizar um ou outro tipo de evento?

Resposta:

O evento /ext/evento-georreferenciamento será utilizado para cadastro georreferenciado das áreas e equipamentos do recinto.
Posteriormente, podem ocorrer indisponibilidades temporárias ou permanentes dos equipamentos.

Para indisponibilidades temporárias basta enviar um novo evento /ext/indisponibilidade-equipamentos referenciando o equipamento (protocolo). Um evento informando a indisponibilidade temporária (Inativo) do equipamento (balança, câmera, catraca, scanner...), incluindo a informação de previsão de retorno à normalidade, e outro evento informando a disponibilidade (Ativo) quando do efetivo retorno à normalidade.

Para indisponibilidades permanentes de equipamentos (desalfandegamento da área, desligamento definitivo da câmera, gate, catraca...) a informação de indisponibilidade (Inativo) é enviada como uma retificação do evento /ext/evento-georreferenciamento no atributo areaEquipamentoAtivo, além dos demais atributos.

Quando devo enviar esse evento?

Resposta:

Neste evento deve ser georreferenciado as áreas e equipamentos do recinto conforme lista do atributo “Tipo”.

As coordenadas de cada objeto definido podem ser um polígono ou ponto, por exemplo:

• O perímetro da área alfandegada e demais áreas... (polígono)
• As câmeras do sistema de CFTV, inclusive dos Gates e que fazem parte do sistema de OCR (ponto);
• As catracas, torniquetes e outros instrumentos de controle de acesso de pessoas (ponto);
• As balanças rodoviárias (ponto);
• Os Portêineres e outros instrumentos de manipulação de unidades de carga em navios (ponto);
• Os escâneres, tanto de contêineres quanto de volumes(ponto);
• Os gates, portões e outros instrumentos de controle de acesso de veículos (ponto).

Georreferenciamento: como deve ser o cadastramento do código de georreferenciamento para as posições de quadra, da área de posicionamento e dentro do Armazém? Cada posição deve ter um código?

Nas quadras normais, para cada posição temos a descrição de cada posição com Quadra, Bloco, quadra, Bay, Row e altura (Exemplo AC 11 D 2 ) são milhares de posições no terminal.

Resposta:

Os códigos de georreferenciamento e localização podem ser informados de acordo com as áreas ou padrões existentes em cada recinto.

Cada item pré-determinado deve ser “georreferenciado”. 

A princípio marcamos os gates, as balanças, os escaneres, as câmeras (todas), as catracas / torniquetes, portões, o perímetro total do recinto e, caso interesse, alguma área interna.

Para cada item desses é preciso enviar um ID, uma forma de identificar unicamente aquele item, um nome (novamente único), indicação se está ativo, azimute (câmeras) e o tipo.

Exemplo:

- Câmera perimetral 01

ID – CP01

Nome – Câmera perimetral 01

Ativo – S

Azimute – 35

Tipo – Câmera

Coordenadas - 26°53'41.4"S 48°39'36.9"W

Para o perímetro do recinto, as coordenadas serão na forma de lista.

Se o recinto informar algum polígono (área) dentro do polígono alfandegado (um armazém, área de conferência, dta, etc) deve usar a sua nomenclatura interna no campo ID e um “nome” no campo Nome. NÃO É RECOMENDADO enviar georreferenciamento das milhares de posições individuais (de unidades de carga). No máximo as quadras. O mesmo para as posições paletizadas dentro do armazém, enviar no máximo o georreferenciamento da área do armazém (polígono).

Devemos enviar o georreferenciamento diariamente? Quando uma câmera e/ou equipamento ficar off-line, por qualquer razão, devemos enviar essa informação?

Resposta:

No evento de Georreferenciamento deve ser registrado a "criação / instalação" de algum equipamento da lista "atributo tipo" e, ainda, áreas do recinto.

A própria API oferece uma tabela de domínio com a lista de equipamentos e áreas que devem ser "georreferenciados".

Desta forma, presumimos que o recinto vai enviar uma série de eventos deste tipo para todos os equipamentos e áreas (da lista) que possuir.

Novos eventos deste tipo serão enviados somente quando novos equipamentos forem instalados ou desativados ou, ainda, caso ocorram alterações nas áreas que foram cadastradas, ou seja, não será enviado diariamente.

Equipamentos que fiquem "off line", ou outros problemas de funcionamento, serão informados no evento de Indisponibilidade de Equipamentos.

Quando devo enviar esse evento?

Resposta:

Neste evento o recinto deve informar as cargas que recebe da companhia aérea(transportadora) quando do ingresso em seu recinto.

Transmitir quando existir ULD (Unit Load Device - Aéreo)

Quais eventos do Módulo Recintos serão integrados com CCT-Importação? 

Resposta:

No momento (agosto/2020) está sendo construído o CCT-Importação/aéreo, fase 1, e haverá integração do evento “/ext/geracao-lotes”.