arce

Amigos O Bug era causado pelo wsdlImporter do D7. Para solucionar o problema é necessário atualizar algumas bibliotecas SOAP, que vcs podem baixar através deste link (http://cc.embarcadero.com/item/24535). Depois é só recriar a unit pelo WSDLImporter. Abraço

Boa tarde A prefeitura está alterando o ws deles de php para C# (Entra em produção dia 02/05). Este é novo link de homologação (http://desenvolvimento.bauru.sp.gov.br/teste5/Default.asmx?wsdl). Contudo as estruturas dos objetos de envio e retorno foram alteradas. Ao utilizar o wsdl importer no Delphi7 a estrutura mudou mto pouco, mas ao enviar ocorre um erro de Objeto, pois o mesmo não era construído no processo de envio da NFSe. Fiz um teste utilizando o wsdl importer no Delphi XE Berlin, e a estrutura ficou totalmente diferente. Exemplo no Delphi7: procedure GerarNota(const DescricaoRps: tcDescricaoRps; out GerarNotaResult: tcRetornoNota; out DescricaoErros: ArrayOfTcEstruturaDescricaoErros); stdcall; Exemplo no Delphi XE Berlin function GerarNota(const parameters: GerarNota): GerarNotaResponse; stdcall; Então, passei a unit criada pelo XE para o projeto do Delphi 7, fiz as alterações dos uses para compilar e parou de ocorrer o problema do objeto não criado. Entretanto o objeto de retorno GerarNotaResponse está retornando vazio. Gostaria de saber se vcs estão passando pelo mesmo problema que eu. OBS: Fiz testes com o programa SoapUI que envia e recebe diretamente o XML e funcionou.

Sim, para importação e exportação essas tags não são preenchidas. Porém as demais informações da nfe mostram que a operação é interna

Neste caso a NFe consta como operação de Venda dentro do estado para Consumidor Final. A SEFAZ ainda não deve fazer o cruzamento o campo idEstrangeiro com Operação Interna/CFOP.

Pelo que li e verifiquei com um contador. Apenas o modelo 65 permite a emissão sem o CPF/CNPJ, porém além desta NFe já vi outras que meus clientes receberam de seus fornecedores.

Boa tarde No fim do ano passado um cliente conseguiu emitir NFe modelo 55 sem constar o CNPJ/CPF do destinatário. Fui refazer o teste de envio e não consegui, está retornando a rejeição 208 . O ACBr no caso está carregando a tag CNPJ dessa forma 00000000000000. Segue o XML em produção emitido pelo cliente no fim do ano passado, percebam que a tag IDEstrangeiro foi carregada e está vazia. Queria saber se isto está correto. Até onde sei apenas o modelo 65 é possível emitir sem a identificação do destinatário. XML_sem_CPFCNPJDest.xml

O ACBr da versão do meu sistema é de uma versão de Agosto de 2016. Porém o erro só acontece com este certificado da CAXA

Tem outra questão, que não descrevi. O Emitente é do SIMPLES NACIONAL, assim ele não pode utilizar o grupo ICMSST (Grupo de repasse do ICMS-ST) pq este aceita apenas CST 41.

Bom dia Um cliente emitente do estado de SP está vendendo mercadoria para um destinatário "não-inscrito no RS". Sendo que o produto possui ST, e segundo a informação passada pela SEFAZ-RS é necessária calcular o "DÉBITO DE ICMS ST" e emitir GNRE. Segue o exemplo do calculo passado pela SEFAZ-RS Desta forma, o emitente fabricante terá que recolher, neste exemplo, via GNRE, o valor de R$ 661,24 para o Estado do Rio Grande Sul, pagando este montante no momento da saída da mercadoria do seu estabelecimento industrial. Existem dois grupos relacionados a partilha: ICMSUFDest e ICMSPart, neste caso qual dos dois devo destacar na NFe? obs: Não foi possível anexar o PDF ao post

Boa tarde O SAT eu consegui ativar. O problema no meu caso está no processo de AssociarAssinatura.

Boa tarde Você conseguiu resolver este problema? Pelo LinkerManager consigo AssociarAssinatura, porém pelo meu sistema e tbm pelo Demo do ACBr retorna "Erro na comunicação com o SEFAZ". Trouxe o equipamento para o escritório para ter certeza de que não era alguma interferência da rede.

Boa tarde Aconteceu duas vezes nesse mês em clientes distintos e me gerou mta preocupação. Estou utilizando o layout 2.0 do CTe para UF SP (ainda não fiz a migração para o 3.0) Ao enviar o CTe as tags de retorno da sefaz estavam em branco. Como guardo a informação da chave antes do envio, consultei a chave de acesso gerada no portal da receita e o CTe constava autorizado (35161209121733000159570010000012811129126469), ao visualizar os dados do documento no site perceba que a chave q consta no mesmo é diferente (35161209121733000159570010000012811189983112 anexo) ao consultar esta última chave o conteúdo do CTe é igual da chave anterior. Consultei ambas as chaves de acesso no portal estadual de SP e somente a chave 35161209121733000159570010000012811189983112 consta. Realizei o download do XML no portal e vinculei ao meu sistema, ao consultar o status do CTe retorna a rejeição 217 - "CTe não consta na base de dados da SEFAZ”. Na tentativa de buscar a chave correta, reenviei a mesma numeração/série crente que retornaria a rejeição 539 com a chave correta, e isto não ocorreu. Lendo a NT 2016_001 encontrei este trecho na página 4: Não estou conseguindo entender o que pode ter acontecido. 35161209121733000159570010000012811189983112.xml

Bom dia Todos os clientes que apresentaram o problema, após a atualização da DLL da Elgin resolveu, estão em produção com a nova versão a mais de um mês sem falhas de timeout.

Um de meus clientes, enviou 5 CTes na semana passada e o mesmo não teve retorno algum. Reenviei para que retornassem a rejeição "539 - Duplicidade" mas sem sucesso. Tentei inutilizar a numeração e retornou a rejeição que a "numero da faixa já foi utilizado". E durante o processo nao foi gravado a chave de acesso para pesquisar no portal da sefaz. Não teria correlação com a mudança da tag citada? Para buscar as informações do retorno uso o comando "ACBrCTe1.WebServices.Retorno.CTeRetorno.ProtCTe.Items.(tag)" O estranho é que enviei outros posteriores a esses e tive o retorno correto.

Um cliente adquiriu um certificado da CAIXA (não recomendo para ninguém por muitos motivos) e este apresentou as mesmas características descritas pelo @CertaSolucoes, a propriedade ACBrNFe1.SSL.CertCNPJ retorna o CPF do responsável. As nfes foram transmitidas corretamente, porém uso a propriedade citada para uma validação que compara o CNPJ do certificado selecionado com o CNPJ do emitente. Existe a possibilidade nesses casos de retornar o CNPJ e não o CPF na propriedade ACBrNFe1.SSL.CertCNPJ?

Fontes->ACBrDFe->ACBrNFSe->PCNNFSe pnfsNFSeR.pas

Bom dia @Italo Jurisato Junior o servidor Fiorilli também é necessário fazer uma alteração em relação ao ISS Retido. Na unit pnfsNFSeR nos métodos TNFSeR.LerNFSe_ABRASF_V2 e TNFSeR.LerRPS_ABRASF_V2, acrescentar o provedor Fiorilli na condição descrita abaixo. if (FProvedor in [proISSe, proVersaTecnologia, proNEAInformatica, proFiorilli]) then begin if NFSe.Servico.Valores.IssRetido = stRetencao then NFSe.Servico.Valores.ValorIssRetido := Leitor.rCampo(tcDe2, 'ValorIss') else NFSe.Servico.Valores.ValorIssRetido := 0; end else NFSe.Servico.Valores.ValorIssRetido := Leitor.rCampo(tcDe2, 'ValorIssRetido');

Consegui transmitir sem alterar nada no código de transmissão, certamente foi uma infeliz coincidência com a instabilidade da SEFAZ

Boa tarde Vou migrar para versão 3.0 do CTe apenas no começo do ano que vem. Porém hoje fui realizar uma emissão em ambiente de homologação com o layout 2.0 e não obtive retorno na consulta do recibo do lote. Segundo a NTCTe_2016_001 a entrada do novo layout ocorreu em 01/11/2016, minha dúvida é, o ambiente de homologação só aceitará CTes na versão 3.0?

@tlucasgoes eu troquei as UFs e urls e não funcionou

Também entraram em contato comigo, já está em produção.

Dimep OK, a Elgin ainda estamos aguardando a liberação da nova versão da DLL

@Riquena Não tive problemas exclusivamente com cancelamento. No meu caso qndo acontece o TimeOut a aplicação não consegue efetuar quaisquer outras operações (Consulta, TesteFimaFIM, StatusOperacional, etc), até q se reinicie o aparelho.

Bom dia Reportei para a equipe de desenvolvimento da Elgin a situação e também a solução da DIMEP descrita pelo @JSantos . Eles repassaram para a engenharia e como utilizam o mesmo OEM da DIMEP provavelmente disponibilizarão uma nova versão da DLL. Assim que tiver um retorno, reporto aqui no post

Bom dia, a falha voltou a acontecer, segue os logs para análise. A Sessão que ocorreu o erro é a 100062 elgin2.txt logACBr_04102016.rar Log_ELGIN SAT_05102016.rar