Alexsander

Temos um cliente que compra papel em TON e vende em PCT com 500 folhas e CX com 10 PCT. A fábrica entrega em PAL (pallet) de 48 caixas (480 PCT), mas na NFe dela cada pallet aparece como 1,123 TON. Na prática você compra 480 PCT e recebe 1,123 TON. Então no cadastro está assim: 1 TON = 427,4265 PCT (para Entrada de NF via XML) 1 PAL = 480 PCT 1 CX = 10 PCT Felizmente eles vendem apenas em PCT e CX (C/10 PCT).

As unidades são normalmente compartilhadas por milhares de produtos, por exemplo uma CX de 50 canetas e outra CX de 144 lápis. Como são produtos diferentes, não há problema, basta informar |0220|CX|50| logo abaixo do 0200 da caneta e |0220|CX|144| logo abaixo do 0200 do lápis. O problema é quando o lápis é vendido em CX de 144 mas também em CX de 1728 (12 x 144). O registro 0220 não aceita duas CX iguais no mesmo 0200, mesmo que sejam FAT_CONV diferentes. Encontrei num fórum [1] a sugestão de usar, neste caso, embalagens "CX144" e "CX1728", mas isso pra mim parece gambiarra -- além de gerar um monte de lixo no 0190 e aumentar a complexidade geral, não suporta "PCT1000" por ter 7 caracteres no UNID_CONV. [1] http://www.spedbrasi...846:Topic:11316 Existe uma maneira melhor de fazer isso? Já pensei em converter TUDO pra unidade pra contornar esta limitação da modelagem do SPED. PS: Eu havia postado num outro tópico; houve uma resposta: Se o problema fosse apenas o tamanho do campo... CX10, CX12, CX50, etc serão também usados por milhares de produtos diferentes; CX10 de bananas e CX10 de laranjas também são "duas coisas totalmente diferentes", e a modelagem do SPED simplesmente não suporta esta diferenciação. Por exemplo, se houvesse no registro 0220 uma coluna "código da embalagem" metade do problema estaria resolvido. Talvez seja mesmo mais simples converter TUDO para unidade de SKU, tanto nas NF de entrada/saída quanto nos cupons, para contornar (mais) esta falha de modelagem do SPED.

Estou justamente vendo um caso semelhante. As unidades são normalmente compartilhadas por milhares de produtos, por exemplo uma CX de 50 canetas e outra CX de 144 lápis. Como são produtos diferentes, não há problema, basta informar |0220|CX|50| logo abaixo do 0200 da caneta e |0220|CX|144| logo abaixo do 0200 do lápis. O problema é quando o lápis é vendido em CX de 144 mas também em CX de 1728 (12 x 144). O registro 0220 não aceita duas CX iguais no mesmo 0200, mesmo que sejam FAT_CONV diferentes. Encontrei num fórum [1] a sugestão de usar, neste caso, embalagens "CX144" e "CX1728", mas isso pra mim parece gambiarra -- além de gerar um monte de lixo no 0190 e aumentar a complexidade geral, não suporta "PCT1000" por ter 7 caracteres no UNID_CONV. [1] http://www.spedbrasil.net/forum/topics/2159846:Topic:11316 Existe uma maneira melhor de fazer isso? Já pensei em converter TUDO pra unidade pra contornar esta limitação da modelagem do SPED.

E se for vendido em PCT com 1000? A string "PCT1000" tem 7 caracteres e o registro 0220 permite apenas 6.

Nenhum dos dois sistemas ECF e NFC-e é infalível, nenhum deles é à prova de fraudes. Já ouvi falar de lojas que imprimiam uma réplica de CUPOM FISCAL numa impressora comum usando o mesmo raciocínio: a maioria dos clientes não sabe diferenciar um cupom impresso num ECF de uma falsificação. Nós aqui sabemos que há pequenos detalhes (ex: caracteres especiais no rodapé) que permitem diferenciar um cupom fiscal real, emitido num ECF, de uma imitação impressa numa térmica comum -- mas os clientes em geral não sabem disso. Mas em ambos os sistemas é fácil detectar e fraude. Basta um fiscal pegar um imitação de cupom -- tanto de ECF quanto de NFC-e -- que a autuação está feita (se o fiscal não estiver no esquema, claro). Mesmo que todo um servidor web falso seja criado (no caso da NFC-e) para apoiar a fraude, basta olhar a URL do QR Code.

O lojista poderia dar um cupom falso com um QR code que aponta pra um site falso (mantido pelo lojista) onde haveria uma cópia do cupom falso, enviada por FTP pelo sistema do falsário... mas isso dá muito trabalho e é facílimo de descobrir -- e quando for descoberto, todo o registro da fraude estará no servidor web do site do fraudador.

Nosso sistema importa o XML e faz o mapeamento entre o código do fabricante (geralmente a referência) e o código interno; ao exportar um XML de fornecedor previamente carregado ele já converte automaticamente, inclusive quantidades.

Sim, estou me referindo apenas à parte de saídas e entradas por XML, isto é, partes dos blocos 0 (zero) e C. Geralmente são os maiores blocos em número de linhas. Em tese o software de contabilidade completaria o resto.

O software de contabilidade não deveria ser capaz de ler os XML emitidos e recebidos e gerar o SPED a partir deles? Tenho visto que alguns conseguem, outros não. Qual tem sido a experiência de vocês com esta questão XML x SPED?

Ambos validam aqui: https://www.sefaz.rs.gov.br/nfe/NFE-VAL.aspx

Eu mesmo baixei o XML do site, com certificado instalado no Firefox, via botão de download. As diferenças existem.

Eu também achava isso, mas a SEFAZ colocou espaço no final de TODOS os tags com elementos vazios. No XML em questão, foi no cEANTrib e nos vários outros dentro da tag Signature. Além disso eles removeram o <?xml version="1.0" encoding="UTF-8"?> do início do arquivo e inverteram a ordem da tag nfeProc: ACBr:: <nfeProc versao="2.00" xmlns="http://www.portalfiscal.inf.br/nfe"> SEFAZ: <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="2.00"> Estranho.

Achei material para embasar esta teoria: http://www.w3.org/TR/REC-xml/#NT-content A gramática é esta: [3] S ::= (#x20 | #x9 | #xD | #xA)+ [44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' Aqui diz que S é um espaço em branco, tab ou ENTER ocorrendo UMA ou mais vezes (+). Só que S? indica 0 ou 1 ocorrência, conforme o item 3.2.1 do mesmo documento, que diz: "The optional character following a name or list governs whether the element or the content particles in the list may occur one or more (+), zero or more (*), or zero or one times (?). The absence of such an operator means that the element or content particle must appear exactly once. This syntax and meaning are identical to those used in the productions in this specification." Os exemplos do EmptyElemTag, no mesmo documento, são estes (reparem no último br SEM espaço): <IMG align="left" src="http://www.w3.org/Icons/WWW/w3c_home" /> <br></br> <br/> Apesar da maioria dos exemplos na Internet usar o espaço no elemento vazio, não está errado omitir o espaço.

O ACBrNFeMonitor insere no XML a tag cEANTrib assim (sem espaço): <cEANTrib/> Isso aparentemente deu erro na importação deste XML no software de contabilidade da Dominio Sistemas. O sistema deles não importou todos os "segmentos" (CFOP diferentes), importou apenas um segmento. O contador baixou então o XML da mesma NF pelo site da SEFAZ e a tag veio assim em todos os itens: <cEANTrib /> Com um espaço antes do fechamento da tag. Há outras pequenas divergências entre o XML original (gerado pelo ACBrNFeMonitor) e o XML que ele baixou da SEFAZ, mas nos itens a única diferença é este espaço em branco. O contador conseguiu ler o XML vindo da SEFAZ no software deles. Agora ele diz o seguinte: Minha pergunta: o que eu digo pro cliente?

Acho que esta NT, quando sair, não vai mais ser 2012/004, deve ser 2013/XXX.

PS: Pelo que encontrei pesquisando pelo "connect error 10060", o problema era o antivírus.

Um erro estranho, reparem que parece estar usando a porta 25: ERRO: Erro ao enviar email SMTP ERROR: Login:???-Other undefined Status 421 Cannot connect to SMTP server XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX:25), connect error 10060 Sendo que no INI a porta é [Email] Host=xxx.xxx.com.br Port=587 ... SSL=0

Faltou o no meu post, eu estava corneteando porque ele certamente se enganou...

Opa, versão 0.9.6! Mais moderna que a versão paga, que ainda está na 0.7.x...

Sim, há os 2 casos, mas eu pergunto: isso não deveria rejeitar na Sefaz ou, antes ainda, rejeitar via "VALIDARNFE" antes de emitir? Se a tag é mesmo obrigatória e tem que ser enviada mesmo que vazia, no uso com monitor basta colocar uma linha com "IE=", certo? Ou o monitor remove quando está em branco?

Uma NFe sem a tag IE, em modo produção, não deveria "trancar" antes mesmo de enviar para a SEFAZ? Tive um caso de uma NFe que foi enviada normalmente mas o contador reclamou que ela não estava validando no software dele por falta da tag IE.

Sou de Porto Alegre, onde será esta reunião?

Acabei de baixar, via site da SEFAZ, os 2 XML novamente. O do IPI de fato está assim mesmo, validando mesmo com os valores zerados e sem alíquota. O outro caso, do espaço, está apenas no XML que veio do fornecedor; ao baixar o XML atualizado, veio sem o espaço. Os dois arquivos, entretanto, apresentam o MESMO valor em <digVal> -- aliás, a tag <protNFe> inteira está 100% igual nos dois. A única diferença entre os arquivos está na tag <X509Certificate>.

Dois exemplos: IPI que devia ser por alíquota sem tag <pIpi> com <qUnid> e <vUnid> zeradas. <IPITrib><CST>50</CST><qUnid>0</qUnid><vUnid>0</vUnid><vIPI>4.32</vIPI></IPITrib> Valor com espaços (?) em <vProd> nos totais da NF: <vProd>1587 0.43</vProd> Como vocês estão fazendo pra entrar as NF-e dos Fornecedores?

Da notícia: