Italo Giurizzato Junior

Boa tarde Asterix, Sendo assim, o problema é na SEFAZ. Liga, manda e-mail, tormenta os caras para eles corrigirem o problema.

Bom dia Lucio, A sua NF-e esta sendo rejeitada porque o seu XML na descrição do produto consta a palavra ÓLEO sem acento, correto? E segundo a regra L102-10 devemos da TAG xProd informar a descrição conforme a tabela ANP para operações com combustível, correto? E na tabela ANP a palavra ÓLEO possui acento. Engraçado, a SEFAZ pede para gerar um XML sem caracteres especiais e de preferencia sem as vogais acentuadas, cedilha e como que fica agora?

Bom dia Jonas, Quanto as TAGs: IDEstrangeiro e vAFRMM já fiz as alterações, ainda hoje estarei disponibilizando. Voltando o assunto da TAG nDI, infelizmente na última versão da NT 2013/005 não temos a composição do identificador DI /DSI. Como essa TAG aceita tanto os números: DI, DSI e DRIE é de se esperar que exista um digito ou quantidade de dígitos para diferenciar um do outro. A DRIE possui 12 dígitos, por outro lado a DI e DSI possem 9 dígitos. Se o conteúdo da TAG: nDI contem 12 dígitos a SEFAZ interpreta que o numero se trata de uma DIRE. Por outro lado se a TAG possuir apenas 9 dígitos qual é a informação (DI ou DSI)? O que a SEFAZ fez inclui um digito identificador de tipo de documento no inicio e de quebra um digito verificador no final. Se hoje a SEFAZ não possui uma regra de validação para esta TAG com certeza futuramente terá. Lembre-se que você tem total liberdade de alterar os fontes, se você não concorda com a validação do conteúdo da TAG: nDI, altere os fontes.

Bom dia jmspoa, Muito obrigado pela colaboração, já fiz a alteração, ainda hoje estarei disponibilizando.

Bom dia Márcio, Muito obrigado pela colaboração, já esta disponível.

Bom dia DATAC, Até onde sei já foi implementado, você baixou a última versão do ACBrNFeMonitor?

Bom dia Jones, No que diz respeito ao DI / DSI acredito que você pode muito bem tratar isso na sua aplicação. No banco de dados fica armazenado sem o primeiro digito (2 para DI e 4 para DSI) mas você acrescenta esse digito quando for alimentar o componente para gerar o XML. Caso o seu cliente veja o conteúdo do XML e te questione, faça um teste na frente dele com e sem esse digito. Tomando como base a NT 2013/005 versão 1.01 se não for informado o digito 2 ou 4 a NF-e vai ser rejeitada. A sua obrigação é fornecer uma aplicação que gere uma NF-e que seja aceita pela SEFAZ a outra coisa é o seu cliente é discordar de como a informação tem que ser incluída no XML. Se ele discorda, manda ele questionar a SEFAZ. Com relação ao CNPJ e UFTerceiro (I23d e I23e) fiz uma alteração e já esta disponível, favor atualizar os fontes e testar novamente. Obs: a unit que gera o XML encontra-se na pasta PCN2. Eu aconselho sempre atualizar todos os fontes de todas as pastas.

Bom dia, Você atualizou os fontes e testou novamente? Se sim, compare esse exemplo com o arquivo: <numero><serie>-con-nfse-rps.xml Dependendo de como o componente esta configurado é salvo também o arquivo completo de envio: <numero><serie>-con-nfse-rps-c.xml Post como anexo este último.

Junior, Infelizmente a ABRASF não tem condições de impor um layout. Sendo assim algumas empresas (provedores) ainda utilizam a versão 1.00 da ABRASF e outras já utilizam a versão 2.00, sem falar em outras que resolveram dar uma personalizada na estrutura. E existem outras que tomaram o layout da ABRASF como uma referencia, mas fizeram diversas alterações como é o caso da E&L. Uma coisa é acrescentar uma TAG a mais, outra coisa é TAGs com nomes diferentes. Isso não significa que não tem como implementar no componente, mas sem duvida será mais trabalhoso. Os provedores que seguem uma das versões da ABRASF seguem também a forma de conexão com os Web Services, isso faz com que a implementação de um novo provedor no componente se torne mais fácil e rápido. Para mim, se o XML de um RPS não se encache com nenhuma versão de layout da ABRASF, o provedor não segue o padrão ABRASF.

Bom dia Eric, Você esta setando o modelo e a versão do documento fiscal no código da sua aplicação? (...) ACBrNFe.Configuracoes.Geral.Salvar := True; ACBrNFe.Configuracoes.Geral.ModeloDF := moNFe; // ou moNFCe ACBrNFe.Configuracoes.Geral.VersaoDF := ve310; (...) Temos que setar o modelo e a versão e tem que ser nessa ordem caso contrario não funciona.

Bom dia Josadac, O ACBrNFeMonitor esta configurado para efetuar o cancelamento por evento?

Bom dia Jones Almeida, Você esta informando o numero da DI / DSI conforme o meu post #8 e do Kiko #9?

Bom dia a todos, Removi os arquivos *.ZIP e deixei dentro da pasta ...\Exemplos\ACBrNFe2\Delphi\Schemas\V310 os arquivos: *.XSD mais recentes. Atualizem todos os arquivos de todas as pastas.

Bom dia a todos, A diferença da versão 1.04 e 2.00 para o componente é apenas a estrutura do XML nada mais. Não existe uma rotina de envio para a 1.04 e outra para 2.00 Portanto se esta ocorrendo alguma lentidão (envio/autorização/impressão) ou é a internet do emitente ou é a SEFAZ.

Bom dia Lucio, O componente ACBrMDFe já foi alterado segundo a NT 2014/003 divulgada pela SEFAZ-RS no dia 23/06/2014. Os Schemas que acompanham o programa exemplo do componente também foram atualizados. Tudo esta disponível no repositório.

Bom dia Junior, O provedor E&L não segue o padrão ABRASF, a estrutura é semelhante mas não é igual veja esse fragmento do XML: XML segundo o provedor E&L: <Endereco> <LogradouroTipo>Rua</LogradouroTipo> <Logradouro>LOGRADOURO</Logradouro> <LogradouroNumero>999</LogradouroNumero> <LogradouroComplemento>Casa</LogradouroComplemento> <Bairro>CENTRO</Bairro> <CodigoMunicipio>9999999</CodigoMunicipio> <Municipio>NOME MUNICIPIO</Municipio> <Uf>ES</Uf> <Cep>99999999</Cep> </Endereco> o mesmo fragmento segundo o padrão ABRASF: <Endereco> <Endereco>RUA PRINCIPAL</Endereco> <Numero>100</Numero> <Complemento>APTO 11</Complemento> <Bairro>CENTRO</Bairro> <CodigoMunicipio>2103000</CodigoMunicipio> <Uf>MA</Uf> <Cep>69301040</Cep> </Endereco> Notou as diferenças (negrito): TAGs de nomes diferentes e ausências de outras no padrão ABRASF.

Bom dia Mattos, Se os seus fontes estão atualizados, se os Paths estão na sequencia correta no Library Paths do Delphi, concluo que o seu Delphi esta encontrando algum DCU antigo e utilizando-o na compilação. Na pasta que contem os fontes da sua aplicação, não existe nenhum .PAS ou .DCU do pcnConversao ?

Bom dia a todos, Para utilizar mais de um NVE será necessário fazer uma alteração no componente. Pois quando essa TAG foi implementada como sendo um Elemento, passou desapercebido o número de ocorrências. Que no caso de um Elemento o normal é aparecer 0-1 (opcional) ou 1-1 (obrigatório). No caso da TAG: NVE (Elemento) o número de ocorrências é: 0-8, isso significa que ela é opcional mas pode ocorrer até 8 vezes. No seu exemplo Elton, teríamos: <NVE>AA0001</NVE> <NVE>AB0001</NVE> <NVE>AC0001</NVE>

Bom dia Maiquel, Para dar inicio a implementação precisamos: * Quais são as cidades atendidas por esse provedor? * Dos Schemas de validação. * Das URLs de homologação e produção de cada cidade atendida. * Se conseguir, exemplos de arquivos SOAP de envio, consulta, cancelamento, .... seria ótimo.

Bom dia Maiko, Na versão 2.00 o termo é Local de Coleta e não de Retirada. Acredito que ao informar o Local de Coleta não muda em nada no tipo de serviço. E pelo que estou entendendo o material a ser transportado pertence a transportadora, é por isso que ela é o remetente, correto? Quanto a impressão, o DACTE não contempla a impressão do Local de Coleta e Entrega, neste caso há necessidade também de informar esse endereço no campo de observação. Esse Local de Coleta pertence a transportadora? Se sim, porque não informa-lo como sendo o endereço do remetente?

Bom dia a todos, Se um tipo ou constante ou identificador é apontando como inexistente pelo Delphi e no fonte ele esta declarado. Verifique se no Library Paths a pasta que contem esse fonte não esta depois da pasta que contem o componente que você esta compilando. Por exemplo (lista do Library Paths): C:\ACBr\Fontes\ACBrCTe C:\ACBr\Fontes\PCN2 Como o ACBrCTe se utiliza de algumas units que estão na pasta PCN2 a ordem correta é: C:\ACBr\Fontes\PCN2 C:\ACBr\Fontes\ACBrCTe Espero ter ajudado.

Bom dia Eduardo, O Exemplo que você postou esta correto. O componente que permite incluir essa TAG: NVE apenas uma unica vez, portanto precisa ser corrigido.

Bom dia Lazaro, Inclui a cidade no provedor GovBR em função dos Schemas que você postou. Caso não o Web Services rejeite o lote de RPS vamos ter que mudar essa cidade para o provedor Pronim. Favor atualizar os fontes e iniciar os testes.

Boa tarde, No final dessa portaria notei que o CT-e deve contem informações sobre o caminhão e do motorista. Para que essas informações constem no XML e consequentemente no DACTE, o CT-e tem que ser Lotação. Como o MDF-e é para carga fracionada, conclui-se que não há necessidade de emitir o MDF-e, apenas o CT-e.

Boa tarde, Se você levar em consideração o tomador, podemos dizer que o CT-e é lotação, uma vez que o tomador é único. Neste caso o CT-e sendo de lotação, devemos informar o caminhão e o motorista e sendo assim não se faz necessário o MDF-e, visto que o mesmo é destinado a carga fracionada. Se você levar em consideração o destinatário, podemos dizer que o CT-e é fracionado, uma vez que temos vários destinatários. O CT-e sendo de carga fracionada, não informamos o caminhão e o motorista. Carga fracionada e transporte interestadual deve-se emitir o MDF-e mesmo que tenhamos apenas um CT-e.