sexta-feira, 20 de fevereiro de 2015

Corrigindo erro 578 - Rejeição: A data do evento não pode ser maior que a data do processamento (Cancelamento)

578 - Rejeição: A data do evento não pode ser maior que a data do processamento.

O xml do Evento de Cancelamento tem a tag dhEvento que deve ser informada com a data e hora do cancelamento.

O Web Service compara o dhEvento com o horário do servidor e caso seja ela seja maior vai ocorrer o erro:

"578 - Rejeição: A data do evento não pode ser maior que a data do processamento"

A causa do erro pode ser:
1) o horário do equipamento adiantado em relação ao horário do servidor - neste caso basta sincronizar o horário do equipamento;

No pedido de Cancelamento:
<dhEvento>2011-09-23T10:17:29-03:00</dhEvento> <=== hora informada no pedido de cancelamento

Na resposta do WS:
<dhRegEvento>2011-09-23T10:14:29-03:00</dhRegEvento> <==== hora do servidor da SEFAZ <====

2) o horário do equipamento está correto, mas o fuso horário está incorreto - neste caso podemos corrigir o fuso horário ou corrigir o horário.
No pedido de Cancelamento:
<dhEvento>2011-09-23T10:14:29-04:00</dhEvento> <=== hora informada no pedido de cancelamento

Na resposta do WS:
<dhRegEvento>2011-09-23T10:14:29-03:00</dhRegEvento> <==== hora do servidor da SEFAZ <====

corrigindo o fuso horário:
<dhEvento>2011-09-23T10:14:29-03:00</dhEvento>, alteramos o fuso horário para UTC-03:00 no Windows

corrigindo o horário:
<dhEvento>2011-09-23T09:14:29-04:00</dhEvento>, corrigimos a hora para 09:14:29-04:00 que é a hora local equivalente 10:14:29-03:00 no fuso UTC-04:00 (Cuiabá), são 9 horas em Cuiabá (UTC-04:00) quando forem 10 horas em Brasília (UTC-03:00)

Tente verificar qual é a data e hora que está sendo informada na mensagem da cancelmeno enviada para o WS (veja o conteúdo de msgDados) e compare com a data e hora do servidor da SEFAZ que existe na resposta do WS.

<?xml version="1.0" encoding="UTF-8"?>
<retEnvEvento versao="1.00" xmlns="http://www.portalfiscal.inf.br/nfe">
<idLote>11111111111101</idLote>
<tpAmb>2</tpAmb>
<verAplic>SP_EVENTOS_PL_100</verAplic>
<cOrgao>35</cOrgao>
<cStat>128</cStat>
<xMotivo>Lote de Evento Processado</xMotivo>
<retEvento versao="1.00">
<infEvento>
<tpAmb>2</tpAmb>
<verAplic>SP_EVENTOS_PL_100</verAplic>
<cOrgao>35</cOrgao>
<cStat>213</cStat>
<xMotivo>CNPJ-Base do Autor da mensagem difere do CNPJ-Base do Certificado Digital</xMotivo>
<chNFe>35111111111111111111111111111111111111111111</chNFe>
<dhRegEvento>2011-09-23T10:14:29-03:00</dhRegEvento> <==== hora do servidor da SEFAZ <====
</infEvento>
</retEvento>
</retEnvEvento>

Outra opção seria o utilizar o CancelaNFEvento que permite informar a data e hora que o Sr. achar mais conveniente.

Fonte : FlexDocs e Unimake

quinta-feira, 19 de fevereiro de 2015

Corrigindo Erro Requisição 12031 e 12057 - envio de eventos CTe e NFe

Erro de Requisição 12031
Erro de Requisição 12057

Após algumas pesquisas e dor de cabeça com diversos certificados digitais que estão sendo instalados nas estações de trabalhos para envio de CT-e e NF-e , resolvi registrar a melhor forma que encontrei para que os mesmos funcionem corretamente para envio de eventos dos documentos fiscais.

Notei que os erros acontecem devido a uma configuração do I.E. , que quando modificada , aparentemente resolve os problemas de Erro de Requisição.

Os Erros que corrigi com essa mudança foram :

1) CT-e ou NF-e , envio de eventos para cancelamento ou carta de correção
Erro : Requisição não enviada
números : 12031 e 12057
Conexão com servidor foi reconfigurada

2) MDF-e, envio de eventos para encerramento e cancelamento
Erro : Requisição não enviada
número: 12057
Erro para envio de requisição.

Para corrigir (pelo menos em meu caso deu certo) :
a) entre no I.E. > Ferramentas > Opções de Internet > Avançado
b) Grupo Segurança. desmarque todos TLS , ficando dessa maneira.



Vale salientar também que :
- todos os certificados registrei sem  Ativar proteção de chaves, para que não seja pedido 'Conceder Permissão' no momento do envio.
- Marcado apenas opção para backup do certificado.

Dessa forma 



Espero que ajude.












quinta-feira, 20 de dezembro de 2012

Entendendo de forma Simples SCAN, DPEC e FS da NFe


Entendendo de forma Simples SCAN, DPEC e FS da NFe


Modalidades de Contingência como funcionam ?

Os desenvolvedores de sistemas emissores de NF-e devem ficar atentos a essa regra, pois os sistemas precisam saber como se comportar em cada situação.

SCAN – Sistema de Contingência do Ambiente Nacional

O SCAN possui a mesma estrutura de recepção da SEFAZ Origem, executando as seguintes operações:
  • Recepção e autorização de NF-e
  • Cancelamento de NF-e
  • Inutilização de numeração de NF-e
  • Consulta ao status de uma NF-e
  • Consulta status operacional do seu serviço (webservice exclusivo do SCAN)
  • Consulta status operacional do serviço da Sefaz Origem (webservice exclusivo do SCAN)
Para que não ocorra a situação de uma mesma NF-e ser autorizada pelo SCAN e também pela SEFAZ Origem, o SCAN tratará somente Notas com numerações nas séries 900 a 999. Isso se aplica a todos os serviços elencados acima. Do mesmo modo, a SEFAZ Origem não tratará nenhuma Nota que possuir séries reservadas do SCAN.
O software emissor de NF-e deve estar preparado para operar tanto com a SEFAZ Origem quanto com o SCAN. Segundo o Manual de Contingência da NF-e, o sistema de mensageria de NF-e deve se comportar da seguinte forma:
  • Passar a gerar NF-e com numeração nas séries de contingência (900 a 999);
  • Alterar as chamadas dos webservices para invocar os webservices do SCAN;
  • Transmitir o aqruivo da NF-e e imprimir DANFE normalmente, conforme as autorizações emitidas pelo SCAN.
  • Monitorar a disponibilidade da SEFAZ Origem (através do webservice NfeStatusServico do SCAN), para determinar o momento de voltar a operar com a SEAFAZ Origem.
A SEFAZ Origem e o SCAN trabalham em sincronia. A SEFAZ Origem avisa o SCAN quando é o momento em que ele deve ativar/desaticar os seus serviços. A Notas Fiscais eletrônicas autorizadas pelo SCAN serão transmitidas também para o ambiente da SEFAZ Origem, permitindo que a consulta possa ser efetuadas nos dois ambientes.

DPEC – Declaração Prévia de Emissão em Contingência

O DPEC também é um ambiente que recebe solicitações das empresas contribuintes através da comunicação de webservices. Entretanto, o DPEC não autoriza a Nota eletrônica, ele apenas autoriza uma declaração de que aquela NF-e será transmitida posteriormente para a SEFAZ Origem, mas que no momento o DANFE será impresso em contingência (formulário comum A4).
Diferentemente do SCAN, o DPEC não se comunica com a SEFAZ Origem. Nesta forma de emissão em contingência, quando a conexão com a SEFAZ Origem for estabelecida novamente, a empresa contribuinte precisará encaminhar para ela todos os arquivos emitidos em contingência pelo DPEC.
Imagine a seguinte situção: a empresa perdeu a conexão com SEFAZ Origem e também não conseguiu conectar com o SCAN. O que ela faz? Ela bate na porta do DPEC e fala:
- DPEC, preciso emitir uma NF-e em contingência, você pode autorizar?
E o DPEC responde: – Claro, mas preciso de algumas informações. Me passe a chave de acesso, número da nota, série, informações da sua empresa e da empresa do destinatário.
- Ok, seguem as informações. Estou autorizado a imprimir o DANFE em uma folha A4 comum?
- Sem problemas, pode emitir. Mas depois, envie o arquivo completo da NF-e para a SEFAZ Origem.
Fiz essa apresentação “lúdica” para exemplificar de forma mais simples como funciona o processo. Em resumo, a NF-e não foi autorizada pelo DPEC, ele apenas tomou conhecimento de que naquele momento não havia conexão com a SEFAZ Origem, que o contribuinte imprimiu o DANFE e que encaminhará o arquivo posteriormente.
Assim como no SCAN, o software emissor de NF-e precisa ficar checando o momento em que a SEFAZ Origem voltar a ter conexão. Quando isso ocorrer ele, precisa enviar para ela (SEFAZ) todos as Notas eletrônicas que tiveram a autorização de emissão feita pelo DPEC.

FS – Formulário de Segurança

Na emissão do DANFE em Formulário de Segurança o processo muda um pouco. Nessa modalidade, o contribuinte precisa imprimir o DANFE em um formulário especial e em duas vias: uma para acompanhar a mercadoria e outra para ser arquivada na empresa (para posterior apresentação ao fisco). O formulário de segurança trata-se de uma folha especial, feita em Papel Moeda. Ao imprimir deve ser adicionada uma “marca d’água” com a identificação de que o DANFE está sendo impresso em contingência devido a problemas técnicos.
Assim como no DPEC, o arquivo da NF-e não é enviado diretamente para a SEFAZ Origem (pois não está sendo possível a conexão). Então, o sistema emissor de NF-e deve identificar quais NF-e foram emitidas em Contingência e transmitir essas NF-e para a SEFAZ Origem logo que a conexão for estabelecida novamente.

Implementando o Modo de Contingência

Para auxiliar o contribuinte a tomar a decisão de passar a operar em modo de contingência, o sistema de emissão de NF-e pode possuir algumas parametrizações e/ou verificações que definam as circunstâncias em que a emissão passará a ser em contingência. Podem existir inúmeras formas de efetuar esse tratamento, vou descrever algumas formas simples, porém eficázes, de possíveis implementações do sistema emissor de NF-e.

Emissão em contingência através do ambiente do SCAN

De tempos em tempos, o sistema pode consultar o status do serviço da SEFAZ-Origem. Caso identifique que a SEFAZ Origem não esteja disponível, o sistema emissor de NF-e já pode alterar automaticamente a forma de geração das NF-e, passando a gerá-las de acordo com as regras do Ambiente do SCAN.
O sistema pode fazer o mesmo quando a SEFAZ Origem voltar a ficar disponível, retornando a geração de NF-e para a forma normal.
Ao invés de proceder de forma automática, o sistema também pode informar ao usuário da situação e solicitar a confirmação da operação.

Emissão em contingência através do ambiente do DPEC

Assim como no SCAN, de tempos em tempos, o sistema pode consultar o status do serviço da SEFAZ Origem e verificar a sua disponibilidade. Se a SEFAZ Origem não esteja disponível, o sistema emissor de NF-e já pode alterar automaticamente a sua operação, passando a solicitar ao DPEC a autorização para emissão em contingência e identificar quais foram as Notas emitidas em contingência.
Quando a SEFAZ Origem voltar a ficar disponível, retornando a geração de NF-e para a forma normal, deverá transferir todos as Notas eletrônicas setadas como enviadas ao DPEC.
É desejável que esse vai e vem possa ser determinado pelo usuário como automático ou manual (fazendo assim que o usuário confirme a operação).

Emissão em contingência utilizando Formulário de Segurança

Poderia funcionar semelhante ao SCAN. Entretanto, ao invés de solicitar a autorização, poderia setar as Notas emitidas em contingência e também disparar a impressão para o Formulário de Segurança, setando a marca d’água necessária.
Quando a conexão com a SEFAZ Origem for estabelecida novamente, todas as Notas marcadas anteriormente deverão ser eviadas para a SEFAZ para autorização.
Também é desejável que esse processo seja disponibilizado ao usuário de forma onde ele possa optar por fazer manualmente ou deixar que o sistema faça as escolhas automaticamente.

Maicon Klug

Marcel Henrique Scandolara

quarta-feira, 24 de outubro de 2012

Dica Formula Visual da Totvs a partir da 11.50

PessoALL,

Depois de quebrar a cabeça e com alguns atendimentos com o suporte da Totvs, verifiquei que tem um esquema para que as formulas visuais disponíveis para ser usada a partir da versão 11.50 passem a  funcionarem.

Apos criação da Formula, tanto em 3 camadas como local, temos que adicionar uma tag para habilitar , segue os caminhos :

- /totvs/CorporeRM/RM.NET/
arquivo RM.Host.exe.config  , adicione a tag
<add key="WorkflowEnabled" value="true" />
abaixo da linha <add key="EnableCompression" value="true" />

arquivo RM.Host.Service.exe.config, adicione a mesma tag
<add key="WorkflowEnabled" value="true" />
abaixo da linha <add key="EnableCompression" value="true" />

- /totvs/CorporeRM/RMNucleos/
arquivo RMNucleus.exe.config, adicione a mesma tag
<add key="WorkflowEnabled" value="true" />
abaixo da linha <add key="EnableCompression" value="true" />

Pronto , agora reinicie o RM.Host que esta dentro da pasta RM.NET ou direto no Gerenciador do Windows , reiniciando o servico RM.Host.Service



               
Feito isso ja podemos startar os gatilhos das formulas e a mesma passará a funcionar conforme nossa necessidade.

É isso ai pessoALL, até a proxima.


quinta-feira, 19 de julho de 2012

Preparando Certificado Digital A1 para registrar

Produto: NF-e 
Processo: Certificado Digital Unidades Certificadoras
Subprocesso: Preparar o Certificado com as unidades certificadoras para Envio da NF-e
Introdução
Para emissão da NF-e/NFS-e utilizando o sistema “SSADM Gestão de Administrativa e Estoque” é necessário preparar o Certificado Digital com as unidades certificadoras para que o TSS assine e transmita os lotes contendo as NF-e/NFS-e.
IMPORTANTE: O sistema  só transmite NF-e/NFS-e com CERTIFICADO DIGITAL MODELO A1, em arquivo com extensão pfx ou p12, de qualquer fabricante.

O certificado Digital deve ser importado em uma maquina que esteja com o sistema operacional Windows XP. Abra o navegador de internet e acesse o menu | Ferramentas | Opções da Internet.

Exemplo: Internet Explorer 8.
clip_image002[4]




Na janela que abrirá clique em “Certificados” na aba “Conteúdo”. Ira abrir outra janela nesta janela clique em “Importar”.
clip_image004[4]
Será aberto o Assistente de importação de Certificado avance a primeira tela e na segunda selecione o certificado que será utilizado e avance. Na tela seguinte coloque a senha do Certificado e marque as opções de “Ativar Proteção de alta segurança para chaves particulares”, “Marcar esta chave como exportável” e clique em “Avançar” até concluir.
clip_image006[4]
Depois de importado ele aparecerá na lista de certificado conforme tela abaixo.
clip_image008[4]

Selecione o Certificado e clique em “Exportar” (figura anterior) Avance ate a tela a baixo e selecione a opção “Sim, exportar a chave particular”.
clip_image010[4]
Na tela seguinte deixe as opções marcadas conforme figura abaixo.

clip_image012[4]

Nas próximas telas deverão ser preenchidos a nova senha do certificado digital, o nome e local que o arquivo será salvo.


quinta-feira, 22 de dezembro de 2011

CT-e - OBRIGATORIEDADE E RELAÇÃO DE EMPRESAS

Agora ja foi definido datas para obrigatoriedade do CT-e, vejam abaixo e identifique onde sua transportadora se enquadra.

AJUSTE SINIEF 18, DE 21 DE DEZEMBRO DE 2011.
Altera o Ajuste SINIEF 09/07, que institui o Conhecimento de Transporte
Eletrônico e o Documento Auxiliar do Conhecimento de Transporte Eletrônico.
O Conselho Nacional de Política Fazendária - CONFAZ, na sua 169ª reunião extraordinária, realizada em Brasília, DF, no dia 21 de dezembro de 2011, tendo em vista o disposto no art. 199 do Código Tributário Nacional (Lei nº 5.172, de 25 de outubro de 1966), resolve celebrar o seguinte
AJUSTE
Cláusula primeira Os dispositivos a seguir indicados do Ajuste SINIEF 09/07, de 24 de outubro de 2007, passam a vigorar com as seguintes redações:
I - os §§ 3º e 4º da cláusula primeira "§ 3º A obrigatoriedade da utilização do CT-e é fixada por este ajuste, nos termos do disposto na cláusula vigésima quarta, ficando dispensada a observância dos prazos nessa contidos na hipótese de contribuinte que possui inscrição em uma única unidade federada".
§ 4º Para fixação da obrigatoriedade de que trata o § 3º, as unidades federadas poderão utilizar critérios relacionados à receita de vendas e serviços dos contribuintes, atividade econômica ou natureza
da operação por eles exercida.";
II - a cláusula vigésima quarta:
"Cláusula vigésima quarta Os contribuintes do ICMS em substituição aos documentos citados na cláusula primeira deste ajuste ficam obrigados ao uso do CT-e, nos termos do § 3º, a partir das seguintes datas:
I - 1º de setembro de 2012, para os contribuintes do modal:
a) rodoviário relacionados no Anexo Único;
b) dutoviário;
c) aéreo;
II - 1º de dezembro de 2012, para os contribuintes do modal ferroviário;
III - 1º de março de 2013, para os contribuintes do modal aquaviário;
IV -1º de agosto de 2013, para os contribuintes do modal rodoviário, cadastrados com regime de apuração normal;
V - 1º de dezembro de 2013, para os contribuintes:
a) do modal rodoviário, optantes pelo regime do Simples Nacional;
b) cadastrados como operadores no sistema Multimodal de Cargas.".
Parágrafo único. Ficam mantidas as obrigatoriedades estabelecidas pelas unidades federadas em datas anteriores a 31 de dezembro de 2011.".
Cláusula segunda Ficam acrescidos os seguintes dispositivos ao Ajuste SINIEF 09/07:
I - os §§ 5º e 6º à cláusula primeira, com a seguinte redação:
§ 5º A obrigatoriedade de uso do CT-e aplica-se a todas as prestações efetuadas por todos os estabelecimentos dos contribuintes referidos na cláusula vigésima quarta, bem como os relacionados no Anexo Único deste ajuste, ficando vedada a emissão dos documentos referidos nos incisos do caput desta cláusula, no transporte de cargas.
§ 6º Nos casos em que a emissão do CT-e for obrigatória, o tomador do serviço deverá exigir sua emissão, vedada a aceitação de qualquer outro documento em sua substituição.";
II - o Anexo Único, com a redação constante do Anexo Único deste ajuste.
Cláusula terceira Este ajuste entra em vigor na data da sua publicação no Diário Oficial da União, produzindo efeitos a partir de 1º de janeiro de 2012.
Presidente do CONFAZ - Nelson Henrique Barbosa Filho p/ Guido Mantega; Acre – Mâncio Lima Cordeiro, Alagoas - Maurício Acioli Toledo, Amapá - Jucinete Carvalho de Alencar, Amazonas - Isper Abrahim Lima, Bahia - Carlos Martins Marques de Santana, Ceará - Carlos Mauro Benevides Filho, Distrito Federal - Marcelo Piancastelli de Siqueira, Espírito Santo - Maurício Cézar Duque, Goiás - Simão Cirineu Dias, Maranhão - Claudio José Trinchão Santos, Mato Grosso - Edmilson José dos Santos, Mato Grosso do Sul - Mário Sérgio Maciel Lorenzetto, Minas Gerais - Leonardo Maurício Colombini Lima, Pará - José Barroso Tostes Neto, Paraíba - Aracilba Alves da Rocha, Paraná – Luiz Carlos Hauly, Pernambuco - Paulo Henrique Saraiva Câmara, Piauí -Antônio Silvano Alencar de Almeida, Rio de Janeiro -Renato Augusto Zagallo Villela dos Santos, Rio Grande do Norte - José Airton da Silva, Rio Grande do Sul - Odir Alberto Pinheiro Tonollier, Rondônia - Benedito Antônio Alves, Roraima -Luiz Renato Maciel de Melo, Santa Catarina - Nelson Antônio Serpa, São Paulo – Andrea Sandro Calabi, Sergipe - João Andrade Vieira da Silva, Tocantins - José Jamil Fernandes Martins.

http://www.in.gov.br/visualiza/index.jsp?data=22/12/2011&jornal=1&pagina=49&totalArquivos=156

quarta-feira, 21 de dezembro de 2011

Novas leis da ANTT para 2012 - Palestra na SINDETRAP - Piracicaba SP

Segue resumo da palestra acontecida no dia 20-12-2011 na SINDETRAP, onde foi discutido varios assuntos e esclarecimentos de duvidas para as novas leis que serão exigidas para o ano de 2012 pela ANTT.


Resumo da Palestra : 
by Aline Fernandes 

A palestra foi referente a lei 12.249/07 e abordou a resolução 3.658/2011 da Agência Nacional de Transportes ( ANTT ), de 19/04/2011
Regulamenta o art. 5º-A da Lei nº 11.442, de 5 de janeiro de 2007, que "dispõe sobre o transporte rodoviário de cargas por conta de terceiros mediante remuneração e revoga a Lei nº 6.813, de 10 de julho de 1980".
A Agência Nacional de Transportes Terrestres (ANTT) começa a fiscalizar e multar, no dia 22 de janeiro quem ainda estiver utilizando carta-frete. As multas vão de R$ 550 a R$ 10.500 e podem ser aplicadas tanto ao contratante (empresa de transporte ou embarcador) como ao caminhoneiro autônomo.
Uma vez proibido a carta-frete, solicita que os contratantes de fretes cadastrem suas operações de transporte por meio de uma administradora de meios de pagamento eletrônico de frete, como a Repom, sendo essa responsável pela geração do Código. Esta resolução visa proteger os autônomos.
A empresa que contratar os serviços do autônomo, se este trabalhar com seu caminhão, terá que gerar o Código Identificador da Operação de Transporte (Ciot) .
O Ciot consiste em um código numérico que, após gerado e informado por uma empresa homologada pela ANTT, deverá constar no contrato de frete ou no Conhecimento de Transporte Rodoviário de Cargas (CTRC).
Para cada operação deve-se gerar um nº de ( Ciot ) , se a carga for fracionada deve-se pegar a viagem mais longa do dia . Esta em discussão para alterar para gerar apenas 1 nº de ( Ciot ) para todas as viagens de cada placa do caminhão no mês ou na data do acerto do Autônomo .
As empresas homologadas pela Agência Nacional de Transportes Terrestres (ANTT) para atuar como Administradoras de Meios de Pagamento de Frete são :GPS Logística, Roadcard, Rodocred e Repom e Dbtrans.
Art. 6º Para a geração do Código Identificador da Operação de Transporte, será
necessário informar:
I - o número do RNTRC do contratado;
II - o nome, a razão ou denominação social, o CPF ou CNPJ, e o endereço do
contratante e do destinatário da carga;
III - o nome, a razão ou denominação social, o CPF ou CNPJ, e o endereço do
subcontratante e do consignatário da carga, se existirem;
IV - os municípios de origem e de destino da carga;
V - a natureza e a quantidade da carga, em unidade de peso;
VI - o valor do frete, com a indicação do responsável pelo seu pagamento;
VII - valor do combustível, se for o caso, destacado apenas contabilmente;
VIII - o valor do pedágio desde a origem até o destino;
IX - o valor dos impostos, taxas e contribuições previdenciárias incidentes; e
X - a placa do veículo e a data de início e término da operação de transporte.

Dúvidas ref a geração do ( Ciot ) para e-mail : Gildete Menezes - Assessora assessora da NTC&Logística e-mail : gmenezes.ntc.org.br
 by Aline Fernandes 

Também podemos encontrar mais informações em :
http://www.sindetrap.com.br/empresarios-e-executivos-do-transporte-participam-de-palestra-do-sindetrap-3/