Italo Giurizzato Junior

Ricardo, Neste caso vou precisar de uma maquina com 4 monitores, pois com 2 já não esta dando mais. 1. para ver os e-mail; 2. para o fórum; 3. para o msn; 4. para o delphi. Vixi esqueci do skipe. rsrsr

dpaulabh, A minha sugestão é seguir a recomendação deles, por conta da sua nota não ser autorizada.

Bom dia Rodrigo, Com o advento do envio Sincrono, foi dito que não teriamos mais o recibo como retorno, somente o protocolo de autorização. Mas, andei notando que no -pro-rec.xml que é o retorno do processamento esta sendo retornado sim o numero do recibo. Não sei lhe informar se todas as SEFAZ, vão disponibilizar o numero do recibo junto com o protocolo de autorização ao realizar um envio no modo Sincrono.

Bom dia Kosvoski, Muito obrigado pela colaboração, em breve estarei disponibilizando.

Bom dia dpaulabh, Se todo inicio de ano a numeração reinicia para que faz pelo site, como que fica o controle? A série continua a mesma ou muda?

Bom dia Ricardo, Exatamente, o valor dessa propriedade é sempre False, agora se o DANFE que você deseja imprimir se refere a uma NF-e cancelada e o seu cliente quer que seja impresso no DANFE a tarja: NF-e Cancelada, basta atribuir o valor True a propriedade NFeCancelada e mandar imprimir o DANFE ou gerar o seu PDF caso a intensão seja enviar por e-mail.

Bom dia prycka, Se antes estava funcionando, com certeza é problema no provedor.

Bom dia Rodrigo, Esta sendo salvo o arquivo -pro-rec.xml ? Se sim, post ele como anexo.

Bom dia info02serraf, Não existe mais a pasta DANFE_QR3, dentro da pasta ACBrNFe2 temos um arquivo TXT que mostra como eliminar as propriedades que não existe na versão 3.0 do Quick Report . Quanto a instalação você tentou instalar usando o ACBrInstall?

Bom dia Cesar, Se durante o mês efetuando uma espera de 10 segundos resolve o problema para pegar o retorno e no final do mês esse tempo chega a 30 minutos. Você concorda que o problema esta com o provedor? Que não consegue dar conta de tanta requisição, pelo simples fato de que a grande maioria das empresas deixam para emitir as suas notas no final do mês.

Bom dia Sergio, A transportadora A emiti um CT-e normal até ai tudo bem. Mas que vai realmente transportar é a transportadora B, neste caso a transportadora A o tipo de serivço a ser informado tem que ser normal. A transportadora B por sua vez tem que informar que o tipo de serviço é subcontratação e informar como documento anterior o CT-e emitido pela transportadora A. veja este link: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-subcontratacao/

Bom dia kartusheidrich, O componente inicialmente gera um XML para cada RPS que são salvos na pasta RPS e possui o seguinte nome: <numRPS>-rps.xml Depois ele agrupa os RPSs em um lote a ser enviado para o webservice, este XML é salvo dentro da pasta Ger com o seguinte nome: <numLote>-env-lot.xml E por fim ocorre o envelopamento do lote para ser enviado. Nesta etapa é acrescentado mais algumas TAGs especificas do provedor, normalmente esse XML não é salvo, a não ser que você configura o componente para que isso ocorra. O componente possui dentro do grupo WebServices uma propriedade chamada Salvar, cujo valor padrão é False. Se você alterar para True, será salvo o lote envelopado dentro da pasta Ger com o seguinte nome: <numLote>-env-lot-c.xml Os provedores quando disponibilizam um exemplo de envio é o Lote, logo você tem que compara-lo com o -env-lot.xml gerado pelo componente. Não sei lhe dizer se a inversão em um NameSpace com outro, colocados na TAG EnviarLoteRpsSincronoEnvio faz alguma diferença.

Bom dia Tiago, Quando você realiza a consulta da NFS-e por RPS o arquivo -rps.xml é carregado antes ou ao solicitar o Cancelamento de uma NFS-e, é carregado antes o arquivo -nfse.xml ?

Boa noite Sergio, O que o nosso amigo Gabriel, postou sobre o Boletim Ténico a respeito do CT-e Globalizado, é verdado. Não cheguei a realizar testes, mas que existe esse Boletim existe, se você pesquisar aqui mesmo no fórum é capaz de encontra-lo, pois eu mesmo anexei o seu PDF.

Boa noite Leandro, Muito obrigado pela colaboração. já esta disponivel.

Boa noite Vanessa, Você esta usando o componente ACBrMDFe? Pois noite a falta de varias TAGs em seu XML. Favor comparar o seu XML com a estrutura que consta no manual disponibilizado pela SEFAZ.

Boa noite a todos, Infelizmente a ABRASF pisou na bola em criar a estrutura da NFS-e. Segundo o layout só é aceito apenas um item de serviço, mas existe um campo para a sua discriminação, desta forma você neste campo detalhar o serviço e até informar algo do tipo: Referente ao mês de Fevereiro.

Boa noite a todos, Primeiramente, o componente possui uma propriedade que se o seu valor for True, após a consulta o XML vai ser atualizado. Segundo, com a alteração do cancelamento por evento, não se deve mais alterar o XML, ou seja, remover o protocolo de autorização e colocar no lugar o de cancelamento. O XML da NF-e deve permanecer com o procolo de autorização, o que devemos fazer é enviar para o destinatário o XML do evento de cancelamento. Terceiro, ao realizar uma consulta da situação atual de uma NF-e, sempre vai constar no XML de retorno o protocolo de autorização e os eventos vinculados a mesma se existirem. Portanto, caso a NF-e tenha sido cancelada, na lista de eventos vai aparecer o evento de cancelamento juntamente com o protocolo de cancelamento. Espero ter ajudado.

Boa tarde Rodrigo, Você utiliza o DANFE em Fortes Report ? Se sim basta checar quais são as units utilizadas por este componente e cria-las de forma semelhante para o CT-e.

Bom dia, Abra a unit ACBrProcedorTecnos e altere a linha 86: de ConfigCidade.AssinaRPS := true; para ConfigCidade.AssinaRPS := false; Isso vai fazer com que ele não assine o RPS no ambiente de homologação. Se funcionar nos de um retorno.

Tiago, Você tem certeza que os seus fontes estão atualizados? Pois fiz uma correção na unit que carrega o XML e utilizei o programa exemplo para visualizar o DANFSE, todos os dados apareceram após a correção. Você compilou a aplicação novamente com a opção Build?

Bom dia Tiago, Favor atualizar os fontes e testar novamente.

Boa noite Tiago, Se você puder postar como anexo o XML da NFS-e, eu agradeço.

Boa noite a todos, Essa informação de que não pode utilizar um numero de série para cada terminal de venda no caso da NFC-e. Não faz nenhum sentido, visto que essa alternativa foi sugerida pelos lideres: Nacional e Estaduais, as empresas participantes do projeto piloto da NFC-e.

Boa tarde Luciano, Hoje o XML da NF-e é exatamente igual ao da NFC-e, logo temos duas TAGs ou dois campos: serie - Série do Documento Fiscal que varia de 001 até 999 e nNF - Número do Documento fiscal que varia de 1 até 999.999.999 Nada impede de você utilizar a serie 001 para uma maquina e a 002 para outra no caso da emissão de NFC-e Se o seu cliente tiver 5 maquinas emitindo NFC-e você terá com certeza 5 NFC-e de numero 560 cada uma de uma série diferente. É por isso que falei de incluir na estrutura da tabela do banco de dados que registra a venda o campo serie e este deve pertencer a chave primaria juntamente com o numero da nota. E ao calcular o próximo numero deve-se levar em consideração a serie. Dica, cada maquina deve ter um arquivo TXT (por exemplo) que contem o numero da série, desta forma o software fica igual para todas as maquinas. O software se utiliza dessa informação que esta no arquivo TXT para consultar o banco de dados e calcular o próximo numero da nota mediante a série informada.