Leonardo Gregianin

Com base na tag cProd é possível agrupar os produtos. Por exemplo: 7109510406282 7109510406251 7109510405926 Composição do código: 71095104 = Código do produto 06 = cor 282 = tamanho Poderíamos criar a propriedade taAgruparProd = (taNao, taSim) e uma propriedade do tipo inteiro para definir até quantos dígitos será agrupado, como no exemplo acima, definiria 8 dígitos.

Bom dia, Conforme o layout da NF-e é possível inserir 990 itens/produtos distintos para cada NF-e desde que não ultrapasse o limite máximo de 500KB para o tamanho do XML, podendo também utilizar o envio compactado com GZIP, o que seria facilmente transmitida uma NFe com 990 produtos. 990 produtos distintos em uma única NF-e parece um número exagerado para uma empresa realizar, mas não, principalmente empresas no ramo de atacado e distribuição e que se utilizam de produtos iguais diferindo entre cor e tamanho, esse número de produtos em uma NF-e é bem plausível. Agora imagine a impressão desta DANFe, facilmente chega entre 50 a 60 páginas. Com a intenção de reduzir custos aos clientes, poderíamos criar uma (ou mais) propriedades na impressão da DANFe na NF-e para agruparmos produtos? Este assunto já foi discutido neste fórum a um tempo atrás neste tópico. Não há problemas na legislação quanto a isso, o XML é transmitido completo e somente a impressão da DANFe que é agrupado os produtos. Outros softwares no mercado já utilizam deste agrupamento de produtos na impressão da DANFe, por exemplo, [1] Att.

Bom dia, Incluir novo município no arquivo Cidades.ini [1503606] Nome=Itaituba UF=PA Provedor=Fiorilli

Eu me preocupo mais com o arquivo ISSNet.ini onde tem informações diferentes entre Cuiabá-MT e as demais cidades. Não gosto da ideia de ficar alterando informações do arquivo ISSNet.ini a cada troca de cidade para emissão da NFSe.

Concordo plenamente com você Ítalo. No ACBr, poderíamos criar um novo provedor, por exemplo, ISSNetCuiaba para resolver isso?

Bom dia, Continuando o tópico linkado abaixo que foi fechado. O Provedor ISSNet atende diversas cidades no Brasil e a alteração ocorreu somente para a cidade de Cuiabá-MT. As URLS do Namespace, os arquivos de schemas XSD e todas as alterações realizadas nos commits 17905 e 17906 devem ser apenas para o município de Cuiabá-MT. Para comparação: https://wscuiaba.issnetonline.com.br/webserviceabrasf/cuiaba/servicos.asmx?wsdl https://www.issnetonline.com.br/webserviceabrasf/dourados/servicos.asmx?wsdl Essa informação foi confirmada pelo suporte da empresa Nota Control responsável pelo provedor ISSNet.

A Nota Técnica que implementou a emissão de NFe para Pessoa Física "NT 2018.001 (Emitente Pessoa Física)" diz isso na página 19: 12. Serviço: Evento de Manifestação do Destinatário (item 4.9 do MOC) O Evento de Manifestação do Destinatário é gerado pelo destinatário da NF-e e atualmente não consegue ser realizado por destinatário pessoa física (CPF). Esta NT trata do emitente pessoa física, portanto não prevê alterações relacionadas com o destinatário.

Esse fórum é para discutirmos sobre o componente ACBr e o componente não tem erro. O erro está na forma que o pessoal está programando. Reclamar do governo tem os canais próprios para isso.

Lentidão dos webservices do governo é comum, existem técnicas de programação que podemos fazer para minimizar isso. Erro de timeout do webservice pode ser tratado com um simples try..except no nosso software. Podemos fazer uma thread para ficar consultando o webservice de tempos em tempos. Acho que o povo reclama demais.

Utilizo na empresa que trabalho e funciona normalmente, temos a baixa por certificado digital pelo webservice e baixa pelo HTML do site. O seu não funciona porque?

Tem empresas utilizando o Manifestador de NF-e disponibilizado gratuito a anos pela SEFAZ para baixar os XMLs. http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=AxaPNP1BtFk=

Faz scraping do site.

Boa tarde Rogério, essa unit não está no repositório oficial do ACBr está no meu repositório do Github nesse endereço https://github.com/leogregianin/ofx-reader Você pode baixar o projeto e testar os exemplos e incluí-lo ao seu software.

Parabéns pelo projeto @RicardoVoigt. Uma sugestão, poderia ser incluído no svn do ACBr em uma pasta separada ou um projeto aberto do github para não ficar esquecido.

Bom dia, Segue anexo inclusão da formatação e validação das placas no ACBrValidador com o padrão Mercosul e com testes unitários. Att. ACBrValidador.pas ValidadorTeste1.dfm validadorteste1.lfm acbrvalidadortest.pas

Veja se o seu código tem esta alteração: último commit O que fiz foi alterar o campo "ID" do ClientDataSet do tipo Inteiro para tipo String. Existem outros exemplos como este da pasta "Simple".

Boa tarde Claudiomir, O erro só ocorria no exemplo com o ClientDataSet. Fiz a alteração no repositório. Faz o pull novamente. Att.

Bom dia, Alterei o cálculo da tag "vNF" na função ValidarRegrasdeNegocios conforme NT 2016.002 versão 1.42, página 55, somando no valor total a tag "Imposto.ICMS.vFCPST". Unit anexa. ACBrNFeNotasFiscais.pas

Bom dia, Estou fazendo testes para NFC-e do Amazonas com certificado fora do Amazonas.Utilizo CSC "0123456789" e o identificador "000001" porém ocorre a rejeição "203 - Emissor não habilitado para emissão da NF-e": <retConsReciNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <tpAmb>2</tpAmb> <verAplic>AM3.10-4.00</verAplic> <nRec>130000101162383</nRec> <cStat>104</cStat> <xMotivo>Lote processado</xMotivo> <cUF>13</cUF> <dhRecbto>2018-03-22T11:08:11-04:00-04:00</dhRecbto> <protNFe versao="4.00"> <infProt> <tpAmb>2</tpAmb> <verAplic>AM3.10-4.00</verAplic> <chNFe>13180337451374000133650051000000041841490903</chNFe> <dhRecbto>2018-03-22T11:08:11-04:00-04:00</dhRecbto> <cStat>203</cStat> <xMotivo> Rejeicao: Emissor nao habilitado para emissao da NF-e </xMotivo> </infProt> </protNFe> </retConsReciNFe> Alguém com esse erro?

Bom dia, Tem Estados que nem homologação está funcionando.

Bom dia Reginaldo, Qual serviço utiliza para consultar a nota autorizada? Não entendi como fez essa consulta porque o RPS ainda não foi autorizado. Bom dia brsamn, Se o retorno fosse síncrono, em teoria, ficaria correto e prático. Mas quando o retorno é assíncrono ainda não entendi como vocês fazem.

Boa tarde Ítalo, O RPS é gerado pela aplicação automaticamente sim. O problema ocorre quando é enviado um RPS e o provedor retorna informando que o RPS já existe, acredito eu que seja um erro do provedor. Após identificado esse tipo de retorno, a aplicação incrementa o número do RPS e envia novamente. Minha dúvida é se todos os provedores retornam o código E10 para a mensagem do "RPS já existente".

Bom dia, Ao transmitir uma nota, em algumas situações, alguns provedores retornam o erro "RPS já informado". Para não ocorrer essa mensagem e ficar transparente para o usuário final, eu gostaria de incrementar o número do RPS automaticamente e transmitir novamente a nota. Qual a melhor forma de identificar o retorno "RPS já informado" para diversos provedores? Será que essa é a melhor forma de tratar esse problema? Att.

Por aqui está funcionando normalmente, eu utilizo LoadFromFile. Configure a propriedade abaixo para visualizar se realmente o retorno do webservice está realmente consultando sem erros. ACBrNFe1.Configuracoes.WebServices.Visualizar := True;

Tem que seguir a ordem sim, primeiro Synapse e depois ACBr_Comum, ACBr_Diversos e PCN_Comum. Os pacotes específicos de Serial, NFe, NFSe, TCP e etc não tem ordem. As bpls serão geradas em um diretório como esse: C:\Program Files (x86)\Embarcadero\Studio\19.0\bin, se não me engano.