Italo Giurizzato Junior

Boa noite Anderson, Sim, esse é o meu entendimento também.

Boa noite Rodrigo, Você desabilitou a visualização? MostrarPreview := False; o comando Imprimir envia o DACTE para impressora, já o comando ImprimirPDF gera o DACTE em PDF e salva em disco.

Boa noite Eleandro, Desculpa não entendi a sua pergunta. Algumas ponderações: a suite ACBr é para o Delphi, o componente ACBrNFe, já possui tudas as TAGs para a versão 3.10 tanto para a NF-e quanto para a NFC-e. Alguns membros do fórum já estão realizando testes. Não sei se isso responde a sua pergunta, caso contrario seja mais claro no seu questionamento.

Boa tarde Rigotti, Obrigado pela colaboração, favor atualizar os fontes e testar.

Boa tarde Sérgio, Quem esta cuidando do munitor é o Isaque Pinheiro. É ele o responsavel pela compilação e liberação, não sei lhe informar qual é a versão que lhe permite a realizar os testes com a nova versão 2.00 do CT-e Nesse primeiro momento pelo que me recordo não ocorreu alteração na montagem do TXT.

Boa tarde Hugo, Será que esse pessoal da prefeitura, não estam confundindo as coisas? Para se emitir uma NFS-e via site, basta possuir um login e senha. Mas para emitir via WebServices é necessário o certificado, pelo menos acredito que todos os provedores sejam desta forma.

Boa tarde Cláudio, Favor atualizar os fontes, inclusive dos programas exemplos. Abra o programa exemplo do MDF-e e estude o código do botão [Consultar pela Chave].

Boa tarde Nellien, O XML que você postou é o retorno da SEFAZ que o componente salvou? Se sim, ele esta muito estranho pois possui um prefixo tanto na tag de abertura quanto a de encerramento, veja: <retEventoCTe:retEventoCTe xmlns:retEventoCTe="http://www.portalfiscal.inf.br/cte" xmlns="http://www.portalfiscal.inf.br/cte" versao="2.00"> (...) </retEventoCTe:retEventoCTe> veja este outro exemplo: <retEventoCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="2.00"> (...) </retEventoCTe> Este último é o correto e esperado pelo componente. Eles pisaram na bola, pois em nenhum XML de envio ou de retorno se coloca prefixo nas TAGs. Nota Técnica 2013/013, página 13 item c: Prefixo de namespace Não é permitida a utilização de prefixos de namespace. Essa restrição visa otimizar o tamanho do arquivo XML.

Bom dia Gallixx, Tente usar o Envio Sincrono.

Bom dia Hugo, O componente ACBrNFSe já possui o provedor Virtual implementado, inclusive para a cidade Barra do Garças. Favor utilizar o programa exemplo para realizar os testes. No caso deste provedor, você deve utilizar o botão [Gerar e Enviar NFSe].

Bom dia Jairo, Verifique se o seu problema não é o mesmo do Luis, ou seja, existe um path no library do Delphi apontando para uma pasta antiga. Ou se existe junto com os fontes da sua aplicação DCUs antigos do componente. Outra coisa importante que costumo dizer sempre, você esta com todos os fontes de todas as pastas atualizados? O teMultiModal esta definido em pcnConversao que esta na pasta PCN2. Tente complilar o pacote PCN2, isso pode resolver o problema.

Bom dia Rodrigo, É preciso fazer uma comparação com os fontes referentes ao DANFSE para descobrir o que foi alterado e que pode estar provocando essa falha.

Boa tarde Astrogildo, Note que o conjunto de valores passado para o operador IN possui apenas 6 elementos. O 301 e 302 são valores de 2 elementos e não a quantidade de elementos. Valores estes a serem comparados com o valor da propriedade cStat, cujo resultado sera True ou False. Darlana, verifique se não existe nenhum "." ponto separando um valor do outro, uma vez que o correto é virgula. Procure deixar um espaço em branco entre a virgula e o próximo elemento.

Boa tarde a todos, Por favor fiquem atentos as publicações da SEFAZ no Portal Nacional da NF-e. A Nota Técnica 2013/005 versão 1.02, página 5 traz as datas de liberação de cada ambiente, bem como a data final de vigencia da versão 2.00 Ambiente de homologação será liberado: 03/02/2014.

Boa tarde Alexandre, Favor atualizar os fontes e testar.

Desculpa, Não vi o post acima, Muito obrigado Leonardo. URL já incluida e disponibilizada.

msiscampos, No meu entendimento, não faz sentido emitir o MDF-e para transporte dentro do Estado, uma vez que não existe fiscalização na entrada de uma cidade. O que temos é um posto fiscal na divisa entre os Estados. Sendo assim a T1 se vai transportar de uma cidade A para uma cidade B que pertencem ao mesmo Estado não vejo motivo de emissão do MDF-e. Apesar de ter uma nova redação da legislação que cita o transporte intermunicipal. Imagina a seguinte situação: Todas as cidade pertencem ao Estado de SP e quem vai realizar o transporte é a mesma transportadora, logo não existe redespacho. Inicio caminhão carregado Entrega das cargas restantes e retorna vazio para a cidade de Inicio A =======> B =========> C ========> D =========> E ==========> A A distancia ente uma cidade e outra é na faixa de 30 km por exemplo. Se for realmente obrigatório emitir o MDF-e para transporte intermunicipal teriamos que emitir 4 MDF-e. O primeiro contendo a carga total para acobertar o transporte de A até B; O segundo contendo somente a carga que vai seguir viagem, para acobertar o transporte de B até C; O terceiro contendo somente a carga que vai seguir viagem, para acobertar o transporte de C até D; O quarto contendo a carga restante que vai ser descarregada em E, portanto para acobertar o transporte de D até E; Como o caminhão segue viagem depois vazio entre E e A não há necessidade de se emitir MDF-e. No meu entendimento, vai ocorrer apenas gasto de papel, tempo e consequentemente dinheiro para garantir a existencia de um documento que com certeza não será fiscalizado. E a carga já esta documentada com as Notas e CT-e. No caso de fronteira entre estados ai sim faz sentido o MDF-e, pois com certeza vai agilizar bastante o processo de checagem da carga liberando o caminhão em um curto espaço de tempo.

Não tenho Paulo.

Bom dia Daniel, Favor atualizar os fontes e testar novamente usando a opção [Gerar e Enviar Lote] do programa exemplo.

Bom dia Leonardo, Ficou faltando a URL de produção.

Bom dia asterix, Submeti o seu XML ao validador da SEFAZ-RS, ele retornou que esta tudo OK. https://www.sefaz.rs.gov.br/CTE/CTE-VAL.aspx Abra o XML usando o Bloco de notas e selecione todo o conteudo depois digite CTRL C no bloco de notas e CTRL V no site e clique em Validar.

Bom dia Marco, Se a distribuidora BR ou Shell emite a nota como sendo NF-e, você não pode utilizar informa-la como sendo NF (papel) ou Outro. O numero do pedido, como você disse vem na nota como sendo uma informação complementar. No CT-e você informa também esse numero no campo de Observação como sendo uma informação complementar.

Bom dia junin, Para implementar essa cidade no componente, há necessidade de saber se o provedor segue o padrão ABRASF se sim, é preciso obter as URLs de homologação e produção bem como os schemas (caso seja um provedor novo).

Bom dia Darlana, Pode ser, não custa nada checar.

Bom dia Darlana, Ao compilar o erro ocorre justamente na linha que você alterou, ou seja: FNotasFiscais.Items[j].Confirmada := (AInfProt.Items.cStat in [100,110,205,150,301,302]); e se remover os valores 301 e 302 a compilação ocorre sem nenhum problema? Se sim, abra a unit pcnRetConsReciNFe e veja se a propriedade cStat não esta definida como sendo Byte em vez de Integer. A unica razão no momento que vejo é essa, uma vez que os valore 301 e 302 ultrapassa o limite de 255.