Italo Giurizzato Junior

Boa tarde Marcel, Mande para mim por e-mail o arquivo -env-lot-c.xml referente ao envio do RPS 98. e o arquivo -rec-c.xml

Bom dia João, O DACTE disponivel não esta completo, ainda falta algumas coisas, uma delas é o quadro que apresenta os dados de produtos perigosos. Você tem toda a liberdade de realizar essa implementação e ficariamos gratos se depois disponibiliza-se para a comunidade.

Bom dia Vinicio, Continua a mesma, a Nota Técnica não diz nada que temos que utilizar uma nova série para enviar para o SVC.

Bom dia Robinho, Agora temos um documento emitido pelo ENCAT que contem as orientações de como proceder. Quanto ao componente não muda nada, como esta claro nesse documento chamado de Boletim Técnico, trata-se apenas da forma correta de passar as informações. Mas para que uma transportadora possa lançar mão dessa alternativa, necessita de uma autorização concedida pela UF de sua jurisdição (veja item 2). Só não consta nesse Boletim Técnico como proceder com as notas, mas acredito que devemos relacionar todas elas.

Bom dia, Descobri o problema. Ele se encontra na function rCampoCNPJCPF que possui a seguinte lógica: result := rCampo(tcStr, 'CNPJ'); if trim(result) = '' then result := rCampo(tcStr, 'CPF'); Note que le primeiramente a tag CNPJ se o retorno for vazio le a tag CPJ. Acontece que dentro do grupo <rem> temos o grupo <enderReme> e podemos ter também um dos grupos: infNF, infNFe, infOutros. Dentro do grupo <infNF> podemos ter o grupo <locRet> ou seja o local de retirada que também poderá ter as tags CNPJ ou CPJ. No seu XML tem o grupo <locRet> com a tag <CNPJ> isso faz com que a funcion pegue o conteudo dessa tag em vez do CPF do Remetente. Se alterarmos a function para a seguinte lógica: result := rCampo(tcStr, 'CPF'); if trim(result) = '' then result := rCampo(tcStr, 'CNPJ'); O seu problema fica resolvido, pois ele vai ler o CPF do Remetente. Mas por outro lado imagina que o Remetente possui CNPJ e a pessoa referente ao local de retirada possui um CPF, a function vai pegar primeiramente o CPF do local de retirada e não o CNPJ do remetente. Sendo assim, a minha sugestão é estudar as function rExtrai e rCampo que estão na unit pcnLeitor.

Bom dia Neo, Por favor atualiza os fontes e tenta novamente.

Bom dia Marcel, Se no ambiente de homologação a emissão ocorre sem nenhum problema e no ambiente de produção o envio é rejeitado, isso me leva a crer que a empresa esta habilitada somente a usar o ambiente de homologação. Verifique se não há necessidade de agora habilitar a mesma em produção. Isso ocorre com a NF-e, CT-e, você credencia a empresa primeiramente no ambiente de homologação e depois em produção, ou seja são dois credenciamentos.

Bom dia Udenilson, Post o XML como anexo.

Bom dia, Post o XML do CT-e como anexo.

Eu sei, Como tem varias pessoas postando que foi publicada a NT de numero tal e se o componente vai ser atualizado ou não. Mediante a isso, tomei a liberdade de realizar as implemetações e avisar toda a comunidade que o componente já foi atualizado. Bastando agora o aval dos mantenedores para que eu possa disponibilizar os fontes. Desta forma o pessoal já poderia iniciar os testes. Lembrando que algumas dessas alterações só vão poder ser testadas quando a SEFAZ implementar em seus webservices. Visto que muitas delas se referem a nova versão da NF-e.

Bom dia Isaque, Eu inclui o seu nome por ser um dos administradores. Inclusive eu mandei uma MP para ele não obtive retorno. Enviei hoje um e-mail para o André contendo as units alteradas. As implementações que fiz atende todas as útimas NTs publicadas pela SEFAZ.

Boa noite Augusto, Você consegui corrigir o problema?

Boa noite Neo, Vou verificar.

Boa noite Lúcio, No quadro Componentes de Valor devemos informar os valores que compõe o valor do frete e não a forma e prazo de pagamento. Os dados relacionados a forma de pagamento como data de vencimento e valor de cada parcela, existe um lugar especifico no XML, quanto ao DACTE essas informações não são impressas. Mas você pode alterar o DACTE para que o mesmo imprima esses dados no quadro de observações.

Boa noite a todos, Optei por remover do nome do PDF o código de verificação para ficar compativel ou melhor dizendo padronizado com os demais DANFSEs. Favor atualizar os fontes e realizar os testes.

Boa noite Vinicio, Segundo a NT 2012/003 não diz que você deve gerar um novo XML e enviar para a SEFAZ de origem (Item 6). O item 8.2 deixa claro que ocorre o sincronismo entre o SVC e a SEFAZ de Origem e se tentar enviar para a SEFAZ de Origem o mesmo XML ele vai ser rejeitado. Em resumo temos o seguinte exemplo: CT-e Envio ------ ------- 250 SEFAZ-MG 251 SVC-SP 252 SEFAZ-MG Neste exemplo fica claro que o CT-e de numero 251 enviado para o SVC-SP não é enviado novamente para a SEFAZ-MG e a numeração permanece sequencial, independente para qual SEFAZ ele é enviado (Origem ou Vitual de Contingênci).

Boa noite Marcio, Precisamos saber com certeza se o provedor de Assis-SP realmente é GovBR ou não, antes de incluir.

Boa noite a todos, O componente ACBrNFe já esta preparado com todas as alterações referentes as últimas NTs. Até o final desta semana posso disponibilizar desde que o André, Daniel, Isaque me autorizem.

Boa noite Marcel, A empresa (emitente) esta cadastrado no provedor para poder emitir a NFS-e?

Bom dia Medreis, Manual da ABRASF Versão 1.0 - página 20 temos a definição do tipo simples: TsAliquota Alíquota. Valor Percentual Formato: 0.0000 Ex: 1% = 0.01 25,5% = 0.255 100% = 1.0000 ou 1 Versão 2.01 - página 25 temos a definição do tipo simples: TsAliquota Alíquota. Valor Percentual Formato: 00.00 Ex: 1% = 1 25,5% = 25.5 10% = 10 Pelo jeito o Ginfes ainda esta na versão 1.0, mas a mensagem de erro não condiz com o schema utilizado.

Bom dia Udenilson, Se você utiliza o tortoise para baixar os fontes, você configurou ele com a nova URL? Se não, pesquise no fórum por: Atualização Forçada.

Graça, Primeira mente desculpe, achei que você estava se referindo ao CT-e que também vai passar a ter essas TAGs como dito a partir da versão 2.00 O grupo <infUnidTransp> foi implementado no MDF-e segundo a NT 2013/004. Quero lembra-la que o componente ACBrMDFe já esta preparado para satisfazer a NT 2013/004. O significado das TAGs são as mesmas em ambos os documentos: MDF-e e CT-e. Até o momento não foi publicado nenhuma alteração nos DA (Documentos Auxiliares ou seja: DACTE e DAMDFE, sendo assim essas informações a principio vão constar somente no XML. Quanto a TAG #62 <qtdRat> da NT 2013/004 (página 97) diz que se trata da Quantidade Rateada que pode ser o Peso ou Volume. Segundo a NT 2013/002 do MDF-e temos:

Bom dia Graça, O grupo <infUnidTransp> é opcional e é uma das novidades da versão 2.00 do CT-e. Já encontra-se disponivel no Portal Nacional do CT-e o MOC versão 2.00 você vai encontrar todas as informações sobre as TAGs desse novo grupo. Um detalhe importante o componente já esta pronto para esta nova versão, faltando apenas as URLs que não foram divulgadas ainda. Mas já é possível iniciar os testes: Gerar o XML; Assinar; Validar. Desde que você tenha os schemas para esta nova versão, inclusive eles também estão disponiveis no Portal.

Bom dia a todos, Segundo o manual da ABRASF a aliquota deve ser informada da seguite forma: Se for 2% devemos informar 0.02 consequentemente se for 3,5% => 0.035 A formatação que consta no manual é 1 inteiro e 4 decimais. A mensagem de erro do Ginfes esta errada não é 5 inteiros e 2 decimais, e sim 3 inteiros e dois decimais, a notação 5,2 para mim significa que temos um total de 5 digitos sendo que 2 são decimais. De uma forma ou de outra neste caso a aliquota não deve ser dividida por 100 ou seja se a mesma for 3,5% devemos informa-la desta forma 3.50 Como não existe uma padronização, e o manual da ABRASF não contem um padrão de layout do XML e sim uma sugestão, o jeito é ficar fazendo testes até encontrar uma forma correta de informar a aliquota.

Bom dia Rafael, OkConversao é apenas uma variável do tipo Boolean. Declara ela em Private do seu form por exemplo.