cleyton44
-
Total de ítens
81 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por cleyton44
-
-
Bom dia Italo,
Sim o CNPJ é exatamente o mesmo do Prestador da prefeitura.
Já tentei das duas formas, formatado e sem formatação.
Segundo dados da ficha CAE e da Certidao Negativa da prefeitura são dados sem formatação. Já internamente no provedor não sei responder.
Continuarei buscando a solução e caso tenha sucesso posto aqui.
grato
Cleyton Luiz
Nobre Sistemas
-
1
-
-
Ainda não consegui resolver, dei um tempo e agora estou retomando. Segue abaixo a resposta do suporte do provedor de goiania:
"
Boa tarde,
Existiram casos de contribuintes que armazenaram o certificados de vários prestadores em um servidor. A aplicação selecionava um outro certificado e ele nos garantia que não. Depois de muito tempo constatou que este era o problema. Talvez isso possa te ajudar.
Erros de assinatura não podem ser verificados por este suporte visto que dependem do Certificado Digital. Este suporte não pode ter acesso ao Certificado Digital de Prestadores por questão de segurança. Reveja a implementação da sua assinatura eletrônica."Fiz testes com o programa de exemplo, sabe-se que o componente não assina se o certificado estiver incorreto.Seguem os xml de envio e retorno, peço ajuda dos mais experientes no ambiente de Goiania. Esgotei minhas alternativas.GratoCleyton Luiz AlbertiNobre Sistemas -
Prezados boa tarde, estou com dificuldades na transmissão da NFE 4.0 no Ceará.
Não uso o arquivo AcbrNfeServicos.ini para configurar as URLs já que o componente sempre supriu esta necessidade.
Notei que os erros estão relacionados a URL, segue imagens da inspeção das variáveis.
É aconselhável que eu passe a usar o arquivo INI?
Grato pela ajuda,
Cleyton Luiz Alberti
-
15 horas atrás, Italo Jurisato Junior disse:
Cleyton,
Porque que você copia os dados do emitente do CT-e no grupo Expedidor e os dados do Destinatário no grupo Recebedor?
Sendo que os grupo Expedidor e Recebedor só são utilizados quando o tipo do serviço for 2 = Redespacho ou 3 = Redespacho Intermediário.
Quanto o tipo do serviço for 0 = Normal devemos apenas informar o Emitente da CT-e, o Remetente da Carga e o Destinatário da mesma.
Veja este link:
http://www.ophos.com.br/publicacoes/detalhe/ct-e-de-redespacho/
Será que essas rejeições não estão sendo geradas por conta de informar indevidamente os grupos Expedidor e Recebedor?
Bom dia Italo, retirei os grupos conforme sua indicação, mas a rejeição persistiu.
Notei que o Colega ricardojr teve o mesmo entendimento e que o componente foi corrigido.
Obrigado a todos
.
Cleyton Luiz Alberti
Nobre Sistemas
-
1
-
-
Vou verificar o porquê destes grupos estarem sendo enviados, pois recebo o xml montado, importo no AcbrCte e transmito.
Farei os devidos testes e te informo.
Grato
Cleyton Luiz Alberti
Nobre Sistemas
-
Boa noite Italo, realmente a minha interpretação sempre foi essa, porém na NT anexada neste post, na página 2 diz que agora é permitido, tive duas rejeições na tarde de hoje,
(232) Rejeicao: IE do destinatario nao informada (MS),
e
(999) Erro nao catalogado. [Det: IE do destinatario nao informada] (PR),
no caso, para fins de tributação no nosso sistema o destinatário é tratado como não contribuinte
(é o setor fiscal do meu cliente que define isso, mesmo que o destinatário tenha IE ativa na UF) então eu passo indIeToma = 9 (já que toma3 = 3).
após a alteração que fiz na Unit (pcteCTeW.pas) a sefaz aceitou os dois CTEs, seguem os xmls para sua apreciação.
não guardei os XMls rejeitados porém a unica diferença é a ausência da tag dest/IE.
Grato pela atenção dispensada.
Cleyton Luiz Alberti
Nobre Sistemas
-
Boa tarde, estou tendo vários problemas no CTE 3.0 desde o dia 15/01/18 com rejeição, quando o tomador está classificado como Não Contribuinte e sua respectiva tag (rem, dest, exped ou receb) é enviada sem a Inscrição Estadual, notei que o componente limpa a IE nestes casos, creio (me corrija por favor) que a SEFAZ está validando se há IE ativa e está retornando (718) Rejeição: IE do Recebedor não informada ou (232) Rejeição: IE do destinatario nao informada ou (719) Rejeição: IE do Tomador não informada ou (716) Rejeicao: IE do Remetente nao informada.
Comentei alguns trechos do código em pcteCTEw.pas para enviar a IE caso haja, mesmo sendo indieToma = 9.
por favor veja se esta é a melhor solução ou se eu deveria tratar isto de outra forma.
Grato
Cleyton Luiz Alberti
Nobre Sistemas
-
Sim, exatamente desta forma. :/
Cleyton
-
Italo,
Já chequei o certificado, o cnpj da NFSe, o site da prefeitura...
Grato
Cleyton
-
-
Senhores,
Estou tentando gerar NFSe pra goiânia e está retornando o seguinte erro:
"CPF ou CNPJ da assinatura digital nao confere com o CPF ou CNPJ do prestador dos servicos.
Para assinar o arquivo digital, utilize uma assinatura autorizada"Eu já verifiquei o CNPJ que está no certificado, o CNPJ que está no XML e também o CNPJ que está cadastrado na prefeitura.
Alguém tem uma luz?
Grato
-
48 minutos atrás, BigWings disse:
Já existe tópico sobre esse erro específico:
Obrigado
-
Boa Tarde estou precisando de uma ajudinha, não compreendo porque da rejeição na SEFAZ de SP
"Rejeição: Carta de correção inválida (campo/grupo [Object reference not set to an instance of an object.] informado não existe no schema do CT-e ou não existe no grupo informado)"
Tentei passar zero em nroItemAlterado mas o componente limpa, mexi no componente para não limpar, dai então a validação do schema rejeita.
Grato
Cleyton
PS: Em Anexo o CTE original.
No Paraná transmiti Carta 3.00 para corrigir CTE 2.00 normalmente.
-
3 horas atrás, cleyton44 disse:
Vou tentar reproduzir, obrigado.
Bom dia, após analisar o exemplo ACBR_CTe, identifiquei que o modo de assinatura esta como "openssl" eu usava capicom, modifiquei meu transmissor e o erro de assinatura foi sanado, curioso é que os CTEs 3.00 continuo assinando e transmitindo com a dll capicom.
Mesmo resolvendo o problema, fiquei com dúvida na questão de assinatura do CTE 3.00, qual conjunto de DLLs é o indicado?
Obrigado
Cleyton Luiz
-
Em 01/12/2017 at 17:51, José M. S. Junior disse:
Boa tarde, consegue reproduzir o erro utilizando o Demo do ACBr_CTe?
Vou tentar reproduzir, obrigado.
-
Estou com um problema parecido só que a rejeição é "(298) Assinatura difere do padrao do Projeto", peço ajuda pois não estou enxergando o erro.
Grato
Cleyton Luiz
-
3 minutos atrás, Italo Jurisato Junior disse:
Boa noite Cleyton,
Por favor anexe a unit alterada para que possamos analisar.
OK segue.
-
Boa noite, implementei a Distribuição DFE para NFe e para CTE esta semana e reparei que o campo "vNF" de WebServices.DistribuicaoDFe.retDistDFeInt.docZip[wi_I].resCTe.vNF vinha sempre zerado, resolvi investigar o código do componente e reparei que na linha 496 da unit "pcteRetDistDFeInt.pas" havia um comentário de código.
Removi o comentário das duas ultimas linhas e alterei as tags da seguinte forma
(*
FdocZip.Items.FresCTe.FtpNF := StrToTpNF(ok, oLeitorInfZip.rCampo(tcStr, 'tpNF'));
*)oLeitorInfZip.rExtrai(1, 'vPrest');
FdocZip.Items.FresCTe.FvNF := oLeitorInfZip.rCampo(tcDe2, 'vTPrest');
e agora o valor de "vNF" passou a popular corretamente.
Não sei se aqui é o canal correto para esta colaboração, se não for peço instruções de como enviar esta pequena correção.
Cleyton Luiz
-
Em 08/04/2017 at 12:31, Italo Jurisato Junior disse:
Boa tarde Otair,
Onde você alterou?
É preciso descobrir de onde vem vindo essa versão.
Você não colocou Schemas da NF-e e do CT-e na mesma pasta, colocou?
Se sim, é preciso separar pois o nome do Schema de DistribuicaoDFe da NF-e tem o mesmo nome que do CT-e a unica coisa que muda é o final que contem a versão.
Da NF-e o nome é distDFeInt_v1.01 e do CT-e é distDFeInt_v1.00, se você configurar o componente ACBrCTe com a versão 2.00 ou 3.00 ele não vai achar o schema nessa versão, neste caso ele procurar por uma versão inferior e acaba encontrado o da versão 1.01
Passei pelo mesmo problema, com ajuda deste tópico consegui entender e resolver, obrigado.
-
Em 01/09/2017 at 10:08, Juliomar Marchetti disse:
Sim está sendo analisado o código do Branches e também um novo anexado em outro tópico
então assim que estiver ok informaremos com anuncio aqui no fórum
Boa tarde Juliomar, tenho que monitorar o fórum para saber sobre a publicação do Componente ESocial, ou será dada uma resposta neste tópico?
Grato
Cleyton
-
41 minutos atrás, Juliomar Marchetti disse:
Já está com parte do código compatibilizado. logo sera comitado
ótimo, obrigado
-
Bom dia, também gostaria de saber se haverá algo disponível e quando, já que o prazo para empresas com faturamento acima de 78 milhoes é janeiro de 2018. Grato.
-
Boa tarde, fui atualizar o ACBR e estou recebendo a seguinte mensagem
Command: Update
Updating: D:\ACBR
Error: Unable to connect to a repository at URL
Error: 'svn://svn.code.sf.net/p/acbr/code/trunk2'
Error: Can't connect to host 'svn.code.sf.net': Nenhuma conexão pôde ser feita porque
Error: a máquina de destino as recusou ativamente.
Completed!:
como devo proceder?
Grato
Cleyton Luiz
-
Bom dia, na semana passada atualizei meus fontes do ACBR, e notei que no envio do evento, passei a receber em alguns casos "(297) Rejeição: Assinatura difere do calculado", também notei que havia acentuação no motivo de cancelamento, removi os acentos manualmente e consegui transmitir.
Porém meu componente está configurado para retirar acentos, e antes da atualizar dos fontes do ACBr estava retirando os acentos sem problema.
Como a sefaz do PR está muito instável alguns CT-es não retornam de primeira e é preciso consultar para obter o protocolo de autorização, ao recarregar o XML no componente e tentar consultar estou recebendo da Sefaz o seguinte retorno "DigestValue do documento não confere.", passei a fazer a consulta simplesmente pela chave sem carregar os dados no componente e obtive sucesso.
Ai entra minha dúvida, pode ser que haja algum problema na retirada dos acentos do ACBr?
Grato pela atenção.
Cleyton Luiz
NFSe para Goiânia-GO
em ACBrNFSe
Postado
Bom dia Júlio, poderia anexar o XML do envio e o do soap por favor.