Italo Giurizzato Junior

Boa tarde Edson, Aumente os valores de IntervaloTentativas e TimeOut. Você pode também aumentar a quantidade de tentativas através da propriedade Tentativas.

Boa tarde Luiz, É regra da SEFAZ.

Geovane, Primeiramente faça uma correção, você esta informando somente a data de emissão sendo que o correto é data e hora, veja como esta ficando o XML: <DataEmissao>2016-09-01T00:00:00</DataEmissao> Você deve estar usando a função Date passe a usar Now para alimentar o campo DataEmissao. Quanto ao erro que você postou, se é uma mensagem retornada pelo provedor isso significa que o problema é com eles. O Danilo, comprova o que estou dizendo, pois diz que no ambiente de homologação esta funcionando, somente no de produção. Sendo assim, concluo que o problema é no provedor, a solução é simples, entrar em contato com eles, expor o problema e aguardar a solução.

Bom dia Dércio, Muito estranho essa resposta do pessoal da DBSeller. Até onde sei esse provedor segue a versão 1 do layout da ABRASF, e nesse versão não existe os métodos: Gerar, EnviarLoteRpsSincrono e SubstituirNFSe. E se você analisar no schema (arquivo XSD) também não vai encontrar a estrutura do lote para envio Sincrono. A não ser que esse provedor trabalha com as duas versões e não sabemos. Se for esse o caso, vamos ter que criar um novo INI para o provedor e vamos precisar dos Schemas, das URLs de homologação e produção bem como a lista de cidades que utilizam a versão 1 e as que utilizam a versão 2.

Bom dia, Pra que? O componente ACBrNFSe já atende a cidade de Cordeiro/RJ

Bom dia a todos, Ramalho veja a assinatura do método CancelarNFSe: function TACBrNFSe.CancelarNFSe(ACodigoCancelamento, ANumeroNFSe, AMotivoCancelamento: String): Boolean; Os parâmetros são> Código do Cancelamento, Numero da NFS-e e o Motivo do Cancelamento. Você esta informando o código de verificação no lugar do código de cancelamento e isso esta errado. Para todos os provedores que seguem o layout da ABRASF seja a versão 1 ou 2, para efetuar o cancelamento de uma NFS-e basta apenas as 3 informações acima que são passadas via parâmetro do método CancelarNFSe. Mas o provedor em questão não segue o layout da ABRASF e portanto requer mais algumas informações, como por exemplo o Código de Verificação que consta no XML da NFS-e. Sendo assim para que seja possível o cancelamento é necessário carregar o XML da NFS-e e depois executar o método CancelarNFSe. Para obter o XML da NFS-e se não me falha a memória é preciso executar o método ConsultarNFSe ou ConsultarNFSePorRps.

Bom dia a todos, Vocês estão se referindo a Belo Horizonto, correto? Se sim o provedor é BHISS e o schema que é usado para validar o lote a ser enviado encontra-se em: ...\Exemplos\ACBrDFe\ACBrNFSe\Schemas\BHISS Abram o arquivo nfse.xsd usando o bloco de notas e vão encontrar o seguinte: (...) <xsd:complexType name="tcInfNfse"> <xsd:sequence> <xsd:element name="Numero" type="tsNumeroNfse" minOccurs="1" maxOccurs="1"/> <xsd:element name="CodigoVerificacao" type="tsCodigoVerificacao" minOccurs="1" maxOccurs="1"/> <xsd:element name="DataEmissao" type="xsd:dateTime" minOccurs="1" maxOccurs="1"/> <xsd:element name="IdentificacaoRps" minOccurs="0" type="tcIdentificacaoRps" maxOccurs="1"/> <xsd:element name="DataEmissaoRps" type="xsd:date" minOccurs="0" maxOccurs="1"/> <xsd:element name="NaturezaOperacao" type="tsNaturezaOperacao" minOccurs="1" maxOccurs="1"/> (...) Notem que a definição do elemento IdentificacaoRps é do tipo complexo (tcIdentificacaoRps) e em sua definição temos os elementos: Numero, Serie e Tipo. Notem também que a estrutura apresentada acima se refere as informações da NFS-e (tcinfNfse). Se antes o grupo IdentificacaoRps e o campo DataEmissaoRps não constavam no XML da NFS-e e agora consta o motivo é simples, vejam que são opcionais, antes o provedor gerava o XML da NFS-e sem essas informações e agora resolveu gerar.

Bom dia Aloísio, A versão 2.00a se refere ao componente e não tem nada haver com a versão do Documento Fiscal do MDF-e. Sim, houve uma alteração nos valores de VersaoDF, agora temos os valores ve100 e ve300. Você deve alterar a sua aplicação informando o valor ve100 e não mais ve100a. E quando for liberado e tornar obrigatório, você deverá alterar novamente para ve300.

Boa noite Walter, Essa mensagem é uma rejeição por conta do envio do CT-e para o SVC-SP ou é o retorno ao consultar o Status do Serviço?

Boa noite, Exato, caso contrario ela não precisa ser informada.

Boa tarde Adilson, Você tem o XML de retorno?

Boa tarde Ramalho, É possível você anexar o XML de pedido de cancelamento e o de retorno?

Bom, se não ocorreu atualização dos fontes do componentes e se não ocorreu também a atualização da aplicação, acredito que o problema deva ser o XML. Verifique se no XML referente a NFS-e que esta ocorrendo o erro não contem nenhum carácter especial, por exemplo: cedilha ou vogal acentuada.

Boa tarde Larry, O problema passou a ocorrer depois de alguma atualização da sua aplicação e ou atualização dos componentes? Qual Report que você usa na sua aplicação (Fast ou Fortes)?

Boa tarde ALA, Neste caso, verifique antivírus, proxy, configurações do Internet Explorer.

Bom dia, Já passei o problema para a equipe ACBr, como o campo RNTRC é opcional acredito que o ACBrMonitor Plus deve usar um outro campo para definir se vai ser gerado o grupo ou não. No meu entendimento esse campo tem que ser a placa do veiculo Tração.

Bom dia Heronim, Desculpe pela demora em responder. Segundo a documentação o provedor não possui o web services de consulta a situação. Fiz uma alteração nos fontes do componente, por favor atualize os fontes e faça novos testes.

Bom dia, As alterações foram enviadas para o repositório no dia 4 de agosto e com toda certeza a última versão do ACBrMonitor Plus já contempla essas alterações. Ficou faltando apenas atualizar o Log.

Bom dia Rafael, Simples, realize o encerramento do MDF-e que a SEFAZ acusa como não encerrado.

Bom dia Glaucos, Muito obrigado, favor atualizar os seus fontes, principalmente os INI pois eles estão desatualizados.

Bom dia ALA, O Ginfes vira e mexe ocorrem problemas, mas sempre é problema deles e não do componente.

Bom dia Walter, No próprio Branches temos uma versão inicial dos componentes ACBrANe e ACBrLMC que esta bem próximo ao padrão do Trunk2. Você pode se basear nesses outros 2 componentes para fazer os ajustes no ACBrCIOT.

Boa noite Marcos, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde ALA, Primeiramente, todos os seus fontes, inclusive os arquivos INI estão atualizados? Segundo, Ribeirão Preto até onde sei usa o Ginfes, logo acredito que o problema que você se refere é referente ao título do tópico, correto? Terceiro, Belo Horizonto não utiliza o Ginfes, sendo assim favor criar ou procurar um novo que se refere ao problema que esteja tendo com a cidade de Belo Horizonte.

Boa tarde Glaucos, Por favor anexe os arquivos alterados para que possamos avaliar e estando tudo OK enviaremos para o repositório.