Italo Giurizzato Junior

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

Boa tarde Elisângela, Qual é a cidade? O provedor SimplISS possui 2 webservices. Um que segue a versão 1 do layout da ABRASF que não exige o certificado digital. O outro que segue a versão 2.03 que exige o certificado digital. Essa imagem que você anexou se refere ao arquivo ini da versão 1 do webservice utilizado pelo componente antigo, portanto esse arquivo não funciona no novo componente. No novo componente na unit SimplISS.provider na procedure TACBrNFSeProviderSimplISS.Configuracao você vai encontrar a seguinte linha: UseCertificateHTTP := False; Indicando que não se faz necessário o uso do certificado. Já na procedure TACBrNFSeProviderSimplISS203.Configuracao não tem essa linha visto que se faz necessário assinar o Rps, o Lote de Rps o o Rps ao ser enviado de forma unitário. Veja: with ConfigAssinar do begin Rps := True; LoteRps := True; RpsGerarNFSe := True; end;

Boa tarde Rogério, Vamos lá a cidade de itaquaquecetuba/SP se utiliza do provedor Ginfes. Até hoje todas as cidades atendidas pelo provedor Ginfes valor do campo ItemListaServico deve ser formatado, exemplo: 14.01, pelo jeito para a cidade em questão resolveram mudar isso. Paciência. Você consegue entrar em contato com o provedor e questionar sobre essa alteração na formatação do campo ItemListaServico? Quanto ao nome do município do tomador segundo os Schemas temos o seguinte: <xsd:complexType name="tcEndereco"> <xsd:sequence> <xsd:element name="Endereco" type="tsEndereco" minOccurs="0"/> <xsd:element name="Numero" type="tsNumeroEndereco" minOccurs="0"/> <xsd:element name="Complemento" type="tsComplementoEndereco" minOccurs="0"/> <xsd:element name="Bairro" type="tsBairro" minOccurs="0"/> <xsd:element name="CodigoMunicipio" type="tsCodigoMunicipioIbge" minOccurs="0"/> <xsd:element name="Uf" type="tsUf" minOccurs="0"/> <xsd:element name="Cep" type="tsCep" minOccurs="0"/> </xsd:sequence> </xsd:complexType> Como você pode ver não existe uma tag para constar o nome do município apenas o seu código IBGE.

Boa tarde Elisângela, O provedor até tem em seu webservice o serviço para o cancelamento da nota, uma prova disso é que ele lhe deu um retorno. O problema é que a prefeitura não aceita que o cancelamento seja realizado via webservice e sim via site.

Bom dia Elisângela, E como que fica os demais provedores que tem um layout de DANFSE diferente desse?

Boa tarde Léo, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2886

Boa tarde Leandro, O MDF-e não tem campos para informar observações, mas sim campos para colocar informações complementares do contribuinte e do Fisco. Veja: infAdic.infCpl := 'Empresa optante pelo Simples Nacional.; Caminhao VW.'; infAdic.infAdFisco := '';

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

Boa tarde, Após alterar a unit se faz necessário reinstalar o ACBr. Isso foi feito?

Olá Pessoal a SEFAZ-MG publicou um aviso que já se encontra implantando em ambiente de homologação as alterações no layout do XML que constam na NT 2022/001 e no ambiente de produção a implantação vai ocorrer no dia 11/07/2022. Segundo a NT não foi definido um dia somente o mês/Ano, ou seja, consta somente 07/2022. As demais SEFAZ podem seguir a mesma data da SEFAZ-MG ou estabelecerem outra data. Como a tag é opcional e não existe regras de validação que validem a informação, mesmo que neste primeiro momento a sua aplicação não gere a tag não terá nenhum problema fiscal. Aconselho que semanalmente realize testes para saber se a SEFAZ-Autorizadora dos seus clientes já estão aceitando a nova tag, caso afirmativo inicie a geração do XML com a referida tag. Para mais informações sobre a NT leia o tópico:

Boa tarde, Não existe nenhuma cópia de Unit do ACBr em alguma pasta do seu projeto? Analisando o XML que você que contem o erro não encontrei nada que fosse a fonte do erro. Os testes você esta fazendo com o programa exemplo do componente?

Olá Pessoal, A versão 1.10 da NT basicamente adia algumas regras de validação do Serviço de Autorização de Nota Fiscal que verificam a existência do GTIN no CCG-Cadastro Centralizado de GTIN para a maior parte dos produtos comercializados. Foram feitas algumas melhorias na documentação e, de forma mais detalhada, as mudanças desta nova versão da NT são: A. Existência do GTIN no CCG Limitada a verificação da existência do GTIN no CCG e o futuro batimento de informações contra esse cadastro de GTIN somente para a NF-e (modelo 55); Limitada a verificação da existência do GTIN no CCG nessa fase inicial somente para as operações de venda da Indústria (CFOP de Venda Produção do Estabelecimento) e para alguns grupos de mercadorias específicos. O grupo inicial de Mercadorias consta no Anexo I desta NT - Mercadorias relacionadas com a Indústria de Tabaco, Medicamentos e Brinquedos; Demais grupos de Mercadorias a serem validados serão definidos a posteriori, por novas versões dessa NT e com prazos futuros. B. Validação do NCM informado na NF-e em relação a informação do CCG (Etapa 2, RV 9I03-20) Esta validação futura será mantida, limitada agora a operação de venda da Indústria, conforme as mercadorias do Anexo I desta NT (Etapa 1: RV 9I03-10 e 9I12-10). C. Validação do CEST informado na NF-e em relação a informação do CCG Adiada a implementação da validação do CEST em relação ao CCG, sem data prevista para implementação (RV 9I03-30). D. Regras de Validação Eliminadas Eliminada a regra de validação do GTIN da Unidade Tributável em relação ao GTIN Contido informado no CCG. Motivo: existe o GTIN do Kit e este GTIN pode representar um conjunto de GTIN Contidos diferentes (RV 9I03-40). Eliminada a regra de validação do GTIN da Unidade Tributável em relação ao NCM informado no CCG. Motivo: esta verificação já é feita para o campo cEAN (RV 9I12-20). Eliminada a regra de validação do GTIN da Unidade Tributável em relação ao CEST informado no CCG. Motivo: esta verificação já é feita para o campo cEAN (RV 9I12-30). E. Diversos Correção da documentação para o código de erro da RV U01-30; A respeito da Tabela 2 valem as seguintes definições: Células com fundo verde: regras estão implementadas e seguirão implementadas, sem nenhuma alteração; Células com fundo vermelho: regras serão implementadas na etapa 2; Células com fundo bege, terão implementação em data futura, a ser definida; Todas as demais células: regras serão implementadas na etapa 1.

Você esta com todos os fontes de todas as pastas atualizados? Se sim, Reinstalou o ACBr com a opção de apagar arquivos antigos marcada? Se sim, compilou a aplicação com a opção Build?

Olá Pessoal, As alterações contidas nessa nova versão da NT não afeta em nada o componente e muito menos a sua aplicação. A seguir detalhamos melhor oque mudou: Quanto as Informações de Transporte Alterações no texto das regras X04-50, X04-60, X04-90 e X04-100. Essas alterações visam evitar rejeições em operações cuja contratação do transportador seja por conta do Remetente e a empresa contratada é uma filial do Destinatário, ou vice-versa. Quanto as Informações de Medicamentos Adiciona exceção na Regra K01-20, do grupo de medicamentos para desambiguar as diferentes exceções. Esta regra obrigava o preenchimento do grupo de Rastreabilidade de produto (tag: rastro) sempre que houvesse o preenchimento do Detalhamento Específico de Medicamentos (tag: med). No entanto, essa informação nem sempre está disponível quando envolve venda pela internet ou quando se trata da NF-e de devolução de mercadoria ou de venda para entrega futura. Remoção nas Regra K01-20 da Exceção 3 os CFOP 5116 e 6116. Outras Alterações Foi corrigida ainda a documentação das regras de validação J19-10, J20-10, J20-20 e U06-10 para adicionar o número do item, facilitando a identificação da rejeição. Sobre a Vigência Entrada em produção de TODA a NT, incluindo as alterações desta versão, fica para 12/09/2022.

Muito estranho pois acabei de realizar um teste usando o programa exemplo e tive o seguinte resultado: Método Executado: Enviar Lote Síncrono Parâmetros de Envio Numero do Lote: 27759574 Parâmetros de Retorno Data de Envio : 30/12/1899 Numero do Prot: 27759574 Numero da Nota: Link : Código Verif. : Sucesso : False Erro(s): Código : 1202 Mensagem: Prestador de Servicos nao encontrado no Cadastro Municipal (CCM).O prestador IM 20001383 nao foi encontrado. Correção: O Rps foi gerado, assinado, validado, enviado, mas foi rejeitado, mais até ai tudo bem. A questão é, não ocorreu erro ao tentar assinar.

Bom dia, Continua ocorrendo erro: Erro ao Assinar: Erro: Falha ao interpretar o XML "xmlParseDoc" ?

Bom dia, Coloquei a linha na unit do GTIN, pois na unit Base pode gerar um efeito colateral nos outros componentes. Favor atualizar os fontes, reinstale o ACBr e faça novos testes.

Bom dia, Notei que as tags: ComplementoEnderecoTomador e EmailTomador contem o caractere "-" com conteúdo. Remova, favor atribuir uma string vazia para esses campos caso não tenha a informação.

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

Bom dia Renato, Já esta no SVN.

Bom dia Gabriel, Favor atualizar os fontes, reinstale o ACBr e faça novos testes. Implementado os novos valores: retMovimentoMensal, retISSQNAutonomos e retISSQNSociedade, para o Regime Especial de Tributação.