Italo Giurizzato Junior

Boa noite Leandro, Esse Link3 é o provedor? Se sim, ele não foi implementado. Busque mais detalhes sobre esse provedor, tais como: schemas, padrão utilizado (por exemplo ABRASF), URLs de homologação e produção, etc.

Boa noite Ronaldo, Favor atualizar os fontes e testar novamente.

Honório, Como o MDF-e não é obrigatório e só vai ser necessário em algumas situações, não há urgencia de implementar no monitor. Mas quando se tornar obrigatório, acredito que sim, vai ser implementado no ACBrNFeMonitor ou em outro Monitor. Acredito que o texto publicado ( link que você postou ) esta errado pois, faz referencia a transporte interestadual e intermunicipal de cargas fracionadas. A não ser que no Estado de São Paulo vai ser diferente, pois até onde sei é somente transporte interestadual de carga fracionada. Vamos checar isso.

Honório, A sua pergunta já respondi veja: Só uma coisa, o seu post foi publicado no dia 12 as 8:14 PM, sábado, feriado. Tudo bem que hoje é terça-feira, passou mais de 1 dia útil, mas lembre-se que, aqueles que costumam trabalhar aos sábados e derrepente é um feriado, ao chegar segunda-feira tem muita coisa para colocar em ordem. E é fatal esquecermos de alguma coisa. Sendo assim, desculpa pela demora.

Boa tarde Honorio, Eu sou o responsável pelo componente ACBrMDFe, mas não sou sou eu quem faz as correções e implementa novos recursos ao mesmo. Acredito que sim, visto que o MDF-e vai ser utilizado em determinadas situações, tanto por emitentes de CT-e quanto de NF-e. Vamos aguardar.

Boa tarde, Mandei para o SVN uma alteração. Gostaria que você postasse em anexo o XML dessa nota.

Boa tarde Aderson, Na versão 2.00 do CT-e, você vai resolver esse problema atribuindo a palavra ISENTO ao campo RNTRC. Na versão 1.04 o campo RNTRC é numérico portanto não aceita a palavra ISENTO.

Bom dia Adilson, Pelo fragmento que você postou, você esta estudando o conteudo do arquivo alimentacomponente.txt que eu disponibilizei juntamente com o programa exemplo do ACBrCTe. Como trata-se de um fragmento da minha aplicação o que posso lhe dizer é que essa parte busca na tabela Cnt_Notas os documentos originários de um conhecimento que pretendo gerar o XML. No meu caso o campo Numero é o numero do conhecimento e Codigo é o código que me diz quem esta emitindo o CT-e, por exemplo: 1 = Matriz, 2 = Filial A, 3 = Filial B, etc

Guilherme, Realmente o lay-out do XML não tem nada haver com o ABRASF. Para ser sincero gostei muito do lay-out pois lembra o da NF-e. Há necessidade de estudar melhor esse lay-out, pois com certeza teremos que criar uma estrurura nova de classes para definir as propriedades que receberão os dados, depois criar as rotinas que vão gerar o XML e tudo mais. Precisamos ver também os metodos de acesso aos webservices. Conforme for o resultado dessa analise, as vezes compensa criar um novo componente para esse provedor.

Bom dia Guilherme, A unit que gera o XML é pnfsNFSeW.pas Esse provedor Infisc segue o padrão ABRASF? Você tem os schemas desse provedor?

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

Boa noite Abade, Favor pesquisar no fórum por Atualização Forçada.

Leonardo, É uma segunda alternativa, mas desta forma as constantes que mostrei no post anterior, deixariam de ser constantes e passariam a ser variáveis que mudariam de valor conforme a versão escolhida.

Leonardo, No momento não esta disponivel os webservices para realizarmos testes na versão 3.10 Na unit pcnConversao.pas temos varias contantes definidas, as que iniciam com NFe e as que iniciam com NFCe. O inicio do nome da constante já deixa claro para qual modelo de documento vai ser utilizado, veja este exemplo: NFeconsStatServ = '2.00'; NFCeConsStatServ = '3.00'; Quando o componente utiliza uma quando utiliza outra, veja: if (FConfiguracoes.Geral.ModeloDF = moNFCe) then ConsStatServ.Versao := NFCeConsStatServ else ConsStatServ.Versao := NFeConsStatServ; Como você pode ver temos uma propriedade chamada ModeloDF = Modelo de Documento Fiscal que pode receber o valor moNFe ou moNFCe. Quando a SEFAZ passar a aceitar em ambiente de produção os dois modelos de documentos fiscais basta alterar as versões das contantes, voltando ao exemplo acima: NFeconsStatServ = '3.10'; NFCeConsStatServ = '3.10'; Isso vai fazer com que o XML seja gerado na versão 3.10 A questão é equanto tivermos dentro de um periodo de transição como conviver com essas versões? Sugestão, para definir o valor das contantes usando diretiva de compilação: {$IFNDEF NF_V_310} NFeconsStatServ = '2.00'; NFCeConsStatServ = '3.00'; {$ELSE} NFeconsStatServ = '3.10'; NFCeConsStatServ = '3.10'; {$ENDIF} Essa alteração seria feita somente no fonte pcnConversao.pas e incluir a definição da diretiva NF_V_310 em ACBr.inc E uma pequena alteração no ACBrNFeNotasFiscais.pas Do resto esta tudo pronto.

Boa tarde Vitor, Eu estou calculando da seguinte forma: vTotTrib := (vTotalPrestacao * pAliquotaIBPT) / 100; Onde: vTotalPrestacao é o valor total que o tomador do serviço vai pagar ou seja o valor do frete. pAliquotaIBPT é o porcentual divulgado pelo IBPT para um determinado serviço, por 2,8%. Supondo que o valor do frete seja R$ 100,00 vTotTrib = ( 100 * 2,8 ) / 100 Portanto o valor total aproximado dos tributos segundo o IBPT para o serviço em questão é R$ 2,80 Agora como alimentar o componente vide o arquivo AlimentandoComponente.txt que esta dentro da pasta ...\Exemplos\ACBrCTe

Boa tarde Jeferson, O componente é capaz de gerar o XML contendo o CNPJ ou CPF. Mas segundo o manual página 153 temos CNPJ do emitente ou CPF do remetente, isso é muito estranho, mas na coluna observação temos: Informar o CNPJ do emitente.Na emissão de NF-e avulsa pelo Fisco, as informações do remetente serão informadas neste grupo. Logo nos leva a crer que no caso do emitente temos que informar o CNPJ e portanto utilizar um certificado de pessoa juridica. Me corrijam se eu estiver errado.

Boa tarde ssouzaacbr, Cada cidade tem o seu código de tributação. A dica é: entrar em contato com a prefeitura, caso ela não saiba o código ( algo normal, eles nunca sabem ), você entra em contato com o provedor, informe a cidade e solicite o código e a sua formatação correta para que seja aceito pelo webservices.

Boa tarde Leonardo, Hoje o componente gera a NF-e na versão 2.00 quando setamos a propriedade ModeloDF com o valor moNFe. E gera a NFC-e na versão 3.00 quando o valor da propriedade ModeloDF é moNFCe. Agora temos uma nova versão a 3.10 que vem para substituir tanto a versão 2.00 da NF-e quanto a 3.00 da NFC-e. Não sei se seria o caso de criarmos uma diretiva de compilação aos moldes do ACBrCTe, mas neste caso ela apenas serviria para definir a versão dos documentos. Ou criar uma nova propriedade no componente para informar-mos a versão desejada. Portanto até o momento nenhum dos dois modelos de documentos fiscais são gerados na versão 3.10. Foi publicado uma nova versão da NT2013/005 que trata do novo lay-out e que me parece estar em conformidade com os schemas v3.10 também publicados. Houve alteração nos grupos ISSQN e ISSQNtot, já estou providenciando as alterações no componente. Mas fica a questão da versão. Como podemos resolver essa questão com o menor impacto possível?

Acredito que sim, pois na minha maquina tenho o DCU e fica dentro de uma pasta chamada QuickRep5. Só que o meu é AR5RunD7.dcu uma vez que utilizo o Delphi 7.

Bom dia Krepe, Segundo a NT 2012/004 item 4 diz que devemos imprimir o DACTE segundo o modelo Contingência em papel comum. Fiz uma alteração no DACTE e na função que gera a chave de contingência para que seja possível imprimir o DACTE com o código de barras de contingência quando o tipo de emissão for 4 ou seja EPEC. Favor atualizar os fontes e testar.

Bom dia sesistemas, Procure pelo arquivo QR5RunDXE3.dcu e inclu-a o path dele no library path do Delphi antes dos paths do ACBr.

Bom dia André, Disponibilizei os schemas versão 3.10 a serem utiliandos tanto pela NF-e quanto pela NFC-e. Esta ainda zipado dentro da pasta: ...\Exemplos\ACBrNFe2\Delphi\Schemas\V310

Bom dia Ricardo, O erro ocorre na compilação da sua aplicação ou ao executa-la? Pois acabo de compilar o programa exemplo e executa-lo sem nenhum problema. Um detalhe, os fontes disponibilizados hoje contem uma alteração no componente ACBrNFSeDANFSeQR. Temos agora uma propriedade chamada ImprimeCanhoto cujo valor padrão é False. Portanto você deve abrir o pacote de instalação do ACBrNFSeDANFSeQR e compilar ele novamente.

Bom dia Krepe, Vamos separar as coisas: O comando Imprimir se baseia no conteudo do XML do CT-e, como este não foi enviado para SEFAZ, logo ele não possui o numero do protocolo. O EPEC é um evento que contem um numero minimo de dados do CT-e que é enviado para SEFAZ Virtual de Contingência. Ainda não esta disponivel o comando para imprimir Eventos. A mensagem que aparece no DACTE esta errada no verdade é EPEC e não DPEC.

Bom dia kzarlopes, A definição do valor teMultiModal se encontra no fonte pcnConversao.pas que faz parte do pacote PCN2. Abra o pacote de instalação PCN2 e simplismente clique em compilar.