Italo Giurizzato Junior

Boa tarde Edson, Por favor anexe o arquivo INI que você alterou para que possamos analisar e estando tudo OK, enviaremos para o repositório.

Boa tarde Adryelle, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde a todos, Realmente segundo os schemas a tag Alíquota deve ser gerada com 4 casas decimais. Alteração realizada e enviada para o repositório. Vou fechar o tópico.

Boa tarde Fabio, A principio o ambiente de homologação funciona tanto com ou sem certificado digital, por outro lado o ambiente de produção só funciona com o certificado digital. Entrei em contato com o eFrete passei um relatório com os testes que realizei e estou aguardando um retorno deles.

Boa tarde Thiago, Complementando o que o Big Wings disse, no caso do CT-e devemos utilizar o método DistribuicaoDFePorUltNSU. Caso você já tenha feito alguma rotina para a NF-e usando o método acima, ela é idêntica para o CT-e.

Boa tarde, Muito obrigado pela colaboração, já esta no repositório. Por favor atualize todos os fontes de todas as pastas e faça novos testes.

Bom dia a todos, O provedor Elotech pelo que notei ele segue a versão 2 do layout do ABRASF com algumas pequenas diferenças. Sendo assim não deveria existir a unit pnfsNFSeW_Elotech.pas, pois a geração do XML deveria ser feita pela unit pnfsNFSeW_ABRASFv2 como é dos demais provedores que seguem essa versão. Não entendi a necessidade de criar esses métodos novos para o cancelamento tanto ACBrNFSeNotasFiscais quanto no pnfsNFSeW e pnfsNFSeW_Elotech, visto que a montagem do XML de cancelamento se encontra na unit pnfsNFSeG, inclusive o de consulta. Logo se existe algo diferente, essa diferença ao solicitar a consulta ou cancelamento deve ser tratado nessa unit.

Bom dia Fabiano, Conforme consta na NT 2020/001 versão 1.04 página 10 temos as seguintes regras: Se modal rodoviário e Tipo Emitente for igual a Prestador de Serviço de Transporte (tpEmit=1) ou transportador que emitirá CT-e globalizado (tpEmit=3), o grupo produto predominante deve estar informado (grupo: prodPred) Observação: regra de validação aplicável em produção a partir de 06/07/2020 [COVID-19] e Se modal rodoviário e Tipo Emitente for igual a Prestador de Serviço de Transporte (tpEmit=1) ou transportador que emitirá CT-e globalizado (tpEmit=3) e MDF-e possuir apenas um DF-e transportado no grupo infDoc: O grupo de informações da carga lotação (infLotacao) deve estar informado Observação: regra de validação aplicável em produção a partir de 06/07/2020 [COVID-19] Essas duas regras são facultativas, mas como o MDF-e só é recepcionado pela SEFAZ-Virtual do RS com certeza vão ser aplicadas. A não ser que dependendo da UF do emitente a SVRS vai aplicar ou não essas regras.

Bom dia Valter, Acredito que em DataEmissao é a data que a nota esta sendo emitida, por outro lado Competência seria a data que o serviço foi prestado. Já DataEmissaoRPS é utilizado por algum outro provedor e que acredito deva receber a mesma data do DataEmissao.

Bom dia Goes, Poderia anexar a unit alterada para que possamos analisar?

Bom dia Manuela, Você atualizou todos os fontes de todas as pastas? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Esta fazendo os testes com o programa exemplo do componente?

Bom dia ALA, Ainda nada foi feito.

Bom dia Wilchaia, Então temos um novo provedor chamado Futurize e a cidade Matias Barbosa/MG passou a utilizar ele. Agora podemos dar continuidade com a implementação.

Bom dia Wellington, Por favor não fique postando o mesmo problema em vários tópicos. Vamos seguir as regras do fórum. Pesquise antes de postar e só crie um novo tópico se o assunto não tiver haver com o que esta sendo discutido nos demais.

Bom dia Walfrido, Esse erro também ocorre com o programa exemplo? Você atualizou todos os fontes de todas as pastas? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Quanto a questão do envio, você deve verificar junto a prefeitura se existe um limite diário de envio de notas.

Bom dia Carlos, Existe uma outra postagem que esta tratando desse provedor, sugiro que você acompanhe ele. Este tópico será fechado.

Bom dia a todos, No caso da NFS-e temos alguns passos a seguir: 1. Verificar se a cidade em questão se encontra no arquivo Cidades.ini, esse arquivo esta na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI 2. Se não existe é preciso entrar em contato com a prefeitura para saber qual é a empresa que foi contratada para implementar a NFS-e na cidade. Essa empresa chamamos de provedor. 3. Verificar se na mesma pasta indicada acima existe um arquivo INI com o nome do provedor. 4. Se sim, basta incluir a cidade no arquivo Cidades.ini aos moldes das demais que se utilizam do mesmo provedor. 5. É importante obter as URLs de homologação e de produção desse provedor para a cidade em questão, pois em alguns casos devemos informar um fragmento dessas URLs no arquivo Cidades.ini 6. Por fim utilizar o programa exemplo do componente ACBrNFSe para iniciar os testes. Agora se o provedor não existe, vai ser necessário descobrir se ele segue a versão 1 ou 2 do layout da ABRASF ou se possui um layout próprio para que seja possível implementar ele no componente. Se ele possui um layout próprio o tempo e a dificuldade de implementar será grande comparada com os que seguem a ABRASF. Espero ter dado um norte.

Bom dia, Eriq e Farnetani muito obrigado pela contribuição, ainda hoje estarei enviando para o repositório.

Bom dia a todos, O evento Prestação de Serviço em Desacordo é emitido pelo tomador do serviço e não pela transportadora, sendo assim não se faz necessário o tomador estar habilitado a emitir o CT-e, muito pelo contrario. Devemos lembrar que o tomador pode ser o remetente da carga ou o destinatário ou o Expedidor (transportadora) ou Recebedor (transportadora). Observação: O Expedidor e Recebedor como dito acima são transportadoras, estas aparecem no CT-e quando o transporte da carga envolve outras transportadoras para que a mercadoria vá do remetente até o destinatário, logo temos o tipo de serviço Redespacho ou Redespacho Intermediário.

Boa noite Leonardo, Não tenho condições de testar, pois além de não ter um certificado digital, não tenho nenhum cliente que emite a GNRE. Logo acabo fazendo alterações que julgo que vai funcionar e fico no aguardo de um retorno de quem utiliza, mas vou voltar a verificar a rotina para ver se descubro algo que possa estar ainda errado. Quanto a informar o produto, você tem algum XML de GNRE a ser enviado que contenha essa informação?

Boa noite Onyx, Você alterou o componente para que a tag <qVol> seja gerada com 2 casas decimais, correto? Gerou o XML e mandou imprimir o DANFE, correto? Foi impresso da forma que o seu cliente deseja, correto? Depois assinou e tentou validar, correto? Ocorreu erro na validação? Com certeza sim, pois veja como esta definido no schema da SEFAZ essa tag: <xs:element name="qVol" minOccurs="0"> <xs:annotation> <xs:documentation>Quantidade de volumes transportados</xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> <xs:pattern value="[0-9]{1,15}"/> </xs:restriction> </xs:simpleType> </xs:element> Na linha: <xs:pattern value="[0-9]{1,15}"/> Esta claro que a tag <qVol> pode conter de 1 até 15 caracteres que estejam dentro do dominio [0-9], ou seja, somente dígitos. Na linha a baixo é um patter de uma tag que aceita até 15 dígitos, sendo 13 de corpo (parte inteira) e 2 decimais. <xs:pattern value="0|0\.[0-9]{2}|[1-9]{1}[0-9]{0,12}(\.[0-9]{2})?"/> Deu para perceber bem a diferença. Resumindo não ainda você fazer a alteração que você fez pois o Schema não vai aceitar um numero real onde se espera um numero inteiro. Mas vamos em frente e atrás vem gente. Mantenha a sua alteração e comente a linha que realiza a validação do XML, desta forma, não vai ocorrer o erro de validação e o XML vai ser enviado para a SEFAZ. Veja a linha que deve ser comentada a baixo: function TACBrNFe.Enviar(const ALote: String; Imprimir: Boolean; Sincrono: Boolean; Zipado: Boolean): Boolean; var i: integer; begin WebServices.Enviar.Clear; WebServices.Retorno.Clear; (...) NotasFiscais.Assinar; // NotasFiscais.Validar; Linha comentada para não realizar a validação do XML antes do seu envio Result := WebServices.Envia(ALote, Sincrono, Zipado); (...) end; end; Se a SEFAZ aceitar a tag <qVol> como sendo um numero real em vez de inteiro, podemos concluir duas coisas: 1. A SEFAZ não valida essa informação, ela simplesmente trata ela como sendo uma simples string com no máximo 15 caracteres. 2. A SEFAZ valida essa informação, logo os schemas disponibilizados por ela a anos esta errado a definição dessa tag. Estou ansioso em saber se a nota foi autorizada ou não.

Boa tarde, Você esta atribuindo a BC ao campo: vBCFCPUFDest? Pois se não estiver, a tag vai ser gerada com o valor zero.

Boa tarde, Verifique se você não esta definindo um nome para o PDF na propriedade NomeDocumento. Se sim, este deve estar acompanhado do Path, caso contrario vai ser salvo na pasta que contem o executável.

SEFAZ Paraíba disponibilizada na SVRS Comunicamos que o ambiente de autorização da SVRS está habilitado para emissão de NF3e para o estado da Paraíba nos ambientes de homologação e produção. NF3e - Nota Fiscal de Energia Elétrica Eletrônica. Fonte: Portal DFe SVRS

Boa tarde Tulio, Muito obrigado pela informação, já foi feito a alteração e enviado para o repositório.