arce

fiz um teste. baixei o emissor da SEFAZ, e o erro é o mesmo, ou seja, teremos que aguardar

O Ruim é que toda vez q isso acontece, recomendamos ao clientes acessarem o portal da receita (http://www.nfe.fazenda.gov.br/portal/disponibilidade.aspx?versao=0.00&tipoConteudo=Skeuqr8PQBY=), e desta vez as marcações estão verdes e o problema permanece. Sabemos q a culpa não é nossa, mas o que dizer aos clientes (

Também estou com o mesmo problema. O estranho que acessei todos os links de produção do webservices SP pelo browser normalmente. 2016 promete fortes emoções

Muito obrigado pelos esclarecimentos

É necessário/obrigatório informar nos dados adicionais as informações da partilha do ICMS? Seria algo como:

Tenho algumas dúvidas: 1º - A partilha de ICMS tbm foi adiada? Se sim, para qual data? 2º - Estou enviando em ambiente de homologação uma NFe com: * Emitente: Regime normal (SP) * CST: 10 * NCM: 48119010 * Com ICMS_ST ( vICMSST > 0) * Destinatário: Contribuinte (PR) * Sem informar o campo CEST Minha dúvida é a seguinte, como não informei o código CEST, e com as informações citadas, não era para ocorrer a rejeição "806 - Rejeição: Operação com ICMS-ST sem informação do CEST."?

Italo. Confiamos no trabalho de vcs e estamos aqui para colaborar. Obrigado

Bom dia Italo, fiz o update do componente ontem e este erro ainda persiste para o servidor Fiorilli. Gostaria de saber, assim como foi citado se neste post, se foi retomado o projeto de correção deste erro.

Estou utilizando o provedor da Fiorilli e ocorre o mesmo erro

Migrei com sucesso a consultaNFeDestinadas do trunk para o trunk2. (semana passada) Mas como este serviço será descontinuado em breve, estou alterando para o DestribuicaoDFe utilizando os exemplos de testes disponíveis no SVN. Após implementar o código, não estou conseguindo realizar os testes de consulta (Retorna 137 - 'Nenhum documento localizado'). No modelo de consulta Nfe Destinadas antigo, para realizar os testes fazia da seguinte maneira. Emitia NFe colocando a mesma empresa emitente como destinatário, desta forma a nota era listada na ConsultaNFeDestinadas . Gostaria de saber se preciso como realizar o teste de homologação.

Atualmente minha aplicação possui o método de consulta das NFes Destinadas. Minha dúvida é a seguinte, preciso criar tbm a consulta via Distribuição Documentos Fiscais, ou seria correto usar um ou outro?

Obrigado Daniel. Exclui o tipo basico antigo e mantive o novo e funcionou .

Régys, eu renomeei o arquivo e mesmo assim o erro persiste. Copiei os schemas do dir ...\Exemplos\ACBrDFe\ACBrNFe\Schemas\ve310 Com o arquivo tiposBasico_v1.03_OPENSSL.xsd consigo emitir normalmente utilizando certificado Capicom. Segue em anexo o arquivo tiposBasico_v1.03_OPENSSL_erro_uTrib.xsd

Copiei os Schemas v310 para o diretório da minha aplicação. E segui as recomendações do post (http://www.projetoacbr.com.br/forum/topic/25032-opensslxmlsec-ou-capicom-dependencia-de-bibliotecas-externas/ ) Porém ... qndo seleciono o certificado com as configurações de OpenSSL, continua apresentando o erro citado, mesmo com o tiposBasico_v1.03_OPENSSL.xsd.

já descobri o erro... foi uma falha minha. Havia referenciação no libaryPath apontando para .dfm destualizados

Assim como o Paulo, reinstalei o o ForteReportCE e o ACBr hoje pela manhã. E ao imprimir uma NFe, dá um erro de Access Violation no método Imprimir da ACBrNFeDANFeRL.pas, na linha 458 ou 460 (RLNFe: Erro durante a preparação do relatório) Seria relacionado aos arquivos .lfm? Existe alguma configuração que preciso verificar nos .ini/.inc do ACBr para que o componente compile o dfm A impressão dos Eventos está Ok.

O erro é um access violation. Escrevi errado, não é o "Assunto" e sim o corpo do e-mail. Como estou revendo e refatorando tbm meu código dos documentos fiscais, atualizo diariamente o fonte do ACBr. Eu ou vc, talvez nos confundimos rsrsrs. Mas aqui está exatamente ao contrário: Fonte ACBr: MAIL.Body.Assign(sMensagem); Minha alteração: MAIL.Body.Text := (sMensagem.Text);

Bom dia Daniel, no enviar email de NFe/Evento, estava ocorrendo um erro referente ao "Assunto". Alterei a ACBrDFe para corrigir o problema. Por favor verifique se está correta a minha alteração (linha 271) ACBrDFe.pas

bom dia A Sweda disponibilizou uma nova versão da dll, atualize e veja se resolve seu problema http://www.sistemas.sweda.com.br/downloads/SATDLL_1_0_6_32_bits.zip

Deu certo Daniel.. Obrigado

Daniel... o erro acontece com OpenSSL (A1), no caso da Capicom, mesmo com a senha errada conecta

Boa tarde Implementando as alterações do certificado digital do trunk2, percebi a seguinte situação. Quando seleciono um certificado não expirado e preencho incorretamente a senha do mesmo, aparece a mensagem de erro: Anexo (ErroCertificadoComSenhaErrada). E quando utilizo outro certificado expirado com a senha correta, aparece o data de expiração certa: Anexo (ErroCertificadoExpirado). Alterei de forma que, se SSL.CertDataVenc = 0, informa que há configurações estão erradas (por exemplo a senha). Seque anexo a unit alterada para análise de vcs. ACBrDFeWebService.pas ACBrDFeWebService.pas

Bom dia Estou migrando minha aplicação para o trunk2. Com o trunk utilizava como motor de impressão da DANFe o Rave (ACBrNFeDANFERaveCB), com ele ao selecionar n NFes gerava um único arquivo de impressão, onde cada página correspondia a uma NFe. Como utilizo o Delphi 7, optei pelo FortesReport para o trunk2, e este tem uma mecânica semelhante ao QuickReport, ou seja, gera-se uma DANFe por arquivo de impressão. Existe alguma forma do ACBrNFeDANFeRL ter um comportamento semelhante ao ACBrNFeDANFERaveCB?

Boa tarde, Obrigado pelo retorno, vou atualizar a DLL dos meus clientes. Já realizei a troca dos cabos tbm. Quando será disponibilizada a versão 64bits? Agora vamos aguardar.

Obrigado Italo, e desculpe a minha falta de atenção.