Italo Giurizzato Junior

Bom dia a todos, Já enviei para o repositório as inclusões das novas cidades.

Bom dia André, Favor atualizar os fontes e faça novos testes.

Vou fechar este aqui.

Bom dia Rafael, Desde de ontem temos recebido relatos sobre esse problema. A solução que o pessoal encontrou foi emitir o CT-e via SVC-RS (SEFAZ-Virtual de Contingência do Rio Grande do Sul).

Boa tarde, Muito obrigado pela colaboração já inclui na minha lista de tarefas.

Boa tarde Douglas, Como você não anexou nenhum XML para pudéssemos fazer testes, gerei um XML e usando os seus fontes o quadro permaneceu do mesmo tamanho. Acredito que você deva ter anexado a unit errada, ou seja, sem todas as alterações que você promoveu nela.

Boa tarde a todos, Só faria sentido somar 366 dias se 2021 fosse bissexto, mas não é, o próximo ano bissexto será 2024. Logo realmente existe um bug na SEFAZ-Autorizadora e na SEFAZ-Virtual do Rio Grande do Sul, uma vez que a maioria dos BP-e são recepcionados por ela. Com certeza a SEFAZ-MG copiou o webservice da SV-RS com o bug.

Bom dia Felipe, As alterações que fiz é para ele separar do retorno a NFSe Substituidora e ler os dados da mesma. É preciso colocar um ponto de parada na primeira linha da function TRetornoNFSe.LerXml (da unit pnfsLerListaNFSe) e fazer um debug para saber o porque ele não esta separando o XML da nota de forma correta. Com base nos seus XMLs anteriores fiz essa alteração, pode ser que algo tenha passado em branco. Infelizmente não tenho como realizar esse debug.

Bom dia João, Se você coloca a URL diretamente no navegador, isso não tem nada haver com os dados e nem com os schemas. Outra coisa, não existe os schemas do eFrete. Por favor faça os testes com o programa exemplo, configure ele corretamente. Uma informação importante, para usar o webservice do eFrete se faz necessário realizar um cadastro como desenvolvedor.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia Thiago, Se a URL da versão ocorre o erro 404 isso significa que ela não existe. É bem provável que a cidade em questão migrou da versão 1 para a 2, sendo assim experimente mudar no arquivo Cidades.ini o nome do provedor de WebISS para WebISSv2. Depois faça os testes.

Bom dia Ornei, Se tratando da SEFAZ-MG tudo é possível, faz anos que eles lidam com a NF-e e não aprenderam nada e olhe que a NFC-e nada mais é que a NF-e com uma informação diferente, ou seja, o modelo do documento fiscal. Com certeza é alguma kaka que eles fizeram.

Bom dia Luiz, Você diz que em a diferença entre as classes é uma letra que em uma é minúscula e na outra é maiúscula, correto? Essa diferença se encontra no nome de alguma tag a ser gerada? Se sim, então é por isso que a classe foi incluída 2x, por conta dessa diferença. O pessoal responsável pelo layout do XML do eSocial não tiveram a capacidade de perceber isso, paciência. Sobra para nós ficar contornando esses problemas.

Bom dia João, Você poderia anexar os arquivos INI que você alterou para que eu possa analisar essa alteração, pois analisando o arquivo VersaTecnologia não se faz necessário nenhuma alteração.

Bom dia André, Você sabe informar qual é o erro de conversão que ocorre? Seria interessante debugar para saber exatamente em qual linha do componente ocorrer esse erro. Esse erro de conversão ocorre ao tratar o retorno do envio?

Bom dia Artur, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.

Bom dia Juliomar, O Sandro anexou uma contribuição em Fast Report veja mais acima (22/09/2020). Inclusive inclui na lista de tarefas (TK-1420).

Bom dia a todos, Se olharem na pasta: ..\Exemplos\ACBrDFe\Schemas vão notar que não existe uma pasta para o CIOT. O componente ACBrCIOT simplesmente gera o XML e envia para o webservice, caso seja informado algo errado por exemplo: um dado que deveria ter um tamanho X e foi colocado com tamanho Y o webservice vai recusar. Reze para que ao recusar retorne um motivo claro do porque da recusa. Se o eFrete publicasse os Schemas seria possível identificar o problema antes do envio ao realizar a validação.

Boa tarde Everto, Não sou eu que cuido das impressões em Fast Report, acredito que quem cuida ainda não conseguiu um tempo para analisar a colaboração e disponibilizar no repositório. Sendo assim, a única opção disponível é o que foi feito em EscPos.

Boa tarde João, Isso depende muito da empresa a ser utilizada. O componente ACBrCIOT se utiliza do eFrete e este não disponibilizou os schemas.

Leonardo, Existe uma diferença muito grande entre as duas formas de alimentar o componente. A que você pretendia utilizar gera um grupo <Servicos> e dentro dele vários grupo <Servico> e dentro desse grupo podemos informar quantidade, descrição, valor unitário etc. No caso do provedor Betha é colocado tudo dentro de um único campo chamado Discriminacao. O provedor Betha adotou para esse campo uma formatação que é só deles, pois a principio esse campo é para você apenas descrever de forma mais clara o serviço que foi executado. O Juliomar disse que esta trabalhando no DANFSE feito em Fast Report, depois vamos aplica a mesma solução para o DANFSE feito em Fortes Report.

Boa tarde Marco, Em vez de você passar o caminho: /Servidor/Schemas/MDFe Porque você não faz um mapeamento e passa somente a letra da unidade mapeada?

Boa tarde Leonardo, E quem disse a você que o provedor Betha permite informar mais de um serviço? O provedor Betha possui 2 webservices, um deles segue a versão 1 e o outro a versão 2 do layout da ABRASF. O que o Betha fez e foi só na versão 1, foi incluir um grupo de condições de pagamento e as respectivas parcelas, grupo este que não existe no layout da ABRASF. No schema da versão 1 temos: (...) <xs:element name="RpsSubstituido" type="tipos:tcIdentificacaoRps" minOccurs="0" maxOccurs="1" /> <xs:element name="Servico" type="tipos:TcDadosServico" minOccurs="1" maxOccurs="1" /> <xs:element name="Prestador" type="tipos:tcIdentificacaoPrestador" minOccurs="1" maxOccurs="1" /> (...) <xs:complexType name="TcDadosServico"> <xs:annotation> <xs:documentation>Representa dados que compõem o serviço prestado</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="Valores" type="tipos:TcValores" minOccurs="1" maxOccurs="1" /> <xs:element name="ItemListaServico" type="tipos:tsItemListaServico" minOccurs="1" maxOccurs="1" /> <xs:element name="CodigoCnae" type="tipos:TsCodigoCnae" minOccurs="0" maxOccurs="1" /> <xs:element name="CodigoTributacaoMunicipio" type="tipos:tsCodigoTributacao" minOccurs="0" maxOccurs="1" /> <xs:element name="Discriminacao" type="tipos:tsDiscriminacao" minOccurs="1" maxOccurs="1" /> <xs:element name="CodigoMunicipio" type="tipos:tsCodigoMunicipioIbge" minOccurs="1" maxOccurs="1" /> </xs:sequence> </xs:complexType> Como você pode ver o grupo <Servico> tem ocorrência máxima igual a 1, isso significa que esse grupo só pode aparecer no XML apenas uma vez, note também que os campos que compõe esse grupo são todos do tipo simples com exceção do <Valores> que é um grupo e também tem quantidade máxima de ocorrências igual a 1. Você pode também checar no schema da versão 2 e vai constatar que o que é a mesma coisa. Resumindo, se no schema não temos a possibilidade de informar mais de uma serviço, não devemos alimentar o componente da forma que você esta fazendo. A possibilidade de fazer o que você quer esta presente e um ou outro provedor, mas você não pode utiliza-lo, uma vez que a cidade em questão se utiliza do provedor Betha (versão 1 do layout da ABRASF).

Felipe, Enviei para o repositório uma possível correção, favor atualizar tudo e faça novos testes.

Bom dia Renato, Já esta no repositório.