Italo Giurizzato Junior

Boa tarde Jean, O valor da carga é a somatória do valor da NFe.

Boa tarde Campos, Se você se refere a inclusão do ELT, ainda sem previsão.

Boa tarde Junior, Favor anexar o evento de CC-e para que possamos analisar.

Boa tarde Karine, Favor entrar em contato com a SEFAZ-MG e relata que o XML foi validado pelo Portal Nacional do BP-e e a SEFAZ-MG acusa rejeição 215.

Roberto, Sendo assim, você esta com todos os fontes de todas as pastas atualizados? Se sim, os componentes foram reinstalados com o ACBrInstall_Trunk2? Se sim, foi marcado para apagar os arquivos antigos?

Roberto, Você esta usando o ACBrMonitor Plus para imprimir o DACTE, correto? É a versão mais recente?

Karine, Coloquei o XML no validador disponível no Portal Nacional do BP-e e o erro aponta para o qrCodBPe, diz que o conteúdo esta em desacordo com o tipo de dado - String. O elemento qrCodBPe é inválido - O valor 'https://bpe-homologacao.svrs.rs.gov.br/ws/bpeQrCode/qrCode.asmx?chBPe=52180201543354000145630030010002772287716385&tpAmb=2&jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJjaEJwZSI6IjUyMTgwMjAxNTQzMzU0MDAwMTQ1NjMwMDMwMDEwMDAyNzcyMjg3NzE2Mzg1IiwidHBBbWIiOjJ9.ZZ/bSHFiOwAvyTgzUBmDO05Mjl9WVTh9DIgrOYo+fms=&fprint = F273623C8E936F1AB5B947FF9B6DF26A98C56BA5 'é inválido de acordo com seu tipo de dados' String '- A restrição Padrão falhou. Não sei se o validador que existe no Portal é incapaz de interpretar o CDATA ou se o conteúdo da tag não esta no formato desejado.

Bom dia a todos, Vou enviar para o repositório ainda hoje uma alteração no componente visando o provedor Ábaco. Peço que atualizem e façam novos testes. Vamos ver se conseguimos ajustar esse provedor para funcionar com todas as cidades atendidas por ele.

Bom dia Diego, Ocorreu alteração no arquivo INI do provedor Abaco, favor fazer testes com o que esta disponível no repositório.

Bom dia Agnaldo, Muito obrigado pela colaboração, ainda hoje estarei enviado para o repositório.

Bom dia Roberto, Esta errado o <protCTe> dentro do <CTeOS>, que justamente o que você esta inserindo. Qual é o problema que ocorre na impressão com o <protCTe> na posição correta dentro do XML?

Bom dia Karine, Com a alteração na unit que fiz, o XML foi gerado, assinado, validado e enviado. A SEFAZ retornou a rejeição 999. Normalmente quando é retornado 999 significa que a SEFAZ esta com algum problema e acaba retornando esse erro padrão. Seria interessante você enviar para a SEFAZ os dois XML. O que gera a string do QR-Code segundo o manual e que por sinal não é validado pelo fato de no Schema não constar os parâmetros jwt e fprint. E o que gera a string do Qr-Code com o parâmetro sign com os valores de jwt e fprint concatenados. Este segundo por sua vez é validado conforme o Schema disponibilizado pela SEFAZ. Acredito que a SEFAZ ainda não ajustou de forma correta a recepção de um BP-e emitido em contingência. Um outro teste que pode ser feito, antes de entrar em contato com a SEFAZ é. 1. Voltar a unit ACBrBPe alterada pelo Daniel onde a String do QR-Code é gerada com os parâmetros jwt e fprint. 2. comentar a linha que valida o XML: Bilhetes.Assinar; // Bilhetes.Validar; <==== comentar essa linha ela se contra na função: TACBrBPe.Enviar que se encontra na unit ACBrBPe. 3. Por fim fazer um novo teste de envio. Se o BPe emitido em contingência for autorizado pela SEFAZ e a leitura do QR-Code funcionar, significa que o Schema esta errado.

Karine, Teste com essa alteração. ACBrBPe.pas

Vamos brincar de TE - Tentativa e Erro. Depois de calculado o jwt e o fprint que tal pegar o conteúdo desses dois parâmetros e atribuir ao parâmetro sign, ou seja: em vez de: Passo2 := '&jwt=' + jwt; Passo3 := '&fprint='+fp; Result := Passo1 + Passo2 + Passo3; faríamos: Passo2 := '&sign=' + jwt + fp; Result := Passo1 + Passo2; Dessa forma não vai ocorrer erro de validação, mas não sei se a SEFAZ vai autorizar. Não custa tentar.

Boa noite Daniel, Exatamente, os caras escrevem o manual de um jeito e monta o Schema de outro.

Boa noite Sergio, Lendo um resumo da reunião sobre o DT-e, muita setores se colocaram contra, não sei se vai vingar, pois é algo que ANTT quer implementar em substituição ao MDF-e que já existe a um bom tempo e esta solidificado. O problema é que a ANTT não tem permissão de ter acesso de forma irrestrita o MDF-e.

Boa noite Karine, O problema agora é o Schema que não contem os parãmetros usados quando o BP-e é emitido em contingência. Veja: <xs:element name="qrCodBPe"> <xs:annotation> <xs:documentation>Texto com o QR-Code impresso no DABPE</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:minLength value="50"/> <xs:maxLength value="1000"/> <xs:pattern value="((HTTPS?|https?)://.*\?chBPe=[0-9]{44}&amp;tpAmb=[1-2](&amp;sign=[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1})?)"/> </xs:restriction> </xs:simpleType> </xs:element> Note que não tem os parâmetros: jwt e fprint, conforme especificado na página 72 do Manual versão 1.00a do BP-e. Favor entrar em contato com a SEFAZ e relatar o problema no Schema: bpeTiposBasico_v1.00.xsd

Boa noite Roberto, Você notou que no XML que você se refere ao acbr consta o grupo <protCTe> duas vezes sendo que uma esta no lugar errado e outra no lugar certo? Analisando o código não encontrei nada que fizesse o componente incluir o respectivo grupo no lugar errado.

Boa noite Karine, Ao consultar pela chave a SEFAZ retorna a situação atual do BP-e, ou seja, se ele esta Autorizado ou Cancelado.+ Já o evento de Não Embarque não altera a situação do BP-e, ou seja, não faz que o mesmo deixa de estar Autorizado. Mas no XML de retorno consta o evento de Não Embarque.

Karine, Muito obrigado pela colaboração, vamos analisar.

Boa tarde Karine, Favor atualizar os fontes e testar novamente.

Boa tarde Roberto, Essa checagem só se faz necessário se a nota for versão 4.00 ? Se sim, a implementação não poderia ser semelhante a do cst41? Pois não entendi o motivo de ler o campo ICMSST uma vez que não é um campo e sim um grupo.

Karine, Você tem razão a montagem da string do QR-Code esta errada para emissão em contingência. Já estamos analisando e em breve vamos enviar para o repositório a correção.

Karine, Pelo que vi, o Cancelamento e o Não Embarque esta funcionando, pelo menos os XML estão sendo gerados de forma correta. Você fez depois a consulta a esses dois BP-e e o retorno dessas duas consultas? Você não anexou o XML de retorno.

Bom dia Roberto, Favor anexar o XML do CT-e OS com o protocolo de autorização segundo o ACBr e segundo a sua rotina para que possamos analisar.