Italo Giurizzato Junior

Bom dia, Tem algo errado. Na empresa uso Windows XP e consigo imprimir a CC-e.

Bom dia Fernando, Checando apenas a estrutura do grupo <evCCeCTe> que diz respeito a CC-e esta correto, inclusive os nomes dos grupos e campos que se deseja alterar. É muito estranho ocorrer a rejeição.

Bom dia JGarcia, Já foi dito em vários post que o componente possui 3 formas de envio, você testou as 3? Se o componente retorna a mensagem informando que a funcionalidade XYZ não foi disponibilizada pelo provedor ABC significa que você não pode usa-la para o respectivo provedor. No caso do Ginfes o Gerar NFSe e o Enviar Síncrono não vai funcionar, uma vez que o provedor não implementou os Web Services que atende essas funcionalidades, restando apenas o Enviar Lote RPS. Se o componente acusa que não encontrou os schemas, com certeza você esta configurando o componente de forma errada.

Boa tarde a todos, Favor atualizar os fontes e testar novamente.

Boa tarde Jadir, Já chegou a fazer algum teste com o programa exemplo, configurando-o para a cidade em questão?

Boa tarde Marcio, Não é nada disso. Por favor leia a Nota Técnica.

João, Sem levar em consideração que a NT 2013/007 versão 1.01 que trata sobre o assunto SVC foi publicado em Novembro/2013 e a última, ou seja, a versão 1.03 em agosto/2014. O ambiente de homologação foi disponibilizado em 01/12/2013 portanto fazendo as contas, foram 10 meses que a SEFAZ deu para que os desenvolvedores pudessem fazer as devidas alterações e testes em suas aplicações para atender essa nova realidade. Mas como sempre, muitos não levam as coisas a sério. Uma prova disso é que hoje: 30/09/2014, data da desativação do SCAN, existem desenvolvedores perdidos, não sabem que rumo tomar.

Boa tarde Odlawso, O schemas que você obteve é o mesmo que encontra-se disponível na pasta: ...\Exemplos\ACBrNFSe\Delphi\Schemas\Salvador.

Post como anexo.

Boa tarde Graça, A principio você não pode alterar, mas porem todavia contudo entretanto, se essa alteração não afetar nos dados já enviados através do EPEC......... Entendeu? No meu entendimento o procedimento correto é: 1. Gerar o XML da NF-e com tpEmis = 4, informar dhCont e xJust; 2. Enviar o EPEC considerando os dados usados ao gerar o XML da NF-e. 3. Assim que os problemas forem sanados, enviar o XML gerado no item 1. Na página 6 da Nota Técnica 2014/001 versão 1.00 temos a estrutura do Evento EPEC, note que temos que informar o Valor total da NF-e, Valor total do ICMS e ICMS ST. Sendo assim qualquer alteração nos itens pode provocar a alteração desses valores, fazendo com que desta forma a SEFAZ detecte que ocorreu uma alteração no XML gerado antes e depois do EPEC.

Boa tarde André, Muito obrigado pela colaboração, já esta disponível.

Boa tarde Fernando, Favor atualizar os fontes, pois acabo de implementar a possibilidade de imprimir o Evento de Registro do Multimodal.

Boa tarde Diogo, Eu não utilizo o componente ACBrNFSe, apenas ajudo no seu desenvolvimento. Por favor entre em contato com o provedor e solicite um arquivo de envio completo, não apenas a estrutura do XML do RPS ou Lote de RPS. É preciso saber a estrutura do Envelope.

Boa tarde André, Favor atualizar os fontes e testar novamente.

Bom dia Dércio, No meu Moto G, utilizo o Rate QR Code Reader.

Sim, mas este que te passei contem os fontes atuais, o outro até onde sei esta desatualizado.

Bom dia João, Você esta se referindo a TAG: indPres e neste caso você esta correto é o mesmo entendimento que tenho. A questão levantada pelo Cantu é sobre o IndFinal, onde devemos informar 0 ou 1 sendo que no caso da NFC-e essa TAG só pode conter o valor 1.

Não esta desta forma? unit pmdfeMDFeW; interface uses SysUtils, Classes, pcnAuxiliar, pcnConversao, pcnGerador, pmdfeConversao, pmdfeMDFe; (...) Então inclua.

Bom dia Cantu, Na Nota Técnica 2013/005 versão 1.03 página 94 temos a regra B25a-10 que diz que a NFC-e será rejeitada caso o indFinal seja igual a ZERO. Como não existe nada a respeito da NF-e, podemos concluir que no caso da NF-e podemos informar ZERO ou UM para indFinal dependendo da situação. Os valores que coloquei no post #2 são os mais comuns.

Celso, Note que o arquivo de retorno após o envio, onde temos o numero do protocolo, consta corretamente o numero do lote. Sendo assim, pode ser algum problema no provedor, uma vez que esta retornando ZERO como numero do lote ao consultar a sua situação. Favor entrar em contato com eles.

Leandro, Verifique se na unit: pmdfeMDFeW.pas consta em Uses a unit pmdfeConversao.

Bom dia Wilton, Se não me falha a memória a URL não é mais essa e sim: svn://svn.code.sf.net/p/acbr/code/trunk

Celso, Esses são os XMLs do RPS e não do lote gerado e enviado. A questão é, se você atribui o valor ZERO para o Lote o retorno esta correto no que diz respeito a TAG <NumeroLote> O problema é que o provedor não processou o seu lote. Se não processou é porque esta na fila de espera.

Bom dia, A final de contas o que você quer emitir, CT-e ou MDF-e? O CT-e é um documento fiscal cujo modelo é 57 e deve ser emitido para acobertar o transporte de cargas. Por outro lado temos o MDF-e - Manifesto Eletrônico de Documentos Fiscais, cujo modelo é 58 e deve ser emitido quando a carga for fracionada e cujo transporte será interestadual. Tem por finalidade agilizar o processo de fiscalização nos postos de fronteira. No Estado de São Paulo fizeram a besteira de obrigar a emissão para transporte intermunicipal também. Entre no Portal Nacional da NF-e, do lado direito temos o logo do MDF-e, clique nele para ter acesso ao Portal Nacional do MDF-e. Baixe a Nota Técnica mais recente para você poder se situar sobre o assunto e não ir na onda de contadores que costumam viajar na maionese e beber gasolina.

Leandro, Mas a unit que mencionei consta as constantes definidas?