Italo Giurizzato Junior

Boa tarde Julianamver, Essas TAGs são opcionais segundo o manual. No caso do Estado de São Paulo os valores da BC do ICMS ST retido e do ICMS ST retido são opcionais ou obrigatório? Se for obrigatório você tem que calcular e informar.

Pesquise no fórum, se não me falha a memória, mesmo você tendo permissão de administrador não é suficiente tem que habilitar/desabilitar umas opções do windows para conseguir ter o controle total da máquina.

Boa tarde Galvaonv, Posso estar errado, mas a partir do momento que você não vai realizar o serviço de entrega, não vejo motivo de emitir. Você deve sim emitir a Nota Fiscal de venda do produto apenas.

Boa tarde tecnologiabr, Seria possível postar como anexo um XML que ocorre a rejeição?

No Windows 64 bits as DLLs são salvas em uma pasta diferente da versão 32 bits.

Se você quer desenvolver uma aplicação que funcione tanto com os certificados A1 quanto com os A3, você deve utilizar o Capicom, ou seja, não definir a diretiva ACBrNFSeOpenSSL. Neste caso não importa se o certificado é A1 ou A3 você vai passar para o componente somente o numero de série do mesmo.

Dependendo da versão do Windows, você tem que instalar as DLLs com permissão de administrador, caso contrario não funciona.

Boa tarde Leufmt, Programa exemplo do ACBrNFSe, procedure ConfiguraComponente: {$IFDEF ACBrNFSeOpenSSL} ACBrNFSe1.Configuracoes.Certificados.Certificado := edtCaminho.Text; ACBrNFSe1.Configuracoes.Certificados.Senha := edtSenha.Text; {$ELSE} ACBrNFSe1.Configuracoes.Certificados.NumeroSerie := edtNumSerie.Text; {$ENDIF} Note que as linhas em negrito só vão ser compiladas se a diretiva de compilação ACBrNFSeOpenSSL estiver definida, caso contrario não. Não definindo essa diretiva, o componente assume que você esta utilizando o Capicom, que lhe permite utilizar tanto o certificado A1 quanto A3. Por outro lado se você defini a diretiva, o componente assume que você só vai utilizar o certificado A1, já que o OpenSSL só funciona com o certificado A1.

Se você tem a certeza que todos os fontes de todas as pastas estão atualizados, desistale e instale novamente.

Boa tarde Junior, Você atualizou a pasta PCN2? Ou melhor você atualizou todos os fontes de todas as pastas? Você compilou a sua aplicação com a opção Build? O componente ACBrNFe agora possui uma propriedade nova chamada VersaoDF, em função disso há necessidade de reinstalar o componente.

Boa tarde a todos, Que tal dar uma olhada no programa exemplo.

Boa tarde a todos, Por favor atualize todos os fontes de todas as pastas. Existem componentes que utilizam units que estão em outras pastas. Compile a aplicação com a opção Build.

Boa tarde Diogo, Fiz as correções, favor atualizar todos os fontes de todas as pastas. Compile a aplicação com a opção Build e teste novamente.

Bom dia Diogo, Você tem toda razão, antes a função rExtrai retornava o conteudo de um grupo por exemplo: infEvento, com a TAG de inicio e sem a TAG de Fim ou seja, </infEvento>. Essa função foi alterada por Claudemir de tal forma que ela retorna-se o conteudo de grupo completo, ou seja com a TAG de Fim. Vamos fazer as devidas correções. Desde já muito obrigado pelo alerta. Favor atualizar os fontes e testar.

Bom dia Claudio, Obrigado pela colaboração, fontes já estão atualizados.

Bom dia Sérgio, Olhei sim o seu arquivo quando você postou e notei que ele esta em ordem. Será que você não esta usando uma versão antiga do ACBrNFeMonitor?

Bom dia Pablo, Entre varias informações no CT-e temos: nCT = Numero do CT-e que é utilizado na montagem da chave e possui um tamanho máximo de 9 digitos, o numero é sequencial e vai de 1 até 999.999.999 serie = Série do CT-e que é utilizado na montagem da chave e possui um tamanho máximo de 3 digitos, a série é sequencial e vai de 1 até 999, avançamos para a série seguinte quando o nCT atinge o seu limite máximo, ou seja, 999.999.999 e consequentemente o nCT volta para 1. cCT = Código do CT-e que é utilizado na montagem da chave e possui um tamanho máximo de 8 digitos, a SEFAZ orienta aos desenvolvedores que o código seja um numero aleatório. Quando atribuimos o valor zero ao cCT ( cCT=0 ) o componente se encarrega de gerar esse numero aleatório, por outro lado se você informar um numero diferente de zero, o componente se utiliza desse numero para a montagem da chave. Eu não utilizo o ACBrNFeMonitor para emitir o CT-e, pois desenvolvo em Delphi logo utilizo diretamente o componente, componente este também utilizado pelo monitor. A diferença é que o Monitor se lê um arquivo txt para poder alimentar o componente e gerar o XML, já a minha aplicação lê as informações do banco de dados. No meu caso, a tabela (banco de dados) que contem os dados pertinentes ao transporte da carga tem um campo chamado: CodigoCT, a rotina responsável por salvar as informações digitadas pelo usuário nessa tabela, gera um código aleatório e ele é armazenado no campo CodigoCT. A rotina que alimenta o componente para posteriormente gerar o XML, atribui o conteudo do campo CodigoCT (banco de dados) ao campo cCT (componente), algo do tipo: cCT := CodigoCT; Desta forma o componente vai utilizar o numero informado, logo não é para ele gerar. Existem desenvolvedores que atribuem ao campo cCT o mesmo valor de nCT, ou seja, se o numero do CT-e é 456 o código também será 456. Não recomendo fazer desta forma, por dois motivos: 1. A SEFAZ recomenda que seja um código aleatório; 2. O tamanho em digitos do nCT é maior do que cCT.

Fechado por Duplicidade.

Fechado por duplicidade.

Boa noite Jorge, Inicialmente nós disponibilizamos o componente para ser utilizado pelos desenvolvedores em Delphi. Incorporar o mesmo a um monitor, isso já outra história.

Boa noite Felipe, Realize uma pesquisa no fórum, você vai encontrar explicações mais detalhas sobre Redespacho e Redespacho Intermediario.

Boa noite Marco, Analisando os schemas notei que a TAG tara é tratada como string, sendo assim: 10 ou 10.0 é aceito pelo schema. Onde você alterou a tara de inteiro para fracionado?

Boa noite a todos, Chequei os fontes do ACBrNFeMonitor e não encontrei nada de anormal. O campo correto é cCT no caso do CT-e. Foi informado cCT=1 e esse valor foi utilizado na montagem da chave, correto? O XML salvo em disco a chave é: 41131205294337000172570010000001071000000010 ? Esse CT-e foi assinado, enviado e protocolado como autorizado? Foi dito que ao consultar "não deu certo", será que não esta sendo enviado novamente o mesmo CTe so que agora com o cCT=0 ? Para mim é a unica resposta por estar gerando a chave: 41130505294337000172570010000001071458724823

Marco, Ao gerar o XML do MDF-e a TAG sai como veicPrincipal ou veicTracao? O correto é veicTrancao, a validação já outra história. A validação depende dos schemas. Se você configurou o componente para a versão 1.00a, os schemas a serem utilizados estão no arquivo: PL_MDFe_100a_pre (correcao).zip pasta ...\Exemplos\ACBrMDFe\Delphi\Schemas\V100

Boa tarde Marco, Note que o componente possui uma propriedade chamada VersaoDF que aceita os valores ve100 e ve100a. Se você esta realizando testes utilize a versão 1.00a e consequentemente os schemas para esta versão. Ocorreu uma mudança entre uma versão e outra. Antes a TAG era veicPrincipal agora é veicTracao. Se esta gerando o XML com a TAG veicPrincipal isso significa que o seus fontes estão desatualizados.