arce
-
Total de ítens
490 -
Registro em
-
Última visita
-
Days Won
3
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por arce
-
-
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.
-
Em 29/03/2017 at 18:32, 3Soft Sistemas disse:
Arce pah teu contador não está correto.
Notas de Importação/exportação não tem tag de cpf/cnpj preenchidas.
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
-
1 hora atrás, BigWings disse:
<indFinal>1</indFinal>
Não acho que esteja correto. mas caso informe que é consumidor final, ela não é rejeitada se não informar a identificação.
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.
-
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.
Citar20170110151204|SAT-AC|info|nvl 2:(AssociarAssinatura) mensagem enviada
20170110151749|AC-SAT|info|nvl 2:(AssociarAssinatura) mensagem recebida
20170110151749|SAT-SEFAZ|info|nvl 2:(CFeSign):0.07 acessado o webservice https://wssatsp.fazenda.sp.gov.br/CfeSignAC/CfeSignAC.asmx
20170110151750|SEFAZ-SAT|erro|nvl 0:(CFeSign) diagnostico SOAP: codigo interno: 400400
20170110151750|SEFAZ-SAT|erro|nvl 0:(CFeSign) diagnostico SOAP: motivo: HTTP Error
20170110151750|SAT-SEFAZ|info|nvl 2:(CFeSign):0.07 acessado o webservice https://wssatsp.fazenda.sp.gov.br/CfeSignAC/CfeSignAC.asmx
20170110151751|SEFAZ-SAT|erro|nvl 0:(CFeSign) diagnostico SOAP: codigo interno: 400400
20170110151751|SEFAZ-SAT|erro|nvl 0:(CFeSign) diagnostico SOAP: motivo: HTTP Error
20170110151751|SAT-SEFAZ|info|nvl 2:(CFeSign):0.07 acessado o webservice https://wssatsp.fazenda.sp.gov.br/CfeSignAC/CfeSignAC.asmx
20170110151753|SEFAZ-SAT|erro|nvl 0:(CFeSign) diagnostico SOAP: codigo interno: 400400
20170110151753|SEFAZ-SAT|erro|nvl 0:(CFeSign) diagnostico SOAP: motivo: HTTP Error
20170110151753|SAT-SEFAZ|erro|nvl 0:(CFeSign) falha de comunicacao com a SEFAZ
20170110151753|SAT-AC|erro|nvl 1:(AssociarAssinatura) falha na vinculacao da assinatura do AC (13002|Erro de comunicação com a SEFAZ) -
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:
Citar9. Padronização do retorno em regras de validação (facultativo) Deverá ser retornada a informação do número de protocolo e data em complemento às rejeições 539, 204, 218, 205, 674, 673, 672, 671 na versão 2.00, da mesma forma que estabelecido no MOC da versão 3.00.
Não estou conseguindo entender o que pode ter acontecido.
-
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.
-
1
-
-
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
-
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');
-
8 horas atrás, Italo Jurisato Junior disse:
Boa noite arce,
Que eu saiba a SEFAZ-SP estava passando por problemas.
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
-
22 horas atrás, Jose Marcelo Pereira disse:
Bom dia.
Hoje a Elgin me retornou um e-mail com a dll, segundo eles, atualizada.
Segue anexo.
Também entraram em contato comigo, já está em produção.
-
1
-
-
22 horas atrás, Renato Chiari disse:
Bom dia
Também estamos enfrentando este problema com os Elgin e Dimep.
O problema foi solucionado com a atualização da dll da Dimep? E alguma novidade quanto a Elgin?
Obrigado!
Dimep OK, a Elgin ainda estamos aguardando a liberação da nova versão da DLL
-
1
-
-
@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
Nfse Bauru - Sigcorp
em ACBrNFSe
Postado
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