Italo Giurizzato Junior

Boa tarde Dércio, No arquivo DBSeller.ini favor fazer uma alteração: de: [Geral] VersaoSoap=1.1 (...) UseCertificado=1 para: [Geral] VersaoSoap=1.1 (...) UseCertificado=0 Faça novos testes, não esqueça de informar o numero de série do certificado. Essa alteração não significa que não seja necessário o uso do certificado e sim tentar eliminar a mensagem de erro que apareceu.

Boa tarde Ramalho, Configure o componente para salvar os arquivos de envio e de retorno: Configuracoes.Geral.Salvar := True Configuracoes.WebServices.Salvar := True; Faça um novo teste de cancelamento e anexe os arquivos de envio e retorno gerados ao solicitar o cancelamento. Note que vão ser gerados 4 arquivos XMLs sendo que 2 deles tem a palavra soap no nome. Anexe os 4 arquivos.

Boa tarde Dércio, Quem te atendeu de manhã foi o Estagiário Jr e a tarde foi o Estagiário Pleno. rsrsrsr

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.