JeannyPaiva

Bom dia. Realizei um ajuste quanto a leitura da tag indDeduzDeson. Como o valor padrão ao passar pela função StrToTIndicador é tiSim, quando não há informação da Tag no XML estava atribuindo este valor em vez de tiNao. pcnNFeR.pas

Boa tarde, Me deparei com um problema na leitura do XML na tag <qtdRat> do grupo infUnidTransp. Fiz a correção desta tag e mais alguns detalhes na leitura de XML que precisei tratar. Segue arquivo anexo pmdfeMDFeR.pas

Responderam aos clientes que a contingência SVC-SP está ativada (mesmo não estando com o aviso no portal do CTe). Estão emitindo atualmente nesta contingência.

Começamos a ter este problema por aqui também em várias empresas. Orientamos os clientes a entrar em contato com a SEFAZ e fazer pressão pra habilitarem a contingência até que estabilizem (ou seja por tempo indeterminado).

Creio que seja o caso de reportar à SEF de MG, porém estes dias eles estão apenas respondendo de forma automática.

Está atualizado aqui sim @Márcio B. , possivelmente você não teve o mesmo problema que nós por não utilizar o mesmo recurso de ler o XML já gerado para depois enviar. A questão eh que o tratamento de leitura da tag x geração esta incompatível. Ao ler o XML já gerado o &amp; é convertido para &. Porém ao gerar novamente o parâmetro ParseTextXML estava false. Para seguir o mesmo padrão de demais tags string fiz as seguintes alterações: Em ACBrCTe > GetURLQRCode, preencher a tag com & novamente em vez de &amp; (como já estava antes) Em pcteCTeW passar o parâmetro de ParseTextXML para True, que assim irá realizar a conversão correta dos caracteres. Esta alteração segue os mesmos padrões do comportamento de outros campos string como Nome, Endereço, etc. @Juliano Otaviano Barreto, teste novamente com essa alteração sem zerar o qrCodCTe. pcteCTeW.pas ACBrCTe.pas

Tive aqui o mesmo erro do @Juliano Otaviano Barreto. Para contornar temporariamente, após ler o XML eu apaguei a tag qrCodCTe para que assim ela fosse gerada novamente. Não fiz alterações definitivas ainda, mas pelo pouco que vi ao ler o XML já gerado com o qrCodCTe preenchido ele troca &amp; para & causando o problema na assinatura do XML.

Não temos CTe-OS aqui, apenas CTe em modal rodoviário, então não sei dizer. Mas se está com algum erro é possível que a resolução seja semelhante.

SEF MG finalmente respondeu dizendo que eles estão certos e os demais que estão errados. No manual realmente consta dessa forma Ou seja, não irão alterar. Alterei novamente a o fonte que havia enviado anteriormente apenas como teste para atender ao envio para MG e também para contingência (a versão anterior tinha atrapalhado o envio para SVC-SP). * A rejeição do envio de eventos já foi realmente corrigida. ACBrCTeWebServices.pas

Bom dia. A tag xJustMotivo no evento de Insucesso de Entrega é opcional (utilizada apenas para tpMotivo = 4). Porém no fonte ela está como ocorrência obrigatória Segue anexo correção para gerar a tag apenas quando preenchida. pcteEnvEventoCTe.pas

Por isso mesmo não coloquei como alteração sugerida, apenas informei o que foi preciso fazer para funcionar para adiantar outros aspectos da homologação. Caso outros tenham necessidade em emitir para MG para adiantar o nosso lado do desenvolvimento e realizar outras validações. Continuo enviando os relatos para a SEF/MG, e pedindo que demais façam o mesmo.

Exatamente a mesma resposta aqui @TiicTechnology Sac. Estão usando como resposta automática. rs Da última agora mandei a reclamação quanto a rejeição do evento pra ver se algo muda, mas ainda não responderam

Com as alterações do arquivo anexado consegui emitir CTe para MG. Envio de eventos respondeu, porém está retornando rejeição (628 - Rejeicao: Erro Atributo ID do evento nao corresponde a concatenacao dos campos (ID + tpEvento + chCTe + nSeqEvento)). Acredito que estejam validando incorretamente de acordo com a regra dos eventos da versão 3.0 com a sequencia de apenas 2 dígitos. O último retorno da SEF/MG foi um não retorno. ACBrCTeWebServices.pas

Obrigada @Scott pela informação. Fiz um teste realizando a alteração sugerida e consegui autorizar um CTe pelo menos em MG. Vou verificar e testar nos demais serviços, e tentar novamente contato pelo Fale Conosco sugerindo a padronização, e/ou ajuste nos fontes aqui do ACBr enquanto eles continuam nos causando problemas.

Nada ainda em MG, o mesmo erro continua, e até o momento sem respostas do Fale Conosco. Sugiro que demais devs/empresas de MG também entrem em contato e caso tenham alguma resposta satisfatória, compartilhar com os demais aqui.

Boa tarde. Tivemos recentemente rejeição no envio de GNRE para receita 100110 (A receita '10011-0' exige contribuintes inscritos! Favor informar a Inscricao Estadual do Emitente.) Ao realizar os ajustes para envio da IE da UF favorecida nos deparamos com a seguinte orientação quanto ao preenchimento da GNRE para envio de Inscrição estadual: Contribuinte Emitente - Se o contribuinte tiver inscrição da UF Favorecida, preencher apenas o campo 'Inscrição Estadual', caso contrário, preencher os demais campos que correspondem ao Contribuinte Emitente. Dados relacionados ao contribuinte emitente: - Inscrição Estadual - Corresponde a inscrição estadual na UF favorecida. ou - CNPJ/CPF - Corresponde à Identificação do Contribuinte/Empresa responsável pelo fornecimento de mercadorias/produtos. Informar CNPJ quando se tratar de pagamento efetuado por pessoa jurídica, ou CPF quando se tratar de pagamento efetuado por pessoa física. - Razão Social - Corresponde ao nome da Razão Social do contribuinte. - Endereço - Corresponde ao endereço completo empresa do contribuinte (logradouro, número, bairro e complemento do endereço do contribuinte). - UF - Corresponde a UF da empresa do contribuinte. - Município - Corresponde ao município empresa do contribuinte. Selecione primeiro a UF do contribuinte emitente para habilitar este campo. - CEP - Corresponde ao CEP da empresa do contribuinte. - Telefone - Corresponde ao código DDD (2 dígitos) e número do telefone do contribuinte (8 dígitos). https://www.gnre.pe.gov.br:444/gnre/portal/ajuda.jsp Porém o preenchimento da IE estava condicionada ao preenchimento do campo de identificação do emitente (CNPJ). Foi necessário ajuste para permitir envio apenas da IE sem demais informações. Segue arquivo anexado. pgnreGNREW.pas

Boa tarde @Italo Giurizzato Junior, Parece que entramos no clássico problema de conserta para um e atrapalha para outro. O mesmo provedor (SH3) que é utilizado para São João Del Rey, é utilizado em São Geraldo e Visconde do Rio Branco, porém está retornando de forma diferente. De acordo com os arquivos acima anexados. SJDR = > nfseDadosMsg SG e VRB = > outputXML Logo, quando foi realizada a ultima correção, SG e VRB parou de funcionar. Para tentar sanar o problema realizei as seguintes alterações nos arquivos que seguem para avaliação: 1 - No arquivo ACBrNFSeXServicos.ini adicionei um parâmetro para identificar qual a tag de resposta ==> Params=ResponseTag:outputXML 2 - Em SH3.Provider ler buscar a informação do parâmetro "ResponseTag" para realizar a leitura do XML. @alfadesign, se possível testes para SJDR com estes fontes para ver se soluciona o problema para todos. * No arquivo ACBrNFSeXServicos.ini inclui apenas para as cidades citadas acima, seria necessário outros que utilizam este mesmo provedor identificar como ocorre o retorno em suas cidades. **Optei por responder no mesmo tópico em vez de abrir novo pois aparentemente foi aqui que gerou a ultima alteração. Exemplo-SG-188-lista-nfse-ger-soap.xml SH3.Provider.pas ACBrNFSeXServicos.ini

Boa tarde. Foi realizado um ajuste para possibilitar ler XML de retorno da consulta por Faixa do provedor SH3. Segue fonte e XML de exemplo 202300000000008202300000000010000001-lista-nfse-fai-soap.xml SH3.Provider.pas

Boa tarde. Passou a ocorrer, após esta alteração, falha ao ler o XML de retorno em ConsultarNFSeporRps. Mesmo sendo o mesmo provedor SH3 parece que tem variado o retorno. No exemplo acima ele retorna com a tag nfseDadosMsg. Porém aqui, para a cidade de São Geraldo retorna a tag outputXML. Realizei a correção nos meus fontes para resolver, mas creio que possa ter empasses semelhantes em outras cidades. Como poderíamos tratar essa divergência ? *Segue arquivo de exemplo e alteração. 30540-comp-nfse-soap.xml SH3.Provider.pas

Bom dia. Foi necessário a realização de um ajuste para o provedor EL no tratamento da tag IssRetido. Segue em anexo. EL.Provider.pas

Boa tarde. Precisar realizar algumas alterações para o provedor EL, utilizado por Linhares, e um ajuste para o envio de RPS (geral). EL: - Formatação de Alíquota - Identificação do XML carregado (NFSe ou RPS) - Ajuste de informações de retorno de erros - Ajuste na leitura de XML de retorno de consultas e cancelamento. RPS: - Ao ler XML de RPS estava carregando a informação de data para a propriedade DataEmissaoRps, porém ao Gerar novamente o XML estava passando a propriedade DataEmissao, que no caso chegava com Zero. ACBrNFSeXGravarXml_ABRASFv2.pas EL.LerXml.pas EL.Provider.pas EL.GravarXml.pas

Boa tarde. Obrigada.

Boa tarde. Foi necessário ajustar o retorno de XML do Provedor SH3 após as últimas atualizações. Segue unit alterada. SH3.Provider.pas

Bom dia. Tive um problema semelhante ao atualizar o componente (de apresentar o retorno vazio), porém vi que o problema estava no momento de interpretar o retorno. Em testes com os provedores SH3 e VersaTecnologia, ao debugar apenas identifiquei que apresentava "Range Check Error", na unit ACBrXmlBase, TipoEncoding. Realizei a alteração na função e resolvi aqui o problema. Pode ser o mesmo caso com o XML retornado pelo Betha ACBrXmlBase.pas

As URLs de contingência SVC quando enviadas de MG está sendo validada fora do padrão dos demais estados. Para contornar, aqui eu utilizo arquivo ACBrCTeServicos.ini diferente para MG dos demais estados. Para homologação [CTe_SVC-SP_H] URL-QRCode=https://hcte.fazenda.mg.gov.br/portalcte/sistema/qrcode.xhtml