Nelson Santos

Bom tarde @Italo Jurisato Junior, Realmente...cada vez mais os caras soltam soluções mirabolantes, mas demonstram não entender nada do assunto. Do lado do programador, temos que cada vez mais nos empenharmos de desenvolver programa PAI - Programa à Prova de Imbecil. O problema é que os caras invento determinados processos que nem eles sabem depois como desenvolvê-lo. Espero que ele tenham explicação sobre as outras opções do campo tpAutor !!

Bom dia novamente @Italo Jurisato Junior, Acabei de ver no Schema (ACBr\Exemplos\ACBrDFe\Schemas\NFe\leiauteEventoCancSubst_v1.00.xsd) e está travado com 1 - Empresa emitente: <xs:element name="tpAutor"> <xs:annotation> <xs:documentation>Autor do Evento de Irregularidade FiscalInformar 5=Fisco para este Evento. Valores: 1=Empresa Emitente, 2=Empresa destinatária; 3=Empresa; 5=Fisco;6=RFB; 9=Outros Órgãos; </xs:documentation> </xs:annotation> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="1"/> </xs:restriction> </xs:simpleType> </xs:element>

Bom dia @Italo Jurisato Junior Realmente também fiquei confuso. Entretanto, será que eles já estão prevendo que no futuro o Destinatário (ou os outros) poderão também fazer isto ? Por isso que hoje, está tratado em 1 - Empresa Emitente, mas já colocaram esta previsão no payout ? Eu não chequei o Schema (xsd) para ver se existe alguma regra de negócio travando isto em 1...vc chegou a verificar no xsd ?

Boa tarde @Italo Jurisato Junior Me corrige, por favor, mas não achei o campo tpAutor (= Informar 1=Empresa Emitente. Valores: 1=Empresa Emitente, 2=Empresa destinatária; 3=Empresa; 5=Fisco; 6=RFB; 9=Outros Órgãos), conforme NT 2018.004 (http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=EvNIAlMalWI= ), pagina 4, campo P21. Outro fato que notei é que a NT cita que o campo cOrgaoAutor = Código do Órgão Autor do Evento. Informar o Código da UF para este Evento. No exemplo, vc informa a UF.

Bom dia... Para quem ainda está interessado. Não tentei implementar o provedor FGMAiss no ACBRNFSe, pois eles utilizam um layout próprio e muito diferente da ABRASF. Desenvolvi um componente separado, mas com semelhança muito grande com os componentes do ACBR. O @Italo Jurisato Junior até indagou sobre este fato, se eu não tentei integrá-lo ao ACBRNFSe (ver tópico: Entretanto, realmente não tentei, uma vez que teria que estudar todo o código do ACBRNFSe para, então, ver como adaptar o provedor FGMAiss ao mesmo (Na época estava iniciando com o ACBR e não tinha muita noção da estrutura do desenvolvimento dos componentes). Hoje tenho informações suficientes sobre a FGMAiss e ACBR para poder ajudar quem já tiver em andamento na integração. Caso queira a minha ajuda, não exitem...me acionem que trabalhamos juntos. Hoje meu componente faz todo o processo de Envio, Cancelamento, Consulta e muitos outros que acabei desenvolvendo, em Delphi e Java (Android).

Boa noite, Já venho trabalhando com o provedor FGMAiss há tempos, pois, aqui no estado do RJ, a única cidade a aderir à este provedor é justamente a cidade onde estou - Três Rios. No início tive muitas dificuldades, principalmente com relação à contato com eles. Parece que, ou ele não sabem nada, ou não estão muito a fim de dar informações. Consegui finalmente no ano passado um contato diretamente com o consultor deles através de um amigo na Prefeitura de Três Rios. Então a coisa andou e consegui inclusive criar um Compnente, nos moldes do ACBr. Já conversei com o Ítalo sobre o fato de inclusão do provedor FGMaiss no ACBr, mas o layout que ele usam é totalmente diferente do padrão. o Componente está totalmente funcional, utilizando Soap para envio que, no caso da FGMaiss só tem em modo sincrono. Ele também não abrem ambiente para testes/homologação. O que fazem é te dar os dados de um cliente fictício para testes....(não vou nem comentar isto !). Cada estado é direcionado para um servidor específico, ou seja, SP para um servidor, RJ para outro, PR para outro, etc...

Bom dia Ítalo, Aproveitando este post, sobre mudança no layout, gostaria de saber, levando em consideração a sua experiência, se é possível fazer a CT-e dar um preview em uma única tela, paginando igual ocorre com ACBrNFe ? Verifiquei no arquivo ACBrNFeDANFeRL como é feito este processo (Linhas de 458-486). é possível/viável colocarmos este mesmo código no ACBrCTeDACTeRL (alterando as linhas 178-182) ?

@Italo Jurisato Junior, Pensei exatamente nisto, tanto que estou realmente no meio do processo para gerar um componente ACBrBPeDABeFortes. Estou com uma dúvida com relação ao Board Pass. Vi pelo Manual que é um campo opcional e livre para o emitente. Já pesquisei e tenho uma Unit para gerar este tipo de código de barras. Testei e funciona. Entretanto, quais as dimensões mínimas e máximas (Altura/Largura mínima) ?? Você tem esta informação ?

Não consegui @ROGERIOHFB. Fiz contato com o Suporte Técnico da Balmak que me passou a seguinte situação: Carga é feita somente através do software DFS, que pode ser baixado neste link http://balmak.com.br/balmak-produtos/automacao-comercial/balanca-digital-computadora-com-impressor-integrado/operacao-em-rede-e-softwares-disponiveis/ No meu caso, o cliente usa a Orion 1; vc precisa saber qual é. A Balança funciona em Rede Ethernet. É necessário instalar uma versão antiga de MySQL (vem junto do instalador do DFS). É neste ponto que pegou pramim...meus sistemas usam MySQL, mas com versão mais nova. Assim, não foi possível instalar a versão mais antiga do MySQL. Tentei ver com o suporte alguma solução, mas nada. Eles ficaram de verificar com sua matriz (na Espanha). O cliente está cadastrando os produtos uma-a-um na própria balança... Se vc não usa MySQL, ou pode instalar a versão exigida pelo DFS, os arquivos de carga são compativeis com outras balanças, como Filizola, Toledo, etc... O DFS faz a conversão para o padrão Balmak...não dá para fazer carga direto para a blança, por exemplo, usando o ACBR... Se vc tiver alguma novidade, me avise, por favor...

Boa noite a todos, Gostaria de saber se já existe componente para DABPe em Fortes Report ?

bom dia, Verdade @bilogyn... Isto acontece no Brasil inteiro...as pessoas confundem Boleto com Duplicata...e estou incluindo neste grupo também Contadores que deveriam saber a diferença...

bom dia @ROGERIOHFB Desculpe postar reabrir este poste, mas vc conseguiu fazer a carga na balança Bamak ? Pode me ajudar ?

Boa tarde, Desculpem retomar o tema... Só para lembrar que o Manual de Orientação do Contribuinte limita a NFC-e em 990 ítens ... referência: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=URCYvjVMIzI=

Conforme mencionei, gerei XML com tags dup com os vencimentos e a tag pag com os dados dos pagamentos como 15-Boleto, por exemplo. Deu certo em homologação aqui no RJ. Outra coisa, gerei NF-e com varios tipos de pagamentos, Dinheiro e Boleto na mesma nota, por exemplo. Funcionou...Isto serve para aqueles casos em que o cliente dá uma entrada em dinheiro e o restante das parcelas será em boletos...

Estava com problema com a Bematech 4200 th, cortando dois últimos caracteres à direita na NFC-e, com Fortes. Colocando a propriedade LarguraBobina para 280 conforme mencionado por @j2c9m7 funcionou perfeitamente, ou seja, não corta a direita...obrigado !

Bom dia a todos, A explicação dada na resposta da SEFAZ/GO, ao @bilogyn está correta. O que faltou foi o fechamento da informação na resposta. Duplicata é um TÍTULO DE CRÉDITO, sendo assim, a empresa que emite uma duplicata está concedendo um crédito ao cliente, como se fosse um empréstimo. Se a NFC-e é uma Nota Fiscal destinada somente à venda à vista, não podemos informar o tipo de pagamento 14-Duplicata Mercantil. Isto para NFC-e. Para NF-e, podemos sim realizar uma venda à vista ou à prazo. Cabe informar aqui que, uma venda à vista é aquela que o pagamento ocorre dentro dos 30 dias. Portanto, se uma empresa vende hoje (07/03/2018) e efetivamente recebe no dia 31/03/2018, é considerada venda à vista. Muitos comerciante consideram isto como à prazo, pois está dando um prazo para o pagamento, mas estão errados ! Este é o primeiro ponto. Segundo que, a emissão de duplicata não tem nada a ver com emissão de boleto bancário. Duplicata segue legislação específica. vejam estes links: https://franciscolimajr.jusbrasil.com.br/artigos/281404763/duplicata-mercantil-aspectos-gerais-e-sua-execucao http://www.planalto.gov.br/ccivil_03/leis/L5474.htm Se não todos, mas a maioria se quer conhecem a lei sobre duplicatas mercantis... Será que seus clientes, em vez de emitir Duplicatas, não estão emitindo somente boletos ? Alguém já tentou informar o grupo de Cobrança com tipo de pagamento 15-Boleto ?

Bom dia a todos, A explicação dada na resposta da SEFAZ/GO, ao @bilogyn está correta. O que faltou foi o fechamento da informação na resposta. Duplicata é um TÍTULO DE CRÉDITO, sendo assim, a empresa que emite uma duplicata está concedendo um crédito ao cliente, como se fosse um empréstimo. Se a NFC-e é uma Nota Fiscal destinada somente à venda à vista, não podemos informar o tipo de pagamento 14-Duplicata Mercantil. Isto para NFC-e. Para NF-e, podemos sim realizar uma venda à vista ou à prazo. Cabe informar aqui que, uma venda à vista é aquela que o pagamento ocorre dentro dos 30 dias. Portanto, se uma empresa vende hoje (07/03/2018) e efetivamente recebe no dia 31/03/2018, é considerada venda à vista. Muitos comerciantes consideram isto como à prazo, pois está dando um prazo para o pagamento, mas estão errados ! Este é o primeiro ponto. Segundo que, a emissão de duplicata não tem nada a ver com emissão de boleto bancário. Duplicata segue legislação específica. vejam estes links: https://franciscolimajr.jusbrasil.com.br/artigos/281404763/duplicata-mercantil-aspectos-gerais-e-sua-execucao http://www.planalto.gov.br/ccivil_03/leis/L5474.htm Se não todos, mas a maioria se quer conhecem a lei sobre duplicatas mercantis... Será que seus clientes, em vez de emitir Duplicatas, não estão emitindo somente boletos ? Alguém já tentou informar o grupo de Cobrança com tipo de pagamento 15-Boleto ?

à solução apresentada por @Adryelle, não podemos esquecer a CST 041, conforme NT 2016/002 1.42, ficando assim: if (GerarGrupoRepasse) and (nfe.infNFe.Versao >= 4) and (nfe.Ide.modelo = 55) and ((nfe.Det[i].Imposto.ICMS.CST = cst60) or nfe.Det[i].Imposto.ICMS.CST = cst41) and //Ajuste para funcionar no ACBrNFeMonitor ((nfe.Det[i].Imposto.ICMS.vBCSTRet <> 0) or //Qdo passar CST 60 e algum campo de repasse de ICMS ST (nfe.Det[i].Imposto.ICMS.vICMSSTRet <> 0) or //estiver preenchido será trocado o cst para cstRep60 (nfe.Det[i].Imposto.ICMS.vBCSTDest <> 0) or (nfe.Det[i].Imposto.ICMS.vICMSSTDest <> 0)) then nfe.Det[i].Imposto.ICMS.CST := cstRep60;

Aos moderados: Parece ter um outro post com esta mesma discussão e com algumas soluções:

Isto não só impacta na emissão de NF-e, mas também para NFC-e , pois o CST 60 ou CSOSN 500 também pode ser usado para NFC-e, assim temos que realizar os mesmos cálculos. Ainda agregando à última informação que acabei de citar, imagine que o mesmo produto tenha vários fornecedores em UF's diferentes, com aliquotas diferentes de ICMS/FCP (totalmente possível). Imagine também que foram feitas várias compras, mas a última compra teve uma aliquota menor que as outras. Como estou propondo guardar somente o último percentual da compra, estaremos usando um percentual menor que todas as outras compras...

@ivan_juste, a regra sobre a informação das tagsvBCSTRet, vICMSSTRet quando for CST 60 ou CSOSN 500 estão na NT 2016/002 1.42, inclusive com Regras de Validação: A minha dúvida é com relação à qual seria o melhor procedimento, menos impactante, para guardar estas informações. Agregando ao mencionado por @cleitonprogdelphi@hotmail., e já pensando no que citei sobre vários fornecedores, pensei em sempre guardar o percentual de ST e FCP em forma de percentual da última compra. Assim, posso aplicar o mesmo percentual quando estiver efetuando a venda daquele mesmo produto, na quantidade e valor da venda.

Como mencionado por @cleitonprogdelphi@hotmail., temos que guardar a ST e FCP na entrada da mercadoria. No entanto, suponha que esta mesma empresa citada no exemplo pelo @cleitonprogdelphi@hotmail. compre de um fornecedor em SP, outra compra de ES e outra de MG...com ST e FCP diferentes... Qual será a BC//Percentual à usar ? da última compra ? média das compras ?

Obtive esta tabela que resume o preenchimento do FCP de acordo com CST (Regime Normal) ou CSOSN (para Simples Nacinal). Acredito que possa ajudar. Além disto, tenho também o documento da Editora Econet, muito bom, obtido no link http://www.econeteditora.com.br/boletim_icms/assuntos_diversos/16/23/nota_fiscal_eletronica_nfe.php . Vejam a explicação do ítem 3.2.1, principalmente com relação ao CSOSN 500. A minha dúvida é sobre este valor "Retido Anteriormente", pois quando uma empresa compra uma mercadoria que já teve o ICMS/FCP retido por substituição tributária, eu devo, então, "guardar" este ICMS/FCP que foi retido ? Como informar este valor retido na NF-e/NFC-e de venda, uma vez que terei que usar o CSOSN 500 ou CST 60 ?

Caso ainda tenha interesse, abaixo um link que costumo seguir e que explica muito bem quando usar o FCP, inclusive para os contadores... http://www.econeteditora.com.br/boletim_icms/assuntos_diversos/16/23/nota_fiscal_eletronica_nfe.php

Seguem alguns links que encontrei sobre FCP : https://blog.tagplus.com.br/como-realizar-o-calculo-do-fundo-de-combate-a-pobreza/ http://blog.oobj.com.br/fundo-de-combate-pobreza-fcp-nfe-4-0/ http://wiki.sabium.com.br/FECP:_Fundo_de_Erradição_e_Combate_a_Pobreza_-_RJ http://www.fazenda.rj.gov.br/sefaz/faces/oracle/webcenter/portalapp/pages/navigation-renderer.jspx?_afrLoop=2509013814354793&datasource=UCMServer%23dDocName%3AWCC294384&_adf.ctrl-state=1a938eshaz_9 * Mesmo assim, ainda tenho algumas dúvidas...e não adianta tentar ver com contadores...a gente (desenvolvedor) acaba ensinando à eles...